Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Qt5 UI for SolveSpace #401

Closed
Symbian9 opened this issue May 9, 2019 · 14 comments

Comments

@Symbian9
Copy link
Contributor

commented May 9, 2019

Expected behavior

Qt5 UI for SolveSpace

Actual behavior

SolveSpace use GTK+ for the UI

Additional information

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?

@bcmpinc

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

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

@data-man

This comment has been minimized.

Copy link

commented May 9, 2019

Maybe ImGui would be better?

@ruevs

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

ImGUI has been discussed before:
#263

@Symbian9

This comment has been minimized.

Copy link
Contributor Author

commented May 9, 2019

Maybe ImGui would be better?

This issue is feature request for Qt5 UI for SolveSpace.

@imrn

This comment has been minimized.

Copy link

commented May 9, 2019

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.

@bcmpinc

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

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.

@imrn

This comment has been minimized.

Copy link

commented May 9, 2019

#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?

@Symbian9

This comment has been minimized.

Copy link
Contributor Author

commented May 9, 2019

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.

@whitequark whitequark added the question label May 9, 2019

@whitequark

This comment has been minimized.

Copy link
Member

commented May 9, 2019

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.

@data-man

This comment has been minimized.

Copy link

commented May 9, 2019

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

@whitequark

This comment has been minimized.

Copy link
Member

commented May 9, 2019

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.

@imrn

This comment has been minimized.

Copy link

commented May 10, 2019

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

@whitequark

This comment has been minimized.

Copy link
Member

commented May 10, 2019

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.

@whitequark

This comment has been minimized.

Copy link
Member

commented Jul 31, 2019

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

@whitequark whitequark closed this Jul 31, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.