nanogui: Thread: ideology of flnx

I was wondering as to the ideology of the FLTK / Nano-X port.  It seems
very curious - it was branched off of FLTK 1.0.7 (over a year ago) and it
seems as though there has been no effort to keep it synced.  Is this
intentional?  That is, is FLNX a distinctly different beast, or has the
effort simply not been made to keep it current?

On the one hand, if it were kept current, it is conceivable that nano-x
could be one of the standard build options for FLTK.  On the other hand, if
FLNX is distinct, then why bother #ifdef'ing all of the NANO_X code, and
not simply replace what exists with what it should be specifically for
Nano-X?

-David

FLNX and FLTK are indeed the same animal (except for a few new widgets that 
we have stuck in here and there).  

It have been our intention to merge FLNX and FLTK.  In fact, plans were in 
place before the original FLTK developers left the project, and it languished 
some what.  FLTK is currently on 1.0.11, and the few bug fixes that we have 
found to since 1.0.7 have already been added to the FLNX tree.

There is a FLTK 2.0 in the works (currently in CVS beta), and we are planning 
(once again) to merge the two (but I am unsure of when that will happen).

So for now, we stay separate, but interchangeable (FLNX can run applications 
built with FLTK 1.0.11, and vice versa).  

If anyone wants to take a look, you get FLTK 2.0 instructions from:
http://www.oss3d.com/fltk2diff/

Jordan


On Thursday 12 July 2001 23:05, David T Eger mentioned:
> I was wondering as to the ideology of the FLTK / Nano-X port.  It seems
> very curious - it was branched off of FLTK 1.0.7 (over a year ago) and it
> seems as though there has been no effort to keep it synced.  Is this
> intentional?  That is, is FLNX a distinctly different beast, or has the
> effort simply not been made to keep it current?
>
> On the one hand, if it were kept current, it is conceivable that nano-x
> could be one of the standard build options for FLTK.  On the other hand, if
> FLNX is distinct, then why bother #ifdef'ing all of the NANO_X code, and
> not simply replace what exists with what it should be specifically for
> Nano-X?
>
> -David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

: I was wondering as to the ideology of the FLTK / Nano-X port.  It seems
: very curious - it was branched off of FLTK 1.0.7 (over a year ago) and it
: seems as though there has been no effort to keep it synced.  Is this
: intentional?  That is, is FLNX a distinctly different beast, or has the
: effort simply not been made to keep it current?

We have planned from the beginning to have the Nano-X port of
FLTK go back to the FLTK maintainers for permanent inclusion.
However, since we're a few revs behind (and they're actually at
2.x now), we need to upgrade before they'll likely accept it.
We're going to be starting a project soon where we'll be moving to
the latest 2.x version of FLTK, and make it work with Nano-X,
with resubmission to fltk.org.

: 
: On the one hand, if it were kept current, it is conceivable that nano-x
: could be one of the standard build options for FLTK.  On the other hand, if
: FLNX is distinct, then why bother #ifdef'ing all of the NANO_X code, and
: not simply replace what exists with what it should be specifically for
: Nano-X?

I very much dislike the underchassis of FLTK, with all of it's crude
multiple #ifdefs for win32, X and now, nano-X.  But that's likely to 
remain, since that's the way the FLTK folks wrote it, and they've kept
that approach in 2.x.

Finally, the current FLNX underchassis is a bit messy, since it was
written over a year ago, just when Nano-X was becoming actually
capable of running real graphics programs.  This will be cleaned up
in the 2.x release.

Regards,

Greg

I found an answer: upgrade the bootldr from 2.9.5 to 2.14.5,which support 
backlight.
Regrads
Chen


>From: "Greg Haerr" ####@####.####
>Reply-To: "Greg Haerr" ####@####.####
>To: ####@####.#### "David T Eger" ####@####.####
>CC: "Jason Kingan" ####@####.####
>Subject: Re: [nanogui] ideology of flnx
>Date: Fri, 13 Jul 2001 10:03:35 -0600
>
>: I was wondering as to the ideology of the FLTK / Nano-X port.  It seems
>: very curious - it was branched off of FLTK 1.0.7 (over a year ago) and 
it
>: seems as though there has been no effort to keep it synced.  Is this
>: intentional?  That is, is FLNX a distinctly different beast, or has the
>: effort simply not been made to keep it current?
>
>We have planned from the beginning to have the Nano-X port of
>FLTK go back to the FLTK maintainers for permanent inclusion.
>However, since we're a few revs behind (and they're actually at
>2.x now), we need to upgrade before they'll likely accept it.
>We're going to be starting a project soon where we'll be moving to
>the latest 2.x version of FLTK, and make it work with Nano-X,
>with resubmission to fltk.org.
>
>:
>: On the one hand, if it were kept current, it is conceivable that nano-x
>: could be one of the standard build options for FLTK.  On the other hand, 
if
>: FLNX is distinct, then why bother #ifdef'ing all of the NANO_X code, and
>: not simply replace what exists with what it should be specifically for
>: Nano-X?
>
>I very much dislike the underchassis of FLTK, with all of it's crude
>multiple #ifdefs for win32, X and now, nano-X.  But that's likely to
>remain, since that's the way the FLTK folks wrote it, and they've kept
>that approach in 2.x.
>
>Finally, the current FLNX underchassis is a bit messy, since it was
>written over a year ago, just when Nano-X was becoming actually
>capable of running real graphics programs.  This will be cleaned up
>in the 2.x release.
>
>Regards,
>
>Greg
>
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ####@####.####
>For additional commands, e-mail: ####@####.####
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.