Bug 299245 - Get rid of "Display borders on maximized windows" setting
Summary: Get rid of "Display borders on maximized windows" setting
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal (vote)
Target Milestone: 4.11
Assignee: KWin default assignee
URL:
Keywords:
: 295417 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-05-02 17:29 UTC by Thomas Lübking
Modified: 2013-08-25 12:18 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.11
thomas.luebking: Decision-Required+
thomas.luebking: ReviewRequest+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Lübking 2012-05-02 17:29:07 UTC
The setting conflict with quick maximization, so we should find a smarter way to handle this.
Idea and rough patch: https://git.reviewboard.kde.org/r/103948/
Comment 1 Rick Stockton 2012-05-09 20:11:06 UTC
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
Comment 2 Thomas Lübking 2012-05-09 21:00:37 UTC
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
Comment 3 Thomas Lübking 2012-12-23 21:40:22 UTC
*** Bug 295417 has been marked as a duplicate of this bug. ***
Comment 4 Mircea Kitsune 2013-02-24 10:05:17 UTC
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.
Comment 5 Thomas Lübking 2013-02-24 12:33:13 UTC
(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.
Comment 6 Mircea Kitsune 2013-02-24 16:11:53 UTC
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.
Comment 7 Thomas Lübking 2013-03-24 21:55:22 UTC
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
Comment 8 Vito De Tullio 2013-08-25 11:29:19 UTC
NOOoooooooooooooooooooo...

Now how can I resize a window by the bottom-right corner?
Comment 9 Thomas Lübking 2013-08-25 11:36:50 UTC
(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.
Comment 10 Vito De Tullio 2013-08-25 12:18:04 UTC
fyi: a bug has been filled for the oxygen decorator: https://bugs.kde.org/show_bug.cgi?id=324011