On 23.03.2010, at 09:36, Albrecht Schlosser wrote: > Am 23.03.2010 01:15, Matthias Melcher wrote: >> >> On 22.03.2010, at 10:15, Domingo Alvarez Duarte wrote: >> >>> I'm experimenting with dao http://daovm.net/ and his author did an >>> amazing job creating a automated tool that can create bindings to almost >>> all fltk 1.3 including deriving fltk classes, but for it to work with >>> callbacks easily he needs to make "void do_callback(Fl_Widget* o,void* >>> arg=0)" a virtual function. >>> >>> I propose to make this modification on the official FLTK sources. >> >> I understand why you would do this. do_callback however is the wrong >> function to make virtual. It could however be quite useful to have a >> function, for example called 'virtual void action()' that could be called if >> there is no callback in place. That way, a user who prefers to derive a >> class - instead of setting a callback - will not need to go through a static >> member function. > > what would be the difference to making do_callback() virtual? Only > that it would be called only if there is no callback? Slightly > confused...
Yes, I see. I'd be ok with making do_callback virtual assuming that only one of the three needs to be changed. +1: on making do_callback virtual (and a bunch of other functions, TBD later) > Et ceterum censeo Carthaginem esse delendam. ;-) I wholeheartedly agree, even though the Cathargians never did anything mean to me. +1: on removing all references to a widget after its callback, plus removing all fluff that we programmed to get around this limitation. ;-) +1: on removing Fl::readqueue. Didn't we decide to remove Forms compatibility anyways? We would need a replacement for modal windows because they are often (always?) used in a sequence of events and need to stay in order. Maybe a function like Fl::run_modal(Fl_Window*) would be nice. It could disable all other windows, avoiding all the locking issues in the bug database (popup menu while using a readqueue loop, etc.). Using Fl::run() from within a callback is bad and should be blocked. - Matthias _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
