MetaInfo: Difference between revisions

    From KDE TechBase
    No edit summary
    Line 9: Line 9:


    == Metadata Types ==
    == Metadata Types ==
    {{Attention|1=All metadata files follow the same XML rules and are essentially the same. The separation made on this page is solely to address different groups of people and different projects, to help them getting started quickly without reading too much information which is not relevant for the project they are developing.}}


    === Application ===
    === Application ===

    Revision as of 17:23, 17 April 2014

     
    Under Construction
    This is a new page, currently under construction!

    Introduction

    These pages contain information on how KDE can make use of the MetaInfo data provided by the Freedesktop.org AppStream project.

    Outline

    MetaInfo files are used to describe a software component in a distribution. The metadata these XML files provide contains information about the public interfaces this component provides, the descriptions of the component, as well as additional things such as icon information and categorization. There are several special components, for example for applications, web-applications, fonts, codecs and input-methods. The information defined in these files is used by AppStream-compatible software centers (such as Apper or GNOME-Software) to display them to the user. In the following, we describe for different kinds of KDE software components how to write proper AppStream MetaInfo files. A project may ship multiple metadata definitions, for example if it ships an application and a library, or multiple applications.

    Metadata Types

    Attention
    All metadata files follow the same XML rules and are essentially the same. The separation made on this page is solely to address different groups of people and different projects, to help them getting started quickly without reading too much information which is not relevant for the project they are developing.


    Application

    Applications are (usually graphical) programs which show up in the applications menu, meaning they have a .desktop-file. You can read more about how to write metadata for them on the page about desktop-apps.

    Component

    A generic component is a software project which doesn't fit into a specific category. This is usually a shared library or framework which wants to publish information about the public interfaces it provides in a distribution, to make it easier for developers to find the component in the distribution's repositories. You can find information on how to write metadata for a generifc component on the page about generic components.

    Web Application

    Questions

    How do I translate this data?

    The plan is to update Scripty to extract all ranslatable strings and merge the translated content back into the original XML file, just like we do with .desktop files.

    Why not just use the package description?

    Different distros cut and join different source packages in different ways, plus, some don't offer translations.

    Why not just use the DOAP description?

    This is one file per-project and is not suitable when one tarball will install several applications. It's also not translatable, and it does not allow specifying information about public interfaces.

    Why XML and not JSON/other?

    The upstream meta-information is a subset of the AppStream schema, which is also XML.

    Where will this data be used?

    We will scrape this data when building and composing distributions, and depending on the implementation will either use an OCS server or directly copy the AppData data into the AppStream metadata. In distributions, this data will be used in software-centers, as well as in other tools to query the installation of missing components.

    Further Information

    For further reading, we suggest taking a look at the AppStream documentation and it's XDG wiki page.