nanogui: Thread: layers

Hello All,

I am been thinking about the layers we have in the 
GUI.

first layer the (OS dependend hardware interface) framebuffer.

second layer the drawwing functions like lines, dots, text etc.

thirth layer the windowing system

fourth layer the GUI toolkit

For small applications only layer 1 and 2 might be interesting.

So my question is , wouldn't it be a idea to split up micro windows 
in two source tree's on that offers the general drawwing interface
to the framebuffer, X11, win32, hardware etc. that can be compiled 
totaly seperate. 

And one tree that deals with the windowing system, that tree can than be
totaly
device independed. 

Mircowindows is already setup like that i guess , but it would in my
opinion
be nice to have them totaly seperated, that way the interfaces are more
clear
and one isn't forced to update the windowingtoolkit everytime there are
made new drivers. 

- Erwin

: So my question is , wouldn't it be a idea to split up micro windows
: in two source tree's on that offers the general drawwing interface
: to the framebuffer, X11, win32, hardware etc. that can be compiled
: totaly seperate.

Having them split into separate directories, like they are in 0.87preXX,
is good enough, IMHO.



:
: And one tree that deals with the windowing system, that tree can than be
: totaly
: device independed.

It already is.  Basically, src/drivers/*.h are the device-dependent
hdr files.  src/include/device.h is the drawing engine hdr file,
and src/include/nano-X and src/include/windows.h are the Nano-X
and Microwindows API hdr files.  src/engine is the engine, src/drivers
are the drivers, src/nanox is Nano-X api, and src/mwin is Microwindows
api.


one isn't forced to update the windowingtoolkit everytime there are
: made new drivers.

A recompile is all that's needed now, never a source change.  I like your
idea though, and I've been thinking about having each of these
libraries take the form of a shared library, with the drivers possibly
auto-loaded.
That would solve your problem.  However, in the spirit of "keep it small",
I haven't done that yet.

Regards,

Greg