Technical Blog of Richard Hughes

I've had to disable anonymous comments on this blog, the number of spam postings is getting too much. Sorry.

Gahh. My car engine stopped half way from my girlfriends to my grandparents. I coasted about 40 meters until I could pull over, and then checked the usual: oil, diesel, water and fuses. I guessed it was some sort of fuel issue, either a blocked filter, blocked injectors or broken fuel pump. Without tools, it was difficult to debug, so I called out the AA. The bloke confirmed it was probably a fuel pump problem but couldn't fix the problem there and there. I'm stuck in the middle of nowhere with a broken car. 85 quid later and I get towed home.

Long shot: Anybody ever fitted a new fuel pump in a 1.7 litre turbo diesel 2002 Vauxhaul Corsa?

Is there any way I can still use gcc and make, but print:

[ok] gpm-backlight.o
[ok] gpm-tray-icon.o
[ok] gnome-power-manager

rather than the pages of incomprehensible gibberish:

gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include   -pthread -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -DDBUS_VERSION_MAJOR=1 -DDBUS_VERSION_MINOR=0 -DDBUS_VERSION_MICRO=2 -DORBIT2=1 -pthread -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/libpng12 -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/libwnck-1.0 -I/usr/include/panel-2.0   -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libpng12   -I/usr/include/gtkunique-1.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12   -DBINDIR=\”/home/hughsie/Code/gnome-power-manager/trunk/gnome-power-manager-2.19.1/_inst/bin\” -DGNOMELOCALEDIR=\””/home/hughsie/Code/gnome-power-manager/trunk/gnome-power-manager-2.19.1/_inst/share/locale”\” -DDATADIR=\”/home/hughsie/Code/gnome-power-manager/trunk/gnome-power-manager-2.19.1/_inst/share\” -DPREFIX=\””/home/hughsie/Code/gnome-power-manager/trunk/gnome-power-manager-2.19.1/_inst”\” -DSYSCONFDIR=\””/home/hughsie/Code/gnome-power-manager/trunk/gnome-power-manager-2.19.1/_inst/etc”\” -DLIBDIR=\””/home/hughsie/Code/gnome-power-manager/trunk/gnome-power-manager-2.19.1/_inst/lib”\” -DVERSION=”\”2.19.1\”” -DGPM_DATA=\””/home/hughsie/Code/gnome-power-manager/trunk/gnome-power-manager-2.19.1/_inst/share/gnome-power-manager/”\” -I../.. -I../../libhal-glib -I../../libgpm-glib -I../../libdbus-glib   -Werror -Wall -Wcast-align -Wno-uninitialized -g -fexceptions  -g -O2 -MT gpm-prefs.o -MD -MP -MF .deps/gpm-prefs.Tpo -c -o gpm-prefs.o ../../src/gpm-prefs.c

I have a feeling there's a random patch floating around, but I wondered if there was anything upstream. Cheers!

Everybody who has reviewed and commented on the power-management specification – THANKS.
I've got a pre-release here which will become version 0.1 assuming nobody finds any glaring errors.

One thing that bothers me is that I can't seem to attach a DBUS path more than once, i.e. just change the interface rather than the interface and the path. I'm pretty sure this is a limitation of the glib bindings of DBUS, which may mean the paths will have to be scoped (/org/freedesktop/PowerManagement/Inhibit) for the spec as well as the interfaces. Urh.

I've also got a crack-infested version of the spec with all the crazy stuff put back in, like Inhibit and Statistics and that sort of thing. I've uploaded a copy here and would appreciate some initial feedback before I pester the XDG list again.

Cheers!

I've proposed the org.freedesktop.PowerManagement specification on XDG list a few days ago, and the feedback has been generally very good. I've renamed a few things, cut some stuff out and generally tried to make it as cross desktop as possible.

I've put the first version here for comments. This is NOT the 0.1 version, this is a pre-release sample.

The statistics, inhibit and UI interfaces that are already being used in g-p-m – please ignore for now. I want to get the base stuff standardized and then we can discuss new optional interfaces for any new functionality.

One thing I'm not sure about: Reboot vs. Restart. I favour the latter, but I'm not sure which is best. My spelling and grammar are also pretty rubbish, so I would appreciate some help on that as well.

Comments or flames, directed as usual to the blog. Thanks!

I got a comment mentioning it was a bad idea to lock the GNOME keyring on suspend and hibernate.

In 2-18 there was code added to unconditionally lock the keyring when we sleep, for security. This has the unfortunate side-effect of NetworkManager asking you for your WEP password when you resume (and probably disconnecting any network shares mounted over gnome-vfs).
I'm going to add a gconf variable in trunk, and possibly a configure option for 2-18 (as I agree it's annoying), but what should the default be? Is there any possible attack vector for not locking gnome-keyring?
Should this be in the UI? Users shouldn't really be touching gconf-editor…

Thanks for any help.

Okay, it appears my last blog post provoked a large reaction. I think the conclusion was that the libnotify notification was indeed crack-tastic, and that we should probably add this information to the tooltip, or just try and 'Do The Right Thing'.

For the moment, I've added a small “Battery charge profile is estimated” to the tooltip, but I'll try to fallback to the rate calculation time remaining, although that might mean dealing with all the duff data that comes with that. Cheer for all the feedback.

You normally run your laptop with one battery.  Then, for the first time since you installed Linux, you insert the second battery.
The discharge and charge profiles of the new combined battery have to be created from scratch, as we can't just use the single battery profile as it's no longer valid. This means your super-accurate profiled time-to-discharge reading gets reset to the default 2 hours until enough discharge and charge data has been automatically collected.

So, what about the following warning dialog? Flames / suggestions as comments please.

p.s. I still can't test the multi-battery code, I'm still looking for donors.

g-p-m now knows how long your battery will typically last when it is discharging, even when fully charged and providing no rate information.

Is it sanity, or insanity to have in the tooltip:

Laptop battery fully charged.
Typically provides about 2 hours 20 minutes of discharge time.

Please direct positive feedback or flames to the comments on the blog. Thanks!

This is the very first ChangeLog comment.

2005-03-21  Richard Hughes  <richard@hughsie.com>

    * Initial release of 0.0.2

I wanted to say a huge thanks to all the people who have helped me, taught me, encouraged me and most of all the people that filed bugs, sent patches and code. This time two years ago I knew nothing about developing a GNOME application. Cheers.