call for other views [was Removing wm/pager interaction]

[Julian Adams <julian adams gmx net>]

I'm just a lurker, but I do have a few points.

Sasha_Vasko@osca.state.mo.us wrote:
> 
> >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.

You're right, of course. I'd guess though that this is the case because
(as you pointed out) the spec is incomplete / ambiguous. Personally I'd
guess that the intent of the spec was to allow addition of desktops in
the middle of the list, and make this process visible to the user. OTOH
I don't know what was intended. 

> 
> 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.

Spot on again. One solution does need to be integrated to clarify the
spec, and make it solid. I think all the guys on the mailing list need
to give input on which approach to take. I think everyone could live
with either of the solutions (perhaps with refinement) if 5, 10 or even
20 people had voted one way or the other. 

You guys who have implemented the spec - surely you must have made
assumptions, which need to be added into the spec as requirements -
what's your opinion ?

> 
> >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.

There has been lots of criticism of the spec being over complex. When I
read it I was actually impressed by how simple it was ! I was expecting
a monster, which it's not. There are plenty of specs running around
which work well (TCP/IP anybody ?) which are much more complex than
this. 

The spec needs to be as complicated as it needs to be - but no more.
OTOH dropping features to make a spec simpler is a false economy IMHO. 

I can't really see that it would be a burden for a new implementation of
a WM to cover the spec, but clearly it may be harder for existing WMs to
implement it. I thought that one of the benefits of Open Source was that
people were prepared to go back and rework stuff. I appreciate that this
may not seem like it's being done for a technical benefit, but it just
needs to be compared with the previous MOTIF/GNOME/K hint saga to see
that one spec will be much better.

Let's try to get everybody involved to fix this one point and try to
wrap up the spec.

Sorry for being so wordy :)

Julian
> 
> Regards
> Sasha
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list