Mousetrap.jl: a GUI library for Julia and C++ that wraps GTK4 | Hacker News Reader

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

github.com

157 pointsxgdgsc54 comments

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/ [2] https://juliagizmos.github.io/GtkObservables.jl/stable/

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?

If you like guis and Julia, this one is outstanding

https://github.com/Gnimuc/CImGui.jl

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

It very much looks like it: https://www.gtk.org/docs/installations/windows/

Yes, the Julia ecosystem provides cross compiled binaries for many platforms

https://docs.juliahub.com/GTK4_jll/XRLGj/4.10.5+0/#Platforms

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

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

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.

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".

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.

You CAN try get rid of call backs if you have nice language like Julia that can inline the call back

You mean using anonymous functions? This is still a callback, it is just a bit nicer (at least assuming the callback code is short).

No, I mean by inlining.

"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.

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.

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?

Some interesting stuff happening here [1] and here [2] too.

[1] https://github.com/stackotter/swift-cross-ui/tree/main [2] https://github.com/TokamakUI/Tokamak

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

Reply on news.ycombinator.com