GNOME Bugzilla – Bug 61892
Setting window group title and icon
Last modified: 2013-10-06 05:45:11 UTC
The properties such as title, icon, etc. on the group leader are properties for the entire application. We need to think through which of these should be set - certainly the icon should be - and maybe add API to handle doing so.
This interpretation of group leader windows goes beyond what the ICCCM codifies and should probably be included in a EHWM revision.
Agree, I actually brought it up a while back I think - everyone agreed that the only possible interpretation of "group" is "an application" - and Jim Gettys said that was the original intent. The ICCCM does say that properties of the group leader are properties of the entire group. Anyway, people seem to agree on this, but we do need to write it down.
The public mail with Gettys' reply is: http://mail.gnome.org/archives/wm-spec-list/2001-September/msg00002.html The WM_TRANSIENT_FOR and WM_CLASS properties suffice for dialog management and application identification, so to interpret a window group as an application is wasteful of the property regardless of the original intent. Furthermore, that does not seem to be the intent any longer: ICCCM 4.1.11. Window Groups A set of top-level windows that should be treated from the user's point of view as related (even though they may belong to a number of clients) should be linked together using the window_group field of the WM_HINTS structure. ... Since IBM does play a role in TOG and the IBM CUA guidelines describe a object called a work area which would need a window group-like property, it would seem that the intent of grouping is a form of task management. That is also far more useful than operations on entire application which may be instantiated multiple times for different purposes.
Work area is IMO far too much API complexity. The group leader hint is already correct in the meaning "application" for nearly all apps.
> Work area is IMO far too much API complexity. Something I was using 9 years ago on a i486/33MHz with 8MB of RAM would introduce too much API complexity? The API is ridiculously simple - gtk_init() can probably handle most of it. In that, an argument such as --window-group=WINDOW would be parsed and if the value were good would be used to set the group leader. Then programs, such as the file manager, which are invoking other programs would use a suitable program window ID, a folder for the file manager, as the argument of --window-group. (A file manager would only do this from folders marked as work areas.) Programs invoked in this way would probably opt out of session management because the group leader would suffice for this. As I can find no restriction on groups within groups, the implementation change may be as simple as setting the group hint on the _gdk_leader_window with the group leader from invocation. The potential complexity lies in changing group associations at run-time, but that is hardly a desireable API when programs are as poorly integrated as they are now. > The group leader hint is already correct in the meaning "application" > for nearly all apps. It is useless as such. That interpretation is most certainly not required by the ICCCM. There are other hints that suffice for what purpose a user may desire to care about an application instead of his work.
Complexity of API and user interface don't necessarily require lots of processing power. :-). User's brains don't scale with their CPU. I'm a bit leary about using the word "application" to mean "window group" in the GTK+ API, because: - The application/process distinction is a bit confusing - We added g_set_application_name() in 2.2, as something all *processes* were supposed to call. I think 'window group' is a less ambiguous term.
closing old bugs