>> Just defining the FLTK UTF8 API would be a huge step toward >> cleaning up.
I would really welcome this step, because that would help me to understand exactly what we are talking about here! >> Next step would be to remove code duplication and consistently >> use the utf8 functions for *all* string handling. > Fully agree - we have quite a lot of good stuff in there, but it > needs rationalisation. For example, the code now includes several > (slightly different) functions for counting UTF8 characters in a > given byte array. There are similar examples of duplicated or > overlapping functionality. > > This is sort of because we have OksiD's stuff *and* the stuff I > merged in from fltk2. I tried to standardise on the fltk2 functions, > assuming that was going to be the way towards closer integration, > but maybe that was the wrong choice? Maybe the two steps need to go hand in hand, that the API for each capability needs to be discussed and documented, and then the various implementations either replaced by the new API version or re-written to call it so that we can test and phase out the variants step-by-step. Cheers D. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
