Future of Qt and other frontends

[375gnu]

Current state: We have two actively supported frontends: sdl & qt, we have 3 less supported frontends: gtk, glut, win, and 2 dead frontends: kde & macosx.

kde frontend is essentially superseded by qt. macosx will be superseded by the new macos frontend (I hope).

sdl essentially supersedes glut, the only problem is that libsdl2 is much bigger than freeglut and has quite a lot of dependencies. Actually, I added it because I need a frontend able to create an EGL context. Maybe GLFW would be better alternative. But we have an unofficial port to HaikuOS and it's powered by glut. I think we need a very basic interface, just need to decide which one.

gtk uses gtk2 library, is unportable to gtk3, uses C-style API, has no support for high DPI. No support for GL ES. And it's ugly :) For me its only purpose is to be used on old computers, so at least in 1.7 we should keep it. UPD: in 2021 it was ported to gtk3 and has support for GL ES.

win has no maintainer, uses winapi directly and all that winapi stuff runs in the same thread as Celestia itself, so when a menu is opened no simulation is performed, has not support for high DPI. Doesn't support GL ES. So essentially all said for gtk applies for win.

qt. Qt library itself has obscure future. To install it on windows you need an account. Different windows versions are compiled using different compilers (5.10 - VS2015, 5.12 - VS2017), afaik 5.12 doesn't provide 32bit builds. More, there are rumors that LTS versions will be opened only in one year since their release. It's unoptimized: our qt frontend uses 147MB vs 113MB with sdl, consumes 5% more cpu power, it sets GL context every single frame. It has bugs unfixed for years: black border around splash screen because of unsupported 8bit transparency, QGLWidget is deprecated but QOpenGLWidget has problems with menus in fullscreen mode. GL ES is not supported on all platforms, even on amd64 GNU/Linux I was unable to enable it. The only reason to support qt is that this is the only cross-platform and feature rich frontend. Actually I want to replace it with WXWidgets or other modern crossplatform lightweight toolkit.

So, what should we do? What to drop, what to replace, what to continue maintain?

[levinli303]

The Mac frontend (in the current codebase) can be safely dropped, the build that I'm maintaining (I think) has all the functionality that 1.6.1 has. Also with metalangle and Mac Catalyst, one should be able to make iOS frontend run on Mac too (but I doubt it would be useful).

all that winapi stuff runs in the same thread as Celestia itself Mac/iOS frontends do the same, render code runs along with api that manipulates native controls, I've not figured out a way to put rendering in another thread other than main thread

For cross platform desktop toolkit, there are other popular ones, like Electron, Xamarin, but I don't think they are good choices. I do not know much about wxWidgets but QT is still ok to me, at least it is not dead and still many apps use it. But I'm just surprised it doesn't support GL ES, does QT only support GL ES on mobile platforms?

I'll talk about the mobile frontends a bit. The current iOS frontend builds on top of native iOS APIs with mostly Swift (Objective-C for bridging), and Android frontend builds on top of native Android APIs with mostly Kotlin (some Java and JNI for bridging). I did not turn to mobile cross platform solutions (like Flutter, React Native, Xamarin, QT) because native APIs gives me more controls over things and I think is easier to bridge with CPP codes. Even in the near future, iOS/Android should still be the dominating operating systems in the market, so these APIs should be in good support. Fuchsia might be coming in the future, of which the native toolkit is Flutter, if it becomes popular, then probably there would be need to have frontend built on Flutter.

[pirogronian]

After short researhe with help of Wikipedia, I cant see any suitable solution for all supported platforms. Maybe for all desktops, like wxWidgets or Fltk, but not mobiles. At least unless we agree to maintain Java code as part of common (and mandatory) Celestia code.

[stalkerg]

Also, you shouldn't forget about Vulkan... have no sense thinking about macos frontend if next version will drop OpenGL.

[375gnu]

For this case we can use OpenGL ES + Angle.

[levinli303]

I do not think OpenGL (ES) support will be dropped any time soon, definitely not in the next version where they added OpenGL ES for macOS for the first time (despite being deprecated). and yeah there is working port of it working with ANGLE