6 ms·

Mousetrap.jl: a GUI library for Julia and C++ that wraps GTK4

157 points by xgdgsc 3y ago

WanderPanda 3y ago
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?
timw4mail 3y ago
[flagged]
- jdiff 3y ago
  If it's always the worst that's getting all the indie dev attention there's probably something to it that you're ignoring or prioritizing lower than the people putting in the legwork.
  - badsectoracula 3y ago
    There aren't really that many GUI toolkits in C[0] (which is what makes it easy to make bindings to other languages) - it is pretty much Gtk and... Motif. Ok, XForms too, probably. Toolkits in other languages need some C intermediate - e.g. Lazarus has a Qt backend for LCL and since Free Pascal can only use the C ABI there is a "qt5pas" library written in C++ that exposes a C API that programs must link against. This can be annoying. [0] ignoring Win32 as that is Windows-specific... unless you consider writing against libwine but i don't think anything uses that as a toolkit
    - seabass-labrax 3y ago
      Your [0] is actually a pretty neat idea - Wine is small and well-supported, and kind of cross-platform by definition. Even better if you explicitly ensured compatibility with both Linux and Windows, for instance with CI testing every build for API errors. After all, GTK kind of has a Wine-style compatibility layer when running on Windows; it's just often statically linked into the binary rather than installed separately.
      - badsectoracula 3y ago
        Winelib (not libwine, my bad) isn't really that great for non-Windows stuff, it is really meant for porting applications that use Windows API calls and it really takes over everything. For example you need to compile the program using "winegcc", which creates a shell script that calls Wine to load the application (the application is compiled as a .so so it can use Linux libraries and calls, it isn't a Windows program). This in turn loads the full Wine server with its various services and Windows compatibility layers. And chances are you'll need to use "winemaker" to build the code (it generates a Makefile for you). Just as a test, compiling and running a very simple "hello, world" program that calls MessageBoxA to show a message box and exits still loads a bunch of processes (checked via ps -A) and dumps a bunch of diagnostics to the terminal. Also, IMO while Wine's GUI bits generally work, they do have a lack of polish even compared to their Windows 95 counterparts.
notyoutube 3y ago
I'd like to see a comparison to GTK4.jl [1] and GTKObservables.jl [2]. [1] https://docs.juliahub.com/Gtk4/rFcBQ/0.5.0/ https://docs.juliahub.com/Gtk4/rFcBQ/0.5.0/ [2] https://juliagizmos.github.io/GtkObservables.jl/stable/ https://juliagizmos.github.io/GtkObservables.jl/stable/
hsjqllzlfkf 3y ago
If you like guis and Julia, this one is outstanding https://github.com/Gnimuc/CImGui.jl https://github.com/Gnimuc/CImGui.jl
ducktective 3y ago
What's the latest status of Windows support for GTK4? Can a binary be cross-compiled for Windows on a Linux machine?
- seabass-labrax 3y ago
  It very much looks like it: https://www.gtk.org/docs/installations/windows/ https://www.gtk.org/docs/installations/windows/
- asg 3y ago
  Yes, the Julia ecosystem provides cross compiled binaries for many platforms https://docs.juliahub.com/GTK4_jll/XRLGj/4.10.5+0/#Platforms https://docs.juliahub.com/GTK4_jll/XRLGj/4.10.5+0/#Platforms
lukeh 3y ago
Some interesting stuff happening here [1] and here [2] too. [1] https://github.com/stackotter/swift-cross-ui/tree/main https://github.com/stackotter/swift-cross-ui/tree/main [2] https://github.com/TokamakUI/Tokamak https://github.com/TokamakUI/Tokamak
deleted 3y ago
[deleted]
JanisErdmanis 3y ago
One thing that popped out for me was the care with which the documentation is made for MouseTrap.jl, and there seems to be no expectation for a user to look into GTK C docs to get some things running. Kudos to the devs for the achievement! At this point it seems that the deployment story missing. There is the BinaryBuilder.jl, but what steps does one need to take to make application bundles for multiple platforms at once and how large those bundles would be? Also, wouldn’t it make sense to bundle Julia with a precompilation file instead of using BinaryBuilder.jl?
3abiton 3y ago
I wasn't aware Julia had such a support on HN!

