On 05/03/2012 11:14 PM, Matthias Melcher wrote:
> Yes, it's all there. You can override draw(). Ye can also easily make
> FL_xxx::draw(void) call the corresponding fltk3::xxx::draw(int, int, int,
> int). In fact, we have to something similar anyway because FL coordinates are
> relative to the next parent Fl_Window, whereas fltk3 coordinates in draw()
> (and handle()) are always based on 0,0 for the top left corner of the widget.
This is done without making draw(void) a virtual function in fltk3? I'm
guessing that draw does something like this:
/* NOT VIRTUAL */ void draw() {
if (this->back_compatibility_stufff)
this->back_compatiblity_stuff->draw(this);
else
draw(this->rectangle);
}
Also notice that this explicitly does the *opposite* of making the
upper-left corner be 0,0. Since the draw has to be prepared to draw in
any rectangle there is no reason not to pass the actual position of the
widget. This will avoid putting translates into the static device object.
The purpose of this function is so a subclass can add "frames" around
the base widget without doing horrible kludges. It is not for InputChoice.
> For composite widgets, I would like to propose something else though. It
> should be possible to derive a new widget from any other widget, based on the
> data that widget provides, not on the UI. For example, InputChoice is derived
> from Group. That is silly, because Group does not normally handle text. It
> should rather be derived from Input, right?
>
> But currently only a Group can have children. So what I would like to do is
> keep the children in Group (no need to move them to Widget - that would be a
> waste), but add something to Widgets that I call Nephew for lack of a better
> word.
>
> Nephews are managed like children in that they occupy space in the widget,
> can receive events, and are drawn by their "Uncle", but they differ in that
> they are not some unknown sized array of any kind of widget, reducing all the
> overhead associated with that.
What I would do is make *all* widgets be Groups (well actually a base
class that has no resizebox or other layout). There was an fltk2 branch
that did this. It simplifies things quite a deal by removing the rtti.
Also GTK takes great advantage of this to support complex sets of images
parented to simple objects like buttons.
To keep widgets as small as possible there was only one pointer. If it
was null then the widget had no children. If it was not null it pointed
at something much like a std::vector of children.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
