Skip to content
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

Define additional metadata in .desktop file #59

Closed
probonopd opened this issue Jan 8, 2016 · 13 comments
Closed

Define additional metadata in .desktop file #59

probonopd opened this issue Jan 8, 2016 · 13 comments
Labels

Comments

@probonopd
Copy link
Member

The topmost .desktopfile in the root directory of the AppDir/AppImage should be enriched with additional lightweight metadata related to the AppImage.

http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s11.html

PortableLinuxGames apparently already has defined some.

  • X-AppImage-Name: Name of the application (e.g., Krita)
  • X-AppImage-Version: Version of the application that is contained in the AppImage (e.g., 1.3.1)
  • X-AppImage-Arch: Architecture of the AppImage (e.g., x86_64)
  • X-AppImage-Release: Version or timestamp of the AppImage itself (added at AppImage creation time)
    ...

However. let's try not to be redundant to AppStream information. So let's not include the license, the URL, etc.

@probonopd
Copy link
Member Author

X-AppImage-Version might be misleading since it is not evident that this is about the payload app

@TheAssassin
Copy link
Member

I think we can close this, since there's support for AppStream, which we propose in a lot of places, including AppImageHub. As far as I know, it has support for a lot of default types, and also allows auxiliary information.

@probonopd
Copy link
Member Author

But it is optional and cumbersome whereas adding the version of the application should be easy/automatic...

@azubieta
Copy link
Contributor

I guess that this should be solved by the conclusions of this discussion: AppImageCommunity/appimaged#30 therefore I'll close the issue.

Re-open it if you think otherwise :)

@probonopd
Copy link
Member Author

AppImageCommunity/appimaged#30 names some metadata which currently is not in desktop files yet (but may be required for the proper functioning of the concepts outlined in AppImageCommunity/appimaged#30). At this point it is unclear whether an extension of the current desktop file format is the way to go, or a switch to something like JSON or YAML (which would allow for plist-style data structures like arrays etc.)

@probonopd
Copy link
Member Author

Let's close this only after we have documented this stuff somewhere.

@probonopd probonopd reopened this Nov 23, 2018
@TheAssassin
Copy link
Member

I don't see why there's a need for another name field. We already have version support. There's no need to put the architecture in the desktop file. And the timestamp of the AppImage creation isn't really anything a user needs to worry about.

There is nothing to discuss in here any more, the version part has been implemented long ago.

@probonopd
Copy link
Member Author

X-AppImage-Version is currently undocumented, isn't it? (Where is it documented/specified?)

@probonopd
Copy link
Member Author

Same for the architecture?

@probonopd
Copy link
Member Author

Reference: #662

@TheAssassin
Copy link
Member

Many features are undocumented right now. Please open an issue in the docs repository.

@probonopd
Copy link
Member Author

Thank you for documenting them. Should we also add them to the AppImageSpec?

@TheAssassin
Copy link
Member

If you like. I'm not entirely sure which are even supported, so I stayed a bit vague. After all, I only know for sure X-AppImage-Version is actively used.

I don't think that stuff needs to go in the spec necessarily, but if you like, you can put it in as a recommendation (SHOULD). That's probably more motivation for anyone than the docs to implement this in their tools.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants