Re: Separate virtual desktops for different monitors

--===============9051622596258140187==
Content-Type: multipart/alternative; boundary=f46d0438907179eb1d0510b290ee

--f46d0438907179eb1d0510b290ee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 3, 2015 at 6:03 AM, Pavel Kretov <[email protected]> wrote=
:

> there exist managers which employ the different concept: they allow user
> to setup own set of virtual desktops for each of monitor. (Mac OS X has a
> similar feature too.)
>

I like this concept very much, too.

Unfortunately, such a behavior is not a part of the specification. I'd like
> to see such a behavior in mainstream window managers too, so are the
> questions:
>
> =E2=80=94 Are there any chances this become a part of standard?
> =E2=80=94 If yes, what can I do for this to happen?


I guess the main challenge is coming up with a good, backwards-compatible
proposal.

The current desktop is currently held by _NET_CURRENT_DESKTOP. Currently
our interpretation is that that desktop is also the only visible one.

What if we added a '_NET_VISIBLE_DESKTOPS' holding the indexes of the
visible desktops (i.e. the one visible on each display)?
_NET_CURRENT_DESKTOP would still hold the current one (e.g. the one last
switched to, or perhaps even tracking the window focus).

Legacy pagers would still work:
* highlighting the current desktop: this might change more often than
traditionally, but still work.
* switching the current desktop: this would still work (though if you allow
migrating desktops from one display to another the WM would now have to
figure out on which display to put the selected desktop).

New pagers could:
* highlight all visible desktops
* switch desktops per display by updating _NET_VISIBLE_DESKTOPS (as well as
_NET_CURRENT_DESKTOP).

Legacy applications would:
* consider themselves 'no longer on the desktop' when the user selects
another desktop on another display

New applications could:
* handle 'no longer visible' and 'no longer on the current desktop'
differently if needed

What would be further limitations of this approach? Other ideas?

Now whether 'mainstream window managers' would actually adopt this model of
course remains to be seen, but if we can come up with a nice way to include
it in the spec that certainly could lower the barrier.


Kind regards,

Arnout

--f46d0438907179eb1d0510b290ee
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 T=
ue, Mar 3, 2015 at 6:03 AM, Pavel Kretov <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:[email protected]" target=3D"_blank">[email protected]</a>&=
gt;</span> wrote:<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);bord=
er-left-style:solid;padding-left:1ex">there exist managers which employ the=
 different concept: they allow user to setup own set of virtual desktops fo=
r each of monitor. (Mac OS X has a similar feature too.)<br></blockquote><d=
iv><br></div><div>I like this concept very much, too.</div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">Unfortunately, such a behavior is not a part of the specifi=
cation. I&#39;d like to see such a behavior in mainstream window managers t=
oo, so are the questions:<br>
<br>
=E2=80=94 Are there any chances this become a part of standard?<br>
=E2=80=94 If yes, what can I do for this to happen?</blockquote><div><br></=
div><div>I guess the main challenge is coming up with a good, backwards-com=
patible proposal.</div><div><br></div><div>The current desktop is currently=
 held by _NET_CURRENT_DESKTOP. Currently our interpretation is that that de=
sktop is also the only visible one.=C2=A0</div><div><br></div><div>What if =
we added a &#39;_NET_VISIBLE_DESKTOPS&#39; holding the indexes of the visib=
le desktops (i.e. the one visible on each display)? _NET_CURRENT_DESKTOP wo=
uld still hold the current one (e.g. the one last switched to, or perhaps e=
ven tracking the window focus).</div><div><br></div><div>Legacy pagers woul=
d still work:</div><div>* highlighting the current desktop: this might chan=
ge more often than traditionally, but still work.</div><div>* switching the=
 current desktop: this would still work (though if you allow migrating desk=
tops from one display to another the WM would now have to figure out on whi=
ch display to put the selected desktop).</div><div><br></div><div>New pager=
s could:</div><div>* highlight all visible desktops</div><div>* switch desk=
tops per display by updating _NET_VISIBLE_DESKTOPS (as well as _NET_CURRENT=
_DESKTOP).</div><div><br></div><div>Legacy applications would:</div><div>* =
consider themselves &#39;no longer on the desktop&#39; when the user select=
s another desktop on another display</div><div><br></div><div>New applicati=
ons could:</div><div>* handle &#39;no longer visible&#39; and &#39;no longe=
r on the current desktop&#39; differently if needed</div><div><br></div><di=
v>What would be further limitations of this approach? Other ideas?</div><di=
v><br></div><div>Now whether &#39;mainstream window managers&#39; would act=
ually adopt this model of course remains to be seen, but if we can come up =
with a nice way to include it in the spec that certainly could lower the ba=
rrier.</div><div><br></div><div><br></div><div>Kind regards,</div><div><br>=
</div><div>Arnout=C2=A0</div></div></div></div>

--f46d0438907179eb1d0510b290ee--

--===============9051622596258140187==
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

--===============9051622596258140187==--