Ehh - to me, the problem is not in Gaim logging in the second time, but
(rather) both instances of the application to GPF :-).
Actually to be honest, it used to GPF on my home machine running
(suffering) under winME, I succeeded in running another instance of
1.0.0 version and exiting quite well on WinXP ;-)
When speaking of logging in the second time, IMHO each protocol (or the
sever implementing it) already has its own way of reacting to this. AIM
for example sends the still-logged in party a message, that a successful
logon attempt was made from some other place. In case of IRC you have to
choose another nick and so on...
I think Gaim should *not* be the one choosing whether to log an account
in or not. It should just *do* it and handle kicking or messaging on the
already logged in part just as specified by *the* *protocol*.
Simone Caldana wrote:
> I some ideas about a complete but complex solution (hey, I know you
> stopped reading after "complex :))
> Some account types (AOL, for example) let you have multiple clients
> connected at the same time, others not.
> In my idea the behaviour would be:
> Every time gaim wants to log in checks the account type: if it allows
> multiple cuncurrent logins, it logs in and that's all. If the account
> type does not allow cuncurrent logins, it checks against othe running
> gaim copies (user wide or even system wide, this way covering people
> which uses multiple user accounts (I think of fast user switching, for
> example)) if someone is already logged in with _that_ account. If no one
> is, then it logs in, otherwise a popup can be showed to the user asking
> what to do (a la reconnect popup).
> I know this behaviour is spoofable my maliciuos users if the check is
> done system-wide (so maybe throw in a little security) or even by
> malicious applications running as the same user.
> Of course, this behaviour should be only one of
> * do not allow multiple copies (user wide)
> * allow multiple copies freely
> * allow multiple copies smartly (which is the behaviour I described here)
> I think that the first should be the default, since users which wants to
> use multiple copies of gaim (or uses more user accounts switching
> between them) usually knows what they are doing and are perfectly
> capable to set the preference accordingly.
> just my 2 cents
> Martin Ott wrote:
>> Only one gaim process per system or user?
>> Actually this would still be a *bad* default in either way, as there
>> still are people, in need for running two gaim instances at the same
>> time (inside one desktop at home) maybe...
>> Gaim still is a good chatting application to use, but only as far as
>> there will be no other (even accidental) running of it tough. I would
>> really appreciate, if once run, the second starting of the app would
>> not interfere the one already running.
>> Currently I see two options for Gaim - never to allow two instances
>> (at least under the same user, or desktop session) or (maybe even
>> *better*) to enable invocations of as many Gaim instances as user
>> would like. In case the second option - it would really be *useful*,
>> if the profile path could be user-specified from command line (eg not
>> to look just that default '.gaim' location).
>> mickael@... wrote:
>>> I have coded a system which limit gaim to a single process. I just
>>> wanted to
>>> submit it, but while reading the mailing list I have discovered that
>>> Luke is not
>>> really convince to add this behaviour. So before doing any submit, I
>>> suggest to
>>> add a parameter at the command line to disable the single process
>>> Tell me if it sounds good to you, and then I will post it.
Martin (va PahaLOOM)
Jabber: ploom@... (only occasionally)
IRC: ploom@... (ircnet)