On 25.03.2009, at 16:34, Fabien Costantini wrote: >> (1) Get utf-8 support ready. > Ok, let's specifiy the _minimum_ features to realize before an RC > can be released then. > - First, the TODO.utf8 file is just a list a files (to be treated?), > should be rename TODO_FILES.utf8 if it is still necessary? > - Then a real TODO.utf8 should be updated with a full list of the > features to fix/add > - Then we should establish which are the priority tasks we want to > fix in utf8 for 1.3. (i.e: I doubt it is a good idea to expect > adding all langages supports in our next release : couldn't it be > made progressively after that ?)
IMHO we must bring a clearer line to the UTF8 implementation. I have only been following loosely, but the last time I checked, we were still missing a definitive set of utf8 functions that can then be used to fix Fl_Text_Display and all the other widgets that count characters. Just defining the FLTK UTF8 API would be a huge step toward cleaning up. Next step would be to remove code duplication and consistently use the utf8 functions for *all* string handling. >> (2) Check, which ABI issues should be solved before a FLTK 1.3 >> release. > The point may be : what if instead of expecting to release > beautiful-complete-abi-stable-proofed-the-one version, we just > target smaller/ more manageable/frequent releases (like a new > release every year approx.). > Then I guess it won't be so terrible to wait for the next ABI > change, wouldn't it ? Well, this is exactly why I wanted to limit the whole 1.3 list of improvements to Doxygen, UTF8, Fl_Tree_Browser and Fl_Table. FLTK 1.4 can then have as many new ABI changes as required. Somehow though we all just dumped our wishes into 1.3 and now have a bug list that is longer than the 2.1 bug list. This is hardly helpful. How in the world was it possible that a 99% stable 1.1.10 ended up in a 200+ bugs 1.3 just by adding Unicode support and documentation? And there is still no Tree Browser in sight. >> (3) Fix bugs. > YES, and the fact that the team is bigger today may help better than > before. >> (4) Improve documentation. > Yes, and probably focus on correctness and completeness more than on > the aspect of the documentation, which still matters though. The current documentation is great, and Erco's improvements make it beatiful and consistent. Now if we solve the PDF numbering issue and the above mentioned missing utf8 API, we are fine. Fantastic work! > I can continue to fix UTF8 bugs, but I need a real TODO list to be > established (see upper) and then priorities for 1.3. Yes, precisely. We need to know what exactly to goal shall be, so IMHO we must write and document the API first, then implement it using the give code and apply it throughout the source (unless someone already did and I missed it and should shut up anyways ;-) >> For me issue (2) seems _very_ important, because there are >> lots of old STR's, maybe already from 2005/06 or even earlier, >> that say "we can't do this for 1.1, because it would break >> the ABI". Now we have 2009, and FLTK 1.4 won't come before >> 2010 or 2011, right? Unfortunately, many of these STR's are >> now classified as 1.4 feature requests, but we should have >> an eye on those, too. > Again, I'd highly suggest here that we (maybe you?) establish a TODO- > CHANGES.abi asap so that we can have a clear view a determine limits > to it. Well, most of that stuff should have gone to 1.4. 1.3 was supposed to be purely the addition of utf8, Doxygen, Fl_Tree_Browser and Fl_Table. Any suggestions on how to get out of this problem are greatly appreciated. Sorry, I hope I am not offending anyone, especially since I have not contributed for quite a while. I would really love to get back to 1.1.10 stability. Matthias ---- http://robowerk.com/ _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
