On 03.05.2012, at 23:04, Bill Spitzak wrote:
> You described it correctly (except I would pass the rectangle as a
> reference rather than as 4 numbers), and I think you are right that this
> would break any existing code that tries to call a base class draw(), as
> that would call the virtual draw(rect) function.
>
> Calling Base::draw() is not useful to implement a draw(rect) function
> (as it does not pass the rect) so this is not a problem for new code.
>
> Any chance some more kludges could be put into the fltk1 emulation so
> that this works for that? One way is that draw(void) only exists in the
> fltk1 wrapper and some trick is done so that all the implementatios call
> the actual function (ie Subclass::draw(rect) rather than just
> this->draw(rect)). There would have to be something in the fltk1 wrapper
> anyway so that draw() can be overridden by old code.
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.
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.
For example:
class InputChoice : public Input {
Menu_ myPulldownMenu;
};
InputChoice::InputChoice(int x, int y, int w, int h)
: myPulldownMenu(w-20, 0, 20, h) // in Ffltk3, all coordinates are relative to
the parent
{
}
void draw() {
Input::draw(0, 0, w-20, h);
myPulldownMenu::draw();
}
int handle(int ev) {
if (event_inside(0, 0, w-20, h) {
return Input::handle(ev, 0, 0, w-20, h);
else
return send(ev, myPulldownMenu);
}
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
