The icon seems to be wrong #27
Comments
|
First of all we should know how Dolphin detects the "right" icon, my AppImage only contain 4 files and a symlink to the icon
|
|
Howdy Ivan 👋
seems to happen also with Nemo |
|
uhm.... just curious, try to download other random appimages from my repositories https://github.com/ivan-hc#my-appimage-packages I have the suspect that its due to newer compression via appimagetool (my AppImages does not require libfuse2) |
|
also test with these appimages by @Samueru-sama
we bundle appimages using the same appimagetool from https://github.com/AppImage/appimagetool |
|
I have the xapp appimage thumbnailer with thunar and I have no problem seeing the Steam appimage icon;
|
None of these show up with an icon file. Maybe it could be fixed with a more recent (how recent?) version of software, but the point of AppImages is to support applications on any distribution release, so it would be nice to have these working. My OS is Gentoo (stable profile desktop) with the newly released stable KDE6 packages. |
Try the zen browser appimage that one also uses the static runtime (Cemu and Duckstation also use it). Looks like KDE has issues displaying the appimage icon for appimages that use the static runtime. |
|
@sinetek The next appimage release which will happen after this PR gets merged will make I have a feeling that the problem is that DirIcon is a symlink and not an image and as result KDE has trouble picking up, after reading some comments from an unrelated thing lol. Edit: Now it is merge, try the appimage and let me know. |
|
I tried just now, I don't see anything different. |
Oh what a shame, if you also don't have the icon with zen-browset, cemu, duckstation and pcsx2 then it is an issue with kde. |
|
It is not, the issue also happens on Linux Mint (most popular distribution)
Anyway don’t be discouraged, the project is cool!
Sent from [Proton Mail](https://proton.me/mail/home) for iOS
…On Sun, Sep 8, 2024 at 02:26, Samuel ***@***.***(mailto:On Sun, Sep 8, 2024 at 02:26, Samuel <<a href=)> wrote:
> I tried just now, I don't see anything different.
Oh what a shame, if you also don't have the icon with zen-browset, cemu, duckstation and pcsx2 then it is an issue with kde.
—
Reply to this email directly, [view it on GitHub](#27 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABNCTC5WTZXDA7JRX6TOC5TZVNHPPAVCNFSM6AAAAABNXAPVIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZWGQYTGMRYHA).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Linux mint using what? If you said linux mint using xfce4, I'm assuming that you would have the xapp-thumbnailer already installed and appimages should show the icon:
|
|
As I said at start, the AppImage only contain4 files and one symlink (the latter now is a real icon instead, as @Samueru-sama said), so it is impossible that a reliabe thumbnail picker is unable to show the icon. Also, Thunar file manager handles these in all AppImages that use newer methods to be packaged. Both me and @Samueru-sama have XFCE/Thunar, but while him uses Arch Linux, I use Debian, so the abovementioned thumbnails plugin is missing in my repositories, so I can't see thumbnails at all. Maybe is your distro in use that has some libraries or plugins outdated if compared with the new specifics for AppImages? Like me? I don't know. But it is also true that AppImages are not all the same, and if some developers compile them keeping the dependency on the EOL library "libfuse2", we got rid of it. Maybe thumbnails are gone for this, in your case, but as packagers and developers who constantly follow the developments of AppImage as a packaging format, we aim for innovation and compatibility with essential system libraries. Thumbnail management is not something we do. While Dolphin, Caya, Tumbnailer... these are the projects that aim to manage files, included in our AppImages. A thumbnail manager is an extension that must follow our work, since showing icons is its purpose. To handle the thumbnails is something that developers of file managers or their extensions should be able to do, if that is their goal. That said, I suggest to contact the developers of Dolphin and Caja or of other file managers or of somehow extension... to verify, follow and collect the newer specifics for AppImages. The issue is not of the developers of the AppImages. Sorry. |
|
For the record, it's just your appimages that don't show up with an icon, the others work fine. |
Can you confirm indeed that zen-browser, cemu, etc don't have the same issue? those use the same tooling to make the appimage. |
Ah, I guess there's different tools to create these appimages? The projects you mention also have the same bug. I give my apologies then, I'll accept the WONTFIX and go do something else. 🤷 |
The issue is that appimages have this well known issue of having a dependency to libfuse2, libfuse2 has been EOL since like 2020. A lot of distros no longer ship libfuse2 by default. The solution has been for a few years, but only recently it began to be used by default on some tooling, it is called the type2-static runtime, which this project among others use. However switching the runtime to be static has had it's on set of issues as you can see, most notably it breaks appimagelauncher which is a popular appimage integration tool, and we just learned that it also breaks some appimage thumbnailers as seen here (but not all as you already saw that thunar with the xapp thumbnailer doesn't have the issue). So you may want to report the issue first at the runtime and hopefully it is something stupid that can be fixed, if not then the next step is reporting this to the KDE folks. And yes there is a lot of appimage creation tools, but in this case the issue is likely something with the runtime being static. |
|
Can you report the issues? Look, I’m not the one using these tools, I have no idea how your are invoking them or what versions you’re using or how any of this works, except that my icon doesn’t show up.
I don’t use appimagelauncher because it doesnt support OpenRC, but thats another issue.
Also don’t do static runtime on Linux. It just does not work properly and glibc folks don’t support it at all.
Sent from [Proton Mail](https://proton.me/mail/home) for iOS
…On Sun, Sep 8, 2024 at 13:36, Samuel ***@***.***(mailto:On Sun, Sep 8, 2024 at 13:36, Samuel <<a href=)> wrote:
> Ah, I guess there's different tools to create these appimages? The projects you mention also have the same bug. I give my apologies then, I'll accept the WONTFIX and go do something else. 🤷
The issue is that appimages have this well known issue of having a dependency to libfuse2, libfuse2 has been EOL since like 2020. A lot of distros no longer ship libfuse2 by default.
The solution has been for a few years, but only recently it began to be used by default on some tooling, it is called the type2-static runtime, which this project among others use.
However switching the runtime to be static has had it's on set of issues as you can see, most notably it breaks appimagelauncher which is a popular appimage integration tool, and we just learned that it also breaks some appimage thumbnailers as seen here (but not all as you already saw that thunar with the xapp thumbnailer doesn't have the issue).
So you may want to report the issue first at the [runtime](https://github.com/AppImage/type2-runtime) and hopefully it is something stupid that can be fixed, if not then the next step is reporting this to the KDE folks.
And yes there is a lot of appimage creation tools, but in this case the issue is likely something with the runtime being static.
—
Reply to this email directly, [view it on GitHub](#27 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABNCTC54S7TBWQ6NYNHUQC3ZVPWAHAVCNFSM6AAAAABNXAPVIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZWGU3DONJQGQ).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
The actual issue is that you must have every file that is at the root of the After I changed it to And remade the appimage: You can test it yourself: https://pub.ajam.dev/temp/steam_fixed.AppImage $ sha256sum steam_fixed.AppImage
228446454a0c18827f302d2a5fa7cf373dd6e88e64e3a6cf9749f1e81b428034 steam_fixed.AppImage
You can get more details and how I discovered this at: https://t.me/VHSgroup/87301/88306 chmod "u=rx,go=rx" {ALL_FILES_IN_SQUASHFS_ROOT}
#chmod 555 will also work |
|
Update: Upon further discussion/deliberation, it's likely that this issue and "fix" may only apply to me. |
No, this works great as a solution!
I just did what you said in your post above, and then |
|
@sinetek Thank you for your confirmation. |
I don't need to touch the files, just unpacking and repacking with appimagetool is enough to get the icon back. I tested this with a lot of broken appimages and it always works. |
What appimagetool did you use? If it is the appimagetool from AppImage/AppImageKit that makes sense, that one is old and still uses the old runtime. While the appimagetool from AppImage/appimagetool or from probonopd/go-appimage use the static runtime instead. |
|
Also did this appimage work? https://pub.ajam.dev/temp/steam_fixed.AppImage Don't repackage it with appimagetool or anything like that, does the appimage from that link work out of the box? |
|
@sinetek I repeat, thumbnail managers should adapt to the work of AppImage packagers, not the other way around. I have over 70 AppImages in my repositories, usability is the focus of my workflow. The concern of an AppImage packager is to make the program run on as many systems as possible, regardless of the Desktop Environment and file manager. File thumbnails are not a priority, and must be managed by dedicated applications or extensions. In @Samueru-sama case, in XFCE/Thunar on Arch Linux, it worked without these tricks. If what matters most to you are the thumbnails in your files, I think your file manager is wrong at this point. If what matters to you is how the file looks in the file manager, report the issue to the file manager developers.
|
No. There are more than 20 major distributions around, and they do not work on a rolling basis. Meaning an update could be 2+ years away in some cases. Moreover, there are a lot of older (supported) installations, and the point of an AppImage is to offer compatibility to these as well. My angle here is helping newcomers to Linux have a good experience instead of hitting a bumpy road. |
Hi sam, |
Yeah, that pretty much confirms that the issue is due to the runtime, like Ivan said here originally. Worth noting that the xapp-thumbnailer has no problems showing thumbnails for these appimages in both nemo and thunar. And also after several days of testing @Azathothas managed to get the Steam appimage to show Icon in dolphin, that is the regular Steam appimage and not the "fixed" one, how I don't know lol. |
|
Update I managed to get dolphin to show appimage icons. All I needed to do was install the
Before I was not able to get dolphin to show any icon for any appimage, be it old or new. |
|
I'm on Debian Testing, I have installed with
all AppImages I have installed via AM have the thumbnail.
and also Steam available here
you can see the two packages I have installed manually from https://www.debian.org/distrib/packages and note that libreoffice is an AppImage requiring libfuse2 that I have repackaged the same way I package my AppImages, and the thumbnail works. also my old Appimage of wine shows the icon
I downloaded also two Brave and Zen now
everything works as expected. So I confirm that xapp-appimage-thumbnailer is a cutting edge thumbnail manager, while Dolphin/KDE/Plasma doesn't give a damn about AppImage as a "dead and unworthy packaging format". This is what happens when most of the Linux community focuses all their efforts on Flatpak, while being fooled by AppImage prejudices. This is the page of the project https://github.com/linuxmint/xapp-thumbnailers just to give you an idea of what deserves attention. |
And as Samuel says, libappimage is also needed, I installed libappimage-dev from Debian repositories. |
|
Hello everyone, I found the issue. libappimage by itself does not support
The solution is to, 1) activate fusefs support in the libappimage build, and I think this uses more resources than just using libappimage's default xz compression, since Arch's libappimage goes through fuse, but it works now.
@ivan-hc Would you be so kind as to document this in your README.md? I apologize if you feel I've wasted your time with this issue, I'll update the libappimage side of the bug report. |
|
Thanks @philmb3487 you are wellcome, I'll redirect new issues on this thread instead or to your last answer. I repeat, I have 70 Appimages in numerous repositories, and this seems to be a solution to be implemented in the tools that we packagers download and use daily. Once this is solved, in months and years, it will be useless to continue to have this indication on the README. We just have to wait. Thank you for the research and the work done. See you next time. |
I don't know if this is just my setup, but the appimage icon does not seem to show up correctly in Dolphin:
The text was updated successfully, but these errors were encountered: