> On July 1, 2014, 6:04 p.m., Hugo Pereira Da Costa wrote: > > @Martin > > yes we can (tm). But then I'll get complains (got some already in the past) > > from people using oxygen-gtk on gnome (or other DEs). > > so there needs to be a way to communicate. (or as thomas suggested, some > > systemwide gtk.css, hopping that it would override the widget's style, > > which in turn would have the advantage to work with any gtk style). > > > > On a similar topic, the same problem happened with latest (gtk3- 3.13.3), > > which also force shadows on menus. > > This in KDE result in double shadows (ugly): the one passed to kwin from > > oxygen-gtk (via KDE_NET_WM_SHADOW) and the one from gtk. > > This is now fixed in oxygen-gtk (next release) by checking the > > NET_SUPPORTED atom on rootWindow and install either the GTK shadow or the > > kwin shadow, depending on whether the above atom is found in the supported > > list or not) > > Maybe we could do the same (e.g. KDE_NET_WM_SUPPORTS_CSD) for the CSD > > shadows. > > Thomas Lübking wrote: > meh. > > "export GTK_THEME=kde" makes gtk3 interpret global kde/settings.ini and > global & local kde/gtk.css > > a) that doesn't help us, since we'd need to invoke a local > kde/settings.ini > b) placing eg. "gtk-theme-name = Awaita" into (global) kde/settings.ini > traps gtk in infinite recursion on starting any application > > W/o cooperation from gtk+, we'd have to manipulate > ~/.config/gtk-3.0/gtk.css on login and logout - risking to leave it "broken" > for GNOME logins (if KDE/X11 crashes and the user logs into GNOME next) > > Ideal solution could be: GTK_SESSION_CSS=kde -> ~/.config/gtk-3.0/kde.css > > Martin Gräßlin wrote: > > But then I'll get complains (got some already in the past) from people > using oxygen-gtk on gnome > > I think we can ignore that. GNOME/GTK only cares about how it looks on > GNOME, so we can do the same. If users complain point them to the bug report > that shadows are included in the window frame and that this has only been > done to workaround this bug with KWin. If they want the problem fixed, they > should complain to GTK devs.
> GNOME/GTK only cares about how it looks on GNOME, so we can do the same humbly disagree, if can be avoided. At worst I can make the disabling of the shadows depend on the root window support for KDE_NET_WM_SHADOW (can be done right now, and is easy) Ultimately, if NET_WM folks agree on a "NET_WM_SUPPORTS_CSD" that gnome would set and not kde, I would use this of course (and ideally, gtk would do the shadow disabling by itself, in which case I'd simply remove the code) - Hugo ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119062/#review61412 ----------------------------------------------------------- On July 1, 2014, 2:53 p.m., Martin Gräßlin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119062/ > ----------------------------------------------------------- > > (Updated July 1, 2014, 2:53 p.m.) > > > Review request for kwin, Plasma and Hugo Pereira Da Costa. > > > Repository: kwin > > > Description > ------- > > Add a script to enforce window decorations for GTK windows > > This is going to be a controversal change. It enforces KWin decorations > on all client side decorated windows from GTK+. Unfortunately we are > caught between a rock and a hard place. Keeping the status quo means > having broken windows and a more or less broken window manager due to > GTK+ including the shadow in the windows. This is no solution. > Enforcing server side decorations visually breaks the windows. This is > also no solution. So why do it? > > It's our task to provide the best possible user experience and KWin is > a window manager which has always done great efforts to fix misbehaving > windows. One can think of the focus stealing prevention, the window rules > and lately the scripts. The best possible window management experience is > our aim. This means we cannot leave the users with the broken windows > from GTK. > > The issues we noticed were reported to GTK+ about 2 months ago and we are > working on improving the situation. Unfortunately several issues are not > yet addressed and others will only be addressed in the next GTK+ release. > We are working on improving the NETWM spec (see [1]) to ensure that the > client side decorated windows are not in a broken state. This means the > enforcment is a temporary solution and will be re-evaluated with the next > GTK release. I would prefer to not have to do such a change, if some of > the bugs were fixed or GTK+ would not use client-side-decos on wms not > yet supporting those all of this would be a no issue. > > For a complete list of the problems caused by GTK's decos see bug [2] and > the linked bug reports from there. > > The change is done in a least inversive way in KWin. We just check for > the property _GTK_FRAME_EXTENTS and create a Q_PROPERTY in Client for it. > If we add support for the frame extents in future we would also need > this. So it's not a change just for enforcing the decoration. > > The actual enforcing is done through a KWin script so users can still > disable it. > > [1] https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html > [2] https://bugzilla.gnome.org/show_bug.cgi?id=729721 > > > Diffs > ----- > > atoms.h d52223504a78909efa7c18d7e96feebec8f3cb21 > atoms.cpp 576e85f0c0e865721a1b513af9d1ad1bfdb580ea > client.h 8e41e203d01b41fdd918c35fb3dc9353d7e41774 > client.cpp 608e6a8435ad9bc7d86ff813038023648e6b7b1e > events.cpp 514eecc69d81136d8975155e0fbb3fef39d3a346 > manage.cpp fbdf19570418e412cdadb54f36cf94e5da24db4f > scripts/CMakeLists.txt feeb288250407f5f2bd4b3ea878f21640ebb7d20 > scripts/enforcedeco/contents/code/main.js PRE-CREATION > scripts/enforcedeco/metadata.desktop PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/119062/diff/ > > > Testing > ------- > > > Thanks, > > Martin Gräßlin > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
