Bug 324011

(In reply to comment #1)
> As per https://bugs.kde.org/show_bug.cgi?id=299245#c5 now kwin lost the
> setting to let the user resize a maximize window from the bottom right
> corner.

To clarify this:
the window is still resizable and there's nothing that would somehow prevent oxygen's resize corner or so.

We just removed the setting that controlled whether a maximized window could be moved and "lie" to decorations (since hiding the borders -as interpreted by many decorations- seemed far more reasonable than showing them)

Reason is that the moveResizeMaximized setting (originally in order to prevent accidental moves) caused reports
- ppl. who wanted no decoration, but still move the window
- ppl. complaining that aero snap would work on dragging away the window (when moveResizeMaximized was true)
- ppl. complaining the (relabeled) setting would not work (turning out their deco just does not interpret it this way)
- ... (yes, many more)

-> Clean up was required.
Maximized windows are now movable/resizable, accidental movement is still prevented, decos should please announce and configure their behavior on maximization (if such feature is supported) themselves.

1/ Not sur I understand the bug properly
2/ tested the following:
- in

aah crap.
Ok. Trying again:

- in workspace behavior, if I uncheck "Maximize window by dragging ..."
when I maximize a window, and drag it from title bar, the window is moved, but the window border is still not visible, and you end up with a middle of the sceen window which has no border, see: http://wstaw.org/m/2013/08/26/plasma-desktopAQ6351.png

@Vito: is this what you are complaining about ? 
@Thomas: is this the intended behavior ? A different bug ? Something that should be fixed in oxygen ? In kwin ? 
(I'm running kwin from trunk)

He wants an option to have borders on maximized windows - something that explicitly replaces "options()->moveResizeMaximizedWindows()" (which now always return false despite actually being more or less true - don't ask. The setting got removed and the assumption was that ppl. will want to have borderless maximized windows - even though they're now movable)

Since oxygen basically supports borderless maximized windows, and if you consider borders on maximized windows reasonable setting, just add a checkbox ;-)

(In reply to comment #3)
> aah crap.
> Ok. Trying again:
> 
> - in workspace behavior, if I uncheck "Maximize window by dragging ..."
> when I maximize a window, and drag it from title bar, the window is moved,
> but the window border is still not visible, and you end up with a middle of

> @Thomas: is this the intended behavior?

Yes, the window is still maximized, just repositioned (you should have had to force the reposition against quite some snapping)
Either it will be (implicitly) unmaximized at some point (and gain back its border), or repositioned to the MaximizeArea or moved to another screen and maximized there.

Basically moveResizeMaximizedWindows() is now always enabled to not conflict with the snapping - before you would either not have been able to reposition the maximized window or had borders on the window.

It's really been a mess, therefore those changes to separate decoration behavior from movement behavior and resolve accidental movement prevention differently.

tl;dr
If you want borders on maximized windows configurable, you've to offer that setting (for oxygen) and not "abuse" the moveResizeMaximizedWindows() setting as hint on it (while that's been common, yes)

Created attachment 81951 [details]
proposed patch

@Thomas
See patch attached (notably the section on oxygenclient.h)
Is this enough ? basically the isMaximized() is used later to decide the metrics and how to draw the decorations (with/without borders).

Or do I need to announce anything more to kwin itself ? (I'm not sure I read "decos should please announce and configure their behavior on maximization" properly from comment #1)

@Vito
Any chance you can test the patch before I push it (needs compilation of kde-workspace from master) ? is this what you are asking for ? (note: with the setting "on", I did test that you can resize a maximized window from the bottom right corner).

Also: there is a new string added to the config, so that it cannot make it into kde until kde-4.12
(if the patch is correct, I will push that to both master and frameworks).

(In reply to comment #6)
> Created attachment 81951 [details]
> proposed patch
> 
> @Thomas
> See patch attached (notably the section on oxygenclient.h)
> Is this enough?
Yes. There's more available now (you can ask for the "QuickTileMode quickTileMode()" when being asked for virtual void borders(int& left, int& right, int& top, int& bottom) and skip resp. borders) but otherwise functionally nothing changed.
Just the movability is no longer present as even slightest hint on whether to show a border or not)

The patch is correct as long as the *.ui stuff is ;-)

> Or do I need to announce anything more to kwin itself?
No. Pure deco inside feature - has always been =)

