From kwin Fri Aug 26 13:01:58 2011 From: =?utf-8?q?Thomas_L=C3=BCbking?= Date: Fri, 26 Aug 2011 13:01:58 +0000 To: kwin Subject: Re: Review Request: Implement Decoration Policy Message-Id: <20110826130158.19319.78677 () vidsolbach ! de> X-MARC-Message: https://marc.info/?l=kwin&m=131436376121262 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============7181103558298588261==" --===============7181103558298588261== Content-Type: multipart/alternative; boundary="===============0212565432098546499==" --===============0212565432098546499== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----------------------------------------------------------- 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 bein= g 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 r= egard (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 _ne= t_wm hint then) but if it's only about chromium or stupid CSD is back on th= e tapet (is it?), that's a social problem but iff we /have/ to fix it techn= ically, there're better ways. Otherwise you can expect a "chromium broken on KDE" bugreport quite soon an= d chromium devs to be smart enough to (surprise ;-) google or just check ho= w 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 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 - wha= t 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, sor= ry. = 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 en= ough) and not indirectly after the next shape change (check keep above, sta= rt 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 w= ants 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=C3=A4=C3=9Flin 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.o= rg/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 remove= d) > = > 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. A= nd it's still possible to hack around through the way how Qt Dock widgets r= equest 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 i= t 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 > = > --===============0212565432098546499== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
This is an automatically generated e-mail. To reply, visit: http://git.revie= wboard.kde.org/r/102434/ 

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

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

Otherwise you can expect a "chromium broken on KDE" bugreport qui=
te soon and chromium devs to be smart enough to (surprise ;-) google or jus=
t 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 (Diff revision 1) 
void Client::checkNoBorder()
772 
        if (!app_noborder) {
 771 
        // they should have=
 decorations - except for kept above
 
Can you please elaborate on this?
What makes keep_above windows special against other shaped ones in this reg=
ard?

It sounds very much like a special case* and has a solution to me - what wo=
uld mean that -motif or not- we actually need either a hint for this or &qu=
ot;smarter" handling of shaped clients or fix the clients, but i do no=
t see any reason to treat them different just because of the keep_above fla=
g, 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 en=
ough) and not indirectly after the next shape change (check keep above, sta=
rt resize -> deco gone. this looks like a bug to the user)

-------------
* /cough/ yakuake /cough/ which is btw. *not* shaped here (square theme ima=
ges), *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 August 25th, 2011, 7:05 p.m., Martin Gr=C3=A4=C3=9Flin wrote:

Review request for kwin and Plasma.
By Martin Gr=C3=A4=C3=9Flin.

Updated Aug. 25, 2011, 7:05 p.m.

Descripti= on 

Implements the decoration policy as described here: http://t=
echbase.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 i=
f you set Chromium to keep above and resize it, the decoration are removed)

This "breaks" Chromium and xeyes with +style. It is still possibl=
e 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 Do=
ck widgets request no deco. This is something I did not change, if applicat=
ion authors find it, I would probably change it as it is marked as a non-st=
andard, non-documented feature ;-)

I would suggest to commit and try it at least in master and see whether it =
unleashes hell upon us :-)

Testing <= /h1> 
* 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

Diffs=

  • kwin/client.h (66b9c46)
  • kwin/client.cpp (a6f0618)

View Diff
--===============0212565432098546499==-- --===============7181103558298588261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kwin mailing list kwin@kde.org https://mail.kde.org/mailman/listinfo/kwin --===============7181103558298588261==--