As usual please refer to the documentation to know how to use it.

List of changes:

* Updated packaging dependencies for Ubuntu 10.10.

* New functionality: “Quick Lookup In…”

* Fixed bugs in Unmark Words and Unmark Words Forcibly

A bug in Gmail allowed students at some schools to read each other’s emails. I don’t know about you but I’d rather not have other people read my emails. (Yes, I know the vast majority of emails are transfered in plain text. I does not entail that it is okay for my colleagues to be able to access my mail folders.)

if (count == 0) return false;
return true;

Why not this:

return (count != 0);

There are some god-forsaken languages in which returning the evaluation of a boolean expression is not valid (e.g. the creeping horror which goes by the name Open Office Basic).  C and C++ are not among these.   Yet, I’ve been running across a good dozen cases where the coders did not realize that.

In case someone would like to object: I know it is possible to just return count and let the compiler do an implicit conversion to bool but an explicit test makes the code clearer.  The additional “if … then” does not.

As usual please refer to the documentation to know how to use it.

I have not been able to work on getting OOHanzi to work on OS X so I presume it still does not work.

List of changes:

* Updated packaging dependencies for Ubuntu 9.04.

* Performance improvements in “Mark Words Present In…”.

* Added support for variant readings when using “Mark Words Present In…/DDB”.

I’ve switched to KeePassX because it seems better supported and has the features I want. Wzzrd produced a script to perform the conversion. His script is in Ruby, a language I’m not particularly interested in. Moreover, his script did not quite do what I wanted so I converted his script to python and adapted it to my needs. I’m attaching the script to this post: revelation-to-keepassx Anybody wanting to use this script should be warned that it is throwaway code and that I implemented just as much as I needed.

The way I converted my data was:

1. Export the data from revelation into an unencrypted XML file. (It is advisable to export it to a file in volatile memory like /dev/shm. This minimizes the risk of leaving unencrypted data in free blocks after the conversion is done.)

2. I ran my script without options:

$ revelation-to-keepassx /dev/shm/revelation-export.xml > /dev/shm/keepassx.xml

(Note that I save the result in /dev/shm again.)

This resulted in the output:

revelation-to-keepassx: ERROR: stripped following ids: generic-keyfile, generic-location, generic-certificate, creditcard-cardtype

I checked my input file to verify that I would not lose anything important if <field> elements with the above ids were to be stripped from the output instead of converted.

3. I reran the script as above but with the “-i” option which tells the script to ignore the stripped ids.

4. I imported the resulting file into KeePassX.

I’ve inspected the final database and found no evident problem. To be on the safe side I used gpg to encrypt the XML file I exported from revelation so that even if I eventually run into trouble and revelation is not easily installable, I can visually inspect the XML file.

1. Open your deck in Anki.
2. Go to File->Export.
3. Set the export format to “Facts in tab-separated text file”.
4. (Optional:) Limit by tags.
5. Click “Export to…”. You will have to select a file to save to.
6. You then need to rearrange the output of Anki. Anki outputs its data as: Chinese TAB English TAB Pinyin. Pleco wants Chinese TAB Pinyin TAB Chinese. Any macro or script which reorders the second and third field will do the trick. I use the following:
   
$ gawk -F '\t' -- '{print $1"\t"$3"\t"$2}' [exported file] > [fixed file]


   “[exported file]” is the file previously exported from Anki. “[fixed file]” is where to save the output.

7. Shove “[fixed file]” onto a flash card or transmit it to the device running Pleco.
8. In Pleco, select “Modules->Open Flashcards…”.
9. 9. Click the “Import” button.
10. 10. Set the following:
    • Source: the file you want to import.
    • Card Language: Chinese-English
    • Text Encoding: UTF-8
    • Missing Entries: Create Blank
    • Ambiguous Entries: Prompt
    • Duplicate Entries: Prompt
    • Store imported defns in user dict: unchecked
11. Hit start. Make sure the sample data looks good. Hit yes if it does look good.
12. Exercise left to the reader: check that your cards look good after importing.

OOHanzi 0.6 has been released.

Of all the releases of OOHanzi so far this is the one which has required the most work and which contains the most substantial changes. There are significant visible improvements but the bulk of the work happened under the hood and is invisible to regular users.

There is one major usability improvement: OOHanzi can now be installed by downloading and installing a single package instead of 5 packages. Please refer to the documentation to learn how to use this new method.

List of changes:

• The user documentation is now stored in an OpenOffice document rather than in an XML document. This will allow for nicer, more friendly formatting of the documentation in the future.
• OOHanzi now uses the officially recommended method to set preferences.
• OOHanzi now checks whether strings passed for lookups are bigger than defined size and warns the user if it is the case.
• OOHanzi now checks whether strings passed for lookups are Chinese and warns the user if the string does now look Chinese.
• When performing a lookup, OOHanzi now sets the system clipboard to the selected text.
• Major restructuring of the selection logic. This allowed the next two changes.
• It now is possible to use OOHanzi in oobase.
• OOHanzi would crash on any operation having to do with text in footnotes. This has been fixed.
• Fixed a bug which caused “Mark Words Present In…”->”DDB” to fail to scan the last character of a selection.

