Article #1031: Proposal for FLTK 3

  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Articles | Show Comments | Submit Comment ]

Article #1031: Proposal for FLTK 3

Created at 17:23 Jan 06, 2011 by matt

I have misused the "links" section to put my proposal there. It's nice though because everyone can comment on my entries. I would like to reach as much of an agreement on this version as possible, or we will run into another source code fork... .

Please check out, comment, and add to: ]


Submit Comment ]

From sedwards, 22:42 Nov 28, 2011 (score=3)

What is the major thrust behind the 3.0 effort:  API or internals?

I'm one of the poor shmucks that jumped onto the 2.0 bandwagon thinking that it was the latest and greatest.  I built something of an application architecture on top of 2.0 that is more reminiscent of what I was accustomed to under BCB/Kylix ("form" based, auto-layout, style control); this required a full set of wrapper classes, and I wound up "tweaking" some of my form classes (ex: single "input" class that leveraged the applicable FLTK input class).

After running into a number of bugs that seemed to be fixed in the 1.0 tree I started backporting (actually, #ifdef'ing so I could switch between 1.0 and 2.0).  This created a huge mess.

I am less interested in the internals of how FLTK does what it does than how I have to interface with FLTK in my applications (ex: I don't care how much of a kludge the dropdowns are, as long as my code doesn't look like a kludge when I use it). 

So, from a philosophical perspective, is 3.0 intended to be more of an "inside out" rebuild or an "outside in" evolution?
Reply ]

From bgbnbigben, 17:09 Mar 12, 2011 (score=3)

Matt, whilst I'm sure this is a question with an obvious answer, instead of having to start from scratch with fltk3, why not use the 2.x base and just build in back-compatibility, like it was originally intended? In fact, why not just build on top of the current 2.x code inside the svn trunk - 2.x is only alpha currently anyway. Sure, there'll be a period of time where it won't have the stability of the 1.x branches, but I'd be willing to venture that it will be relatively stable by the time you manage to get all the back-compatibility done, and if you're using the svn trunk then every bug patched also removes a bug from your code. If stability is the only reason for using 1.x as your code base, why not just use the 2.x branch? It seems like it would save you a mammoth amount of effort in the long run.....
Reply ]

From dejan, 05:19 Jan 19, 2011 (score=3)

*matt*, encouraging news! I am willing to work on FLTK 3 as long as all developers agree FLTK 2 API is going to be maintained *and* there is possibility to use relative coordinates, which I think is a major difference between FLTK 2 and FLTK 1. I always believed FLTK 2 was a major step forward in the development of the FLTK project, and it had my support since the first (CVS) version. Judging from the poll we had on recently, many others think exactly the same.

Second, I believe one of the biggest problem with other C++ GUI toolkits is that *all* of them decided to separate from largest C++ frameworks - STDC++, STL and Boost. I think FLTK would benefit if we closely work with people who work on any (or all) of these. I know there are some people who like FLTK for being "between" C and C++, but I think that should be put to an end. I am not saying we should force ourselves to use STL templates, for an example, but whenever it is convenient, why not? Almost all other toolkits have their own implementation of strings, etc... Why, when we have std::string ?? (Yes, I am aware of the fact that in the past we had chaos with regards to the STDC++ and STL, but it is *THE PAST* :)

Since we are at the beginning of a large re-work of FLTK, we should think about what I wrote above...
Reply ]

From markjolesen, 03:12 Jan 11, 2011 (score=3)

Personally, from what I gathered, and just my opinion, FLTK has some very simple components that are really great. However, I think it would be best served by first taking those things that make FLTK simple and great and back-porting to ``C'' only libraries. That's right, I said it, back porting the cross platform units of FLTK from C++ to C. Face it, QT, Fox, Juice, et. al., C++ frameworks suffer, and thus, FLTK as well. Consequently, GTK suffers as well due to separation of components --- too tight integration, not enough separation. 

What this means is an software architectural change and mindset, which aims to continue to keep things simple.

From what I have seen so far, FLTK already has a `C' base, but has not been separated into individual libraries. The `C++' interface is primitive at best and convoluted, and is not really needed --- it is superfluous.

Therefore, I vote ``no'' to both versions 2 & 3. Consequently, the only reason for going with 1.3.X series is because of UTF8 and the power to do things the way a programmer wants to (no dictation needed).

Regards, Mark J. Olesen

Reply ]

From kapojko, 04:56 Jan 27, 2011 (score=3)

Porting FLTK to C is an idea of a big interest. It'd be great even such descendant will be totally separated from FLTK (without bugfix merging, etc.), thanks to stability of FLTK. Maybe, some API concepts is to be changed in order to gain quality and simple C API; non-OO, maybe (like WinAPI against GTK). Did somebody planned such work?
Reply ]

From matt, 06:40 Jan 27, 2011 (score=3)

FLTK3 will have a simple interface layer. You could write (or generate) a "C" interface that would even support virtual functions via function pointers. The core team has no plans for a "C" interface AFAIK.
Reply ]

From engelsman, 12:53 Jan 07, 2011 (score=3)

Hard to know whether to comment here, or ask in fltk.development :-(

I know that you looked at a compatibility layer a couple of years ago, but do you intend to look at and implement each of the seven areas one at a time, with intermediate 3.0.x releases as each is functional, or do you see simultaneous changes involving parts of more than one area at a time. Or are you waiting to see what people suggest first?
Reply ]

From matt, 14:46 Jan 07, 2011 (score=3)

I ported FLTK to three platforms. This task is different, but the strategy could be similar. I like to pick the simplest test app (hello.cxx) and port every file needed to make it run perfectly, then work my way up in complexity.

