Re: Removing wm/pager interaction

[Sasha_Vasko osca state mo us]

>Sasha_Vasko@osca.state.mo.us writes:
>|>so (insert 1) means to insert a new desktop before desktop 1 (i.e.
>|>between the first and second desktops), shifting all desktops after
>|>the insertion point one place down
>|
>|I don't see how you can easily do that - you'll have to renumber all
>|the desktops and update properties on all the client windows. This is
>|potentially very costly operation, and since you don't change desktop
>|names result will be the same as to add a desktop to the end of the
>|list, only this latter approach will be much simplier, and much less
>|confusing.
>
>what? how is creating a new workspace in the middle (thus shifting all
>windows on workspaces after that point) the same as appending a
>workspace at the end?


It's the same from the users perspective. Here is why :
You don't change your names list, so if you had desks labeled:
1:Desk_A, 2:Desk_B, 3:Desk_C

If you insert desk right after desk 1 you gonna get :

1:Desk_A, 2(new_desk):Desk_B, 3(old_2):Desk_C, 4(old_3):Undefined

So from the user's perspective it will look as if you added desk to the
end,
and then moved all the windows from the desk 2->3, 3->4. Which is certainly
not something that user, who knows nothing about your bookkeeping, expected
to see.

You don't mention that, But I suspect that you don't change root background
assignments as well, which will make illusion even more complete.

That's why it is making better sense to add remove desktops only from the
tail of
desktops list. THE USER PERSPECTIVE.

>imho, it's ridiculous to remove / restrict a feature of the spec.,

I'm not saying that this feature has to be removed/restricted. I'm saying
that it has to be better defined. I offered 2 different solutions - one
allowing for insertition/deletion in the middle of the list - another one
allowing only for adding removing to/from the tail. Either one of those
solutions, or some better one, has to be added to specs in order to make it
usable.

>simply because _some_ window managers _may_ be unable to implement it
>blindingly quickly

You have to think about ALL window managers since you don't write
sawfish compatibility specs, but Window Manager compatibility specs.
Other WMs may not be able to implement it blindly quickly not becouse
they are lousy, but becouse they have richer and therefore more complicated
feature set, and you may come to regret your decision, when one day sawfish
will become complicated as well, and this blindly quick decision will
come in a way of future progress.

Regards
Sasha