Since KDE 4.11, kWin hides most window decorations (borders) if a window is maximized. It it is moved in maximized state (a *very* handy feature that could be enabled in the options in earlier KDE's, but I cannot currently find the configuration setting in the system settings application?!?), the window decorations stay hidden. The window decorations should be restored as soon as a maximized window is moved with the mouse or keyboard shortcuts. Reproducible: Always
do you mean the complete window decoration is gone (including the title bar with buttons) or just the side borders?
The title bar is visible, only the borders on the sides, the bottom and the top of the title bar are removed. I understand that this is intentional while the window is maximized and in its original position, as it provides more display space to the application's contents and reduced visual clutter, but it's just strange after moving the window - for one, it looks different compared to all other windows, additionally, you can't resize such a window by dragging its borders, since there are none...
The window is still maximized, the deco does not update the border size. Previously such windows (ultimately no borders for maximized windows, but it's more complex) could simply not be moved at all (unless you had "Quick Maximization" enabled) and if you allowed move/resize, the window had borders all the time. I guess this and bug #324410 fall into the same category, being a preference for bordered windows even though maximized (rather than the window bein movable?) -> see bug #324011 and also https://bugs.kde.org/show_bug.cgi?id=299245#c5 Every window can btw. be resized using Alt+right mouse button (anywhere on the window) and as an explicit resize below the maximum size will also withdraw the maximized state, you'll also get back the borders at once. Also Oxygen and some other defcorations provide a "resize corner" (which Oxygen however withdrew in your condition, see bug #324011 as well) Dev note: We could re-ask the deco for borders when snapping in/out of MaximizeArea (but that makes present client snapping mandatory, since otherwise the decorated window will never snap into that area)
Thanks, Thomas, that clarifies a lot! Also many thanks for reminding me of the Alt-Rightmouse-Drag-feature - theoretically I knew about it, but not actively using it for some time I somehow I didn't remember it when I was stuck with the borderless window. It needs a steady hand if you do not want to resize the window vertically as well, but otherwise works well. :) (As a sidenote, I'm using the complementary Alt-leftmouse for moving windows quite often...) If it would be somehow possible to auto-redecorate windows that snap out of "maximized" position, that'd definitely be an improvement (otherwise the window simply looks and behaves funny compared to all the others), but as you correctly noted I'm probably someone who would prefer even maximized windows to have borders, now that I think of it again... However, I'm already happy to know that there's quite a bit of thought invested into the whole topic from the dev's side, and I think I can live with the Alt-rightmouse-drag-workaround so far - I'll try how this works out during the next days. :)
(In reply to comment #4) > It needs a steady hand if you do not want to resize the window vertically Try hitting the window on the vertical center third.
Cool, works. :) I knew Alt-Rightdrag but I didn't know it makes a difference where you drag.
kwin emits signals to indicate when the maximized mode changes. you could also monitor frameGeometryChanged or clientGeometryChanged