Re: Removing wm/pager interaction

[Sasha_Vasko osca state mo us]

>Am Mon, 19 Jun 2000 schrieb Sasha_Vasko@osca.state.mo.us:
>> <snip>
>> >So yes, the hints are indeed very important for many desktops. Luckily
we
>> >agreed on them long time ago and luckily the end-users will be able to
use
>> >tools like "kicker" with any window manager they want in the future.
>>
>> Unluckily there is a sufficient amount of problems with agreed specs:
>> 1) INSERT/DELETE DESKTOP message has no defined behaviour in specs, and
>> either
>> way to define it you'll get into other problems.

>I disagree. Those hints are totally independent.

eh? Independant from what ?? Specs reads :
<quote>
A Pager can insert or delete a certain desktop by sending a
_NET_{INSERT/DELETE}_DESKTOP client message to the root window.
</quote>

But there is no definition as to what is supposed to happen when
desktop is inserted/deleted. What name to use with it ? what root background ?
what to do with windows that are on the desk being deleted ? What happen
if Pager requests addition of the desktop 7 when we only have 0, 1, 2, 3 ?
etc. etc. etc.  All of that has to be defined some way or another if this really is
a WM compatibility specs.

Please understand that I don't raise these questions out of idle interest -
I am trying to implement support for this specs in AfterStep and I'm literarly
stuck not knowing what should be implemented.

>>
>> 2) Desktop naming and numbering is too inflexible and shortsighted
>
>Nothing that can be fixed later. The current scheme is, as you pointed
out, so
>simple that it's no problem whatsoever to support it as a subset for
>compatibility in any later version of the spec or windowmangers that
implement
>it.

related to previous problem. If desktop is deleted from the list and then
readded
( maybe with different number)- what happen to the name of it ? virtual
root of it ?
What if WM supports virtual desktops, but does not want to carry
information about
desktop names? How to let Pager know that it's supposed to take care of it
instead of WM ?

Note that none of that can be fixed later without major change to the
specs, as this
scheme has zero expandability, and as the result - major recoding involved.

>>
>> 3) several hints are designed to provide clients with means to do
things,
>> that
>> should not be allowed, thus creating possiblity for conflicts of
interests
>> and configuration between WM and client.
>
>There is no conflict of interests between the WM and clients. Ultimately
it
>boils down to what the *user* wants. If users want to run a CD or MP3
player
>that provides a "stays on top" checkbox in the application menu, for sure
they
>want to be able to use this checkbox.  This is basic functionality of a
window
>sytem, there's really no reason to prevent a client from requesting this
state.

Aha, you forget one thing that if WM supports StayOnTop : a) it will
provide means
to configure particular window to StayOnTop in its own config, thus
creating
a conflict with the client; b) It's likely to support much more
sophisticated
version of it like layers. Both of this items make this option completely
useless.
Urgency hint is more then enough to indicate WM that app should be placed
as higher up in stack as possible. Leving this hint in specs will create
nothing but confusion.

Again I'm viewing this question from the point of implementation it in real
life
window manager, and anticipation of potential user dissutisfuction.

>>
>> Fact that it is implemented somewhere does not right the wrong. It will
>> only lead to the situation where these specs will have to be reviewed in
>> future.

>Yeah, better have nothing common than something that isn't 100% perfect.
Do we
>want to improve X11 interoperability or not?  If that's not your goal,
just let
>those who agree work on the task.

Here we go. If I would not want to improve X interoperability I would not
waste
endless hours for this disscussion. I don't like aguing anymore then the
next person,
and you can be sure that if I would not be forced into this, I would keep
lowest
profile for as much as possible.

All that noise I make  is becouse of the problems that occur when you try
to
move this specs into the real life, and actually implement it. As you might
have noticed I don't run around shouting that this whole effort sucks, but
instead provide constructive, real life based, criticism. I sure regret
that
I was not here half a year ago, when all this decisions were made. But it
is not
to late to consider changes and provide more consistant and mature specs,
that will
stay around for along time, instead of being tossed out into a garbadge
before long,
as happened to Gnome specs from rasterman.

This questions come from real life experince, guys.

>The spec is defined in a way that everybody can choose to implement only
the
>subset he or she likes. It's not necessary to have a 100% equality among
all
>window managers, every small step we can reach is an advantage.

That is a very wromg approach. What it leads to is bunch of window managers
that claim to be 100% compliant but in fact all do things differently.
The only time when WM may choose to not implement any part of the
specification
is when this particular feature is not supported by it, and not becouse
specs are
crapy. For example if window manager supports virtual desktops, it should
always
be able to support virtual desktops provisions of these specs as well.

Not every small step is an advantage. In this particular case we take one
small
step ahead, only to take two big steps back. You letting out crippled and
incomplete specs, that are supposed to be treated with respect, but instead
will
cause nothing but frustration and anger, and will severly damage
credibility
of this kind of effort in future.


>Matthias

Cheers
Sasha Vasko
AfterStep and aterm developer.