> "decos should please announce and configure their behavior on maximization"
Yes, sorry - i meant "towards the user", ie. you need a setting in your config dialog.

> the setting "on", I did test that you can resize a maximized window from the
> bottom right corner).

Isn't the resizecorner available anymore?

> @Vito
> Any chance you can test the patch before I push it 
> (needs compilation of kde-workspace from master) ? 
> is this what you are asking for ? 
> (note: with the setting "on", I did test that you can resize 
> a maximized window from the bottom right corner).

I need to download + compile master... not for this week, I think I could have the time next weekend.

But if it's for 4.12 I think we have the time :D

(In reply to comment #7)
> (In reply to comment #6)
> > Created attachment 81951 [details]
> > proposed patch
> > 
> > @Thomas
> > See patch attached (notably the section on oxygenclient.h)
> > Is this enough?
> Yes. There's more available now (you can ask for the "QuickTileMode
> quickTileMode()" when being asked for virtual void borders(int& left, int&
> right, int& top, int& bottom) and skip resp. borders) but otherwise
> functionally nothing changed.
> Just the movability is no longer present as even slightest hint on whether
> to show a border or not)
> 
> The patch is correct as long as the *.ui stuff is ;-)
> 
> > Or do I need to announce anything more to kwin itself?
> No. Pure deco inside feature - has always been =)
> 
> > "decos should please announce and configure their behavior on maximization"
> Yes, sorry - i meant "towards the user", ie. you need a setting in your
> config dialog.
> 
Ok. All good then.

> > the setting "on", I did test that you can resize a maximized window from the
> > bottom right corner).
> 
> Isn't the resizecorner available anymore?

ahah. It is, but only for "windows with no border", that is: when you configure window border to be "no border", and then, it is disabled for maximized windows ... 
Ok. So then, I guess I "could" enable it for all maximized windows (when border is not displayed), and this, disregarding the "border width" settings. 
That is: pretty much the opposite of what we have now ... 
But then again: people would complain that they can't resize from the left side/right side/bottom side ... 
So I'm not sure it is worth it.
How does bespin deal with this ?

(In reply to comment #9)
> How does bespin deal with this ?
You can have the screen corner or not - it's then there all the time (but since the input frame is there, it's hardly required)

About dealing with the maximized/noborder change: not at all.
Had we slightly considered ppl. were actually interested in keeping the border (as actual resize/movability is still provided), the config ui had remained, the value been read and ultimately served to configure exactly this (with a warning for deco devs to get rid of it and the acceptance of occasional "does not work", ie. "deco doesn't actually do that" reports)

The ability to *not* have scrollbars etc. on the screen edge was simply regarded a no-feature (thus also snapping rather to the client and not the decoration)

Git commit 1e21fe110f2d5dbe9d9f909faf18d75c4dd05080 by Hugo Pereira Da Costa.
Committed on 26/08/2013 at 19:47.
Pushed by hpereiradacosta into branch 'master'.

Added "Display window borders for maximized windows" option.

M  +4    -1    kwin/clients/oxygen/config/oxygenconfigwidget.cpp
M  +23   -16   kwin/clients/oxygen/config/ui/oxygenconfigurationui.ui
M  +1    -1    kwin/clients/oxygen/oxygenclient.h
M  +5    -0    kwin/clients/oxygen/oxygenconfigdata.kcfg

http://commits.kde.org/kde-workspace/1e21fe110f2d5dbe9d9f909faf18d75c4dd05080

