| Summary: | setting an existing window as transient doesn't disable minimize button on dialog | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Samuel Venable <samuelvenable> |
| Component: | decorations | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | CC: | kde |
| Priority: | NOR | ||
| Version First Reported In: | 5.17.1 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Samuel Venable
2019-10-22 21:53:31 UTC
Why is that desirable? From what I can tell minimizing a transient minimizes its parent with it. The problem is that when you try to minimize the transient window, the parent does not minimize with it - so for example, in a fullscreen app, this forces the user to Alt+Tab their way back to the transient window. This has been tested with a good number of apps, not just zenity; it has also been tested with kdialog, kwrite, and kate to name a few. All of which have this problem. I'm not certain whether this is a problem with kwin or my code specifically; but I do know my code works as intended on other WM's. I mean to clarify, in the case of some apps, such as kdialog, the opposite is the problem, while minimizing the trnasient window does minimize the parent, minimizing the parent doesn't minimize the transient window. I'm not sure what makes the difference, but either way there is an issue with one window minimizing while the the other does not. The reason why i said that disabling / making invisible the minimize button on the transient window is a desirable solution, or partial solution, is because that is what most other modern WM's do with their decorations for transient windows, this includes Xfwm, Metacity, Mutter, etc. KWin is the only one among the most popular WM's that has such issues and deviates away from the norm by not having the minimize button and taskbar icon hidden for transient windows. these issues only apply to certain windows, not all of them. But it as long as the window type is being set to a dialog via setting the correct Atom property, and using the XSetTransientFor() Xlib function, these things should never be an issue if it worked how other WM's did. Not every WM has to be the same; if the minimize button doesn't get disabled or hidden, at the very least both windows should reliably minimize regardless of which minimize button was pressed, whether parent or transient window. And the task bar icon being hidden should be a given, imo, but if you guys feel differently, it's not like you need to do it. I hope I gave enough details this time. Sorry for not being thorough initially. So, there are four cases we have to take into account: - Minimize the parent window, which has a modal dialog: Only the parent window will be minimized - Minimize a modal dialog: The dialog and all its main clients will be minimized - Minimize the parent window, which has a dialog: Both the parent window and the dialog will be minimized - Minimize the dialog: Only the dialog will be minimized Such behavior has been present since long time ago and we don't have plans to change it. Also, if my memory serves me well, the EWMH spec doesn't say that transients must not be minimizeable. |