AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity

macos: Update event source doc

Browse Source 
Update the documentation with the interaction pattern we
need to support DnD.
This commit is contained in:
Arjan Molenaar 2023-01-17 16:24:47 +01:00
parent 16e23b3f9e
commit 136c1ccd2c
1 changed files with 20 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
gdk/macos/gdkmacoseventsource.c
View File

@ -37,11 +37,15 @@
/* /*
* This file implementations integration between the GLib main loop and * This file implementations integration between the GLib main loop and
* the native system of the Core Foundation run loop and Cocoa event * the native system of the Core Foundation run loop and Cocoa event
* handling. There are basically two different cases that we need to * handling. There are basically three different cases that we need to
* handle: either the GLib main loop is in control (the application * handle:
* has called gtk_main(), or is otherwise iterating the main loop), or *
* CFRunLoop is in control (we are in a modal operation such as window * - the GLib main loop is in control. The application has called
* resizing or drag-and-drop.) * gtk_main(), or is otherwise iterating the main loop.
* - CFRunLoop is in control. We are in a modal operation such as window
* resizing.
* - CFRunLoop is running a nested loop. This happens when a drag-and-drop
* operation has been initiated.
* *
* When the GLib main loop is in control we integrate in native event * When the GLib main loop is in control we integrate in native event
* handling in two ways: first we add a GSource that handles checking * handling in two ways: first we add a GSource that handles checking
@ -57,14 +61,23 @@
* stages of the GLib main loop (prepare, check, dispatch), and make the * stages of the GLib main loop (prepare, check, dispatch), and make the
* appropriate calls into GLib. * appropriate calls into GLib.
* *
* Both cases share a single problem: the OS X API’s don’t allow us to * When initiating a drag operation, a nested CFRunLoop is executed.
* The nested run loop is started when fetching a native event in our GLib
* main loop. The application does not receive any events until the nested loop
* is finished. We work around this by forwarding the
* events that trigger the callbacks of the NSDraggingSource protocol.
* The "run loop observer" is executing the GLib main loop stages as long as we're
* in the nested run loop, as if CFRunLoop were in control.
* See also GdkMacosWindow.
*
* All cases share a single problem: the macOS API’s don’t allow us to
* wait simultaneously for file descriptors and for events. So when we * wait simultaneously for file descriptors and for events. So when we
* need to do a blocking wait that includes file descriptor activity, we * need to do a blocking wait that includes file descriptor activity, we
* push the actual work of calling select() to a helper thread (the * push the actual work of calling select() to a helper thread (the
* "select thread") and wait for native events in the main thread. * "select thread") and wait for native events in the main thread.
* *
* The main known limitation of this code is that if a callback is triggered * The main known limitation of this code is that if a callback is triggered
* via the OS X run loop while we are "polling" (in either case described * via the macOS run loop while we are "polling" (in either case described
* above), iteration of the GLib main loop is not possible from within * above), iteration of the GLib main loop is not possible from within
* that callback. If the programmer tries to do so explicitly, then they * that callback. If the programmer tries to do so explicitly, then they
* will get a warning from GLib "main loop already active in another thread". * will get a warning from GLib "main loop already active in another thread".