Git commit 8a0e134f6a2171856d163df66761922fdaad3557 by Hugo Pereira Da Costa.
Committed on 26/08/2013 at 19:47.
Pushed by hpereiradacosta into branch 'frameworks-scratch'.

Added "Display window borders for maximized windows" option.

M  +4    -1    kwin/clients/oxygen/config/oxygenconfigwidget.cpp
M  +23   -16   kwin/clients/oxygen/config/ui/oxygenconfigurationui.ui
M  +1    -1    kwin/clients/oxygen/oxygenclient.h
M  +5    -0    kwin/clients/oxygen/oxygenconfigdata.kcfg

http://commits.kde.org/kde-workspace/8a0e134f6a2171856d163df66761922fdaad3557

so ... since I understood the problem right, and implemented a fix, 
I'm marking this bug as FIXED.
Feel free to reopen if I missed something.

Hi, I just found this bug (via Bug 299245) after I realized that the MoveResizeMaximizedWindows option is gone in kde 4.11.3 (using openSUSE 13.1).
My question: Does the fix of Huga Pereira Da Costa only affect the Oxygen decoration?  Background: My users are mainly using the Redmond decoration and I'm wondering if a separate bugreport is needed for each decoration.

any decoration that wishes to provide different borddrs depending on the window state will have to be patched, yes.
but the redmond decoration has been dropped years ago, you should not be using it at all.

> but the redmond decoration has been dropped years ago
Sad to hear this;  but thanks, so a bug report against this decoration would be in vain.
Is there a list of supported window decorations?  openSUSE delivers a lot and I don't want to post bug reports against unsupported ones.  (I searched kde-look.org, but I couldn't even find Oxygen there, so it's probably the wrong place).

oxygen
aurorae
--
laptop
b2

with the latter two on the edge for PW/2, ie. "notKDE5"

decos like
- bespin
- dekorator
- oxygen-transparent
- qtcurve
- skulpture
- smaragd

