Re: [Gaim-devel] Gaim's Status Rewrite

[Nathan W. <fac...@fa...>]

On Sun, 2004-04-25 at 17:41 -0700, Christian Hammond wrote:
<snip current situation>

> Now for what I'm attempting to do about all that.
>=20
> The new status rewrite centralizes all status information into a
> couple of structs.
>=20
> The main struct is GaimPresence. This contains a list of known statuses,
> the active status, the idle state, idle time, warning level, and sign-on
> time. Every buddy, account, and user in a chat gets its own GaimPresence.

It'd be a lot easier for me to visualize and comment on this if we could
see at least a preliminary definiton of GaimPresence (and the other
structs, while you're at it)


> GaimStatus represents such things as away, extended away, invisible,
> available, etc. Each GaimStatus has a parent GaimStatusType that is
> registered with the account (more on that in a second). It also has an
> optional user-defined name. This is only useful for some statuses, and
> is used in the same way that away message titles are. This is what
> you'll look up saved statuses as in the menu or whatever. GaimStatus
> also has a list of attribute values, and its active state.
>=20
> GaimStatusType defines the template for a status. They are registered
> for each account independently. Protocol plugins define them, and must
> provide at least "online" and "offline." When registered, an optional
> list of attribute types (using GaimValue) are added. The most common
> will be "message" of type string.
>=20
> Along with the attributes, a status type contains its primitive type
> (more on this soon), an ID that is internal to the protocol plugins, a
> name that the user will see ("Away," "Extended Away," "Do Not
> Disturb," etc.), and the saveable, user_settable, and independent
> flags.
>=20
> These flags are important to this model. Saveable status types are
> ones that will get written to the statuses.xml file. These are
> primarily useful for away messages. I should note here that this new
> status API will allow you to sign on to accounts in the state they
> were in when you left them last time. The saveable flag does not need
> to be set for this. The information will be temporarily saved in
> accounts.xml.
>=20
> All statuses whose parent type has a user_settable of TRUE will appear
> in the UI. You would want to set this to FALSE if you planned on using
> the status internally only.

I can't quite see where non-user-settable settings are useful, but that
may be because I don't know the nitty-gritty of each of the protocols.


> By default, all statuses are exclusive. You can only set one at a
> time. However, if a status type has the independent flag set, it will
> no longer be exclusive. Setting it won't deactivate any other
> statuses, and activating other statuses won't deactive that one. One
> such use for this is an Invisible state. You may want to set Away and
> Invisible, and if Invisible's status type is independent, you can do
> so. It'll appear as a checkbox or something. It's also useful for
> internal statuses that the user doesn't see or manipulate.

I think this is going to get very confusing very quickly for the users.
Feel free to prove me wrong, but I'm already getting confused.


> Status types are registered with a "primitive" type. The current
> primitives are GAIM_STATUS_OFFLINE, GAIM_STATUS_ONLINE,
> GAIM_STATUS_AVAILABLE, GAIM_STATUS_UNAVAILABLE, GAIM_STATUS_HIDDEN,
> GAIM_STATUS_AWAY, and GAIM_STATUS_EXTENDED_AWAY. These define the very
> basics of the status type, and are used when determining if a
> particular presence is available or not, and when calculating which of
> two presences is more available.

Can we get a little more info on these.  Why do we have AWAY and
EXTENDED_AWAY, but no DND?  Are these to be combined, so I'd be AWAY and
UNAVAILABLE?  Or are they all mutually exclusive? =20


> The calculations are done using scores, just like Nathan's contact
> scoring system. A table called primitive_scores exists in my status.c
> that defines a score for each primitive. Negative scores are
> unavailable, while positive scores are available. These can all be set
> through prefs.xml as well.

See above, I'm still a bit confused.


> All presence and status-related information from GaimBuddy and
> GaimAccount have been removed, and were replaced when a GaimPresence.

So is the GaimPresence for a GaimAccount updated when a GaimStatus is
selected?  And the GaimPresence for a GaimBuddy updated when the server
lets us know a buddy's status has changed?


> When an account is created, the prpl's get_status_types() function is
> called. It's much like the old away_states() function. It returns a
> list of status types that it creates. Each of these may have
> attributes listed, and even default values for these attributes.
>=20
> After creating the account, its presence is created. It will then
> receive a status of each type that does not have a saveable flag set.
> If there are any stored statuses (like stored away messages), these
> will go in as well.

You lost me here.


> When a protocol plugin updates the presence for a particular buddy,
> every instance of that buddy in the buddy list is automatically
> updated. This potentially simplifies code a bit for protocol plugins.

This is a sad limitation of the stupid way we handle multiple copies of
a buddy.  I wish we had a better way of handling things, like a
GaimBuddyCopy that just pointed to a GaimBuddy or something.


> The server.c file is slowly being eliminated with this rewrite.
> serv_got_update() is now gone, and has been replaced with the presence
> and status APIs, as well as a handful of gaim_prpl_got_* utility
> functions. These functions essentially locate the account or buddy
> (depending on the function) with the specified name, grab the
> presence from the account or buddy, and call the appropriate API
> functions. I have not yet decided if I'm going to keep these, or just
> remove them.
>=20
> I should note that no UI work has currently been done. I am in the
> process of converting all prpls, which is a difficult task. Many of
> the prpls are very dependent on the uc variable, and keep their own
> copies of away and away_state around. These must be re-thought and
> re-implemented to use the new code. Currently, only gadu-gadu, IRC,
> and MSN are converted.

I'm thinking we need a working UI before we need all the prpls
converted.  Hell, demonstrate this working with 1 or 2 working prpls,
and we can convert the rest after it works.  Converting all the prpls in
the tree still leaves us with something that doesn't work, and something
we can't test.  Also, I still can't see a UI for all of this that isn't
going to confuse the hell out of people.


> If any developers wish to help speed along this process, let me know,
> and I'll give you an account on my local SVN development tree. I want
> to get this all working before I put it into CVS, so that we don't
> have any major issues that will delay a release.

After graduation I'll want an account, if nothing else so I can see code
rather than descriptions.  I deal better in code.


> I'm sure I forgot to address many things in this, but it's getting
> long, and I have to head out. If you have any questions, reply, and
> I'll address them.

You did some wonderful Wiki work for the first conv rewrite.  Are we
going to see anything along those lines for this?


/me goes back to the schoolwork he's been avoiding.


-Nathan