Duncan Gibson wrote:
>> Maybe someone could trawl through these extra widget toolkits and see
>> what the most common add-ons are and therefore what people are missing
>> in fltk.
>
> I've taken the summary of third party widgets available for FLTK,
> and grouped them around related functionality. I have then ordered
> the groups by size to give some idea of where people have needed
> to add to core FLTK capabilities in the past. Obviously some of
> these are now obsolete, superseded, or "duplicates".
Nice..!
I guess one thing I'm curious about is widget skinning for FLTK1.
I've seen at least two approaches:
1) Wiring directly into fltk code, eg. Fl::scheme("plastic")
2) Deriving new widgets that overload draw(), eg. Fl_Gel_Tabs.
I assume there's some 'better way' that other widget kits use
to allow redefining the look of base widgets. Is there some generally
accepted technique other widget kits offer for this?
I haven't thought about this much, but I assume there's some simple
way to do this. I don't know of a C++ way to redirect eg.
Fl_Button::draw()
to point to a different bit of code without deriving a class. Or can
one somehow overload Fl_Button::draw()?
Assuming that's not possible, I suppose one way might be to offer
a 'draw callback' to users, so that if one wanted to redefine the
look of Fl_Button, one could call something like:
Fl_Button::draw_callback(MyButtonDraw_CB, my_data);
..and in Fl_Button::draw() it might have something like:
void Fl_Button::draw() {
if ( draw_cb )
{ (*draw_cb)(draw_data); return; }
else
{ fltk_draw(); } // fltk's default draw code
}
Kinda hacky. Is there a better way that fits the FLTK1 model?
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
