On Sat, Mar 7, 2015 at 3:23 PM, Pavel Kretov <fireguraf...@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
_______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org https://mail.gnome.org/mailman/listinfo/wm-spec-list
