<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="https://git.reviewboard.kde.org/r/119062/">https://git.reviewboard.kde.org/r/119062/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On July 1st, 2014, 8:04 p.m. CEST, <b>Hugo Pereira Da Costa</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">@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. </pre>
 </blockquote>




 <p>On July 1st, 2014, 9:04 p.m. CEST, <b>Thomas Lübking</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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</pre>
 </blockquote>








</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> 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.</pre>
<br />










<p>- Martin</p>


<br />
<p>On July 1st, 2014, 4:53 p.m. CEST, Martin Gräßlin wrote:</p>








<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for kwin, Plasma and Hugo Pereira Da Costa.</div>
<div>By Martin Gräßlin.</div>


<p style="color: grey;"><i>Updated July 1, 2014, 4:53 p.m.</i></p>









<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt;">Repository: </b>
kwin
</div>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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</pre>
  </td>
 </tr>
</table>



<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>atoms.h <span style="color: grey">(d52223504a78909efa7c18d7e96feebec8f3cb21)</span></li>

 <li>atoms.cpp <span style="color: grey">(576e85f0c0e865721a1b513af9d1ad1bfdb580ea)</span></li>

 <li>client.h <span style="color: grey">(8e41e203d01b41fdd918c35fb3dc9353d7e41774)</span></li>

 <li>client.cpp <span style="color: grey">(608e6a8435ad9bc7d86ff813038023648e6b7b1e)</span></li>

 <li>events.cpp <span style="color: grey">(514eecc69d81136d8975155e0fbb3fef39d3a346)</span></li>

 <li>manage.cpp <span style="color: grey">(fbdf19570418e412cdadb54f36cf94e5da24db4f)</span></li>

 <li>scripts/CMakeLists.txt <span style="color: grey">(feeb288250407f5f2bd4b3ea878f21640ebb7d20)</span></li>

 <li>scripts/enforcedeco/contents/code/main.js <span style="color: grey">(PRE-CREATION)</span></li>

 <li>scripts/enforcedeco/metadata.desktop <span style="color: grey">(PRE-CREATION)</span></li>

</ul>

<p><a href="https://git.reviewboard.kde.org/r/119062/diff/" style="margin-left: 3em;">View Diff</a></p>







  </td>
 </tr>
</table>








  </div>
 </body>
</html>