I'm not a big fltk2 user (though I do dabble) so I can't really say how much impact the fltk3 changes would have. I like the way fltk3 is looking so far, but I have a lot of fltk1 code around. I don't mind changing to the fltk3 API, but the compatibility layer will make that easier.
On 10 Jul 2011, at 14:49, Matthias Melcher wrote: > > So here are my options: > 1: keep F1 and F2 development active, forget about F3 Might work, though I think fltk3 is worth pursuing at this point. > 2: abandon F2, continue with F1, forget about compatibility That's kinda what I did in my work anyway (and others seem to have done the same, Mike, Matt, Greg, to name a few...) but fltk2 did not die. OpenSource is like that... > 3: abandon F1, continue with F2, forget about compatibility Does not seem likely (see response to (2) above!) > 4: merge F2 into F3, forget about the compatibility layers Again, see response to (2)... > 5: merge F2 into F3, continue with the compatibility layers This seems like the best bet *to me*, though we might get away with a less complete fltk2 compatibility layer, since the fltk2 API moved around a bit anyway, and it *seems to me* (probably wrongly) to have less of an installed base. Though the dillo people, Nuke, cinepaint, et al might take issue with that... Anyway, what I was thinking that we get the fltk1 compat layer working as well as possible, but caveat it that things may not work quite right - maybe even document some typical workarounds if there's any pattern to the failures... We do the same for fltk2, but maybe accept a lower level of coverage and more workarounds. This assumes that we think that approach most efficiently reflects the needs of the installed base. In any case, once fltk3 is "good enough" we encourage folk to consider moving to that for new applications, with a view to deprecating the compat layers "eventually". Or something. -- Ian _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
