An update to S3AIR itself, including some changes.

[TiZ-HugLife]

These changes may be controversial, but I hope they and the rationale behind them are well received.

First, the easy part: Sonic 3 A.I.R. is updated to the latest release, v21.09.12.0. Right now the data is hosted on my repo, but if we gotta move it somewhere else, no big deal to me.

Next, the part right in the middle of easy and controversial. The reason I changed the runtime is mainly for convention; every game that handles all of its own rendering targets the FreeDesktop platform (or if not all of them, a vast majority). But we have a companion launcher here, and the FreeDesktop platform does not have GTK4, only GTK3.

So that takes me to the controversial part. I pushed the launcher backwards from Adwaita (and GTK4) to Handy (and GTK3). The reasons for this are a complex blend of practical and ideological, and I struggle to word them with consideration to the work that you have already done on packaging S3AIR. But you deserve for me to make a good faith effort, so here I go.

I don't think that you meant to target Adwaita as a means of making S3AIR's Flathub package be only for GNOME. I think you targeted Adwaita because you're comfortable with it as a graphical toolkit, and you wanted to make a launcher to improve the user experience of playing S3AIR. And honestly, it's a fantastic idea that I think was well-executed. It's why I bothered at all to push it back rather than just advocating for cutting it out.

Not only that, but I could tell that you had a pretty fantastic idea for theming the launcher. Normally, I strongly dislike it when apps that are meant to be part of my main workflow try to do their own thing theme-wise, but S3AIR is a game that renders everything itself, so the custom style is appropriate in that context; it's a prelude to a game that's going to draw everything itself anyways. Unfortunately, in the Adwaita version, the idea doesn't really shake out right on my environment.

That's XFCE with Picom as my compositor, and that's after trying to make GTK4 play nice with it and failing. I would hate to imagine what it would look like on KDE, or a standalone window manager. If this was meant to be for a custom repo only available to GNOME users, that would be fine, but Flathub serves every Linux desktop, so I felt that pushing the launcher back to GTK3 and Handy was important to make sure that the experience you made is better-polished on non-GNOME environments, even if it can't be perfect on all of them. And it's not that I think that it's invalid to have apps that are meant to be only for GNOME on Flathub, but this should not be one of those apps.

Anyways, that was really long-winded and I apologize for that, but I hope it explains why I bothered to push the launcher back to Handy and why I would like those changes to be merged here.

Thanks.

[flathubbot]

Started test build 60554

[flathubbot]

Build 60554 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/58413/org.sonic3air.Sonic3AIR.flatpakref

[alice-mkh]

I believe just updating libadwaita will fix that. That issue is the exact reason for the "controversial" change in libadwaita.

