USER FORUM
(you are viewing a thread; or go back to list of threads)
QT GUI (by James Marine)
Is that possible to change the current GUI to QT-based? It seems the current gui is a bit old-styled. i am wondering whether it is possible and how much efforts will be needed to port the GUI to QT.
(no subject) (by Paul)
The look is not due to the GUI toolkit. SolveSpace uses native windows and MacOS gui on those platforms and GTK on Linux. It looks mostly the same on all of them.
The GUI toolkit is only used for window creation, menus, and popups. Toolbars and the text window contents are all rendered with OpenGL on all platforms.
The main issues with the gui are lack of localization in the text window, and no ability to resize the text and icons. Changing toolkits won't fix those problems.
The GUI toolkit is only used for window creation, menus, and popups. Toolbars and the text window contents are all rendered with OpenGL on all platforms.
The main issues with the gui are lack of localization in the text window, and no ability to resize the text and icons. Changing toolkits won't fix those problems.
(no subject) (by Jack Lang)
So Qt seems to solve all the problems:
- Only one toolkit to maintain for the 3 differents platorms (windows, linux and macos)
- You keep your 3D window the same
- Use Qt internationalisation tool for localisation
- Only one toolkit to maintain for the 3 differents platorms (windows, linux and macos)
- You keep your 3D window the same
- Use Qt internationalisation tool for localisation
(no subject) (by Paul)
GTK could also serve as a cross-platform toolkit, and is already one of the implementations. It's also lighter weight.
One of the issues is complicating the build system by adding a big dependency on Windows and MacOS. We don't currently build or ship any GUI toolkit code.
That said, if someone wanted to submit a QT version that solves some of the issues that would worth consideration.
One of the issues is complicating the build system by adding a big dependency on Windows and MacOS. We don't currently build or ship any GUI toolkit code.
That said, if someone wanted to submit a QT version that solves some of the issues that would worth consideration.
(no subject) (by Jack Lang)
Can i ask you why GTK is not used across all platform ?
I understand that using Qt is not straightforward, moreover there is a lot of debate as Qt is becoming less and less "friendly" with open source community since Qt6 release.
Have you considered the use of other lightweight toolkit like LmGui ?
I may try to write a prototype if i find some time...
I understand that using Qt is not straightforward, moreover there is a lot of debate as Qt is becoming less and less "friendly" with open source community since Qt6 release.
Have you considered the use of other lightweight toolkit like LmGui ?
I may try to write a prototype if i find some time...
(no subject) (by Weston)
You might find these issues relevant:
https://github.com/solvespace/...ues/263#issuecomment-315380580
https://github.com/solvespace/...ues/401#issuecomment-491042005
https://github.com/solvespace/...ues/263#issuecomment-315380580
https://github.com/solvespace/...ues/401#issuecomment-491042005
(no subject) (by Paul)
GTK 4 would probably be the best choice for cross platform GUI, but that would complicate the build process. We do not currently compile any GUI code as part of the build process on any platform.
Previous maintainer had a lengthy discussion about ImGui here:
https://github.com/solvespace/solvespace/issues/263
I completely agree. People keep suggesting a change of GUI toolkit for misguided reasons. It doesn't solve a real problem and would add complexity.
Previous maintainer had a lengthy discussion about ImGui here:
https://github.com/solvespace/solvespace/issues/263
I completely agree. People keep suggesting a change of GUI toolkit for misguided reasons. It doesn't solve a real problem and would add complexity.
(no subject) (by Jack Lang)
I saw those discussions and i totally agree with "Traverseda".
If people keep asking a better GUI like you said, then i don't think it's for misguided reasons, but a real demand
But i can understand it s a lot of work also...
If people keep asking a better GUI like you said, then i don't think it's for misguided reasons, but a real demand
But i can understand it s a lot of work also...
(no subject) (by Weston)
I've read all the issues related to GUI toolkit changes and it seems to me that many people think that a GUI toolkit change will somehow make the project much easier to contribute to.
This comment and down explains it pretty well:
https://github.com/solvespace/...sues/17#issuecomment-319724608
This comment and down explains it pretty well:
https://github.com/solvespace/...sues/17#issuecomment-319724608
(no subject) (by Weston)
(no subject) (by Paul)
>> it seems to me that many people think that a GUI toolkit change will somehow make the project much easier to contribute to.
I wonder if they think new features are a matter of adding a GUI widget with a little code to call some APIs in the geometry kernel. That would definitely not be correct. It could become more like that, but it's not today.
The text window code is IMHO ugly, but that needs to be improved with or without changing GUI.
I have yet to see anyone say "here is a feature and this is how standard GUI widgets would be used to implement it". One thing that people like about SolveSpace is the direct interaction with the sketch - the lack of widgets.
I would really like suggestions on the proposal for a hole tool or group:
https://github.com/solvespace/solvespace/issues/955
That is a very complex thing to do, and I'd like to get it right. It's also the only time I've thought about doing complex stuff in the GUI like maybe showing a dimensioned profile of a hole - which no toolkit has a widget for BTW.
I wonder if they think new features are a matter of adding a GUI widget with a little code to call some APIs in the geometry kernel. That would definitely not be correct. It could become more like that, but it's not today.
The text window code is IMHO ugly, but that needs to be improved with or without changing GUI.
I have yet to see anyone say "here is a feature and this is how standard GUI widgets would be used to implement it". One thing that people like about SolveSpace is the direct interaction with the sketch - the lack of widgets.
I would really like suggestions on the proposal for a hole tool or group:
https://github.com/solvespace/solvespace/issues/955
That is a very complex thing to do, and I'd like to get it right. It's also the only time I've thought about doing complex stuff in the GUI like maybe showing a dimensioned profile of a hole - which no toolkit has a widget for BTW.
(no subject) (by ruevs)
Changing GUI toolkits solves none of the problems that SolveSpace currently has. In my opinion being "old-styled" (whatever that means) is not a problem. This is a CAD tool - not a smartphone chat application.
On the topic of QT (to add more "noise" to the discussion) - just changing to QT will not change the way the GUI looks - read through the issues people already linked to understand.
And here is the issue regarding QT specifically https://github.com/solvespace/solvespace/issues/401 .
On the topic of QT (to add more "noise" to the discussion) - just changing to QT will not change the way the GUI looks - read through the issues people already linked to understand.
And here is the issue regarding QT specifically https://github.com/solvespace/solvespace/issues/401 .
(no subject) (by James Marine)
Personally i am in favor of QT 5 and hope could personally find some time to do this?
It would be appreciated if anyone familiar with solvespace could kindly provide some estimations of efforts need for this work, for examples, days? or months?
What is the major area that need to be changed?
It would be appreciated if anyone familiar with solvespace could kindly provide some estimations of efforts need for this work, for examples, days? or months?
What is the major area that need to be changed?
(no subject) (by Paul)
If you really want, look in the platform folder here:
https://github.com/solvespace/solvespace/tree/master/src/platform
There is a single file (plus whatever CMake config stuff) for each platform. The guigtk.cpp file for example is about 1500+ lines of code. You'll need to implement the equivalent for QT in a new file probably called guiqt.cpp
Nothing outside that folder and the build configuration should need to be changed to build on linux. Oh, and if you want to do this, please do Linux first and dynamic link against the system installed QT. We don't build any GUI toolkit code with SolveSpace for any OS.
https://github.com/solvespace/solvespace/tree/master/src/platform
There is a single file (plus whatever CMake config stuff) for each platform. The guigtk.cpp file for example is about 1500+ lines of code. You'll need to implement the equivalent for QT in a new file probably called guiqt.cpp
Nothing outside that folder and the build configuration should need to be changed to build on linux. Oh, and if you want to do this, please do Linux first and dynamic link against the system installed QT. We don't build any GUI toolkit code with SolveSpace for any OS.
(no subject) (by James Marine)
Is there any specific reasons that why linux should be done first? The major platform I am using is Windows. I am wondering whehter it is possible to get a windows QT version first
(no subject) (by Paul)
The reason I said that is because I will not accept patches to use QT on Windows.
There is zero value in that, and we would have to use an installer to bundle QT with SolveSpace and for what? We already have a native Windows GUI.
I will not adopt QT as a cross-platform toolkit for solvespace. It's open source, so you are free to maintain something like that yourself if you want.
There is zero value in that, and we would have to use an installer to bundle QT with SolveSpace and for what? We already have a native Windows GUI.
I will not adopt QT as a cross-platform toolkit for solvespace. It's open source, so you are free to maintain something like that yourself if you want.
(no subject) (by Thomas Herrmann)
I like the look a lot I have to say. Minimal and straight forward. No need for any gui changes and I'm usally a fan of beautiful made ui designs with bells and whistles.
(no subject) (by Vin)
Honestly, the biggest thing would be if a better font could be used in the text window. A nice proportional font would be a smoother read than the fixed-width one that's there now. (Blender's UI uses a proportional font, and I think their UI is all OGL rendered, so it should be possible ... but I'm not an opengl programmer, unfortunately.)
BUT
The UI is not a big issue for me. The look reminds me a lot of when I used to use Wings3d for poly modeling. You spend more time creating content than worrying about the UI.
I'd much rather see effort spent on fillets or chamfers than any time being thrown at using another UI toolkit just for the fun of it.
BUT
The UI is not a big issue for me. The look reminds me a lot of when I used to use Wings3d for poly modeling. You spend more time creating content than worrying about the UI.
I'd much rather see effort spent on fillets or chamfers than any time being thrown at using another UI toolkit just for the fun of it.
(no subject) (by Paul)
The text window font is GNU Unifont. It's a bitmap font that contains every glyph in the (unicode) multilingual plane. That's cool but it's not resizable.
Solvespace needs a resizable monospaced font and a new way to render it, preferably with OpenGL.
Solvespace needs a resizable monospaced font and a new way to render it, preferably with OpenGL.
(no subject) (by Dave)
The UI is no issue for me either.
I'd prefer time be spent on new features and performance improvements.
I'd prefer time be spent on new features and performance improvements.
Post a reply to this comment: