nanogui: Small Xlib replacement
Subject:
Small Xlib replacement
From:
Greg Haerr ####@####.####
Date:
8 Sep 1999 16:14:56 -0000
Message-Id: <01BEF9E2.55AFC3E0.greg@censoft.com>
: I know. I was talking about Xlib too. We did consider changing the
: function names to closer match X, but it might confuse people into
: thinking that Nano-X is supposed to be a faithful clone of X, which it
: isn't.
Perhaps the name should be changed Nano-Y then. It's
already confusing. Nano-X implies a smaller version of X. Most
newbie questions on this list seem to want a small X.
There are a lot of things which can be done (and are done) more
: simply than how X does it.
That's a for sure ;-)
:
: > The point is that the nano-X api is *already* Xlib compliant, but noone
: > realizes it, and that further slows development. I'm not suggesting that
: > the API has to remain Xlib compatible, but when you've already got 90% of
: > your API compliant, why not?
:
: It isn't anywhere near that close,
Check out each function and it's arguments. Although the types
are typedef'd, you'll find that very many are exactly the same, of course
lacking the Display * arg.
In any case, if folks are looking for a small, highly functional
Xlib api that is *much* smaller than Xlib, but performs very similarly,
I'll write it. I estimate that I could have it *finished* in about a week.
This would allow the Gtk etc guys to get their stuff running very quickly,
and then we could concentrate on the harder aspects that the engine
doesn't currently support, like off-screen pixmap drawing.
The idea would be to implement the Xlib api quickly using exactly
the same parms as documented, until the engine or Xlib design required (because
of good design considerations, like size) a change. This would end up
creating a large set of compatible routines, and a smaller set of incompatible routines.
Of course, anyone's free to add new api entry points to their heart's content.
Most of the initial engine work is completed, as evidenced by the MicroWindows demo.
As I've mentioned before, the biggest engine problem is lack of offscreen drawing
support, which involves some larger architecture/driver changes.
Greg
