I would, as much as possible, want FLTK to allow widgets to be deleted in callbacks.
Deferring deleting of widgets is causing us no end of grief with some Qt work being done now. The problem is that many Qt calls (and same with fltk) will trigger the deletion, such as changing widget layouts. This pretty much means you cannot call lots of code from the callbacks anyway and thus defeats the whole point of adding the complexity of deferred callbacks. This does not have to be perfect but I would much prefer that deletion from the callback be tested and considered a design criteria. Albrecht Schlosser wrote: > Question to developers: > > Recently I added a new class Fl_Watch to simplify the handling of widget > deletion during callbacks (svn -r 6651, [2]). > > This class is used to wrap the use of Fl::watch_widget_pointer() and the > related functions. Now ... > > Matthias Melcher wrote in [1]: > > > I am happy about wrapping the functionality into a class and to get > rid of > > the deferred delete. I would like to suggest a different name for the > class > > though - I am no native speaker, but "watch" to me is such a commonly > used > > word. How about: > > > > Fl_Widget_Tracker > > Fl_Widget_Guard > > Fl_Widget_Patrol > > > > or simply > > > > Fl_Smart_Pointer (maybe even making it public?!) > > I wasn't sure about a good name (my first idea was Fl_Widget_Watch), and > I am open for suggestions. > > From the above names, I'd like Fl_Widget_Guard or Fl_Smart_Pointer most. > > Suggestions for other names are welcome! > > BTW.: The current implementation of Fl_Watch _is_ public and documented > in svn :-) > > Albrecht > > P.S.: I'm wondering why the discussion of STR #1306 doesn't show up in > fltk.development... > > ----- > [1] http://www.fltk.org/str.php?L1306 > [2] http://www.fltk.org/newsgroups.php?gfltk.commit+v:7003 _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
