> > On May 17, 2007, at 4:15 PM, Stan wrote: > > > I've been trying to develop guidelines for myself to follow > > when designing widgets that are derived from Fl_Group. > > Interesting list. Please keep in mind that overriding non-virtual > functions will not have the expected result if you don't know the > class at compile time. FLTK1 has too few virtual functions, something > we were not able to change without corrupting binary compatibility. >
Yes, I'm all too aware of those issues; in fact I started a thread here some time ago on the subject. It's too bad that the change couldn't be made. Of course, it's an orthogonal issue. The considerations I tried to list would still apply if the methods were virtual. > FLTK2 takes an interesting path right now. Bill decided to derive all > Widgets from Group (instead of the other way around). This is a great > idea and will make it much easier to do meaningful composite widgets. That sounds like a promising idea. At the user level, I was thinking of introducing a CompositeWidget class derived from Group. The idea would be to implement the Widget interface by sequentially dispatching the calls to each child. I haven't really thought it through yet. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
