Toughts about gtk_init

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:


while its plugins would only have:


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 Hoffleit   Mathematisches Institut, Uni HD    |
|   INF 288, 69120 Heidelberg, Germany |
|               (NeXTmail, MIME)   (49)6221 54-5771    fax  54-8312   |
|                  "We will make windows invisible"                   |

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