[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: Review Request 103948: Remove "Display borders on maximized windows"
From:       XI <xizard () free ! fr>
Date:       2013-02-25 16:31:22
Message-ID: 512B91DA.4090104 () free ! fr
[Download RAW message or body]

Thomas Lübking wrote:
> 
> This is an automatically generated e-mail. To reply, visit: 
> http://git.reviewboard.kde.org/r/103948/
> 
> 
> On February 25th, 2013, 12:53 p.m. UTC, *Martin Gräßlin* wrote:
> 
> kwin/libkdecorations/kdecorationbridge.h
> <http://git.reviewboard.kde.org/r/103948/diff/4/?file=115266#file115266line51>
> (Diff revision 4)
> 
> class KDecorationBridge : public KDecorationDefines
> 
> 	
> 
> 	51 	
> 
> virtual QuickTileMode quickTileMode() const = 0;
> 
> do we need to create a KDecorationBridge2 or is it safe to do non-ABI changes in \
> the bridge since Compiz is no issue any more? 
> Towards the decoration plugins this is safe.
> 
> Whether this is gonna introduce an ABI break for the kde4 decorator for compiz \
> depends on whether it actually includes this header. If yes, it has to implement \
> the new virtual and previously compiled versions linking libkdecorations will get \
> an ABI crash for this. 
> If the decorator brings its own deco interface implementation, there's no problem.
> 
> I guess i'll have to lookup the decorator sources, but that would be a quite crap \
> situation because the decobridge would exist for no more any reason (being the glue \
> between the core and the deco API) 
> 
> - Thomas
> 
> 
> On February 24th, 2013, 10:36 p.m. UTC, Thomas Lübking wrote:
> 
> Review request for kwin, Martin Gräßlin and Hugo Pereira Da Costa.
> By Thomas Lübking.
> 
> /Updated Feb. 24, 2013, 10:36 p.m./
> 
> 
> Description
> 
> Actually the only thing the patch does not is what's stated in the summary ;-)
> 
> - 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. (I've a sample implementation in local \
> Bespin as inspiration for other decos) 
> Ratio:
> It's simply not possible to perform the specialstate snapping in the core.
> Either the decoration gets clipped, but that also clips titlebar buttons -> fail
> Or the decoration gets resized "under the hood" (ie. we override border_* after \
> obtaining it) but that has bad visual impact on decorations like plastik (where the \
> client visually overflows the border, it clearly looks like the client is patched \
> onto the deco) -> fail 
> -> the deco is informed about those special states and can drop some of its borders \
> or not. Should be no major problem for oxygen (since it blends into clients anyway) \
> but i've not checked how to make use of that in aurorae (or even its client code) 
> 
> Testing
> 
> With the (still local) changes to bespin I get nice partial clipping for quicktiled \
> (or partially maximized) windows. Helped me to clean up some bespin deco code as \
> well =) 
> *Bugs: * 299245 <http://bugs.kde.org/show_bug.cgi?id=299245>
> 
> 
> Diffs
> 
> * kwin/workspace.h (e033ac9)
> * kwin/libkdecorations/kdecoration_p.cpp (5b54369)
> * kwin/libkdecorations/kdecorationbridge.h (2cb36c9)
> * kwin/libkwineffects/kwinglobals.h (dba4324)
> * kwin/kcmkwin/kwindecoration/preview.cpp (94aacba)
> * kwin/libkdecorations/kdecoration.h (2c20767)
> * kwin/libkdecorations/kdecoration.cpp (7ccbdb6)
> * kwin/libkdecorations/kdecoration_p.h (71833cd)
> * kwin/bridge.h (35efc90)
> * kwin/bridge.cpp (31d285e)
> * kwin/client.h (0c9d1d2)
> * kwin/client.cpp (f2338d4)
> * kwin/geometry.cpp (372a4c8)
> * kwin/kcmkwin/kwindecoration/preview.h (420e302)
> 
> View Diff <http://git.reviewboard.kde.org/r/103948/diff/>
> 
> 
Hi,

Sorry to intrude in the discussion, but I am still very attentive to 
changes that may affect multiple screens setups, and I prefer to ask 
before it is too late.

As far as I understand, the option "Allow to move maximized windows" 
will disappear, but, we won't loose the ability to move maximized 
windows, right ? (that's fine: this feature is really important, 
especially on multiple-screens setups).

Could you just confirm that the maximized windows will still be movable 
using the [ALT] + "mouse left click" combination too, as it was before ?


P.S. as for KDE3 (3.4), not checking the option "Allow to move maximized 
windows" totally prevents to move a maximized window.

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin


[prev in list] [next in list] [prev in thread] [next in thread]