Interesting. But if the app bundles GTK2 via snap or flatpak, it should work, right?

Most Linux distros don't allow bundling in their system package manager, to avoid security-critical dependencies going out of date. If smuxi doesn't care about this and only cares about distributing via flatpak, that's its choice. Historically it has cared though, meebey was (and still is) a Debian Developer.

Most Linux distros don't allow bundling in their system package manager, to avoid security-critical dependencies going out of date

I guess you're talking about .deb packaging here? I never referred to bundling gtk2 inside the deb package.

If smuxi doesn't care about this and only cares about distributing via flatpak, that's its choice

I'm not talking about choices here yet, I'm asking technical questions. In fact if you are a debian user yourself you could answer my technical question by doing a very simple test from your system, because I happen to be a developer of a GTK2 app myself which can be installed via the snap store. Can you download the snap package for app called "geewallet" and see if it works in the Debian OS version that is dropping GTK2? Because if that works, I can contribute a PR that creates a snap package for smuxi.

This issue is about the smuxi-frontend-gnome .deb package. As a Debian user and developer that is what I care about. I don't care about snap or flatpak.

Snap and flatpak are the best way to distribute GUI applications in Linux. IMNSHO deb/rpm packages should be used for only core parts of the distro. I'll help meebey setting this up in case he has troubles moving forward with Debian.

While I can understand that Linux distros don't want to keep multiple versions of libraries with the same functionality (gtk2/3) around, it is a bit questionable to just drop the GNOME frontend and render the software useless.

The install base of GTK2 is declining but way still too significant to call GTK2 legacy or obsolete (it is the percentage of all Debian installs that submitted data to popcon):

Upstream wise the situation looks very different. GTK+ 2.x had their last release with 2.24.33 about 2 years ago, so it appears to be no longer maintained:
https://gitlab.gnome.org/GNOME/gtk/-/commits/gtk-2-24/

Kind of funny timing that smuxi-frontend-gnome is removed from Debian while I pushed it to NixOS last night:
NixOS/nixpkgs#249831

Looking at the Debian bug it appears Debian is happy to remove more packages based on low popularity. Not sure when or if I will find the time to move Smuxi over to GTK#3. Many show stoppers are resolved (like dropping libglade and use GtkBuilder) and the last piece is re-basing the gtk3 branch of Smuxi and get a GTK#3 release out somehow...

I can see why snap/flatpak is useful for some cases in particular if the team is active and on top of their security patches. Historically this has not been the case for small FOSS projects which is why the distros have these policies.

I think the fact that GTK 2 hasn't been maintained for over 2 years weighs more than the fact that 50% of Debian (popcon) users still have it installed - likely not intentionally or consciously. Personally I just think of it as a proxy for "is the project actively maintained or not".

The person that dropped smuxi-frontend-gnome is just one Debian Developer and you can contest his decision and re-upload it back if you wish. The fact that you released 1.2.1 in April is encouraging, although I can understand you don't want to make any promises for when GTK 3 will actually be done. On the other hand 1.2.1 isn't in Debian today, does that mean you're no longer actively interested in keeping the Debian package up-to-date?

edit: of course there's a time window for re-uploading it back, you have until when they actually remove GTK 2. It's currently still in the archive but I'm not sure for how long.

@infinity0 I agree that using unmaintained libraries is bad, so that event was decided upstream and not downstream. Downstreams that leave unmaintained software around may lead to security issues...
Smuxi should move to GTK+3, it is time.

The official gtk-sharp repo stalled with 2.99.3, released in 2014, so we should consider other GTK# forks... (in theory they should be mostly API compatible as they try to expose the same underlying APIs of GTK).

@knocte as long as Smuxi uses a native UI toolkit like GTK I don't think it worth the afford to make it work with snap/flatpack in my opinion (given it could use gtk3 without a "container" around it). Software is actually no longer native/consistent these days and simply relies on cross-platform web interfaces. So beyond gtk3, Smuxi should get a web frontend with MAUI that would also unlock mobile support...

https://github.com/GtkSharp/GtkSharp lists GTK+ 3.22 as a .NET Standard 2.0 target and is being actively developed. It's a fork of mono's gtksharp. I'm not sure of the best way to include the dependency. Nuget is the obvious way, but it's not necessarily the best for packaging. Guidance would be helpful.

Stetic isn't available for GTK+ 3 (and Monodevelop hasn't been developed in the past two years), but that's probably not going to be a giant problem for an immediate port. Long term, migrating to Glade and Gtk.Builder is preferred.

Debian has also removed gtk-sharp2 on other grounds, while gtk+2 is still around.

TL;DR: gtk-sharp2 includes API definitions (XML files called *.raw) that preceded Gir for the GTK# binding code to be generated. The input of the API definitions were "scraped" from GTK+'s C header files in the past. Now this is not free enough in some people eyes because you can't reproduce this scraping... A bit esoteric in my eyes but I understand the rational.

Following this logic: how about code with the actual API implementation in C (not the headers/prototypes), when the human who wrote the code dies, it means we lost the capability to reproduce that code (the input process to the code file is gone). Should we stop using that code and remove it from the Debian archive after his death?

So the problem is not just porting Smuxi to GTK+3, but also to a language binding that does not violate the new standard for free software in Debian archives. I have updated the title of this issue to reflect that.

I wonder if any of the new C# bindings do it in a Debian DFSG-compliant way as in: not containing generated GTK+ API definition files as part of the source tarball.