Re: Separate virtual desktops for different monitors

[Pavel Kretov <firegurafiku gmail com>]

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

Yes, and I've already realized that the task is way more difficult then 
it seemed from the beginning.

> 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).

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:

 — ctwm (one set of desktops, each can be mapped to any output);
 — i3 (different sets of desktops for each output);
 — awesome (the tag approach, any combination of tags can be mapped
   to any output).

It seems like we need to provide enough information for pagers to be 
able to deal with all of that.

> 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).

This can work. I personally would prefer to set _NET_CURRENT_DESKTOP to 
value like 0xFFFFFFFF to indicate the fact it is undefined, but this 
would be backward-incompatible.

> 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 
make the specification way too complicated.

> You need to prepare a change to the spec. The tricky part here is to keep
> 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).
>                                 ——— Martin Gräßlin, 2015-03-03 10:08

> 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 
desktops.

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.

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 virtual 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 switching 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?

———— Pavel Kretov.