: I support having a partial Xlib implementation, but *not* if it affects
: size and efficiency.
:
I completely agree. For instance, none of the Xrm* stuff would
come in. OTOH, why not just call XOpenDisplay and XDrawString,
rather than GrOpen and GrText? It would involve one more (usually NULL)
parameter, the Display *. But most of the api would port easily.
: I suspect it would be hard to implement a full featured API and maintain
: a small size without deviating quite a bit from the Xlib API. It might
: be worth a try to add at least partial compatibility.
I think it's a good try. Just like when I reimplemented win32,
I'm only going for the graphics stuff, not the whole damned world. Heaven's
knows we don't want to create Gate's whole idiotic pig-big system all over
again.
On a more rational note, yes, the Xlib api may differ
on certain items. Like color. We could use a much simpler color
model than X. So the api isn't exactly Xlib, but it's as close. We
try to keep the parameters the same, but don't have to match the internal
Xlib data structures for the parameters. This is a trick I used in
microwindows, if anyone's noticed.
Greg
