Re: metacity, vte



A nice coherent post on the topic at last. Some comments inline...

On Sun, Sep 22, 2002 at 01:57:56PM -0700, Adrian Custer wrote:
> The question of "sorting out metacity" seems to involve several issues
> none of which are spelled out in this post. I am also at a loss as to
> who the "people" are whose opinions are relevant. 
> 
> Breaking apart the discussion I get two questions:
> 
> 1) Does GNOME intend for the near future to support a single window
> manager or allow the flexibility of several?

I would disagree that this is an issue -- the answer has been "both" up
to now and there is no reason to restrict that now. We need to pick a
default window manager that a lot of effort is put behind to fix serious
bugs in. However, any window manager which obeys the relevant
specifications will also work with GNOME -- there is no "secret
handshake" whereby GNOME checks you are using the One True Window
Manager.

> 2) Does GNOME want to change from sawfish as the default to metacity?

In view of the above, I will interpret this as "do we want to change the
default, shipped window manager from Sawfish to Metacity".

> Addressing 1) the issues seem to be:
> 
> a single window manager:
> --is easy for new users
> --does not require defining a standard of integration, a standard list
> of features or any other standard for GNOME compliance
> --concentrates developer attention

The first and third points are arguments in favour of having at least
one "officially blessed" window manager.

I am not, btw, very happy with calling any window manager the "official"
window manager. It really is the "default" window manager, but it _will_
tend to be the one where a lot of bug-fixing attention goes. Of course,
I don't get to pick the euphemism-du-jour, so it's bad luck for me.

The second point misses the mark, I feel. Havoc wrote Metacity with a
lot of attention to relevant standards. In cases where the behaviour is
ambiguous or undefined w.r.t. open, published specifications, he has
sometimes picked a sensible looking alternative. At other times, he has
held off implementing anything until some behaviour can be written up.

Ever since the early days, GNOME has tried to have some kind of
specification of what it requires from a window manager. This has not
always worked beautifully, but it was well-intentioned. Of course, in
the early days, the whole point was partly to avoid having any default
window manager -- which sort of worked and sort of didn't. In latter
times with Sawfish and now Metacity becoming the "dominant" window
manager by fiat, it is very nice that accomodation with pre-existing
specifications is still important to the respective developers.

> multiple window managers:
> --allows user choice

The choice is still going to be there regardless of whether Metacity
becomes the default or not.

> --allows users to use a window manager which either "just works" for
> them or one with the features they feel they need to be productive

Same as my previous comment.

> --requires a GNOME wide definition of features which window managers
> must implement to be GNOME compatible.

Yes. This is important whichever window manager is blessed as the
default. Fortunately, as mentioned above, it is mostly happening anyway,
since accordance with the various specifications at
http://www.freedesktop.org is more or less necessary and sufficient for
compliance. There may be some extra window hints that GNOME understands
-- I can't remember now -- but spec compliance is important and
happening.

> (The issue of how users get to a new window manager, I leave aside since
> this seems to be a minor piece compared to publishing a definition of
> GNOME compliance.

I agree with this. How to switch window managers is really minor. Do we
have any evidence to suggest it is something people do a lot? Is it
going to kill us to post it in answer to questions on the mailing lists
once or twice and then point people at the FAQ list?

> Note that this standard would impose on the default
> window manager a set of minimum requirements which may or may not be
> supported by the module maintainer.)

I don't understand this.

> Addressing 2) the issues seem to be:
> 
> for using metacity:
> --many developers support it
> --major distributions have decided to ship it as a default

Both true.

> --it ties into the menus in a specific way

??? What do you mean?

> --it has active development which sawfish seems to be lacking

Well, Sawfish has basically stabilised on its goal, it appears.  Every
now and against, jsh has time to hammer some bugs (last weekend seems to
be one example) and Sawfish basically Just Works for a large bunch of
use cases. So too much development is bad.

On the other hand, Metacity has consistent development at the moment,
which seems like a good thing.

> for keeping sawfish:
> --many users like one or several features which metacity will not
> support. 

Making Metacity the default window manager for GNOME 2 does not mean
Sawfish will suddenly stop working or that people will be required to
switch. It may mean that some functionality can now be implemented that
is spec-compliant in cases where otherwise working aroudn a Sawfish
problem may have been necessary, but I do not know if this is a common
restriction people are finding or if it is even cause for a little bit
of concern.

> I am sure there are more issues and leave those to others to add in.
> Also, I refrain from giving my opinion since I don't think that the
> opinion of users is considered useful by those who will ultimately
> decide on the issue.

Whoops ... you were going so well up to here and then it devolves into
something resembling a conspiracy theory accusation. Anybody with a
well-reasoned argument will be heard. I found your points above well
worth reading, although it may look like I'm just poking holes in them.

Some serious discussion on this topic (rather than the
feature-by-feature comparison we've seen so far) is going to be
necessary. Hopefully your post kicks that off again.

Oh, yeah ... do I have an opinion? I guess Metacity is an appropriate
default. I don't particularly like; the lack of configurable options
bites me, since it is impossible to have some options that are good for
everybody and I prefer differences from the defaults. But it's a well
written piece of code with consistent design ideas behind it and backed
up by published and freely available specifications.

I definitely prefer vte over zvt, although both have interesting quirks
at the moment. Again, I think it's a case of slightly better designed
and maintained code at the moment (vte learns a lot of the lessons
taught by experiences with zvt, for example) and getting anti-aliasing
and interantionalisation working is very important.

Cheers,
Malcolm



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]