are maintained, but 3rd party.
Adding a conf key for the behavior to any deco of particular interest should be trivial (i think one or two of the legacy decos didn't invoke the moveResizeMaximizedWindows() hint, but apparently Redmond is not one of them)

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

I'm unclear if this is fixed or not! 

It _appears_ from reading this that the problem is whether or not borders appear on maximised windows, a patch has been committed (6 months ago) but this doesn't seem to be live in my distro (kubuntu).

Does this patch return then resize max'd windows functionality prior to 4.11.3?
Is this patch accepted into 4.11.3?
Is it reasonable to expect this fix to filter through to the mainstream distros?

Patch is in master -> "KDE 5"

It will allow you to have borders on maximized windows *for the oxygen decoration* what has nothing to do with the ability to resize the window.

But presumably borders on max'd windows is what I require to restore the prebious functionality (resize with left mouse button as for any other window)?

Will this be back ported to 4.11.3 or will it be necessary to jump between 4.10 and 5.xx to avoid this problem?

kde-workspace of SC4 is feature frozen.
No new features nor user visible strings can be added.

Eg. dekorator always had a distinct setting for this and i'm at hand not sure about aurorae theme handling.
Other than that, you'll have to ask your distro for adding this (untranslated) patch downstream or patch and compile the oxygen deco yourself.

(In reply to comment #20)
> Patch is in master -> "KDE 5"
> 
> It will allow you to have borders on maximized windows *for the oxygen
> decoration* what has nothing to do with the ability to resize the window.

The ability to resize maximized windows is the reason of this bug, as stated in the first comment. AFAIK the only condition needed to allow this is to have borders. Is this sufficient?

i'm not sure whether i understood your question, but the window can be resized by
- alt+right mousebutton
- alt+f3 menu
- a shortcut (to the alt+f3 entry)
- on the titlebar (depending on the deco)

ie. the core does not prevent resizing.

fwwi, kwin can also operate w/o any decoration (titlebar/frame) and decorations provided a borderless mode before even there was additional support through blind input windows.

iow: the decoration has nothing to do with the ability to move/resize a window at all. it's just a very popular approach, implemented differently by different decorations.

I think we are after letting max'd windows be resized in the same way as non max'd windows - in my case left mouse-button drag of the borders - I know in a small number of cases this is not desirable (shirt sleeves dragging on mouse pads) but for everyone else this is a nice feature. On my pre 4.11 machine I must have used this 20 time already today and it is very annoying not to have it.

I know this is marked as fixed because most people only care about re-sizing, but some people seriously want to see the window border.  It's been bugging me for the past few weeks that this option is gone.  Is there another issue open on the window border part of this?  And a related question:  Anyone happen to know what the package name is in Debian/Ubuntu so I can force my computer to downgrade that package?  Thanks!

@Jacob
This is marked as fixed, because in KF5 there is an oxygen option to "show the window border on maximized window", and because it does exactly this: you get the window borders drawn, and you can resize from them. 
This has not been backported to KDE4 for reasons explained above (string freeze).

the last comments probably added some confusion.
you'd have to downgrade kwin, but that's probably not a good idea.
alternatively you could just compile a patched version of oxygen(-tansparent) or use a windo decoration that ignores the maximization state (bunch of aurorae themes should and dekorator has an explicit setting)

well,
although one of the assignee for this bug, I am confused about what's confusing in my last comment. So maybe someone can explain it to me ...

not "the last comment" but "last comments", ie. the talk about resizing (before jacobs post)

Oh I didn't realize this feature has been moved to Window Decorations themes.  I'm currently using Plastik for my Window Decorations theme (I can't stand Oxygen.)  Hope they fix it for Plastik sometime soon too....

Created attachment 85095 [details]
patch to keep plastik borders on maximized windows

The "feature" never existed, just a bunch of deco authors (*cough* including myself *cough*) "abused" a behavioral setting to implicitly change the border style (reasoned by that if you cannot resize the window anyway, there would be no point in showing borders)

Plastik would require a different bugreport.
Since it's however a QML decoration, you can patch it downstream (it's just a textfile)

-> See attached patch.
Applies to /usr/share/apps/kwin/decorations/kwin4_decoration_qml_plastik/contents/ui/main.qml
** warning: any update will naturally override the patch, but you could make a local copy in ~/.kde/share/apps/kwin

Thank you so much Thomas!  After playing around with that main.qml file, I've gotten it so that it mostly looks how I like it.

  One thing I can't figure out:  When I have a window Maximized,  the window borders are no longer draggable (I cannot resize with mouse dragging the border).  I don't see a way to fix that in the main.qml file.  Is there another qml file somewhere I can change to fix this?

That would requirece changes to kde-workspace/kwin/clients/aurorae/src/aurorae.cpp - either ::isMaximized() or ::mousePosition()
(ie. also recompilation of the deco plugin would be required)

I've just upgraded to Debian Jessie (KDE4.14.2)  and there is no good way to resize a maximized window. By trying to drag, I just get a borderless, screen-sized, unresizable window, except if I go to (window menu) -> more actions -> resize, then I can resize the lower right edge.

Is this due to the old version / will downloading the latest KDE4 fix this regression?

Alt + RMB, oxygen deco setting should be available.

The alt, meta etc. modifiers first didn't seem to work, but maybe I had the wrong theme.

Now I get a classic-maximized-and-resizable window by Meta-RMB (I reassigned it from Alt).

I can't find a setting on oxygene (and I don't think this should be part of each decoration, ¢¢), but I guess it's OK for now. Thank you.

http://wstaw.org/m/2015/06/17/plasma-desktopM18600.png
(I know the widget style I use is breeze, and so the window decoration, but the shown dialog really is *oxygen* decoration config)

That option is missing in Debian Jessie /  KDE4.14.2.

http://7eggert.selfhost.bz/tmp/kde4.14.2-oxygene.png