Version: unspecified (using KDE 4.5.95) OS: Linux I have configured KWin to snap windows to the corners (this Aero Snap thingie) using keystrokes (Meta+Left and Meta+Right). I noticed that this affects Plasma extenders as well, so they get maximized to the left half of the screen or right half, depending on the keystroke. Maximizing keystroke maximizes the extender. Using a fullscreen keystroke (in my case Alt-F11) makes the extender fill the whole screen. Reproducible: Always
And they retain their shape even after closing it, so now I got a network manager plasmoid that fills the right half of the screen and I cannot resize it smaller since resizing this extender doesn‘t work.
these probably should not be applied to such windows which have asked not to be managed ..
Concerning quick tile it's more difficult as it's a proprietary KWin enhancement. It respects only move/resize. From that I assume that alt+click also influences those extenders. I think this is another case for "we need a window class for the desktop shell". Something for next Tokamak.
Yes, Alt+Mouse also affects them but I didn‘t wrote that since some extenders do use the mouse and you can drop them on the desktop (I think the calendar does something like that?) but yes, this also affects them. Well but not only quick tile (ah, that‘s the term, right :P) affects, but also the standard maximizing keystroke. The keystroke for moving also lets them being moved, and alt-f5 minimizes them.
@Aaron if you can use alt+l/rmb on a window it should not have (and probably does not have) the "override" type, so those extenders should maybe just use it then =P (i only tested with "wall ding" -> notification, but that's a _NET_WM_WINDOW_TYPE_DOCK) @Martin: why should "quick tiling" /not/ respect (_NET_WM_ALLOWED_ACTIONS & _NET_WM_ACTION_MAXIMIZE_VERT) or just Client::isMaximizable() ie., what's the point in allowing explixitly non maximizable clients to "pseudo v'max" - notably since they'll implicitly get the _NET_WM_STATE_MAXIMIZED_VERT property by the set geometry (probably only iff allowed) (in doub't: just don't paint the tile hint either =) @Kai-Uwe if you can use alt+mouse to move windows, you can also use the right mousebutton to freely resize the window - the max'd state will be removed by this (unless the extender was smart enough to setFixedSize() - then you're doomed but it's also a bug in the extender ;-)
> @Martin: > why should "quick tiling" /not/ respect (_NET_WM_ALLOWED_ACTIONS & > _NET_WM_ACTION_MAXIMIZE_VERT) or just Client::isMaximizable() > ie., what's the point in allowing explixitly non maximizable clients to > "pseudo v'max" - notably since they'll implicitly get the > _NET_WM_STATE_MAXIMIZED_VERT property by the set geometry (probably only > iff allowed) > (in doub't: just don't paint the tile hint either =) Because it's not really maximizing and wouldn't solve the problem... xprops of the calendar: _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
changing to wishlist as it's not really a bug and needs change in currently correct behavior (considering the allowed actions shown in comment #6)
I think this could (actually only) be "solved" by making the shortcut a toggle. A "_NET_WM_DO_NOT_REACT_ON_QUICK_TILE_SHORTCUT" is rather not in the cards and one cannot prevent windows from being undecorated, yet managed (since they'd all be affected by this, not only some plasma extenders)
Created attachment 56251 [details] Make QuickTile shortcut act as toggle the maximize shortcut works this way as well (yes - i've maximized a window to test this, now bash me ;-)
seems to be implemented in master.