On 12.12.2010 15:05, Domingo Alvarez Duarte wrote: > Here there is most of my diffs to fltk 1.3 trunk hoping they can be > incorporated on the official distribution. > It was tested and seems to work fine with fltk 1.3 trunk as of today, > I'm using it on my applications too.
I took a quick look at the patch(es), and as Matt said already, there are some that would really be good to have in FLTK. However, these lots of changes are IMO /too/ much for FLTK 1.3.0, since we're so short before a release. First of all, you should really separate your big patch(es) in parts that can be applied and tested individually, as RFE's for FLTK 1.4. This is the way to go... Some comments to your patches (my personal opinions only): - we don't need another method and flags to find a group or window. is_window() and is_group() are not necessary. This has been discussed, and we agreed to use as_window() and as_group(). These methods are virtual and don't need another flag() bit like yours, and they do already exist. You should change your code to use them. - changing the structure of the sizes() array in Fl_Group is very good. I also wanted to do this already. But it would probably break someone's code, and we want to be as compatible as possible to 1.1. Conclusion: good for 1.4, not applicable to 1.3.0 (although the sizes array is not officially documented). - if we added the "STL-ish" vector(s) as public classes (probably a good idea), they should be named accordingly: Fl_Char_Vector instead of CharVector etc.. I didn't look at the code very closely, but if they are public, we should make a good design decision. Since they are only local now, this doesn't matter much (but I don't say that they are wrong ;-)). - the Fl_Group's User_Event_Handler is not a bad idea, but it would take another pointer in Fl_Group. Anyway, we should consider this... There are also other proposals to intercept system events *before* they are used by FLTK, but this is probably another thing to handle, and I assume that we could have both. - Fl_Input_ extensions: I don't think that we need new method(name)s for the setter methods, we could simply overload the value(char*) method: value(int), value(double). However, we would need new names like your value_int etc. for the getter methods... - CTRL/A for Fl_Input: personally I would like to have it, since most probably expect it. I'm not used to all the existing editing shortcuts used in Fl_Input etc.. - Fl_Help_View: I didn't look at your current version, but the major reason why it was rejected was that you didn't adhere to FLTK coding standards. I didn't check (and compare) your current version... - FL_EXPORT additions: I'm not sure about these, but I believe that they are needed for DLL creation, right? If so, they *should* be applied to FLTK 1.3.0. Conclusion: Please post individual STR's (I propose as RFE for FLTK 1.3 (!)) so that we can decide whether they can be included in 1.3 or moved to 1.4 (or maybe also rejected). Thanks for your great efforts to improve FLTK! Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
