I often abuse Fl_Widget::user_data() for such purposes,
but this sounds better.
It looks like you were able to remove the tooltip pointer and
replace it with the more flexible 'Fl_Widget_Association'
The downside is that the association table is static, and
therefore grows with each widget added, causing 'linear lookup'
overhead for each widget that has association data.
Possibly each widget could have a single association pointer
(ie. replace the tooltip* with an Fl_Association*, so the Fl_Widget's
don't actually need to get bigger), and this pointer would be NULL
if there's no associations, and would keep track of its own size,
and grow one element for each association added. This way any lookups
would be on the small per-widget array, instead of a lookup into a
globally static table. The array This would mean the association stuff
would need to be public, but that's maybe for the good..?
Or maybe I'm missing some aspect of the suggested code, not sure.
For sure, whether the data within is a linked list or an array
should probably be invisible to the caller.
I would request a few naming changes for consistency before accepting
the patch:
> Change the abbreviation "Ass" to "Assoc", so it's clear what
the abbreviation stands for. ("Ass" is funny, but unclear)
> Consistent use of caps in naming.
For instance "Tooltip" instead of "ToolTip" to be consistent
with existing "Fl_Tooltip.H"
ToolTipAssociationType -> TooltipAssociationType
..and Fl_Word_Word_Word underbar naming for public classes,
eg:
Fl_AssociationType -> Fl_Association_Type
> FLTK oriented naming conventions for methods/macros, eg:
static void growTable(void)-> static void
growtable(void) // eg.
void Fl_Widget::AssAdd() -> void
Fl_Widget::add_assoc() // eg. add_fd(), add_idle(), etc
bool Fl_Widget::AssRemove -> bool
Fl_Widget::remove_assoc() // eg. remove_fd(), remove_idle(), etc
fltk_WidgetAssociation_h -> Fl_Widget_Association_H
// eg. Fl_Preferences_H, Fl_Printer_H, etc
> Carefully follow the FLTK CMP/ doxygen coding standards, eg.
http://docs.google.com/Doc?id=dgn42tzv_0fsbjmjgp
/*!
* Add an association to a this widget. The associated data is of the given
* association type. The associated data must not be NULL. NULL is simply
* not added as association.
*/
void Fl_Widget::AssAdd(const Fl_AssociationType& at, void* data) const {
..to..
/**
Add an association to a this widget. The associated data is of the given
association type. The associated data must not be NULL. NULL is simply
not added as association.
\param[in] at The association type to be modified <<
\param[in] data The new association data to be added <<
*/
void Fl_Widget::add_assoc(const Fl_Association_Type& at, void* data) const {
Andreas Röver wrote:
> Hello,
>
> Well there is not all that much interest in this subject, so I'll post an
> update.
>
> I have created an STR feature request. This STR contains 2 patches. One with
> the basis for the associations.
>
> The other patch contains an example: tooltips. This example removes the
> tooltip pointer from the widget class and replaces it by an association.
>
> I've also ported my grid layouter to use widget associations. This is an
> automatic layouter working like an automatically sized table. Where column
> and row sizes are automatically calculated to fit the requires widgets.
>
> My project burtools.sf.net uses this layouter. In the published project thou
> it uses an old version of the layouter that uses multiple inheritance to
> attach the layout information. The new layouter uses the widget associations.
>
> I have also got one comment regarding this whole matter: why not simply add
> another user pointer. This is faster.
>
> Well, but it would allow only one user. If you'd use the layouter you will
> have used that pointer for the layouter and still have no pointer for your
> own use. The associations will allow multiple users.
>
> So it is thinkable to have all kind of additional modules that need to attach
> data.
>
> For example think of an remote controller that wants to send events to
> widgets with certain names. So you need to attach those names. Another
> possibility are help labels. The help dialog would automatically look up if
> there is an help label attached to the widget under the mouse cursor, ...
>
> All these can be used independently and don't need to know of one another.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
