Toughts about gtk_init

[Gregor Hoffleit <flight mathi uni-heidelberg DE>]

The ICCCM paper suggests the notion of window groups that group `related  
windows'. Window managers can decide to treat these windows as an entity  
(e.g. hide all at once).

Currently, each call of gtk_init creates a new window group. In the case  
of GIMP e.g., any plugin that's loaded creates a new window group. IMHO  
that's not what we want, the plugin's windows are owned by the GIMP and  
should therefore go into GIMP's window group.

IMHO a clean solution for this is to provide a distinction in the GTK API  
if the process creates a new instance of an application or belongs to a  
running application.


A first guess would be to introduce a new GTK function, call it  
gtk_appinit(). Any _application_ would call gtk_appinit once and then  
gtk_init, while things like _plugins_ would only call gtk_init.  
gtk_appinit could be supplied with a WM_CLASS classname to be set for this  
application and would then create a leader window.

A problem is that all sub-programs had to inherit the leader window of  
the application. A quick fix would be a commandline option "-leader  
WINDOW_ID" that would guide sub-programs which leader window they had to  
`connect' to.


E.g. the GIMP would say:

	gtk_appinit("Gimp");
	gtk_init(argc,argv);

while its plugins would only have:

	gtk_init(argc,argv);


it's still not the level of abstraction I'd like to have (the -leader  
hack looks silly), but I think the main thing is that there the API should  
provide a mean to make the difference between apps and plugins visible.

Any thought or objections ?

	Gregor



---
|                Gregor Hoffleit   Mathematisches Institut, Uni HD    |
| flight@mathi.uni-heidelberg.de   INF 288, 69120 Heidelberg, Germany |
|               (NeXTmail, MIME)   (49)6221 54-5771    fax  54-8312   |
|                  "We will make windows invisible"                   |