Hello, whoops a lot of replies in a short time. I will try to answer all questions in this mail.
> It seems that there is something wrong with "burtools.sf.net" it > goes nowhere ! burrtools.sf.net I dropped one r. This uses an old version of the layouter that doesn't use associations, but multiple inheritance. >I wouldn't recommend to replace the tooltip pointer. IMHO the tooltip > replacement was only intended as an example. I don't think that it > would be useful (in terms of performance) to replace any core widget > property with the Fl_Widget_Association mechanism. The tooltip removal was indeed intended only as an example. It is not worth removing the tooltip pointer due to the overhead of the hashtable (one pointer requires more than 4 pointers of management). So this is purely educational and not intended for inclusion. It would be possible to split the global hash table and have the associations within the widget class, with the described effect of loosing the possibility to find all widgets with a certain association attached. And yes, the remote controller would need that feature, so I am personally against it. The associations are btw. not really public as you need the associationtype pointer to gain access. Without it you don't know what you get. If you keep that pointer private no one will be able to properly access your associated data. So the attached data is private to the module/class that initially assigned that data. Not to the widget that it is assigned to. > I would request a few naming changes for consistency before accepting > the patch: I will try to include the requested name changes and code style cleanup. Albrecht also found some bugs just by looking at the code :( I also think now that we can live without the foreach functions. We would loose the ability to attach multiple data pointers of the same type to the same widget. But I guess if one user wants to do that he should design his datatype that he wants to append in a way that it can handle multiple instances... so I guess we don't loose anything when I remove the foreach stuff > However, there can be more than one widget with the same hash value, > and thus it is correct that there can be a linear search through the > linked list of more than one widget's association entries. However, > the table is always at least as big as the number of widgets that > have associations (IIRC), and thus I don't think that there will be a > lot of widgets with the same hash value in general, but that may > depend... Hastables have normally (when you have a nice hash function) a amortized constant time lookup time. So generally there is no huge need to worry about speed. Especially as drawing things on screen takes much longer. But I would not place the position and size into the association because lookup still is slower than direct lookup by a factor of 5 or so I guess... > One more thought: IMHO the optimal way to implement this can't be > decided, because nobody would know how it will be used, anyway. The > central question would be the relation of #widgets/#associations > and/or the number of associations per widgets. So we must guess and > decide something. Yes it is indeed hard to decide on a proper data structure for the associations ad you normally don't know what the kind of usage will be, but I think that the presented data structure should work well in most cases Ok, I hope that this answers all questions on this. Andreas _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
