On 23.03.2010, at 11:01, Matthias Melcher wrote:
> 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)
+1
> +1: on removing all references to a widget after its callback, plus removing
> all fluff that we programmed to get around this limitation. ;-)
+1
You mean the limitation to delete widgets in their callback? I tried
very hard to do this (by adding Fl_Widget_Tracker etc.), and I think
that I got most of 'em. Removing clear_changed() after the callback
(in do_callback) would remove one Fl_Widget_Tracker use :-).
There are other places in the code, where event handling is really
difficult to understand, and where under some circumstances the
callback could even be called twice. One example (off the top of
my head): dragging the mouse over radio buttons in a group so that
setonly() is called that can affect multiple radio buttons. Or
dragging the mouse over sliders with when(FL_WHEN_CHANGED).
> +1: on removing Fl::readqueue.
+1. At least we should remove it from FLTK's internal code. I can do it
for fl_ask and friends and probably also Fl_Color_Chooser.cxx, but I'd
ask you to have a look at fluid/Fl_Function_Type.cxx. Would this be
okay?
Removing it completely would probably affect user code. We should delay
this at least until FLTK 3.0 ;-) - but clearly deprecate it in FLTK 1.3.
> Didn't we decide to remove Forms compatibility anyways?
Step by step - first we wanted to make a configure option (maybe with
default = disabled), and later remove it entirely. But it's not easy
to decide (at least for me) what is only needed for Forms compat., and
what could be used elsewhere. I've started
> 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.
fltk::exec() seems to do something like that, but I need to take a
deeper look how it works.
> It could disable all other windows, avoiding all the locking issues in the
> bug database (popup menu while using a readqueue loop, etc.).
I believe I know where the problem is, but I will probably need your
help to solve it (or at least discuss the solution).
> Using Fl::run() from within a callback is bad and should be blocked.
It's usually Fl::wait() or Fl::check(), but I know what you mean.
Whatever we call (name) it or in what way we call the function, IMHO
we'll always end up with nested event loops, because there must be a way
to block the normal code flow during popping up a modal window in a
callback. One example is fl_file_chooser, but also fl_choice etc., e.g.
fl_choice("Do you really want to exit without saving ?",...).
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
