I apologize for the long post, but I thought about these problems for a
long time, and maybe it helps to write this down.
matthiasm wrote (in another thread):
> WRT the earlier suggested Label-in-a-widget and other special widgets
> that have child-like widgets without beeing a group, I suggest that we
> find a general way to dispatch events. This would make it alos much
> easier to derive composite widgets from more useful superclasses
> instead of Fl_Group.
I assume you're not talking about signals and slots or other completely
different event dispatching methods? And you're not talking about the
idea that every widget should also be a group and can have child
widgets? (Although I think that having child widget (or subwidgets, as I
call them below) _could_ be a good general widget feature).
> For example, Fl_Input_Choice is a combination of a text
> input and a pulldown menu. It is currently derived from Fl_Group, but
> should rather be derived from Fl_Text_Input because it expands the
> functionality of Fl_Text_Input, and not Fl_Group.
Yes, fully agreed !
I had a similar (well, better: identical) problem like Fl_Input_Choice,
and I solved it by deriving the composite widget from my Input widget
and added a box widget internally, just like Fl_Input_Choice:
+--------------------++---+
| Fl_Input || X | X = Fl_Box
+--------------------++---+
[please use a fixed font to view the "grapics"]
Indeed, this combination led to STR #1894 [1], because my solution was
to add the small box widget to the parent group of the Fl_Input widget,
and there were problems when destroying the widgets, but that's another
story. You can see two example programs there [2,3], but they use two
small boxes instead of one.
Why did I do this? The problem with this composite widget is that the
box widget would never get events, if it is not included in an Fl_Group,
because event dispatching works top-down through group widgets. And the
group widget delivers events to all its children, _if_ the event happens
to be inside the child widget, something like:
if (o->takesevents() && Fl::event_inside(o)) { ... }
So, how can this be solved?
Either you can extend the base (Fl_Input) widget's dimensions (xywh) to
include the box, but then you would have to change the draw() method and
maybe (surely) more ... [shudder]
Or you must put both widgets into a container widget with appropriate
dimensions (Fl_Group), but then you can't derive your composite widget
from Fl_Input ... [bad]
My solution to put the box widget in its parent group works for my
application, but that is not a general solution [also bad].
But what, if a composite widget could _pretend_ different (say: virtual)
dimensions that include both widgets? Then all events like mouse clicks
would be delivered to the composite widget, even if they are in the area
of the small box widget (let's call this a subwidget for now). Then the
composite widget would decide, if the event should go to the subwidget
(box) or the main widget (Fl_Input), just like how I changed the
Fl_Scroll widget in my proposed patch (the other thread mentioned
above). Thus, the composite widget would have to dispatch events to its
subwidget, just like Fl_Group does with its children.
*===========================*
|+--------------------++---+|
|| Fl_Input || X || X = Fl_Box
|+--------------------++---+|
*===========================* <-- virtual composite widget dimensions
This could be done, e.g. if a new virtual widget method like
Fl_Widget::event_inside() or similar would be used instead of
Fl::event_inside(const Fl_Widget *). This method would be implemented to
test the normal widget dimensions, but could be overloaded with the
composite widget's special needs that check its extended dimensions.
Maybe, this would only need a new virtual method and minor changes in
Fl_Group and similar widgets to work.
Well, that's only a first idea (and I developed the details while
writing this). Maybe someone has a better idea, but I hope that I could
inspire others to think about this.
This does not really specify "a general way to dispatch events", but
maybe it can help to improve deriving composite widgets.
Albrecht
---
[1] http://www.fltk.org/str.php?L1894
[2] http://www.fltk.org/strfiles/1894/crash.cxx
[3] http://www.fltk.org/strfiles/1894/crash_1.cxx
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
