GNOME Software and DOAP Files

Progress on gnome-software is progressing nicely. Most of the major functionality is semi-working, although there are an awful lot of rough (and unimplemented) edges. Now the UI is coming together somewhat, it’s probably time to talk about what data it is going to consume. I’ve talked a lot before about extracting application icon and translations from .desktop files, but now I wanted to talk about long, formatted descriptions. Something like:

long-description

So where do we get this long description from? There seems to be many possible places to put this data:

  1. On the distribution web service
  2. In the ${app}.desktop files of the upstream application
  3. In the DOAP file of the upstream tarball
  4. In the package file description
  5. Some new ${app}.xml file shipped by application with all this extra data
  6. Some simple ${app}.md file containing markdown

Each has positives and negatives:

  1. All distros have to do basically the same work, and have to retranslate these over and over. -ENORESOURCE.
  2. It’s not much fun to do multiline descriptions trying to work on one line in a .desktop file, and trying to do rich text like hyperlinks and bullet points is impossible.
  3. DOAP files are not translated, and we only get one file per project, not per app. You probably want a different description for LibreOffice Calc than LibreOffice Presenter.
  4. Same problem as 3, and it also pushes the work to the distros, like 1. And it’s not typically translated.
  5. YAFF. Yet Another Format. Okay, it lets us define rich text (SGML/DocBook/whatever) but it’s another file format to be added to intltool and I’m not sure how easy it would be to get random projects to ship this.
  6. Easy to write, although much harder to extend in the future with things like screenshots and the like. Also, very hard to translate.

Also, anything except option 1 requires the use to have a big cache of all the possible applications they want to search for. So far I’m leaning on some kind of composite approach:

  • Add a X-SoftwareCenterLongDescURI key to the desktop file
  • Have a web URL with an .xml file on any remote server.
  • Download and load the .xml file when the application detail view is opened
  • Optionally translate the .xml.in using intltool and update the description at release time
  • Applications not shipping .desktop files with X-SoftwareCenterLongDescURI just get a shitty app-detail view in the software center.

Comments, suggestions, flames, all very welcome. If/when we come to a consensus, I’ll write up a proper proposal with some guidelines for application authors. Thanks.

 

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

9 thoughts on “GNOME Software and DOAP Files”

  1. Hi, might be a good idea that software displays a preview about the program. The user is more visual, is guided more by an image.

  2. Cool progress! One worry that I would have about having a URL to a remote server is that for large installations you could end up hitting that server a lot. The related issue is that sysadmins like to be able to manage things in an isolated “offline” way. So if that link is pointing to a public address, instead of your local yum repo, then this could be an issue. Not sure what you had in mind.

    HTH
    James

  3. Not completely related, but I wondered what the plans were for multiple distro support. All distro’s have different packagemanagers and different packages (ArchLinux for one doesn’t include gnome-boxes in its main repositories), is that going to be covered?

    For niceness, what about a screenshot carousel in the details page :)

  4. Create a wikisite and give control to users (which contain potential translators). Ahh, bad idea. ;-) Information may be outdated and may be destroyed simply.

  5. How are you going to deal with the fact that different distributions split their packages in different ways? E.g. some provide libreoffice as one big package and some as separate components such as Calc, Writer and Presenter.

  6. Let’s do pypi for generic packages (not just python tarballs, eggs and wheels).

    The way this would work is that all upstream projects could register themselves there, provide meta-data, releases (as source tarballs), etc. Distributions could amend that with distribution-specific information that points to say, fedora or debian package name and availability (release) information.

    The way this would be a win-win is that it would be decentralized (so upstream participation would be evenly possible) but valuable for distributions (they could map all upstream projects to their packages).

    One thing this does _not_ solve is application -to- package mapping but I’m sure it would bring us closer. The libreoffice example could be composed out of meta-data from .desktop files (applications) and central meta-data about the libreoffice project (from the pypi-like central database).

Comments are closed.