Re: Only one instance of a capplet should be allowed

[Havoc Pennington <hp redhat com>]

On Tue, 2006-02-21 at 21:10 -0500, Behdad Esfahbod wrote:
> 
> May I ask for the reason?  Processes are cheap in Unix, and we
> have been making all kind of static data shared among processes.
> By overly making all apps be single-instance, we only make you
> lose more of your work when a process crashes...

You're talking about implementation, while I much more meant something
about the UI. I would say:
 - if you open a document that's already open, the existing window 
   for that document should come up
 - if you launch something that's not document-oriented, say rhythmbox, 
   you usually want its existing main window to come up

The UI I'm talking about could be implemented (somewhat painfully) with
multiple processes, if someone wants to suffer that pain then I have no
objections.

But I see no real reason that:

$ foobar MyDocument

should produce a new process, and 

File->Open, choose MyDocument

should not, so if an app was designed to have a process per document I'd
make File->Open create a new process.

>   1) Those that it doesn't make much sense to run in more than
> one instance.  Capplets are probably a good example of this.

My claim is that pretty much every app I can think of is in this
category. It's certainly the normal/default case, and app authors should
"opt out" of it for that reason, if their app is weird.

>   2) Those that are preferred to just pop-up on later
> invocations, but it may make sense to run more than one instances
> of them too, in certain circumstances.  Your favorite music
> player and gaim fit in this category.  Normally when you press
> the gaim launcher, you want a gaim to pop up, you don't need a
> new instance most of the time.  Sometimes you may want to run a
> separate gaim instance in  "booth-mode" where it loads no
> configuration and logs nothing...

Sounds like questionable workarounds for missing app features to me.

But we could make the single-instance API support a special command line
option for this. e.g. gnome-terminal has the whole --disable-factory
command line option if you really want a process per window. If we had a
standard single-instance API then --disable-factory could also be
standard.

>   3) Those that there's no reason (other than technical reasons)
> to do single-instance.  They typically don't have much shared
> configuration/preferences.  Evince may be a good example of this.
> Evince is single-instance right now, but that's just the way it
> is implemented I guess.  It could have been non-single-instance
> and perform quite the same.

I bet Evince is single-instance because Bryan, Jonathan, & co. wanted it
that way from a UI standpoint. I could be wrong.

> > Since arg parsing/handling is different for single-instance apps
> > (certain kinds of arg don't make sense for instances after the first,
> > such as --display) gtk could offer a gtk_init() alternative perhaps. The
> 
> Can you elaborate?  Why doesn't --display make sense?

You have to make the app support multiple displays for any instance
after the first to open on a different display. I spent a lot of time on
that for some app (I think it was gnome-terminal), but really just
printing an error saying "use --disable-factory, thanks" would have been
a lot more sensible than wasting my time on this.

A more minor issue is that Xlib will exit your app on all displays if
any display disconnects.

Or it can be solved by having a single instance per-display, instead of
per-session.

Anyway, complete corner case, basically nobody uses multiple displays in
a session. (Multiple screens sure, displays no.)

Havoc