Open Source

Productivity Shattered!

I was given an invite to Orkut yesterday. For those of you who don’t know what Orkut is, get out from under your rock 🙂 It’s a rather interesting waste of time, and it’s delayed a lot of my development. I think I’ll be getting back to that in a few minutes though. Just.. just five more minutes.. then I’ll code.. Promise.

My copy of Dream Theater – Change of Seasons and Metropolis 2000: Scenes From New York came yesterday, and I spent the better part of today watching/listening to them. Excellent stuff.

While on the topic of that, it’d be nice to see some kind of CD ripper integration in Nautilus. Right-click an audio CD and get a Rip To Music entry or something, which brings up a dialog allowing ripping to wav, mp3, ogg, flac, etc. Maybe multiple ones at once? I wouldn’t mind flac and ogg copies. For now though, Grip is my friend.

Reasons for Galago’s Design

I have received several criticisms regarding my design for Galago, most of which I believe to be misunderstandings as to what the eventual goals are. Unfortunately, such misunderstandings and criticisms are now leading to duplicated effort, something which really is not needed.

First off, Galago does require a daemon running in the background, though it’s not something that users are going to have to deal with, so that shouldn’t be a major problem. The main question I have received is, why use a daemon? Why not just have everything listen on the interfaces in D-BUS?

A couple of people have suggested that a daemon is pointless and serves no value. Originally, my design for Galago did not include a daemon. Everything would simply listen on the interfaces and report back. This design proved to be flawed, however. Let me start off with an example.

Say you’re using Gaim to provide feed information, and then you start up a program that uses Galago to receive presence information. Every time you open up a window on this program (let’s pretend it’s something with an address book), the Galago-Gtk widgets are given information on what user’s presence should be monitored. Of course, since it’s just monitoring for new presence updates, it doesn’t have anything currently set. So, each widget makes a query to receive the current presence information.

Now, Gaim had already pushed presence for these users before. As a Galago feed, Gaim is able to push presence when a user’s presence changes, which is quite quick, or it search through the buddy list and build a presence list when specifically polled. The polling is what these widgets have to do to receive initial status. You wouldn’t want to just have them wait with no active presence information until someone signs on/off or sets away.

So, back to our address book. Each widget queries for presence. In a design with no daemon, each feed would receive the poll and send back a response. This could be a lengthy operation, depending on the program feeding presence, or it could be quick. Either way, each feed is going to have to send the presence again.

With a design requiring a daemon, that information has already been pushed and cached. When the widgets in the address book poll for the current presence for a user, the daemon will simply return what it has stored. This is much faster and doesn’t require re-polling every program. It’s also smarter, as it can determine which to poll based on the registration time of a feed (more on that in a second), instead of polling every single program every time.

One person pointed out that you wouldn’t be running Gaim and Kopete at the same time. This, however, is not always true. I know of people who run Gaim and AMSN at the same time, and those who run Kopete and AMSN. Regardless, this particular point wasn’t well thought-out. Not only instant messaging programs provide presence. IRC programs, Gnomemeeting, and other collaboration software.. heck, even a program feeding presence for users logged in to the computer can all provide presence at once. I try not to limit my designs to “what do I need right now, I can always expand it later!” That’s a bad design method, imho.

There are more reasons for the daemon requirements. Feeds will soon be registering themselves when created. It’s something that the developers using the API won’t have to really see or touch. The libraries handle it. Registration simply registers the feed with an ID, descriptive name, and a couple other small pieces of information. This allows the daemon to keep a list of what feeds are available, which can be polled, which can push, their sign-on times and last active times, and actions (sending a message, for instance). Any program can query for a list of applications providing presence, and display them in something like a drop-down protocol box.

Avatars will soon be able to be sent along with presence. This is something else that the daemon can cache, though that may be an option in a preferences file, not that many people would need to modify it. The idea is to have such items expire so that memory is not taken up by unnecessary items. This does require a re-poll from time to time, but it’s considerably less work than polling every feed every time we want to display something.

Finally, Galago is not an instant messaging platform. It is for presence, which instant messaging programs can use or provide if they choose. It is not limited to instant messaging programs either, as I mentioned above. I find it unfortunate that a duplicated effort is going on when the two really should work with each other, but that’s the beauty of open source.

