SVU's blog

Talks, ideas…

Yesterday night I had two simultaneous chat sessions, both of them were quite interesting and gave me a lot of food for thought.

In jabber, Andriy Rusin and me discussed the idea of the unified DBus interface to the keyboard switching modules in DEs. The draft is published for discussion and announced on xdg and kde-core-devel maillists.

Also, Andriy nearly (hehe:) pushed me to implement the idea I had for a long while – get rid of translations from base.xml (which is getting damn fat these days). So xkeyboard-config would install a set of .gmo files and any interested app/library (read “libxklavier”) would use gettext explicitly. Some minor (intltool?) hacking would be required – the build process should change all underscore-prefixed tags in base.xml.in to the “normal ones” in base.xml, without actually merging translations. Lightweight base.xml would allow me to drop slightly overengineered DBus connection between the indicator widget and g-s-d.

Second session, with Daniel Stone on IRC, pushed another idea I had boiling in my head – introduce cross-element dependencies in base.xml. That way I would be able to say “this layout is only available for that keyboard model”. Or “this option is only available for that layout”. That kind of restrictions could be analyzed by the GUI frontends and prevent “semantically broken” configurations.

xkeyboard-config 1.1: (nearly) failed release

The release of xkeyboard-config a couple of days ago would be the smooth one, if only…

Unfortunately, by mistake, the tarbals included broken sl.po, which caused troubles in building base.xml (and subsequent problems in GNOME). I uploaded fixed tarbals several hours later – but apparently some people already downloaded original broken stuff.

I deeply apologize to everyone for inconvenience and potential troubles.

Technical detail: the .po files used by intltools cannot contain <> characters. That breaks resulting XML badly.

Ruby, part2

Thanks to Ubuntu, Ruby 1.9 is available in Gutsy. And I still cannot find the way (the letter:) to unpack UTF-16. Should I wait for Ruby 4 for UTF-16 support (necessary for proper handling of id3 tags)?

And I am really happy to see ruby packaged for Maemon (now – with GNOME and Hildon, hurray!)

PS And lads thanks for mentioning KCODE – at least handling of UTF-8 is bearable.

Ruby: disappointment of the year :(

Heard a lot about Ruby. Read some articles etc. Got deeply impressed by that really nice language. Yesterday, tried it on my small personal project – and now I am crying aloud. No native support for UTF-8 strings (well, I mean stable 1.8, not some development branch). I  still wonder how it could happen that the language with that kind of problem can even be considered as mainstream in 2007?

SVG -> Cairo, Ubuntu way – ?

In gswitchit-plugins, I am rendering svg files into Cairo. Using libsvg-cairo. Some people were asking me, if I could make .deb of the plugins (for Ubuntu). No, I cannot – because libsvg-cairo is not packaged in Ubuntu. I wonder, what do Ubuntaries do when they have to render SVG to Cairo?

XKeyboardConfig release schedule + freeze for 1.1

TWIMC

In order to a bit of order into the maintenance process, yesterday I published the release schedule of XKeyboardConfig. No more “when” questions from that point, please:)

According to the schedule, the freeze for release 1.1 is starting today.

BTW, how could I remove the page from fd.o wiki? A couple of pages were created by mistake.

LVM/Ubuntu/PowerPC

Yesterday, upgraded Ubuntu on my Power G5 from Feisty to Gutsy. Everything is smooth so far.

Additionally, tried to change a couple of partitions to LVM. Found a couple of interesting things:

1. I could not create a partition of type 8e (Linux LVM) on PowerPC. Neither fdisk not parted could help. I found the answer during the discussion with some smart folks on #gentoo-ppc (I always knew gentooers are smart, though I would never use their distro): first, fdisk on PPC is a symlink to mac-fdisk which has nothing to do with PC-oriented “usual” fdisk, second, the format of the partition table on Mac (Apple Partition Map, APM) has absolutely no relation to good old MBR/PT on PC, so signatures like 8x, 83 (ext2) etc make no sense whatsoever. So, just creating empty partition of type Apple_Unix_SVR2 was good enough – it worked ok for me, anyway.

2. Unfortunately, Ubuntu has problems with /var on LVM. The partition is mounted too late, so first parts of the init process gets screwed up (error messages about missing /var/lock and /var/run). So, I had to move /var back to “normal” partition. Pity. If anyone has idea how to fix it – please tell me. Going to file a bug in launchpad anyway.

Misc

Tried to install on N800 tasks/contacts/dates from OHand repository. Miserably failed. Missing evolution-data-server package. Where could I find one? I see the package in the repository – but for some reason AppManager is not happy with it. IIRC these apps already caused some troubles when I installed SIP support from Nokia…

I think it is time to establish some regular schedule for xkeyboard-config releases – just for distros to be able to get access to latest layouts and translations (without looking into CVS). Good old “release early, release often”. The only question is what would be the reasonable period…

libxklavier 3.3 and beyond

Finally found time to release libxklavier 3.3. GNOME 2.20 users are recommended to upgrade – selecting keyboards per-vendor would be easier than browsing huge list.

Next logical step would be finally adding language list to every layout/variant in xkeyboard-config and providing that information through libxklavier API (and GNOME UI, gnome-keyboard-properties). Sure, as with XCI_PROP_VENDOR, it would be done by using g_object_set_data, so no API/ABI breakage would be needed.

Politics. Again. Arrgh

There are not many technical challenges in xkeyboard-config maintenance process these days. The worst part of that project is politics. Now, it is about Tibetian layouts. Which ISO 3166 country code should it go under?

The worst part of it is that even if tomorrow I totally redesign the structure and make it language-based – things would not change, I’m afraid (except that in addition I’d get a lot of excitement from people disgusted by breaking compatibility).