The taskbar aka task manager fails to re-activate the "Maximize" button in its context menu once a minimized application that was full screen has had full-screen turned off. Reproducible: Always Steps to Reproduce: 0. Use Global Keyboard Shortcuts to configure KWin with a shortcut either for minimize or show desktop. (Alternately, have another window open.) 1. Start an application, e.g. Kate, not maximized. 2. Right-click, go to "More Actions", click "Fullscreen". 3. Kate is now fullscreen and covers the taskbar. Press the keyboard shortcut you've configured to show the desktop or minimize. (If you didn't configure a shortcut, but you have another window open, you can Alt-tab to it, then minimize Kate from the taskbar.) 4. Kate is now minimized and fullscreen. Right-clicking the taskbar properly shows "Maximize" unchecked and disabled. (If you'd started step 1 with a maximized Kate, it would properly show a checked and disabled Maximize button.) Uncheck "Fullscreen" from the submenu. 5. Kate is now still minimized, but not fullscreen. Right-click again and look at the context menu that appears. Actual Results: It still shows "Maximize" disabled (whether checked or not). Expected Results: Maximize should now be available.
Created attachment 90872 [details] demo of the bug
Reassigning to plasmashell since it's still reproducable with the current-gen applet in Plasma 5.
libtaskmanager instanciates a new KWindowInfo after the window drops out of fullscreen, which then returns false for actionSupported(NET::ActionMax) when the context menu construction interrogates it. CC'ing Martin for the KWindowSystem side ...
It's expected behavior (X11 limitation to be precise). The window is minimized (that is unmapped) which means the state is not applied at all. KWin as the window manager has no chance to update the allowed actions. This happens when the window gets unminimized. My suggestion is to disable any interaction while the window is minimized from taskmanager.
Thanks Martin. That makes this a WONTFIX, since the action is correctly inaccessible.
That assessment makes no sense whatsoever. What X11 does or doesn't know is completely irrelevant. What is relevant is that KWIn knows at all times when a window is fullscreen or not, and whether it is maximized or not. Knowing that is not dependent on whether the window is minimized/unmapped. The taskbar action of checking or unchecking "Maximize" ALWAYS unminimizes the window if it was minimized. >> This happens when the window gets unminimized. Exactly, so WHEN it unminimizes (which it always will), it can update X11 however it needs to. Thus there is no reason for the Maximize action to be disabled.
Created attachment 90939 [details] demo of related problems Here's a demo of two related problems: one is where the "Maximize" is still enabled after "Fullscreen" is selected. Then after exiting Fullscreen, "Maximize" is disabled even when the window is NOT minimized. To duplicate: 1) Start Kate (or anything) neither minimized or maximized. 2) Check Minimize. 3) Check Fullscreen. 4) Though it's now fullscreen, the "Maximized" box is still enabled. Clicking this brings the fullscreen window to the front (but behind the panel). 5) Uncheck Fullscreen. 6) The window is now back to normal (neither minimized, nor maximized, nor fullscreen), however the "Maximize" is still disabled on the taskbar.
As I said in comment #4: My suggestion is to disable any interaction while the window is minimized from taskmanager.
In that case KWindowInfo::actionSupported() should return false for everything for minimized windows. A fresh KWindowInfo instance is interrogated for this every time the context menu is constructed, the Task Manager doesn't keep any state for this by itself.
Martin, what about the above?
(In reply to Eike Hein from comment #10) > In that case KWindowInfo::actionSupported() should return false for everything for minimized windows. hmm, that would be wrong I think. It would mean that the method does not reflect what it should do. Also applying this logic might be difficult as there is no minimized state. To a wm there is hardly a difference between a for example shaded and minimized window or a window on a different desktop. It also would be a clear behavior change in KWindowSystem which I would say violates the ABI promise of frameworks. Now I thought about whether we could withdraw the actions from wm side, but that sounds also very racy and potentially dangerous. Also it wouldn't solve the problem as it would only fix for KWin. Thinking even more about it I think that changing the option "Keep window thumbnails" to "Always" would fix this problem. So it's not bound to the minimized state, but only to the mapped state. This is also readable through KWindowSystem and given that I think the restriction needs to be done closer to the usage and cannot be abstracted in the library.