Galago-Gtk#, Freedesktop.org

I spent part of the day working on Mono bindings for Galago-Gtk. I now have running a C# version of the Icon Entry test that was in the previous entry. Later, I’ll write bindings for libgalago itself. What’s nice is that this will allow me to prototype much faster. I’m hoping to get someone to do Python bindings. I may handle Ruby myself. Of course, there’s no rush, as the whole system needs to be developed further.

Just a short while ago, Daniel Stone was nice enough to setup a CVS account on freedesktop.org for Galago. It no longer has to run off my slow little CVS server here. I’ll soon get a page up and people can start playing with it.

I’m playing around with the idea of creating a little applet that displays presence info for selected user(s). I don’t know if there would be an icon per person, or one icon with a drop-down. If the later, whichever person is selected on the drop-down will be the new entry on the applet. I’d personally find it useful, and it would be a good little real-world test of Galago.

Galago Status – Widgets and Avatars

The past two days, I have been hacking on a new Gtk widget that will be included in libgalago-gtk. It’s a nice little subclass of a GtkEntry that includes an embedded icon, as shown below:

GalagoGtkEntry screenshot

It has a lot of work to go, but so far it’s rather nice.

Avatar development has just begun in libgalago. Avatars, aka Buddy Icons or That Little Picture of Me will be able to be pushed and received just like presence information. This is untested, but should be working by tomorrow, along with a little Gtk widget for easily displaying them.

I think the next trick is to write a general GalagoConnection API that wraps DBusConnection and allows feeds and watches to be registered to it, so that we can eliminate this one connection per feed/watch requirement Galago currently has.

Gaim Status Rewrite

I’ve been going through several drafts of the status rewrite for Gaim, to make it less AIM-centric as well as core/UI split, and more advanced. The trick is doing this in a way that doesn’t suck. By doesn’t suck, I mean that it’s a clean API that is expandable without being confusing.

Currently, the idea is to have a few main structs:

GaimStatusType – A type of status, containing the account it’s associated with (or probably just the protocol ID), the status type ID, name, parent slot (see GaimStatusSlot below), list of attributes (see GaimStatusAttr below), the primary attribute ID, whether it’s saveable, and whether it’s settable by the user in some fashion.

GaimStatusAttr – An attribute in a status type. It has an ID and a name, and the type of value it has.

GaimStatus – A specific created status, containing the type of status, the associated buddy or account, whether or not it’s active, and a hashtable of filled in values for the attributes in the status type.

GaimStatusSlot – A way of grouping statuses internally. It contains a list of status types, and a flag indicating whether or not the status types inside are all exclusive.

GaimStatusBundle – This is what is created and stored when a user defines their status (which may be an advanced mode in the UI). The status bundle has a name and a list of status IDs that map to it. This is used to, say, set an Away status, but to have it activate “Be Right Back” on MSN and Jabber, a certain away message on AIM. This is of course not something the user is going to have to do. They should be able to set away just like how they currently do.

The trick with GaimStatusBundle is to do things in a way where it supports global status types and protocol-specific ones. Although there really isn’t a distinction… It references by ID. I guess we’d just have to standardize some. I need to think about that more.

It all sounds a bit complex, but it’s pretty easy really. Each protocol plugin registers one or more slots, each with a status type. Each status type can have an attribute. When a user makes a new user-settable status, like an away message, they can build it individually for a specific account or protocol, or globally. It can be as simple as an Away type with an away message (using a standard “away” status type ID and making it global), or they can get complex and set up a scenario like one depicted above.

Status types will be able to go a bit further. Since not all status types are even settable by the user, there can be status types indicating that a user is on a mobile device, that they’re an op in a channel, or whatever. The API for those parts need to be drafted, but once in the base is in place, that shouldn’t be a big deal.

I still have a lot to fledge out. It needs to be slightly complex to be useful, but I think it’ll be manageable.

GalagoWatch – Presence Push

Tonight, most of the work needed for the GalagoWatch was completed. GalagoWatch is a nifty little API for saying, “I want to capture all presence info as it happens,” or “I want to capture all presence info on this service” or “on this account” or “for this user,” etc.

