App categories?

Contribute Room Apps packaging
,
1

Hi, we discussed a few times about grouping apps in categories
Here is the pad summarizing some ideas https://pad.aposti.net/p/ynh_app_categories

The discussion continues :slight_smile:
What do you think?

2

I am for multiple tag usage to simplify the search in the list of apps.
And for the possibility to grouping apps from one tag in the user portal.

3

Yes, tags will be much more suited for apps. For example Nextcloud would have the “Mail, contact, cloud…” tags. Eventually the current app list will be replaced by some kind of market in the admin interface right ? One thing I tried a few months ago was getting a filtered app list with Colio. The idea was to have the page fetch the app list and create Colio items, although I never achieved that, but that would be cool to implement something like that in the admin interface.

In the manifest file tags would need to be added, as well as maybe an initial support for image/icon. The sooner the better right ?

Edit: actually I already kind of talked about this here.

4

+1 with using tags instead of categories, I’m always lost in software that uses strict categories (think of the windows “control and settings” panel)

5

Here again I suggest to reuse AppData file to describe applications.
Fedora, Debian, Ubuntu and many other distribution use a standard file named “.appdata”, including description, categories, tags, and it supports internationalization.

Here is an example of a non translated appdata file from josm: https://jibecfed.fedorapeople.org/l10n/appdata-fr/xml/josm.desktop.xml
Here is an example of a fully translated appdata file from gnome-maps: https://jibecfed.fedorapeople.org/l10n/appdata-fr/xml/org.gnome.Maps.desktop.xml

It’s gettext who produce the translated content (it’s using Pot/Po files), here is the example for gnome-maps source file: https://git.gnome.org/browse/gnome-maps/tree/data/org.gnome.Maps.appdata.xml.in

Of course, there is documentation: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-filespec
Appdata validator: https://github.com/hughsie/appdata-tools
A tool to consolidate multiple AppData files from a folder: https://github.com/hughsie/appstream-glib

6

jibecfed ,
to use Appdata, I’ve, at least, 2 doubts.

  • xml files are really less readable for a human than a json file. To read license or name or mail of maintainer, I prefer Ă  json file.
  • xml is more complicated to parse than json with a shell script. That limites others usages of this files by third party apps.

And, that implies to rewrite all codes parsing manifest.

So what does this add to the actual json file?
In this state, it’s simple to add tags to json. So which addition?

7

I agree with tags.
Tags should be defined within YNH to help internationalization. So which list of tags is comprehensive enough? Perhaps from other projects?

Then extend the manifest to add the tags?

Finally we should perhaps extend the community and official json lists to add tags, or have some sort of manifest.json parsing (if not too heavy given the number and diversity of repositories)?
This idea of an “appstore” from heyyounow is interesting

Thanks

8

sorry for late answer: you may use YAML, would it be easier? https://www.freedesktop.org/software/appstream/docs/sect-AppStream-YAML.html#spec-dep11-example

9

Well, we already have json files for the manifest so bringing YAML here will only brings a small value (YAML being a superset of json) and would require much more work than simply adding a new entry in the manifest.json.

For reference YunoHost • index

10

I’ve same opinion of Bram.
I not sure that migrate to yaml brings us a real advantage instead of json.