Gaim

Unproductivity

This week has been really bad for my productivity. It seems that with only a few exceptions, I’ve ended up reverting nearly all the code I’ve written this week. Wednesday, however, I managed to be very productive and get a lot of important code written for Galago. I also managed to start the protocol docs, but those aren’t very far yet. Still, I should have some things for this week’s Galago status report.

I decided today to pick up a dual-head Sapphire Radeon 9600 card. I hear good things, and two monitors should really make things easier when I’m working with a bunch of terminals while reading documentation. I’m hoping to get it this week, but I’m in no rush.

Back to working on the status report…

Ahh, Nostalgia

I think there’s something wrong with me. With the help of Mike Hearn, I now have After Dark running in Linux, through xscreensaver. I couldn’t be happier.

I’m free, and things *work*

Woo! Yesterday marked my last day of finals. Though now I’m finding that I miss my classes. Ah well, plenty to do this summer.

The computer situation has been fixed. The motherboard, it seems, had some “issues.” On top of that, two drives were going bad. The reason for all the lockups and kernel panics were probably a result of bad sectors where the virtual memory was. So now I have a new, better motherboard and a replacement harddrive for the two that were failing.

Oh, but now that that’s all fixed up, the mouse decided it’s time to die. No real surprise there.

I wonder what I’m going to do with 8 USB ports and 3 firewire ports…

Computer Issues and Filesystem Corruption

It’s never a good thing when your daily alarm on your computer (which is basically XMMS here) doesn’t go off in the morning. Seeing the keyboard LEDs blinking and a frozen screen saver aren’t much better. Once again, this new box kernel panicked in the middle of the night.

I’m not sure whether to blame the hardware, or the 2.4.26 kernel. The RAM checked out fine, and nearly everything works otherwise, with a few exceptions. My IntelliMouse Explorer keeps losing the ability to function, and I have to unplug it from the USB port and plug it back in every 20 minutes or so. I replaced mice, and it seems to work now. However, now the IntelliMouse is working fine in the iMac. I can’t tell if the mouse is going dead or if it’s a kernel issue.

I couldn’t get 2.4.26 working on the server box (which used to be my main desktop). It would lose all network connectivity, no matter what I did. Oddly, the same configuration works on this box, using the same network card. I suspect 2.4.26 is just a buggy kernel, but I haven’t seen a whole lot from other people to indicate that.

So anyhow, this morning, I rebooted and it came up with a whole bunch of filesystem errors. All kinds of stuff. Several of the errors said, "attempt to read block from filesystem resulted in short read." A quick google search indicates that this could be the disk going bad, so I’m sure I’m in for a lot of fun these next few days. Fortunately, the only data I lost were a bunch of KDE .desktop files and some .m4 files that apparently weren’t even lost. No clue what happened there. *sigh*

Some days, I really miss using my Commodore 64.

Gaim Goodies

I’ve finally been getting back into Gaim development a bit lately, outside of the status rewrite. The multi-field request API, which is used for abstracting request dialogs with various forms of input for a Gaim UI to generate dialogs from, got several improvements.

Some fields are marked now as required fields. If set, the UI can grey out the OK button when those fields aren’t filled out. This only applies to text entry fields at the moment, but support can easily be added for other types (if it makes sense for them).

An account field type was also added, which was the final piece allowing us to replace the New Instant Message and Get User Info dialogs with the request API. A lot of GTK+ code was removed from this change, and it improved consistency and HIG compliance.

And last but not least in this department, type hints have been added to fields, which the UI can use for additional functionality. The first use in Gaim is that if a text field has a type hint of “screenname,” the text field will get support for auto-completion of screen names.

And with that fun out of the way, work continues on the status rewrite. Oh so fun…

Moving On

Life took a bit of a turn for the worse recently, relationship-wise. My now ex-girlfriend, whom I cared deeply for, and I broke up, and it ended pretty badly. So, it’s time to move on, find someone who perhaps is more compatible, and get some code written again.

Gaim’s status rewrite is now moving along well, aside from the past few days, when I’ve just been dealing with the aforementioned issues. I still don’t have a definite ETA for completion, but the core code is now mostly there. It likely won’t be able to do some of the really complex status combinations people wanted, but that can be done through a second layer (as it should). Anything more complex than what it currently is would require a really complex API, and none of us wants that.

Galago has been moved to SVN over on freedesktop.org, and I’ll likely get a page up soonish, after tests and other responsibilities. After I figure out a couple of design issues, support for presence feed capabilities will go in, and the work on Evolution’s Galago support will be nearly finished.

