nanogui@linuxhacker.org

> would be nice to start experimenting.  Another issue is that, if we want to implement
> all this fancy GDK and Mozilla stuff on top of nanoX, the driver layer is going to
have
> to support a HELL of alot more than it does now.  This means that it will take

Not that much

> palette management, xor/and/or/set drawing modes, background transparency

Fixed palette is acceptable with gtk, and indeed for LCD screens is a good
first model anyway.

> draw modes, text with transparency, and possibly a nanogui-defined device context

Text just needs to follow the draw modes - or/xor/and/set

> structure for each entry point, which will mean that drivers will have to ultimately
be
> designed for nanogui itself for speed.  Comments?

I think thats unavoidable.