Created attachment 47518 [details] [review]
docs.patch

I don't think these docs are a good thing. A dialog created in this
way isn't "non-modal" (it wouldn't be accessible if it was) ... it
*independent* of the modality of all other dialogs and windows
of the application. I can't imagine when that makes sense.

Usually, GtkWindowGroup is used when an application wants to have
multiple toplevels that seem like entirely separate applications.

Yeah, I can absolutely see that. However, the current GtkWindowGroup docs are
horrible. Both myself, federico and vektor attempted to solve what most likely
is a common use case (Where you have three windows, A, B and C, with A as the
main toplevel, B as a child of it, and C as a child of that. Make B modal, and
not allow access to A, and allow C to be accessed), and we were all unable to do so.

Anything to clear this up in the docs would be great.

I don't think window groups are the right solution for your use case...
they don't give the right behavior in the end. I would consider what
you are asking for to be more or less impossible with GTK+ as it is
currently set up.

This may be related to the idea of "attached windows" that I've 
discused with Vektor in the past, where you can specify that
a popup window is logically part of a toplevel window. (Think
drawers.)

The case where C is a real dialog strikes me as pathological ...
a modal dialog with a tool palette or similar is an abuse of 
modality and just bad user interface. (The idea of modality as
an interface of last resort has been a tenet of GUI design 
ever since the beginning of WIMP)

I dont quite see how it isn't the right solution, as it works. We just create a
new WindowGroup for C and then everything works like we want it to. So until
there is a 'real' solution, I don't see why including useful documentation in
the docs is bad (Note, I only added/filed this because federico wanted something)

The problem is that if another modal dialog is created that overrides
dialog B, then dialog C is not blocked.

It's good you found a workaround that basically fixed your problem, but
I don't think it belongs in the documentation as an approved normal
way to use a GtkWindowGroup.

Makes sense. In our case, there is no modal dialog popped up from B ever, so
it's not an issue.

In our case, the case that B needs to be modal, but needs to have children is
absolutely correct, I agree that in general, it is abusive, but in the domain
where we are working, this is exactly what people expect.

Whenever the API is created for "attached windows" is there a way to make sure
it includes the ability to attach multiple windows? I ask only because our
current use case uses that right now.

Wontfix, according to Owens first comment.

I'll reopen this to remind myself to fix the docs.  I want to have an
explanation of how window groups work in terms of grabs, modality, etc., and
their intended purpose.

closing out old bugs