Automatically categorizing apps can have its own drawbacks in the future.
Some people might want to have a bunch of apps in the same folder (like me).
Plus, it creates an additional “pain in the ass” for 3rd-party repo maintainers.
Out-of-the-box functionality can be an advantage, but sometimes it is better to just provide users with an ability to tailor the system in accordance with their own tastes (which are different).
I believe that menu is good the way it is now. Especially when we have such an awesome documentation.
Looks like all that experience sorting out the BeOS archive could come in useful here. Though would those categories be as useful if people only have a few dozen items in a menu rather than hundreds or thousands?
Like you said, having the same categories (tags or whatever you call them) also show up in HaikuDepot for the packages would be good.
For bonus points, tag the thing (application executable, documentation file, etc) that should be in a menu with an attribute that lists the categories it is in (more than one would be a nice feature) and automatically generate the menu from the attributes.
This is absolutely necessary. I have a partition for testing purposes with every available end-user HPKG on it that doesn’t conflict with something else.
For the last year, I have been using the existing categories on HaikuDepot for all apps on my repo.
Internet and Network
Science and Mathematics
System and Utilities
Since that classification is part of HaikuDepot and the Web app, that system must have been officially decided upon at some stage, but if it is officially changed I will update my packages (might take a while, but I will) I think Games can be subdivided further. It still scrolls off the screen. As you can see in the screenshot there are some unofficial additions to the deskbar from apps like Quassel and Exult - Hey, those aren’t my ports. And when you look at the non-classified apps, you only get to B before you start scrolling. And scrolling. And scrolling
A menu system that works perfectly with 10-20 apps just does not scale when you have hundreds of them.
One problem here is that Deskbar seems to pick up its sorting prefs from Tracker. These standard subdirs work great if you have set sorting in Tracker to set directories before files, as in the screenshot. If not, not so good. But at least you don’t have to scroll the deskbar for five minutes to find your app.
There is a weird workaround where you delete a directory and make a symlink that will let you rearrange your Deskbar manually. I suppose Lelldorin’s app makes use of that - sorry, I haven’t had a chance to look at it yet. It is not clear to me if that would survive a system upgrade.
I like agmsmiths’ idea - it is the haiku way of doing things and would probably work better with internationalization.
In BeOS there always was a problem with not structured data going to chaos. To resolve this we need force some structure on it.
In menu and software categories, I think, that it must work in this way:
in the web there are tags and subtags, and in Haiku FS attributes and subattributes.
Every software has its place in attributes and subattributes tree (in web is tags and subtags), like this:
Taking the hint from MIME type attributes combined with damoklas’s list of categories, the category attribute (call it “META:category”) would look like a path name: “system_files/drivers/audio” for one category example.
To make it work with multiple categories, I’d have them stored as comma separated values in the attribute string. For example, an audio driver that talks could be “system_files/drivers/audio, audio_tools/text-to-speech”. However, this would slow down BFS queries to find all things of a particular category since the indices don’t handle multiple values (except in the experimental AGMSRAMFileSystem) and it would have to search through them all to find items in a particular category.
An alternative would be to have an attribute named for each category, like “META:tag:system_files/drivers/audio” with a dummy value of a boolean (set to true for consistency). Then if there was an attribute index set up for each category, you could find all audio drivers using a query. The downside is that there would be dozens if not hundreds of indices on the hard drive (created if necessary when you install the related app), and it would be hard to enumerate all category values (listing indices would work).
A third alternative for having multiple categories is to have a symbolic link pointing to the executable with attributes on it for the alternate category.
Or just not have multiple categories.
By the way, does the package file system support BFS queries? All this won’t work if it does not have queries (and be slow if it doesn’t have indices).
I don’t know if the virtual directory system would support that.
But maybe use a real directory tree of categories, like the MIME database in /boot/system/data/mime_db (have a look, see if you can find text/plain for example). Then have symbolic links in that directory tree to the actual executables or whatever file the menu item is about.
Either way, you’d need to change the deskbar menu code to use it as its source of data. Though if it is a real directory, that would be easier (just move the symbolic link it uses to find the current menu directory tree).
So, if we don’t like the standard Deskbar folders, we should agree on an alternative directory tree root location and use Damoklas’s categories for the structure. Package builders should identify their category as a symbolic link in the alternative tree when they build the package. Then just change the Deskbar symbolic link to point to that alternative root, and presto, it’s using the new categories.
Or have both. Beside the Applications menu item, add the Category tree root folder. I suggest naming it /boot/system/data/deskbar/menu/Categories
I think better put sorted apps in Applications, categorization can be optional (a corresponding entry in Deskbar settings). New “Categories” entry in menu feels like overdose.
…After all, I think to be good, that package builders as standard must include optional symbolic links of app also in Deskbar Applications (not sorted), in main Deskbar menu and on the Desktop.
I suggest these categories in Applications (Deskbar menu):
Games (with optional subcategories)
Internet & Network
Sciense & Education (or, maybe, Education just subcategory inside?)
“Games” subcategories (optional):
Also, maybe, is worth to have optional subcategories in other categories to.
… and more links to make for hpkg makers… or system can do that by self?
This is a great idea that has needed done for a long time! It’d definitely help clean things up in the Leaf menu to do this.
As an extra suggestion to this one, maybe to prevent it from looking like how the unwieldy list of folders and programs used to get in Mac OS 7-9 (or Windows 95/98), Haiku might consider adding in a category or tag manager like the Menu Editor frontends in several desktop environments? It’d just be a suggestion that could help users and packagers wouldn’t have to deal with so many tags, since people could just make or define their own.