DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending] Link: http://www.fltk.org/str.php?L2308 Version: 1.3.0 Yuri, you wrote: > i think there is no reason leave return type of argument to be long. I think that we should keep the API (literally) so that we keep the 'long' return type. This way most user's won't need to change any code or other data types. > it may cause value lost of value in some future codes. The only problem is with Windows 64bit systems, and users compiling code for these systems need to handle that "long/pointer incompatibility" anyway. > if we decide use typedef fl_long we must use it everywhere to avoid > future errors. My intention is to have the least impact on application developers for the transition from FLTK 1.1 to 1.3. We decided that FLTK 1.3 should be API compatible as much as possible, so that FLTK 1.1 source code compiles well with FLTK 1.3. Again, this will not be given for users that also switch from 32-bit Windows to 64-bit Windows systems, but this is its own problem. Taking this as a reason to change the API for all users is not what I think is appropriate now. > P.S. I think that on 'normal' systems this will only be a 'cosmetic' > changes and we only must recomended use of fl_long in fltk manual (and > use in in all examples of course). It might be true that most of the code will compile anyway (maybe with warnings), but why would we want to change the API w/o need, if there's a way that we can fix the issue w/o doing so? Having said that: yes, I agree that we should think about changing the callback related API and semantics in a future version of FLTK. But IMO this should not be FLTK 1.3. And if we do, then we should do it "The Right Way". P.S. I hope that I can post my version of a patch during the next few hours... Link: http://www.fltk.org/str.php?L2308 Version: 1.3.0 _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
