Are we talking about group leaders or client leaders?

group leader, sorry.

My feeling is we should just do this as part of the modal group. 
That's got to be right in general.

A group should be a main window + dialogs, toolboxes, etc.

Though by that definition, arguably each non-dialog non-toolbox 
non-splashscreen toplevel should be in its own group by default, 
with other windows deriving their group from transient parent...
unfortunately that gives ABI compat issues.

Group leaders, I guess (otherwise, Havoc would have mentioned the
session manager, not the window manager).
  
Also see bug 68557, bug 61892 and bug 116278 for issues regarding
group leaders. Client leaders don't live on the GTK bug mountain (yet).

*** Bug 116278 has been marked as a duplicate of this bug. ***

I think having "applications" as groups of windows different
from GtkWindowGroup is too much complexity. And also, 
if a user sees two windows as separate applications, then
you don't expect a dialog modal for one to affect the other.

So, I think using GtkWindowGroup as the "application" object
is right.

Having window groups inherit across gtk_window_set_transient_for()
makes a lot of sense to me; I think that's a compatible change
to make.

However, if we make GtkWindowGroup the way of doing X window
groups, we clearly can't make each toplevel a separate application
by default, since we would break applications that depend
on modal dialogs being process modal. So, people will have
to be responsible for creating their GtkWindowGroup objects
themselves. That doesn't strike me as being that bad to do.

Marking dependency on bug 69934 because encouraging GtkWindowGroup
usage means we need a easy way to have process modal dialogs.

Window groups are inherited across transient parents now in cvs HEAD.