icon file name in appdir root: has to share basename with desktop file?

[kossebau]

The current section about "filesystem image" uses an identic variable name $APPNAME in the names of the desktop file and the icon file. Which can be understood to imply that the icon file should have the same basename as the desktop file name, even more as $APPNAME in both cases is specified "being the name of the payload application":

• SHOULD contain exactly one $APPNAME.desktop file in its root directory with $APPNAME being the name of the payload application
• MAY contain an $APPNAME.png file in its root directory with $APPNAME being the name of the payload application as set in the Icon= key of the $APPNAME.desktop file.

This conflicts slightly with the fact that for existing applications which follow latest xdg recommendations the desktop file names these days have tld-prefixes (e.g. "org.kde.kdevelop.desktop", "org.kde.krita.desktop", "org.qt-project.qtcreator.desktop") but continue using non-prefixed names for the application icons, which even might have names not exactly matching the application name ("kdevelop", "calligrakrita", "QtProject-qtcreator").

More, the AppDir specification from https://docs.appimage.org/reference/appdir.html has this specifications more relaxed by the text: "It is recommended by AppImage and also the XDG icon specifications to use a lower-case filename which is equal to the desktop file’s name."

My proposal would be to relax the current wording a bit, and make using non-matching names not a negative thing. This allows application authors to use consistent names for the app icons both for the appimage needs as well.

[TheAssassin]

I think we should change the AppImage spec to reflect the current situation instead of increasing the number of constraints in appimagetool. I don't think more strict rules here have any positive effect, they might even break existing third-party tools. The "AppDir spec" is more precise, and I think we should use it to adjust the AppImage spec. (Of course, the AppImage spec is always the top priority document which we rely on, but it should be correct.)

[probonopd]

@kossebau probably I am to blame here. To give you some background, I am always trying to use the simplest, most elegant and easy solution there is. So In my simple world view, the application myapp has myapp.desktop and myapp.{png,svg[z]}. This is nice, clean and simple, and in my opinion everything that deviates from this is more complicated and cumbersome. So this is what I use. I have not really tested all the other combinations - why should we need those?

[TheAssassin]

Reverse domain names are perfectly valid and shouldn't be artifically prevented for some politics. In fact, appimagetool allows all these things. What @kossebau requests is to change the spec to be a bit less strict (as in, "exactly one desktop file and exactly one icon which must match the entry in the desktop file" instead of myapp.{desktop,png}).

[probonopd]

Funny, incidentally I have to fight with icon names that follow reverse DNS notation now, and they make thigs harder than need be... maybe they are "perfectly valid", but that doesn't make me like them.

https://github.com/probonopd/linuxdeployqt/commit/2633eb943be1b2e83678c0514122cc21a3142059 and of course I don't get it right the first time, so https://github.com/probonopd/linuxdeployqt/commit/4f449c161dd43a92a4263bf4e1798b9173b233f5 - this gives you an impression why I don't like such complications when "simple" would just do as well ;-)

Using filenames such as org.olivevideoeditor.Olive.png instead of olive.ong just makes everything harder and less fun for everyone... my 2 cents.

[TheAssassin]

That is an opinion I do share (not completely, but largely), but I'm also a fan of being easy to use and compatible.

I'll have a look at the PR.

[probonopd]

Another example: https://github.com/AppImage/appimage.github.io/pull/1066 (yes, those are bugs, but they illustrate how reverse-DNS just adds complexity and potential error sources)

[TheAssassin]

Closing as resolved. Thanks @kossebau.