since some time I’m wondering how to (i.e. using which GUI library) to build a GUI-based control/measurement application using Julia. In the past I have used Python + PyQt + PyQtGraph to create quite performant GUIs which could communicate with lots of I/O devices - slow (RS232) and fast ones (GigE/PCIe devices) - and display retrieved data (medium sized heatmaps) at 25 FPS even without openGL acceleration.
Ideally I would like to embed GLMakie plots within the GUI which can be done in QML.jl if I see it correctly. However, due to the current licensing trend for Qt6 and beyond as well as the not-so-well maintained status of QML.jl I am not convinced that this is the way to go for me.
Are there any other (well-maintained and mature) GUI options for Julia for this use-case? I have the impression that web-based GUI libraries (e.g. Dash.jl) are quite mature but I suppose they are not really suited for my application.
I would be happy for a suggestion or experiences from the community.
I have played around with CImGui.jl in the past but the last release was almost 2 years ago. Additionally I’ve found it somewhat cumbersome to manage states in CImGui (i.e. device states etc.). You have to play around a lot with “hacks” to use real C pointers to Julia fields in order to make it work…
Unfortunately, after a ~decade in Julia I’ve not yet seen a convincing GUI solution, and expecting for one was the main reason I came here.
@joa-quim For years I have believed that Julia’s type flexibility and linear inheritance over parameterized struct abstractions coupled to judiciously entire dispatch coverage provided the essential constitutive elements from which a beautiful GUI package would emerge. I am not being unhappy … after all, I have not made it happen … not today anyway.
I welcome your thoughts.
That’s unfortunate. Makie with its GL backend surpasses what one could do with matplotlib/pyqtgraph in Python in terms of realtime plot performance. Pyqtgraph still only has fairly limited (and buggy) GL capabilities but is quite fast even when using the CPU.
As I’ve switched my whole workflow from Python to Julia since I’ve started using Julia end of 2020, the next step would be to switch to Julia for application development as well…
For now it seems QML.jl + GLMakie would be my best option but I’m still not convinced not running into a dead end the next years… Otherwise it will be the two language problem again (Julia for the backend, another language for the GUI).
indeed – it does seem imprudent to go in on a solution that has no avid devs and maintainability.
@JeffreySarnoff My thoughts? My basic hope was that we could have one GUI system that at least could rival with Matlab, specially with the old one (before the full java sh…) that ended circa 2015. It was not an elaborated one, kind of mediocre looking with our current standards, but one really fast where one easily can (I say can and not could because I still use it) draw raster as well as vector data with lots of context menus that are vital for adding specialized options.
I made two attempts to start recreating it. First with IUP that I ended due to a too bad documentation and the smell of being a dead end and libui that stalled because it stalled at origin. I still have (now much more contained) hopes that this will regain traction again, but original’s author manifesting recent interest on it seemed to have shouted out an attempt from community to take over the development.
I know the problem is hard and googling shows several discussions on multi-platform solutions where at the end they all seem to converge too:
Qt is a monstrous but it’s the only real alternative. And we have no access to it in Julia.
On top of all of this we also have the Julia latency problem, so you see, still waiting from that flash of light through a covered sky.
And, as a curiosity. GMT.jl was created in advance waiting that it could be made the Julia back-end my ~200k lines Matlab Mirone program.
I have advocated the path of most already done-ness.
Any other route puts our carts before their horses in my estimation.
25fps at 2040x60 is ~3 million pixels / second or about 100_000 pixels each frame.
Does this seem appropriate or too slow?
Looks good, actually a visualization like this is quite similar to what I need: Line Integral Convolution / Zihou Ng / Observable
How to achieve this in Julia with the existing packages/tools? The data would be calculated in Julia and has to be passed to JS Frontend.
I have another thought, likely not so popular here, and it’s one that says most people use regular computers.
Regular computers (laptops) are those that do not have infinite disk space, so packages that depend on many other packages and so forth till the GigaByte championship, is not such a good thing. And those computers also normally do not have very very large RAMs.
You maybe be right on the browser-GUI’s but my feeling is that they all aim at that class of users that don’t care about the hardware.
to the contrary – while I may have this backward … it used to be true that
html 5 wizardry and css abstractions, a jump on the gtks and kin with respect to performance x flexibility. I have used Qt, and it looks better and behaves more uniformly (imo) than gtk based interfaces. And yes, it compiles to make very good use of the Qt innards. However, if you want to add a nontrivial new widget that has its own interpretation of context – that is much more work than would be the case with appropriate browser driving libs/ops. There is no speed advantage in missing having something needed.
However, for the quite legitimate use case you raise, FLTK https://www.fltk.org/, may be the fastest reliable utilitarian gui dev platform of them all. IWhile providing a Julian interface would be a chore, the binarybuilder part is cake. So a not so Julian set of interfacing routines could be partially autogenerated pbly.
Let me know your opinion of FLTK and FLTK 1.3.8: Programming with FLUID
Well, I know about FLTK for a long but being a C++ toolkit has always put it out of my interest. And I also had the impression that it was a dying solution, but I might be very wrong on this.Please don’t take me as GUI expert. I happened to have learned the Matlab GUI system in some depth because it’s a simple thing that normal people can learn, contrary to the C++ … ones.
But, yes, if we could have a wrapper to FLTK I think that would be very helpful and would cover the needs of many of us that want to build GUIs in Julia, and one that does not put the GPU running at 100% even when were doing absolutely nothing with the mouse or keyboard and the display is still (cimgui and others).
BTW, I also tried Red once but damn it, those guys are unbelievably still on 32 bits only.
After some more detective work, your sense of an erstwhile FLTK appears correct.
I am looking at more current, vital options that have likely longevity on their side.
CImGui.jl is no longer maintained. My solution is embedding julia in imgui.
Not certain if it will do what you need, but Gtk.jl and perhaps more easily GtkObservables.jl may be an option. In principle it should be possible to get Makie drawing into a Gtk canvas, but I suspect that might take a bit of work. If you’re content to have the GUI just be a “controller” and have GLMakie do all the plotting in a separate window, this should be easy since both are based on Observables.jl—you should be able to get Makie keying directly off the observables that link to GUI elements (or vice versa).