Matthias Melcher wrote:
>
> These days I do the first steps for one crazy transformation. I would
> like get you all enthused (as Teutel Senior would say - gosh, I miss
> that show) and excited about what I am planning.
>
> FLTK 1 over the years has become a nice starting point for the first
> steps in GUI programming. It runs on al major platform (and on many
> minor ones as well), is small, compact, and easy to use. FLTK 2 was the
> attempt to continue the success of FLTK 1 with a much cleaber API and
> many important details improved. Unfortunately many users never made the
> jump to FLTK 2 and so it not only ended in a crawling slow branch, it
> also became instable and at last unmaintainable.
>
> I would like to spend some of my spare time to create FLTK 3.
That's a great idea. I'd like to help, if I can.
> FLTK 3 sets out to surprise FLTK 1 users and satisfy FLTK 2 junkies. It
> will basically be the improved FLTK 2 API combined with the quite stable
> innards of FLTK 1. As an extra bonus, FLTK 3 will be compatible to 1 and
> 2. Just prepend your code with the "coding_style" instruction and FLTK 3
> will do the rest. It is even possible to intermix FLTK 1 and FLTK 2
> coding styles within a single project.
I'd like to hear more about that "coding_style" instruction. What is it,
how does it work?
> Nice challange, eh? So let's get going.
A *BIG* challenge, I guess.
> I have added a file to the 1.3 repository "README.123" which lists all
> differences between version that came to mind.
>
> I would love to hear your comments, know about stuff I did not list,
> collect suggestions, and then get the fish swimming as soon as possible.
I'm afraid that there are semantics that we can't adapt easily. One
example that I found just today by chance (from FLTK-2 src/TextBuffer.cxx):
/**
* Return the entire contents of the text buffer. ...
*
* Unlike previous versions of fltk, DO NOT FREE THE RETURNED RESULT!
*/
const char *TextBuffer::text() {
<snip>
The CAPITOL letters are the problem here: in FLTK 1.x you MUST free the
returned text(). And to make it worse, in FLTK-2 it is const, whereas it
is not in FLTK-1. I changed the editor.cxx test program in both versions
for a test, and I ran into the "const" problem when I copied a simple
2-line test statement from FLTK-1 to FLTK-2. :-(
This is only a small example, but what else is waiting for us?
> As a little bonus, I made Fluid 1 read Fluid 2 files. There are still a
> bunch of bugs and it's mostly untested, but it is a start at least.
Nice :-)
> PS: in case you are wondering about this moment in time, particularly
> with a huge bug list in FLTK 1.3, 1.4, and 2.0. Well, even though the
> bug and feature list in 1.3 is long, it is very usable in this stage.
> Fixing some of the issues will require backporting FLTK 2 code (mainly
> the UTF8 stuff), so why not port forward instead?
IMHO we should only try this, if we are sure that it will
(a) save time
(b) don't bring instabilities into FLTK 1.3/3.0
What are you particularly thinking of to port forward? TextDisplay and
TextEditor, perhaps?
> Anyway, for now, I call this hybrid 1.3. But as soon as 1.3 links with
> Dillo, I will make it head of the SVN repository and call it 3.0... .
I like that goal too, and in fact, I proposed it a few days ago (to make
the new version the head (trunk)). But my *feeling* is that we should
first try to get a stable 1.3 version before we try to create a FLTK-1
and FLTK-2 compatible version.
However, I don't want to sound too pessimistic. I'd *like* to be
convinced that the proposed way is the better way, and that it is doable.
Thanks for all your efforts to create a better FLTK !
Albrecht
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