GTK3 would have the same exact issue if you have gtk-theme-name point to something non-existent (which is most probably what's happening here)

[TiZ-HugLife]

Updating libadwaita improves the situation only marginally:

The window remains improperly sized and GTK4 still forcibly adds extents to the window even when they're not added. Even still, Adwaita or not, this is a hard-coded theme, and the included style.css should act that way and hardcode all of its colors rather than counting on the theme to have the right ones.

This is what my branch looks like:

No double shadows or ghost extents, proper sizing that has everything visible. The animations still work, albeit with changes to the CSS for them to work on GTK3. For the most part, it looks the way that I believe Kekun intended for it to look; using GTK3 and Handy to do it means that look is more robustly implemented on non-GNOME DEs. Sonic 3 A.I.R. is not a GNOME app and it should not be one.

Yet more concerning about the libadwaita route is that in order to update it, you have to pull in libsass and sassc, which creates more bloat to make a launcher for a very lightweight game package. I believe that is yet more reason to just push the launcher back to GTK3+Handy and the FD.o runtime.

gtk-theme-name is set on my system by XFCE's Xsettings daemon; it's currently set to a theme that has a GTK3 version but not a GTK4 version, GTK3 Adwaita with a cyan accent. An invalid value for that setting isn't worth considering anyways because it would be problematic for all GTK3 apps on the system.

[alice-mkh]

The window remains improperly sized

It's improperly sized on both of your screenshots. The app uses a hardcoded height hand-tweaked for a specific font - and you have a different font. The only reason it fits on your second screenshot is because the Game Over label also has incorrect size.

If you wanna actually fix that, remove https://github.com/Kekun/sonic3air-launcher/blob/main/src/sonic3-window.ui#L7 and make sure the scrolled window propagates natural height. In both GTK4 and GTK3.

GTK4 still forcibly adds extents to the window even when they're not added

I assume you had filed a bug report for that in GTK, right?

The animations still work

Why wouldn't they. Except they now also consume CPU with large window size, e.g. on a HiDPI screen - nothing in GTK3 is hardware accelerated and animations like that are quire expensive.

Even still, Adwaita or not, this is a hard-coded theme, and the included style.css should act that way and hardcode all of its colors rather than counting on the theme to have the right ones.

Yet instead of doing that, or even checking why that happens, you ported it to GTK3.

Yet more concerning about the libadwaita route is that in order to update it, you have to pull in libsass and sassc, which creates more bloat to make a launcher for a very lightweight game package

Well, if you had taken the time to actually check why it depends on them, you'd find out that:

• libsass is a sassc dependency
• sassc is only needed at build time
• GTK4 also depends on sassc at build time, seems it's so concerning you hadn't even noticed it :)
• GTK3 and libhandy both depend on it too - the only difference is they ship precompiled files and you need sassc to regenerate them after editing them instead

An invalid value for that setting isn't worth considering anyways because it would be problematic for all GTK3 apps on the system.

Of course it would be. And since this is Flatpak, there's a good chance that your random theme is not in the sandbox and so the app cannot access it. And when that happens, you get Adwaita, and the light variant to boot, regardless of whether the app asked for a dark one. If it expects dark variant and cannot work with light - it breaks. And that's exactly what happened here. :)

[TiZ-HugLife]

It's improperly sized on both of your screenshots. The app uses a hardcoded height hand-tweaked for a specific font - and you have a different font. The only reason it fits on your second screenshot is because the Game Over label also has incorrect size.

If you wanna actually fix that, remove https://github.com/Kekun/sonic3air-launcher/blob/main/src/sonic3-window.ui#L7 and make sure the scrolled window propagates natural height. In both GTK4 and GTK3.

Good idea.

GTK4 still forcibly adds extents to the window even when they're not added

I assume you had filed a bug report for that in GTK, right?

I haven't filed a bug report yet. In so doing, I would have to convince them that they should care that an external compositor for X11 window managers is a use-case that they should bother supporting. GTK3 exhibits similar behavior on CSD windows by default; you remove it by using xdg-config/gtk-3.0/gtk.css to forcibly rip the shadows off of toplevel windows. I would have to convince them that this is something they should allow users to be able to do again. And even presuming I could succeed in that, the fix would need time to make it to a release before it would reach here.

I don't like the idea of sacrificing things we can do with certainty in the present for a future that may not happen.

The animations still work

Why wouldn't they. Except they now also consume CPU with large window size, e.g. on a HiDPI screen - nothing in GTK3 is hardware accelerated and animations like that are quire expensive.

That's a good point. That would be a good reason to just disable the animations on a GTK3 version.

Even still, Adwaita or not, this is a hard-coded theme, and the included style.css should act that way and hardcode all of its colors rather than counting on the theme to have the right ones.

Yet instead of doing that, or even checking why that happens, you ported it to GTK3.

Yes. Again, GTK3 fixes the issues right now and makes a more universally comfortable experience for everyone who uses Flathub.

Yet more concerning about the libadwaita route is that in order to update it, you have to pull in libsass and sassc, which creates more bloat to make a launcher for a very lightweight game package

Well, if you had taken the time to actually check why it depends on them, you'd find out that:

* libsass is a sassc dependency

* sassc is only needed at build time

* GTK4 also depends on sassc at build time, seems it's so concerning you hadn't even noticed it :)

* GTK3 and libhandy both depend on it too - the only difference is they ship precompiled files and you need sassc to regenerate them after editing them instead

