Well, I think the docs do answer what the main set of Haiku applications do. But a getting started box like the one you made would definitely help for sure.
Iâve used Linux distros where they try to give every application an âintuitiveâ name. The result is that you have a bunch of applications entries in the menu like:
- âWeb Browserâ (Which? Firefox, Qupzilla, Chome? Epiphany, Opera?)
- âText Editorâ (Gedit? Kate? Leafpad? Notepadqq?)
- âDrawingâ (Kolourpaint? Krita? Gimp? Inkscape?)
- âMoviesâ (Totem? VLC? Mplayer? SMPlayer? Kaffeine?)
I donât find these âintuitiveâ names intuitive at all. They always create more, rather than less, confusion.
1 Like
Better would be like in old Zeta times to have a more detailed Application menu with cathegories: Painting, Office, Media, EditorâŚ
Indeed, a few categories would help once people install more apps, because otherwise they would have to scroll through a long menu.
And if Haiku would implement some of the FreeDesktop specifications, that would be of great help for the developers, with so many already knowing how to handle these:
Why did you wake up the dragon? 
1 Like
In a pre- package manager era the modification of start menu was a matter of creating a few folders and populating them with relevant links. Today the package Haiku has this stuff in a read-only place. And if I remember it correctly, somebody started a tool for this issue.
Still configurable, see User guide on Deskbar (esp. the info box under âMenuâ).
A more user friendly way with a GUI, e.g. in the Deskbar preferences would be nice, but nobody took that on yet.
1 Like
Thatâs merely a hack. The specifications I mentioned would make things much simpler. It would be awesome to have those implemented. Are you familiar with them?
My answer was intended for alpopa.
Itâs not a hack, but intentionally coded to work like this.
Categories arenât universally adored either. There have been discussions about this on the mailinglist over the years, but no consensus was reached, IIRC. As itâs not in the R1 focus, decisions have been postponed.
2 Likes
I agree that currently there are much bigger priorities than categorizing the menu, but ultimately it has to be done because it makes the menu more manageable after we install many programs. It also makes it easier for people to find the software they need. And using some existing standards it could be easier to figure out a way that also helps other developers. Thereâs even a very nice menu editor for these specifications, that could be ported to Haiku - MenuLibre:
Porting is not the best synonym.
Do we need a dedicated menu editor? It should be enough to allow the user to add, remove and edit menu entries by right-clicking in the leaf menu. This looks like a very over-engineered solution to a Linux-specific problem (multiple desktop environments).
Itâs more than meets the eye, not just a way to make multiple desktop environments play along. The benefit of the FreeDesktop menu and desktop entry implementations would be the automated management of the menu.
The implementation relies on a directory which stores the desktop entries for the programs, it reads them all and automatically categorizes them based on their internal definitions. So the menusorter that @lelldorin mentioned is great right now, except that you have to know which program does what, create directories and move shortcuts manually.
But if the .hpkg files already contain the desktop entry files, the Deskbar could automatically categorize them. And when a there are changes the content of the desktop entries directory, a menu update can be triggered. I donât know how the GNU/Linux distros detect this, but it just works. I guess the window manager or another program monitors the system calls for changes in that directory.
The bottom line is itâs a nice way to take care of the menu. The menu editor itself isnât a necessary tool, unless the menu cannot be edited otherwise with a GUI.
There are some people who include a cathegorie menu folder with the menu shortcut at installing there apps (bbjimmy and clasqm), but i think like you this should be a defined way and not every one do as they like. This need to be a part of the must define options of a hpkg. But the developers have other things to do, and does not take the time for user related stuff at the moment.
Haikuâs package recipes already have a line that creates a shortcut in the leaf menu. How else would a new shortcut end up there when you install an application? All you would have to do to make it more organized is modify that one line and add, say, the word âofficeâ for office related recipes.
Also, I can see a downside to adopting the FreeDesktop menu. Right now on my Linux system the menu is completely chaotic because I sometimes use Wine and it puts all sorts of things in the menu. There are a total of 6 Wine-related âcategoriesâ and they canât easily be removed: https://i.imgur.com/urBk5Um.png
Also, some of the other categories donât make sense either. Whatâs the difference between âOtherâ and âSundryâ? Whatâs the difference between âSystem Toolsâ, âSystem Settingsâ and âUtilitiesâ?
According to the Recognized desktop entry keys page, the only required values are the following:
- Type (string) [Application | Link | Directory ]
- Name (localestring) Specific name of the application
- URL (string) If entry is Link type, the URL to access.
So the way the menu looks depends on the implementation. Haiku doesnât have to do the same mistakes as others.
About the categories:
- System Tools can hold a backup tool, a maintenance app, etc;
- System Settings = programs capable of changing the system settings;
- Utilities can hold whatever doesnât fit in Multimedia/Office/Internet/Games, which could easily be merged with Accessories. But at least these make sense, unlike the 7-zip/KORG/Sundry categories - thatâs a sign of a weird implementation of the menu specifications. A single âOtherâ is more than enough for anything that doesnât fit anywhere else.
With a simple and strict implementation it would be up to the app developers to decide which category they want their shortcut listed under. With the categories defined, the users would have a consistent look of the menu, which would be the same for everyone.
It makes only sense then the structure of the menu are a part of the hpkg. My tool is only a dirty way.
For backup solutions are the hpkg files need to include all informations, so you just need to store the packages as backup and the settings.
WRT categories for apps, Iâd prefer to have complete control and not having to rely on the choices of developer or packager.
When I install a package that wants to put a link into the Deskbar, Iâd like to have a window pop up that allows me to choose what to do. Either not have it in Deskbar at all, or let me choose a category from a list of pre-defined categories, or create/use my own custom category.
The package (or the data provided by HaikuDepot) may include a category suggestion that presets whatâs shown in the window I imagine.
The Deskbar will then also need a âAllâ subfolder, that shows all apps independent from their categories, i.e. how itâs currently done since BeOS times.
The categories can be stored as file attributes. Then the category subfolders can be implemented as queries.
All this is post-R1 stuff.
1 Like
Thank you! Definitely will use this.
I would rephrase it a bit: âThe main disadvantage of the FreeDesktop menu and desktop entry implementations would be the automated management of the menu.â I like to have control on menu. I like it much more the Haiku way.
The Menu Editor is a very simple tool that obscures (pardon, abstracts) the access to the menu structure. All its actions can be easily done in GUI or in Terminal exactly the same way, with the same difficulty and much more flexible. For example, did you ever use Wine in Linux? You can install Windows programs, and they land in menu, but only for the current user. Then you uninstall them, but the menu entry doesnât disappear. You have to know where the configuration is, how to reach it, what to modify and pray to make no mistakes, so the menu is still consistent. I doubt the Menu Editor can help much here.