B_OPTION_KEY, Input Server filters, show desktop, etc

Hi everybody,

So I came back to my idea of a “Show desktop/Minimize all” functionality, and discovered that there’s already an InputServer filter, called minimize_all, that does exactly that (but might need tweaking). It’s even on the Haiku main source code tree (on src/add-ons/input_server/filters), but it doesn’t seem to ship/build as default, at least with nightlies.

I’ve tried to make some changes to use the Option (Windows/Super/Meta) key + D to do that. In doing that I’ve discovered that keymaps/key functions are a mess in Haiku. If I use let’s say CTRL, everything’s fine, but when using B_OPTION_KEY (Win/Super) I can recognise the modifier, but ‘d’ gets changed to a whitespace, and so the shortcut is never triggered. Reading a little bit more I found a thread here (Stack And tile shortcuts/improvements) that points that Opt key it’s apparently used as Alt-Gr, that being the reason for ‘d’ becoming a whitespace.

At the same time, I can configure Opt(Super/Win) + D to trigger a shortcut on the Shortcuts preflet, so there must be a way to bypass that.

What would be the correct approach to do something like that? Is there some consensus in what to do with the keymaps/key functions?



My “idea” for that functionality would be to change deskbar so it stops hiding the desktop window, and make clicking it minimize all windows and give it the focus.

Currrently deskbar always shows tracker because the desktop window is implicitly filtered out.

As for keyroles the tl;dr is as I remember that an alt_gr role has to be added to properly support european keyboards.

What do you mean with d gets changed to a whitespace? If you are in shortcuts territory it should not matter at all which “character” is typed with the keymap. Anyhow, the shortcuts preferences need to be reworked at some poing.

You’re absolutely right. I was reading the “bytes” from the BMessage, mostly because I saw it done that way in another filter, but after a look at the Shortcuts filter I learnt that you can read the “key”, which in turn I did. It’s working fine now.

As it is on the Haiku tree now, it uses two different key combos (one to minimize all, one to restore), and the logic behind it it’s not great: basically, it asks the app server for every single open app and in turn minimizes it or brings it to front. That results in windows you had minimized or covered before the first press coming to front when you restore, which is obviously not expected. I’ve changed it to use just one combo (Super+D) using a toggle variable, which is an ugly hack but suits better my needs than two combos.

The right way to do it (what Windows does, and they got this right) would be:

  1. Ask the app_server about the windows (not apps) in the current workspace being shown at the moment, remember them some way, minimize all, and toggle a switch so the next key press restores instead of minimizing.
  2. In case of any window-related event (new app opening, user using Twitcher or Deskbar to bring a window to front), this switch should be toggled again to “minimize all”. This way, you can use the “Show desktop” key to show desktop/restore as many times as you want (great for taking a look at a replicant you might have on the desktop, for example), as long as you don’t bring a window to front in another way. I find this very useful on Windows and I think this step is the key for getting it right.
  1. On the next keypress, restore the windows the exact same way if the toggle was not changed on step 2, or repeat step 1 if it was changed. In any case, toggle the switch after finishing.

I have yet to find a way to a) ask the app server about the windows currently shown in a workspace and b) getting notified of any window-related events not coming from this functionality. There’s probably a way to do it, it’s just that I’m not really familiar with the Haiku code yet.

1 Like

Your aproach sounds good!

Sadly I don’t know too much about the app_server internal api to see how that info could be exposed, though adding the functionality in app_server directly may also be an option.

To be honest I don’t see the need for that when you can switch very easily to an empty workspace with already existing shortcuts.

1 Like

That was what I was thinking when I first started to look at this. It is indeed a duty of whatever piece of software is in charge of presenting the windows to the user and arranging them (what would be a window manager in the Linux world), but I’m not sure if that’s Deskbar, Tracker or the App server itself. Then I saw the code for the filter sitting there and here we are. I’ll have a look at the Workspaces app code because somehow that little piece of software knows the windows shown and their placement.

Matter of taste or habit. I never got really used to workspaces, plus switching back to the original workspace requires moving your hand to a different shortcut (I think). As long as it doesn’t break existing behaviour/functionality and I’m willing to code it (thus not taking time away from the devs) it can’t hurt. Worst case scenario I end up with a filter that doesn’t make it to the source tree but it’s useful for me (and hopefully a few others).

In haiku it is the app_server, it draws the contents of windows itself (serverside drawing) based on instructions from the applications.

The decorator around windows is also completely within app_server.

Tracker provides the file management stuff and the desktop background.

And I think deskbar only does the deskbar and “twitcher” if you switch eindows with ctrl-alt.

Personally I think deskbar and tracker do too much each. In your case I think the functionality makes most sense in app_server, that way it can be triggered from the input_server for the shortcut and from deskbar aswell when needed.

To be fair, as long as you don’t break things, I don’t mind. It’s your time after all. I was only wondering if it worth the effort…
As I said, switch is very easy. You can use different methods using shortcuts and even mouse wheel. The only drawback is that a workspace even empty cost memory.

Thanks all for your comments. I went ahead and sent a patch (which you can find at https://review.haiku-os.org/c/haiku/+/5573) to the minimizeAll filter. I asked some questions there about how to resolve certain things in a efficient manner, so suggestions and changes are most welcome, but for a first attempt is working as I expected, which makes me happy.

1 Like

For your knowledge of how some things work in Haiku: Workspaces is implemented with sort of a hack where it is a special view (identified by a private window flag) that the app_server draws, so the Workspaces app itself actually doesn’t know much about window placement.