Re: Removing wm/pager interaction

["Michael Rogers" <mrogers cs ucl ac uk>]

> I like the simplicity of your draft, but I think it just makes the
> problem worse. If you remove the pager hints it won't stop people using
> them (or something similar).

Are there any programs other than the Gnome pager, tasklist and desk guide 
which use these hints? Those applets are part of the core Gnome packages, so 
they could easily be removed from the next major release. (IIRC, panel version 
1.1 broke v1.0 applets without causing any major problems, because all the 
affected code was in the core packages, so it was possible to keep it 
synchronised.)

> So what might happen then is that we'll
> have a standard for a few trivial interactions, plus maybe a few ad hoc
> standards for pager interactions. This doesn't seem much better than
> what we had before..

I agree. That's why I don't think a standard which only covers a simplistic 
set of behaviours is very useful. Window managers will provide their own 
pagers anyway, to incorporate extra features or provide better integration. 
The universal pager will end up being a default which doesn't quite work, 
which users replace (if they're technically minded) or get frustrated with (if 
they're not).

> IMHO it would be better to at least _have_ a standard for this, even if
> the standard is slightly restrictive.

If we're going to have a standard, it has to be one that makes sense. The 
current draft standard (1.9e) has some serious problems when it comes to 
creating, deleting and naming desktops.

> There is nothing forcing wm's to implement this standard, and there is 
> nothing stopping them from implementing their own pager with all the 
> functionality that that window manager can support (e.g. sawfish supports 
> windows being on any arbitrary set of workspaces, yet it can't expose this 
> information through the pager spec. But I'd rather have it that way than 
> have to reimplement yet another desktop pager)

WM idiosyncrasies like this one will lead to the information provided by the 
pager being inconsistent with the information provided by the wm. (Another 
example is that the Gnome deskguide uses click-to-focus, while my wm uses 
focus-follows-pointer.) That might be a fair compromise for those users who 
are aware of the fact that their window manager and their pager are two 
separate programs which share a limited amount of information, but I imagine 
inconsistencies like this would frustrate most users, who don't need or want 
to know how their desktop environment works.

> Maybe it would be easier to just make it clear in the spec that window
> managers are free to implement any subset of the spec that they choose
> (isn't this what the _NET_SUPPORTED_HINTS property is for?)

Again, that's a good compromise from a technical user's point of view, but I 
don't think it will give a good impression to non-technical users, because 
there will be no way to pick a "Gnome+KDE compatible window manager".

For example, a user may install window manager A which claims to be Gnome+KDE 
compatible. Window manager A doesn't support pager interaction, but it sets 
_NET_SUPPORTED_HINTS to indicate this, so it complies with the spec. The pager 
complains that the user isn't running a Gnome-compliant window manager. 
Confused, the user switches to window manager B, which cooperates with the 
pager, but also provides its own pager which shows different information.

This is the problem that the spec is meant to solve, and ironically the 
universal pager, the tool that was supposed to enable window manager 
independence for Gnome, seems to be the biggest stumbling block.


Michael