-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Appimagelauncher renames the appimage file when 1st run to a very long name #547
Comments
Other appimage launchers do the same. I assume it is for tracking specific versions of appimages. |
Maybe, but does that mean it's the right thing to do? Having an application folder with a bunch of long names is just not a good default user experience. |
This is not a bug, the long name is used to track the appimage version. |
Although i do not care about the aesthetic issue of the file name, i would like to point out another problem: i use KDE Plasma DE, and i usually pin often-used apps to the task manager. however, due to the changed filename this breaks after every app update, after which i have to unpin an empty white logo, find the app in the app launcher, and repin it. it's a small user experience thing, but would it not be possible to provide a static alias link next to the binary? i would expect usability improvements like this from a package manager. I would also not tag this issue as a bug, but a feature request, as this behavior is expected afaict. |
Please open a new issue @whysthatso. The question was answered. Edit: thanks folks for the replies.
It should behave just like the "regular" package. There's no reason why it would differ integration code wise. |
P.S.: @whysthatso your issue is not related to the filename of the AppImage itself. It's the desktop entry's name that changes between different releases and causes those problems. |
ah, i see. i'm not sure if i understand this to be a bug on either appimagelauncher or kde plasma (or the specific app that does the integration with plasma, not sure which one that would be), or of this is an implementation detail that just is the way it is. @TheAssassin do you think it is worth pursuing here as a feature request or what do you think i should do? (also checked #609) |
Well, there is a chance the issue is within AppImageLauncher or one of its components. If it really is a KDE bug, they'll appreciate our debugging as well. Those issues are going to come up regularly. I recently saw some similar behavior on a KDE and a(nother) GNOME system. This pinning causes trouble with the current algorithm. We need to work on that. |
Pre-submit checks
Describe the bug
when running the appimage file for the first time, appimagelauncher intercepts it fine, but it then renames the appimage file to a very long name.
For example:
LibreOffice-fresh.standard-x86_64.appimage
becomes
LibreOffice-fresh.standard-x86_64_a36867597551dafbe6a66179109ac537.AppImage
Expected behavior
for appimagelauncher not to change the filename.
Steps to reproduce the issue
-download an appimage
-open that appimage with appimagelauncher so it integrates to the system.
Screenshots
No response
Distribution and desktop environment
Operating System: KDE neon 5.26
KDE Plasma Version: 5.26.4
KDE Frameworks Version: 5.100.0
Qt Version: 5.15.7
Kernel Version: 5.15.0-56-generic (64-bit)
Graphics Platform: X11
Processors: 12 × Intel® Core™ i7-3930K CPU @ 3.20GHz
Memory: 62.7 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 980/PCIe/SSE2
Installed AppImageLauncher version
202211022349-stable-0f91801~ubuntu22.04.1
List of AppImages you tried
-libreoffice
-librewolf
-geeqie
-stellarium
-avidemux
Additional context
No response
The text was updated successfully, but these errors were encountered: