Building Yad from a github action script

[AtomHare]

This draft allows building the latest version of Yad (13.0) from a GitHub action using a simple workflow dispatch and making a release for it. Marking it as a draft since it needs some testing.

I will make a force push to have it in a single commit, you can try the created yad appimage here https://github.com/AtomHare/steamtinkerlaunch-tweaks/releases

Related to sonic2kk/steamtinkerlaunch#859

[sonic2kk]

See also:

• Misc: Bump Yad AppImage to use new release steamtinkerlaunch#1077 (comment)
• Bump Yad to a new release steamtinkerlaunch#1060 (comment)

My concern with having CI to do this was really that it would be a lot of work to implement compared to how much benefit it would provide, since we probably won't be doing this again for another 2 years. If you had commented on that issue I would've put up the same resistance, but you've gone ahead and implemented it, so assuming testing on my end goes well, I don't have a reason to say no 😄

I also wanted to have documentation for how to build a newer Yad AppImage manually and I sill do so I'll look into that after this PR (using the easy-builder project).

I just have a couple of questions:

1. Does ubuntu-latest target the latest LTS? I think that's the most common to build against and most in line with the AppImage ethos. If it doesn't target the latest LTS, do you have any thoughts on whether it should/shouldn't? For example users running on an older Ubuntu version may have trouble (observed a little bit with the ProtonUp-Qt project bumping the base AppImage build target), and the AppImage's 2nd most common usage is on Debian-based distros (1st being SteamOS)
2. It probably does and I'll test myself, but in principle, this should have the same portability as the current 10.XX AppImage, right? The question above of the base target aside, this should still work on an up-to-date Arch, Ubuntu, Mint, SteamOS (based on a custom Arch snapshot), Fedora?
3. Filesize looks reasonable for this too. Just out of curiosity is there any way to reduce it or strip anything out? Probably not and that's absolutely not your job here, it's just because we're here and you seem more knowledgeable than me that I wanted to ask :-) "no" or "I don't know" is fine, there's no pressure to do this.
4. We'll be running this so infrequently that it really doesn't matter but, will this use GitHub Actions minutes or does this still fall within the free minutes criteria?

I think having a CI job here that we can kick off whenever we need a new Yad AppImage is fine, you've gone to lengths to implement it and it looks reasonable from skimming on my phone.

Thanks a lot for your work here!

[AtomHare]

1. Does ubuntu-latest target the latest LTS? I think that's the most common to build against and most in line with the AppImage ethos. If it doesn't target the latest LTS, do you have any thoughts on whether it should/shouldn't? For example users running on an older Ubuntu version may have trouble (observed a little bit with the ProtonUp-Qt project bumping the base AppImage build target), and the AppImage's 2nd most common usage is on Debian-based distros (1st being SteamOS)

According to the runner-images repo, it should target the latest LTS verified by the GitHub team. Currently, ubuntu-latest = ubuntu-22.04. To avoid any potential issue with GLIBC on conservative distros it might be wise to stay on ubuntu-22.04 in order to make it work everywhere.

2. It probably does and I'll test myself, but in principle, this should have the same portability as the current 10.XX AppImage, right? The question above of the base target aside, this should still work on an up-to-date Arch, Ubuntu, Mint, SteamOS (based on a custom Arch snapshot), Fedora?

I'm not very familiar with AppImage building as a whole, but it should work everywhere as long as the GLIBC version of the OS it's ran on isn't too old.

3. Filesize looks reasonable for this too. Just out of curiosity is there any way to reduce it or strip anything out? Probably not and that's absolutely not your job here, it's just because we're here and you seem more knowledgeable than me that I wanted to ask :-) "no" or "I don't know" is fine, there's no pressure to do this.

The size comes from WebKitgtk, I don't know if it's needed or not. I included it because the previous release of this lib contained it. Without WebKitgtk the build size is around 10~ MB and with it around 70~ MB.

4. We'll be running this so infrequently that it really doesn't matter but, will this use GitHub Actions minutes or does this still fall within the free minutes criteria?

Since it's a public repository it falls within the free minutes criteria, see https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions#about-billing-for-github-actions.

---

Note: This github action uses the exact sames commands as easy-builder the only difference is debian vs ubuntu. Tecnically the GitHub action yaml file could be read as is and commands could nearly be pasted on an Ubuntu desktop to make the Appimage.

