2 more options would greatly improve usability:
single click switch to application window when single app window exists. Pointless to force 2 clicks (deskbsr selection of app, then 2nd click to select single window).
an application launching icon. With some long loading apps, there is no indication something is happening.
Loading indication is a task of application itself. If application launching takes a lot of time, it should show splash screen, dialog with progress bar or something like that. Deskbar donât know that application is loading and there are no API for that.
Deskbar subscribes to BRoster::StartWatching(), but BRoster notifies client at ReadyToRun stage, not at BApplication constructor stage (which would be the feature request). There is opportunity to insert a message sooner, however there is the problem that the appâs BLooper hasnât started yet (via Run) so to avoid nastiness BRoster delays informing subscribers. Regarding displaying loading screens, that would require more work for application developers - you wont always get that (or will rarely). Displaying a loading icon would benefit the user from lazy app developers.
I moved this thread to a new topic, because itâs not about the current Deskbar options. In fact, those suggestions would probably not end up as options, but simple default behaviours.
This. Both of these options would definitely add more goodness to the Deskbar 
Most applications start instantly. If application is so complex, that it canât start instantly, adding loading screen wouldnât be difficult comparing to application logic. Microsoft Office, Teams use loading screen.
Apps should start instantly. If they donât, blame the app developer and let them deal with the consequences 
QuickLaunch is pretty full-featured, I donât know that we need it in the base system. Instead, I think Deskbar should have a filter box, which behaves similar to Tracker typeahead filtering or the old Windows start menu search: it just filters whatâs in the Deskbar menu.
Iâm wondering how much of deskbar, as it is now, makes sense to keep. When it is on the bottom of the screen for example it looks like a windows taskbar but behaves very differently, a single click doesnât focus the app ment but instead opens a context menu, to me this feels very inconsistent.
Iâm also wondering why âexpand new applicationsâ is not on per default for new installs, without the app list in deskbar seems pretty pointless. Maybe I am missing something though.
I mostly agree. Now that Iâve straighten Dockbert up a bit, I keep the Deskbar hidden all the time and I use it mainly for the replicants and for those few items missing from the Haiku menu in Dockbert.
Iâd like to see the Deskbar evolve allowing the user to:
As a matter of preference, I also would love to be able to detach the taskbar and put it on the bottom while leaving the leaf button and the replicant shelf on the top (tell me you are a Mac user without telling me you are a Mac user 
)
Perhaps type ahead filtering would be handy when navigating with keyboard but it would not be convenient when using a pointing device. I fear that we need that menu sorted anyway.
Inconistent with what?
Windows has borrowed this feature from BeOS since Windows XP, but enables it only when there are 3 or more windows of the same app.
The idea is that there are applications, and then each application has a list of windows. Maybe you want to access just one window, or maybe all of them. Doing âall of themâ by default would raise a lot of windows to the top, and maybe destroy your carefully laid out Z-Ordering (especially if you use focus follows mouse and donât always move the active window to the top). So, first you select an app, and then you select a window inside it.
The alternatives would be:
It behaves the same when DeskBar is vertical (and you donât use âexpanderâ mode). So itâs consistent with itself, and also with some version of Windows in some cases.
I already wrote it above that line. using a left click there opens a menu that looks like a context menu instead of on right click.
In the horizontal mode I donât even know how to get to the list of windows in an app, and in vertical mode, by default, there is no way to have a click target to focus a single window, or focus âthe appâ which would focus one window o r many.
WebPositive has usually one window for me, preferences only have one etc. Especially for those having the minimize all option available, looking like a context menu, by default makes no sense to me. I expect left click to perform an action, and I expect a left click kn that list to perform an action becausethe entries look like buttons.
The entires beeing called Hide all doesnât help much either for me.
You click on the app and you get a menu with all its windows (and a few global actions). Same as in vertical mode if you donât enable the expander.
It is not a context menu, just a normal menu, like in a menu bar. I think this is a well known UI element for several decades now?
Not very different from having âSelect allâ in an Edit menu in a menubar, even if your text document contains only one word or nothing at all. Having the menu being always laid ou the same way seems better than having it be different depending on the number of opened windows.
I donât really like it and I use the Expander mode myself. But I donât see how it is inconsistent, on the contrary, it is behaving predictably and always in the same way, no matter if there is one window, or mutiple windows, or even no windows at all.
There is room for improvement there, of course. I think there are tickets about allowing apps to add custom things in that menu for quick access to common functions. Maybe you could have a âNew text documentâ entry directly in StyledEdit deskbar menu. Maybe the media player could have play/pause/next track buttons quickly reachable there without having to go to its window. Maybe for apps that have a single window, the entire main menubar of that window would be replicated there? There sure is opportunity for experimenting.
My point is that it behaves inconsistent with regards to the rest of the OS, not with itself. The entries look like buttons, in my mind they should do something on their own when pressed.
I donât know of other UI elements in Haiku with a similar or same appearence that behave the same way.
They are drawn using a button background, but when clicked they open a menu.
This is the same as BPopUpMenu or BOptionPopUp, except these have a small arrow at the right to more clearly indicate that there is a popup menu when clicked.
Maybe the more subtle gradient of BMenuBar could be used instead, Iâm not sure how it would look.
Anyway, yes, maybe itâs just a slightly non-standard widget, but think of it like a menu and not like a button. We can make the look match that.