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.

4 thoughts on “Gaim Status Rewrite

  1. Just a few thoughts since there’s work on a gaim rewrite anyway. I always wanted to see instant messengers be a little less intrusive. Here’s what I mean. Why not have a mode where gaim just minimizes to the dock. Then when you get a new message you still play a sound and the dock icon flashes.

    Then you can right click on it and it will have a list of all the people you are currently chatting with. The person who just messaged you would somehow be hightlited (different color etc) to tell you that they were the one who sent the message.

    All the windows that instant messengers create are a little intrusive I’ve always thought. This is explained by their need to show ads, but gaim could be much more user friendly if it took up much less screen real estate. Maybe the chat window could just even “roll-up” from the dock like gnome-blog does.

    The easiest way to do this would obviously just be to make all the windows visible/not-visible (even the main gaim buddy window) based on the user current choices.

    I may spend sometime in glade and try to make a mockup…

    Just some ideas. Keep up the great work on gaim.

    Thanks
    matt

  2. One thing I miss in all IM-suites is the ability to run a “client-server” wich will always be connected to the various networks, and have several clients connect to this. The clients would all have the same data (incoming messages, sent messages etc).

    This enables me to leave my IM client connected at work, and come home and read the messages I did not get to read at work.

  3. One thing I miss in all IM-suites is the ability to run a “client-server” wich will always be connected to the various networks, and have several clients connect to this. The clients would all have the same data (incoming messages, sent messages etc).

    This enables me to leave my IM client connected at work, and come home and read the messages I did not get to read at work.

  4. I think Gaim is a great app overall, but honnestly, some UI polish is in order.

    Skinning support would really help (changing the icq/msn/aim/etc… icons, background, etc…) and improving the fonts settings as well (having your font in blue and the other person’s font in red)

    Overall, Gaim has really come a long way!!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s