On 11.07.2011, at 16:37, Edzard Egberts wrote:
> Matthias Melcher schrieb:
>>
>> On 11.07.2011, at 14:26, Edzard Egberts wrote:
>>
>>>> I added a wrapper that makes FLTK 1 source code compile with the
>>>> FLTK 3 library. This is a true wrapper, not just some #define
>>>> list of new names. I have started a very minimal wrapper that
>>>> makes FLTK 3 source code compatible to FLTK 2 as well. To verify
>>>> the effort, all FLTK 1 tests compile and mostly run in this
>>>> wrapper mode. There are still a lot of bugs though!
>
> I want to understand this right - you mean a lot of wrapper related bugs?
Yes, bugs in the wrapper code. FLTK 3 itself should be pretty much as bug free
as the version that we forked of. The diffs from that version still need to be
patched into F3.
>> The wrapper happens to 99% in header files in a separate directory.
>> There are only very minimal additions in FLTK3 to make the wrapper
>> work, which is, every class has one additional pointer to the
>> wrapper, and every virtual function has a few lines of extra code
>> that starts with:
>>
>> if (wrapper) { (...) }
>
> I continue not to like this, to much "every" and it feels to me, it's
> not the way "virtual" is ment for. Wrapper should be a layer,
> overwriting virtual.
I mean "virtual" functions. This is pretty much limited to fltk3::Widget::show,
::hide, ::draw, ::handle, and the destructor. I purposely did not intermix the
F1 and F3 class hierarchy, because that would mean that we have F1 code inside
of F3. However, now that you mention it, there could be a *very* elegant way of
having an WrapperToFLTK3 class layer that would not show up *at all* in the
FLTK 3 world!
I will give this a shot tonight. That would limit the overhead in FLTK3 to one
single pointer per widget and one "if" in do_callback().
>> The wrapper generates very very little code if not used!
>
> The wrapper generates overhead, even if not used. ;o)
>
>> An additional benefit to having the wrapper is the ability to create
>> a perfect wrapper into pretty much any scripting language.
>
> One click wonder (Eierlegendewollmilchsau)? Maybe keeping it simple is a
> better goal, than providing support for *potential* new purposes?
Egg laying wool milk pigs aside, that's just the nature of the wrapper.
>>> Also this way goes on, to leave developers stuck to old code.
>
> Thinking some development steps further - are you sure, the wrapper will
> keep downwards compatibilty all the time, when people are using old code
> and old concepts? Wouldn't it tighten developers to think down
> compatible? I would prefer to switch and keeping involved, even when it
> is necessary, to readjust code from time to time.
That is a very good point. Keeping the wrapper fully compatible, even when the
FLTK 3 side changes, is additional work. There will be a day when we abandon
the wrapper. Hopefully, all code is FLTK3 by then.
- Matthias
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
