> > 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. Sounds great, just added a new TODO.utf8 canvas, Please fill the minimum tasks to do in this file, so that discussions won't be lost in the flow of messages, I added your point as a starter but need your help and probably at least Ian's help too for it to be filled.
> > >> (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. Frankly, I feel that just UTF8 and the new documentation is worth the new 1.3 version, but we all know that much more has been done so I would vote for dropping the Fl_Tree_Browser and Fl_Table for post 1.3. Honestly, I am afraid that we stilll have a hell of a work to finish with what we already started in 1.3 ... > > 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. Again, you're right here: I think many 'bugs' could just be RFE or could close w/o resolution. Still, we have more bugs than in 1.1, I think also that the new configure defaults raise more easily new bugs (I don't know why I think about OSX? <smile here>) ./.. > 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. I'll highly second that, please, let's focus more on bugs and have a more realistic approach. > > Matthias Fabien _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
