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.