Dude, I have a full-time job, and programming is a part-time hobby for me, among many other hobbies that give me way more happiness than the inverse happiness that this conversation is giving me right now. I don't have time to go checking why libraries are doing things that make my system less comfortable for me. You all want contributors, and that's what always gets trotted out when there are people dissatisfied with something. I am contributing with the time and the knowledge that I have.

An invalid value for that setting isn't worth considering anyways because it would be problematic for all GTK3 apps on the system.

Of course it would be. And since this is Flatpak, there's a good chance that your random theme is not in the sandbox and so the app cannot access it. And when that happens, you get Adwaita, and the light variant to boot, regardless of whether the app asked for a dark one. If it expects dark variant and cannot work with light - it breaks. And that's exactly what happened here. :)

My random theme is in the sandbox. I took care to expose it. I am a customizer, I took the necessary steps to ensure my customizations would be picked up.

I'm trying to be as kind as I can, but your plausibly deniable condescension is making it extremely difficult.

None of this should matter. Adwaita is for GNOME apps, and Sonic 3 A.I.R. is not a GNOME app.

[TiZ-HugLife]

Actually, now that I think about it, the only person who should have the final say in what S3AIR should or should not be in any given desktop environment or platform is @Eukaryot. What is your take on this? Is Sonic 3 A.I.R. a GNOME app, or a Linux app?

[Eukaryot]

Without too much knowledge about the details of this conversation - I'd say that S3AIR is a Linux app, not made for GNOME specifically. It runs on all desktops supported by SDL2.

[Kekun]

Maybe this escalated too much, let's all calm down a bit. I don't think moving back to GTK 3 is going to solve the issue: going back to a deprecating technology won't help. Moving to another UI toolkit like Qt won't help either, it's just going to move the issue.

I used GTK 4, Libadwaita, and the GNOME runtime because:

• I'm a GNOME dev.
• GTK is per se de-facto the Linux GUI toolkit as it's the only one that is bother largely used on Linux and that kinda supports only Linux.
• GTK 3 is old, GTK 4 is not just its future but its present.
• GNOME is the major DE developed with the de-facto Linux GUI toolkit.
• I am a coauthor of Libadwaita, the GNOME UI library.
• The GNOME runtime ships some deps I needed like the icon theme: I initially tried to use the FDO runtime but the close button icon was missing! It just wasn't usable at all.

I may absolutely be biased but I think that yes, targeting GNOME is the thing to do when targeting Linux as a whole.

That being said.

I don't want to hinder other desktops' users, we could have different launchers, but that's just not going to scale. And I don't think it's relevant for a window you're supposed to see less than a minute in your whole life. I tried to develop that launcher as a self-contained mini app that doesn't look like a GNOME app or anything else other than a Sonic app, any UI glitch you encounter is indeed a bug that should be fixed, but moving back to a 10 years old tech can't be the solution.

I see 2 solutions here:

• Fix the GTK 4 app now to make it even more robust, and use the FDO runtime as soon as possible, even if that implies bundling more deps.
• Have @Eukaryot implement the functionality directly into Sonic 3 AIR, which is IMO the best long-term solution, and the most portable too.

@HugLifeTiZ, @Eukaryot, what do you think? :)

[Kekun]

BTW, shitting on us on Reddit isn't exactly the best way to solve your issue. :)

[TiZ-HugLife]

BTW, shitting on us on Reddit isn't exactly the best way to solve your issue. :)

You can't say "hey let's cool it down" and then immediately take a shot like that. GNOME has developers in its fold being just as acerbic and explicitly exclusionary toward non-GNOME platforms. Besides, I didn't think others in the project cared about what people say on reddit, only about whether or not people are contributing. :)

GTK is per se de-facto the Linux GUI toolkit as it's the only one that is bother largely used on Linux and that kinda supports only Linux. / GTK 3 is old, GTK 4 is not just its future but its present

