Re: Improving work areas with multiple monitors
Alberts Muktupāvels via wm-spec-list <[email protected]> Mon, 31 Dec 2018 13:48:51 +0200
| Newsgroups | gmane.comp.gnome.wm-spec |
|---|---|
| Message-ID | <CAKX6tkUAb2nE-iPO8LQzRwC_sjmZ7Cqud_CPmkfBf5auOHs8tg@mail.gmail.com> |
--===============1862705060906278546== Content-Type: multipart/alternative; boundary="000000000000d10c8b057e4fff28" --000000000000d10c8b057e4fff28 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 31, 2018 at 10:44 AM Martin Fl=C3=B6ser <[email protected]> wr= ote: > 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 if we have left and right monitors put side by side. How do you set strut for 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, but 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 current 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 areas for many configurations. I plan to write patches for metacity, mutter, gtk and maybe also for compiz= . --=20 Alberts Muktup=C4=81vels --000000000000d10c8b057e4fff28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di= r=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Dec 31, 2018 = at 10:44 AM Martin Fl=C3=B6ser <<a href=3D"mailto:[email protected]" ta= rget=3D"_blank">[email protected]</a>> wrote:<br></div><blockquote clas= s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= gb(204,204,204);padding-left:1ex">Am 2018-12-27 22:22, schrieb Alberts Mukt= up=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" = class=3D"m_3246188659427574235gmail-m_-7293387589141991585gmail_signature">= <div dir=3D"ltr">Alberts Muktup=C4=81vels<br></div></div></div></div></div>= </div></div> --000000000000d10c8b057e4fff28-- --===============1862705060906278546== 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 --===============1862705060906278546==--