Category: GNOME

Testing GNOME session new services framework

To make it easier for people to test the new service framework in gnome-session, here are some instructions to help them.

  1. Get and install libgnomeservice from CVS.
  2. Apply the dbus*.patch files in libgnomeservice to D-BUS HEAD.
  3. Compile gnome-session, with this patch and with –enable-services argument for autogen.sh/configure.
  4. Test this, and check the session is started correctly. If not, report bugs to me, please.
  5. Then, it’s time to add additional services. You can either apply one of the patches in libgnomeservice (*.patch) to the corresponding modules. I suggest just testing with something like beagle, or gnome-screensaver’s patches. Those are not session managed, and should be started correctly on session startup but not saved to the session. The other patches (panel, nautilus, etc) make services be started twice, so that part is better left out for now.
  6. You can also add additional services, by just putting a .desktop-service file (here‘s an example) to $(datadir)/gnome/desktop-services, and a .service file (example) to $(datadir)/dbus-1/services. For the .service file, the command line should be like:

    gnome-service-launch org.gnome.MyService /full/path/to/command_to_execute_as_service

With this, the new framework can be tested perfectly.

Notifications

After all the comments in my last blog entry and some other comments, here are my thoughts:

  • notifications in dialogs, like the ones in gaim, are disturbing, and sometimes makes user lose them (if you are typing and looking at the keyboard, and press SPACE/ENTER/whatever)
  • notifications in panel (either notification area or a bubble on an icon) are, at least from my experience, always missed. I used to have the alarm daemon in Evolution set up to use the tray icon instead of dialogs, and after a few days missing *all* my appointments, I switched back to disruptive dialogs, which at least are more difficult to lose (unless you are typing)
  • libnotify implementation makes it difficult to not see the notification, but doesn’t interrupt your current task

So, my conclusion is that libnotify is the best way I’ve seen so far for notifications. Of course, as with the trash applet thingy, we need to make sure we don’t abuse them, and only use them for real notifications, not for every status change.

The GUI in the notification-daemon might need some tweaks, specially if we want it to look like all those mockups we saw some time ago, but that’s all I can think of against libnotify.

libnotify in GNOME Applets

I’ve been playing this weekend with libnotify, and, before taking the task of changing the Evolution’s alarm daemon to use it, I’ve made some applets in GNOME Applets use it for some nice notifications.

First, the weather applet, which displays a notification whenever it gets an update from the weather forecast service:

Then, the trash applet, which does the same when there are files deleted/added from/to the trash.

These notifications expire a few seconds after they are shown, so they should not disturb the user at all.

GNOME Session desktop services

In the last couple of weeks I have been working on completing the work started by the Red Hat guys on libgnomeservice. This is a system for system wide services installation and startup, so that admins can add services to be started for all users. It is also used to start the standard GNOME desktop services, like Nautilus, the panel, etc.

To test it, you need to get libgnomeservice from CVS, compile and install it, and apply all the *.patch patches to the corresponding CVS module. Then, to install additional services, you just need to put a *.service file in $datadir/dbus-1/services and a .desktop-service file in $datadir/gnome/desktop-services. There are two ways to install services. First one, the easiest one, is to use the gnome-service-launch program, which starts another process, wrapping the libgnomeservice API for that process. The second one, not yet used on any CVS module, is to use libgnomeservice API in the service. This is, of course, the best solution long term, since it would allow services, like Nautilus, to provide extra methods, and thus allow other applications to call those methods on the desktop service.

There are a couple of things missing, which I’m looking at at the moment. First is the D-BUS patch, which hasn’t been accepted upstream yet because of the test program failing, while for gnome-session, things are working pretty well. The second one, is a crash on gnome-session when you close the session, which needs to be fixed before anything of this goes to CVS.

Let’s hope this can be included for 2.12, so please, send your comments/suggestions/patches/etc

Desktop platform

As Philip says, the desktop platform for 3rd parties is not as attractive as it should be, given the fragmentation on two big, and incompatible for the most part, development platforms.

And it sucks that politics are involved, since that’s the only reason I can think of about glib, for instance, not being used in DBus, adding the need to copy/paste code from glib to DBus code or rewrite already existing/well tested code. This introduces the need to be updating the code in DBus whenever a bug is fixed in the GLib one, and, most important, fails short in the code reuse philosophy free software is supposed to promote.

Of course, this is just a small detail compared to Philip’s cool integration ideas, but I think a good common platform could help in solving all those integration problems.

So yeah, please let’s have some form of committe or something that approaches a similar KDE people committe to try to promote more the code reuse between the 2 desktops, trying to share as much of the platform as possible. Then, once the basics are shared, we’ll just have two different ways of writing desktop applications, just like there are several different ways on Windows (Delphi, VB, C API, Java, etc).

GUADEC 2006 in Barcelona

Seems it’s finally been decided that GUADEC will be held in Barcelona, a very nice city in the Northeast of Spain.

This means that next year, we’ll have two big GNOME events in Spain, this GUADEC in Barcelona, and the III GUADEC-ES in Las Palmas (not 100% confirmed yet, but probable). We have been talking about moving the GUADEC-ES to another time in the year, so maybe, instead of doing it a few weeks before the big GUADEC, it might get moved to September or around it.

In any case, good news for Spanish GNOMErs.

Scheduled jobs

Since I moved from the Evolution team to the desktop team at Novell, I have been looking at the desktop in a different way than before, looking for missing stuff, cool things that could be added, etc. The things that I miss the most, as a power user, is the access to many of the UNIX tools/commands from the desktop in an easy way. It makes a lot of sense to not complicate the interfaces much, but it also makes a lot of sense, at least IMO, to provide an easy access to the powerful stuff we have in UNIX systems.

So, since this weekend I had no plans at all (apart from some beers on Friday), I started hacking on one of those missing/cool things, which is a simple frontend to the crontab command. I didn’t finish it, but since it’s an easy task, I think I’ve done most of the stuff, missing only the dialog for adding/editing crontab jobs.

That missing dialog needs a bit of thought, since just providing a frontend to the crontab file format might be a bit overwhelming for most users. What I have done so far is this:

Next to the “On specific week/month days” labels, I was thinking on having a way to select any number of days to run the job at. The same for hour/minute, but I’m really short on ideas on how to make it simple but able to edit any kind of crontab entry.

GTK+ Cairo

So went ahead yesterday and compiled 2.11 with jhbuild. Everything worked great (didn’t do any performance review) when opening a “normal” X session. But, when using Xnest, this is the result:

Not sure if it’s Cairo’s or GTK’s fault, or anything else’s, but it looks quite bad.

On the good news front, I have to say I didn’t feel it being much slower than 2.6. Of course, as I said, I didn’t do any performance tests, but still, doing normal desktop tasks, I didn’t see it perform too bad compared to 2.6 (which is not slow and unresponsive, despite what Eugenia might say). To show a little example, here is the color selector dialog with no Cairo:

And the one with Cairo:

Which one looks better?