Category: Uncategorized

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.

In SVN trunk, gnome-power-manager has grown a test suite. Executing “test/gnome-power-self-test –all” executes 100 self tests on some of the key GObjects, testing for things like numerical accuracy, segfaults on error conditions, some parts of the DBUS interface and other useful stuff like that. The output is pretty crude, something like this:

…
> check #19     GpmArray         :      clear array……OK [cleared]
> check #20     GpmArray         :      get cleared size……OK [get size passed]
> check #21     GpmArray         :      save to disk……OK [saved to disk]
> check #22     GpmArray         :      load from disk……OK [loaded from disk]
> check #23     GpmArray         :      get file appended size……OK [get size passed]
> check #24     GpmArray         :      interpolate data……OK [interpolated]
> check #25     GpmArray         :      limit x size……OK [limited size X]
> check #26     GpmArray         :      limit x width……OK [limited width X]
> check #27     GpmArray         :      test copy……OK [copied]
> check #28     GpmArray         :      uniform weighted average……OK [averaged okay]
> check #29     GpmArray         :      integration down……OK [integrated okay]
…
> test passes (100/100) : ALL OKAY
…

It lets me continually add features, hopefully without regressing. If I process a crasher bug in bugzilla that could have been tested for and prevented, I add it to the self test program so that any refactoring in the future does not re-introduce the bug.
This found even the simplest functions of gnome-power-manager were suffering from bugs really hard to pin-point in real world use. I'm also adding more and more tests everyday to the test program as some of the nastier bits of g-p-m (GpmPower, GpmBattery) get refactored into nice clean GObjects.
Hopefully this refactoring and restructuring of g-p-m will allow me to just slot in the profile code, and everything will “just work”, with less memory and less complexity. Let's wait and see.. :-)

GNOME Power Manager supports merging multiple laptop batteries into one virtual battery for the time remaining calculation and also the status area icon. Unfortunately my new statistical driven approach breaks with primary batteries being removed and inserted, as we'll need some sort of profiles for “one battery” or “one battery plus extra battery” just to make the new code work. Unfortunately, my Lenovo only has the one battery, with no option to extend it. Now, long shot: Does anybody have an old laptop that they do not want that they could send to me? It would need to have two batteries expressed in ACPI (with at least 10 minutes of charge in both), with the ability to remove one at run-time. It doesn't matter if the machine is 400MHz with a smashed screen, any old test machine would be great. If I get my hands on a multi-battery laptop, then the new profile code work will work really well with two batteries. Sorry if this sounds cheeky, but it's really hard to code for a situation you can't test for.

The new profile code in gnome-power-manager allows us to calculate the amount of time the battery has until charged, and also the amount of discharge time you would have if you disconnected the ac adapter now.

Is this useful to expose to the user? If so how? What about a tooltip “Laptop battery 48 minutes remaining until charged (64%), currently provides 1 hour 45 minutes discharge time“. I really suck at UI wording, so better ideas please.