thank you for your answers.
>
> I assume the image->Filter(...) call is some time consuming
> processing step? If so, I'd strongly advocate against doing that. In
> the callbacks, it is probably best to do as little as possible. The
> problem is that whilst fltk is processing the callback for a widget,
> it can't be handling any other widget events, so the UI becomes
> unresponsive, with other UI events either getting queued or lost...
>
yes image->Filter() is time consuming.
i indeed assumed that fltk couldn't handle another window callbacks while one
was still running. actually, at first i had a separated MyCallback.cpp file,
where all my callbacks, from any window, were implemented. I changed that
because i had to declare my classes global to use them in the callbacks. As i
try avoiding globals, i reimplemented callbacks as member functions, but now
i'm having the problem to make callbacks communicate between classes...
Maybe i should go back to the first idea, and find a way to gather all
callbacks in a single file while avoiding global...
> You need to have your callback simply note that the processing has
> been requested and return, (thus allowing the UI to remain active,
> and able to show your parameters window) then have some other
> processing actually execute the filter window.
>
> This is where it gets tricky - I'd have a worker thread that was just
> waiting for the callback to signal it to do the processing, but a lot
> of people (probably rightly) are wary of threads (although on modern
> multi-core PC's they do help spread the CPU load around better!).
> An alternate not-threaded approach (and this smells a bit hacky to
> me, although I have used it) is to have the "start" callback register
> a timeout with add_timeout (which will run once the UI widget
> callback has returned) then have that timeout start your processing
> step... I *think* that works the way you'd want...
>
it does get tricky :-) Even with add_timeout, if i have:
[filterWindow.cpp]
..
void filterWindow::run_cb()
{
SetParameters();
Fl::add_timeout(10, Filter_callback);
}
..
i still have to let my add_timeout function know that the Filter_callback is a
function from my main GUI class...
another idea: if filterWindow is declared as a child of my main Fl_window,
can't he use his parent's callbacks ?
i'd have stg like:
[in main class.cpp]
void myGUI::Filter_callback()
{
filterWindow->show();
}
[in filterWindow.cpp]
void filterWindow::run_cb()
{
parent->RunFilter();
}
.... what do you think ?
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
