Re: Only one instance of a capplet should be allowed

On Tue, 21 Feb 2006, Havoc Pennington wrote:

> Virtually all apps really should be single-instance (though they often
> allow multiple document windows). There should be an API in GTK for it,
> in fact ignoring back compat, single-instance ought to be the default
> behavior for a GNOME application unless the programmer does something
> special. Probably too late to make it the default, but it should at
> least be easy.

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...  If type-system
initialization and such is an issue here, the kdeinit road can be
taken.  Apps can be categorized in three groups:

  1) Those that it doesn't make much sense to run in more than
one instance.  Capplets are probably a good example of this.
This access a resource that is best not accessed by more than one
application at a time.  Like your gconf configurations.

  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...

  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.

> 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?


> API would let an app register a "new instance" callback essentially,
> which would be called when the app is first launched, and also if it's
> launched again and forwarded to an existing instance.
> Something like:
> int
> new_launch_callback(int argc, char **argv)
> {
> }
> int main(int argc, char **argv)
> {
>   gtk_set_instance_handler(new_launch_callback);
>   return gtk_invoke_instance(&argc, &argv);
> }
> If the app is already running, then the callback is not invoked in this
> process but instead invoked again in the existing process. If the app is
> not already running, callback is invoked in the current process.
> There are a variety of complexities, but this is a pretty longstanding
> thing nobody has ever fixed... every app is hand-rolling some wacky
> solution.
> Havoc


"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
	-- Dan Bern, "New American Language"

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]