Review Request: Implement Decoration Policy

[Thomas Lübking]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102434/#review6024
-----------------------------------------------------------


And if you remove _KDE_NET_WM_WINDOW_TYPE_OVERRIDE then what? Qt docks being decorated twice just like kruler once and yakuake - but only if there's a rectangular shape?
Until then _every_ Qt application will remain completely unchaged in this regard (since the Qt::FramelessWindowHint does set the property)

If it's about getting rid of motif hints, that's fine (we'll add a real _net_wm hint then) but if it's only about chromium or stupid CSD is back on the tapet (is it?), that's a social problem but iff we /have/ to fix it technically, there're better ways.

Otherwise you can expect a "chromium broken on KDE" bugreport quite soon and chromium devs to be smart enough to (surprise ;-) google or just check how KDE apps do it and then add this property as well to their next release (since they're probably not stupid)

Sorry, I don't want to be mean or demotivating, but in the latter case this looks a bit like a quick shot to me - and I do not think it would work at all.


kwin/client.cpp
<http://git.reviewboard.kde.org/r/102434/#comment5310>

    Can you please elaborate on this?
    What makes keep_above windows special against other shaped ones in this regard?
    
    It sounds very much like a special case* and has a solution to me - what would mean that -motif or not- we actually need either a hint for this or "smarter" handling of shaped clients or fix the clients, but i do not see any reason to treat them different just because of the keep_above flag, sorry.
    
    Also i object the way it's done.
    Iff the  decoration (of shaped clients) depends on the keep_above state it should change whenever this state changes (what's actually confusing enough) and not indirectly after the next shape change (check keep above, start resize -> deco gone. this looks like a bug to the user)
    
    -------------
    * /cough/ yakuake /cough/ which is btw. *not* shaped here (square theme images), *does* set _KDE_NET_WM_WINDOW_TYPE_OVERRIDE anyway and actually wants to be an override-redirect window just like the Qt docks probably want to be. (meaning they have to do stacking and focus by themselves)


- Thomas


On Aug. 25, 2011, 7:05 p.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102434/
> -----------------------------------------------------------
> 
> (Updated Aug. 25, 2011, 7:05 p.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Summary
> -------
> 
> Implements the decoration policy as described here: http://techbase.kde.org/Projects/KWin/Window_Decoration_Policy
> 
> The following changes are performed:
> * remove support for motif_nodeco hint
> * styled windows get window decorations unless they are keep above (means if you set Chromium to keep above and resize it, the decoration are removed)
> 
> This "breaks" Chromium and xeyes with +style. It is still possible to use the normal no-border mode either through Alt+F3 settings or window rule. And it's still possible to hack around through the way how Qt Dock widgets request no deco. This is something I did not change, if application authors find it, I would probably change it as it is marked as a non-standard, non-documented feature ;-)
> 
> I would suggest to commit and try it at least in master and see whether it unleashes hell upon us :-)
> 
> 
> Diffs
> -----
> 
>   kwin/client.h 66b9c46 
>   kwin/client.cpp a6f0618 
> 
> Diff: http://git.reviewboard.kde.org/r/102434/diff
> 
> 
> Testing
> -------
> 
> * Yakuake still is without deco
> * All Plasma windows are without deco
> * Qt Dock widgets are without deco
> * KRuler is without deco
> * Chromium is forced to have deco
> 
> 
> Thanks,
> 
> Martin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20110826/9ae759d6/attachment.html>