Subject:
RE:
From:
Greg Haerr ####@####.####
Date:
11 May 1999 22:39:21 -0000
Message-Id: <01BE9BCD.202F14F0.greg@censoft.com>
On Tuesday, May 11, 1999 3:58 PM, Alex Holden ####@####.#### wrote:
> On Tue, 11 May 1999, Greg Haerr wrote:
> > I agree that the window mgr should be modular, but if you want different window
> > managers, you might as well use X. Actually, although it was a good idea,
> > the fact that X's design allowed for so much flexibility with differing looks and feels
> > contributed to Microsoft's taking over with their faster, more consistent gui...
>
> That's only one side of the story. A lot of people (myself included)
> _like) the fact that there are a million and one different window
> managers, most of them extremely configurable (and more recently,
> themeable), to play with. People keep saying that "users want the
> interface to always look exactly the same so that they only need to learn
> it once", but to me that's just plain boring. The fact that Motif is
> non-free did the most damage, IMO. Only now with modern widget sets
> like GTK+ can you really produce a _decent_ looking X app.
I agree. Except that most of the work in writing window managers
(except for the expose event/z-order calculations, which is handled "internally"
in the X model) is writing all the code to draw the good-looking window frames,
etc.
But in the nano project, it's really a moot issue, since we're all in agreement
that at least the draw-code side of the window manager needs to be available as
a detachable api that would allow anyone to code their own look and feel, should
they really find the time and energy to do it. I'm actually in favor, stated in another
email, that we don't get locked into *any* window management theology at the mid-level
api's for nanogui, so that the nanogui graphics engine could be used, for example,
for my nano-win32 project. ;-)
In another email, I will propose a development track for nanoX v0.4:
separation and identification of this "mid-level" api from the user-level X-like
api's now present in nanoX. By creating this api early, various folks on this
mailing list could start out feasability testing certain concepts, like whether
or not nanoX should/could support GDK directly, or whether it's built on top
of nanoX. Getting more developers in the game will help us determine how much more work
the base nanogui graphics engine needs to support the "cool stuff."
Greg
>
> > The first version of nanoX that I write will definitely have some built-in window
> > management, in order to keep it small. In my opinion, *all* of nanoX should be
> > kept small, so that it can be used where X can't. Otherwise, why not just use X?
>
> X is _really_ big and bloated. Just adding a versatile set of hooks to
> Nano-X which allow you to link in a decent WM if you want isn't going to
> cause a significant amount of bloat.
Agreed.
>
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
>
>
