| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #3464
| Application: | FLTK Library |
|---|
| Status: | 2 - Closed w/o Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | Printing |
|---|
| Summary: | Fl_Native_File_Chooser multithread issue (gtk) |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | djcj |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | Will Not Fix |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | djcj
15:08 Apr 18, 2018 |
| I have attached a little test program. It starts a separate thread and does something (in this example it constantly updates the label of an Fl_Box widget). When I add a button with a callback that calls fl_file_chooser() the thread is still running but when it calls Fl_Native_File_Chooser() instead the thread pauses until I closed the gtk window.
I'm on Linux here so I don't know if the same happens on Mac or Windows. | |
| |
| #2 | AlbrechtS
05:10 Apr 19, 2018 |
| Just an observation, unfortunately I don't have a solution:
The thread "hangs" indeed when it calls Fl::lock() because FLTK holds the lock while the GTK file chooser is shown. This can easily be seen if you modify the function loop() in the demo program like this:
printf("loop: BEFORE Fl::lock() %2.2s .\r", l[i]); fflush(stdout);
Fl::lock();
printf("loop: AFTER Fl::lock() %2.2s .\r", l[i]); fflush(stdout);
The underlying cause is that the GTK file chooser needs to process system (X11) events while it is running. While the GTK window is open, FLTK processes *only* expose and configure_notify events. I /tried/ a few things with Fl::unlock(), Fl::check(), Fl::lock() etc. but the effects I saw were worse than before, so I gave up. I have no idea how this could be changed.
FWIW: This is all handled in function Fl_GTK_Native_File_Chooser_Driver::fl_gtk_chooser_wrapper() in file src/Fl_Native_File_Chooser_GTK.cxx, line 492. The GTK event loop is handled in lines 622 and following lines:
while (response_id == GTK_RESPONSE_NONE) { // loop that shows the GTK dialog window
fl_gtk_main_iteration(); // one iteration of the GTK event loop
while (XEventsQueued(fl_display, QueuedAfterReading)) { // emulate modal dialog
// more code here ...
if ( xevent.type == Expose || xevent.type == ConfigureNotify ) fl_handle(xevent);
}
Fl::flush(); // do the drawings needed after Expose events
}
Sorry, that's it from my side. Someone else may chime in with more information or a solution.
Or maybe there is no solution at all. | |
| |
| #3 | djcj
22:47 Apr 21, 2018 |
| dlopen()ing a plugin that starts a Qt5 file selection has the same result. I'll see if I can instead just modify the FLTK file selection so that it has a bit more of the look and feel to the native dialogs. | |
| |
| #4 | AlbrechtS
10:02 Apr 22, 2018 |
| Okay, then I believe we can close this STR for now. Right? | |
| |
| #5 | djcj
11:19 Apr 22, 2018 |
| Sure, go ahead. | |
| |
| #6 | AlbrechtS
04:04 Apr 23, 2018 |
| Closed. | |
[ Return to Bugs & Features ]
|
| |
