nanogui: Thread: FLTK and Nano-X

I am interested in a toolkit for an embedded system under Linux that
supports multi-processing, i.e. multiple application support, and is
also as small and fast as possible. 

To me it seems like multi-application support is more easily achievable
with Nano-X than MicroWindows, (partly) due to its client/server
architecture. I followed the client/server discussion a while back,
looked at the code, and it seems like this could be made to work without
too much drama. After all, the thing nearly works already in an example
that I have :-) . 

Secondly, FLTK looks lighter weight and higher performance than
gtk++/gdk. So, I think the ideal combination for me would be and
FLTK/Nano-X port, with some work on Nano-X to get the multi-app support
going. 

I would appreciate anyone's opinion on this, particularly my FLTK/gtk
assesment. If gtk is not as heavy as I believe, then I can go with
gtk/Nano-X. Unfortunately I do not have actual memory/CPU usage targets
yet, so I am forced to take an as fast/small as possible stance.

Thanks,

Victor

> To me it seems like multi-application support is more easily achievable
> with Nano-X than MicroWindows, (partly) due to its client/server
> architecture. I followed the client/server discussion a while back,
> looked at the code, and it seems like this could be made to work without
> too much drama. After all, the thing nearly works already in an example
> that I have :-) . 

Or you could extend the client/server stuff to the microwindows side as well
as to nano-X..

> Secondly, FLTK looks lighter weight and higher performance than
> gtk++/gdk. So, I think the ideal combination for me would be and
> FLTK/Nano-X port, with some work on Nano-X to get the multi-app support
> going. 

FLTK is lighter but more limited. For very small embedded things I imagine
the limits dont bite you and size is the big one

: To me it seems like multi-application support is more easily achievable
: with Nano-X than MicroWindows, (partly) due to its client/server
: architecture. I followed the client/server discussion a while back,
: looked at the code, and it seems like this could be made to work without
: too much drama. After all, the thing nearly works already in an example
: that I have :-) . 

Yes, I agree that Nano-X is the way to go for lightweight client/server
multiple process access to a graphics server.  Originally, I wrote
the win32 API with the hopes that it would be useful, and many
people have found it useful to bring Windows programs into
the embedded world.  However, the win32 API wasn't designed
for client/server because of it's use of pointers, and requires a complex
marshalling implementation to do client/server correctly.

As a result of this, I have been reconcentrating my efforts on the
Nano-X API, which is required to get important ports like gtk++
going.  Currently, the win32 implementation is more advanced than
Nano-X, but the engine routines can all be shared, so it's not that
big a deal to bring Nano-X up.  There are some other issues that I'm
working on, which include getting the window-level clipping shared
between the APIs.


: 
: Secondly, FLTK looks lighter weight and higher performance than
: gtk++/gdk. So, I think the ideal combination for me would be and
: FLTK/Nano-X port, with some work on Nano-X to get the multi-app support
: going. 

I agree with your FLTK/GTK assessment.  Currently we have a win32
version of FLTK running, which was performed in order to "test" the
Microwindows implementation.  We need to start in earnest with
a Nano-X implementation of FLTK now, which will bring a powerful
combination to the embedded market.  I'm also working on getting
the gdk port going to Nano-X as well.  BTW, the Nano-X server
should run well when used with the "persistence" option -p, which
keeps the server running after the exit of a client.  There's still
a bug in there somewhere (details on request) but most clients
run well, and the server now removes unowned windows on client
exit.

Regards,

Greg

> FLTK is lighter but more limited. For very small embedded things I imagine
> the limits dont bite you and size is the big one

The widget sets are less rich that gtk, etc, however the framework is
very easy to work with.  You can extend and create widgets to do
whatever you need to very easily by extending the base classes.  Whats
curious though is the extended support for GL stuff..., very
interesting aspect of FLTK.

My underlying point is that the base of fltk may be "less rich", but
in a way it's more rich especially for the embedded sector because it
has all the primitives you need to create something truely rich.
Theme support I believe is coming in fltk2.0 along with lots of other
cool stuff.  Overall I think it's a wise decision to opt for this
widget set for an embedded device.  I've found it easier to work with
than gtk, but that's just my assesment.  (i.e. it doesn't burden you
with rarely used widgets like other widget sets do)

Shane.

Hi , I'm new to this list and I was wondering if anyone new were I could find
apps for microwin ?


####@####.#### wrote:

> > FLTK is lighter but more limited. For very small embedded things I imagine
> > the limits dont bite you and size is the big one
>
> The widget sets are less rich that gtk, etc, however the framework is
> very easy to work with.  You can extend and create widgets to do
> whatever you need to very easily by extending the base classes.  Whats
> curious though is the extended support for GL stuff..., very
> interesting aspect of FLTK.
>
> My underlying point is that the base of fltk may be "less rich", but
> in a way it's more rich especially for the embedded sector because it
> has all the primitives you need to create something truely rich.
> Theme support I believe is coming in fltk2.0 along with lots of other
> cool stuff.  Overall I think it's a wise decision to opt for this
> widget set for an embedded device.  I've found it easier to work with
> than gtk, but that's just my assesment.  (i.e. it doesn't burden you
> with rarely used widgets like other widget sets do)
>
> Shane.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####