Ever since we rolled out the GNOME Software Center, people have wanted to extend it to do other things. One thing that was very important to the Eclipse developers was a way of adding addons to the main application, which seems a sensible request. We wanted to make this generic enough so that it could be used in gedit and similar modular GNOME and KDE applications. We’ve deliberately not targeted Chrome or Firefox, as these applications will do a much better job compared to the package-centric operation of GNOME Software.
So. Do you maintain a plugin or extension that should be shown as an addon to an existing desktop application in the software center? If the answer is “no” you can probably stop reading, but otherwise, please create a file something like this:
<?xml version="1.0" encoding="UTF-8"?> <!-- Copyright 2014 Your Name Here <your@email.com> --> <component type="addon"> <id>gedit-code-assistance</id> <extends>gedit.desktop</extends> <name>Code Assistance</name> <summary>Code assistance for C, C++ and Objective-C</summary> <url type="homepage">http://projects.gnome.org/gedit</url> <metadata_license>CC0-1.0</metadata_license> <project_license>GPL-3.0+</project_license> <updatecontact>richard_at_hughsie.com</updatecontact> </component>
This wants to be installed into /usr/share/appdata/gedit-code-assistance.metainfo.xml
— this isn’t just another file format, this is the main component schema used internally by AppStream. Some notes when creating the file:
- You can use anything as the
<id>
but it needs to be unique and sensible and also match the.metainfo.xml
filename prefix - You can use
appstream-util validate gedit-code-assistance.metainfo.xml
if you install appstream-glib from git. - Don’t put the application name you’re extending in the
<name>
or<summary>
tags — so you’d use “Code Assistance” rather than “GEdit Code Assistance“ - You can omit the
<url>
if it’s the same as the upstream project - You don’t need to create the
metainfo.xml
if the plugin is typically shipped in the same package as the application you’re extending - Please use
<_name>
and<_summary>
if you’re using intltool to translate either your desktop file or the existing appdata file and remember to add the file to POTFILES.in if you use one
Please grab me on IRC if you have any questions or concerns, or leave a comment here. Kalev is currently working on the GNOME Software UI side, and I only finished the metadata extractor for Fedora today, so don’t expect the feature to be visible until GNOME 3.14 and Fedora 21.
Thank you for this work!
It’s really cool! Should we do create pull-requests to the projects with addons to pkgs ? :)
Yes, this should be done upstream — either open bugs or create pull requests to help out — thanks!
How do I handle an program, that is a (Gimp-)PlugIn and a stand alone program at the same time?
Are they shipped in the same package? If so, don’t bother creating a metainfo file. If they are split up, create one appdata file and one metainfo file. Thanks!
This modular system should be applied to the Gnome shell extensions icons, and themes as well!
Installing them through the gnome software would make more sense than downloading zip files, adding random repositories or going to a website which requires a plugin to work (which btw no longer works in Chrome)
And then there is the problem of packages collecting several plugins into one packege like this one:
http://packages.ubuntu.com/trusty/amd64/gimp-plugin-registry/filelist
Upstream I think every plugin should have one metainfo file. I think you’ll then need to find a solution for the UI.
gnome-software should be clever enough to work out that the other addons have changed state, so we should be good there. It’s really the upstream descriptions I need.
if you’re using intltool to translate either your desktop file or the existing appdata file and remember to add the file to POTFILES.in if you use one