4 ms·
You cannot really get rid of callbacks (or well, you can, but there is no practical benefit and it can be very messy) for things like widget events (e.g. when t
by badsectoracula 3y ago
You cannot really get rid of callbacks (or well, you can, but there is no practical benefit and it can be very messy) for things like widget events (e.g. when the user clicks a button).
But you could provide an API that allows the toolkit user to do their own main loop instead of having the toolkit do that. There isn't really that much of a benefit though - in theory it makes mixing with other libraries that might handle UIs easier, but in practice (having worked in a codebase that did that by mixing two toolkits - because of migration that never finished) tends to become a mess and for anything else an "idle callback" will work just fine.
- PaulDavisThe1st 3y agoGTK relies on the Glib event loop, which is in a separate library (and also used by Qt, at least optionally). You can, if you want to, reimplement the abstract API of the Glib event loop, and use that with GTK instead. Note also that on macOS, GTK has to integrate both the Glib event loop and the event loop used by NeXTStep/Cocoa, because it is not always the case that the same one is in control (e.g. during drag-n-drop processing). It handles this "just fine", for some definition of "just fine".
- badsectoracula 3y agoYeah i was referring that is possible that toolkits to do that in general (not just GUI toolkits, AFAIK even something like Freeglut which normally uses callbacks has an API for manual main loops), not specifically about Gtk.
- hsjqllzlfkf 3y agoYou CAN try get rid of call backs if you have nice language like Julia that can inline the call back
- badsectoracula 3y agoYou mean using anonymous functions? This is still a callback, it is just a bit nicer (at least assuming the callback code is short).
- hsjqllzlfkf 3y agoNo, I mean by inlining.