How would you write a GUI? Seeking opinions, recommendations, and what to avoid.
Hi all. I am asking this open-ended question (bottom of this post) because I am considering making contributions to an open-source project that would directly benefit me and other users.
Some background:
I have worked with an engineering simulation software called Ansys MAPDL basically everyday for the last 4 years, in both an academic and a professional capacity. It's not necessarily relevant whether you are familiar to that program to participate in this discussion. The relevant thing is that the GUI for MAPDL is written in Tcl/Tk and I don’t imagine it is going to be modernized (because of more modern, but distinctly different, replacements). This is a screenshot of the GUI for reference.
Why do people put up with such an old interface?
The power of the program is not its GUI, but the scripting language that can be run to setup and solve simulations. The program name is really the scripting language name, Ansys Parametric Design Language (APDL). It's somewhat like Matlab. The program also offers an enormous amount of control when compared to the more modern GUI that's been released, since the modern GUI holds a totally different philosophy.
The older GUI is really helpful in certain circumstances because it will spit out a file containing commands that were used in the session. This is a great demonstration of how to run a command or use a setting/config command, but a lot of newer features are buried in the documentation and aren't available in the older GUI.
My coding experience
I know the MAPDL language very intimately, but my experience beyond it is limited to some Perl scripting, and a bit of Python exposure.
Motivation
Open-Source Ansys API
Recently, Ansys started supporting an open-source Python project called PyAnsys. MAPDL is otherwise fully closed source, and this is really the only public-facing API. PyAnsys has basically converted a lot of MAPDL script commands to a pythonic format, hence Python can now be used to interact with MAPDL. This is great for several reasons, but is limited regarding interactivity. Interacting with MAPDL via Python is basically happening in a fancy console via Jupyter notebook or IDE like Spyder. Certain commands will bring up Python-based graphics displays of solid models and results plots, but there isn't a dedicated GUI open all the time.
The Question(s)
My question is whether it is feasible to write a frontend GUI to a bunch of python commands. If you were going to do it, how would you do it? What might you write it with? Would you even do it? Is this a stupid endeavor?
So this is a little bit shot from the hip, but python has perfectly servicible GTK/GDK bindings, and I've built GUIs in python with it in the past. It's as easy to use as any other GUI toolkit might be, and it's nicely documented.
At the very least, you should be able to get a 'hello world' going in 15 minutes or so, which should give you a taste of whether that would be a pain in your environment or not.
This is definitely a potential avenue. I see that GIMP was written in GTK, and it has a reasonably nice interface, as do the GNOME applications.
It looks like it's possible to get some rather modern-looking interfaces with GTK. Do you have any experience on how they look across different platforms?
Cross-platform you're probably better going with Qt imo. You won't get something that looks like a native app, but it will work well on all platforms with minimal effort.
It sounds perfectly reasonable to me. You'd basically be wrapping the python API with GUI elements. Just a matter of deciding what API pieces you want to expose and how to best capture the user input to encapsulate all of the required function parameters. It's probably going to be easiest to stay in a Python framework, either PyGTK like @Ephemere mentioned or PyQt. Depending on how the API works, it might not be possible to get back the image data itself for display in your GUI if they are just drawing the plot/model to the screen; so something to keep in mind at least.