Is it possible to change the name displayed by an app image?

[Dziban-dev]

I'd like to know if i can rename it to just RawTherapee. im using deepin os, another question i have is, if you can customize an app with themes, where to i put them, there are no folders expect /home/~/Applications

[TheAssassin]

We consider these brackets a feature. The value in the brackets is what the AppImage author specified as version number. In case of RawTherapee, it's quite broken (there should be a real version number), you should contact the author to set a better value.

The idea is that if you run multiple versions of an application, you can easily see which one you want to use. See this example:

"Renaming" of an application isn't trivial, but doable: you need to repack the AppImage with a correct desktop file. You can't simply "rename" an entry in your launcher, that's a limitation of the desktop environments. Please contact your distribution or desktop environment if you need such a feature. We at AppImageLauncher just make use of what's available.

[TheAssassin]

As this is being requested regularly (see also #171), let's reopen this but make it low prio.

[RogueScholar]

Okay, so here are a couple of scenarios that I've found to be fairly ubiquitous for this AppImage enthusiast, at least. They divide into two (possibly three if you're being especially Linnean about it) basic categories:

• There is a not insignificant plurality of the software developer community (present company surely excepted) that is either too lazy or too bloody illiterate to craft an effective, complete .desktop file for their project. I doubt I'll ever understand it; Freedesktop has it documented better than 90% of specifications I've ever tried to comply with and it evolves only slightly faster than ice melts at the poles.
• Only slightly less frequently is the situation where I'm being mildly neurotic about how I like my launcher menus organized and am at variance with the author as to which category suits it best or am using an icon theme which provides a more pleasing means of visually identifying it. The potential third case which I think mostly resides under this umbrella is the rare occasion when I wish to modify the Exec field to include or remove a switch or flag they've set that interferes with my workflow.

What I had envisioned being possible within the AppImage ecosystem was basically inspired by the venerable X11 server's approach to conditional configuration within the xorg.conf file. I agree that it's just not good policy to complicate things by generating a new unique identifier (locally or definitively at the time of packaging) to manipulate these admittedly trivial data points. However if, like in xorg.conf, it was possible to define a Match= condition that could be parsed during the integration/install process when the desktop file is generated, it should be some very straight-forward "sed-fu" to replace certain specified fields with user-defined instead of author-defined values.

These Match strings could take one of any number of forms, from simple text matches with all/some of the app name to a proper regular expression, perhaps even the fingerprint of the key used to sign the AppImage during packaging. (Amazingly, I believe only once in over five years of AppImages have I ever had more than one from the same publisher, so while not a perfect solution, it might be hard to beat as an expression to evaluate against.) Since the fields in a .desktop file are never duplicated (provided you're parsing them as Group+Key since of course each Action has a Name and Exec value as does the Desktop Entry itself) my hope was that for each match that evaluated as true any associated keys in the user override file would simply have their value replace what was going to be generated programmatically.

There really isn't any call for complex logic beyond that, as I see it, since all the changes I've ever wanted to make have been arbitrary in nature. Names, categories, even the icon field is just a simple string since I'd be relying on the DE to tease out the actual path to the image file from the theme rather than needing to insert a path relative to the location of the AppImage.

How does any/all of this sound to you? I could be so out of my depth here that I lack even the ability to intuit how ridiculous it is; if you tell me so I'll accept it and promptly forget the matter. My only goal was to see AppImage gain a bit more parity with the other package formats since they've worked so well for me but always seem to be waging a pitched battle for wider adoption.