Category: Uncategorized

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.

I'm looking for a new RSS reader. I've been using liferea for years, but recently it's picked up a new feature; It now displays the number of unread items in the 22x22px tray icon:

From what I can get from the authors blog it was implemented because it was cool, and to copy Akregator.
I've emailed the liferea development list saying that I can't read the numbers on the icon, theming is now broken, and that transparency in the panel no longer works.
I've got very unfriendly responses back, basically boiling down to the fact that it works okay on GNOME 2.14.3, and that the author does not intend to support people with visual impairments, or people that want their gnome panel to look sexy.
Now, I know I'm often pretty blunt sometimes, but I really feel like I shouldn't have bothered and just switched readers given the response.
Anybody got any good ideas for a GNOME RSS reader?

Alexander Larsson has put together the xdg-user-dirs stuff, and caused a riot in the process. It's stable code, integrated in rawhide, and seems to be working well. He's managed to do something that we've been arguing about for years, in a cross desktop way, and in a way that is truly configurable for some of the power users that can't change habits.
It's not specifically deciding on common directories for stuff that's making Linux more suitable for the masses, but it is sure a step in the right direction. So Alexander, Matthias and whoever: Thanks, and keep up the good work.