Anyone crazy enough to develop a pure Julia GUI toolbox?

Yea, I think something like GtkReactive.jl

https://juliagizmos.github.io/GtkReactive.jl/stable/drawing.html

… or its potential successor in GtkObservables.jl as mentioned above seems like it is moving in the right direction.

https://juliagizmos.github.io/GtkObservables.jl/dev/controls/

Using GTK as a basis seems like the path of least resistance since it uses C rather than C++ and is thus easier to call directly from Julia.

Another alternative is the QT based QML.jl

That said writing the equivalent of Java’s AWT, Swing, or the Android UI does seem unnecessary given the availability of the above.

4 Likes

Personally, if you are interacting with a lot of data points, I would look into a immediate mode GUI, of which imgui is the most famous.

They are very underrated!

And much easier to use than something like gtk, imho.

See what imgui can do:

and a nice Julia wrapper:

imgui also compiles just fine to webassembly.

7 Likes

Well, I would not say it is unnecessary… GTK has a lot of disadvantages, Glade is terrible and you end up reading C library documentation…
QML is broken on 1.7…

3 Likes

imgui has a huge drawback. It’s barely usable from laptops because it puts the gpu running at 100% all the time. I don’t want mine to melt that way.

As I referred before in other posts about this. My hopes were in libui and even made a wrapper once but the libui project looks dead, though there are still people trying to resurrect it.

4 Likes

Okay, but how much is necessary to rewrite to achieve that? Could it be in a package on top of GTK.jl or not? The GTK.jl design seems the same of many solver wrappers (Gurobi.jl, CPLEX.jl, GLPK.jl, Xpress.jl) that is: just wrap every function automatically and point to the original documentation (often C/C++). JuMP then enters as a layer above all of them which allows writing mathematical models without worrying about the specific solver and its peculiarities. The problem here is that, as there is no layer above GTK.jl, it is not worth converting all documentation with small changes to Julia, nor the code follows what would be Julia design patterns. A package above GTK.jl (instead of replacing GTK.jl) could take care of these problems.

2 Likes

GtkReactive is a package that sits above GTK.jl

https://juliagizmos.github.io/GtkReactive.jl/stable/controls.html

GtkObservables is a further iteration on this taking advantage of Observables.jl:

https://juliagizmos.github.io/Observables.jl/latest/

Importantly, Observables.jl is generic. You could combine with another graphics framework to enable a similar signals-and-slots pattern.

2 Likes

This is an unnecessary splitting of hairs. I think it was very obvious what I was talking about with the OP given the current state of the Julian infrastructure. I don’t believe that the creators of GTK or QML were asked to parse out their use of words in such a manner. I guess my mistake was not including the phrase “native Julia at a level most reasonable developers can use without having to re-write the entire operating system in Julia.” I’ll try to be more specific in the future

Another option I haven’t seen mentioned is making a TUI toolkit. Here are some from other languages

3 Likes

Gtk.jl actually does abstract quite a bit from GTK already but it’s true it could be improved to hide the library more. That said I think it’s very hard to get away from GTK logic and design without encountering some serious issues. For example if a user wants to update part of the GUI at regular intervals, it might not be safe to do it from Julia’s side, because you can invalidate GTK objects and that will lead to random segfaults (Gtk apps can be a nightmare to debug). Instead the user should add a callback to GTK’s main loop, so it’s hard to hide these concepts completely.

Working on Gtk.jl is also difficult because you need to have a good understanding of both GTK and Julia’s internals. A lot of GTK designs are also linked to C limitations (GTK has it’s own pseudo object system, memory management,…) and presumably one could do something better in 2022.

6 Likes

Looking more into Wayland, it does look like there might be decent cross platform support in the future beyond the native Linux support.

macOS: GitHub - owl-compositor/owl: The portable Wayland compositor in Objective-C
Windows Subsystem for Linux: Run Linux GUI apps with WSL | Microsoft Docs

While someone may still need to understand C to do move this forward via libwayland, it does seem plausible. Eventually, it is also may be possible to implement the Wayland wire protocol directly in Julia without needing to depend on libwayland C library.

https://wayland-book.com/

1 Like

@logankilpatrick put together a nice overview here about existing frameworks:

6 Likes

@caleb-allen I think you are getting the gist of the original idea along with @jonathanBieler and @ufechner7. There seems to be a lot of folks on this thread that like to look at a problem and see all the things that can go wrong and say it can’t be done or shouldn’t be done. If you or anyone is willing to risk abject failure and embarrassment tilting at this windmill and possibly come up with something useful, elegant and Julia based towards this end, I am willing to set up a Git Repositorynot that I have a damned clue on how to do that but there are tutorials, and start dedicating time to it. If not then I am perfectly willing to table this discussion until a later release.

Okay, and what level is that? This includes rewriting GTK.jl or not? Or it will build above another library like QT? It will support X11, Wayland, Windows, or focus on just one of these? These are things that need to be defined before starting the project.

1 Like

another option might be to wrap one of the various new UI toolkits for Rust:
https://www.areweguiyet.com/

personally, I’m skeptical of the viability of user interface-toolkits that don’t target the browser (or adjacent technologies) for at least one of the backends.

2 Likes

It would be cool to have Julia bindings to Rust’s gui libraries. Possibly even cooler to port them to pure Julia, but that would take a lot longer.

Neither of these is yet stable but both quite interesting:

2 Likes

I would be interested in a GUI toolkit that does not build on top of GTK (problematic programming model) and not on top of QT (license issues, large, C++ not so easy to integrate with Julia).

I like the Rust libraries, that were suggested, but also GitHub - MasFlam/AttoUI at bestofcpp.com

Not so sure if extending Makie.jl would also be an option…

3 Likes

It sounds a web-based solution will perfectly fit your requirement. I used to write a Flask-based app (Python) to handle my simulation data. I believe in Julia domain maybe Genie or Dash will do the job well. It works perfectly for such tasks.

1 Like

Press “OK” then wait for “OK” codepath to compile, hourglass pops up.

Press “Cancel” wait for “Cancel” codepath to compile, hourglass pops up.

1 Like

Exactly. Without some bit of pre-compiled code doing the heavy lifting a pure Julia GUI would be a nightmare to use. Which means either good binary caching in Julia itself or system images containing the GUI code. Or, of course, just use a compiled library such as GTK as a backend.
I love Julia, but honestly at this stage I think it’s just not the right language for GUI development (or similar things, such as games).

This actually happens in Gtk.jl (presumably because callbacks & wrapping code need to be compiled), it doesn’t seem much better than in Makie. I think all this GUI talk needs to assume we’ll have good binary caching at some point.