Re: Separate virtual desktops for different monitors

[Arnout Engelen <wmspec bzzt net>]

On Sat, Mar 7, 2015 at 3:23 PM, Pavel Kretov <firegurafiku gmail com> 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:

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

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

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

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

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