Tried a bit of nostalgia driven “comfort” programming making wmapcups. It is a Window Maker dockapp that presents the status of an APC UPS via the apcupsd.
Window maker itself is a bit dated compared to the ‘desktop managers’ these days but it is fast if can look past that. If your keyboard sees more action than your mouse and you don’t want to to overboard with tiling window managers this is a good trade off. I use window maker at work on one of the older PCs while the newer ones run xfce4. I use dockapps under Xfce through a panel plugin called xfce4-wmdock-plugin which gobbles up X11 programs that provide the hints that they are dockapps.
My running dockapps in xfce4 panel plugin.
Dockapps are widget-ey programs with UI made of a small square (64×64 or 48×48 pixels) mostly presenting some information. Most dockapps would serve some purpose now handled by panel (or taskbar) plugins except they have the same consistent ‘square’ tile feel. The whole ‘style’ of window maker and dockapps is inherited from the NextSTEP OS.
To write a dockapp, some familiarity with X11 programming would be useful. However its quite simple to glean the essence of it from the existing dockapp sources. Also there is library called libdockapp that wraps up the most common pattern used in the sources. For pythonistas there is a module for writing dockapps as well (I’ve not tried it yet).
Window maker development was dead for many years during before being started up again in 2012. The current team accepts patches for window maker and few orphaned dockapps that they’ve adopted.
Continuation of the previous one.
The “M$ occassionally we make usefulstuff” keyboard is working fine after foolishly attempt looking at xev output and modifying /usr/share/X11/xkb/keycodes/evdev to map what I thought was the correct codes. The wrong codes were due to my mixing the kbd driver and evdev driver (for extended events aka fancy buttons). You get both if you comment the kbd driver out (in xorg.conf) and add two evdev keyboards (for me the event devices are event5 and event6). X not getting the device from HAL automagically has something to do with the GDM kinda session creation. I login to console and ‘startx’ – more digging later.
The Caps to Control map that did not work in console (mentioned in earlier post) was due to change in approach to doing it – Now you set X-like option (XKBOPTIONS=”ctrl:nocaps”) in /etc/default/console-setup.
I stumbled on another bug – apparently related to evdev driver or xorg – the left arrown, down arrow and the ‘end’ key lose their ‘repeat’ capability – Using the work around mentioned here.
Compiz was crashing with :
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string: :_S_construct NULL not valid
Googling indicated someone had gotten past the error by setting the LANG variable – tried it and it worked (LANG=en_US.utf-8 for me.)
Mplayer playback acts funny – every 30 seconds to one minute it apparently realizes it was slow and does a quick ‘catching’ up. No clue on this one yet – VLC also acted in similar manner a couple of times.
My “TyTN II – OpenSync – synce” setup is blown mostly by the python upgrade. This is going to take quite some time to get back.
Roger Murtaugh: I’m too old for this bleep !
The following are the issues (some are still at large):
- acpid: Does not use /proc/acpi/event. Instead uses netlink to get events. So new kernel needs new acpid.
- xargs: There was an old problem with xargs getting huge command lines (was fixed many months ago). I still had the old version.
- RTC vanished: The module rtc-cmos is needed and nodes /dev/rtc -> /dev/rtc0 needed (major = 253).
- Nvidia: Just like previously downloaded the package from nvidia. Should work without problem.
- Keyboard: Okay this needs another paragraph.
Keyboard issues: Ironically I thought of upgrading the kernel to get the “Microsoft Natural® Ergonomic 4000” working with all those special buttons. The pain started like this:
After configuring X display and first run – black screen nothing happens. Well actually there is no crash. Incidentally the black screen was just Nvidia’s idea of a default surface for X (Instead of my favorite X crosshatch pattern). The non-response is due to new X not using hal for some reason to get te mouse and keyboard. HAL is working fine lists all the devices (even the other half of “Microsoft Natural® Ergonomic 4000” with the fancy buttons) – X just does not get it. Currently X is set to use the ‘kbd’ driver and evdev mouse (yeah, funny – hal supposed to suggest ‘evdev’ for both keyboard and mouse).
Getting to use the keyboard in some is a relief after which surfaces minor problems that have crept in. The remapping of CapsLock to Control in console is gone (apparently the sed scrpt /etc/kbd/remap is not working and resulting in some funny symbol like “keycode 58 = CtrlL_Lock”) – Left it at that for now – not much console usage once X is working.
Keyboard issue did not stop. A good one came in. I see that the shell pipe lines I make lose space after the ‘|’ i.e (ls /foo |grep bar). This was due to overlap of ‘Right shift’ while the ‘|’ and space keys are hit – so Shift-Space gives no space. After googling and starting of with info from http:/pascal.tsu.ru/en/xkb/setup.html, ended up in base.lst file. This file describes an option called nbsp:none which when enabled causes any level of modified space key appears as space. I’m sure this has broken something else somwhere – I’ll wait for it.