I was wondering why the HaikuDepot has not (yet) a content taxonomy, dividing software by…well…some criteria (categories games, productivity, emulators and/or tags like SDL, Qt, etc.).
Today it’s ok to find a software you already know of.
But ports archive is growing steadily and I think this is a feature that should be discussed sooner or later.
Is there a reason on why this was not considered yet?
There is one already I think. The software has to be tagged at depot.haiku-os.org.
And the initial UI mockups which worked with categories as the main way to browse software were ignored and we got a super long list of everything (which is useless, of course) instead.
One could keep the actual clean layout but introduce filters, instead. But a tree panel should be evaluated too IMHO.
Ofc, adding elements to the taxonomies can’t be open to everyone, but to depot maintainers only
Ironically, porters have strict constrains on where to physically put the recipe files in haikuports repo, but this is then totally flattened at users’ side.
Lack of collaboration between haikuports and haikudepot developers…
Same thing for icons and screenshots, which are handled completely separately at depot.haiku-os.org when they could be in the package metadata in some way as well.
I don’t find “throw everything in a list” to be a clean layout. I think there is (or was?) a popup menu at the top to filter by categories, but I don’t think the filter approach is working well. The use cases are well defined:
It’s not like we would be inventing anything here, I mean, that’s basically the design of BeBits/BeBytes, of the Android App store (currently with a popup menu for the categories), …
None of them think “oh we’ll just list thousands of apps in a long boring list, that’s totally great!”
I totally agree.
Where/How we could eventually discuss to understand if this is somewhat to put in a roadmap?
I’m probably not understanding something, but HaikuDepot does have a drop down box for Category.
One thing I would like to see is a tab (along with Featured and All) that shows newly added packages and, maybe, a New Updated packages tab. Might give a good reason for more people to create an account and log in.
It has, but since most of the packages has no metadata there, the lists are (usually) incomplete, while the taxonomy is very poor anyway (there are a dozen of categories only)
Ah. I never noticed. If they were open to being able to change it, this could be a community driven thing.
I was looking for something like that (didn’t know the word for it, thank you). Would this be like a tag cloud or something else?
I was misunderstanding the term thinking it would allow setting a disposition on the current state of a package. Example: Reason a package has not moved forward. A disposition to assist in identifying a requirement to build or modification to a dependency.
I was working through the dependencies for building Icecat. I could set the disposition that says 5 libraries are outstanding, and did not have expertise to resolver.
Most packages are libraries and other dev-related things. Developers know the names of the components they need to code or port, so it was decided those should not all crowd the “development” category (or worse, audio/video/game categories when they are specific to the development of those aspects).
I don’t feel we need many more categories, as they tend to be increasingly bad to define neatly. Personally, I still struggle with “Productivity” and “Business” on occasion…
We had a few runs in the past GCI programs to have students submit category, icon, and screenshots for packages that still miss those. I really doubt that many apps are missing this meta data.
People that are really interested to continuously keep things uptodate can join the HaikuDepotWeb mailing list. They can earn perimssions at HDS to fill that meta data. Even CSV lists can be ex-/imported to find out which packages lack category/icon/screenshots.
I can also add that meta data, if people create a list.
In any case, I don’t see what’s not to like about the categories menu in HaikuDepot…
resurrecting an old but important thread here, but can we please extend the HPKG spec from 2013 to include Categories and store them also in Application attributes so Deskbar can filter/query them to build a nice dynamic menu structure? Let’s use the power of native extended attributes and queries here, please.
After checking out some apps from HaikuDepot, I get a flat Applications menu that’s completely useless and fills the entire screen height…
Same goes for Preferences, btw - there’s no need for a overloaded “SuperPreferences” app, we just need a Categories attribute (yes, one or more so users can find them in different ways), and then have the preferences menu populate a structure based on queries for this attribute (and possibly a meta attribute to denote it’s actually a Preferences app).
Just for the heck of it, I’ve tried this out (with a copy of the prefs apps since they’re package-protected) and this is how it could look like…
Just a reminder : I already started something about it but it seems nobody looked at it yet.
that seem very good… 
The HPKG spec does not need any change for that. The attributes should be stored in the executable themselves, not in the packages. So it’s “only” a matter of going at haikuports and adding some “addattr” command to all recipes to set the attributes.
For preferences, I think the current goal is to merge some of them together:
I think it would reduce the number of menu entries sufficiently.
ah didn’t know, that looks exactly what I was aiming for, could you update your changes for a PR to Haiku/Deskbar?
…so maybe it need make some standard and formalize it … so we can follow that rule and update the recipe
How are you envisaging these categories added to the binaries are going to work with HDS and it’s database and APIs? I’d be interested to hear the overall end to end plan here?
None of them think “oh we’ll just list thousands of apps in a long boring list, that’s totally great!”
For the purpose it is intended I don’t see anything broken and I don’t find it surprising or difficult to use at all.
You probably know better than me how it could work on that side 
. I don’t know if it’s acceptable for HDS to scan the content of the hpkg and find the file attributes in there, or if you’d need them exported somehow in an easier to use format, and who could do the exporting. I guess it makes sense to have the same categories used both in HDS and in DeskBar and not have two independant things here.
I guess it makes sense to have the same categories used both in HDS and in DeskBar
That would very helpful. See pkgCategories in here for the current list of codes used;
curl -L "https://depot.haiku-os.org/__reference/all-en.json.gz" | gzip -d | jq . | less
I don’t know if it’s acceptable for HDS to scan the content of the hpkg and find the file attributes in there
HDS currently scans the HPKR binary. If the categories could indeed be included there then that would be the least difficult thing to do but creates the risk of a data anomaly if the HPKR is different from the attributes stored elsewhere. Otherwise are you suggesting that the attributes would appear in the ELF binary file inside the HPKR?
They would appear as filesystem attributes for the application, inside the hpkg file:
https://git.haiku-os.org/haiku/tree/docs/develop/packages/FileFormat.rst#n449
So, no need to examine the ELF file itself. I don’t remember enough of the details of the HPKG format to see how hard it would be to access these attributes