----------------------------------------------------------- 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
