Rodrigo Moya

We all know now about Nautilus Actions, and I think people agreed, while discussing its inclusion in 2.14, on having this much better integrated into Nautilus itself. And, you know, I am in a quest to provide UNIX power to all kinds of users So, I’ve been wondering for a few days about some ideas, which can be summarised in a mix of nautilus-actions, Automator and, of course, Nautilus.

What I’m thinking is about the Scripts menu in Nautilus context menu to provide better tools to write scripts. One, the simplest, is to create scripts directly (by allowing the user to enter a command or a full script in any language), and allowing the user the kind of tweaks nautilus-actions offers, like specifiying for which files/protocols to show the script in the menu. The other is to provide a mechanism for writing scripts like what Automator does.

In Automator, there are ‘actions’, which are just calls to AppleScript/Automator modules (and which could be calls to D-BUS services and normal commands in our case), and then there are ‘workflows’, which are combinations of actions in a specific order and with specific input parameters/sources. In our case, a XML file describing all the actions and their relationships, and an accompanying command-line tool to run those files through, could be enough for users to write scripts without even knowing a thing about programming. Experienced users could also define more actions, by just specifying commands to be run. And applications could provide even more actions, via D-BUS.

As you can see, my ideas are not still very clear, so would appreciate any opinion on how this could be done, or if it should be done at all.

Yeah, I know, I don’t blog for weeks, and now, suddenly, 3 posts in a row, but this is important, really
Our friends from the Universidad de Manizales, in Colombia, have just announced their GERvoice project, a voice recognition software used to give orders to the desktop through voice commands.

After some great advise from Michael, I’ve committed 2 changes that improve a little bit more the GNOME startup time. This, with the previous changes (to gnome-settings-daemon to lazy load not critical services, like screensaver and typing break and use a single GConf client instead of calling gconf_client_get_default repeatedly), along with the GConf improvements recently announced, login time for CVS HEAD is, for me:

• Cold startup: 14-18 seconds
• Warm startup: 5-7 seconds

My “benchmark” is very basic (chronometer), so if anyone could benchmark it better, I’d appreciate it.

I am in the process of installing many distros on a single machine, and would like to have all of them available at all times (ie, no need to reboot to switch to another one). So, I’ve heard about PXES, which, if I understood correctly, should allow to do that.

Anyone with experience on this able to give some advise?

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.

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.

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.

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.

Murray, not 100% sure of this, but I think PXES does solve the problem of seeing the local drives in the thin client computer.

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.