157 points by xgdgsc 3y ago

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?

timw4mail 3y ago

[flagged]

jdiff 3y ago
If it's always the worst that's getting all the indie dev attention there's probably something to it that you're ignoring or prioritizing lower than the people putting in the legwork.
- badsectoracula 3y ago
  There aren't really that many GUI toolkits in C[0] (which is what makes it easy to make bindings to other languages) - it is pretty much Gtk and... Motif. Ok, XForms too, probably. Toolkits in other languages need some C intermediate - e.g. Lazarus has a Qt backend for LCL and since Free Pascal can only use the C ABI there is a "qt5pas" library written in C++ that exposes a C API that programs must link against. This can be annoying. [0] ignoring Win32 as that is Windows-specific... unless you consider writing against libwine but i don't think anything uses that as a toolkit
  - seabass-labrax 3y ago
    Your [0] is actually a pretty neat idea - Wine is small and well-supported, and kind of cross-platform by definition. Even better if you explicitly ensured compatibility with both Linux and Windows, for instance with CI testing every build for API errors. After all, GTK kind of has a Wine-style compatibility layer when running on Windows; it's just often statically linked into the binary rather than installed separately.
    - badsectoracula 3y ago
      Winelib (not libwine, my bad) isn't really that great for non-Windows stuff, it is really meant for porting applications that use Windows API calls and it really takes over everything. For example you need to compile the program using "winegcc", which creates a shell script that calls Wine to load the application (the application is compiled as a .so so it can use Linux libraries and calls, it isn't a Windows program). This in turn loads the full Wine server with its various services and Windows compatibility layers. And chances are you'll need to use "winemaker" to build the code (it generates a Makefile for you). Just as a test, compiling and running a very simple "hello, world" program that calls MessageBoxA to show a message box and exits still loads a bunch of processes (checked via ps -A) and dumps a bunch of diagnostics to the terminal. Also, IMO while Wine's GUI bits generally work, they do have a lack of polish even compared to their Windows 95 counterparts.

notyoutube 3y ago

I'd like to see a comparison to GTK4.jl [1] and GTKObservables.jl [2]. [1] https://docs.juliahub.com/Gtk4/rFcBQ/0.5.0/ https://docs.juliahub.com/Gtk4/rFcBQ/0.5.0/ [2] https://juliagizmos.github.io/GtkObservables.jl/stable/ https://juliagizmos.github.io/GtkObservables.jl/stable/

hsjqllzlfkf 3y ago

If you like guis and Julia, this one is outstanding https://github.com/Gnimuc/CImGui.jl https://github.com/Gnimuc/CImGui.jl

ducktective 3y ago

What's the latest status of Windows support for GTK4? Can a binary be cross-compiled for Windows on a Linux machine?

seabass-labrax 3y ago
It very much looks like it: https://www.gtk.org/docs/installations/windows/ https://www.gtk.org/docs/installations/windows/
asg 3y ago
Yes, the Julia ecosystem provides cross compiled binaries for many platforms https://docs.juliahub.com/GTK4_jll/XRLGj/4.10.5+0/#Platforms https://docs.juliahub.com/GTK4_jll/XRLGj/4.10.5+0/#Platforms

lukeh 3y ago

Some interesting stuff happening here [1] and here [2] too. [1] https://github.com/stackotter/swift-cross-ui/tree/main https://github.com/stackotter/swift-cross-ui/tree/main [2] https://github.com/TokamakUI/Tokamak https://github.com/TokamakUI/Tokamak

deleted 3y ago

[deleted]

JanisErdmanis 3y ago

One thing that popped out for me was the care with which the documentation is made for MouseTrap.jl, and there seems to be no expectation for a user to look into GTK C docs to get some things running. Kudos to the devs for the achievement! At this point it seems that the deployment story missing. There is the BinaryBuilder.jl, but what steps does one need to take to make application bundles for multiple platforms at once and how large those bundles would be? Also, wouldn’t it make sense to bundle Julia with a precompilation file instead of using BinaryBuilder.jl?

3abiton 3y ago

I wasn't aware Julia had such a support on HN!