Oh, I get it.
So in the rare cases where public draw() is needed (like composite
widgets),
Roman's suggestion of the downcast trick would solve it.
Interesting.
The trick should be documented though, so widget designers making
composite widgets will know what to do. Sure, they can RTSL to figure
it out, but new widget designers might not know which of the many
FLTK widgets to look to.
Roman Kantor wrote:
> The reason for this one could be that its draw() method might be
> explicitly called within "composite" non-group widgets like Fl_Scroll.
> But obviously it could be always accessed by downcasting to (Fl_Widget*)
> so no problem here.
>
> I believe that these draw()s from your list are public rather by
> overlooking (when written) than for some purpose so making them
> protected should not break too much user code - no heretic is calling
> these directly, right?
> Greg Ercolano wrote:
>> Oscillator detected..
>>
>> matthiasm wrote:
>>> please do *not* make draw() public.
>>
>> Albrecht's STR#2142:
>>> I suggest that we should change all core widget's draw() methods from
>>> protected to public.
>>
>> The STR would appear to point out a technical reason for this;
>> a widget that wraps more than one widget; derives from one,
>> contains an instance of the other, and the wrapper's draw()
>> function (appears to) need to call the instanced widget's
>> draw() function, which it wouldn't be able to do if private.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
