Memos, notes

Harish: I guess it would be much better than exporting from Tomboy to E-D-S, to make Tomboy use the E-D-S API, and thus share all the notes.

Even more, the sticky notes applet should be using also E-D-S.

Back from Boston

Got yesterday back from Boston, after 8 days there, first on a Novell’s desktop team meeting, and then, for the summit.

It was a great week, first because of the high productivity achieved during the desktop team meeting. It really makes a difference to have all your coworkers near and discuss about what everyone is doing. I would really like to have the Boston office closer to where I live, so that I could go many days to work there. Unfortunately, teletransportation hasn’t been invented yet 🙁

Then, the summit was also great. In the last few months, I have come to the conclusion that I don’t like conferences as I used to, but on the other hand, I love more and more this kind of meetings, where all interested people get together for sharing ideas, discussions and hacking. As Luis says, it would be really nice to do some more specialized meetings for getting groups of people to work on something for a weekend.

As for the interesting things about the summit, here are some:

  • People seem to be worried about performance, so expect lots of improvements in this front for the next few weeks. Let’s hope we succeed in creating some sort of GNOME Performance Team, to continously run tests on applications and libraries.
  • Mark committed his new session manager during the summit. It is a complete rewrite of gnome-session, using the services vs applications separation mechanism we talked about in the gnome-session BOF. As discussed during that BOF, it is missing XSMP support, which we should be adding soon. Some other details, like playing login sounds, are also missing.

    One other nice thing about it is that it already includes all the infrastructure to autostart services/applications, so we should not need anymore to hard-code programs to be started on the session.

    I will be testing it in the following few days, but so far the code looked quite better than the old one, much cleaner and much easier to read. Not sure what people will think about a rewrite though.

  • John showed us (Christian and myself) his rewrite of libnotify. While I like the new API (much more GObject-oriented and cleaner to use than the old one), I still prefer the visual style of the original version from Christian. Hopefully the code will be in GNOME CVS soon, so that we can have everyone’s opinions before going further, as to avoid having disagreements when the code lands on some core GNOME module.
  • Lots of Novell projects were announced: BetterDesktop, Tango icon theme, Banshee.
  • As a result of my recent work in trying to improve GNOME startup time, I applied, along with Rodney and Chris Lahey, for maintainership of gnome-control-center. This means I will continue working on my patches for improving gnome-settings-daemon in the next few weeks, to make startup in 2.14 much quicker.
  • Federico is a great guide for restaurants in Boston. If you are in Boston, just follow him at dinner time, you will get great food. He took us once to an Ethiopian restaurant, which was just delicious, and other day, to a nice, smallish, very mediterranean-like, Italian restaurant, where we had another great dinner.

As always, the best thing on these meetings was to meet again all the nice guys, apart from meeting new ones. I won’t try to mention everyone, since I’ll probably forget someone, but I can’t resist mentioning how happy I was to see again, after more than 3 years, Duncan. Although I just saw him for a few minutes on Sunday, it was very nice to see him again.

GNOME startup speed

I have been for a couple of days now looking at improving the startup speed of GNOME, and this is what I’ve found so far (patches not included).

  • gnome-session does a DNS check on the hostname, not sure why. I removed that and things seem to work as before.
  • Some programs in gnome-session are being started with g_spawn_sync. I changed some of them to be g_spawn_async.
  • esd is started twice, once in gnome-session and once in gnome-settings-daemon
  • Screensaver and typing break are not essential services for the startup, so I’ve changed gnome-settings-daemon to start those 2 processes on idle callbacks, so that they are started when everything else is running
  • xrdb is run 3 times in gnome-settings-daemon!

With these changes I’ve gone from starting the session in 12/15 seconds to 4/6 (I even got sometimes that ‘your session has lasted less than 10 seconds’ error after loging out immediately), and, I think, there is a lot of room for improvement still.

Not sending patches yet, since the changes I’ve made are quite ugly so far (commented out code, #ifdef’s, etc), but will be as soon as I get them sorted out.

Update: hadn’t really read Lorenzo’s analysis before, so I guess all the things he points out make much more room for improvement.

Also, bad news is that on the first login, things are quite slower (15/20 seconds), but I guess this could be easily improved by preloading libraries and programs.

Hacking bits

Some stuff I’ve been working on recently:

  • Hints were added to the notification spec, and now it’s possible to display notifications at a given position in the screen. So I changed the weather applet to use it:

    The battery applet had been already changed, so now the notifications look much better.
  • Added an option to gnome-screensaver-preferences to enable/disable locking.
  • Ported gnome-passwd patch from NLD to openSuSE. This includes a small applet to replace the kdepassword thing that we were using in previous versions.
  • I have been receiving some feedback about my entry about bringing more UNIX power to the desktop. Specially interesting is Nautilus actions, a tool that allows the addition of custom entries to the Nautilus popup menus. I think integrating this with the scripting feature in Nautilus could be a very a good idea, allowing users to easily create their scripts/custom menu items. As I get feedback, I’m adding things to the wiki, so please, if you’ve got something to add, add it there.

Also, very happy to see cairo 1.0 out. Now, I hope, we will start using it to make the desktop a pleasure to look at.


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.

KDE and Wikimedia

The KDE project has started some collaboration with Wikimedia to provide KDE applications with a remote API for accessing Wikimedia databases. Nice ideas have been proposed here.

Since the API seems to going to be desktop-neutral, I guess we need to pay attention to start using it in GNOME as soon as it is available. gnome-dictionary could use Wkimedia sites as its sources, Beagle could search in Wikimedia articles, Totem/Rhythmbox could display information on tracks/artists/albums as they play music/video, text editors could allow importing of those articles, etc, 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).