The good:

1. Open Office 3.0 feels snappier than 2.4. I don’t have hard statistics but it feels like it starts faster and various operations are faster.

2. Extensions designed for 2.4 work in 3.0 without modification.

3. A window bug in 2.4 which was triggered by compiz has been fixed in 3.0

4. In text documents, it is now possible to see the content of notes on the right side of the document. I would go as far as asserting that before 3.0, Open Office’s support for notes in text documents was so badly broken as to be unusable. In 3.0 it is possible to put notes to good use. And I would say that this feature alone is what made the move to 3.0 worthwhile for me.

However all of the positive above is undermined by long-standing problems in Open Office which still have not been fixed in 3.0:

1. Open Office’s support for notes is still deficient. It is not possible to associate a note with a span of text. I find this very annoying because I usually think of notes as comments on spans of text. It is currently not possible to select part of a paragraph for instance and add a note saying “this passage is incorrect” which would clearly be associated with the selected passage. If you select a passage and add a note, the note will be inserted at the start or end of the passage without any indication of what exactly it applies to. So you have to write in the note “The passage from A to B is incorrect.”

2. It is still not possible to get a split-screen view in Open Office. This may be due to just how abysmally ill-designed the underlying architecture of Open Office is. I often find myself wishing for such functionality. Sigh…

3. Open Office is just as likely to crash as before.

4. As I intimated above, the underlying architecture of Open Office is just as horrible as it ever was. If you have never tried to write extensions for Open Office you have no idea just how bad it is.

5. The documentation is just as inadequate as before. I’m talking not only about the documentation available to people writing extensions but also the documentation for end users.

Lately I’ve found asking myself why I’m putting up with Open Office and why I’m writing extensions for it. I keep having to remind myself that although Emacs would be more pleasant to work with, it is not a likely tool for most of my colleagues. Word would sit at the top of the list of most popular tool but due to ideological reasons (Word is not open source software) I’m not going to develop for Word. This leaves Open Office. I’ve checked again this morning what was available in the open source world and as bad as Open Office is, there is really no other contender. In my opinion, other office suites are either incomplete or not supported well enough on other platforms. I’m not fond of Windows but I’d rather develop extensions for an open source suite which is fully ported to Windows rather than an open source suite which is only half-ported or badly ported. Ditto for OS X.

I’ve upgraded from Hardy to Intrepid and found a slew of problems. First the problems which are not fixed:

1. Gnome does not want to start the gnome-terminal which is saved in the session configuration. After further investigation I found that session saving in gnome 2.24.1 does not work at all. This is a regression bug and a major one at that.

2. Update: I can’t sync to my cell phone using bluetooth. The bluetooth driver is there and working but to be able to sync there need to be some configuration performed. The configuration of the bluetooth tools has significantly changed since Hardy so this is not a trivial thing to fix. And the documentation seems nonexistent. One step forward, two steps back.

3. Evolution displays negative total number of emails.

Then the problems which I have been able to fix:

1. The guys working on compiz have decided to go from 0-based indexing of viewports to 1-based indexing. Of course, user settings are not automatically upgraded so I had to go into my configuration and fix that manually. I think the change is good because 0-based indexing makes sense only to programmers. However, not providing for an automatic upgrade of the configuration data is asinine.

2. scim initially refused to start. It turns out that skim was preventing it to run. Not skim directly but there was a session script which checked whether skim is present or not and if present would refuse to run scim.

3. Evolution at first did not want to connect to my mail server. I fixed this by switching from TLS to SSL for the connection protocol.

4. Update: Hardy and Intrepid run different versions of rsync. Unfortunately, the two versions do not speak the exact same protocol. There is some degree of compatibility so not all uses of rsync between an Intrepid and Hardy machine are doomed to fail. However, I use rsync in such a way that Intrepid’s rsync cannot talk to Hardy’s rsync. I’ve backported Intrepid’s rsync to Hardy to take care of that problem.

5. Update: Skype initially was not able to produce audio. Changing my sound out and ringing devices in the “Sound Device” tab of the “Options” dialog to the value “pulse” fixed the problem.

6. Update: Spamassassin’s cron job fails. A workaround exists.

7. Update: The Eclipse version bundled with Intrepid is both ancient and buggy. To be fair that is also a problem with Hardy. The problem has been reported and a newer version of Eclipse exists in one of the PPAs.

8. Update: Evolution displays a huge “Show:” button. I fixed this by going into the gconf registry and removing the key at /apps/evolution/mail/labels.

I will update this page as I find more.

1. OOHanzi will work with Open Office 3 without modification.
2. There was a bug in Open Office 2.x which affected only people using compiz. If compiz was running, all dialog boxes which were created by the Java virtual machine running in Open Office would be displayed smaller than they should have been. This bug crippled OOHanzi pretty badly. After testing Open Office 3, I found the bug has been fixed.