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…
@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.
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).
@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.
Using now standard browser-based gui-ness leveraging the worldwide support for and development of HTML/CSS/JavaScript(TypeScript) and friends. We do have a few well produced packages that would be of some help getting from Julia to and back from browser based GUI instruments/planes/objects …
Any other route puts our carts before their horses in my estimation.
Would be fine for me, but now the question for Dash/Electron/Blink/…: I have to display for example 4 heat maps at the same time at 25 fps which have an image size of 2048x60. Is this doable? From the documentation of these packages I have doubts that the javascript solutions responsible for plotting can handle this fine. Maybe embedding WGLMakie is possible?
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
the next-gen browsers (the ones out now) had, through javascript libs
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.
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.
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).