GNOME Bugzilla – Bug 164537
Non-modal transient dialogs should iconify with parent
Last modified: 2007-10-18 00:33:51 UTC
Transient dialogs that are not modal should iconify along with their parent window. Instead, only the parent iconifies and leaves the transient dialog visible. This also has the effect of not being able to restore the the parent window until the transient dialog has been dismissed. It is possible to work around this by using notifiers and forcing the iconification of the transient dialog, but the natural behavior should be that it automatically iconifies along with its parent window.
Changing type from feature request to bug after determining that behavior works as expected in GTK UNIX (transient dialogs do iconify with parent as expected in UNIX, but they do not in Windows.)
Well, there are lots of different window managers for X11, so you can't be 100% sure that this works as expected with all of them...
That's a good point about the window managers on X11. The one I tested it on was GNOME using Metacity I believe. Here it does display the expected behavior. On Windows, the normal behavior of a transient dialog is that it should iconify with its parent. So I still think this is a bug in Win32 GTK.
FYI, I also tested it in KDE an hour or so ago. It also has the expected behavior on KDE where transient dialogs iconify along with the parent.
Created attachment 91840 [details] [review] Work in progress This patch makes children minimize with their parent. The problem if that the item in the taskbar doesn't necessarily refer to the parent, so restoring windows doesn't work yet. I'm not sure how that works yet, but I'm posting my first attempt at this patch anyway. There is another angle that I looked into, but couldn't get to work and that is the WM_SHOWWINDOW notification's lParam == SW_PARENTCLOSING/SW_PARENTOPENING. Unless I'm overlooking something, it seems that this doesn't work for deeply nested transient windows.
Created attachment 94029 [details] [review] More complete proposed patch This patch addresses both this bug and also bug #164537. It's still got a little bit of debugging output that was being used for testing, and may require a tiny bit of cleanup.. but otherwise, I think it fixes the issues. I'd like Tor to take a look at it and see if it's fixing the issues right though. ;) So, the gist of this is that each GdkWindowWin32Impl already stores a pointer to its transient owner from my last patch, and it now stores a GSList of its transient children. Whenever a window gets minimized or restored from a minimized state, we walk up the list of transient owners to the top (to a window that doesn't have a transient owner) and we recursively minimize/restore all its children. The reason for all this is because Windows seems to be assigning one taskbar entry for any particular chain of transients and if you have Window1, Transient1, and Transient2.. and then you minimize Transient2 then that window is lost to you, because clicking on the taskbar entry will just focus on one of the remaining windows that is still on screen. The workaround seems to be that you can still alt-tab to get back your lost windows, but that's a shitty workaround for the end user.
Err.. I meant to say that this also addresses bug #371036.
I believe this will also solve bug #405178.
Created attachment 96125 [details] [review] Updated patch against trunk (2.12) This is basically the same as the last patch, but updated to apply and build with gtk+ trunk (2.12).
Is there anything at all I can do to get this accepted so I can commit? Or at least get it reviewed, or something? I want to be done with this.
Created attachment 97397 [details] [review] Same patch minus the g_print() statements.
As discussed on IRC, looks good to me, please commit.
2007-10-17 Cody Russell <cody@jhu.edu> * gdk/win32/gdkevents-win32.c * gdk/win32/gdkwindow-win32.[ch]: Force non-modal transient dialogs to iconify with their parents on Win32. Maintain a list of transient children, and whenever a window is hidden or restored we now do the same thing to all connected transient windows above and below the current window in the chain. See comment under WM_ACTIVATE for the reasons why. (#164537, #371036, #405178)