On 13.03.2010, at 13:25, Albrecht Schlosser wrote:
>> -/* \file
>> - Fl_Window widget . */
>> +#include "../fltk3/Window.h"
>
> Unfortunately "../fltk3/Window.h" is missing in svn. Please see also
> below.
>
>> Modified: branches/branch-3.0-matt/README.123
>> ===================================================================
>> --- branches/branch-3.0-matt/README.123 2010-03-12 21:14:19 UTC (rev
>> 7250)
>> +++ branches/branch-3.0-matt/README.123 2010-03-12 21:54:51 UTC (rev
>> 7251)
>> @@ -687,3 +687,17 @@
>> 2: struct NamedStyle
>>
>>
>> + CONVERTING A CLASS
>> +
>> +- find the matchin headers
>> +- copy the FLTK1 header to fltk3
>
> This should IMHO read:
>
> *svn* copy the FLTK1 header to fltk3
Doh. Yes, of course. This is all still quite experimental. Now that I have a
way of comparing both libraries on a function-by-function base, I will have to
come up with a better plan... .
> 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:
1: I tried typedef'ing from fltk::Widget to Fl_Widget, but that does not work.
The new type is "Fl_Widget", not "class Fl_Widget". Source code that uses the
statement "class Fl_Widget;" will trigger a syntax error. Also, we would not
know at creation time if the user wanted an FLTK1 or FLTK2 widget. This is
important because both behave slightly different.
2: I tried #define Fl_Widget fltk::Widget. Boy, that caused a headache (not
entirely unexpected though). This truly is Pandoras Box!
3: I tried to have two dependency trees in parallel, where the Fl_Widget would
have a pointer to fltk::Widget, Fl_Group to fltk::Group, etc. . This is better,
particularly because the "friend" statement solved a ton o fminor issues, but
for derived classes in FLTK1, all references to a variable would have to be
prepended with "p->" which is a lot of work.
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
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. 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.
What I checked into SVN does not follow these ideas yet. It will not becom the
new repo simply because Fl_Printer and Fl_Device are not there yet ;-)
>
>> Modified: branches/branch-3.0-matt/src/Fl_Window_iconize.cxx
>> ===================================================================
>> --- branches/branch-3.0-matt/src/Fl_Window_iconize.cxx 2010-03-12
>> 21:14:19 UTC (rev 7250)
>> +++ branches/branch-3.0-matt/src/Fl_Window_iconize.cxx 2010-03-12
>> 21:54:51 UTC (rev 7251)
>> @@ -29,7 +29,7 @@
>>
>> extern char fl_show_iconic; // in Fl_x.cxx
>>
>> -void Fl_Window::iconize() {
>> +void fltk::Window::iconize() {
>> if (!shown()) {
>> fl_show_iconic = 1;
>> show();
>> @@ -38,7 +38,7 @@
>> ShowWindow(i->xid, SW_SHOWMINNOACTIVE);
>> #elif defined(__APPLE__)
>> #ifdef __APPLE_COCOA__
>> - MacCollapseWindow((Window)i->xid);
>> + MacCollapseWindow((Fl_Window*)i->xid);
>
>
> Hmm, the above is maybe wrong. Does it compile?
Oops, yes, that is wrong. Damn the string-replace function ;-)
> There's a _typedef_ in the old code (and that is really confusing for
> me, but Manolo should know about it) at line 79 in FL/mac.H:
>
>
> #ifdef __APPLE_COCOA__
> [...]
> typedef void *Window; // this is really a pter to the subclass FLWindow
> of NSWindow
Yes, this is extremely confusing and must be removed first.
>
> Sorry if I'm wrong, but I thought it's worth to be checked. I found
> it by reading the diff, no testing or compiling ...
Thanks, yes, you are absolutely right.
- Matthias
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
