On 05.10.2009, at 17:01, Albrecht Schlosser wrote:
>> 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.
Great, thank you.
>> 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?
It is probably not even required anymore, but we will see. The
coding_style() would set a flag that determines if future constructors
create Window or Group relative coordinates, and automated begin().
But with my current dea, it is not even needed anymore (could be
optional though).
>> 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() {
Well, the Widget class will have a new flag which determines the
coding style. If the buffer was created with the FLTK1 style set, the
buffer will be copied before it is returned. The coding style will be
automatic by default, so creating an Fl_Text_Buffer will set this
flag, while fltk::TextBuffer will not.
>> 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?
Unfortunately, C++ is missing a true "alias" functionality, so I had
to come up with something.
In a first step, I will naively convert FLTK1.3 into the naming scheme
of FLTK2. This will not add (or remove) any functionality to 1.3. It
will just rename all classes from, say Fl_Pack to fltk::PackedGroup.
The header files go from FL/ to fltk/.
Next, to make 1.3 applications work again, we need the corresponding
Fl_ stubs. A new FL/*.H will look something like this
(Fl_Text_Buffer.H):
> #include "../fltk/TextBuffer.h"
>
> class Fl_Text_Buffer : public fltk::TextBuffer {
Constructors need a stub:
> Fl_Widget::Fl_Widget(int x, int y, int w, int h)
: fltk::Widget(x, y, w, h) { coding_style(FLTK1); }
and only functions that return an fltk style type will get a stub cast
here:
> Fl_Text_Buffer *Fl_Text_Editor::buffer() { return
reinterprete_cast<...>(...); }
After this step, 98% of FLTK1 software should compile and run. The
only major difference is a somewhat messed up class hierarchy. Since
the Fl_ classes are only stubs, for example Fl_Slider can not
reference Fl_Valuator anymore, but must reference fltk::Valuator
instead.
In a third step, finally some brain is required. We need to make the
FLTK2 apps compile as well, so now we need to clear the remaining API
differenced, like the one you mentioned above. That one is easy to
solve:
> char *Fl_Text_Buffer::text() { return strdup(fltk::TextBuffer()); }
But some are a lot harder, like group-relative coordinates for all
widgets that don't have FLTK1 fag set. The list of differences is in
README.123 . There are also many minor changes for function names,
which should all be resolved in inline functions.
In this phase, we can go class by class and function by function and
find incompatibilities to existing FLTK2 software. Once those are
ironed out, we can probably throw the FLTK2 bug list away and many
issues of the FLTK1 which relate to UTF8 and some missing API issues.
>> 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.
Yes, I though that too, but when we merge 1 and 2, we will have to
look at the source code off both, and even if FLTK2 has become quite
weak over the years of neglect, it nevertheless has a great base, and
many of our FLTK 1.3 bug may vanish, simply because FLTK2 may have a
solution already (specifically UTF8).
> 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.
No worries. I will put a few nights into this, and we will see quite
soon, if this is feasible, and if it has the benefits that you
mentioned above (less total development time, but also a larger user
base).
Thanks for reading through all this ;-) ,
Matthias
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