I'll edit the PR with a single commit and hardcode ubuntu-22.04. Then I'll mark it as ready for review !

[sonic2kk]

Thank you!

I'm not very familiar with AppImage building as a whole, but it should work everywhere as long as the GLIBC version of the OS it's ran on isn't too old.

Thanks, that's kinda what I expected (iirc this is the problem I ran into into with sonic2kk/steamtinkerlaunch#1077).

Pinning to 22.04 sounds reasonable.

Note: This github action uses the exact sames commands as easy-builder the only difference is debian vs ubuntu. Tecnically the GitHub action yaml file could be read as is and commands could nearly be pasted on an Ubuntu desktop to make the Appimage.

That makes sense now that you've said it. easy-builder I think has the option to use Docker to make it more distro-agnostic but Docker can be a headache, it's probably easier to spin up an Ubuntu VM in Boxes and as you said just run the commands from the Actions yaml.

---

I'll take a look when this PR is ready for review but I need to double-check the STL codebase. The name that the AppImage release uses might need to change, I think the current naming has a hash and I vaguely remember the name being "important" in some way.

I absolutely should've mentioned this in my initial comment but I entirely forgot and I apologise for that. So once I double-check I'll let you know but the release name might need to be adjusted, or the codebase if that's going to end up being an easier path.

Thanks for your work here again! I don't foresee any issues getting this merged, despite my initial reluctance when this was proposed, you already did all the work here so there's no reason to say no as it won't cause an major problems :-)

[AtomHare]

The PR should be ready for review !

About the name it's no trouble, it can be whatever we want it's easily swappable.

I could have run the Dockerfile provided in the easy-builder project directly on GitHub actions but for performance reasons it didn't make much sense to me since GHA can already be considered a VM or container.

[sonic2kk]

I could have run the Dockerfile provided in the easy-builder project directly on GitHub actions but for performance reasons it didn't make much sense to me since GHA can already be considered a VM or container.

Makes sense, no need for Docker here, I agree :-)

---

Took a look at the SteamTinkerLaunch codebase and the PR to bump the Yad AppImage (sonic2kk/steamtinkerlaunch#1077), and it looks like it is just the name that needs to change. There's no complex logic with checking tags or anything like I thought.

One thing I did spot that was missing which my (broken) pre-release upload was also missing, is a checksum. I think STL will just skip over this if it is missing, but if at all possible I wonder if we can include one with the actions? Not sure quite how much benefit it would provide, so if it's not trivial / you're not keen, that's all good too.

---

Once a Yad AppImage is created and released using this Action, SteamTinkerLaunch will continue to use the AppImage release it is pinned to check for with YADSTLIMAGE. In other words the codebase will need to be bumped afterwards. That's totally fine, there's nothing to do on your end, I'm just noting this for clarity.

---

Took a quick look at the Actions, looks mostly good, just have one thing I'll leave a comment on.

[AtomHare]

One thing I did spot that was missing which my (broken) pre-release upload was also missing, is a checksum. I think STL will just skip over this if it is missing, but if at all possible I wonder if we can include one with the actions? Not sure quite how much benefit it would provide, so if it's not trivial / you're not keen, that's all good too.

Sure I can add it as a step and ship it, how would you like it to be shipped ? As a checksum file or included as a description of the release post ? I'm not very familiar on how to do it

[sonic2kk]

The current release includes the checksum as a separate release asset: https://github.com/sonic2kk/steamtinkerlaunch-tweaks/releases/tag/Yad-8418e37-x86_64.AppImage

I'm also not sure how it works, but perhaps it would go here? https://github.com/sonic2kk/steamtinkerlaunch-tweaks/pull/2/files#diff-0fc51d8605d4bc23541443425edb21f87e22b6a91136180a4aa2b827b886f35eR76

There is an example on the action-gh-release readme: https://github.com/softprops/action-gh-release?tab=readme-ov-file#%EF%B8%8F-uploading-release-assets

So perhaps we need another step like this, to create checksum from the created AppImage, and then create a new file with the same name as the AppImage (including the .AppImage extension), but with the extension .sha512sum.

    - name: Generate sha512sum
      run: sha512sum Yad-${{ steps.yad_version.outputs.version }}-x86_64.AppImage > Yad-${{ steps.yad_version.outputs.version }}-x86_64.AppImage.sha512sum

Then we can attach it to the release assets by modifying the release step's files section:

files: Yad-${{ steps.yad_version.outputs.version }}-x86_64.AppImage
    | Yad-${{ steps.yad_version.outputs.version }}-x86_64.AppImage.sha512sum

All of those snippets are untested :-) But hopefully it gives some direction on how to do it. I'm very unfamiliar with GitHub Actions (made a bunch of commits trying to get ShellCheck to work on the STL repo 😅) but I'll do my best to give any more help.

