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…

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.