I would use the FLTK1 code base as a starter. Then, the header files need to be changed to fltk3 namespace and new naming conventions (Fl_Tab becomes fltk3::TabGroup, etc.). With every header file that is ported over, the matching compatibility file for FLTK1 must be created at the same time so the APIs stay synchronized.

FLTK3 shall have a base class for every F3 class and an interface class for a (any) compatibility layer. These are in place and working 80%. The interface layer can be used for any language compatibility layer, not only F1 or F2, but also a scripting language, etc. . It should live in headers only to avoid bloat in F3!

Once we have all F1 header files ported, the F1 comp layer complete, and all F1 tests compile and run, we can update the file naming and directory structure in src, including all IDE and [C]Makefiles.

Now comes the exciting part: we take the F2 source code and create an F2 compatibility layer from all F2 headers.

We will find a bunch of methods that don't map. This is the time when we can port those features from F2 into F3, deciding for the F1 or F2 or a hybrid way to solve the issue.

Once we are done porting F2 features into F3, all F2 test should compile and run as nicely as the F1 tests. We should now have F3, F3 documentation, and an F1 and F2 compatibility layer. F3 tests should have been created in the process.

PS: I absolutely want to hear from as many users as possible!
Reply ]

From csaw, 16:55 Jan 11, 2011 (score=3)


This is all very encouraging news.

I am an FLTK user, and have been using it as a GUI layer for my Windows/Linux graphics engine for some time, including commercial projects. So far it's been quite simple; procedurally generating editable variables for scene objects within tab groups - a bit like Mayas attribute manager.

Back when I started I opted for F2 as I prefer the namespace API, though I have just recently been re-evaluating this as I'm expanding my tools and need more functional widgets that F2 is lacking somewhat...

I was seriously considering Qt since it's LGPL, though having to learn another API is just too time consuming with the other work I have on.

I originally wrote all my GUI code as templated container classes with the idea that I could 'switch' GUI APIs, and in fact seeing the support for F1.3, and the wealth of addons that people have created - I actually just backported my GUI layer to compile with F1.3 using this technique.

So from one side the F3 ideas all sound great, and it sounds like the best way forward IMO, though I've just decided to go with stability and features over bleeding edge, so then the real question is: Is there a rough estimate of the time to get F3 to a usable (stable) state?
Reply ]

From matt, 17:11 Jan 11, 2011 (score=3)

Thanks for that interesting developer history.

As for a first version of FLTK3: I am currently translating manually and I am not too happy with that. Event though I make quite good progress, I have t retype many lines of code which is boring and error prone. I am considering a semi-automatic translation using SED scripts. If that works, the mapping of 1.3 could be done in a few weeks.

The mapping of FLTK2 is much harder because functionalities do not always overlap, and whatever can't be emulated on the wrapper side needs to move into FLTK3 (which is a good thing, but requires much copy-n-paste coding with additional smarts)... .
Reply ]

From ishti10, 09:50 Jan 07, 2011 (score=3)

hi I would love to join up, and work on the dev of FLTK 3. I loved fltk 2.0's API. I am a bit lost and need some information though. Where can I find the repo and get write privileges? How do we you guys communicate with each other? (I hope IRC) What do I need to do to start working on FLTK 3?

Thanks, ish.
Reply ]

From matt, 14:52 Jan 07, 2011 (score=3)

Get a Subversion browser and look for a version of FLTK, tagged as branch-3.0. Check that out - it's only a proof of concept though - the official start will be based on 1.3.0-final.

svn co fltk-3.0

I never found a decent IRC client that didn't annoy the heck out of me on OS X, but I am willing to give that another try.
Reply ]

From ishti10, 16:46 Jan 07, 2011 (score=3)

ok I used subversion that is in the apt repository for ubuntu. I have all the source code.

I am on the 'official' IRC channel. #FLTK on

Now what can I help code up? I can probably start writing unit tests for fltk 1 and 2 so that once ported we can check to see if all the unit tests run well (signifying a good port).
Reply ]

From matt, 13:29 Feb 05, 2011 (score=3)

My day job keeps me extremely busy this month. I will try to get the F1 to F3 script that I wrote into SVN quickly, so we can experiment with that until 1.3.0 has been released.
Reply ]

From nitinrakh, 08:10 Feb 05, 2011 (score=2)

fltk-3.0 not make on 64bit centos

./configure  --enable-debug  --enable-shared --enable-threads

make === making src === Compiling Fl.cxx... ../fltk3/x.H:63: error: ‘NativeWindow’ does not name a type ../fltk3/x.H:70: error: ‘NativeWindow’ does not name a type ../fltk3/x.H:113: error: ‘NativeWindow’ does not name a type ../fltk3/x.H:114: error: ‘NativeWindow’ does not name a type ../fltk3/x.H:125: error: ‘NativeWindow’ has not been declared ../fltk3/x.H:133: error: ‘NativeWindow’ does not name a type ../fltk3/x.H:134: error: ‘NativeWindow’ was not declared in this scope Fl.cxx:592: error: redefinition of ‘fltk3::Window* fl_find’ ../fltk3/x.H:134: error: ‘fltk3::Window* fl_find’ previously defined here Fl.cxx:592: error: ‘NativeWindow’ was not declared in this scope make[1]: *** [Fl.o] Error 1 make: *** [all] Error 1

g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj- --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)

uname -a Linux Samarth 2.6.18-194.26.1.el5xen #1 SMP Tue Nov 9 13:35:30 EST 2010 x86_64 x86_64 x86_64 GNU/Linux

plz help me
Reply ]

From matt, 13:28 Feb 05, 2011 (score=3)

Please use FLTK 1.3.   FLTK 3.0 is highly experimental.
Reply ]


Comments are owned by the poster. All other content is copyright 1998-2015 by Bill Spitzak and others. This project is hosted by Seriss Corporation. Please report site problems to ''.