[AtomHare]

Thanks for your help with it, I added it to the workflow and it looks to be working well. See https://github.com/AtomHare/steamtinkerlaunch-tweaks/releases/tag/Yad-13.0 !

[sonic2kk]

sha512 checks out, thanks!

So I tested out the AppImage and in terms of pure functionality, it works perfectly with STL - at least in what I tested with. One user on endeavourOS had segfaults with Yad from AppImage and repos, so I wanted to do an extra check for this.

There is a """problem""" here though, as a result of it being built against Ubuntu, the AppImage will by default use GTK Adwaita(?) theming and fonts. This can be somewhat remedied with GTK_THEME="theme_name" (i.e. GTK_THEME="Breeze"), but that would have to be a hardcoded value.

I am running on Arch Linux with KDE Plasma 6 Wayland for context.

For some reason the AppImage will not use the system-configured values here, but the existing AppImage works fine. It is likely the result of one being built on my PC and the other being built inside of a container, as this does also happen if you use easy-builder and build against Debian with Docker iirc.

Yad 13.0 AppImage

Note the theme, icons, and font.

Yad 13.0 AppImage using GTK_THEME="Breeze"

Note that the theme is now correct, but the icons and font are not.

Current Yad 10.XX AppImage (Yad-8418e37-x86_64.AppImage)

It respects the system theme, font, and icons.

---

This isn't a result of anything that you are doing incorrectly but likely something has to be tinkered with to get the AppImage to build with the expected parameters. I'm not sure how to do that yet at this moment though.

I suppose because this is more of a cosmetic thing and because the AppImage doesn't have to be built immediately, this PR can be merged as-is because it is 100% correct, and this problem can be tackled separately. It's not like we're in a desperate hurry for a new Yad version 😄

[AtomHare]

Okay after some looking, I think I may know where this come from, when building the appimage it pulls the availables systems libs on the host and everything else required (probably themes and fonts too). I'm going to install breeze-gtk-theme and breeze-icon-theme in the runner and we'll see how it does, if you are okay to try again.

Edit: It doesn't look like to have bundled the required files, it will probably need some digging

Edit 2: After extracting each AppImage and comparing them, they really look alike. It may be that it was compiled in an KDE environment, whereas the Ubuntu one is built in an Adwaita environment. I don't think the currently working yad AppImage would work well in a gnome environment for example.

[sonic2kk]

Thanks for doing some digging, I'm already asking far more of you here than I had any right to 😅

I don't think the currently working yad AppImage would work well in a gnome environment for example.

