What’s interesting with attributes is that the file doesn’t need to be a binary.
Unfortunately, for different reasons, people tend to install another browser quickly and are missing bookmarks in Web+. So, we could have an help section (Something really simple, so restricted to Haiku itself) with well chosen bookmarks & docs. For example, we could have a bookmark for quick tour and another for an help page explaining ‘How & where to report a bug’.
1 Like
they are on the desktop in releases 
I know but people only have a quick look at these before sending them to trash to have a clean desktop…
How does it currently work: the buildbots get triggered by a new revision of a recipe and create a HPKG, hand it over to HDS which looks into its .PackageInfo file for the SUMMARY, DESCRIPTION, HOMEPAGE etc.? If so, there’s no provision for a CATEGORY, let alone assigning different categories to a number of binaries in the package.
That’s correct; there is currently no mechanism for the category to be carried in the HPKR / HPKG.
I don’t think using the same tags in HDS is neccesarily a good idea.
It would be interesting to know why you think this?
Indeed, for example the Qt development packages install a few tools which might reasonably go in separate categories, for instance.
This is a good point @waddlesplash and @humdinger. Do you think the “scriptlet” (I am unfamiliar with this) can be machine-parsed so that HDS could read this in or is it just a shell script that could be in any structure? Could the category instead be added as an attribute to the application binary entries within the HPKG; in which case it would presumably be easily machine-readable?
The problem with adding the categories to the HPKG files in some way like this is that the categories are “locked in” and unable to be reworked or adjusted later. At the moment, the system of categorisation can be re-designed / re-worked in HDS and the change will take “immediate” effect in the web and HD. In contrast if I have an old package which was categorised in 2014 as “Art” but we’ve since change that to be two categories “Painting” and “Vector” then there is no easy way to retrospectively re-categorise those older packages. Maybe this is a problem that can be accepted?
1 Like
The latter two points maily, for one packages in HDS only have one category. And for another I’d like packages to be in severall in deskbar if applicable, with a leafed structure.
So Art/Vector in your example instead of just art. I don’t think it makes sense to design this for hds directly as it is similar but not the same, if it works for deskbar you can still use it for hds.
As for the script thingy i think waddlesplash ment this as a line in the package build files that just calls addattr for the attributes to attach them to the executables.
That is what the scriptlet would do, yes.
Yes, I think that’s acceptable. We rebuild HaikuPorts packages for smaller things all the time.
If the categories are conveyed as attributes on binaries within the HPKR, how will the overall system ensure that one single scheme of categories is used? This could be problematic if there are multiple repositories with different categorizations?
Would you see the attribute contain “keys” such as “software_engineering”, “vector_art” etc… so that the categories are localised locally?
I think the categories used as attributes on the binaries (added manually when building or with a haikuporter “scriptlet” (similar to “addResourcesToBinaries”) in a recipe), which will be used by the Deskbar, and the categories used by HaikuDepot will be separately maintained (though in most cases identical probably).
That’s not terrible IMO. Right now, categorizing at HDS is already a manual process:
- You find a new package at HDS
- You install it on your Haiku test system
- You play around with it to determine what kind of app it is
- You grab the icon and a few screeshots
- You go to HDS and upload icon, screenshots and set the category (plus do translations, if you’re fluent in some non-English language)
Nothing really changes if there will be categories already set by attribute on the binaries. You still have to decide what categories to set at HDS, just that you now have those attributes as a guideline.
I don’t think HDS will have to change at all, other than possibly add/remove categories that turn out to be un/popular with the ‘attribute-categories’.
Those ‘attribute-categories’ will have to be decided on and maintained. I think the haikuporter “scriptlet” that sets the attribute needs to be restricted to that list of categories. No free text.
2 Likes
I think that there should be guidelines to set categories on a binary, maybe a tree or a list that can serve as reference. Otherwise, simply for a matter of wording, we will end up with multiple categories for the same thing. QMplay2 could be in video, VLC in Video, SMPLayer in videos, MediaPlayer in Videos etc
Good question!
I would think that different repos should be allowed to have different categories.
Perhaps a repo specific catalogue makes sense?
(that the apps then depend on)
Hi Humdinger – can I check; is HDS not currently capturing those icons automatically?
It did not in the past, though can’t remember when I uploaded one the last time. Because we seem to have more updated than really new apps with icons recently, and someone (diver?) often adds screenshots and icon(?) before I get a chance…
In cases where we have several binaries and different attributes-categories in a package which can have itself a different (more generic?) category, it would be nice to indicate where to find what in package description. Perhaps, splitting packages when possible will make more sense…
y’all need to sit down and define exactly what category’s will exist, and then enforce that as far as is reasonable.
it’s probably ok to use attributes, but iirc non haiku filesystems and os’s may strip them off.
reduce the size of this problem to the smallest subset of features possible. Standardize the attribute structure, and enforce 1 attribute per package. i suppose you could use hierarchical attributes to nest applications in the folder scheme, but i find drilling down folds in menus highly annoying. I’m probably not alone in this.
In this case the attributes will be added to files inside hpkg packages, so stripping them off will take some effort (and won’t happen by accident).
That being said, it could be done like icons: as an app resource that then automatically gets copied/cached into an attribute.
That’s what I just thought too!
ToDo: Use the attributes to sort the Deskbar!
Other thoughts:
1.) Do we all not use Lnlauncher and Launchbox for sorting our apps?
2.) And would be grouping the apps there would help sorting the Deskbar?
EDIT: The “prototype” is just that: instead of a “blue folder”, put a query in your deskbar, searching for all files with a specific attribute. That’s it. You have a dynamic DeskBar that auto-populates. Make as many of these queries as you want (for apps, games, etc).
Some querys could be there for reference or tutorial!?
here’s a good nested hierarchy mess.
I’m working with TI code composer writing a control system.
there’s the TI folder, and in it is has the IDE, and compiler and other tools broken into sub categories.
i think this will only really be common in development apps. Most programs have the utilities integrated, but some don’t. So in those cases, are the applications inside the group folder supposed to be categorized too, or just the main group ??
personally, i think this should be pushed to hpkg and the developer as much as possible. Also it’s probably best to have things grouped together, IE the Xiliniz dev suite etc, is all in the Xilinix primary folder
so in short, I don’t really think much needs to change. maybe just add a way to let apps create custom virtual categories “virtual folders” at file system mount and let it ride from there.
1 Like
On windows it was common practice and most installer pushed for installing the stuff into C:\Program Files\Softwarehouse_Name\Application_Name folder, and to create Start menu\Applications\Softwarehouse_Name\Application_Name folders.
Maybe i have OCD, but i always removed the Softwarehouse-Name part.
1 Like
if you have a group of applications, those kinds of fold layouts are probably preferable to the linux method of
throw everything into one directory.
on my Windows PC, it’s CodeComposer, then a bunch of applications inside the folder. i don’t see that as a problem and in all honesty, it’s preferable to most users, it’s how brain’s tend to associative sort dat anyway
"
if you have a group of applications, those kinds of fold layouts are probably preferable to the linux method of
throw everything into one directory.
"
come again?