Xfce Volstatus Icon 0.1.0
Yesterday I released the first version of my Xfce Volstatus Icon. It's a pretty simple little app; all it does is sit quietly (and invisibly) in your system tray until you plug in a removable device (like a USB flash disk or an iPod), and then it turns into a little icon that you can click to easily and safely unmount and/or eject the device so you can physically remove it.
The code for the icon itself is relatively simple; it's all less than 2000 lines of C. Another 2000 lines resides in 'ghal', a library I've written to act as gobject bindings for libhal and libhal-storage. Currently it's not documented at all, and it's not released as a separate library dependency, but included in the xfce4-volstatus-icon source package. I first wrote the libhal bindings for Airconfig, and then extended them for volstatus to include libhal-storage.
The upshot is that you can create a GHalContext object, and connect to gsignals on the object such as device-added and device-removed. You can enumerate devices (GHalDevice objects) on the system via their UDIs. Now ghal also knows about 'special' devices, which are subclasses of GHalDevice: GHalDrive, GHalVolume, and GHalVolumeDisc. The cool thing is that you don't have to know what they are explicitly. ghal_context_device_from_udi() will create the right kind of device and return it to you cast to a GHalDevice; you can use e.g. GHAL_IS_DRIVE() to determine if it's also a GHalDrive, etc. Currently you can use ghal_context_find_device_by_capability() to find devices of particular types if you know the HAL capability strings, but I plan to add convenience API to abstract the capability strings.
I'd also like to add more objects, like GHalComputer (the root computer object), and support for performing actions on particular devices (like mount/unmount for volumes, suspend/hibernate for the power management interfaces, etc.). I'm also debating including some parts of Airconfig in there as well (mainly the interface control stuff), though I'm not yet convinced that that's necessary or useful, especially since it currently relies on a custom HAL addon and method-invocation scripts. At any rate, I think it's pretty useful for people who want to use HAL just like any other glib/gobject-type services, and I'll turn it into a standalone library Real Soon Now[tm].
(Yes, I know about libhal-glib, written by Richard Hughes for gnome-power-manager. However, I don't really like the API that much, and it obviously has a decidedly power-management-slanted focus that I don't need.)
Xfce Volstatus Icon 0.1.0
Yesterday I released the first version of my Xfce Volstatus Icon. It’s a pretty simple little app; all it does is sit quietly (and invisibly) in your system tray until you plug in a removable device (like a USB flash disk or an iPod), and then it turns into a little icon that you can click to easily and safely unmount and/or eject the device so you can physically remove it.
The code for the icon itself is relatively simple; it’s all less than 2000 lines of C. Another 2000 lines resides in ‘ghal’, a library I’ve written to act as gobject bindings for libhal and libhal-storage. Currently it’s not documented at all, and it’s not released as a separate library dependency, but included in the xfce4-volstatus-icon source package. I first wrote the libhal bindings for Airconfig, and then extended them for volstatus to include libhal-storage.
The upshot is that you can create a GHalContext object, and connect to gsignals on the object such as device-added and device-removed. You can enumerate devices (GHalDevice objects) on the system via their UDIs. Now ghal also knows about ’special’ devices, which are subclasses of GHalDevice: GHalDrive, GHalVolume, and GHalVolumeDisc. The cool thing is that you don’t have to know what they are explicitly. ghal_context_device_from_udi() will create the right kind of device and return it to you cast to a GHalDevice; you can use e.g. GHAL_IS_DRIVE() to determine if it’s also a GHalDrive, etc. Currently you can use ghal_context_find_device_by_capability() to find devices of particular types if you know the HAL capability strings, but I plan to add convenience API to abstract the capability strings.
I’d also like to add more objects, like GHalComputer (the root computer object), and support for performing actions on particular devices (like mount/unmount for volumes, suspend/hibernate for the power management interfaces, etc.). I’m also debating including some parts of Airconfig in there as well (mainly the interface control stuff), though I’m not yet convinced that that’s necessary or useful, especially since it currently relies on a custom HAL addon and method-invocation scripts. At any rate, I think it’s pretty useful for people who want to use HAL just like any other glib/gobject-type services, and I’ll turn it into a standalone library Real Soon Now[tm].
(Yes, I know about libhal-glib, written by Richard Hughes for gnome-power-manager. However, I don’t really like the API that much, and it obviously has a decidedly power-management-slanted focus that I don’t need.)
Marihela Xfwm theme
I relooked a little bit the Moheli theme with some ideas that throwed my head.
You can go to my gallery, the last screenshots are the most recents. Pick this one.
Dwarf GTK+ theme for Xfce
I was using the Xfce-stellar theme for quite more than a week now. Today I renewed that theme by using the most recent features from the Xfce GTK+ engine like gradients and borders for menu items.It was an easy hack since both the Xfce-stellar theme and the new default for Xfce are really clean. I mostly changed colors and some other misty stuff. I choosed the name Dwarf, coming from the White Dwarf, since it has a direct relation to Stellar. If you like the next screenshot you can download the theme here: Dwarf.tar.gz.
Edit: I have done some updates while I was travelling by train. There is a gallery with several screenshots and the tarball has been updated too.
Jerry Springer + Congress = Awesome
If US Congress was more like Taiwan's Parliament, I think many more people would be interested in politics.
Stupid Motherboard
Ok, this is retarded. About 2 years ago, I bought a DFI K8M800 MLVF motherboard to act as the foundation for my HTPC/PVR box. This was before I had my 6.1-channel sound system, so at the time, I was ok with the onboard VIA 8237 sound chip, which, without buying an extra connector bracket, would more or less just give me 2 channels.
However, after setting stuff up, I had no sound. I was not pleased. I googled and googled, and found that the ALSA driver for that chipset (snd-via82xx) was a little messy, and sometimes you had to pass special parameters to the driver to get it to work for your particular hardware. I tried a bunch of combinations, but had no luck. Eventually I gave up, and bought a cheap Turtle Beach card. By that time, I'd bought my surround sound system, and wanted something that could do digital S/PDIF out (though this card only does coaxial, not optical, but whatever).
Lately I've been thinking about reducing power usage on the HTPC, with the possible intent of retiring my desktop machine and moving all the data to the HTPC on a RAID array that I'd build and put in an external box using something like eSATA. I'd also need to free up a PCI slot: even though I'm only using 2 of the 3 slots, the 3rd slot is effectively blocked by the large fan on my AGP video card. So, I thought it would be a good idea to try to get the integrated sound working again.
So, I resumed googling, and messing around, and still, no luck. Tonight, I decided to google my specific motherboard. This led me to the ALSA bug tracker, where I put in a broader search query for all bugs related to the via82xx driver where there was no sound. With a little luck, I came across a post that said something about having disabled the rear outputs in favor of the front outputs on their multimedia-oriented case.
This rang a bell.
I dug out my motherboard's manual, and, sure enough, connecting the front in/outs on a case to the appropriate header on the motherboard will disable the rear outputs. Of course, I'd never done this, as I hadn't cared about the front audio jacks. But I thought I'd look anyway. Apparently, two pairs of pins on the header need to be shorted if you don't intend to use the front outputs. Otherwise the rear outputs still get disabled. You'd think that DFI would ship the motherboard with these pins already shorted, since you'd want to get some sound out of the box if you don't go and connect anything to the front outputs. But no, I see the header, plainly sitting there with its pins un-shorted. So, I dig out some jumpers, short the pins, boot the box, load the driver, unmute the mixer channels, and... voila... I have sound.
I can't believe the amount of time I wasted on this, and it turned out to be a hardware problem in the end! I was so afraid that it was a Linux software issue, and it was actually hardware. Sigh.
Time to go order that S/PDIF bracket...
Patented Farts
Those guys over at United Aircraft really take their flatulence seriously.