Created attachment 8163 child windows test case When an application has child windows, those appear in the Window Buttons and can be switched to with Alt+Tab, but they cannot be minimized (actually they can, but it behaves strangely, more on this later). They have no minimize button. In other window managers (Metacity and KWin for example), child windows behave almost like normal windows. The only thing that cannot be done is put them behind their parent window (and this is expected, I think, and works already correctly in xfwm4). It is nevertheless somehow possible to minimize child windows. When the button of a focused child window is clicked in the Window Buttons, the child window is minimized. But when another child window (or the parent window) is selected by using the Window Buttons or by switching to it with Alt+Tab, the minimized window is restored. I think that similarly to Metacity and KWin (and probably other window managers), xfwm4 should allow to minimize child windows as other windows. They should have a minimize button. Minimizing a window should minimize all its child windows (it already behaves like this), and restoring a window should do exactly the opposite operation. This means that if any of its child windows was minimized before its parent was minimized, that child window should not be restored when its parent is restored. Not being able to minimize child windows makes it cumbersome to work with application that have many child windows. A test case is attached to this bug. It creates a main window with 3 child windows. It uses Python 3 and PyQt 5. I’m willing to fix it myself, but I have no idea in which file this is handled. If someone could give me a clue, it would be great.
Works as expected here... The so called "child windows" had a minimize button and can be minimized at will and also appear in the alt-tab list. One thing though, there is no such thing as "child windows" in X11, there are however the concept of "transient" relationship between windows which can be used to create a parent/child relationship. Actual decorations and allowed actions on transient windows, usually used to describe "dialogs" and "modals" in entirely up to the window managers. You can check if a dialog set its transient parent using "xprop WM_TRANSIENT_FOR" and clicking on the dialog window. The value will be the XID of the parent window, or can be the root window in which case the WM will treat that windows as a "transient for group". xfwm4, like other window managers such as mutter/gnome-shell, will not allow transient windows to be minimized independently of their parent window, this is a very common behavior expected by most users and applications. That said, attachment 8163 sets no actual transient relationship and therefore the all windows cxan be minimized independently, including in xfwm4. Basically, I see no bug here...
Hi Olivier, and thanks for your reply. I’m surprized that we have such different results. I tried it on Xfce 4.12 (xfwm4 4.12.3) on Ubuntu Studio 16.04 and on Xfce 4.10 (xfwm4 4.10.1) on Fedora 21. Maybe you’re using a more recent version where this has changed? If this is the case, then it is good news. Or maybe your Qt version is different? I tested with Qt 5.5.1. If the way parent windows work has been changed in more recent versions of Qt, that would explain the difference. When I run the test, the child windows don’t have a minimize button. The context menu of the title bar shows the “Minimize” action as disabled. I tested the transient property of the child windows with your method, and they are indeed transient for the main window. Why wouldn’t xfwm4 allow to minimize transient windows independently of their parent? I understand that they should be minimized when their parent is minimized, but when it is not, why not offer the option? For utility windows, I guess it doesn’t make much sense, but for applications that use big child windows (like Maya for instance), it would be very useful. I’m not the only one asking for this: https://forum.xfce.org/viewtopic.php?id=6005 I’m actually currently using Metacity instead of xfwm4 only because of this (even if I really prefer xfwm4 over Metacity).
I just checked on GNOME 3, and transient windows can be minimized (I checked for the WM_TRANSIENT_FOR prop), like in Metacity and KWin. It seems that only xfwm4 behaves differently.
Created attachment 8169 Fixed reproducer Right, as I said, your reproducer does not work for me, it does not create transient windows. That updated version does.
Created attachment 8170 Reproducer with xfwm4
Created attachment 8171 Reproducer with metacity
Created attachment 8172 Reproducer with mutter
As you can see, none of metacity, mutter or xfwm4 actually allows the "child" windows to be minimized independently from their parent window, and this is on purpose. Only exception here being kwin, but as I said, this is up to the window manager to decide. So either we are not talking about the same thing, or... it's as expected.
I see that in the reproducer you changed the widget type from Window to Dialog. Indeed, with a dialog, it works as expected, as dialogs cannot be minimized usually. The issue happens only when the widget is of type Window, but starting with Qt 5.6.2, it is not possible anymore to create a normal window that is transient to another window, so the bug doesn’t appear. The change was made as part of the fix for https://bugreports.qt.io/browse/QTBUG-52550. To see the bug in action, you need to run the reproducer with an earlier version of Qt, or we should have another example that does not use Qt. The code that Qt uses to set up the transient parent is at line 825 of https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/xcb/qxcbwindow.cpp?h=v5.6.1 In version 5.6.2, they changed the condition, so normal windows never reach the code.
I see, yet the point remain, the type (dialog) is something added with EMWH, the transient relationship is something in X11 itself.
What do you mean by “the point remain”? Do you acknowledge that xfwm4 behaves differently than the other window managers (and that we should probably fix this), or do you mean that there is no issue?
I mean it works as designed, the concept of "dialog" is something specific to EWMH, whereas transient windows is from the ICCCM so both should be treated the same.
Then why most other window managers allow to minimize transient windows that are not dialogs? They only don’t allow to put them behind their parent, and if the parent is minimized, they are minimized with it. With xfwm4, we are in a kind of limbo with these windows: they appear in the window list, can be switched to with Alt+Tab, but cannot be minimized, and are not raised when they are selected (as described in bug 14952). I don’t think this is desirable and this puts xfwm4 behind the other window managers in term of user friendliness.
Sorry but I checked (once again) metacity and mutter with "nedit" (Motif based text editor which doesn't use EWMH) and both behave like xfwm4 with dialogs, these cannot be iconified neither from the title bar (no “iconify” button) nor from the window menu. Can you please provide a working example of what you're trying to demonstrate? (attachment 8163 is not a good reproducer as you noted in comment 9)
Created attachment 8189 child windows test case Replace PyQt5 test case with PyGTK test case.
Does the PyGTK test case shows the problem for you? Do you think it could be fixed easily? I’m willing to do it myself, but I don’t know where to begin. Could you tell me in which source file this is handled?
Yes, I see the problem... It's a mix of different things, one being libwnck relying on the behavior from metacity. I have the choice, a quick but ugly fix or rewrite some of the oldest core functions in xfwm4...
Olivier Fourdan referenced this bugreport in commit bd6481d170cebb56b33a38806e021a5781d82c6c clients: Allow transients to be minimized https://git.xfce.org/xfce/xfwm4/commit?id=bd6481d170cebb56b33a38806e021a5781d82c6c
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/311. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev