matthiasm wrote: > > ::draw() is protected because we kept getting complaints that "draw()" > is not working as expected. The event-driven nature of GUIs is new to > many developers, and some assume that they can call draw() whenever they > want something appear on the screen. We had to explain redraw() vs. > draw() at least once a week. > > After making draw() protected, we rarerly get this question. Seein that > draw() is protected, users start reading the docs to find out why that > is, and usually find redraw() pretty quickly. > > Fl_Widget::draw() obviously must be public, or Fl_Group could not redraw > its children. There is no harm in that whatsoever because draw() is > virtual, so the correct implementation will be called. > ((Fl_Widget*)w)->draw() in that respect I would not consider a hack, but > a useful stumble stone - plus it does the Right Thing anyway. > > Or in short: please do *not* make draw() public.
That's a good rationale, and I do fully understand your reasoning. But then we should IMHO be consistent and make *ALL* draw methods protected (excluding Fl_Widget::draw(), of course). If this is common sense, then I'll change my STR #2142 [1] accordingly, and I'd happily change the existing public draw methods to be protected (in FLTK 1.3). We would have to use this "useful stumble stone" then for some core widgets, but I'm okay with this, if it is _consistent_. My concern was: (a) consistency (b) *technically* spoken, it's useless if it can be called anyways Albrecht P.S. This ought to be in fltk.development, but ... _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
