Bug 262543 - Respect title bar button setting in Present Window Grid
Summary: Respect title bar button setting in Present Window Grid
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-window-management (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-08 17:15 UTC by Kai Uwe Broulik
Modified: 2011-09-23 15:53 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kai Uwe Broulik 2011-01-08 17:15:38 UTC
Version:           unspecified (using KDE 4.5.95) 
OS:                Linux

I tend to have my title bar buttons (close, maximize, minimize) on the left side. In KDE 4.6 you have the close button to close a window in the Present Window Grid. It is always on the right side which is inconvenient to me. It should not directly respect the position of close button position but look whether it is left or right of the title bar setting (see the dialog) and then position that button accordingly.

Reproducible: Always
Comment 1 Martin Flöser 2011-01-08 18:56:40 UTC
This is hardly possible to implement, because KWin core does not know where the button is positioned. This is internal to the decoration and cannot be changed without compatibility to existing decorations.
Comment 2 Kai Uwe Broulik 2011-01-08 19:12:20 UTC
But why can't it know? I manually set the positions. I can understand that it may not know the position(s) predefined but why shouldn't it be able of gathering custom position information?
Comment 3 Thomas Lübking 2011-01-08 19:40:50 UTC
The setting is known, it's just that /theoretically/ the client can simply ignore those settings and hardcode button positions or (for themable ones) read them out of its own config file.

I however have to agree that the at least the configured setting should be honored. Having buttons on the "wrong" side is pretty nasty.

Maybe we could just wrap "T options()->f()" to "QVariant effects->kwinOption(enum)", where the effectshandler "kwinOption" is just a switch/case for the (not exported) Options functions?
This way the effects can get acces to (a limited set of) the kwin core settings...
Comment 4 Martin Flöser 2011-01-08 19:48:46 UTC
On Saturday 08 January 2011 19:40:51 Thomas Lübking wrote:
> The setting is known, it's just that /theoretically/ the
> client can simply ignore those settings and hardcode button positions or
> (for themable ones) read them out of its own config file.
When writing my answer I was particularly thinking of Aurorae which does not 
provide any way to get the default button position.
> 
> I however have to agree that the at least the configured setting should be
> honored. Having buttons on the "wrong" side is pretty nasty.
The question is: what are the users using? Do they change the position at all 
and by that is it worth to invest time into it?
> 
> Maybe we could just wrap "T options()->f()" to "QVariant
> effects->kwinOption(enum)", where the effectshandler "kwinOption" is just a
> switch/case for the (not exported) Options functions?
> This way the effects can get acces to (a limited set of) the kwin core
> settings...
That could work and in general I'm not opposed to have more access to core 
options in effects. It showed to be rather useful in the past (resize, 
geometry tip...).
Comment 5 Kai Uwe Broulik 2011-01-08 20:11:06 UTC
Maybe transitional there could be an option for the position of the close button in present window grid effects settings (and an option to hide it altogether)
Comment 6 Thomas Lübking 2011-08-09 21:48:58 UTC
Git commit 4e0f11c62bdbad58de2cf038640bdff2ea396af2 by Thomas Lübking.
Committed on 25/04/2011 at 17:04.
Pushed by luebking into branch 'master'.

fix close button side for present windows effect
BUG: 262543

pint desktop as background when including desktop in switcher
BUG: 262137

zoom windows as hover/selection indicaton (1/8 of the screen or 105%)
BUG: 215348
CCBUG: 175521

no closer on "show desktop" desktop
show closer immediately but have it disabled for a short time to allow the user realize it

REVIEW: 101318

M  +99   -27   kwin/effects/presentwindows/presentwindows.cpp
M  +9    -0    kwin/workspace.h
M  +15   -0    kwin/libkdecorations/kdecorationfactory.h
M  +11   -0    kwin/effects.cpp
M  +4    -0    kwin/libkwineffects/kwinglobals.h
M  +2    -1    kwin/libkwineffects/kwineffects.h
M  +6    -3    kwin/effects/presentwindows/presentwindows.h
M  +2    -0    kwin/effects.h
M  +22   -1    kwin/libkdecorations/kdecorationfactory.cpp

http://commits.kde.org/kde-workspace/4e0f11c62bdbad58de2cf038640bdff2ea396af2
Comment 7 Marco Martin 2011-09-23 15:53:24 UTC
Git commit dbe57396853f9995a9b3d7ab5d55f88fc730512a by Marco Martin.
Committed on 23/09/2011 at 17:55.
Pushed by mart into branch 'active-development/screenlocker'.

fix close button side for present windows effect
BUG: 262543

pint desktop as background when including desktop in switcher
BUG: 262137

zoom windows as hover/selection indicaton (1/8 of the screen or 105%)
BUG: 215348
CCBUG: 175521

no closer on "show desktop" desktop
show closer immediately but have it disabled for a short time to allow the user realize it

REVIEW: 101318

Conflicts:

	kwin/effects.h

M  +11   -0    kwin/effects.cpp
M  +99   -27   kwin/effects/presentwindows/presentwindows.cpp
M  +6    -3    kwin/effects/presentwindows/presentwindows.h
M  +22   -1    kwin/libkdecorations/kdecorationfactory.cpp
M  +15   -0    kwin/libkdecorations/kdecorationfactory.h
M  +2    -1    kwin/libkwineffects/kwineffects.h
M  +4    -0    kwin/libkwineffects/kwinglobals.h
M  +9    -0    kwin/workspace.h

http://commits.kde.org/kde-workspace/dbe57396853f9995a9b3d7ab5d55f88fc730512a