Migrate to GTK4 on Linux

[phkahler]

System information

• SolveSpace version: Latest GTK4 branch
• Operating system: Linux

Expected behavior

The GTK4 branch should build and work properly.

Actual behavior

The GTK4 branch does not build.

Additional information

The CMake stuff on the branch has been tweaked to use GTK4 and C++17 as required. The file guigtk.cpp has had includes commented out and new ones put in. It's at the point where compiler errors are due to API changes in GTK4. Theoretically all the required changes should be in platform/guigtk4.cpp which was copied from the still existing guigtk.cpp.

A migration checklist is available here: #853

Solvespace uses very little toolkit on any platform. GTK is used for window creation, menus, popup dialogs, and the file chooser. Most of the code for menus and events is completely broken due to the API changes. I don't do much GUI work ever, so this is really a call for someone with more experience to jump in.

BTW After getting it to build and work properly I'd like the GTK4 version to be single window but that's something for later....

[BKLronin]

If I might add some thoughts,

Would it be a good idea to have a python based UI with Pyside6 that uses the Solvespace library under the hood? This would simplify the cross paltform UI and it would be easier to add macro like features or new operations from connected existing ones and small plugins that sends jobs to Kiri:moto and Octoprint etc.

I see KDE as the most complete Linux platform currently and had more problems with gtk in the past.

I do like custom and independent solutions but I also heard that the current system has to be adjusted to each OS quite a bit.

[phkahler]

Would it be a good idea to have a python based UI with Pyside6 that uses the Solvespace library under the hood?

Unfortunately the "library" only provides access to the geometric constraint solver, not other major parts of the application. I do think we should move to a cross-platform toolkit, but my preference for that is GTK.

[BKLronin]

Hmm, I see.

Would it be technically possible to "libify" the complete sourcecode directly with bindings?

[phkahler]

Would it be technically possible to "libify" the complete sourcecode directly with bindings?

That's an interesting question and I'm not "software achitect" enough to know the answer. My guess is that a lot of refactoring would be necessary first. Have you looked at solvespace-cli? It's not real comprehensive, but it can be useful for a few things. Might adding some capability there cover what you want?

[BKLronin]

The idea would be to have the existing solvespace as "kernel" and python on top handling the gui stuff with gtk or pyside so that the (hard)core guys can focus on the nasty stuff while another team can handle the user experience. This might unload the engine room and enable externals to jump right in faster. That might enable implementing more external features like the mentioned macros and other external connections easier cause python is more of a "glue".

[phkahler]

The idea would be to have the existing solvespace as "kernel" and python on top handling the gui stuff with gtk or pyside so that the (hard)core guys can focus on the nasty stuff while another team can handle the user experience.

That sounds a lot like FreeCAD which already exists so I honestly don't see the point. This is also getting way off track from the title of this issue.

[BKLronin]

Yes it does but it would be something totally different. I like the idea. EDIT: I like the current gui a lot, thats not the point.

Sorry this thread just induced the thought.

[phkahler]

I'm not much of a GTK developer, but after messing around with it quite a bit my conclusion is that it may be easier to do a fresh GTK4 implementation from scratch, rather than trying to modify the existing GTK3 code.

This would be a good opportunity for someone who really wants to get in to solvespace development longer term.

My hope was to eventually use GTK4 on all platforms and use more of the toolkit. Things like a proper tree view, scalable fonts, maybe SVG icons. But I've now come to question the direction of GTK. It still seems like the best option in principle if not in practice.

[BKLronin]

I' m interested in this,realietically somewhat next year.

Problem is that my own stuff is in Python and Pyside and I dont want to mix sruff that much.

However I might need to switch to cpp at some point and gtk looks nice.

Other than that I might be of use when making svg or pixel art graphics and logos etc down to gui concepts in glade maybe.

[ofrzeta]

Howdy, where's the GTK 4 branch?

[phkahler]

Howdy, where's the GTK 4 branch?

@ofrzeta Looks like I deleted it? I have a GTK4 branch on my fork. You might use the first 1 or 2 commits from that. There are 4 commits but the last ones I think are failed and not useful. Feel free to have a look.

[xerio123]

ok i will put time to help going gtk4 can i have sometime to see how i need to put effort ?

[xerio123]

a meet or something

[phkahler]

@xerio123 So my personal fork has a gtk4 branch. I think only the first commit on that branch is of any value. It changes some build stuff, checking GTK version and bumping the C++ requirement to C++17, and it makes a file "guigtk4.cpp" which is just a copy of the existing guigtk.cpp for GTK3. That's a good start.

But in later efforts to comment out stuff to get it to build, I ended up commenting SO MUCH CODE that it would really be impossible to get it to compile and then incrementally switch functionality over to the new APIs. So I don't really recommend using any of the gtk3 code as a starting point.

I would suggest studying the stuff in platform/gui.h as I think the job consists of implementing the functions declared in that header file.

you can also study the 3 existing gui implementations. Take note that things in platform.cpp already have fileIO and path implementation for the different OSes, and that should all be fine to stay the same, as GTK4 is still a "linux version". But don't be surprised if file dialogs work differently with GTK4. Solvespace uses the interface defined in that header though, so the goal is to get those functions implemented the way Solvespace wants them to work by using GTK4 equivalents under the hood in guigtk4.cpp.

If starting from scratch I might just use a mostly empty guigtk4.cpp and add stub functions that do nothing or return simple constant values until it compiles. Then implement the window creation fuctions. Then get the menus to populate via those functions. Menus are defined in the application code and realized via functions in the patform abstraction layer, so you don't get to (need to?) define them in a GUI builder or anything like that. Then on to rendering, and finally input events.

There is also an open issue to merge a QT version that someone made over in #1406 so maybe @shingen75 could comment on what it takes to do a new port, since he is the only one around who has done it.

[ruevs]

you can also study the 3 existing gui implementations.

Four; if one counts the non-gui implementation in https://github.com/solvespace/solvespace/blob/master/src/platform/guinone.cpp that is used for the command line version. It may also be a more convenient "empty" starting point - depending on ones programming style and preferences.

[shingen75]

Hi,
I am interested in porting solvespace to GTK4 but I would rather use gtkmm4 which is the C++ wrapper for GTK4. From the look at the API, it seems to be very close to Qt in design which would make it easier for me to port the code. I have interest in evaluating gtkmm4 and I think for me, porting solvespace would be a good project to evaluate it.
If this is acceptable, then I would happy to give it a try.. Let me know
Here is a link to the programming with gtkmm4 available online for reference.
https://gnome.pages.gitlab.gnome.org/gtkmm-documentation/

[ruevs]

The current GTK3 version uses gtkmm, so of course it is acceptable.
https://github.com/solvespace/solvespace/blob/master/src/platform/guigtk.cpp