Linux Setup

Hello, dear Linux users!

The ABI incompatibility that we have encountered was the last straw that forced me to switch to Flatpak.

Here is the link to the Flatpak build with a detailed manual on installation:
https://pilgway.com/~sergyi/links-Linux.html

With help from Copilot, I have found and fixed a long-standing problem: the inability to run 3DCoat from the launcher using a Desktop file. After installing 3DCoat as Flatpak, you will see the 3DCoat icon in your Linux launcher.
This build can be unstable.
I see reports from Windows users complaining about the instability of 2026.01 in general. Please consider this build as a packaging test.

Regarding GTK2. A year ago, I ported the code to GTK3. Everything worked except one thing: 3DCoat’s internal modal dialogs, which it draws itself (not system modal dialogs), crashed the app. For more than a month, I investigated the problem without working on anything else. But because of the enormous size of the 3DCoat source code, I wasn’t able to determine the cause.
I reverted to the GTK2 code only because of those internal modal dialogs, and I notified the company that we should implement them differently. I have worked around the file dialog problem by building 3DCoat on Pop!_OS instead of Ubuntu.
The file dialog problem is another ABI incompatibility issue that Flatpak should now solve.

Some questions I have for you. As you know, I have developed the low-level foundation on which 3DCoat runs. That foundation isolates 3DCoat tools from the platform. To do that, I have rewritten each low-level function three times using different API on each platform: WinAPI on Windows, Cocoa on macOS, and GTK on Linux. That process is tedious because you do the same work three times. Moreover, you have to build the project source code three times with different compilers, which introduces optimization errors. In the case of Linux, you have to encounter ABI incompatibility between distributions. Given the complexity of this process, I was looking for an alternative.

Accidentally, in 2021, I learned about WebAssembly and fell in love with it. WebAssembly allows application developers to use a single API and to make a single build that runs everywhere. WebAssembly effectively solves the problem with updates, because users always run the latest uploaded build. I have ported the low-level foundation (let’s call it “engine”) to WebAssembly with deep modifications. You can see it here in action in my game:
https://underseagame.com
I developed this game in 2011 with an artist for iOS, but I have now ported it to my new WebAssembly engine.
What do you think about the idea of reimplementing some 3DCoat functionality on this new WebAssembly engine?
Please consider the real-world limitations of WebAssembly: single-threaded and 32-bit, whereas multithreading and 64-bit support are uneven and experimental. Obviously, the full 3DCoat source code is not portable to WebAssembly because it was not designed for it.
But some tools, some functions, could be.

How do you see the 3DCoat web tool? What essential functions should it have? Before raising this question in the company, I would like to hear your expert opinions.

Sergyi