Galago
I finally gave up with the whole “playing everything politically safe” with Galago and am now moving the whole library to GLib. It’ll take some time, and there’s a few things I need to figure out first. For example, a very useful feature that Galago’s object model let you do was connect a signal handler on a class itself, which would call the handler any time the signal of any object of that class was emitted. This of course didn’t translate to other object models or bindings well, and certainly doesn’t translate to GLib at all.
One of my potential solutions was to create a Manager class for each class where developers would want to do this. The Managers would be singletons and objects would emit signals on them as well as themselves. Maybe Manager is a bad name of the type of object… I’m still not sure what to do about this. It’s a very useful feature though, and the only alternative for everything that currently uses this is to set up a bunch of signal handlers for parent containers to know when these objects are added/removed and then register/unregister signal handlers every time the objects of interest are created/destroyed. It’s a lot of messy code, and would take up more memory than a manager interface. Still got to play around with the idea more…
Notifications
I’ve begun work on porting libnotify and notification-daemon to D-BUS 0.3x. I plan to use a simple abstraction layer consisting of macros to keep compatibility with D-BUS 0.23.x for now. I have a lot of work to do this week at VMware, so I don’t have a whole lot of time to devote to it right now.
Mike Hearn and I had a talk earlier about extending the notifications spec. Sorry, we’re still not going to provide a way to embed Mozilla. One thing people have been wanting, though, is to be able to associate a notification with something on the screen, say, a notification icon. So what we’re going to do is provide support for X, Y coordinate hints. Since they are hints, the renderer will be able to just ignore them if they want. However, this would allow the battery applet (for example) to say, “I have a notification, and here’s my location!” and the renderer could pop up a notification near there with, say, a little arrow pointing to that X, Y location. This could be useful in a few situations, though hopefully it won’t be abused.
I have some future plans for the notification daemon. I’m going to put together a (for now at least) experimental daemon that has two types of plugins: Render plugins and Transition plugins.
The Render plugins will be responsible for rendering the notification. They could do the nifty folding thing that appeared on Planet GNOME a while back. They could do a bar sitting at the bottom of the screen, semi-transparent. They could do toaster popups. Whatever.
Transition plugins handle how the notification will be displayed. They could just show a notification, fade it in, slide it in, make a poof of smoke.
Again, it’ll be a while before I can start on this, due to life just being busy right now.
Disneyland
And this is one other reason why life is busy. My girlfriend Jamie and I are going with my family to Disneyland after next week. Unfortunately, this week is spent on some deadlines at work. But that’s just going to make the next week even more fun 🙂 We’re staying at the Disneyland Hotel, which will be a first for both of us. I’ll have plenty of pics when I return.
Trackback: http://www.chipx86.com/blog/archives/000098.html
Trackback: http://pvanhoof.be/blog/index.php/2005/06/20/39-galago-and-other-important-desktop-integration-compontents
“Connect a signal handler to the class itself”. What you want is g_signal_add_emission_hook().
Wow, thanks Federico. I didn’t realize this existed. The port will be a lot cleaner now.