Is there an entry in the HPKG for this? Or how does HaikuDepot sort the categories? If that is possible, I would have to include this information in my HPKGCreator.
If not, how is this maintained?
1 Like
how to take the categories of haikuDepot into the Deskbar?
i see all application links in the directory named âapplicationsâ.
can i add sorts of subdirectory just like the categories of haikuDepot ?
run some command , lauch the script or cut-paste by myself?
mmm, i see.
but can i create some subdirectory in the directory named Applications by running sorts of script , even by default?
it seems very regular at haikudepot.
just like:
after i install the application from haikuDepot-Category"Video"-SMPlayer , its link will be in Deskbar-Applications-Video-SMPlayer , not in Deskbar-Applications-SMPlayer .
and it is auto , no more hand movementă
is there such the script?
I think there is a YAB BASIC script on Fat Elkâs repo. But if its like I think, you have to arrange it manually.
Thereâs a 3rd party app that can help you with the manual sorting of the menu. Itâs from the Besly repo.
https://besly.de/index.php/system-tools/menu-sorter/menu-sorter
1 Like
i see.
thanks.
but , i really want it become the native function in haiku with auto-script by default.
just like the categories of haikudepot, it is very clear and regular.
2 Likes
I think about this for my Menu Sorter too, but you can not get the cathegory information from the package, so this is not doable at the moment.
Tutorial: Menu Sorter
I would like to have (optionally) a categorized menu, can we script this? or is there no way to get the category info from depot?
In my opinion, you can not get the category. If I knew that, I would have built that into the little tool.
If thatâs the case, Iâd love to include it.
Maybe it is just me, but âlets script thingsâ smells too unixy for me. We could use the force of BFS and have some extra category info as attributes. Why not just query for the attributes and show them in the Deskbar menu?
And if we are already here, we discussed this topic plenty times, but nobody answered, what kind of categories should we have? Do we need a hardcoded or a dynamic list? What if an app fits into more than one category? And what if a program doesnât fits in any? Why do we need deskbar menu at all?
It seems nobody reads the forum archive, however the search button is available for everybody. Still, some users only gets that far âOh, i donât like this and that, lets switch to write-only mode, ignore all the previous discussion results and outcome and open a topic about this effectively resetting the subject to zero.â
So we are right now at that stage that we ignore the previous questions and instead lets hack a unixy script which will iterate trough the packages, fetch their infos with repeated http requests and will try to coategorize stuff?
1 Like
I took the liberty to unify these latest two concurrent threads on software categories.
That would be my idea as well.
The categories available through HaikuDepot are maintained at the HaikuDepotServer (HDS). Together with translations, icons, screenshots and if they are âfeaturedâ. User ratings and comments are also stored there.
Iâm not sure where HDS is hosted, but I imagine itâs not on a server running Haiku. Therefore, if we want to store category (and possibly other information) as attributes, they cannot be added directly at HDS to the HPKG packages.
It has to be done locally then. The HaikuDepot app and the pkgman command can request the info from HDS and add a category attribute to the HPKGs they have downloaded. If you have a âside-loadedâ HPGK - maybe directly downloaded with a browser from the HDS site - the package_daemon could request the category info from HDS if the attribute is missing when it is installing the HPKG.
The category attribute, say HPKG:category - could contain several semicolon separated categories. Apps can be in several categories after all.
The second step is to change the Deskbar to make use of those attributes. Maybe a setting in the Deskbar preferences, âApplication hierarchy: manual | flat | categoriesâ.
âManualâ would be leaving all up to the user - whatâs now described in the User Guide.
âFlatâ is how it itâs now.
âCategoriesâ is using the mentioned categories as subfolders.
3 Likes
But it would lead to longer loading times, since the attributes would be reapplied at every start. Doesnât make sense in my opinion.
If every HPKG had the corresponding information in Package.info then it would be easier.
Should be extremely fast, like every query for indexed attributes. As attribute of the HPKG, we also have the charming possibilty to be user-editable.
Why so complicated?
Adding the categories to the Executable that is inside the package should be fine? and then querry for that attribute
I donât think the vague categories of hds are neccesarily good for the deskbarâŚ
Iâd rather use a flattened BMessage for the category info than a comma seperated string or so, but that is just the specific data format to pick.
The problem is that not every package has an executable file. Also, how is the system supposed to know which is the executing file, because there is no requirement that it has to have the same name as the package. No, the other idea is safer.
The best way would be an entry in the package.info file, because only if the program writer or package creator names this, it will be added to a category, i.e. maybe in a menu sub-item at the end. But this would require changing all previous pakages and no one dares to do that.
This is easy with the externally created packages, which e.g. were created with my PackageCreator, because there you can create a subfolder directly in the menus and place the link here (some have already done so, unfortunately not in accordance with the system guidelines), since there is no specification for it at the moment.
The first step in this direction should perhaps be this determination. What subfolders should there be anyway? what goes with what? Then the package creators can stick to it.
I would e.g. donât want to put the Games in the Applications menu, but would like to have a Games folder next to Applications, as this makes much more sense and would make things tidy (even children would then find what they wanted faster 
).
If it doesnât have an executable then it doesnât belong in the deskbar.
The system knows precisely because of the querry, this wierd way of post processing packages adds a huge deal of complexity for what seems to me a small gain, especially with the other way around beeing much easier.
We donât need subfolders, we donât even need .desktop files, seperate icons, even ressources can be added to the executable⌠so why start with something as small and simple to implement as tags?
Itâs in the simples incarnation just a string atribute on the file!
Also this solution completely misses that not everything has to be packaged.
Iâd rather not have to package locally compiled stuff to work around a such a wierd design.
1 Like
But we now have the package management system and the virtual packages. Attributes are ok, but have to be reset every time. Anyone who has many programs installed will notice this (unless they have a high-end computer) when they start up.
I still think subfolders are nice, because an endlessly long list of programs is very confusing. Of course you can do that using search options, but that would be too cell phone style for me.
But youâre right, with locally inserted programs (non-packaged) the whole thing becomes even more difficult if you donât pack them in an HPKG beforehand.
And if you want it there, you can still put an attribute on the file.
What is the problem here? Really, listing all files with a specific attribute should be very fast, just as fast as listing a directory, if the attribute is properly indexed. In fact it would probably be faster than the current âblue folderâ solution, which needs to query several directories and not just one.
2 Likes