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.

 

9 responses to “GNOME Software and DOAP Files”

  1. Jeremy

    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. Jeremy

    The best option is In the ${app}.desktop, because will avoid Software very slow.

  3. James

    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

  4. Lennart

    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 :)

  5. Mike Manilone

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

  6. Alexander E. Patrakov

    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.

  7. Zygmunt Krynicki

    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).

  8. ReinoutS

    Many Gnome apps already have some sort of About text in their manual, available on https://help.gnome.org/ .

Bad Behavior has blocked 2769 access attempts in the last 7 days.