nanogui: Thread: Microwindows/Nano-X version 0.87pre1 released

I have prepared an interim release of Microwindows and Nano-X enhancements,
which
completes many things folks have asked for, version 0.87pre1.  This is available
for
download at:
    ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.87pre1.tar.gz

The major enhancements include:
    o support for running under X11.  Microwindows and Nano-X can now run as a
user-defined (default 640x480) window under X Windows.  The graphics output
and look and feel are identical to framebuffer, but will run on any X display
server.
Compile-time options allow configuration to emulate any of the Microwindows
truecolor or palette modes, in any pixel depth, including grayscale.  This
allows
a Microwindows or Nano-X application to be emulated exactly, regardless of
the host's or target's framebuffer characteristics.  Thanks to Tony Rogvall for
the X11 driver.

    o the client/server network code has been completely rewritten for
_speed_!!!
I studied the X11 Xlib implementation and came up with a similar implementation.
By queuing all client data until an event or reply is required, Nano-X now runs
at extremely high speed.  Unlike the Xlib implementation, Nano-X still runs
synchronously per client, meaning that once a client request packet is sent,
the server waits until the whole packet has arrived until servicing another
client.
This keeps the server code immensely simpler, while still running very quickly.
I urge interested folks to check out the implementation, in
mwin/src/nanox/nxproto.{ch}, and mwin/src/nanox/client.c.

    o routines were added to allow Nano-X to be used as a "passive library",
meaning that an application with it's own main loop can now call into Nano-X
occaisonally (after a select returns a file descriptor that Nano-X is interested
in),
and it will all work.  This was done for Morten.  See mwin/src/nanox/client.c,
functions GrPrepareSelect(), GrServiceSelect(), GrMainLoop().

    o routines were added to get the system palette, and translate an RGB color
to a PIXELVAL palette index.  This was for Richard and the Opera browser.
See mwin/src/nanox/srvfunc.c, functions GrGetSystemPalette, GrFindColor().

    o a null mouse driver was added for systems without a mouse, by setting
NOMOUSE=1 in Makefile.

This is released as 0.87pre1 because I still haven't finished the directory tree
reorganization, and adding Martin's cool X11 graphics makefile configuration
tool.  The client/server code rewrite took alot more time than expected.
I am also working on getting all source on CVS.

Please try it out, and send bug reports and enhancement requests to me or the
nanogui list.

Greg

> at extremely high speed.  Unlike the Xlib implementation, Nano-X still runs
> synchronously per client, meaning that once a client request packet is sent,
> the server waits until the whole packet has arrived until servicing another
> client.
> This keeps the server code immensely simpler, while still running very quickly.

That kills you on a network or a client hang at the wrong moment. Reblocking
the data isnt hard but it can be sorted later. The big thing with reblocking
in nanogui will be keeping the max command length low to avoid large buffers

>>>>> "Alan" == Alan Cox ####@####.#### writes:

    >> Nano-X still runs synchronously per client, meaning that once a
    >> client request packet is sent, the server waits until the whole
    >> packet has arrived until servicing another client.  This keeps
    >> the server code immensely simpler, while still running very
    >> quickly.

    Alan> That kills you on a network or a client hang at the wrong
    Alan> moment. 

I would argue that this may not be acceptable.  In addition to being
small and fast, I think one of our design goals should be that it is
robust.  And when I say robust, I mean so robust that I could
comfortably use it for my avionics.  When my GPS reciever locks up
(happened to me recently), it should not lock up the entire
multifunction display.



-- 
               "So, shall we go act innocent now?"

Daniel Risacher                                   ####@####.####

:     Alan> That kills you on a network or a client hang at the wrong
:     Alan> moment. 
: 
: I would argue that this may not be acceptable.  In addition to being
: small and fast, I think one of our design goals should be that it is
: robust.  And when I say robust, I mean so robust that I could
: comfortably use it for my avionics.  When my GPS reciever locks up
: (happened to me recently), it should not lock up the entire
: multifunction display.

I agree.  It's just more coding.  The previous implementation of
client/server
networking for Nano-X didn't support async reading/writing either.  I'm
happy
to add all this, but the code size will just get bigger and bigger, and the
semantics of exactly how the tcp subsystem work and what errnos
are returned etc start becoming more important.  My initial idea
was to rip all this out of the tested Xlib implementation, but if you look
at it, it's damn near as big as all of Nano-X itself.

Greg