Re: Proposal: Add a window state for "undecorated" windows
"Jasper St. Pierre" <[email protected]> Thu, 20 Feb 2014 10:23:41 -0500
| Newsgroups | gmane.comp.gnome.wm-spec |
|---|---|
| Message-ID | <CAA0H+QR8_yQhV+9+TOd3VmhGbsvn4sRJrbFEt1CcOKHw=h_=wA@mail.gmail.com> |
--===============4667807840339729912== Content-Type: multipart/alternative; boundary=089e0115ebf41d5d7004f2d81797 --089e0115ebf41d5d7004f2d81797 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There's a bunch of open questions about this state. If a window is CSD-drawn, does it include drop-shadows, or should the compositor draw drop-shadows? If the compositor should still draw drop shadows, what happens if the client uses ARGB32 to get rounded corners, how does the compositor efficiently calculate a shadow? Does it take the alpha channel of the composited pixmap and do a blur on the GPU (your rounded corners look fine, but your transparent terminal is a bit too dark)? If the client draws the shadow, how does the WM decide where the boundaries of the window are for snapping / maximization? It would be awkward to drag the window to the left and see an invisible shadow edge tile. To solve this I proposed a client-set _NET_WM_FRAME_EXTENTS property on this list a little while back, but didn't hear any response. On Thu, Feb 20, 2014 at 2:23 AM, Carsten Haitzler <[email protected]>wro= te: > On Thu, 20 Feb 2014 07:37:59 +0100 Martin Gr=E4=DFlin <[email protected]= > > said: > > we're in the middle of release stabilization for efl1.9 ... so kind of > busy. :) > > > Hi, > > > > this is now two weeks without any reply :-( It would be really great to > get > > some feedback. Our feature freeze for both Frameworks 5 and KWin 5 is > > approaching... > > > > Cheers > > Martin > > > > On Wednesday 05 February 2014 11:39:42 Martin Gr=E4=DFlin wrote: > > > Hi, > > > > > > as it's getting more common to do client side window decorations and > this > > > part is not standardized at all [1], I want to suggest that we add a > > > distinct state for this (_NET_WM_STATE_UNDECORATED). Please see > attached > > > patch to the spec. And please propose any improvements to the wording= . > > > > > > If we get this in, I suggest to update the toolkits to use this in > addition > > > to the Motif hint. I will take care of changing Qt of course (which > btw. > > > already uses a KWin-specific hint). With other toolkits I'm not > familiar > > > enough to try to change them :-) > > > > > > Looking forward to your comments. > > > > > > Best Regards > > > Martin Gr=E4=DFlin > > > > > > [1] Just last week we got one bug report about Motif handling being > broken > > > in KWin, and one "bug report" about a toolkit abusing > > > _NET_WM_WINDOW_TYPE_SPLASH for undecorated windows. > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > _______________________________________________ > wm-spec-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/wm-spec-list > --=20 Jasper --089e0115ebf41d5d7004f2d81797 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div>There's a bunch of open questions about= this state. If a window is CSD-drawn, does it include drop-shadows, or sho= uld the compositor draw drop-shadows?<br><br></div>If the compositor should= still draw drop shadows, what happens if the client uses ARGB32 to get rou= nded corners, how does the compositor efficiently calculate a shadow? Does = it take the alpha channel of the composited pixmap and do a blur on the GPU= (your rounded corners look fine, but your transparent terminal is a bit to= o dark)?<br> <br></div>If the client draws the shadow, how does the WM decide where the = boundaries of the window are for snapping / maximization? It would be awkwa= rd to drag the window to the left and see an invisible shadow edge tile.<br= > <br></div>To solve this I proposed a client-set _NET_WM_FRAME_EXTENTS prope= rty on this list a little while back, but didn't hear any response.<br>= </div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu,= Feb 20, 2014 at 2:23 AM, Carsten Haitzler <span dir=3D"ltr"><<a href=3D= "mailto:[email protected]" target=3D"_blank">[email protected]</a>>= ;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">On Thu, 20 Feb 2014 07:37:59 +0100 Martin Gr= =E4=DFlin <<a href=3D"mailto:[email protected]">[email protected]</a>&= gt; said:<br> <br> we're in the middle of release stabilization for efl1.9 ... so kind of = busy. :)<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> > Hi,<br> ><br> > this is now two weeks without any reply :-( It would be really great t= o get<br> > some feedback. Our feature freeze for both Frameworks 5 and KWin 5 is<= br> > approaching...<br> ><br> > Cheers<br> > Martin<br> ><br> > On Wednesday 05 February 2014 11:39:42 Martin Gr=E4=DFlin wrote:<br> > > Hi,<br> > ><br> > > as it's getting more common to do client side window decorati= ons and this<br> > > part is not standardized at all [1], I want to suggest that we ad= d a<br> > > distinct state for this (_NET_WM_STATE_UNDECORATED). Please see a= ttached<br> > > patch to the spec. And please propose any improvements to the wor= ding.<br> > ><br> > > If we get this in, I suggest to update the toolkits to use this i= n addition<br> > > to the Motif hint. I will take care of changing Qt of course (whi= ch btw.<br> > > already uses a KWin-specific hint). With other toolkits I'm n= ot familiar<br> > > enough to try to change them :-)<br> > ><br> > > Looking forward to your comments.<br> > ><br> > > Best Regards<br> > > Martin Gr=E4=DFlin<br> > ><br> > > [1] Just last week we got one bug report about Motif handling bei= ng broken<br> > > in KWin, and one "bug report" about a toolkit abusing<b= r> > > _NET_WM_WINDOW_TYPE_SPLASH for undecorated windows.<br> <br> <br> </div></div><span class=3D"HOEnZb"><font color=3D"#888888">--<br> ------------- Codito, ergo sum - "I code, therefore I am" -------= -------<br> The Rasterman (Carsten Haitzler) =A0 =A0<a href=3D"mailto:raster@rasterman.= com">[email protected]</a><br> <br> _______________________________________________<br> wm-spec-list mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> <a href=3D"https://mail.gnome.org/mailman/listinfo/wm-spec-list" target=3D"= _blank">https://mail.gnome.org/mailman/listinfo/wm-spec-list</a><br> </font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>=A0 Jaspe= r<br> </div> --089e0115ebf41d5d7004f2d81797-- --===============4667807840339729912== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ wm-spec-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/wm-spec-list --===============4667807840339729912==--