5 ms·

Would be really nice if there also is a „library mode“ without relying on callbacks in addition to the „framework mode“ [1] [1] https://www.brandons.me/blog/li

Would be really nice if there also is a „library mode“ without relying on callbacks in addition to the „framework mode“ [1] [1] https://www.brandons.me/blog/libraries-not-frameworks https://www.brandons.me/blog/libraries-not-frameworks

MobiusHorizons 3y ago
This is typically not possible in gui programming, because the underlying display library typically owns the event loop, which fundamentally makes it framework like
- 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 ago
    GTK 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 ago
      Yeah 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 ago
    You CAN try get rid of call backs if you have nice language like Julia that can inline the call back
    - badsectoracula 3y ago
      You 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 ago
        No, I mean by inlining.
- mostlylurks 3y ago
  "Not possible" is an exaggeration. For a retained mode GUI library, you could, for instance, have the event loop of the library run on a separate thread, and provide functions to modify the widget tree and read events that have occurred since the last time events were read, allowing the user of the library to operate the library without being coupled to the event loop in any way. For an immediate mode GUI library, things are even simpler, because the library doesn't even have an event loop in the first place, placing the responsibility of implementing one on the user of the library.
  - badsectoracula 3y ago
    No need to mess with threads in retained mode libraries, just have a call or two to run a single iteration of the event loop, e.g. Freeglut has glutMainLoopEvent() which only handles a single event. A toolkit of mine has ff_pump_events(), ff_has_events(), etc. Normally applications are expected to do a call like "return ff_run()" at the end of main() but they could do their own main loop if they want using these functions.
bmitc 3y ago
What do you mean by "library mode" with respect to GUI functionality? How would you use a GUI library different than a framework in a way that you couldn't do with a framework?

MobiusHorizons 3y ago

This is typically not possible in gui programming, because the underlying display library typically owns the event loop, which fundamentally makes it framework like

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 ago
  GTK 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 ago
    Yeah 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 ago
  You CAN try get rid of call backs if you have nice language like Julia that can inline the call back
  - badsectoracula 3y ago
    You 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 ago
      No, I mean by inlining.
mostlylurks 3y ago
"Not possible" is an exaggeration. For a retained mode GUI library, you could, for instance, have the event loop of the library run on a separate thread, and provide functions to modify the widget tree and read events that have occurred since the last time events were read, allowing the user of the library to operate the library without being coupled to the event loop in any way. For an immediate mode GUI library, things are even simpler, because the library doesn't even have an event loop in the first place, placing the responsibility of implementing one on the user of the library.
- badsectoracula 3y ago
  No need to mess with threads in retained mode libraries, just have a call or two to run a single iteration of the event loop, e.g. Freeglut has glutMainLoopEvent() which only handles a single event. A toolkit of mine has ff_pump_events(), ff_has_events(), etc. Normally applications are expected to do a call like "return ff_run()" at the end of main() but they could do their own main loop if they want using these functions.

bmitc 3y ago

What do you mean by "library mode" with respect to GUI functionality? How would you use a GUI library different than a framework in a way that you couldn't do with a framework?