Linux Desktop

New libnotify, notification-daemon and notify-python releases

I’m very tired, so I’ll keep this brief.

I just put out libnotify 0.4.0, notification-daemon 0.3.5, and notify-python 0.1.0 releases. Most of the really annoying bugs people have reported have been fixed. More information is available on the news post.

I made a decision that will be unpopular to some, and I expect some disagreement on it. notification-daemon 0.3.5 does not ship with the Bubble theme. A large number of the problems people have reported to me on IRC and in e-mail centered around this theme, and until I have the time to give it the attention it needs, I’m removing it from the default install. It’s still in SVN and the tarball, and development will resume on it at a later date. However, I want to give people the best out-of-the-box experience as possible, and the Bubble theme currently makes that hard. If people want to chip in and help, you’re more than welcome.

Aside from that, it’s a very good release and I highly recommend people update. As always, please make sure to report bugs.

I have a couple of neat things I plan to work on. One is a little event notifier for scheduled events on online calendars (30Boxes.com to start). This will be using the new libnotify Python bindings. If it proves useful, I hope to add Google Calendar support as well. I’ll make some sort of announcement once I get a prototype working.

Alpha channels and release schedules

  • GTK+ and semi-transparent windows

    Mike Hearn wrote a blog entry on writing GTK+ applications that provide semi-transparent Cairo-rendered windows. He suggests a SexyWindow class for libsexy, which actually fits in with some of my plans nicely. More on this… someday.

  • Galago 0.5.0.. Almost

    Galago 0.5.0 is about to be released. I’ve said this for a while, but it’s actually happening now. The only thing left is to get the GalagoGtk# bindings out, but I’ve ran into a problem… I want to call the namespace Galago.Gtk, but then the GAPI-generated code tries to use Gtk.Widget and such, which causes a lookup in Galago.Gtk. I don’t know how to fix this, and may have to go back to the GalagoGtk namespace. Any suggestions?

  • Thanks Federico

    I’m somewhat borrowing Federico’s blog entry format on a trial basis for some posts. I’ve grown to like it. Helps to stay organized without being too verbose.

Taggable Desktop


Luis: You wanted a taggable desktop? Oh, okay.

Announcing Leaftag, our desktop tagging framework. This is an evolution of the original prototype we created, originally named fstaglib (isn’t leaftag just so much better?).

The main part of Leaftag is a library called (oddly enough) libleaftag, which interfaces with the tag database. It’s GObject-based, and the API is quite small. It can tag anything with a URI.

There’s tagutils, a small app used for working with tags and files. It is able to tag and untag files, list all known tags, list all files with a specified tag, and manipulate tag properties (such as icons and descriptions). It also includes some symlinks that provide shortcuts to common tagutils functions (tag, untag, tagls, tags, and tagprop).

leaftag-python contains Python bindings for libleaftag. It simplifies the already simple libleaftag library.

And then there’s leaftag-gnome, which will contain all future GNOME support for tagging. Currently, it supports only a Deskbar handler. Future releases will hopefully include Nautilus search integration and property pages.

Now, it’s important to point out that the screenshots on my previous blog entry are of the old implementation, and have not been ported over to Leaftag yet. This is largely due to lack of time as of late (because of Galago and VMware Server work, on my part), but it’s also because we want to re-implement this correctly. In the meantime, we’re hoping additional apps will start supporting this.

This is the first public release of the Leaftag framework, so please report any bugs to us. In time, after a server migration, I plan to put together a dedicated Leaftag site and bug tracker.

Are we assuming users are really dumb?

Update: This is a general criticism of modern development trends. Despite appearing on Planet GNOME, and referencing a current debate, this is not at all specific to GNOME. The point listed below was more a maintainer screw-up than anything else. It’s not a debate on good usability, because everyone has different opinions on it, none of which are right. The point you should be caring about is how users are treated. I know we’ve assumed too little of some people in Gaim and other projects. Not always, but often enough, and I know many other large projects do this as well. So please, focus on that part.

I completely agree with Davyd on the contextual information lost in notifications. I like GNOME, but I feel that we are taking a step back in this regard, and it’s leading me to wonder, are we assuming our users are really, really stupid and need hand holding?

Now, the Linux desktop is maturing, but there are a lot of areas that could be made easier. Things that confuse users. I hardly think “JPG” or “PNG” or “SSH” emblems are one of them. And really, do we think users have never seen JPEG or PNG files, have never heard of them, and would be confused and scared to use their desktop if they saw them?

If a user is connecting to a remote server and mounting it, they probably have some kind of understanding as to what SMB or SSH means. I mean, come on, they have to choose it first! It’s not some random technical thing we’re throwing at them. Context is good, and I know a lot of average users who prefer the context and turn on file extensions on Windows because they want to know what kind of file they’re actually working with.

The common question that I always hear is “but can my Grandma use it?” Are we really targetting senior citizens? If so, we’ve lost. Let’s take a page out of the proliferation books that McDonalds, Microsoft, and everybody else uses. It’s a simple one. Target people when they’re young! Contrary to popular belief, a number of teenagers use computers, and these teenagers understand things. They’re using bittorrent clients, maintaining websites, sending files across the Internet. Should we really treat them like they’re idiots? Sure, Grandma may not know what a JPEG file is, but I doubt she’s a heavy computer user anyway. Most likely, she plays solitaire, and I think her hand can be held with anything else. In the meantime, let’s not forget our younger users who really aren’t as stupid as we’re starting to treat them.

