Gaim

Perfect timing, Yahoo

Yahoo has blocked third party clients again. This is part of their master plan to drive away users, I mean, fix the spam issue. Not that I’ve experienced a spam issue yet, but I’m probably just lucky. Most third party clients use the same authentication code to connect, and Yahoo just exploited a bug or lack of something in the code.

This is all great timing, because we’re releasing Gaim 0.79 tomorrow. For now, we are using the web method to connect, but this has a number of disadvantages. For example, you can’t add or remove buddies.

Despite Yahoo’s attempts, I’m sure they realize this is only going to keep third party clients off temporarily. Sure, they’ll change it again. So will we. Yahoo, some people don’t want to use your client, and your Linux version quite frankly sucks. Don’t push us away. Share the love!

Perfect timing, Yahoo Read More »

Gaim’s MSN and Buddy Pounce Improvements

One of our Gaim patch writers, Felipe Contreras (AKA shx), sent in a wonderful patch today that he’s been working on for some time. Aside from cleaning up a lot of the MSN code, we now have support for MSN buddy icons and file transfer! There are a few bugs to work out, but it’ll still be a couple of weeks until we release, so they’ll be sorted out.

I finally got fed up with the default events and actions for buddy pounces. The defaults were to send a message (which is blank, and therefore does nothing, by default) when the buddy signed on. I felt they could be smarter than that.

Now, when you right-click a buddy in the buddy list and add a buddy pounce, it will automatically pick some sane defaults. If the user is currently idle, “Return from idle” will be enabled. If the user is away, “Return from away” will be selected. And finally, if the user is offline, “Sign on” is selected. “Sign on” is the default if no other defaults were chosen. As these are, I believe, the more popular options, and fit the scenarios people use the buddy pounces for best, these “smart” defaults should save some time.

Also, the default action(s) are now set based off the previous pounce’s enabled action(s). Those of us who always unchecked “Send a message” and checked “Popup notification,” or something similar, should rarely have to change the actions anymore.

Gaim’s MSN and Buddy Pounce Improvements Read More »

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…

Gaim Goodies Read More »

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 Status Rewrite Read More »

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.

Gaim-Galago Read More »

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.

Galago Presence, Gaim Status Read More »

Scroll to Top