Following up to my Mailing list actions stories, today I received the check with the bounty money!
Which is a definite improvement over the four months it took them handling the my NNTP bounty. Gotta like the good people over at Ximian (now owned by Novell). It's still not four hours though :)
A timeframe: on 24 November, I filled in the bounty claim form; after that, I filled in and posted the Ximian copyright assignment form On 20 December, I got an e-mail, saying I should fill in the copyright assignment form; the Novell people said they would "check it up". On 23 January, I sent an e-mail about when the cheque was going to be sent, but the cheque had in fact probably already beeen sent by then: the check, dated 17 January, arrived with me today, the 27th January.
Posted at 19:06 - [/projects/eplug-mailing-list-actions] - permanent link
Here's what I think:
- 22-01-2005: Victoria is the mole!
- 15-01-2005: Yvon is the mole!
Posted at 00:02 - [/misc] - permanent link
As mentioned, I used Dxgettext (aka GNU Gettext for Borland Delphi, C++ Builder and Kylix) to translate my Borland C++ Builder 5 application into multiple languages.
While this was actually quite a snap, also thanks to the great docs, there was one problem I encountered. Trouble is that C++ Builder 5 includes the Pascal compiler from Delphi 5, for which Dxgettext has a separate module, which caused a bit of trouble when used in C++ Builder 5. Easiest would probably be upgrading to C++ Builder 6, but version 5 happens to be the version I actually paid good money for, so I'll just stick to that for now, thank you.
Anyway, the trouble is the following error message:
[C++ Error] FfrmGeneral.cpp(51): E2015 Ambiguity between '_fastcall Gnugettextd5::_(const System::AnsiString)' and '_fastcall Gnugettext::_(const System::WideString)'In other words, both namespaces define a
_ function, and C++ Builder doesn't know which to choose. We want to use the Gnugettextd5:: variant, because the C++ Builder 5 VCL uses AnsiString and not WideString. The solution is to #define NO_IMPLICIT_NAMESPACE_USE prior to #include'ing the Gettext files; this removes the using namespace Gnugettext clause found in one of the (auto-generated) headers, and then add using namespace Gnugettextd5 ourselves, like this:
#define NO_IMPLICIT_NAMESPACE_USE #include "gnugettextD5.hpp" #include "gnugettext.hpp" using namespace Gnugettextd5;_ function fromGnugettextd5without problems. Unfortunately,TranslateComponentis defined inGnugettext, so when calling it, we need to explicitly mention the namespace:Gnugettext::TranslateComponent (this, "");Another irritating thing is the fact that many VCL functions, such asApplication->MessageBox, usechar*arguments, so in my case, I need a hell of a lot ofc_str()calls to make things work. It later occured to me that this could be fixed by removing theusing namespaceline and instead adding something like:char* _ (const System::AnsiString argument) { return Gnugettextd5::_(argument).c_str (); }This should make the
_function work under all circumstances without problems. I didn't try it though, I'll stick with thec_str()solution for now, but you may find it useful.Posted at 00:00 - [/projects] - permanent link
Mon, 24 Jan 2005Afer an e-mail I got today, I decided to take the challenge and see how difficult it would be to make it translatable into multiple languages. The answer: it's pretty easy, much thanks to Gettext for Borland C++ Builder (some technical notes to follow).
Anyway, here's a test executable: download. Sources can been seen in the
i18n-branchbranch of the CVS. It is still Dutch by default, but it has English baked in. It should boot in English if you have an English version of Windows; otherwise, start a command prompt, and enter the following (from the directory you downloaded the EXE to):set LANG=en widm-ii18nI didn't do much testing, so it is bound to have some problems (particularly in the area of pass question calculation, and labels showing off to small and stuff); be sure to e-mail them to me.
And perhaps more importantly: if you want to help out to make WIDM available in your language, that's pretty easy too: grab Poedit, start translating this file, and e-mail the results!
Posted at 23:43 - [/projects/widm] - permanent link
When I released the fixed WIDM last week, there was still a known crash when entering a non-existing name in a test. I found the bug; it seems to only occur when two contestants have the same name; I both fixed the bug and added code to check against that. Full changelog since last week:
- No longer allow two contestants to have the same name (causes crash)
- Replaced English texts in program by Dutch versions (bet I forgot a few though)
Happy mole-catching!
Posted at 21:28 - [/projects/widm] - permanent link
If you have a Medion 5044 TV card and you want to use it under Linux, you may have the same problem I had. The Medion 5044 is supported in Linux 2.6.* through the
saa7134 driver developed by Gerd Knorr. If you have it, you should be able to get it running using
>modprobe saa7134 card=9
The problem was though, the audio didn't work for me: all I heared was buzz. Fortunately, there's a solution. Get your kernel sources, and look for a file called saa7134-cards.c; in it, there is a line:
.audio_clock = 0x00187de7, // was: 0x00200000,I got tempted to try reverting that change because previous versions of the driver did work fine for me, so I changed it back to:
.audio_clock = 0x00200000,And that fixed the problem.
On a related note, in Ubuntu, if you build your kernel, the modules are not installed in the right place where modprobe can see them: modprobe looks in something like /lib/modules/2.6.8.1-4-386/, where the modules are installed in /lib/modules/2.6.8.1-4/. The solution is to copying the files over, or, to test, first modprobeing the old saa7134, then rmmoding it, and then do something like:
/lib/modules/2.6.8.1/kernel/drivers/media/video/saa7134/saa7134.ko
Update Gerd Knorr says the following:
> things are now working perfectly. Maybe there are two different types
> of Medion 5044 cards out there?
Probably, newer kernels should even print that to the log on driver
load because there is no (known) way to figure which one is which.
You can fixup that with the audio_clock_override insmod option at
runtime, without modifying the source code.
I'm currently capturing TV so I'm not going to try, but apparently this is the way to go (though since audion_clock_override doesn't seem to be documented I'm not sure):
modprobe saa7134 card=9 audio_clock_override=0x00200000
Posted at 10:10 - [/projects] - permanent link
This is the first post of a series of posts about the Piclig.net website, a website created as a communication design website by Christina Schultz, in which I helped a bit; more about that later.
"Piclig" stands for "Picture Ligature", which is what the project tries to achieve: a merge between two important concepts in markup: emoticons (pictures), and ligatures. Ligatures are what happens when multiple characters, when placed after each other, form one character, which is more or less the case in Holland with "ij", which is often written as one character. See the Wikipedia.
Basically, Christina has made a font that consists of both normal writing characters, and emoticon-like symbols such as happy faces, but also for example an icon for "telephone" and for "chichen" (one of my favorites). There were already fonts that contained only symbols, such as Wingdings, but this combination of special characters and normal characters in one font means that any application that uses the font can also show the piclig symbols.
The idea would be that when you type in a combination of characters, just like with emoticons, it would be replaced by the appropriate symbol, for example ";D=H" becomes chicken. Or, as Christina describes it:
piclig is a font with smart characters, which when typed in a specific succession, merge together and form picture ligaturesA demo can be found on the Piclig website. So summarizing: the idea is to put emoticons along with the normal characters in a font by itself, rather than transmitting them as images, which is what happens now. Apart from the fact that this saves storage, this would also mean that the emoticons can be used in pretty much any application.
While the idea is nice, in practice things are a bit more difficult. This is because ligatures (i.e. automatically replacing a series of characters with its ligature), is not really widely supported by operating systems yet. The OpenType font file format has support for ligatures, but Operating Systems do not seem to actually use that information: neither Windows, nor Linux or Mac OS X (for all three, support seems to be in development, particularly for GTK, but it doesn't seem to really actually work yet). This means that currently, one specifically needs to add support to programs that want to use Picture Ligatures (or normal ligatures, for that matter).
And that's where I come into play. After mistaking my character substitution plugin for Blosxom for a client-side plugin, Christina e-mailed me, so I offered to add support for Picligs to an online Java chat program for a demo. The result can now be admired on the piclig website. Later on, I'll talk about how I added Picligs to an on-line chat program, and how you can add Piclig support to your programs, too! More on that later.
Posted at 21:55 - [/projects/picligs] - permanent link
Now that the new Wie Is De Mol series has begun, this draws attention to my Wie Is De Mol software, too. This is why a did a bit of bugfixing. There's a new testing WIDM executable that fixes the following problems:
- Fix problem where "mol" as question answer didn't work
- Fix problem where sometimes, the wrong person would be executed (when two persons had the same number of errors)
Also, check the WIDM CVS here.
Posted at 20:53 - [/projects/widm] - permanent link
At the end of the year, it's hard to resist making end-of-year lists, so I could hardly resist making a list of all my weblog articles over 2004. In the end, I didn't actually get around to doing it, but since I was patching along nicely this evening, I figured now would be the time to do it.
So. From now on, for any /index.html URL in my website, substitute it by index.index.html to get an index. Nifty, eh?
Internally, it is driven by the index.html template, which can be found here. I added the following to my blosxom.cgi to generate it:
@static_flavours = qw/html rss index.html/;So.. to see the offical "Meilof's homepage" 2004 overview, go here and be amazed...
Posted at 02:24 - [/log] - permanent link
For everyday use, I often make backups of DVDs. I do this by storing the DVD on disk with DVD Shrink, which works really nicely under Wine, and then burning the thing as a data DVD with K3b.
But. There's a slight problem. The DVD's play fine on my standalone DVD player (a real Lenco!) as well as under Media Player Classic, but XINE refuses to play them, giving output like:
$ xine dvd:// This is xine (X11 gui) - a free video player v0.99.1. (c) 2000-2003 The xine Team. libdvdnav: Using dvdnav version 1.0 from http://xine.sf.net libdvdread: Using libdvdcss version 1.2.8 for DVD access libdvdread: Attempting to use device /dev/hdd mounted on /media/cdrom1 for CSS authentication libdvdnav: Can't read name block. Probably not a DVD-ROM device. libdvdnav: Unable to find map file '/home/meilof/.dvdnav/.map' libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.BUP failed libdvdread: Can't open file VIDEO_TS.IFO. libdvdnav: vm: faild to read VIDEO_TS.IFOThe problem here is probably in
UDFFindFile: because I put the data DVD in my DVD drive, libdvdnav naturally assumes it's a media DVD with UDF, which it's not.
The same set of files does play nicely when played from the hard drive, e.g.:
xine dvd://home/meilof/dvd/
This gives rise to a very simple workaround to fool XINE into thining the files are not actually on a DVD drive, by creating a symbolic link to the DVD drive in my home directory. Indeed, after running:
ln -s /media/cdrom1/ /home/meilof/dvdthe above
xine command runs fine. Of course, this is still a pretty preliminary solution. It also has the disadvantage of needing to mount the DVD before viewing, which libdvdnav would normally do automatically for us. The real solution would be to edit libdvdnav to fix this behavior.
I didn't do that yet, but I did do a small fix that at least gets rid of the symlink: I added support for an environment variable DVDNAV_NO_DEVICE which, if set, makes libdvdnav stop trying to get the device from a direcory. The patch for the latest libdvdnav is here. To apply, go to the src/dvdread subdirectory of your libdvdnav sources, and enter:
patch < libdvdnav-dvdreader-nodevice-diff dvd_reader.c
Unfortunately, Xine ships with its own version of libdvdnav, so to have the fix in Xine as well, you need to apply the patch in the Xine source tree (src/input/libdvdnav subdirectory), too, and rebuild Xine. After that, a data DVD with video on it can be played with something like:
DVDNAV_NO_DEVICE=yes xine dvd://media/cdrom1/If you'd ask me what's the added value of this over the symlink workaround (since you still need to mount and all), I would honestly don't know :) I may have a bit of a closer look about whether I can get it to work automagically, without the environment variable.
Posted at 02:11 - [/projects] - permanent link
From Meilof's Assorted Patches Department: can you use JavaScript on a web page to detect whether a specific font is installed? Answer: yes, but...
When looking around the usual "you should not want to check whether a specific font is installed" chit-chat (and I really needed it for a project -- more on that later), one quickly finds out there is no direct way to test whether a font is available in JavaScript.
Luckily, the people at WebReference.com found a smart way to check anyway. Basically, what it boils down to is that using DHTML, two hidden text layers are created, one with the font you want to check, and one with the default font. If the layer with the font to check has a different size than the layer with the default font, then apparently, the font is installed, otherwise, it isn't.
The downside is that the article is already a few years old. It works with Internet Explorer 5.5 and higher, and Netscape 4. Yes, you read it right, Netscape 4. Mozilla, Firefox and Netscape 7 all, unfortunately, don't support the detection method mentioned in the article.
I did a bit of hacking to the JavaScript. This makes it work with very recent Mozilla Firefox versions with document.all support (which does not include Firefox 1.0, unfortunately). It should be possible to re-write the same basic idea using real DOM code with getElementByID and stuff, but unfortunately, I don't know anything about that and no-one else seems to have done it, either.
So, basically, the idea is nice and it actually works in practice, but the current code is very IE-specific and I don't have the knowledge to fix it. If you want to test with it, here are my sources.
Posted at 23:50 - [/projects] - permanent link
As an update to my previous story, the Posadis Wiki with this patch applied actually went live two weeks ago, and it all seems to work pretty well. Except, I noticed, I forgot to update the code that generates InterWiki links. The updated patch is here to fix it.
Also, I e-mailed Andreas Gohr about my patch, and here's what he said:
This was supported in one version but was dropped again because it tends to break included files like images and CSS.As I said, images, CSS, scripts and now also Interwiki images seems to work quite nicely in my case. Since it doesn't seem this patch is going to be put in the main DokuWiki, I'll just maintain it here and I'd like to hear in case of any problems with it.
Posted at 23:17 - [/projects] - permanent link