GNOME
So, 2.9 is starting to freeze. The keyboard stuff is in a reasonably good shape. The only thing which bothers me is that yesterday I fixed long outstanding bug with the multiple applet instances – and now the plugins are effectively broken. Expecting some number of bug reports regarding this…
GNOME
Yesterday I made first relatively large commit of the new keyboard preferences. Basically, the idea is to get rid of the applet properties altogether, move some of them to the control center and leave the rest on the gconf level. So, the screenshots of the first version (withouth preview) are here and here. Comments are welcome (directly or in the mailing lists).
HAL
So, the very first battery daemon is working – and updating the mouse’s battery status. The code is not in CVS yet – waiting for David to commit it there (I know, he first has to do some initial restructuring in 0.5 series). The discussion regarding ACPI in HAL generally shown the WTG – again, just waiting for 0.5 development cycle to start – so I could add ACPI daemon. David, let’s branch 0.4 and start ruinning the HEAD:)
GNOME
I am finally confident that all the Keyboard Indicator Applet’s preferences should go into the g-c-c’s Keyboard Preferences (separate tab, popup dialog – whatever). All these options should be system-wide and should not depend on the fact whether the applet is on the panel or not.
GNOME
Massive cleanup in gkb-new. Only xmodmap stuff is remaining from that point. Got confirmation from Shooby (humm…) that I can move xmodmap data to X11 licence (to xkeyboard-config) – but will not do it, for now. Still, xmodmap stuff needs some cleanup and polishing – the slow, error-prone process (expecting loads of bugreports). Well, really, xmodmap layouts are in a good shape as they are – BUT since it was agreed to use Alt-Alt as a default switcher – I have to ensure that all layouts are ok with it (Alts are used in a “conformant” way). So here can be some problems…
GNOME
Thanks to Alexandre Prokoudine, I got my very own “head”. So now Planet GNOME can use it with all the stuff coming from my name.
HAL
It seems the project “a battery the way HAL percieves it” finally cought me. Ma, I swear, I did not want to start it!
libxklavier
Ugh. Released 1.12. And it really works with xmodmap (yeah, I tested)! By default, xmodmap is disabled – but just adding –enable-xmm-support to configure turns it on.
GNOME applets
Next thing to do is to perform major cleanup in gkb-new directory tree (remove xkb-based layouts, remove C code etc etc). Sure, I won’t do it till I discuss it with other folks involved in gnome-applets maintenance. BUT this is a minor thing comparing to the bigger issue I got. I would like to move all xmodmap data from gnome-applets to xkeyboard-config. And cannot do it without contacting the author. Yeah, you are right. This is about viral GPL which I cannot turn into MIT X11.
Hardware
Got my nice new mouse: Logitech® MX[TM]1000 Laser Cordless Mouse. 12 buttons. Damned xmodmap sees only 7 of them – even though server itself (and xev) sees all 12 (well ONLY with evdev patches!). Trying to realize where is the bottleneck – still stuck… Also, found lmctl. Nice utility, indeed! And it shows the mouse battery status! What about the GNOME applet for it? I always missed such a thing with previous Wireless MS Explorer… Unfortunately, ordinary user cannot write into /proc/bus/usb files – so I’m afraid I’ll have to dig into Project Utopia, Dbus etc etc etc. Scary business…
libxklavier
Lazying around xmodmap support, I tightened the gcc options. Now I use “-Wall -Werror” which is ok. But “-ansi” makes me some trouble. No more strdup and snprintf – they are not standartized. Sure, good old #ifdef allows me to put their declarations into my headers – but thats sucks big time… Especially taking that snprintf is REALLY not avalable on some systems.
At the moment, I just declare these functions inside #ifdef (keeping the -ansi in Makefile.am) – but I’m afraid at the end of the day I’ll have to provide my own implementations. _XklStrdup and _XklSnprintf?.. 🙁
PS Do NOT ask me to use glib please. It is not standartized by fd.o yet.
PPS The code is not in CVS yet. Just in case if you are interested…
libxklavier
Another breakage of libxklavier API is nearly there (not in CVS yet but…). xmodmap support happens to be more PITA than I expected. Well, it is good anyway – the reason to cleanup and polish.
This time I will try to make the API transition process as smooth as possible – I will commit all changes to libxklavier, g-c-c and g-a simultaneously – and at the same time I’ll release 1.12 of libxklavier. I really hope this will save me some bad mail… If anyone has better ideas on how to handle this – I’d appreciate. The biggest challenge is that jhbuild builds libxklavier from CVS – but at the same time g-c-c and g-a cannot depend on unreleased API…
Planet GNOME
Now, when I am registered at the Planet GNOME, I’d love to get my very own little hackedgotchi. Is there anyone who would be able to help?
GNOME
Thanks to ska-fan and jdub, this blog is recognized by the Planet GNOME. Now, if only my name would be written in cyrillic as Сергей Удальцов…
Libxklavier
About to release 1.11 (actually, it is already tagged). Keeping the API stable, I performed substantial internal reogranization. For now, all the xkb-related code is localized (well, at least from the compiler POV – noone knows when I bump into some implicit assumptions which won’t work for xmodmap logic). The vtable idea seems to be the WTG. Scary thought – but it seems I finally have to go for xmodmap support. Sure, not earlier than 1.12…
