On Wed, 1 Dec 2004, Sean Egan wrote:
> On Wed, 01 Dec 2004 13:22:00 -0600, Tim Ringenbach <omarvo@...> wrote:
> > Sean Egan wrote:
> > If you ask me, it's more of a merger between autologin and login.
> I'll grant that.
> > The thing I like
> > least about it, is that in order to log on a seldem used account, it
> > also becomes autologin, that is, I have to remember to uncheck enabled
> > later, if i just quit gaim, and restart tomorrow, my test account logs
> > back on, which may displease me.
> I've already thought about how this will change my normal process of:
> gdb ./src/gaim
> set args -a
> Login SeanEgn6
> Wait for it to crash
> Obviously this wouldn't be possible with my newfangled scheme, but
> it's an obscure case easily fixed by changing -a to -c gaim_debug or
> some such.
> As for the actual end user who is signing in EndUsr6, it's not that
> big an issue at all. It's only an issue at all because it's different
> from what we've always done. A broader view will see there's nothing
> unnatural about having to explicitly disable an account you explicitly
> Even if it takes a while to get used to it, it's not the end of the
> > Also consider the case of a neighbor or friend coming over, adding their
> > account, and enabling it. They quit gaim, next time i start, I log on my
> > friends account, knocking them offline, pissing them off, and making
> > them distrust me since I appear to be using their screennames and
> > pretending I'm them.
> This is a more serious effect of the same issue. But even this is
> bearable, and will probably get accustomed to with a little
> adjustment. This problem would exist in any system, though, that
> correctly implements the "Single Global Status" abstraction we're
> discussing here. The whole point of it is that the user is a single
> person with one status.
> Anyway, you said that this system has pros, and I feel they outweight
> the cons. However, if anyone has a better way to allow "Offline" to
> be an ordinary state set in the blist menu, without causing an
> incredible amount of confusion due to the login checkbox, I'm all
I haven't exactly been the most involved in this discussion, nor have
I really looked at any of the status code, so it is entirely possible
that this idea will be unhelpful or even impossible, but here it is
What if Enabled (or whatever we decide to call it) is taken to mean
that any default status applies to this account. That is that any of the
standard status types that gaim ships with (Online, Away, Invisible,
Offline) will apply to this account, where as disabled accounts are
always offline. (This leaves the guest account stuff still to be
We then make a clear distinction between the standard statuses and any
custom statuses people might create. Created statuses are visually
separated by some means (a separator, different color, etc.) in the menu
at the bottom of the blist. Creation of a custom status requires use of
a dialog (like Mark's or one yet to be created). Custom statuses are
defined over certain accounts/protocols, leaving out any accounts which
are intended to be offline. (I think the code has a method to layer
statuses which means you would define a custom status as a base status
or a layerable status, which would be used to allow for signing on and
off groups of accounts independently of main status.) Layered statuses
can apply over a standard status or a custom status.
The Enabled checkbox has no effect on any custom status that might be
set. Discussion on what to do with that column of the account dialog
when one is in a custom status is needed. I'd vote for having it do
nothing to the custom status and still just control default status
behaviour under the assumption that most people won't be messing with
custom statuses at all and if they are they will not want it messing
with their carefully constructed custom status.
I'd also suggest that we add a Status column to the accounts window
which indicates the current status of each account. This allows us to
leave the Enabled column as indicating solely whether or not a default
status will apply to the account, and gives us a column in which to
This idea isn't quite complete, nor is my explanation of it, but I think
it at least starts to get my idea across.
P.S. Perhaps it would make sense to make indicate that custom statuses
are an advanced concept and as such to make the dialog for creating
them, and perhaps even the adding of them to the status menu at the
bottom of the blist, the job of a plugin. This would let us keep the
main interface simple for the 95% of the cases that Sean talks about on
his mockup website, while allowing those people who care more to
specifically complicate their interface.