How to use

[darkdragon-001]

I need help packaging Pinta 1.8 which replace org.freedesktop.Sdk.Extension.mono6 with org.freedesktop.Sdk.Extension.dotnet5 and GTK2 with GTK3. Unfortunately, the .NET SDK is no longer installed in /app/bin and /app/lib but instead in /app/dotnet/bin and /app/dotnet/lib which is not added to $PATH automatically. I tried using custom build-commands and command, but running the app aborts with the following error: /app/bin/pinta: line 5: /usr/lib/sdk/dotnet5/bin/dotnet: No such file or directory.

• How should one use the enable.sh and install.sh scripts correctly?
• Is there a way to avoid allowing network at build time using dotnet modules?

See my experiments in com.github.PintaProject.Pinta branch gtk3-v1.8.

Any help appreciated. @barthalion @scx

[scx]

Have you even tried to build Pinta using dotnet, e.g. on the host? In my opinion, it is not that simple. You should know that there are actually two Gtk+ bindings for .NET:

• gtk-sharp for .NET Framework (and Mono)
• GtkSharp for .NET Standard (and .NET)

The first one supports Gtk+2. There is also an unstable branch with Gtk+3 support, but its developments has been practically stalled long time ago. This Gtk+3 variant also tends to break with new releases of Mono. GtkSharp is actually a C# wrapper for Gtk+3 and its related components. However, it is not compatible with gtk-sharp. It is like PyGTK vs PyGObject (or PyQt vs PySide, although it is not exactly the same thing). They are not compatible, even if there are some similarities (BTW: a lot of things have been broken during PyGTK → PyGObject transition in OCRFeeder, like spell checking or scanning documents, so you must be very careful with such experiments). Besides, if I good remember, Pinta was written for Gtk+2 in mind. This is similar to the situation with wxWidgets programs, like wxMaxima or Aegisub. Even if you build them against Gtk+3 (wxGTK3), it won't work very well. Actually, I will show you some screenshots from wxMaxima (just take a look at the wxSpinCtrl controls).

wxMaxima Gtk+2:

wxMaxima Gtk+3:

There are similar issues with Gtk+3 in Aegisub (labels, edit boxes, etc.).

Aegisub Gtk+2:

Aegisub Gtk+3:

I know that the maintainers of leading Linux distributions are tending more and more to choose the Gtk+3 variants, but this is mainly a cargo cult. Besides, they often refuse to build Aegisub against wxWidgets 3.1, because it is an "unstable" branch, completely ignoring the fact that this program is just broken when it is compiled against wxWidgets 3.0. I can only remember a single Linux distribution that provided Aegisub built against wxWidgets 3.1, but they used a broken version of it (at that time it was the latest release), which caused the application to crash at startup. Anyway, although Gtk+3 is modern toolkit (it has support for transparency, Wayland, HiDPI, modern WebKit, xdg portals, etc.), it is not always possible to take advantage of these benefits. For example, you can't just use the native file selector from xdg desktop portal to open subtitles, because in this case the program won't be able to load additional files (e.g. the corresponding video file or waveform). Moreover, Aegisub can't work with native Wayland at all, because it relies on wxGLCanvas, which doesn't support it yet. Aegisub doesn't use any web component, so we don't have to worry about an unpatched WebKitGtk. Moreover, both Aegisub and wxGTK3 use hardcoded values in many places, so they are not in complete harmony with HiDPI. Of course, you can fix many things in the program, but then you will hit issues like this one:

Aegisub without HiDPI patches:

Aegisub with HiDPI patches:

As you can see, sometimes it is better to stick with the legacy toolkit.

Anyway, even if you somehow build Pinta against the Gtk+3 version of mono/gtk-sharp, you probably won't be able to use .NET/GtkSharp with the current stable release of Pinta. There was an effort to build MonoDevelop against GtkSharp and dotnet, but the last time I checked this, it didn't contain working code. Usually it takes months or even years to provide good enough quality. Why am I saying this? Because you may encounter similar problems with Pinta. In my opinion, this is a job for the vendor developer, not maintainers. As long as you're not going to fork Pinta (Pinta.NET?), you should just let it go. I believe that a stable version of Pinta for .NET/GtkSharp will come out in the future, but it's not that time yet. And remember, Flathub focuses on stable releases, not experimental builds.

