discrete <features> list

[hsitter]

I'm seeing a lot of descriptions having a features list and can't help but wonder if it wouldn't make sense to have them formalized. e.g. the windows store works this way. It'd allow clients to render features lists in a consistent place/format (and also allow appstream metadata to better feed into windows store releases)

<features>
<feature>crash</feature>
<feature lang=de>flugzeug</feature>
<feature>memleak</feature>
</features>

or some such

[ximion]

What kind of features to do you have in mind? I can't think of any feature value that would apply to every single application, besides stuff like crash-reporting, which the user likely doesn't care that much about...

[hsitter]

Sorry, what I meant was a list of features per app.

e.g. Filelight's description currently includes this

Features:

    Scan local, remote or removable disks
    Configurable color schemes
    File system navigation by mouse clicks
    Information about files and directories on hovering
    Files and directories can be copied or removed directly from the context menu
    Integration into Konqueror and Krusader

and okular's this

Features:

    Supported Formats: PDF, PS, Tiff, CHM, DjVu, Images, DVI, XPS, Fiction Book, Comic Book, Plucker, EPub, Fax
    Sidebar with contents, thumbnails, reviews and bookmarks
    Annotations support

What I'm suggesting is have these encoded separately rather than as part of the description.

[cassidyjames]

Hm, I don't personally see the advantage to encoding these as "features" in the spec versus just continuing to allow app authors to determine the contents and order of their description. One possible argument I could think of is some interesting layout ideas in an app store that pulled features out next to the regular description, but I don't know if that's actually a real use case that has been expressed by any of the known app stores/software centers—and if this would actually be useful to or wanted by application authors.

@apachelogger can you describe a problem this is looking to solve?

[hsitter]

A more standardized way of presenting features in UIs is what I'm after. When you browse https://apps.kde.org/ you'll find features all over the place. Sometimes mid-description, sometimes none, sometimes as part of the description, sometimes as completely unrelated list. Compared to e.g. the windows store with a discrete features list https://www.microsoft.com/en-us/p/kate/9nwmw7bb59hw#activetab=pivot:overviewtab

This would also allow us to score searches different when they match a feature entry (as opposed to a random substring in the description).

[cassidyjames]

@apachelogger thanks for the prior art; that's interesting regarding the Windows/Microsoft Store. TIL. In this case I could personally see it as a nice-to-have wishlist item, but I think we also have to decide if it's worth creating yet another thing for developers to fill out, for us to document and validate, etc.

[hsitter]

another thing for developers to fill out

Speaking for KDE at least, it seems developers do it already, albeit as part of the description. Out of our 240-odd components ~120 appear to contain the string Features:

[ximion]

The prior art is indeed interesting! Having this as a separate block would be an extremely disruptive change... Maybe in future if we allowed developers to tag paragraphs and lists (like we allow for EULAs and GDPR agreement sections) something like this could be implemented in a backwards-compatible way...