The API is theoretically finished, but not yet tested. I got side-tracked, and adding away status and away message support to the gaim-galago plugin, and am in the process of adding emblem support to the GalagoGtkPresenceIcon widget. Although I should really be asleep right now, I figure I’ll get that done, set the widget up with GalagoWatch support, and get most of the bugs out.

I’m told that jdub’s speech went really well. I’m hoping I can get a copy of it. It’s too bad I couldn’t be there in person to hear it 🙂

Galago Screenshots!

I started work today on the first Gtk widget to use Galago. It’s a simple presence indicator icon. It’s a bit hacky, as it polls every 10 seconds for new status, which can make things slower than they should be. However, the GalagoWatch API that’ll be coming in galago soon will deliver new presence and association information directly to anything that uses it, so this problem will go away soon.

Anyhow, I have a test program, and two screenshots. The first is doing a presence query for myself while I’m online and non-idle, and the second is when I’ve become idle:

Online Presence

Idle Presence

Perrty.

Gaim-Galago

A lot of good presence work was done on Galago today. Presence feeds can now return a list of presences for the user sent to it, which is useful on such things as IM. Say, for example, a program requests presence for user ChipX86, but neglects to specify a service or source account, since it just doesn’t care. The feeds can now return lists of presences, containing, say, Yahoo and AIM presences.

So I got tired of playing with a test presence feed, and wrote a plugin for Gaim that would provide presence information. So far, it’s working rather well, except for the fact that Gaim’s current concept of status royally sucks. I’m working on it, but am having difficulties creating an easy to use API that handles status exclusion. I talked to Kevin Stange, and he suggested using slots, which could work.

So, with that concept, protocol plugins would define one or more slots, each with an exclusion boolean flag set to TRUE or FALSE. Status types would be registered into a slot. The typical status types, such as Offline, Online/Available, Away, Extended Away, etc. would all go into an exclusive slot, while status types such as Mobile, would go into a non-exclusive slot.

The idea is to have this covering all aspects of status. The state of the user, what the user is connecting from (cell phone, etc.), and anything else. Not everything would have to be displayed. There will be type hints used for that, and prpls can still specify what to show. However, there will be a lot more flexibility in what kind of states can be chosen. Available messages will be doable for protocols that support them, for example.

Also, this will be core/UI split, which has been needed for awhile.

I should have status done within the month, if all goes well.

Depending on what happens tomorrow with my girlfriend, I may or may not start the galago-gtk widgets module in CVS. If I get something really cool, I’ll post a screenshot.

Another Sad Day

The first news I read when I woke up was the passing of Mark Finlay. Unfortunately for me, like Ettore and Chema, I didn’t know him personally or talked to him online, but I have kept up with his blog. I had respect for him. He seemed like a really good guy, something that is backed up by all the people praising him on Planet GNOME.

I’d like to take a moment and say thank you to all of the people who bring what I use every day to reality, keep it maintained, and provide support for it. They don’t have to. None of us do, and I know open source developers see “Why haven’t you fixed my bug yet?” more often than “Thank you.” To any users of any software reading this, thank your developers. It’ll make their day, and sometimes it helps to be reminded that what they’re doing is wanted, and you never know how long they’ll be around…

Good bye Mark. Thank you.

Galago – Finally some progress!

After four days of hacking, Galago now provides enough structure for a program to act as a feed for presence information, and for others to request that information. This includes information on a user’s service, the status(es), away message, etc.

There’s currently only one method for requesting presence. It blocks until it receives a response, but there will be two more methods. The first new method for receiving presence information will be a function that takes a callback function as a parameter. The program can continue going on its merry way, and the callback will be called with the new presence information when it’s finally available.

The second new method will be to use a GalagoWatch. GalagoWatch will be used for both presence and associative information, but for now, I’ll concentrate on the presence. You initialize a GalagoWatch, feed it the information needed so it can do its queries, set a callback function, and then start it. Any time the user’s presence information changes, the callback will be called with the new information. This would be useful for widgets and such.

It’s exciting to see it come together. Once I implement those and clean up the server a bit, I’ll be writing a Gaim plugin that acts as a feed, and a widget to display status information for the user passed to the widget. Exciting 🙂

Scroll to Top