On 16.11.2010, at 08:42, Domingo Alvarez Duarte wrote: > En 16/11/2010 01:03:17, Greg Ercolano <[email protected]> escribió: > >> Hmm, but isn't that the same as deriving a MyIntInput class >> from Fl_Float_Input, and then referencing it inside fluid >> by dropping an Fl_Int_Input widget into the fluid form and >> setting the "Class:" field in the C++ properties to MyIntInput? >> > > On the original specific question yes it's the same but as a generic > broader solution it isn't, for some things it's easier to have extra > fields/methods from the base classes. > > Like for the "const char* field_name;" if we set it on FL_Input_ we have > it for all it's derived classes with less code and everywhere we use our > customized fltk.
OK, hmm, you recent mails hit some very important spots, so I would like to write a longer answer. Part 1 (fixing Fl_Int_Input): Well, about Fl_Int_Input: you have experienced problems with that widget. It is very difficult to use for precise positioning. You could say that the widget is the wrong choice for what it is supposed to do in Fluid. I'd take it one step further and say that the widget design is just plain wrong. The widget doesn't do what the user expects. It has many features that are not obvious at all, even worse, that are contrary to what the user expects. Dragging the mouse over text should *select* the text, and not increment or decrement the value. Adding the Ctrl modifier support is completely invisible to the user and makes the widget even more confusing. There are two solution that I see: 1.1: Fluid should not use this widget. Positioning can be done visually and to the pixel in the designer. The properties sheet should be limited to numeric input. 1.2: The Fl_Int_Value widget needs a complete redesign. There are plenty of ways to do this and plenty of examples in other GUI kits. Just because this widget was in the Forms Library doesn't mean we have to keep it. We can still keep the API, if we want to. FLTK 2 threw this widget overboard and replaced it with something much more intuitive: you change the value by positioning the text cursor and pressing up or down to change that count. Now all it needs is a visual indicator that the user can use up and down, and we have the perfect new widget. It would almost make sense to use it in Fluid now. Part 2 (adding #define's to the source code): C is a bad language, C++ is even worse. Adding elements to a class is only possible via inheritance, or by adding universal fields in base classes. There are very many attempts to get around the limitations of C++. The "Widget Association" solution by Andreas in STR #2402 is one of the more elegant ones, but still a crutch. The problem is the choice of language. You may have seen a lot of script bindings to FLTK (Lua, Python, etc.). Well, they exist because their developers don't want to be limited to what C++ offers. Your suggestion of adding #define's everywhere in the source code is another crutch for the shortcoming of C++. Please do not do that to yourself or your code. #define's and all the other macro tricks are just that, tricks. They will bite you eventually because you (or your build environment) will no longer be able to understand which file depends on what, and you will end up in a huge mess of code that can no longer be debugged (trust me, I have been there). Again, I have some solutions for you: 2.1: use the 'better' crutches. #define is no option. If I could, I would kick them out of the entire FLTK source code. Association would solve some of your problems, including those that Greg mentioned. I give it a +1 and I think it is very likely that you will see them in 1.3.1 or whatever else comes after 1.3.0 . 2.2: instead of fixing the widget at compile time, we must fix widgets at design time. If they are designed wrong, it's back to the drawing board, redesign, implement, distribute, test, redesign. But more importantly, instead of making the widget fit the use, use the widget that fits the needs (see 1.1). 2.3: maybe C++ is not the right language for your project. NewtonScript (admittedly a dead language) allows adding features (functions and variables) at run time to any class system wide. There is, for example, an address book app in NewtonScript which has no field for web addresses. No problem, just add it to the base class, and all address based applications will automatically support it. I know that there are tons of languages out there that provide similar features. FLTK can only provide the little Lego bricks to build the GUI. Conclusion: Fl_Int_Input is bad. It must be redesigned in the next iteration of FLTK. Many widgets in FLTK were designed 14 years ago. Maybe we should go through them one by one and ask ourselves if they are still up to their task. But please, let's do it right. - Matthias _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
