API to know when to call `uiMainStep`

[daurnimator]

Instead of calling uiMainStep on some arbitrary timer, provide a way know when to step next.

I'd suggest a function that returns both:

1. a file descriptor (unix) or HANDLE (windows) to wait on
2. a timeout

These would then be passed (by the user) to poll/select(unix)/WaitForMultipleObjects(windows) to multiplex the UI with other (e.g. network) resources.

[andlabs]

That isn't how it would work on Windows; on Windows you would use MsgWaitForMultipleObjectsEx() and not have a HANDLE for the GUI as that's taken care of for you by that function.

Other than that I'm still not fully sure what you're asking for...?

[zevv]

I was about to bring up the same issue, but it fits in this topic:

On unix, when integrating libui in an application with it's own poll()/epoll()/select() mainloop, you would ideally have a method to request a file descriptor (or set of file descriptors) from libui which you should add to the poll() loop. As soon as any of these fd's trigger a POLLIN, you call uiMainStep().

On X this would usually be a single file descriptor returned by ConnectionNumber(display), but this might be different when running gtk on directfb, for example. I suspect the same mechanism (polling for files) might work for MacOS, while on windows there would probably be a number of handles to pass to WaitForMultipleObjects.

[andlabs]

I have no idea what OS X does, but I can figure out what to do on Windows and GTK+ (since the GTK+ main loop has support for I/O; I'm just not sure if you can pass it arbitrary fds or not). A function like uiMainStepPoll() could be useful here.

[zevv]

• On 2016-06-10 13:47:55 +0200, Pietro Gagliardi wrote:

I have no idea what OS X does, but I can figure out what to do on
Windows and GTK+ (since the GTK+ main loop has support for I/O; I'm
just not sure if you can pass it arbitrary fds or not). A function
like uiMainStepPoll() could be useful here.

I think it should be the other way around: I would not want libui to
handle the polling of my file descriptors; instead I would like to know
which file descriptors are used by GTK under the hood, so I can poll
these fd's in my own event loop, and know when I need to call
uiMainStep() when the fd(s) have data pending.

:wq
^X^Cy^K^X^C^C^C^C

[andlabs]

The only reason I am suggesting libui does it is because on Windows you would use MsgWaitForMultipleObjectsEx(), which takes care of the fact the UI event queue is not a waitable kernel object for you. I'm not even sure GTK+ or GDK exposes any FDs; does it?

[zevv]

• On 2016-06-10 16:50:47 +0200, Pietro Gagliardi wrote:

The only reason I am suggesting libui does it is because on Windows
you would use MsgWaitForMultipleObjectsEx(), which takes care of the
fact the UI event queue is not a waitable kernel object for you. I'm
not even sure GTK+ or GDK exposes any FDs; does it?

Indirectly from gdk, this works for me:

int uiConnectionNumber(void)
{
       GdkDisplay *gd = gdk_display_get_default();
       Display *d = gdk_x11_display_get_xdisplay(gd);
       int fd = ConnectionNumber(d);
       return fd;
}

:wq
^X^Cy^K^X^C^C^C^C

[daurnimator]

For GTK you can get a list of things to poll via g_main_context_query. For convenience, you can wrap this up into a single fd with epoll/kqueue/ports.

On OSX you can see what GTK themselves do to solve the same question with quartz http://www.lanedo.com/the-main-loop-the-engine-of-a-gui-library/, but the simple general answer seems to be to use a helper thread. However, I can't see why you couldn't create your own kqueue object and hook that up (I think cocoa communicates with mach ports, which means we can use EVFILT_MACHPORT).

For windows things are trickier.

• The simple solution is to tell people to use MsgWaitForMultipleObjects(Ex) so they get woken up on a message delivery. I'd have a 'backup' by providing a timeout of e.g. 30ms.
• A medium complexity solution would start a new thread and use AttachThreadInput to listen for messages; when a message is available it would alert the main thread via an Event or self-pipe.
• The scary solution: I did some research, and it appears that MsgWaitForMultipleObjectsEx works by using an internal Event HANDLE that polls ready when there are events. It can be found in the win32 threadinfo struct. the member is known as hEventQueueClient

[andlabs]

Please see #95 (comment)

[andlabs]

(Copy-pasting from #21 (comment))

Okay, I need to resurrect this.

It's useful for any apps where you still want control of the main loop - for instance if you have a game or gamedev tool that uses libui, and you need a tight render-loop and other updates alongside your ui. I guess you could delegate the ui handling to a separate thread, but that seems a bit of a convoluted solution (and needless threads usually cause problems).

How do people do this right now on macOS in a macOS-native application? Because there is no real supported way to do this directly in the same way libui does it now, and even if I did just recreate what -[NSApplication run] does internally, that wouldn't be sufficient to replace all of -[NSApplication run].

And for the record, I am specifically referring to GUI apps here, not just programs that roll their own poll/kqueue loop.