|
|
On 30/9/22 21:03, Rob McDonald wrote:
My C++ FLTK application is wrapped with SWIG to be available form
Python. This is normally done in a non-GUI way. We are trying to
enable the GUI while keeping access via Python.
If you initialize the GUI and then start the FLTK event loop
from Python, the GUI will open and operate properly (tested on
Windows and MacOS). Of course, Python is blocked until control
is returned. If you stop the event loop (without terminating
everything else), control is returned to Python. You can
re-start the event loop and return control to FLTK.
This works so far. You can have the application GUI in a
'blocking' mode -- either the GUI is responsive, or Python can
work.
We are working to make the GUI available in a non-blocking
mode. To do this, we need to compile the SWIG wrapper with the
-threads option -- thereby the program gets and releases the
Python GIL (global interpreter lock) as appropriate.
Then, if we start the application GUI up in a Python thread,
the GUI seems to work, and Python can continue. This seems to
work fine on Windows.
However, on MacOS, when the GUI is being initialized in a
secondary thread, execution hangs on a call to:
Fl::screen_xywh( x, y, w, h );
If that call is commented out, we instead hang a few lines
later on a call to:
Fl_Sys_Menu_Bar::add()
Key amongst these is that, for many of
the target platforms on which FLTK is supported, only the main()
thread of the process is permitted to handle system events,
create or destroy windows and open or close windows. Further,
only the main() thread of the process can safely write to the
display.
I think I might be running into this problem.
More than likely.
If I am hitting this problem, what will it take to get FLTK
to work in the thread created for it by Python?
Nothing. FLTK cannot work on a child thread. Only on the main
thread.
Is there any way to make the new thread the 'main' thread?
Not, AFAIK.
What would happen if someone wanted to use some other GUI with a
separate event loop in the main Python thread?
I assume you have FLTK wrapped like pyFLTK. What you can do is
have the main thread release control sporadically, by calling
Fl::wait instead of Fl::run in a python loop (I am not too
familiar with python so this is pseudo code):
--python--
while Fl.wait():
# call python code that should return quickly
print("in loop")
--python--
--
Gonzalo Garramuño
ggarra13@gmail.com
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/05de3cdf-2a87-58ca-8645-cbd0021718af%40gmail.com.
[ Direct Link to Message ] | |
|
| |