Re: Separate virtual desktops for different monitors
Arnout Engelen <[email protected]> Sat, 4 Apr 2015 18:43:28 +0200
| Newsgroups | gmane.comp.gnome.wm-spec |
|---|---|
| Message-ID | <CACDuYhu_m5h1_=nJcaP2-cV7OOiu-Lm-KLUtUC7z0M7ThGWEog@mail.gmail.com> |
--===============7905561994025940844== Content-Type: multipart/alternative; boundary=f46d043bdce6b794070512e8c393 --f46d043bdce6b794070512e8c393 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Mar 7, 2015 at 3:23 PM, Pavel Kretov <[email protected]> wrote= : > > I feel we need adding some more properties to describe the exact way how > window manager deals with virtual desktops. It may employ different > strategies like used in: > > =E2=80=94 ctwm (one set of desktops, each can be mapped to any output); > =E2=80=94 i3 (different sets of desktops for each output); > =E2=80=94 awesome (the tag approach, any combination of tags can be mapp= ed > to any output). > > It seems like we need to provide enough information for pagers to be able > to deal with all of that. Perhaps we should focus on the ctwm and i3 approaches and leave the awesome approach for future research? Adding a setting to tell pagers how the WM treats desktops could indeed be useful. We must allow pagers to ignore this information, but it could help some pagers. Something like _NET_DESKTOP_STRATEGY ? > Legacy applications would: >> * consider themselves 'no longer on the desktop' when the user selects >> another desktop on another display >> > > As Martin noticed, this can cause problems with some overly smart > applications. If we want to never break such programs, we may have to mak= e > the specification way too complicated. > You need to prepare a change to the spec. The tricky part here is to kee= p >> backwards compatibility. We must expect that some applications do "smart= " >> things like stopping video playback if they are not on the current >> desktop. >> (That's the main reason why KWin didn't go the road i3 went: we cannot >> break >> existing applications). >> > > =E2=80=94=E2=80=94=E2=80=94 Martin Gr= =C3=A4=C3=9Flin, 2015-03-03 10:08 > > Well, of course window managers are free to ignore any new features we might add to the spec, or make acting on them optional/configurable. While KWin didn't go the way i3 went, obviously i3 did, and potentially broke existing applications. Extending the standard to allow i3 to better communicate the choices it made doesn't change the fact that those applications broke. It does, however, allow us to lobby for those applications to also take those new features into account, fixing them. What would be further limitations of this approach? Other ideas? >> > > I was thinking of several ideas of how to implement the desired behavior. > Here they are. > > 1. Use the idea like described by you. This is the most obvious, clean, > easy to implement and straightforward way to do the thing, but, > unfortunately, it will break some application like Martin said. There is > another drawback: "visible on every desktop" feature will be quite tricky > to understand as application is NOT actually displayed on EACH of desktop= s. > > If we wish not to break those applications, we must ensure that all > windows visible at the time on all outputs have the same _NET_WM_DESKTOP > property value. > That's an interesting observation, I hadn't realized that. On the other hand: is this really a problem in practice? Indeed a _NET_WM_DESKTOP of '0xFFFFFFFF' should then be interpreted as 'never hide this window' rather than 'show it on each desktop'. What applications do we expect problems with when _NET_CURRENT_DESKTOP doesn't match the desktop they're actually on, when they've set _NET_WM_DESKTOP to 0xFFFFFFFF? > 2. Select one of output as a primary one. Old properties _NET_DESKTOP and > _NET_CURRENT_DESKTOP (and so on) are to be set accordingly to the primary > desktop. The state of other outputs is controlled by new properties (we m= ay > refer to desktops on secondary outputs as "subdesktops", making clear tha= t > switching subdesktops actually means moving windows to other virtual > desktops). Old pagers will be able to switch main desktop the way like th= ey > do it now, new pagers will be able to provide more comprehensive switchin= g > facilities. I don't fully realize how to do it yet. > > 3. Introduce a completely new subset of _NET_* properties and set old > properties to fail-safe defaults. Every old pager, task switcher or > application will see a setup with the only one virtual desktop, where > windows gets shown or iconified. > > How do you think, which directions is the best one? Options '2' and '3' appear arguably more complicated to me, and I'm not sure how they would break existing applications any less than the first proposal. Kind regards, Arnout --f46d043bdce6b794070512e8c393 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S= at, Mar 7, 2015 at 3:23 PM, Pavel Kretov <span dir=3D"ltr"><<a href=3D"m= ailto:[email protected]" target=3D"_blank">[email protected]</a>&= gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l= eft-style:solid;padding-left:1ex"> I feel we need adding some more properties to describe the exact way how wi= ndow manager deals with virtual desktops. It may employ different strategie= s like used in:<br> <br> =C2=A0=E2=80=94 ctwm (one set of desktops, each can be mapped to any output= );<br> =C2=A0=E2=80=94 i3 (different sets of desktops for each output);<br> =C2=A0=E2=80=94 awesome (the tag approach, any combination of tags can be m= apped<br> =C2=A0 =C2=A0to any output).<br> <br> It seems like we need to provide enough information for pagers to be able t= o deal with all of that.</blockquote><div><br></div><div>Perhaps we should = focus on the ctwm and i3 approaches and leave the awesome approach for futu= re research?</div><div><br></div><div>Adding a setting to tell pagers how t= he WM treats desktops could indeed be useful. We must allow pagers to ignor= e this information, but it could help some pagers. Something like _NET_DESK= TOP_STRATEGY ?=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote= " style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"= "> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Legacy applications would:<br> * consider themselves 'no longer on the desktop' when the user sele= cts<br> another desktop on another display<br> </blockquote> <br></span> As Martin noticed, this can cause problems with some overly smart applicati= ons. If we want to never break such programs, we may have to make the speci= fication way too complicated.=C2=A0</blockquote><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-= color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span clas= s=3D""> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> You need to prepare a change to the spec. The tricky part here is to keep<b= r> backwards compatibility. We must expect that some applications do "sma= rt"<br> things like stopping video playback if they are not on the current desktop.= <br> (That's the main reason why KWin didn't go the road i3 went: we can= not break<br> existing applications).<br> </blockquote></span> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=94=E2=80=94=E2=80=94= Martin Gr=C3=A4=C3=9Flin, 2015-03-03 10:08<span class=3D""><br> <br></span></blockquote><div><br></div><div>Well, of course window managers= are free to ignore any new features we might add</div><div>to the spec, or= make acting on them optional/configurable.=C2=A0</div><div><br></div><div>= While KWin didn't go the way i3 went, obviously i3 did, and potentially= broke existing</div><div>applications. Extending the standard to allow i3 = to better communicate the choices it=C2=A0</div><div>made doesn't chang= e the fact that those applications broke. It does, however, allow us to</di= v><div>lobby for those applications to also take those new features into ac= count, fixing them. =C2=A0</div><div><br></div><blockquote class=3D"gmail_q= uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c= olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class= =3D""> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> What would be further limitations of this approach? Other ideas?<br> </blockquote> <br></span> I was thinking of several ideas of how to implement the desired behavior. H= ere they are.<br> <br> 1. Use the idea like described by you. This is the most obvious, clean, eas= y to implement and straightforward way to do the thing, but, unfortunately,= it will break some application like Martin said. There is another drawback= : "visible on every desktop" feature will be quite tricky to unde= rstand as application is NOT actually displayed on EACH of desktops.<br> <br> If we wish not to break those applications, we must ensure that all windows= visible at the time on all outputs have the same _NET_WM_DESKTOP property = value.<br></blockquote><div><br></div><div>That's an interesting observ= ation, I hadn't realized that. On the other hand: is this really a</div= ><div>problem in practice? Indeed a _NET_WM_DESKTOP of '0xFFFFFFFF'= should then</div><div>be interpreted as 'never hide this window' r= ather than 'show it on each desktop'.</div><div><br></div><div>What= applications do we expect problems with when _NET_CURRENT_DESKTOP doesn= 9;t</div><div>match the desktop they're actually on, when they've s= et _NET_WM_DESKTOP to 0xFFFFFFFF?</div><div>=C2=A0<br></div><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;= border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex= ">2. Select one of output as a primary one. Old properties _NET_DESKTOP and= _NET_CURRENT_DESKTOP (and so on) are to be set accordingly to the primary = desktop. The state of other outputs is controlled by new properties (we may= refer to desktops on secondary outputs as "subdesktops", making = clear that switching subdesktops actually means moving windows to other vir= tual desktops). Old pagers will be able to switch main desktop the way like= they do it now, new pagers will be able to provide more comprehensive swit= ching facilities. I don't fully realize how to do it yet.<br> <br> 3. Introduce a completely new subset of _NET_* properties and set old prope= rties to fail-safe defaults. Every old pager, task switcher or application = will see a setup with the only one virtual desktop, where windows gets show= n or iconified.<br> <br> How do you think, which directions is the best one?</blockquote><div><br></= div><div>Options '2' and '3' appear arguably more complicat= ed to me, and I'm not sure how they=C2=A0</div><div>would break existin= g applications any less than the first proposal.</div><div><br></div><div><= br></div><div>Kind regards,</div><div><br></div><div>Arnout=C2=A0</div></di= v></div></div> --f46d043bdce6b794070512e8c393-- --===============7905561994025940844== 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 --===============7905561994025940844==--