This is a good point, so perhaps this is the same problem but the other way around. Although I thought the previous AppImage was built on an Xfce4 desktop (I think that's what Frostworx used at least at the time).

I'll try spin up an Ubuntu 24.04 VM tomorrow and see how the current AppImage looks there. Assuming it doesn't use correct theming there, we could add optional settings in STL to override the theming of the AppImage with the GTK environment variables, and the only reason we would put them in the UI is to keep them independent from any env vars a user might set up themselves and also because I don't think there's an easy way right now to set environment variables for just the Yad AppImage with SteamTinkerLaunch.

---

If testing shows that the theming thing has always been a problem, just masked by myself using KDE and no one having reported the AppImage not following the system styling, we can merge this PR

[AtomHare]

Okay, I reverted by previous commit.

Thanks for doing some digging, I'm already asking far more of you here than I had any right to 😅

Well no issue, it's basically debugging and normal since I'm doing the PR.

If testing shows that the theming thing has always been a problem, just masked by myself using KDE and no one having reported the AppImage not following the system styling, we can merge this PR

Now that I think of it does STL actually use either breeze or adwaita theme ? Doesn't itself uses his own theme ? I never seen either icons when using STL on my steam deck.

[sonic2kk]

Now that I think of it does STL actually use either breeze or adwaita theme ? Doesn't itself uses his own theme ? I never seen either icons when using STL on my steam deck.

SteamTinkerLaunch doesn't have a theme, Yad uses GTK and will use whatever GTK theme is available to it on the system. When installed with a package manager for example, it will use the system GTK theme. If I change the GTK theme in the KDE System Settings, Yad at /usr/bin/Yad will respect it. Likewise the current Yad AppImage will also respect it. It is only the AppImage built from CI here that won't use my system GTK theme and I am not sure why 😅

I hunted through some old Steam Deck screenshots and it seems Yad is using Breeze icons, note the folder icon beside "tmp": sonic2kk/steamtinkerlaunch#639 (comment)

It also looks as though it's using the system GTK theme, perhaps Valve's Vapour or a custom user-installed theme? I'm not sure, but it is respecting some configured theme here.

I don't currently use and will likely never again use SteamTinkerLaunch on a Steam Deck again so I can't verify current behaviour. But I'm planning to test on an Ubuntu VM and see how the current AppImage looks, because the current AppImage is able to use my selected system GTK theme whereas the one built from CI here is not.

[sonic2kk]

I wonder if there is some system package needed on CI to get the AppImage to work properly. I wonder if kde-gtk-config has to be installed on the container (possibly kde-gtk-config-style for Ubuntu, unsure of the exact package name)?

I think this is the package that needs installed to be able to configure GTK application theming in the KDE settings in the first place, which is why I think that may help here, but I could be wrong. Although that would explain why the pre-release Yad AppImage built on my system (and not working on other systems because of the higher glibc requirement, which this PR resolves by building against Ubuntu 22.04) respects the GTK theme.

EDIT: Still unsure of the exact package but perhaps it is kde-gtk-config-style although based on the dependencies here it may not support Qt6... But perhaps there is another package or something. I am not too familiar with Ubuntu these days 😅 On Arch the package is just kde-gtk-config and the dependencies mostly seem to line up, except for Arch they are KDE Plasma6/Frameworks6+Qt6 dependencies and not their 5.X counterparts.

[sonic2kk]

I did some tests and the existing AppImage does actually work as expected; it follows the system GTK theme on my KDE Plasma 6 Arch PC (Breeze) and the system GTK theme on an Ubuntu 22.04 VM (Adwaita I think it's called). Here are some screenshots to visualise it:

Ubuntu VM

Both the current Yad AppImage and the Yad 13.0 AppImage built from GitHub Actions respect the system theme on Ubuntu 22.04.

Arch PC

Only the current Yad AppImage uses the system GTK theme. The icons used are also different. The Yad 13.0 AppImage from GitHub Actions is still using the same theme as the standard GNOME Desktop and not using the GTK theme selected in the KDE Plasma System Settings.

The font is also different, and this problem should be solvable, as I have seen at least one AppImage that does respect the system font (ProtonUp-Qt, although its AppImage build Action process differs slightly).

[AtomHare]

Thank you a lot for your testing, I don't really know how to differentiate both AppImage because the building looks identical between the old and new one except maybe the computer it was built on and the version of the libs used.

I just tried a new approach on my testing branch with the linuxdeploy-plugin-gtk which fits in since yad is a gtk app.

Could you try it? I tried it on my Steam deck and it looks like it's following the theme ! Yad-TEST used a "workaround" that looks needed too, feel free to tell me which one works best ! It looks related to linuxdeploy/linuxdeploy-plugin-gtk#39 but don't look too much at the workaround it's kind of ugly (AtomHare@26868be).

If it works for you, I will rebase and fix everything in a single commit, you can pre-review it here !

---

Note: Unrelated to the PR

I don't currently use and will likely never again use SteamTinkerLaunch on a Steam Deck again so I can't verify current behaviour. But I'm planning to test on an Ubuntu VM and see how the current AppImage looks, because the current AppImage is able to use my selected system GTK theme whereas the one built from CI here is not.

Did you had a bad experience with STL on the SD ?

[sonic2kk]

I tested out the Yad AppImage and unfortuantely on my Arch PC and an endeavourOS VM, Yad is still using the same theme.

However, it is now using the system icons!

Also, looking at linuxdeploy/linuxdeploy-plugin-gtk#39, I can see the APPIMAGE_GTK_THEME environment variable. This will actually get the AppImage to use Breeze, whereas GTK_THEME="Breeze" doesn't work on the latest AppImage you built.

So perhaps this is simply a case of an upstream GTK issue that we can't do much about? It sounds that way from reading the issue.

---

EDIT: Oops, forgot to mention, it seems the newest AppImage wasn't built with Wayland support. For the record I did test on an X11 and Wayland session on the endeavourOS when I realised this just to rule out that being the culprit.

And:

Did you had a bad experience with STL on the SD ?

Yes, in terms of userbase and general usage. Valve deliberately lock down SteamOS unfortunately and various functionality that STL offers such as launching a custom executable alongside a game, by design Valve try to stop on in Game Mode (to prevent rogue processes draining battery etc).

[AtomHare]

I think I misworded it, TEST2 icons work but not the theme (same behavior I observed on my steam deck but TEST works indeed), could you try with TEST? https://github.com/AtomHare/steamtinkerlaunch-tweaks/releases/tag/Yad-TEST You can directly skip over to the next comment to try the Yad-13.0 release !

About Wayland support, I'm pretty sure it shouldn't change the theme since AppImage don't support Wayland, x11 or Xwayland should behave nearly the same !

[AtomHare]

I've updated the branch with the gtk plugin for better gtk support with the workaround. The latest build is now available as the usual Yad-13.0 https://github.com/AtomHare/steamtinkerlaunch-tweaks/releases/tag/Yad-13.0 !

Note: This build fix both icons and theme

[sonic2kk]

Tested and the latest AppImage linked in your latest comment works! Hell yeah! It fixes the theme and icons issue, now the AppImage theming works as expected.

The last thing to fix here is to bring back Wayland support which was lost somewhere along the trail. Maybe the Wayland libs need to be installed on the container? I think Proton-tkg installs libwayland-bin, libwayland-dev, and wayland-protocols on its Ubuntu CI.

Running GUI applications under XWayland has quite a few quirks, one of the main ones being poor support for mixed scale setups. Yad is pretty much unusable on my PC when running with XWayland. The Yad AppImage runs exactly the same as my system Yad if I force it to use XWayland with GDK_BACKEND=X11, but the AppImage here has no support for Wayland, whereas earlier versions of it did, and the existing Yad AppImage does too.

Once that is fixed this PR is ready to merge 🥳

[AtomHare]

Maybe it's linked with the libs but I'm pretty sure Wayland libs are already bundled in the appimage but unused.

We probably need to test this using a sed commande (like for the theme) to remove this line : export GDK_BACKEND=x11 # Crash with Wayland backend on Wayland

[AtomHare]

If you try again with the latest 13.0 build Wayland should work ! https://github.com/AtomHare/steamtinkerlaunch-tweaks/releases/tag/Yad-13.0 🎉

[sonic2kk]

Wayland support is back with that fix, but the system theme is not respected when using Wayland.

# Specifying "GDK_BACKEND" is not explicitly necessary to use Wayland,
# I'm just specifying it here for clarity on what backend is being used

# Uses X11, system theme + icons are used :D
GDK_BACKEND=x11 ./Yad-13.0-x86_64.AppImage

# Uses Wayland, default GTK theme + icons are used :(
GDK_BACKEND=wayland ./Yad-13.0-x86_64.AppImage

Using GDK_BACKEND=x11 (XWayland)

Using GDK_BACKEND=wayland (Native Wayland on KDE Plasma)

Note that on a Wayland session, specifying this is not required, because your recent commit fixes using Wayland, but the theming is not applied properly.

Using GDK_BACKEND=wayland GTK_THEME="Breeze"

This hardcodes the theme to be a theme on the system, in this case it is KDE's "Breeze" theme for GTK. The widgets are right but the icons are not, we have come full circle again 😅

---

I don't think this is an issue you introduced or anything, there might just be some weirdness that needs worked around. I'll see if I can find anything out...

[AtomHare]

It looks like it's related to this https://github.com/swaywm/sway/wiki/GTK-3-settings-on-Wayland, I'm not sure how we can implement it though.

I don't know how the previous AppImage did work on Wayland properly 🤔
Even under Gnome 46, the old AppImage Yad-8418e37-x86_64.AppImage looks broken under Wayland

Could you try this workaround ? (With the latest 13.0) It may be linked with your gtk3 config: https://wiki.archlinux.org/title/GTK#Themes or https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK_applications#Breeze

[sonic2kk]

It may be linked with your gtk3 config

Yes, KDE handles this. It syncs the Plasma theming to the ${XDG_CONFIG_HOME}/gtk-3.0/settings.ini. All of the values in this file are synced to the same ones configured by the system (font, cursor, icons, etc), this is handled by gtk-kde-config. Other GTK applications can read this that are installed to the system, although I am not sure about other GTK AppImages. I'm not sure that I have any that aren't just Electron apps. I'd be interested to know if recent GTK application AppImages also have issues picking up theming on Wayland, but work fine on X11.

Using the GTK_THEME workaround does work, except for setting icons and fonts, unless you were talking about another workaround that I missed 😅 It seems that the AppImage here is not reading the GTK config file.

I wonder why the old AppImage worked as well. Maybe this is something problematic only with a newer GTK version?

[AtomHare]

Honestly, I don't have clues anymore since using AppImage with Wayland doesn't look to be officially supported for GTK applications (on linuxdeploy) but even then this leads to nearly no information to provide fixes to the Wayland theming issue with GTK.

Maybe it was lucky for the old AppImage to work with KDE since it's broken on gnome ? If you still have contact with the old STL maintainer, it could be nice to know how it was really compiled !

Edit: Is the theming issue under Wayland really important, since people should install it using their distribution instead of the AppImage ? The AppImage is mainly for Steam deck users if I understood everything well, this give us some time because KDE on the steam deck is currently on x11

[sonic2kk]

Maybe it was lucky for the old AppImage to work with KDE since it's broken on gnome

Yeah, that's my thinking overall. It is also possible something has changed in the last couple years with linuxdeploy, upstream GTK, both, or something else.

Is the theming issue under Wayland really important, since people should install it using their distribution instead of the AppImage ? The AppImage is mainly for Steam deck users if I understood everything well, this give us some time because KDE on the steam deck is currently on x11

It's not a huge deal, it is mainly that I wanted it solved for parity. If I recall correctly, if I compile the AppImage with easy-builder on my Arch PC the theming appears to work properly, but if I compile it on a VM, or here with CI, it does not theme correctly. But I guess on GNOME it's broken anyway, so... The only thing missing that I can think of that is that kde-gtk-config package.

I don't think the Steam Deck will switch to Plasma Wayland for a while, probably sometime early next year. I imagine they're going to wait for the Steam Client, Steam Overlay, etc to be ported to Wayland, so that things like fractional scaling look right across displays.

However, anyone can use the Yad AppImage. If a distro doesn't supply an up-to-date Yad in its repos (or at all), users install the AppImage with steamtinkerlaunch yad ai. Any user on KDE Plasma Wayland will see the inconsistent theming. I am thinking about it from my perspective, I would be a bit frustrated. But in this case I'm not sure we can do anything, I think this is out of our hands.

---

I will merge this PR as-is and create the Yad AppImage. I will update sonic2kk/steamtinkerlaunch#1077 to point to the AppImage release here once the workflow creates it.

From reading the workflow file, I assume I just kick this off manually from the Actions tab once merged? Seems like that's all there was to it, done :-)

---

Thanks for dealing with all my questions 😅 I really appreciate all your work here and discussion! If nothing else, this will serve as documented discussion to show we were aware of this issue and attempted to resolve it :-)

[AtomHare]

I have a last idea, you said if you follow easy-builder on your machine you get a working wayland theme ? Could you send this particular Yad image compiled on your machine? I'd like to see how they differ!

[sonic2kk]

No problem! The Yad AppImage that works on my machine with the correct theming is here: https://github.com/sonic2kk/steamtinkerlaunch-tweaks/releases/tag/Yad-fbfb0fa-x86_64.AppImage

This was compiled on Arch, and so on SteamOS at the time (and presumably several other distros) the glibc version was too new and so it did not run.

[AtomHare]

Hmmm, now that's weird. I just tried Yad-13.0 on a fresh KDE Neon install inside a VM and the breeze theme indeed works:

[sonic2kk]

Hm, I don't have KDE Neon (based on Ubuntu), but with endeavourOS (based on Arch), the AppImage looks the same as it does on my Arch PC. Perhaps this is theming issue that I'm having is something specific to Arch-based distros...