Re: FW: XFree86 future

On Sun, Mar 23, 2003 at 10:35:19AM +0100, Lukas Molzberger wrote:
> There was often the argument that X11's API would never have to be rewritten 
> since you can just add another extension if you need a new feature. I think 
> this is a big mistake in the long term. It leads to dublicate and 
> inconsistent API's. It makes it more difficult for the developer who wants to 
> use these API's to find the right way to use them. Which then leads to hacks 
> and bugs.

The reason I'd disagree with this is that developers really have no
business writing raw Xlib. Plain Xlib (or "look ma, I wrote my own
toolkit") apps are always broken in hundreds of ways.

Should raw Xlib be simpler so you can use it? The only way to achieve
that would be to make the lowermost/Xlib layer of the window system
look like a toolkit, not a window system. i.e. the "put the toolkit on
the server side" model. This is the *opposite* direction from direct
rendering. I would generally feel that server-side toolkit is wrong, 
not least because we need to be able to evolve and modify the UI
without breaking the protocol.

So the reality is that the only people that really need to understand
Xlib are people writing window managers, toolkits, and this type of
thing.

If you move to direct rendering, stuff using plain Xlib would probably
end up being broken in thousands of ways instead of hundreds, because
the ICCCM-equivalent would have to cover a lot of things that are
currently implicit in X protocol and people would have to implement it
all properly.

> All these problems make XFree a very complex project. It's very hard for a new 
> contributor to dig through the XFree sources and to understand them to a 
> degree where he can make a meaningful contribution.

I don't agree in fact. I wrote an extension last year, and the
problems spent most time on were:

 a) it was hard to find the relevant code just because the source tree
    is big
 b) the build system

I was surprised by the clarity and quality of the server code once I
found it, especially given its age. I have seen much worse.  Granted I
don't understand the hardware specific bits at all, but that's because
I don't understand hardware. But I felt I was able to get a grip on
dix and mi and do a simple extension in a few days, aided by good
preexisting knowledge of X client-side programming and Xlib internals,
but there are a fair number of people out there with that knowledge.

Based on my experience, to make it easier for people who already know
something about X to contribute, the most useful thing would be build
system cleanup so e.g. build dependencies work (I wasted noticeable
time on "bugs" where I didn't rebuild something after changing one of
its deps). And all the exports/ stuff - there has got to be a better
way to do that. ;-) And the .cf thing is fairly confusing.

After that, I'd concur with something a lot of people have mentioned,
break the distribution up into smaller modules. Server, core libs
(possibly subdivided), deprecated/stupid libs, clients (possibly
subdivided), docs, fonts, etc.

The easiest way to address the build stuff may well be to slowly move
things out of the current build into their own module, revamping how
they are built as they move. And of course use autotools, not
because autotools don't suck (sure they do), but they suck less and in
well-known ways. ;-)

Havoc