Created a Qt 5 port for solvespace (would like to provide source)

[shingen75]

System information

• SolveSpace version: 3.1~;
• Operating system: Windows ( 10 and 11) / Linux ( CentOS 7 )

I have ported the solvespace user interface to Qt and I have tested all the basic functionality and I believe everything works correctly.
I have updated the CMakefiles and added an option to build in Qt mode (USE_QT_GUI). An additional library tiny2xml ( added to the
extlib and referenced using extlib/tinyxml2/CMakeLists.txt when in Qt mode) was used to save/load the configuration file solvspace.conf (preserve the settings). I was wondering if it would be possible to provide you with the Qt code.

[ruevs]

@shingen75 how did you port it? I do not see a fork in your GitHub account? If you provide a link to your fork or create a pull request we can look at your port.

[phkahler]

@shingen75 The approach should be to create a new file "guiqt.cpp" in the platform folder. QT should only be used as a GUI on Linux, and only as an option with the default being GTK. As ruevs said, create a fork, make a branch for your QT stuff and let us know when it's ready or create a PR.

I'm curious.

1. why did you do this QT version?
2. Why a new way to save the settings?
3. does it work on X?
4. does it work on Wayland?

[ruevs]

2. Why a new way to save the settings?

I was wondering the same, but decided to take it a step at a time.

[shingen75]

@shingen75 how did you port it? I do not see a fork in your GitHub account? If you provide a link to your fork or create a pull request we can look at your port.

@ruevs
I am sorry, I was not aware of the procedure to do the port on github. I use git internally at work but I have not used github for project development. I will fork the repository and put the port work in it. I will do this over the weekend.

[shingen75]

@shingen75 The approach should be to create a new file "guiqt.cpp" in the platform folder. QT should only be used as a GUI on Linux, and only as an option with the default being GTK. As ruevs said, create a fork, make a branch for your QT stuff and let us know when it's ready or create a PR.

I'm curious.

1. why did you do this QT version?
2. Why a new way to save the settings?
3. does it work on X?
4. does it work on Wayland?

@phkahler
Thank you for the comment. I initially looked over the code and I have followed the same process that was done to provide a win32, gtk, ..etc platform support with the Qt port. As I have mentioned to @ruevs I was not aware of the github process of the fork / pull request to contribute code. I will do the fork first this weekend and add the changes made for the Qt support to it.

With regard to your questions :

1. why did you do this QT version?
   Many of the projects I work on use Qt version 5 and it I was looking at the possibility of porting solvespace to Qt to evaluate whether to use it in future projects. Qt 6 should not be that much different that Qt5 in terms of the capabilities used for this port. For now, I will not be using a direct integration of solvespace qt port into other projects. But rather use it as a stand alone. This would make it easier for me, for example if I set the look and feel or add theme, for solvespace to have the same look and feel.

2. Why a new way to save the settings?
   The settings are saved differently I believe in both the current solvespace windows version and the gtk Linux version. I am not sure about the MacOS version. For projects I usually work on xml files are more commonly used as a file format for settings. So I have implemented the port to use an xml file. The same file is written in both Windows and Linux

3. does it work on X? does it work on Wayland?
   I have tested the solvespace qt version on CentOS 7 gnome desktop which was the the requirement for me if I was going to to use this. I also tested this on Windows. I am aware that Qt support wayland and other X desktops so I am going to guess that it works but I have not tested it myself.

Also I would recommend that the USE_QT_GUI should be used as a way to allow a developer to use Qt as an option for both Windows and Linux. Qt is a cross platform toolkit and they the solvespace Qt port in implemented allows for solvespace to run in Qt mode in both Linux and Windows. I myself also like the original solvespace windows option since it is lighter and does not require any extra dll files and I do not think it should be replaced. But rather, giving a developer various options can be beneficial by allowing them to use Qt for both Windows and Linux if the developer is looking to use solvespace user interface into an existing Qt application.

I am not looking to be an active developer but rather thought I would contribute the work I have since it was based on the great work you guys have done so far if you see it can be of benefit.

Thank You

[ruevs]

I was not aware of the procedure to do the port on github. I use git internally at work but I have not used github for project development.

No problem :-) Here are some official GitHub documents on the topic of pull requests:

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request

[shingen75]

Hi @phkahler and @ruevs
I have forked the solvespace repository and have add the Qt support work to it. Sorry it took a while longer.. I have been busy with other projects at work. The repository name is solvespace_qt5. I have added the tinyxml lib to extlib. The port is src/platform guiqt.cpp and qglmainwindow.h. This has been tested on CentOS 7 and Windows 11.

[dgramop]

I see you have the fork uploaded on GitHub! When you're ready, you can make a pull request from your fork @shingen75:

Create a pull request

Select "compare across forks" so you can make a pull request from your repo into this repo

On the right side, select your copy of solvespace on GitHub, with the changes you made.

In the description, you should reference this issue (Just type in #1406) so that the issue is linked.

[WickedSmoke]

Hello, I've created a repository which fixes a few things things in the shingen75 repo. This has been rebased on your current master.

I'd like to replace the XML settings with QSettings, cleanup the whitespace, and fix a bug where some widget is being drawn in the menu.

Is there anything else that needs to be done to get the Qt port merged into your repo.?

[ruevs]

The QSettings based implementation to store the settings looks nicer than the tinyxml2 one. And it is more appropriate for a QT port that would need all the QT DLLs anyway. And it also seems pretty flexible.

From what I've just read it seems that the way you've implemented it it'll store the settings in NativeFormat. On Windows this would mean the registry and this is good (if they end up in the same spots in the Registry). On macOS it means property lists - also good. On Linux it seems to mean .conf files while the GTK port uses JSON.

Since the QT port will not be the "main" version on any of the platforms the above is not critical, but it would be nice if we at least tested/ensured that on macOS and Windows the settings are interchangeable/compatible between the native and QT versions.

So in my view to do:

• Test on Windows, make sure the settings storage is compatible with the native version.
• Test on macOS, make sure the settings storage is compatible with the native version.
• Configure the GitHub CI action to build the QT version on at least one of the three platforms so that it does not bit rot.

[WickedSmoke]

I'll open a pull request when I track down that errant menu widget, but as I don't use Mac, Windows, or GitHub CI someone else will have to look at the items you mention.

[BKLronin]

I could test on mac arm/intel and win10 but earliest in two months (ish).

[WickedSmoke]

The unknown widget turns out to be a scroll bar which is not fully implemented.

So there are two types of Windows, TOPLEVEL & TOOL, but do they actually both have a vertical scroll bar & a menu bar? Or does only TOOL need a scroll bar and only TOPLEVEL need the menus?