Usinability

A few notes about XChat's (version 1.8.9, hopefully these have improved with version 1.9 which has apparently a rewritten GUI code for Gtk2) UI, after a day of using it:

• To modify the IRC colours, you need to use the Palette dialog. There is no further explanation for the colours, besides the names visible in the window. You can adjust each colour individually, but the changed aren't mirrored by the UI instantly. To see how your change has affected the display, you press the "OK" button, which makes the dialog go away.




• The settings dialog has an Apply button, luckily. However, some of the changes will only take effect after you close the IRC window. Confusingly enough, not just the leaves, but also the branches contain configuration options, just like Mozilla.

  Some of the options are accompanied by enlightening tooltips. The option "Old-style Nickname Completion" has a tooltip making it all clear: "Nickname completion is old-style (instead of GNU-style)". Of course, not all the options have tooltips, but some of them do have one-line explanations in the manual. On the other hand, the manual also describes some options which can't be found in the UI.




• Key bindings are modified via the Edit Key Bindings dialog, with yet another appearance and logic of operation. Without OK/Apply/Cancel, your changes affect the UI as soon as you do them. The lower part of the dialog contains an initially empty field the same colour as your IRC window. If you resize the dialog, weird things happen.

  If you press the "Add new" button, a new line is appended at the end of the list, but nothing else happens. The text fields are always active, but they don't have any effect if you don't have a line selected.

  
  

  The text fields have slightly erratic behaviour: the "Key" field contains always the name of the last key you pressed. If you pressed shift, it says something along the lines of "Shift_L", if you pressed a, it contains "a". This change is instantly visible in the list. The next two text fields are still a mystery if we are adding a new key binding. However, they behave like normal text fields, and things you type into them aren't mirrored by the list before you press enter.

  
  

  Next up are the modifier selectors: these, again, modify the entry in the list instantly. Of course they don't mirror the list of your real modifier keys, so I don't get to choose Hyper or Super.

  
  

  Finally there's the option menu. It gives you a list of functions, and when you select one, the explanation for it appears in the strange box underneath. In the same font as you selected for your channel windows (or maybe dialog windows? I don't know, I didn't see a need to use different fonts for them), and if you happened to choose to display time stamps before messages, you get a time stamp in the help box too. However, here you luckily get explanations for the "Data 1" and "Data 2" fields, the meaning of which vary from command to command.

The server window has its share of problems too, but I don't think I'll go into them now.

However, despite the above, I think I prefer XChat to the other currently available options. And maybe some of the problems have been fixed. If not, after the move to Gnome2/Gtk2, I hope I can do something about them. At least I have the source.

Easy to use Euros

I've been wondering for a while why I can't get the Microsoft web fonts (one of the truly nice things to come out of Redmond) to display the Euro symbol, as it's pretty obvious they do support it. The problem came even more "acute" as I started to IRC with XChat and dircproxy and decided I wanted to use Georgia as my font.

After Googling and apt-cache searching for a while, I finally found the reason and the solution: the program I've been using to generate fonts.dir files for xfs to read is mkttfdir. I don't remember how I found it, but there it is. It has been doing it's job mostly OK, so I haven't bothered to mess with it, but turns out it handles only ISO-8859-1 and JIS. Now I found out there's another fonts.dir from TTF generating program, called ttmkfdir (naturally!), which does all the encodings. I'd just love to know why the apparently broken mkttfdir is packaged in Debian.

I guess there's a HOWTO or FAQ somewhere which explains this all. I just love it when things are intuitive.

me2

Jarno listed many of the problems surrounding moving a blog I've been thinking about too. Luckily I'm too lazy to have a RSS feed without the platform doing it for me, so no problems from that.

Patch it up

XML-RPC works via HTTP POSTed XML messages. Araneida, as of version 0.61, assumes all POSTed content is form/urlencoded, but that isn't correct in this case. I have a mostly-working XML-RPC server implementation in Common Lisp ready but I wanted to get it working on Araneida, so this was a problem. I patched Araneida to figure out from Content-type how to handle the content; however, sending just a patch to allow not to modify the content seemed kind of silly, so I ended up doing support for multipart/form-data too.

A few minutes ago I sent the patch to Dan, here's hoping he'll accept it. I kind of expect it to be shot down in flames, as my Common Lisp is still a bit shaky :-) We'll see.

About XML-RPC: it seems to suffer from some of the same problems as RSS apparently does. Weak specification (there should hardly be need for a FAQ to figure out the protocol) and the only way to figure out if you have it more or less correct is to use the UserLand validator. It does have its strengths too: it's extremely simple, but often good enough to do the job.

Attack of the Clones

Not surprisingly, I'm not the only one working on a LSP-like thing. And he's quite right in that A) everyone has done one already and B) all this would have been a lot cooler in 1997. Of course, I'll probably do my own thing anyway because the code is already there. ATM it looks like it'll be for Araneida, not AllegroServe, though.