spec: Allow <icon> tags in generic components #138
Conversation
|
See hughsie/appstream-glib#192 for the corresponding change to appstream-builder. |
|
The reference implementation and appstream-generator support this already for a really long time. The spec indeed should mention that (I actually thought appstream-glib started allowing the |
What about the paragraph about the location restrictions? Should they be in the spec at all? They are mostly a consequence of how appstream-builder works. (But I think appstream-builder has very good reasons to work the way it works.) I think the situation is similar to the one with icons from a *.desktop file. The Desktop Entry spec allows absolute pathnames pointing everywhere, but appstream-builder will ignore any that are not in the usual locations. This is documented as part of the appstream-builder README (https://github.com/hughsie/appstream-glib#guidelines-for-applications). I think we can do the same here. |
docs/sources/metainfo/component.xml
Outdated
| <para> | ||
| <literal>local</literal> icons are loaded from a file in the filesystem. | ||
| They should specify a full file path in either <code>/usr/share/pixmaps</code> | ||
| or <code>/usr/share/icons</code>. (These restrictions on the icon location are in |
There was a problem hiding this comment.
Those restrictions are appstream-builder specific, I guess - the local type explicitly makes no restrictions for where icons are located, it could be anywhere on the filesystem. The appstream-generator tool deals with them whereever they are.
For the paths you mention, stock is the better solution anyway.
In general, using local is discouraged, stock is almost always the better option.
There was a problem hiding this comment.
I have removed that sentence.
docs/sources/metainfo/component.xml
Outdated
| </para> | ||
| <para> | ||
| <literal>remote</literal> icons loaded from a remote URL. Currently, at least HTTP urls must be supported. | ||
| This icon type may have <literal>width</literal> and <literal>height</literal> properties. |
There was a problem hiding this comment.
Changed. I have also made the corresponding change in xmldata.xml
docs/sources/metainfo/component.xml
Outdated
| properties. | ||
| </para> | ||
| <para> | ||
| <literal>remote</literal> icons loaded from a remote URL. Currently, at least HTTP urls must be supported. |
There was a problem hiding this comment.
I think we can make "at least HTTP urls must be supported" and "only HTTP urls are supported", because that is much more precise and leaves no room for people reading the spec to speculate which other weird protocols we might support.
There was a problem hiding this comment.
Changed. I have also made the corresponding change in xmldata.xml
And not just in the collection metadata. This way, components of type "service" and any other other component can specify icons upstream in a standardized way.
mvollmer
force-pushed
the
upstream-icons
branch
from
c755200
to
388fedc
Compare
| <para> | ||
| The <code><icon/></code> tag describes the component icon. It is mostly used for GUI applications (component-type <literal>desktop-application</literal>). | ||
| It can be of the type <literal>stock</literal>, <literal>local</literal>, | ||
| or <literal>url</literal>. |
There was a problem hiding this comment.
This should be remote, but I can quickly fix that after merging the patch.
|
Looks good now, except for one small type that I'll fix after merging the changes. |
And not just in the collection metadata. This way, components of type
"service" and any other other component can specify icons upstream in
a standardized way.