On 13.03.2010, at 14:08, Matthias Melcher wrote:
>
> On 13.03.2010, at 13:25, Albrecht Schlosser wrote:
>> Can you elaborate what your current plan is? I'm curious ;-)
>
> Sure. The plan is to have the FLTK2 API on top of the stable FLTK1 core,
> while staying source code compatible to both versions. The history is this:
-- snip --
> 4: Rename everything to use FLTK2 class names. Then double up the class tree
> where Fl_Group, for example, is derived form fltk::Group (Fl_Window then
> would be derived from fltk::Window which in turn would be derived from
> Fl_Group). Even though this adds some complexity, it also seems to solve all
> issues for existing (non-fltk-library) code. The resulting code actually does
> compile easily with both versions and without changes. Even deriving new
> classes works like a charm. The process is not as straight forward for the
> core team.
>
> Let's look at the fltk::Widget - Fl_Widget pair: all function arguments
> should use fltk::Widget. So no matter if an fltk::Widget or an Fl_Widget is
> passed, it will be fine. All return values from the library however need to
> be Fl_Widget (or whatever the derived class would be), so that the receiver
> can downcast implicitly.
>
> Example1: Fl_Group fltk::Widget::parent(); must return FLTK1 style
> Example2: void fltk::Group::add(fltk::Widget*); must take arguments FLTK2
> style
Hmm, that looks like a *plan* :-)
> Internally, the code can be intermixed FLTK1 and FLTK2, because Fl_Widget and
> fltk::Widget are binary equivalents. So even upcasting (must be done
> explicitly) is not an issue. In a minimal version, teh fltk::Widget class
> would merely have stubs that forward a function into FLTK1 code:
>
> void fltk::Widget::color(int c) { ((Fl_Widget*)this)->color(c); }
>
> That's ugly but works.
Yep, probably too much casting, but if it works as intended, ...
> The core remains mostly untouched, and we could very soon invite the first
> migrants from FLTK2.
>
> We would then have to decide if we eventually move the FLTK1 code base into
> FLTK2 format, making FLTK2 the new FLTK3 coding style. All new users would
> likely start with FLTK3 eventually and would be very surprised if the core is
> still FLTk1. Also, we would surely move parts of the FLTK2 core to FLTK3,
> resulting in a happy style mix.
>
> Does it matter? Will it hurt maintainability? I don't know - we'd have to
> test and see.
We really have to see how this would all look, and maybe a
GSoC student has some more ideas?
Albrecht
PS: you'd better not use 'join' w/o a path in 123/joinall:
$ which join ; join --version
/usr/bin/join
join (GNU coreutils) 6.10
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