[darkdragon-001]

@scx Thanks a lot for your detailed explanations! This pretty much covers my experience with my failed attempts to use GTKSharp3 with Mono in https://github.com/flathub/com.github.PintaProject.Pinta/pull/14.

However in this case, I am using Pinta's branch gtk3-v2 and following their Linux build instructions in the README. Build process with flatpak-builder works in my mentioned experiments! Building and running locally works like a charm (just copying the commands from the README)! After closure of Pinta#1890999, I am quite confident that this will be the base for the upcoming stable release 1.8.

So this request is specifically about usage of org.freedesktop.Sdk.Extension.dotnet5 with my tests. As mentioned before, build process works. So it probably is just a matter of setting the right environment variables and maybe use flatpak-builder more efficiently.

[archive11]

Enable.sh should add dotnet to path but it's broken. You can omit use of this script by using dotnet with full path: /usr/lib/sdk/dotnet5/bin/dotnet publish....

Install.sh copies dotnet runtime to /app. It's needed to run app in user enviroment. However package is quite large then. Instead I prefer to use dotnet publish --self-contained true -p:PublishTrimmed=True --runtime runtime-id. You look for this method here. Sources.json file can be created using Flatpak .NET Generator. Additionally you have to add this for output file:

    {
        "type": "file",
        "url": "https://api.nuget.org/v3-flatcontainer/microsoft.aspnetcore.app.runtime.linux-arm64/5.0.1/microsoft.aspnetcore.app.runtime.linux-arm64.5.0.1.nupkg",
        "sha512": "270f3ff83525a69e4e5d0e6df0ad90ba924dc8b61cf263b647fa8a8684fff92f223cb8aa020e3fe1a69b6a952ce152cdb901a87ef02b692fb401dee197ccf847",
        "dest": "nuget-sources",
        "dest-filename": "microsoft.aspnetcore.app.runtime.linux-arm64.5.0.1.nupkg"
    },
    {
        "type": "file",
        "url": "https://api.nuget.org/v3-flatcontainer/microsoft.aspnetcore.app.runtime.linux-x64/5.0.1/microsoft.aspnetcore.app.runtime.linux-x64.5.0.1.nupkg",
        "sha512": "1596cc7e60435327f25a29ee5bf66e90230d7610561d6ede244d62df0fba6fd0c2d1cc818fdc59dcaaa828a392267ce106f80ec17e1ed2330ef2f58f700b3ec9",
        "dest": "nuget-sources",
        "dest-filename": "microsoft.aspnetcore.app.runtime.linux-x64.5.0.1.nupkg"
    },
    {
        "type": "file",
        "url": "https://api.nuget.org/v3-flatcontainer/microsoft.aspnetcore.app.runtime.linux-arm/5.0.1/microsoft.aspnetcore.app.runtime.linux-arm.5.0.1.nupkg",
        "sha512": "a9e97d01703c169e571293982139fab6e9053bde3192f0e253376186a27bce69016fb188923942900946b51c739fb50bd8897f5f732cc9c5050844d7502ff146",
        "dest": "nuget-sources",
        "dest-filename": "microsoft.aspnetcore.app.runtime.linux-arm.5.0.1.nupkg"
    },

These packages are needed by the build process for a specific runtime.

About the network. It's required for downloading nuget packages. You can download them manually but I think it misses the point.

[archive11]

Readme added in 898189e

[darkdragon-001]

@tofudd Thanks a lot for your explanation and the great README. I will definitly have a closer look in the next days!

Install.sh copies dotnet runtime to /app. It's needed to run app in user enviroment.

It currently copies to /app/dotnet/lib which is not in $PATH. Shouldn't it copy to /app/lib like Mono 5.x / Mono 6.x? This way it would also work with launch scripts provided by the projects etc...

[archive11]

Thank you for this suggestion. Enable script finally works!

[darkdragon-001]

I just noted the following snipped, which might be used instead of enable.sh:

build-options:
  append-path: /usr/lib/sdk/dotnet5/bin
  append-ld-library-path: /usr/lib/sdk/dotnet5/lib
  env:
    PKG_CONFIG_PATH: /app/lib/pkgconfig:/app/share/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig:/usr/lib/sdk/dotnet5/lib/pkgconfig

[archive11]

Good to know. This way is definitely more elegant.