Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

A flying office with incredible views

There's a Lufthansa ad on page 37 of this week's Economist advertising their new in-flight broadband service. The person in the picture seems to be running GNOME on his iBook. (It's a bit blurry.) Way to go!

posted Thu 16 Jun 2005 in /software/gnome | link

Metacity "reduced resources" mode

% gconftool-2 -t bool -s /apps/metacity/general/reduced_resources true
% metacity-message restart

This turns off opaque resize/move, animations and so on. My 3-year-old work machine has an expensive-but-useless graphics card that is only fast when used with proprietary drivers. Since I only display Firefox, rxvt and emacs it's not worth the hassle to install them. This gives a nice speedup.

posted Thu 16 Dec 2004 in /software/gnome | link

The computer for the rest of us...

GNOME is getting to a really delightful level of elegance, of which Muine is just the latest installment.

Having used Stephane's mac a little bit, I wish Metacity had a "hide other windows" command, even if it was off by default. I know the whole point of it is not to add too many features, so maybe it'll never get in.

posted Mon 1 Nov 2004 in /software/gnome | link

CPU indicator light for GNOME

I wrote a little GNOME applet to show when the CPU is busy.

Certainly there are at least dozens of different system load indicators, but I don't really like the existing ones, for two usability reasons.

Many load indicators give you a graph showing historical load. The GNOME multiload applet is an example of this. That's fine, but I don't care very much about how busy the machine was in the past. What I mostly want to know is whether it's busy at the moment. That's useful in giving a feeling for the machine: is something unexpected happening? Has your compile finished yet?

In the current GNOME load applet (shown above), the current state of the CPU, which is the most important information, is confined to a one-pixel bar over on the right hand side. In fact, it's not even that, since the bar is only updated every ten seconds or so.

The other approach is something like gkrellm, which shows flcikering indicators of instantaneous load, as well as a graph. But I find it too distracting; load is something you want a background awareness of. It shouldn't be so intrusive as to have moving object in your field of view.

Hardware indicates what I feel is a good interface to do this: it makes a little bit of quiet noise, or lights up a small LED depending on state. Furthermore the LED is in your peripheral vision so you can be aware of it without actually looking at it. You can be easily aware of when your drive is busy and therefore get some idea of what the computer's doing without needing a massive moaning goat on your desktop.

What I would really like is a hardware CPU busy LED on my machines. Failing that, we can fake it in software:

This is meant to look like a hardware LED: when the CPU is idle, it's black. When the CPU is flat out, it lights up brightly, in between it is proportionally bright. It responds fairly promptly to changes in actual load, unlike things based on loadavg or that only update every ten seconds. I don't use loadaverage because it's not well suited to modern machines; instead this is the fraction of idle time in the last 0.5 second.

There's a little bit of hysteresis to make it look less flickery and more analog.

I think brightness is probably a better display than say a bar graph. It doesn't cause a visual sensation of motion unless it suddenly switches on or off, which is the most important event. Brightness is only qualitative, not quantitative, but that's highly appropriate for this.

I've been running it for a few days and I like it. You can see out of the corner of your eyes when a compile finishes or when a cron job starts up.

The implementation needs to read /proc/stat (via libgtop) every second, which is a bit unfortunate. It would be nice if it didn't need to wake up so often, but I think the impact is not necessarily much worse than showing a blinking cursor. It doesn't repaint unless the load changed significantly.

This was my first GNOME applet. It turns out to be pretty easy to write, except that the bonobo server registration stuff is just slightly hard to work out. Basically you need to copy the .server file into /usr/lib/bonobo/servers before the applet can get onto the panel at all. In GNOME 1.4 just running the program would make it pop up on some panel.

Probably the worst part of writing this is all the automake voodoo required to link against GNOME; that's deeply unfortunate. I think the only way to get it right is to copy and paste from existing code, and I hate to think how novice programmers would work out some of the automake error messages. I'd like to write predefined SCons builders so you could just say GnomeApplet('blink_applet', 'blink.c') and have it work.

Once it is there you can update the program by just killing the old task. The panel then asks if you want to restart it; if you say yes there then it runs the new version.

Get it and let me know what you think.

You can also get a more recent copy using darcs get http://sourcefrog.net/darcs/blink-applet/

posted Wed 28 Jul 2004 in /software/gnome | link

GNOME file selector broken

On upgrading to GNOME 2.6 you may find you have a pretty new file selector dialog. Sadly, it is missing a text entry field! There is no way to quickly navigate using the keyboard, and it's lost the beautiful Tab-ding feature.

In fact, it is still there, but it's bizarrely hidden. Press Ctrl+L to bring up a text field.

GNOME bug 136541

gtk-list thread about this

posted Fri 2 Jul 2004 in /software/gnome | link

GNOME: Java, Mono, or C++?

Havoc writes on the issue of a high-level application language for GNOME.

In the Linux desktop world, there's widespread sentiment that high-level language technologies such as garbage collection, sandboxed code, and so forth would be valuable to have and represent an improvement over C/C++. [...]

To me the way to create something that most of the community can swallow is to stick strictly to open source, unencumbered technologies. This means there's a level playing field; anyone can hire developers to contribute to the technologies, anyone can fork if they have to. It's essential that our high-level language technology have no single owner with irrevocable control.

Open source creates this level playing field, and that's why it historically works as a way for diverse companies and individuals to collaborate on software projects. Without the level playing field, everyone gets too paranoid and fragmentation or stagnation are inevitable. [...] Aside from IP issues, Microsoft controls the .NET platform. They will always be ahead, and it will always be tuned for Windows. This is the wrong direction for free software, if we want to win the war, and not only some battles.

Even if we use some unencumbered ideas or designs from the .NET world, we should never define our open source managed runtime as a .NET clone.

I think he's right that Python, Perl and Ruby are not it. They're great for particular applications but I wouldn't want to write an office suite in them. On the other hand, if neither C# or Java work out for licensing reasons, Python might be a good pick.

Rick Kitts is not convinced, but I think he's being too pessimistic.

You can often see open source projects having design arguments, personal fights, making mistakes or changing their mind in public. It's easy to conclude from this that they're really schizophrenic or hostile. I don't think they are. Similar discussions occur inside companies. The only big difference is that open source projects do it in public.

In particular, Microsoft probably had a similar discussion paper before deciding on their strategy for C#. Indeed, you can see them doing this sort of thing in the Halloween papers.

GNOME have pretty consistently been able to have a dicussion, make a decision and move on. I think they will be fine here.

posted Thu 18 Mar 2004 in /software/gnome | link

gtk_widget_hide_on_delete

To make a GNOME modeless dialog just hide when its frame Close button is clicked, connect delete_event to gtk_widget_hide_on_delete. The default is to destroy the widget, which can be inconvenient if, for example, it was constructed by Glade and you don't want to rebuild it when the user wants to see it again.

posted Mon 22 Sep 2003 in /software/gnome | link

GTK+/GNOME Application Development

Havoc Pennington's book GTK+/GNOME Application Development is now online. It's a good introduction to the interface and covers a lot of the tricks that are not obvious from the API documentation.

posted Wed 10 Sep 2003 in /software/gnome | link

LWN coverage

Just after I wrote, I realized that Linux Weekly News also has an article about Conglomerate, which is more detailed. An LWN subscription is excellent value.

posted Fri 5 Sep 2003 in /software/gnome/conglomerate | link

Conglomerate

Alexander pointed out Conglomerate, a very promising GNOME XML structured document editor. The screenshot speaks for itself here:

posted Fri 5 Sep 2003 in /software/gnome/conglomerate | link

Glade and Python

Python and Glade is quite a neat little rapid development tool. In about five minutes, without using it very much before, I could write a tiny but handy GUI utility to tweak X11 monitor settings:

#!/usr/bin/env python
import sys, os
import pygtk
pygtk.require('2.0')
import gtk
import gtk.glade

fname = 'gammaknob.glade'
xml = gtk.glade.XML(fname)

def gtk_main_quit(*args):
    gtk.main_quit()

def on_gamma_scale_value_changed(gamma_scale):
    os.system("xgamma -gamma %f" % gamma_scale.get_value())

xml.signal_autoconnect(locals())

gtk.main()

It still has that Linuxy loosely-coupled feeling: you can't (?) edit Python source directly inside Glade, and you have to copy in a tiny bit of boilerplate to get it going. That's not necessarily a problem; keeping it separate has some advantages.

One very cool thing is that because the user interface description is cleanly separated from the code you can run the exact same XML file with either a Python, C, or other language implementation. So a mockup in Python can directly transform into a release in C. (Although for many things just sticking with Python might be OK.)

posted Thu 17 Jul 2003 in /software/gnome | link

Evolution mockups

Evolution mockup

posted Wed 16 Jul 2003 in /software/gnome | link

Copyright (C) 1999-2007 Martin Pool.