Not relevant for for KDE 4.9 - and this comment is about FullScreen WITHOUT borders ;) I've just added a new entry 'FullScreen' into QKeySequence::StandardKey for Qt 5.0. In KDE-next, we might want to take advantage of the multi-value, platform-dependent lists which I provide per HIG guidelines. Here's the Gerrit Change: https://codereview.qt-project.org/#change,25412

Just for the records: this is a dummy bug for the feature plan script and the target item is whether and how maximized windows are movable  - it's not actually related to decorations (the netbook setting) or fullscreen windows

*** Bug 295417 has been marked as a duplicate of this bug. ***

Personally, I support a way to fix issues with this setting rather than removing it. I don't use it myself, but wouldn't like seeing features and settings get deleted. If it's way too buggy to do anything about however I understand.

(In reply to comment #4)
> Personally, I support a way to fix issues with this setting rather than
> removing it.

*sigh*
This is /not/ a gnome-style feature removal thing and removing the setting will be the only fix.

History:
The setting is internally (sitll) called "MoveResizeMaximizedWindows" and was alongside this ("Allow to move maximized windows" or such) exposed through the GUI - what has been wrong even then, because it's always been possible to "move" the window to another screen (in a multiscreen setup), however w/o any visual feedback (ie. you started to drag the window, it didn't move and suddenly jumped to the other screen - or did so when releasing the drag, don't know anymore how it's been in KDE3 times)

Then the "ElectricBorderMaximize" aka "Aero Snap" (the ability to un/maximize a window by dragging it to or from the upper border) was added and the "MoveResizeMaximizedWindows" setting as it was exposed in the GUI lead to confusion, because allowing it would implicitly break "ElectricBorderMaximize".
As a result, the setting was renamed to "Display Borders on Maximized Windows" what is epically wrong because
1. this is sth. the decoration does or does not. It became common amon many decos for that setting but is no necessity.
2. Why would such setting be in the "Moving" section of the config GUI.
3. Didn't fix the conflict.

Since ppl. by this setting still broke "ElectricBorderMaximize" implicitly, it's actually just ignored if "ElectricBorderMaximize" is enabled. Yeay!

Ppl. however wanted no borders on maximized windows (alongside the abililty of "ElectricBorderMaximize") because it will pass infinite space to (most) scrollbars (fitt's law - you can slam the cursor to the right edge and use the scrollbar - not click the window border or such) - so the decorations would have to ignore the setting for that purpose as well.

So the current strategy is to:
- Remove the setting. Maximized windows can /always/ be moved.
- If you use "ElectricBorderMaximize", that will hit first.
- To compensate the lost protection against accidental moves a (strong) border snapping is enforced for maximized windows (ie. you've to really move it "quite" away from the border in order to start a move/resize)

Benefits:
- correct visual feedback on moving between screens.
- you always get the content aligned to the screen edge for maximized windows.
- more honest relation to "ElectricBorderMaximize"
- no more lying about capacities that are actually in the used decoration.

I understand. If you're one of the devs or people who know the code, you know best, so do what you must. Thankfully it's not an important feature, except for visual preference. Besides... if one wishes for a window to have borders while fitting the screen, they can just resize it instead of maximizing... so I guess nothing too important is lost. I know KDE isn't a fan of throwing things away to add something completely new, which is another reason I love it over gnome.

Git commit 395bee6032ca41a1ebf916110ee95aa6056a94ee by Thomas Lübking.
Committed on 17/02/2013 at 01:56.
Pushed by luebking into branch 'master'.

remove moveResizeMaximized option

REVIEW: 103948
Related: bug 91703
FIXED-IN: 4.11

- The setting is ignored, the decoration always gets a "true" for it
- moving a maximized window requires breaking a "strong" snap (1/16 of screen height - unless you use quick maximization)
- all snapping is done towards the client, not the frame
- QuickTileMode is exported to the decoration (just as the maximizeMode) so that it can fix the bordersize alongside that.

M  +1    -0    kwin/bridge.cpp
M  +1    -0    kwin/bridge.h
M  +12   -2    kwin/client.cpp
M  +4    -2    kwin/client.h
M  +74   -42   kwin/geometry.cpp
M  +5    -0    kwin/kcmkwin/kwindecoration/preview.cpp
M  +1    -0    kwin/kcmkwin/kwindecoration/preview.h
M  +12   -1    kwin/libkdecorations/kdecoration.cpp
M  +32   -5    kwin/libkdecorations/kdecoration.h
M  +0    -7    kwin/libkdecorations/kdecoration_p.cpp
M  +0    -1    kwin/libkdecorations/kdecoration_p.h
M  +1    -0    kwin/libkdecorations/kdecorationbridge.h
M  +0    -15   kwin/libkwineffects/kwinglobals.h
M  +1    -0    kwin/workspace.h

http://commits.kde.org/kde-workspace/395bee6032ca41a1ebf916110ee95aa6056a94ee

NOOoooooooooooooooooooo...

Now how can I resize a window by the bottom-right corner?

(In reply to comment #8)

> Now how can I resize a window by the bottom-right corner?

Make a demand to your favorite decoration to offer showing borders even on maximized windows.

As explained in detail in comment #5, this has never really been a WM feature ever, decos just "abused" a hint and the setting was relabeled in a misleading way to resolve a logical conflict of the actually controlled setting.

fyi: a bug has been filled for the oxygen decorator: https://bugs.kde.org/show_bug.cgi?id=324011