GTK4 won't be the present until it's used by cross-desktop apps, and Firefox is not migrating to it in the foreseeable future. Other desktops aren't migrating to it. The reasoning for this goes into context that isn't suitable for this conversation. But I feel that the statement "it is the present because we say it is" is not reflective of reality.

The GNOME runtime ships some deps I needed like the icon theme: I initially tried to use the FDO runtime but the close button icon was missing! It just wasn't usable at all.

Wouldn't that be an Adwaita bug? If proper use of Adwaita requires GNOME-specific elements to be present, then that just further proves my point that targeting Adwaita makes your app only for GNOME.

I may absolutely be biased but I think that yes, targeting GNOME is the thing to do when targeting Linux as a whole.

This does not bode well for the ability for us to come to any sort of consensus on this, and this stance erodes my trust in Flatpak as a technology and Flathub as a distribution platform.

Have @Eukaryot implement the functionality directly into Sonic 3 AIR, which is IMO the best long-term solution, and the most portable too.

I think that this is the best long-term solution, and one is sorta kinda there already.

However, if I try to run the native binary inside the Flatpak sandbox with the ROM renamed, it exits without any output. I think that may be an error case of sorts, because it can look into my Steam config and see that there is a library in a location that is not currently accessible. Because when I run the binary outside the Flatpak, it just goes and gets S3K from the correct location. If I hide that location, it pops up a rudimentary dialog that it will need to be added manually and to consult the Manual.

So the game does currently do something. It's not as nice as what the launcher does. If there was a non-GTK way to call the portal file-picker, a button could be added to that dialog for providing the ROM.

Fix the GTK 4 app now to make it even more robust, and use the FDO runtime as soon as possible, even if that implies bundling more deps.

Despite how I feel about GTK4's suitability for cross-desktop use, I don't think this is so bad. After all, if you want to make it cross-desktop suitable, you have to use it and you have to fix things that are broken. However, I think that is a medium-term thing. I think the more responsible thing to do would be to go ahead and roll back to GTK3 for now, then work on fixing everything that broke in GTK4 to make it work badly in non-GNOME environments, presuming GTK4's stewards want to fix those things instead of insisting that a "platform library" that doesn't exist right now for anyone but GNOME has to be used.

Here's another question. Does it have to be Adwaita? With how little we're doing in this app, I would imagine that the static content can be replicated with vanilla GTK4 widgets and extra styling. I'm even more amenable toward a GTK4 route if that route does not include Adwaita.

[TiZ-HugLife]

I'm going to close this issue with apologies for some specific things.

First, Sonic 3 AIR itself does need to be updated, and it wasn't exactly fair for me to bundle the update for S3AIR along with a complete overhaul to the included Adwaita launcher. I had thought that keeping it all together would have made things easier, but in so doing, I accidentally held the S3AIR update hostage to acceptance of my overhaul changes. I apologize for having done that. That said, I'm not really a fan of how the S3AIR upstream release and metadata are currently bound to the launcher, and would like to have a better way to do that. I will create an issue for discussing that.

I do want to apologize for having contributed to a combative discussion tone regarding the ideology of having the launcher be Adwaita. I have opened bug reports to the various components responsible for the aberrant graphical behavior with GTK4/Adwaita apps. Unfortunately, they didn't really go anywhere, but I am not sure that it is Adwaita's problem, or your problem, either. I have migrated from XFCE/Picom to Plasma, where Adwaita generally works fine.

I still don't know if using Adwaita for the launcher is appropriate. Sure, it's a great demo for Adwaita's hardware accelerated CSS styling and animation, and the fact that it uses a game-centric style means theming issues get sidestepped entirely, but like... is this really the right place to show that off? A simple shell script using Zenity, already in the FDO runtime, could very easily accomplish what this entire C program with additional dependencies does. While I don't want to hold the update to S3AIR hostage to accepatance of my changes, I also don't want S3AIR's data in general to be held hostage by acceptance of the custom launcher, either. These concerns should be separated regardless of whether we use the Adwaita launcher, the GTK3 launcher, or a simpler Zenity script launcher.

I'm going to go ahead and open those issues now and hopefully discussions will go better this time.