Sometime this week, I plan on finishing up a bug fix for Gaim for Qtopia and releasing 0.5. It’s long overdue, and people are waiting for some of the fixes to go in.

Just got to get my motivation back after the break-up. Metroid Prime is also sucking up my time, but that’s probably not a bad thing right now.

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.

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.

Best Bugs

I was having a chat with my brother earlier about software bugs, and I started trying to remember about the best bugs I’ve encountered in software I’ve had a hand in. Below are my list of favorite bugs that I found entertaining. I’m kind of curious as to what other people would choose for their favorites.

My favorite bug would have to be Gaim’s flying buddies. When the rewrite of the Gaim buddy list was commited, in 0.60, we had a fun little bug where the drag-and-drops weren’t completed. This triggered a Gtk bug (I think it was Gtk’s bug?) where the nodes in the GtkTreeView would fly around the screen a bit from point A (where the node originally was) to point B (where the node is now). When the buddy list was off-screen, this made it particularly fun. As these were flying around, we quickly named them Flying Buddies.

Between classes one semester, I wrote a Snake game for my TI-89 calculator. It was rather easy to do, but I had an off-by-one error that generated what I called “snake droppings.” When the snake ate one of the blocks on the screen, it would of course extend. As soon as the tail started moving again, it would leave a pixel or two behind, hence the name.

My third favorite bug was during the development of my BilliardZ game for the Sharp Zaurus SL-5×00 PDA. Occasionally when hitting a ball, a big black hole would open up on the board, and the ball would disappear in it. Playing pool with black holes littering the table is a little inconvenient. I’m still not sure what caused it, but I ended up fixing it.

Speaking of bugs, something messed up on gnome-blog. I’ve spent over an hour trying to get it working again. Works now though.

(Update: I somehow lost the top paragraph. I don’t know how, but it’s back. That should provide more context.)

Galago Presence, Gaim Status

So far, the Galago framework is coming together rather well. I don’t have anything that runs and communicates yet, but a lot of the base framework has come together, and I expect to build test programs by next week (assuming all the other busy things in my life don’t take up too much time).

At the moment, I’m working on the Galago Presence stuff. I’m running into design problems that I also have with Gaim’s status rewrite. This is to be expected, since the two are essentially the same thing.

The main issue I had in the Gaim status rewrite is that I wanted to generalize status types, and provide a mechanism for multiple types to be set at once. This also requires that some times exclude other types from being defined. Unfortunately, this creates a big mess when registering status types.

My vision for Gaim status is to cover all aspects of a user’s status. Their online state, offline, away, brb, idle, whether they have encryption enabled, mobile communications, etc. The display in Gaim would be the same as it is now, with the exception that the Away menu would be a little different, as would the away dialog. Icons would still appear in the list.

The problem comes when we want to say, “away implies online” or “online excludes offline” or “I’m online, away, but hidden.” It can get confusing, so it needs to be done in a simple fashion.

Now, back to Galago and status. How detailed should status information be? We probably don’t need to know every little detail like we do in Gaim, but maybe we do? How do we standardize it then? It’s easier when we have control over the source tree in Gaim and can make status IDs all match, but when we have third party applications defining their own IDs, it doesn’t work so well.

The approach I’ve taken in the Galago presence code currently is to separate it out into a status type (an enum defining OFFLINE, AVAILABLE, AWAY, EXTENDED_AWAY, and HIDDEN, currently), a status name (“BRB,” “On The Phone,” “Away,” “Online,” etc.), and an optional message (such as an away message). I believe this is sufficient for most purposes. It won’t allow the applications using Galago to display a mobile or game indicator or other such things, but it will give the generic status to those applications.

Another option is to do what we have above, but allow a person to have multiple statuses. That way, they can indicate they are away and are using a mobile device. This should be broadcasted as one presence packet, as presences for a single person on one protocol are not additive. The last one sent is the one that gets seen.

There’s still an issue with applications sending odd statuses, like the user is away and available at the same time, or they’re offline and online. I guess that’s up to the individual programs to fix. We can’t do all their work for them.

It’s still not as flexible as what Gaim’s status model will end up being, I’m sure, but it works sufficiently for most cases, in my opinion. If the user wants any further information on the user’s status, they can check their buddy list or whatever else is providing the detail.

With that in mind, I’ll probably move forward in that direction.

Scroll to Top