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?
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.
"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?
It's so terrible that we've been using it for more than 20 years for a 600kloc cross-platform digital audio workstation.
It's so terrible that it's FLOSS-iness encouraged us to fix problems with the macOS (then OS X) and windows aspects, and contribute them back (mostly) to the project.
It's so terrible that when I meet other developers we swap stories about their chosen cross-platform GUI toolkit, and things seem to pretty much even out.
GTK doesn't have accessibility on Windows and macOS, correct? Do you implement your own a11y? Because music as a profession seem to have a higher proportion of visually-impaired people, and I would have though that any DAW, etc. would make sure to cater to them to be competitive in the market.
I think that was the case, but I remember hearing that GTK4 has made accessibility a priority and introduced some kind of system similar to what ARIA is on the web. Not sure if those accessibility plans were fully realised though.
That is pointless hairsplitting, in practice in every mainstream platform where programs can use shared libraries there is a C ABI. That it is not defined by the C standard doesn't mean it doesn't exist, it only means that the C standard cannot be relied on for the ABI - and that is all that it means wrt. to the C standard. But very few programs limit themselves only to what is defined by the C standard.
A stable ABI ties you down in a lot of ways that compiler and language authors don't place a ton of value on early in the lifetime of a language. And to be honest, the necessity of one is a bit over played. Dynamically linked system libraries are going the way of the dodo.
No, seriously, though -- it does seem bizarre that "a newish library" is one you wrap like this.
I get that its touchy saying that GTK4 is bad -- but I genuinely don't understand why GUI libraries like this appear to break backward compatibility SO OFTEN, with nearly zero (apparent and obvious useful) innovation?
GTK4 certainly comes with a lot of breaking changes[1] compared to Gtk+ 3.0 - not least the naming change :) - but you'll probably only need to update a few things in the average GTK application to upgrade. It's not like they've changed the constructor function signature for a GtkButton or something.
The most obvious change to a non-technical observer is of course the new default theme, which I am rather unhappy about because they didn't back-port it to Gtk+ 3.0, so in the context of a GNOME desktop it's now half-and-half old and new theme depending on whether someone has bothered to migrate the application in question. This is slightly unfair of me though, since compared to a mixed Qt/GTK desktop or the average Electron app or even Microsoft products since Windows 8, GNOME is super consistent visually.
I don't develop, but "a few things" DRASTICALLY contrasts with my experience actually trying to use GTK as a user. Number changes in GTK BREAK ALL THE THINGS ALL THE TIME.
It REALLY doesn't make sense to me how badly, e.g. themes break between versions. Offhand, I can't think of too many "standards" that break that badly, it just makes no sense to me that GTK2, GTK3, GTK4 apps simply CANT co-exist. Like AT ALL, without severe uglification.
That is a bit unfair, a GUI library is a huge undertaking. I did see some projects move to Qt, but not many. It is with C++ quite different from GTK. Not sure how FLTK fares, but I don't see many projects using that.
My point is that if you think the wrong things are being wrapped, it may be profitable to self reflect. It may mean what you want is not aligned with what people with the time and ability to build things like this want. If you think everyone else is wrong (which to be clear is not necessarily a bad thing) it can be worthwhile to attempt to do that thing yourself, and find out why no one else has done it. In the best case, you get what you wanted. In the worst case you learn why it hasn’t been done.
> That is a bit unfair, a GUI library is a huge undertaking. I
But its not about a GUI library, its about a wrapper for one. After all, if its “the worst” library getting wrapped, then obviously there’s a lot of easy opportunities to wrap a better library.
IMO Gtk4 (the one being wrapped) is terrible even on Linux :-P. Gtk peaked at Gtk2 and Gtk3 is passable with the right theme but i can't say i liked any Gtk4 program i've seen (fortunately Gtk4 doesn't seem to have much of an uptake so far).
There are hundreds of apps on Flathub that already use GTK 4. Bottles, Easy Effects, Mission Center, Amberol, Celluloid, are all popular (more than 60,000 installs from Flathub) examples of apps that are using GTK 4. I personally use all of them and think they are some of the best looking apps available on Linux.
You have a choice to install a non GTK4 program with an identical function. And yet 60K people chose the GTK4 option. You may not like the UI, totally fine, but clearly plenty of people do when they're looking through a catalog of just screenshots and pick the GTK4 option.
Amberol? Celluloid? Mission Center? Practically every toolkit out there has one of each these apps before it even hits version 1.0 just as a demo of its capabilities. There's dozens if not hundreds.
Bottles has PlayOnLinux or Lutris. I'm not familiar enough with the Linux audio landscape to know any Easy Effects alternatives for it off the top of my head. Nobody's locked into anything or being forced into GTK4. Heck, Celluloid is just straight up a wrapper around MPV.
Bottles is much better designed than PlayonLinux (which is a dead project) or Lutris which have absolutely dreadful UX paradigms. They are not even equivalent piece of software, and that has nothing to do with GTK4.
Then let's take that one example off our friend upthread's list and I fully believe their point still stands very strong. Users use the GTK4 apps that devs chose GTK4 to build with, and that stands even when an app has competition in its space. The evidence given demonstrates that pretty clearly.
> There are hundreds of apps on Flathub that already use GTK 4
Might be that i also avoid flathub, but i haven't seen much use of Gtk4 in the applications i use myself.
> think they are some of the best looking apps available on Linux.
Ok, thanks for the information but i think otherwise, i dislike how Gtk4 looks. TBH i also think Gtk3 looks bad but i've got a theme for that. Perhaps i might find a decent Gtk4 theme too.
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.
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
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.
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.
[1] https://docs.juliahub.com/Gtk4/rFcBQ/0.5.0/ [2] https://juliagizmos.github.io/GtkObservables.jl/stable/