Discussion: Should the engineering GUI be rewritten?

[pmelanson]

I'm coming back to orbitx after a little hiatus, and taking a fresh look at the engineering GUI code it's a little obtuse. I think this is because I made the decision to go with tkinter, which are the Python bindings for the tk GUI tools, which are a platform-generic way to make windows/forms/all that.

But tkinter is just bindings, so it's a little awkward to use. The options don't have native Python verification, you have to just try stuff and see if it works. Also, native window applications (like a form pops up with "Ok" or "Cancel") are a little 2000s/2010s.

Considering the goal of OrbitX is to

1. provide simulation tools that are an OCESS-specific blend of realistic but simplistic
2. be maintainable by OCESS denizens

I think tkinter is an uphill battle to accomplish #2.
In particular, tk/tkinter is old (about as old as I am), so it's not a relevant framework OCESS tinkerers to learn.

The way I see it, there are three options:

1. Stay the course, using tkinter
   Not ideal, for reasons mentioned above

2. Switch to a Python-native GUI framework, like PyQT
   This has the benefit of at least sticking with Python, which most of the rest of the codebase is written in

3. Rewrite engineering in some web technologies like a Javascript framework
   This is possible because I've enforced a gRPC boundary between server/client components of OrbitX; the physics server is written in Python, and so is the flight GUI client, but the flight GUI client communicates via gRPC to the physics server. The engineering client, then, could just as easily be written in a totally different language and communicate over an internal-API via gRPC.

The benefits of #3 I see are:

• It allows OCESS tinkerers who are more used to web technologies to contribute to OrbitX
• Web GUIs are perhaps more suited placements of buttons on an SVG background, which is what engineering/power grid looks like it's going to be (doing this with tkinter is a pain, which motivated this whole discussion).

---

I'm going to ask OCESS denizens this question, which is why I'm writing this issue. Which of options 1, 2, or 3 would you prefer?

In particular, for option 3, do you have a web framework/architecture in mind? I accept ideas on how to re-implement the engineering GUI in a web framework, but I would be particularly overjoyed if you were opinionated enough to also contribute code and PRs (in fact I would gladly set up some coding time together to get you started!).

TL;DR: I'm farming opinions on how to re-implement the engineering GUI for OrbitX, possibly via a web framework/architecture. If I'm going to be the one implementing it, I'll be selective about the opinions, but if a contributor wants to step in I would be more than happy to give you that freedom :)