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.
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:
Either you search for something, and for this the main widget should be a big large searchbar (think of the Google homepage), not a small one in a corner
Or, you want to explore and discover things, and in this case, we should have a list of categories which you can click through
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’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.
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…
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:
Time and Locale
Input, keymap and shortcuts
Maybe backgrounds, appearance and screensaver
I think it would reduce the number of menu entries sufficiently.
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 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?