Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Qt5 UI for SolveSpace #401
Qt5 UI for SolveSpace
SolveSpace use GTK+ for the UI
I remember that there was discussion on possible porting SolveSpace UI to Qt5 (as alternative to GTK+), but don't know is there any progress on this. Anybody working on it?
Even Qt is somewhat popular for now, it is showing it's age. It is using old C++ paradigms (even it reinvented them) and makes sure you use them too. And it is huge.
I too think imgui as a credible alternative.
I'd suggest reopening #263 and continuing the discussion there.
The issue with ImGui is that it is a library for creating a GUI in your OpenGL application, whereas solvespace is a GUI application that contains an OpenGL viewport. GTK+ is used for more than rendering the GUI. It is also used for:
ImGui provides none of those.
The main reason why we might want to get rid of GTK+ is that it does not provide a stable ABI, which frequently has been an issue with packaging (#17, #336, #344). Furthermore, if we want to add Vulkan support, because MacOS dropped OpenGL support, we have to either switch from GTK+3 to GTK+4 (#376) or a different GUI toolkit with Vulkan support such as Qt5 v5.12+, which internally uses MoltenVK.
Do you think it is really a show stopper?
There are three separate questions in this thread, which I'll address one by one:
Migration to imgui
Imgui is completely orthogonal to the platform toolkit we're using. The platform toolkit is used for things like menus and file selectors, and I do not think that such widgets composed with imgui are remotely acceptable for everyday use. If there's a direction I want to take SolveSpace in, it is the direction of being more consistent with platform it's running on, not less.
Using imgui for drawing the internal SolveSpace GL-based UI components is, in principle, an option, but I don't think it would be a major win. Currently most of the complexity in that area is in the management of state and imgui doesn't help there.
Migration to Qt on Linux
The original choice for GTK on Linux was made because of the same considerations as with the other platforms: Ubuntu used GTK as the primary toolkit, and SolveSpace was to integrate well with the most popular distribution. I've heard that Ubuntu will migrate to Qt as the primary toolkit, but I'm not sure if that's the case in practice. If it is, we should migrate to Qt as well.
Regarding ABI issues, an AppImage that cannot be run because the platform GTK is incompatible with the build-time GTK is only a little less useless than an AppImage that cannot be run because there is no platform Qt at all.
Adding Qt as a second option on Linux
I'm not generally opposed to it. I am a bit worried about having to update 4 GUI adapters (5 if asm.js ever ships) instead of 3 each time a new element is required, but since I'm familiar with both GTK and Qt it's not a major issue.
Migration to Qt on macOS
There are two serious problems with macOS and none of them are solved by a different GUI toolkit. First, I have no way to do development on a macOS 10.13 because I have no Apple hardware and it's no longer runnable in a VM. Second, supporting newer macOS would require SolveSpace to gain a Metal or Vulkan rendering backend.
It's not realistic to add a Metal or Vulkan rendering backend because doing so would mean either dropping support for not-so-old OpenGL-only devices like ThinkPad X220, which is unacceptable, or maintaining an OpenGL 3 and Metal/Vulkan rendering backends in parallel, which we don't have enough people for.
Qt and "Modern C++"
The Qt preprocessor is not an issue at all because it is handled just like any other platform-specific build step. We already use various kinds of preprocessors for Win32 and macOS builds.
Whether Qt uses or does not use "modern C++" is irrelevant because it bears no difference to the vast majority of the application, which will not end up having a Qt dependency to stay embeddable. Whether a ~1000-line platform adapter is using the latest fad C++ practices doesn't affect its maintainability much.
@whitequark : Thanks for detailed comments for defining your technical position and preferences even if we (mere mortals ;) ) miss the core points. As you made perfecly clear that, it is not a matter of black and white, I'd still want to get some insights about the gui direction solvespace would be heading in -say- next 5 years.
Given #375 requesting a complete stripped down headless/guiless solvespace for programmatic modelling, my concern would be that some qui library would creep deep into the core api so that such an isolation would became theoretically impossible. I think the style Qt dictates have an inherent potential for that.
The answer to this question is twofold.
Therefore your concern about Qt 'creeping' into the rest of the codebase is unfounded. There is no gain from doing so, and so it will not be done.