I just spent some time reading through the recent Why Linux won’t work on the desktop and The Linux desktop of the future stuff. Just works(TM) seems to be the most important point today, and many projects claim to follow that idea. My experience is that most things just work if [long list of conditions skipped].
Playing the devils advocate, I think that things are even worse than before on the Unix/Linux desktop: While some time ago, a lot of stuff was very Linux specific and you had to port it yourself if you happen to run a Unix or a BSD system, today you have to run a specifc Linux distribution (at a specific version) to get a chance to have certain things running. So instead of being Linux specific, which is already not a good thing, stuff is now Linux distro vendor specific. A simple example: Try to get Mono into a usable state on a slightly out-of-date Debian system (yeah, I know, Debian is always a bit behind, but this is really just a bit behind the latest stable release for various reasons): It isn’t trivial. It’s just pain. Waste of time probably.
And there are several other examples. HAL comes to mind here. The initial idea was very good. A platform independent hardware abstraction layer. But in it’s current state you need to run a very specific version of the Linux kernel. No chance to get see this running on anything else in the not so far future (yeah, I know there’s a solaris/osspec.c, but if you look closely, it’s just a dummy).
I remember a time where the vendor-independence was a big plus for the Unix/Linux desktop, and I remember a lot of people complaining about the dependency on Microsoft for the Windows products. Now, it looks like the vendor-dependency is being ported from Windows to Linux.
Sure you could say “The stuff will be ported at a later time”, but let’s be honest, Microsoft could tell exactly the same.
I was very surprise to see that from the big two on the Unix/Linux desktop, KDE is far ahead of GNOME when you use it on a machine that doesn’t run a product made by RedHat or Ximian/Novell. You get nearly 99.99% the same functionality with an old Linux/i386 system, a new Linux/i386 system, a Solaris/sparc and a FreeBSD/i386 machine. That’s pretty amazing and very encouraging. It’s nearly as platform-independent as Xfce. ;-) Although, to be fair, KDE provides a lot more services than Xfce, so you can say, the KDE people did a good job. With recent GNOME releases it’s kinda frustrating, esp. if you just want to check something in Nautilus (e.g. to verify that Thunar will behave similar). For example, I don’t see any removable devices on FreeBSD or on that older Linux machine, although Konqueror displays them. Even the Thunar prototype does that already in the BSD volume manager implementation, and it’s really easy. Even CDE provides better volume management on Solaris than recent GNOME versions. Then the SMB module in GnomeVFS. I have no clue about SMB and CIFS, but even Xffm works way better than GNOME here. GNOME never sees the Windows machines during testing. And there are several other things that don’t just work.
Now I’m not a desktop user. I don’t use a file manager. I mostly interact with applications running inside a terminal emulator. And of course, browser and mail reader. But I wasn’t talking about myself. I was talking about the average user. And the average user won’t be pleased to discover that just works is bound to 100 conditions (atleast if his system does not fullfil 99 of these conditions).
It may look like an advantage to Novell to ship something with their distribution, which doesn’t easily run on other systems as well. But if you look back in time, that wasn’t the way of the world so far. Imagine back in the days before the internet as you know it today, somebody would have come up with: “Hey, here’s TCP/IP and there’s the socket interface, which can be used to connect networks to form the internet. But, ehm, you’ll need to run 4.2BSD to use it. You cannot get it to work on other systems. That’s intentional. Everybody should run our beloved system.” Doesn’t sound like this would have worked, does it?
It’s more than ok if the first public version doesn’t support all the operating systems out there. But it would be good if released software would run equally well on all supported systems. And in the case of GNOME: While the desktop is in reality just the core of C programs, most people also think of 3rd party stuff like Beagle, etc. as GNOME components, and it doesn’t matter if you tell them that it’s not part of the core and thereby not officially supported; they’ll be disappointed to see that only half of their GNOME works.
To conclude (as usual, just my 2 cents, nothing that’s neccesarily true): With the current direction, it is very doubtful that the Unix/Linux desktop can compete with Windows and OSX in the future. That’s even independent of Microsoft and Apple. The problem is that people started to cut off their very own roots.
In reply to Christian’s comment on my last blog entry:
I read the spec right before writing the blog entry, and I basicly followed the discussion on xdg-list earlier.
The spec covers some basics. But from my point of view, the focus of the reference implementation and the spec is wrong.
First of all, your reference implementation is the most important point for now, simply because that’s what people see. You could write a perfect spec, people will always check your reference implementation first. So all oddities (really mainly the odds, not the bugs) will affect the acceptance of the spec. My feeling is that Galago is currently trying to catch people with those nice popup effects seen on other operating systems - but I don’t follow that project very closely, so I may be wrong here. Still it is a problem for your project if developers (and users) see your project as eye-candy only.
Then, back on topic, the filtering issue. You really want to do filtering on the daemon side, because else if the client would filter events, those would never show up in the event log. And besides that, this is the only way to ensure that all the filter information is managed and stored in a single place. But to be able to allow useful and flexible filtering in the daemon, the client must provide as much data as possible. And in order to allow easy configuration, the client must also provide information about the filter tags.
The spec currently provides two tags for filtering: The notification type id and the urgency level (I’d strongly suggest to provide more than 3 levels by default). The application name is pretty useless, as the spec explicitly states that this should be the formal name rather than a unique id. And formal names are not garantied to be unique and may change over time. The notification type id is a single string and thereby not suitable for non-trivial filtering. E.g. I can only say, that I’d interested to know whenever an IM buddy goes online. I cannot say Tell me when Harry goes online (sure, you could use something weird like im.user.harry.online, but that’s really only a work-around for a limitation in the system). Two criterions are simply not enough to perform useful filtering.
Then, the configuration issue: If you want to do filtering in the daemon (and you really want to do this if you plan to support event logging), then there must be a way for clients to tell the daemon about the different filter tags and the default settings, and at best also an interface to allow clients to change the settings easily. I proposed to use a simple XML file here, installed by every client that supports desktop notification, but that was just a suggestion, you could use any other file format. The file name would somehow include the application’s unique id. You would also store thinks like the application icon and the sounds to play for a specific event and such within this file, which allows integration with desktop wide sound themes, etc.
What really bugs me about the spec and the way this is started in GNOME currently is the fact that important issues like filtering get nearly no attention, but instead the focus is on minor details like the appearance (esp. since the spec explicitly states that “applications can generate passive popups”, which somehow makes it less suitable for a general desktop notification spec). I’d welcome if people would focus on the important parts first, and don’t focus too much on details like how to display the messages (and there should be really more than one way to display notifications, atleast something non-disturbing like an icon in the systray).
Note that these are just my 2 cents. I’m not an expert in desktop notification, nor do I have any time or interested to work on the spec or the implementation (well, maybe an implementation for Xfce, once there’s a usable spec, but not this year). So you may disregard my comments silently. But I really strongly recommend to revise the spec, because else I’m pretty sure, this won’t be the standard for a long time.
Edscott, how about using the icon-theme.cache generated by gtk-update-icon-cache instead? There are several advantages: First - and foremost - the cache is shared by all Gtk+ apps and therefore it’s likely that most parts of the cache are already loaded. Second, both the image data and meta-data is contained within the icon cache, and thereby safes you a lot of disk I/O in the common case. And last but not least, there’s already an implementation of the icon cache, namely GtkIconTheme.
Really, I don’t get this. The GNOME guys started the libnotify integration (once again?), which lead to controversial discussion.
I wonder why things have to be that complicated all the time. Why not simply design a desktop notification system based on the ideas used in system notification - namely syslog. Speaking from the flexibility’s point-of-view. You have different, pre-defined levels of importance. And you have various services, like Thunderbird or the battery monitor, that want to present notifications. Now the user can choose based on the level and the service, how to present the notification (e.g. popup notification for events from the battery monitor, and simple, non-disturbing, systray notification for Thunderbird events). All events will be logged and it’s possible for the user to access/clear this log. In addition, you could allow the services to tag their messages using simple strings. For example with an instant messenger, if you’re only interested about online/offline popup notifications about your friend Harry, you’d add a rule to the notification server saying it should display a popup for notifications tagged with "online-state-changed", "Harry". For easier usage, the notification server should allow its connected services to also modify certain settings. So, all the user would need to do is to right-click on Harry’s buddy icon and toggle Tell me when Harry is online/offline.
Of course, sane defaults should be choosen for the different services. Services would need to install an XML (or whatever) file to tell the notification server what they do, which events they provide and whats the default way of notification.
This way you’ll have a very flexible, but yet easy to use system. The average user will probably just stay with the (sane) defaults, while the more advanced users will reconfigure certain aspects. And the logging of the events ensures that you don’t miss events while you’re away.
Does KISS mean nothing in today’s open source world?
Just discovered on the nautilus mailinglist:
Looks familar, eh? The full thread is here.