Gpg4Win Fails in TChinese Windows

Further to my discovery of problem in Gpg4Win when the "Language for non-Unicode program" is not set to English, I decided to test it in Traditional Chinese Windows with "Language for non-Unicode program" set to same as the Unicode language (TChinese HK SAR) and to English US.

Sadly Gpg4Win will not allow me to enter passphrase when generating my key:

The captured screen shot did not show the mouse carot but it was actually inside the Passphrase edit box and no matter what I typed, nothing appearing.

The strange thing is that. I could enter my name and e-mail address, albeit very poor focusing handling, but only in the passphrase entry dialog did the program misbehave. This kind of misbehavior in part but not in other is common in this program.

Not deterred by this, my next test was to import a key that was generated in an English Windows XP. The import process worked fine.

But once again the Windows Explorer plug-in failed when I used the context menu to encrypt a small text file with the same misbehavior reported previously.

The next test is to use the File Manager (a rather clunky and clumsy user-interface. They should simply just make a Windows API call to invoke the familiar UI) from the GPA (GNU Privacy Assistance) to see if I could encrypt and decrypt the text file the loooooong way that could not be done via the Explorer plug-in.

Once again, like other features in Gpg4Win, parts work and other parts fail. The annoying things are those operations that fail aren't some exotic rarely used ones. I could encrypt a text file but when I tried to decrypt it, I was met with this familiar dialog box:

The content showed the correct armor text. To prove that the file was correctly encrypted, I took this file to an English Windows and it decrypted it fine. This clear shows another bug in Gpg4Win.

Conclusion:
Gpg4Win 2.0.4 does not work in a non-English Windows or English Windows with non-English language for "Language for non-Unicode program" settings.

GPG3Win 2.0.4 Windows Explorer Context menu still fails to work

This is my pet project to see how long it takes Gpg4Win to produce a Windows Explorer context menu that is capable to encrypt and decrypt files.

My test environment is XP Pro SP3 (English Windows) with HK SAR as the language setting for non-Unicode Programs. Gpg4Win's explorer context menu fails to encrypt and decrypt a file producing the following familiar dreaded message box:

To get this feature working one has to change the "Language for non-Unicode program" is set to English. This is an unnecessary demand clearly indicating a lack of Internationalization Programming prowess. It presents great inconvenience to non-English speaking Windows users. Sad to see this bug still lingering on for so long.

It is another case of using 'It-works-here' development methodology.

Some people just writing rubbish on the Internet

Consider this totally inaccurate and ignorant statement by Jason Hiner on ZdNet:

No Windows 7 tablets have hit the market, or even been officially announced.

Jason has either lived in the wilderness for the last few years or so ignorant to make such a statement. No Windows 7 tablet?

Is he joking? I was using one and listed on Fujitsu's product site. There are plenty of Windows 7 touchy type of touch-screen only device too if he cares to investigate. All of them can do that silly gesture to open and flick. The T4310 can do both - touch sensitive as well as using stylus to write in ink - something iPad can't do.

Just because Apple brought out a touch-sensitive device, just like those in use in check out counters, so may so called tech journalists are totally confused.

It is like saying a vehicle is not a car if it does not look like a Mini while accusing Toyota and Land Rover has yet to produce a car!

Important to set up a subversion repository correctly

To use Subversion effectively, one needs to sit down and plan the organization of the repository layout. "Version Control with Subversion" book page 16, recommends:

While Subversion's flexibility allows you to lay out your repository in any way that you choose, we recommend that you create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies, and a tags directory to contain tag copies. For example:
$ svn list file:///var/svn/repos
/trunk
/branches
/tags

Failure to adhere to this recommendation can bring lots of grief later on. Often when you start off a project, you may not anticipate that you may need tags or branches and hence you start importing file directly into the repository at the root. Like this:

Then one day you decide to start using tags to record interesting events. Where do you now put it? Let's create a directory called Tags and put it there, like this:

Now you may think this fixes the problem. Not quite. If some one decides to check out the trunk, this is what you will end up with:

Now you do not only get the files for the trunk but also files associated with every tags you have in the repository. In this demo, I only have one tag.

While it is not a dead loss, you can still fix this situation. First get everybody to check in everything first.

Then create three separate directories in the repository, 2 are of immediate need, as Trunk, Tags and Branches directly below the root. Staying with the recommended names and structures benefit everybody and avoid misunderstanding.

Select all the trunk directories, excluding Branches, Trunk, or Tags folders, and move them into the Trunk sub-directory.

Check the Trunk out to a different directory on your local drive. it is best not to use your old copy anymore. Then tag that immediately so that you know this important event in correcting the repository directory structure. Of course you store the tag in the Tags sub-directory.

These steps are totally unnecessary if it is done immediate after the creation of the repository.