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.
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:
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.
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).
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:
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:
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.
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.
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.
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).