At least we can try starting with student project: “reinventing the wheel” is one way to learn fundamentals. I have a strong belief that someone will do it. 
1 Like
I have seen several examples where “reinventing the wheel” ended up in “reinventing a more complicated wheel” because it’s better to understand the fundamentals before doing it. For infrastructure like GUI toolkits there is no learning by doing.
flat boards, spokes in compression, spokes in tension, balls in cups
flat spring suspension, wound spring suspensions, wishbone suspension, torsion suspension, hydraulic suspension
direct lever brakes, caliper brakes, drum brakes, disk brakes, hydraulic brakes, air brakes, electrical energy recovery brakes, torsion energy recovery brakes
solid tyres, inflated tube tyres, tubeless tyres, airless tyres
3 Likes
Clearly, gui’s are something even Julia is thinking about
2 Likes
That vacancy is curiously thin on technical requirements. “GUI” could mean anything from desktop frameworks (Qt and friends), web front-ends (React, Vue, etc), or even terminal-based GUIs. Makes quite a bit of difference in terms of required experience. Given that cloud-based is mentioned a couple of times I would expect web front-ends is the case here.
AFAICT yes, some of them (i.e. not counting the ones that loads gtk/qt, e.g. libreoffice). And yes they do have issues with input methods. AFAICT they do implement the standard protocol, but are limited to the bad protocol on X and the worse one on wayland.
1 Like
Alternatives (or blueprints) to reinventing the wheel for publication-ready plotting GUIs:
- Support for ASCII, binary, HDF5, netCDF, FITS, ROOT, Ngspice and JSON formats with many options to control the import process
- Tree-like organization (parent-child hierarchy) of created object, navigation is done in Project Explorer
- Support for (i.e. embed) different open-source computer algebra systems (CAS) like Maxima, Octave, etc.
Having mentioned custom installations of backends and Julia above, in 19.08 we allow to set the custom path to the Julia interpreter similarly to how it is already possible for some other backends.
Cantor 19.08 – LabPlot (kde.org)
-
Veusz – a scientific plotting package
Reads HDF5, written in Python → add a Julia wrapper.
[FR] Add Julia support · Issue #560 · veusz/veusz (github.com)
1 Like
If you mean a wrapper for it then yes, if you mean a reimplementation, the I guess yes too “in finite time”, while a bad idea.
I hadn’t heard of this project and it seems interesting supporting all platforms, almost, not just desktop, also mobile, reads “Currently, only iOS is supported through us, however you can add android”. That’s version 0.1 after “months of work” by a team (“we”).
“Dioxus Desktop is built off Tauri.” So I went and looked, also built on Rust, but not only and predictably also JS:
Rust 76.9%
TypeScript 15.6%
JavaScript 5.0% […]
What a lot of people don’t understand is that GUI has a very important role in research and algorithm development for example.
In most cases, GUI is developed after a software has been written, to give a user friendly interface to an otherwise working command-line interface. It is so common to use GUIs this way that a lot of people mistakenly think that this is the “correct” way to do GUI or that it is the only way. It makes people feel warm in their belly knowing that the real program doesn’t need the graphical interface, that it could be easily ported to other operating systems or languages and so on. Which is true, but it is not the only use case and it comes with a price.
There exists a fundamentally different paradigm to GUI programing, one that does not try to separate the program from the GUI, which results in highly efficient iterative programing, necessary for algorithm development. Such approach could be used with Visual Basic for example, but the best tool for the job in my opinion was MathWorks GUIDE (that evolved into App designer). With those tools, you can develop your data loading, your processing, algorithms and visualizations with less typing, significantly faster trial & error iterations over your algorithm due to offloading all the overhead typing and running and re-running and opining and closing figures and changing inputs - to the GUI.
I haven’t seen anyone teaching this programing paradigm so researchers either have to figure it out on their own or in most cases remain unaware of it completely. I have actually seen people programing GUI’s on Matlab with code!
For that reason, people who have replied above with suggestions such as Gtk.jl or PySimpleGUI are probably unaware of the paradigm that I described (let’s call it GUI oriented programing - GOP for lack of a better term or because I’m ignorant to the real name of it). Let me be clear:
- If you have to code your GUI, it is not GOP. The whole point is to save time and effort by dragging and dropping buttons, text fields, plotting axes, etc. and applying functionality to them in the code, saving all the overhead.
- If you have a GUI designer (like QT) that you can compile into code - it is not GOP, because you have to make modifications to the GUI that merge into the existing code automagically.
- If you have to re-run the GUI every time you make changes to the code, even in non visual parts of the code, it is not GOP, because you have to make quick iterations over your algorithm, change normalizations, noise filters, data processing routines and see how the new code affects the visualization without re-compiling and re-running ( I guess in Julia’s case it could be feasible to do something similar to Revise.jl)
Some people unfortunately believe that GUI is slowing their research, that it creates overhead that is not necessary for their research. It just means that they don’t know how to use GUI oriented programing tools, which significantly accelerate research when used correctly.
8 Likes
For those of us who haven’t seen this paradigm, could you share some video(s) of how it actually works in MathWorks or elsewhere?
I tend to use Pluto and its widgets for such purposes — when basic GUI elements are needed during working on data/algorithms. They are quite nice, and the reactive nature of Pluto helps making them feel more “interactive” than other solutions.
No recompilation/waiting for TTFX is needed, thanks to Pluto.
8 Likes
Here is a video introduction to MathWorks’ App Designer
The Related Resources on the above page would also help.
I believe guide (GUI development environment?) was pure java and should be very easy to replicate. Drag and drop the GUI components into a canvas, run the naked GUI to interact with them and finally link the callbacks and you are done. Even I have done it!
1 Like
I have done exactly that but not for ignorance of GUIDE. I have used it and become utterly frustrated with it.
2 Likes
Unfortunately I don’t know of any videos for that and I’m not much of a youtuber.
I believe so too. In fact, Yair Altman (Technical articles - Undocumented Matlab) sort of “hacked” it and wrote a book about how to extend the GUI functionality by understanding the underlying Java.
I’m sorry to hear, I think that using GUIDE improperly (e.g. not understanding the “handles” object) can be frustrating for sure. For example, I saw people using global variables to share information between visual elements which is just not how it is supposed to work so it leads to complications and frustration.
GUIDE is nice to layout the widgets but it’s horribly verbose when exporting to code.
I’ve done dozens of figures in Matlab where I started with GUIDE and next stripped down the generated code to 10% of original size.
And yes mastering the use of handles is an absolute must.
I wish I had a small portion of what you said 
How do you offload it?
Like, Pluto.jl automatically rerunning on updates? I do get how that could be a time saver/convenient.
Otherwise, foo() to rerun everything I need to rerun after a change is much easier and faster than $(sequence of 10 button presses w/ associated menu navigation).
Obviously, I fall into the camp for which anything GUI is totally alien.
1 Like
Even Matlab is moving towards a web technology based GUI over time as opposed to their current Java based GUI.
If you really wanted a native windowing GUI, you could take a look at https://glade.gnome.org/ . That takes on the role of an app designer kind of approach.
When we get interactive threads with Julia 1.9, I think this would be worth exploring again
I’ve tried Glade and IMHO it’s awful. The documentation is the worst and the tutorials are as bad or worse.
2 Likes
I agree. We need something much better. GLMakie is already pretty nice (even though not 100% native). Hopefully in 1.9 (when Implement support for object caching through pkgimages by vchuravy · Pull Request #47184 · JuliaLang/julia · GitHub is merged) the load times become much shorter, then it could be a good foundation for a native GUI designer…
The best GUI designer I ever used was part of Delphi. It might be worth to look at FireMonkey - Wikipedia to pick up some ideas…