nanogui@linuxhacker.org

: In the following example I create a window with a red square that is
: supposed to turn blue for 10 seconds when clicked, but remains red. If I
: remove the 'sleep' and 'change back to red' I see that it does indeed turn
: blue when clicked.
: 
: Anyone have an explanation?

You problem is most likely that you need a GrFlush() call to
tell Nano-X to flush the graphics draw commands from client
to server.  Normally this happens on the call to GrGetNextEvent.
All graphics commands are queued in a local client library
buffer for speed reasons.  You end up seeing the red square
because it draws the blue then red quickly after ten seconds
have elapsed and the flush happens in the return to GrGetNextEvent.




: Also in general what is the split in users/programmers between the Nano-x
: API and Microwin API. Which is most likely to 'succeed' in the handheld
: device market?

There seems to be quite a few developers using both.  However,
the mwin32 API is currently only suited for applications that are linked
with the server, although someone has created a version that is
client/server, to a degree.  Nano-X is being used as the api for
all the widget set ports since it allows multiple processes to connect
to the server.  Both APIs share the same engine draw code, with
minor changes to the window clipping.  I intend to merge the window
clip code at some time as well.



: 
: And also... I'm finding that only root can run the Nano-X stuff. Is this
: usually or have I missed something in the set-up?

I'm thinking that only root users can open /dev/fb0.  Does anyone know
of a way for non-root users to talk to /dev/fb0?


Regards,

Greg