GNOME Bugzilla – Bug 340166
TRACKER: Grouping definition, modality types
Last modified: 2018-02-10 03:19:45 UTC
So, I want to make this somewhat of a tracker bug for grouping (GtkWindowGroup), especially as it relates to modality. I'll add some explanation to tie the bugs together. According to bug 109638 comment 1, GtkWindowGroup was added to allow making a window modal to its parent window only. The documentation is somewhat vague and only mentions that it can be used to limit the effect of grabs. However, later when it was used in such a way in bug 307095, Owen said that this seemed like a misuse and that GtkWindowGroup should instead be used to have different windows be treated like entirely separate applications and that something else was needed for modal-to-parent-window. Indeed, this seems to be backed up in bug 59724 comment 5 where Owen says specifically that this "GtkWindowGroup means 'application'" behavior is what he wants. And, for what it's worth, it definitely seems like the best route to me too. So there are some issues: -- gtk+ doesn't have any way to provide modal-to-parent-window behavior, the modal-to-"application" behavior that does exist needs to be documented (bug 307095), there's some question as to whether modal-to-entire-process is wanted or needed (bug 318676 and bug 69934, for example; it appears to me that this was before "GtkWindowGroup shoudl mean 'application'" was decided on, though, so I don't think this is wanted), and hinting to the window manager of the modality type is messed up (I'm about to file a new bug for this; but see also bug 91023).
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.