DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending] Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current Manolo: > Now the CR/LF issue has been solved, we have to decide between > the two proposed solutions to this STR. > > 1) Matt's solution: just transfer the file data to the > Fl_Text_Buffer widget even if it's not UTF-8 encoded and arrange > for the FLTK code to accept these data. > ... > 2) The solution proposed in attached file Fl_Text_Buffer2.Patch: > only correct UTF-8 data ever enter the Fl_Text_Buffer widget. > ... Option 1 of "keeping the original text but make the code jump through hoops in order to work round unknown characters" seems wrong to me and will mean adding spaghetti code on top of other spaghetti code. I would favour option 2 *but* I think that the proposal as it stands is still too "hard coded" using static functions, and it would be much better if we could define a class interface that could be used so that we can add classes over time, and application developers can add or override character set translations if required, and we can also extend to handle multibyte character encodings. I'm just worried that an "interim fix" to get 1.3.0 out of the door becomes fixed in stone and even more difficult to replace/extend later. HOWEVER, as I have no time to contribute any code until mid-January and therefore after the 1.3.0 release, I shall go with the flow... Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
