Re: Removing wm/pager interaction
- From: Sasha_Vasko osca state mo us
- To: Sasha_Vasko osca state mo us,John Harper <john dcs warwick ac uk>
- Cc: Tim Janik <timj gtk org>, wm-spec-list gnome org
- Subject: Re: Removing wm/pager interaction
- Date: Mon, 26 Jun 2000 14:44:56 -0500
>|>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
>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
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
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
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
>simply because _some_ window managers _may_ be unable to implement it
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.
] [Thread Prev