Pretty new notifications… And a release!

I’ve been inspired by the December GNOME mockups. A lot of them are quite nice, and in the area of notifications, it had some good ideas on sprucing up the look and feel. So I present to you, notification-daemon v0.3.4!

Along with the usual assortment of bug fixes, I’ve improved the style quite a bit. There’s now a countdown timer on notifications with actions, a close button, themed urgency-based stripes, and actual buttons.

Before After
Old urgency stripesOld icons and actions New urgency stripesNew icons and actions

A few project updates

I’ve been putting off several posts for a few days now, due to just being busy with things. So, here we go.

Notification Framework

I just put out a couple of good releases of notification-daemon and libnotify. A few days ago, I released version 0.3.2 of both components, and tonight I put out notification-daemon v0.3.3, which contains a few nice bug fixes such as a fix to prevent notifications when the screen saver is active or when something is running full-screen. The style of the notifications has been changed to resemble the look from notification-daemon v0.2.x. It now supports theme engines, so that other looks can be developed. The protocol has improved and stabilised a bit, and the API and general code of both components have been cleaned up, thanks to J5’s work.

Galago

Galago’s been on hold lately due to work and trying to get the new notification-daemon and libnotify ready for distros. Development has picked up again, and I’m hoping I have very little to do before I can put out the 0.5.0 releases of all the components. Finally, libgalago will be GLib/GObject-based, and the API will be a lot more sane. Plus, Python bindings! Yay!

Oh, and I’m moving to Trac for our bug tracking (see trac.galago-project.org). This is real nice, because I can now reference bugs in commit messages and they’ll close automatically with the commit message. It’s also quite clean and easy to use. I’m slowly moving some bugs over, but I’ll continue to monitor the bugzilla for a while.

Leaftag

Remember those screenshots of our tag integration I posted? It too has been on hold, but it’s far from vaporware. We’re calling it leaftag, and I think our logo is somewhat cute :). I have very little left to do before the library is released, and I should be able to redo the Nautilus support quickly. I’ve been using the tagging almost every day. Now I just need to find the time to get this ready. Maybe at one of these upcoming hackfests I’ve been doing (and really hope to do more) with friends.

VMware

Busy busy busy, but good. I’m working on some pretty exciting stuff. More about this later 🙂

Oh, and someone needs to remind me to put up a picture of our cool new Workstation 5.5 sweaters featuring Mario!

Tagging and the GNOME Desktop

Just a little preview. It’s not done yet, but will be shortly. What you see below is a small python module, a useful command line utility (well, that’s not shown, but if you check the gallery these are in there will be a full-size screenshot showing one), and plugins for Nautilus, GNOME-VFS, and Deskbar. There are plans for Beagle support in the near future, and to make the system more robust.

Stay tuned. There should be a release soon.

Tags in Nautilus lists

Tags in Nautilus lists

tags URI

Deskbar Integration 1

Deskbar Integration 2

The Future of the Linux Desktop?, Part I

It seems there are a lot of interesting things being developed lately. I’ve been reading about GNOME Storage, which is a really cool concept. I haven’t played with it yet, or looked into the code, but I think that if done right, it can really add to the desktop experience. Perhaps it could be used as a feed for Galago.

Linux as a desktop system has, in my opinion, a lot of potential. Though I wouldn’t recommend it at this point to most people I know, I do hope for a day when I can. The reason why it has so much potential is that anybody can modify the source of any program to provide the integration, assuming there’s not an API and plugin architecture that would do the job. Of course, we all know this, but think about it. Work like Dashboard or Gnome Storage just wouldn’t be all that doable under a closed environment without a lot of collaboration and licensing between Microsoft and any other companies. Unless of course there’s an API available there, but MS APIs only go so far.

There’s a lot that can still be done. My goal with Galago is to be able to automagically retrieve information related to the task at hand on almost any supporting program, in a desktop-neutral fashion, and to have an indicator of a person’s status wherever you see his/her name, e-mail address, or other contact information. But this is just one small part.

I want to see a desktop where when I open my report for school, I can instantly see on the side of my screen or somewhere icons for the other files related to this report, URLs I accessed to find the information, and the status of any people on my buddy list I worked on the report with. I’d prefer not to see this in a big white window on the side, like Dashboard does and Galago will do, but something more integrated into the environment. How, I’m not sure yet.

Something else that may be neat to see in the future is a revision control feature built somewhere in the backend. I believe Gnome Storage has this in their plans, and I hope it ends up being a part of the desktop experience. I’ve had clients and family members complain that they accidentally deleted or overwrote a file they were working on, and wanted me to recover it. If this was built right into the system, their documents would be safe.

Drag-and-drop install/uninstall of applications is another feature I’d love to see. This was something that Mike Hearn brought up the other day. If a person could download a single package and drag it to their desktop to install, and then drag it back to the trash to uninstall, it would simplify package management for the user dramatically. Of course, this requires that we finally get packaging sorted out and standardized, but this isn’t likely to happen any time soon. However, his autopackage project does provide an interesting form of package management that I wouldn’t mind seeing take off. The rest could be abstracted through GNUpdate.

At this point, I’d like to bring up how cool the stuff Robert Love is working on. It’s one of the upcoming things that are really exciting me.

I had more I was going to bring up, but it slipped my mind, so I think I’ll end this post….. now.

Scroll to Top