I'm in favor of porting it to Qt5 as well. If @whitequark is okay with this, I'm willing to pick this up.

Maybe ImGui would be better?

ImGUI has been discussed before:
#263

Maybe ImGui would be better?

This issue is feature request for Qt5 UI for SolveSpace.

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 think Qt will be unable to utilize modern C++.
http://www.open-std.org/JTC1/SC22/WG21/
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2019/

https://www.reddit.com/r/cpp/comments/5t7d6u/trying_qt_seems_great_what_downsides_am_i_missing/
In practice the pre-processor can be a huge deal if you need to get it to play nice with something else that does weird fancy stuff, such as OpenGL, MPI or similar. They provide wrappers and libraries for compatibility with a lot of these but it's fairly limiting and can be a big mess to deal with.

I too think imgui as a credible alternative.

Blizzard Entertainment is the primary supporter of Imgui.
Project makes +$1000/month on patreon.
https://github.com/ocornut/imgui
https://www.patreon.com/imgui

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:

• handling user IO;
• creating OS-native file dialogs;
• getting a list of system fonts and font metrics;
• creating an OpenGL context (or at least a window/widget that can be used for that purpose);
• clipboard support;
• configuration files.

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.

#376, #398 and possibly other issues mention that supporting MacOS is becoming increasingly difficult. Is it worth the investment with the folllowing dead end tech?

• Qt only toolkit and tools
• Ancient C++ practices
• MacOS

creating an OpenGL context (or at least a window/widget that can be used for
that purpose);

Do you think it is really a show stopper?

Do you think it is really a show stopper?

Please, stop spamming in this issue thread!

@imrn, if you want discuss ImGui use #263 thread.

There are three separate questions in this thread, which I'll address one by one:

1. Migration to imgui,
2. Migration to Qt on Linux,
3. Migration to Qt on macOS.

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.

Just for thinking.
awesome-cpp#gui
awesome-cpp#graphics
Maybe Magnum Engine or Ogre3D.

I would appreciate it if people didn't try to suggest things without familiarizing themselves with the problems that SolveSpace faces. I've been using C++ for many years and I am well aware of the many graphics and widgets toolkits it has.

@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.

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.

• Right now, there is a lot of deliberate effort invested by multiple people to keep the platform-specific GUI (and non-GUI) code completely separate and self-contained from the rest of this application. There are currently no plans to change that, so any Qt code would also stay separate and self-contained.
• Qt has separate libraries for the core and GUI parts; Qt5Core and Qt5Gui. It would be completely unreasonable to require Qt5Gui for headless or embeddable code, but requiring Qt5Core--the part with data structures only--is not inherently a problem any more than requiring C++ STL is, although Qt5Core is quite a bit larger. Nevertheless, there are currently no plans to change that, as the Qt collections are not any better than the STL collections (they're about equally bad), so they would simply make interop harder.

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.

Closing as the question (viability/necessity of migration to Qt 5) is answered in this comment.

Cairo widget for FLTK and Qt

• https://github.com/user1095108/cairowidget

This code illustrates one possible way to use Cairo in your FLTK and Qt projects. It does not require support for Cairo or SVG to be compiled into FLTK or Qt and shows an alternative way to render SVG using Cairo and NanoSVG.

I also explored support for Cairo's OpenGL backend (Cairo_Gl_Window). This could make for fast renders of large interactive GUI controls, but the backend has considerable bugs.

Qt markedly outperforms FLTK in rendering performance.

Qt would allow easy porting to Android:

• https://solvespace.com/forum.pl?action=viewthread&parent=3966&tt=1635827927

It seems someone has ported SolveSpace to QT after all. Let's see how it goes :-)
#1406