DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature First off, thanks for helping out so thoroughly in this rather pesky area. :) We'll start of with the mac portions: > With the patch, the result is unpredictable, that is, not reproducible. > This is because there is a memory allocation problem in these statements: The object lifetime handling on Mac takes some getting used to and I can't say I was entirely sure things were correct. From what I understood, most things are put in a "autorelease pool", which generally meant they lived long enough for the event to be processed but no longer. I assumed that e_text and friends were only valid from an FLTK event handler, and hence the lifetime of these objects were sufficient. This was also before I had considered the more advanced input methods. A more robust allocation scheme like the one you have proposed is very much welcome. > Also, I don't understand why you build Fl::e_text in setMarkedText as > the concatenation of the previous Fl::e_text and the received string. This was added to deal with how OS X deals with bad compose sequence. E.g. press dead tilde twice, which will result in: Press 1: setMarkedText (tilde) Press 2: insertText (tilde, overwritting the earlier tilde) setMarkedText (tilde) Hence the need to concatenate the data from insertText with the one from setMarkedText. > I would also suggest that you put the cocoaDead2FLTK function in your > application code rather than in FLTK itself. I added this method for two reasons: 1. We need a set of platform independent symbols, as we cannot rely on all three platforms having the exact same representation of dead keys (they don't). 2. I did not want to use the "non-dead" versions of the symbols as that could possibly create ambiguities. Say on X11 where you could generate ò using either "<dead grave> <o>" or "<compose> <grave> <o>". So for applications that want to see the specific symbols, differentiating between "dead" and "non-dead" seemed important. And since Unicode has an equivalent concept in combining characters, that seemed like a good symbol set to use. (The Win32 code has a similar translation routine) Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature
_______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
