Re: Improving work areas with multiple monitors
Alberts Muktupāvels via wm-spec-list <[email protected]> Thu, 16 Jan 2020 14:36:04 +0200
| Newsgroups | gmane.comp.gnome.wm-spec |
|---|---|
| Message-ID | <CAKX6tkW6remdQDjG5SUwaArqAJTQHpY6esjG-Oq50iZ1Hkq0GQ@mail.gmail.com> |
--===============8946103020148987047== Content-Type: multipart/alternative; boundary="00000000000037259d059c4112cd" --00000000000037259d059c4112cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I have created merge request for this: https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/22 Any objections? On Mon, Dec 31, 2018 at 1:48 PM Alberts Muktup=C4=81vels < [email protected]> wrote: > On Mon, Dec 31, 2018 at 10:44 AM Martin Fl=C3=B6ser <[email protected]> = wrote: > >> Am 2018-12-27 22:22, schrieb Alberts Muktup=C4=81vels via wm-spec-list: >> > Hi, >> > >> > I would like to improve work area situation with multiple monitors. >> > Before writing patches I would like to hear what you think about my >> > idea. >> > >> > First I think there should be new property for struts because existing >> > properties can not be used to set struts on edges between two >> > monitors. New property could be named _NET_WM_STRUT_AREA and used to >> > define rectangular area (x, y, width and height) that should be >> > excluded from work area. This property will need to follow at least >> > two rules: >> > - at least one edge of area must match with monitor edge. The window >> > manager must ignore strut if it is not placed at monitor edge. >> > - if strut appears on edge between two monitors it should be ignored >> > when calculating _NET_WORKAREA to ensure backward compatibility. >> >> sounds fine to me. >> >> As a note: in KWin we allow panels on shared edges to set a strut with >> the existing protocol. We just decided that a strut is not allowed to >> cover a complete screen. Technically it's a violation of the current >> protocol, but might be a better idea than introducing yet another >> property. >> > > This property probably make sense only with new workarea... For example i= f > we have left and right monitors put side by side. How do you set strut fo= r > panel / dock that is placed on right monitors left edge? And more > importantly - how would look generated work area? It has to ignore strut = or > one monitor is excluded from work area. > > It could be a simple textual addition like: "Struts covering a monitor >> completely are ignored for that monitor" >> >> > >> > Next and more important part is new property to allow set work areas >> > for multiple monitors. Currently I am thinking it could be >> > _NET_WORKAREAS_Dn where n is desktop number. For example if >> > _NET_NUMBER_OF_DESKTOPS is set to 3 then there must be >> > _NET_WORKAREAS_D0, _NET_WORKAREAS_D1 and _NET_WORKAREAS_D2 properties. >> > >> > Property would have one or multiple work areas: >> > _NET_WORKAREAS_Dn, x, y, width, height CARDINAL[][4]/32 >> >> This property I do not understand. What is the area of x, y, width, >> height? Why per desktop? >> > > Per desktop? Because existing _NET_WORKAREA property have work areas for > each desktop? If you have one desktop you have one rectangle with work > area, if you have 5 desktops it will contain 5 rectangles. To speak truth= I > don't know if you really can have different work areas for different > desktops and/or if anyone support/use that... I don't want to introduce > more changes then needed. > > x, y, width, height is work area rectangle. Property format basically is > same as _NET_WORKAREA, except multiple rectangles are not for desktops, b= ut > for monitors. For example two 1280x1024 side by side monitors with 24px > panel on right monitor left edge would produce following property - > _NET_WORKAREAS_D0, [0, 0, 1280, 1024], [1304, 0, 1256, 1024]. And if you > have more then one desktop there would be _NET_WORKAREAS_D1, > _NET_WORKAREAS_D2... properties. That way you can read property for curre= nt > desktop - _NET_WORKAREAS_D{_NET_CURRENT_DESKTOP}. > > Did I make it more understandable or still not clear enough? > > > >> > Window managers adding support for this would need to add >> > _NET_WORKAREAS hint to _NET_SUPPORTED. >> >> And also for the new strut property. >> > > Right. I mention only work area hint because I have not seen that panels = / > docks would check if property is supported. They just set both properties > and window managers first tries to read _NET_WM_STRUT_PARTIAL and then > _NET_WM_STRUT. > > >> > >> > Does anyone see reasons why this would not work and/or have better >> > suggestions? >> >> As a note: KWin is feature frozen for X11. This means we will not add >> support for this. I don't know whether other window managers are still >> interested in extending the protocol. For me it's a thing which has been >> broken for ages and we found a workaround for the problem. I don't see a >> need to fix the "legacy" protocol. >> > > I guess it is fine, but it should not be reason to not update/improve > spec, right? > > For example, how do you workaround following bug?: > https://bugreports.qt.io/browse/QTBUG-60513 > > Anyway, I am not after workarounds... Right now it does not look like big > and complicated changes so I don't see why would this be rejected unless > someone sees big problems that I have not thought about. > > For example metacity based window managers already have work areas for > each monitor - all it needs is to make it available to clients / toolkits= . > It would be enough to allow toolkits to fix mentioned bug. And adding > _NET_WM_STRUT_AREA would make it possible to correctly calculate work are= as > for many configurations. > > I plan to write patches for metacity, mutter, gtk and maybe also for > compiz. > > -- > Alberts Muktup=C4=81vels > --=20 Alberts Muktup=C4=81vels --00000000000037259d059c4112cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I have created merge req= uest for this:</div><div><a href=3D"https://gitlab.freedesktop.org/xdg/xdg-= specs/merge_requests/22">https://gitlab.freedesktop.org/xdg/xdg-specs/merge= _requests/22</a></div><div><br></div><div>Any objections?<br></div><div><br= ></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Mon, Dec 31, 2018 at 1:48 PM Alberts Muktup=C4=81vels <<a href= =3D"mailto:[email protected]" target=3D"_blank">alberts.muktupa= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd= ing-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir= =3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mo= n, Dec 31, 2018 at 10:44 AM Martin Fl=C3=B6ser <<a href=3D"mailto:mgraes= [email protected]" target=3D"_blank">[email protected]</a>> wrote:<br></div>= <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex">Am 2018-12-27 22:22, schr= ieb Alberts Muktup=C4=81vels via wm-spec-list:<br> > Hi,<br> > <br> > I would like to improve work area situation with multiple monitors.<br= > > Before writing patches I would like to hear what you think about my<br= > > idea.<br> > <br> > First I think there should be new property for struts because existing= <br> > properties can not be used to set struts on edges between two<br> > monitors. New property could be named _NET_WM_STRUT_AREA and used to<b= r> > define rectangular area (x, y, width and height) that should be<br> > excluded from work area. This property will need to follow at least<br= > > two rules:<br> > - at least one edge of area must match with monitor edge. The window<b= r> > manager must ignore strut if it is not placed at monitor edge.<br> > - if strut appears on edge between two monitors it should be ignored<b= r> > when calculating _NET_WORKAREA to ensure backward compatibility.<br> <br> sounds fine to me.<br> <br> As a note: in KWin we allow panels on shared edges to set a strut with <br> the existing protocol. We just decided that a strut is not allowed to <br> cover a complete screen. Technically it's a violation of the current <b= r> protocol, but might be a better idea than introducing yet another <br> property.<br></blockquote><div><br></div><div>This property probably make s= ense only with new workarea... For example if we have left and right monito= rs put side by side. How do you set strut for panel / dock that is placed o= n right monitors left edge? And more importantly - how would look generated= work area? It has to ignore strut or one monitor is excluded from work are= a.<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= "> It could be a simple textual addition like: "Struts covering a monitor= <br> completely are ignored for that monitor"<br> <br> > <br> > Next and more important part is new property to allow set work areas<b= r> > for multiple monitors. Currently I am thinking it could be<br> > _NET_WORKAREAS_Dn where n is desktop number. For example if<br> > _NET_NUMBER_OF_DESKTOPS is set to 3 then there must be<br> > _NET_WORKAREAS_D0, _NET_WORKAREAS_D1 and _NET_WORKAREAS_D2 properties.= <br> > <br> > Property would have one or multiple work areas:<br> > _NET_WORKAREAS_Dn, x, y, width, height CARDINAL[][4]/32<br> <br> This property I do not understand. What is the area of x, y, width, <br> height? Why per desktop?<br></blockquote><div><br></div><div>Per desktop? B= ecause existing=C2=A0 _NET_WORKAREA property have work areas for each deskt= op? If you have one desktop you have one rectangle with work area, if you h= ave 5 desktops it will contain 5 rectangles. To speak truth I don't kno= w if you really can have different work areas for different desktops and/or= if anyone support/use that...=C2=A0 I don't want to introduce more cha= nges then needed.</div><div><br></div><div>x, y, width, height is work area= rectangle. Property format basically is same as _NET_WORKAREA, except mult= iple rectangles are not for desktops, but for monitors. For example two 128= 0x1024 side by side monitors with 24px panel on right monitor left edge wou= ld produce following property - _NET_WORKAREAS_D0, [0, 0, 1280, 1024], [130= 4, 0, 1256, 1024]. And if you have more then one desktop there would be _NE= T_WORKAREAS_D1, _NET_WORKAREAS_D2... properties. That way you can read prop= erty for current desktop - _NET_WORKAREAS_D{_NET_CURRENT_DESKTOP}.</div><di= v><br></div><div>Did I make it more understandable or still not clear enoug= h?<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= "> > <br> > Window managers adding support for this would need to add<br> > _NET_WORKAREAS hint to _NET_SUPPORTED.<br> <br> And also for the new strut property.<br></blockquote><div><br></div><div>Ri= ght. I mention only work area hint because I have not seen that panels / do= cks would check if property is supported. They just set both properties and= window managers first tries to read _NET_WM_STRUT_PARTIAL and then _NET_WM= _STRUT.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"> > <br> > Does anyone see reasons why this would not work and/or have better<br> > suggestions?<br> <br> As a note: KWin is feature frozen for X11. This means we will not add <br> support for this. I don't know whether other window managers are still = <br> interested in extending the protocol. For me it's a thing which has bee= n <br> broken for ages and we found a workaround for the problem. I don't see = a <br> need to fix the "legacy" protocol.<br> </blockquote></div></div><div dir=3D"ltr"><br></div><div>I guess it is fine= , but it should not be reason to not update/improve spec, right?</div><div>= <br></div><div>For example, how do you workaround following bug?:</div><div= ><a href=3D"https://bugreports.qt.io/browse/QTBUG-60513" target=3D"_blank">= https://bugreports.qt.io/browse/QTBUG-60513</a><br clear=3D"all"></div><div= dir=3D"ltr"><br></div><div>Anyway, I am not after workarounds... Right now= it does not look like big and complicated changes so I don't see why w= ould this be rejected unless someone sees big problems that I have not thou= ght about.<br></div><div dir=3D"ltr"><br></div><div>For example metacity ba= sed window managers already have work areas for each monitor - all it needs= is to make it available to clients / toolkits. It would be enough to allow= toolkits to fix mentioned bug. And adding _NET_WM_STRUT_AREA would make it= possible to correctly calculate work areas for many configurations.</div><= div><br></div><div>I plan to write patches for metacity, mutter, gtk and ma= ybe also for compiz.<br></div><div dir=3D"ltr"><br>-- <br><div dir=3D"ltr">= <div dir=3D"ltr">Alberts Muktup=C4=81vels<br></div></div></div></div></div>= </div></div> </blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr"><div dir= =3D"ltr">Alberts Muktup=C4=81vels<br></div></div> --00000000000037259d059c4112cd-- --===============8946103020148987047== 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 --===============8946103020148987047==--