Bug 159924

I've previously discussed this with the gaim-devs. Their take, if I recall
correctly, is that gaim is not by default designed to run parallel versions, and
if you want to do this, then utilise the -c switch. As gaim is a
multiple-protocol IM program, there's really no need for multiple profiles.

Admittedly running parralel gaims with the same config could be, in theory, a
very bad thing and should probably be trapped and blocked. However, this is an
RFE and not a bug.

This is my take, based on previous convos with the devs. Your luck may be different.

I agree that we should be trapping and blocking an attempt to run gaim again as
the same user.  How to do this however is a bit tricky.  We could use xremote
(doesn't work on Windows), or maybe ping a local named unix socket in the user's
homedir (does that work on Windows?), or maybe something else...

I wonder if it's possible to utilise the gaim-remote at all, in a similar way
that the mozilla-help does 'magic foo stuff'. From past experience, it's very
poor at detecting dead instances which is my only immediate concern about this
suggestion (however, I haven't tried using it recently).

Oh, I just realised this is a rather silly sugegstion as of course this'd mean
that gaim-remote would have to be 'on'.

Behnam Esfahbod: Why do you feel a need to run multiple instances of Gaim?

Gaim runs just fine in parrallel, IF you are using the -c flag.  Also
noteworthy, ther are situations where it'll work just fine even if you are not,
such as using -a and then signing on different accounts, IF you don't mind the
side effects: other than those changes made during those runtimes, groups will
be consistent across both instances, across all accounts.

I *suspect* what we see here is a request for "guest access" to gaim: that is
the ability to let a friend sign on once using a gaim session running as the
same user you do.  While this sort of activity is completely insecure, many
people do it as a matter of pure convience. 

-c IS ideal for such people, as they can keep not only the groups across the
accounts separate, but the log files as well.  The problem is that the gui does
not offer any easy way to have a -c <some/path> launch, and cannot do so short
of having two gaim icons, one for each "profile."  

netscape solved this same probly by creating its profiles *inside* its config
directory, ~/.netscape in that case, and mozilla appears to follow that pattern.
 This allowes them to write their own profile manager and do the Right Thing
after a profile has been selected.  On the other hand, I have always found the
Profile Manager itself a pain to use or have active.  I would thus be at least
somewhat opposed to this sort of solution for gaim. 

I think there are two simple solutions, probably both can be done using a small
launcher script, like the gecko browsers do:

1) On a second launch, the running instance will pop up.  Like xmms is doing today.

2) On a second launch, a new instance is run, but no autologin is performed. 
Like skype is doing today.

What i said about profile is specially for "Guest" profile, that doesn't
remember anything, like yahoo/msn messenger.  Gaim people told me that I can use
"-c /tmp" for that, but it's not a solution for users.

My suggestion is launcing gaim for the second (or any other) time, runs gaim
with a new profile (i.e. -c /tmp/user/.gaim.PID) and probably a notic for user
that there will be no archive nor any other good stuff.

I suggested gaim developers to have a guest mode without many memory-related
features, but they don't like it.

Of course it's good idea that panel-launcher just show current run(s), and a
guest launcher be available in Applicatios menu.

The current behavior where it attempts to auto-login using the same profile,
therefore interfering with your existing gaim, is unacceptably bad.  We need
*some* way to check for a running session and prevent this.

I disagree that running a second time should start a guest session.  I think the
most logical thing would be to pop-up the existing gaim.

Netscape's Profile thing is *extremely* annoying and something we should avoid.

A gaim "Guest Mode" with a possible separate launcher might also be a good idea.
 It would also be very useful for kiosks.

I've pointed out before that Kiosks should be more thorough in wiping out old
data.  You can't expect every application to have a "Guest Mode"--it's far
better to just delete /home/guest at logout.

I agree that Gaim needs to detect when the user runs a separate instance.  I'm
undecided about whether it should start a new instance in "Guest Mode" or just
pop up the old instance.

My 5c
Launching again should pop up the original instance.
'Kiosk/Guest' style mode requires a switch (eg, -g [guest] or -k [kiosk]).

This behaviour is intuitive, imo

Created attachment 115315 [details]
gaim-launcher script

The attached short script is a launcher that detects if a gaim is running in
the current session (using xlsclients), and runs the subsequent gaim's with no
autologin.  The effect is that you get a login screen.

I can't think of any way to pop up the current instance without a gaim plugin. 
But maybe such a plugin can be written (should be easy) and turned on by
default.

Created attachment 115316 [details]
gaim-launcher script

Attached launcher detects a running instance, and runs subsequent ones with
no-autologin.

I cannot think of an easy way to pop up the current running instance, without
writing a gaim plugin.	But that should be easy to do.	Are Red Hat / Fedora
people Ok with shipping gaim with such a plugin on by default?

Sorry for dup.  Both times I got a Bugzilla internal error :(

We will not ship an alternate launching script because it is an ugly hack.

Peter is correct in Comment #11 that it should pop-up the existing gaim session
rather than running another instance of the same profile.  This should be the
real bug that should be fixed.

> I've pointed out before that Kiosks should be more thorough in wiping out old
> data.  You can't expect every application to have a "Guest Mode"--it's far
> better to just delete /home/guest at logout.

This thinking about kiosks is flawed, because the vast majority of kiosk
computers do not logout when a new user sits at the computer.  An explicit kiosk
mode that neglects to save info is necessary for this situation.  Perhaps also
kiosk mode should have a protocol chooser at the login screen, since users are
most likely to choose one protocol and use it once.  This is a separate RFE than
the existing profile pop-up issue described above.

Closing this as this is work required upstream and not Fedora's sole responsibility.