Caja Navigation and HUD

A nasty problem for keyboard navigation (especially in Caja) came up recently in 18.04 Daily and I’m glad I did some new-feature reading and was able to locate why.

In Caja, the quick keyboard navigation makes use of ALT, mostly combined with Arrow keys. But it was a frustrating fight to get it to work and took several hits before it did anything. I could see slowing down helped.

Enter HUD which apparently uses the ALT key and a 250msec delay. BINGO! Disable HUD in Startup and Caja is its old friendly self again. It’s just a battle for the ALT key. :slight_smile:

Hope this helps someone else.


@vkareh Anything we can do about this?

@Wimpy - Yep! I can update mate-hud to whitelist the caja shortcuts (<Alt>Enter is alread white-listed for file Properties).

From what I can see, these are the shortcuts that need it:

  • <Alt>Up
  • <Alt>Down
  • <Alt>Left
  • <Alt>Right
  • <Alt>Home

@Bill_MI, are there any others you know about? (good find on this bug, btw, I wasn’t even aware of these shortcuts!)

Since they are hard-coded, this should be easy and I don’t think it will interfere with other applications. I’ll run some tests to make sure there are no regressions.

In the meantime, you can still access those shortcuts by double-tapping the second key while still holding down <Alt> (e.g. <Alt>Home+Home)

edit: Added <Alt>Down to this list.

Hi @vkareh, Thanks to you and @Wimpy for taking notice. If I discover any more I’ll pass it along.

I must admit “whitelisting” certain combos concerns me. Is this for only Caja? At the algorithm level, isn’t ALT down/up within 250msec and nothing else the HUD trigger? I don’t see how whitelisting fits in.

One thing comes to mind is pull-down menus accessed with ALT with the underlining scheme. This can be almost any character in any app.

Thanks again!

Hi @Bill_MI, maybe whitelisting is not the correct term. Maybe “allowed for replay” is more technically accurate. In any case, there are two types of key bindings: global and application.

Example of a global one is Alt+Tab. The root window is always listening to it regardless of which window is in focus.

Example of an application binding is Alt+Home in caja. The root window doesn’t know nor care about it, but caja is listening to it.

The HUD registers Alt in the first category, since otherwise we would need to add a new HUD to every single application. Now, since Alt is such a popular key, there are many bindings that use it, but the HUD has dibs on it, so whenever you press it the HUD reacts to it and grabs and locks the keyboard entirely (this is normal key binding behavior), then it just eagerly waits for those 250ms for the key to be released.

If the release happens next, and is within the 250ms delay, the HUD shows the menu and releases the keyboard lock for other inputs to happen. But, if another key is pressed before the delay ends (or even if the delay ends before Alt is released), HUD needs to decide whether to let the event through asynchronously, or replay it for the benefit of the application in focus.

Global key bindings (Alt+Tab) should be let through, as the root window is already aware of them being captured and things proceed as normal from there.

Application key bindings, however, were never let in on the fact that Alt was already pressed before someone else (i.e. the HUD) grabbed it, and so the event of “pressing the Alt key” needs to be replayed in the event queue so that they can see it. Here’s where things get fun. The HUD doesn’t know which keys belong in which category, but there are some clues: each keyboard layout has an internal map of keys that are used for input (a, b, c, etc.) and some that are used for controls (arrows, F1, Ctrl, Tab, etc.)

Usually you can just replay the former and let the latter through asynchronously, but things get dicey if you have an application that uses control keys in their bindings (i.e. caja with Alt+Home). That’s where the replay whitelist comes into play.

Since Alt+Home is (afaik) hardcoded in caja, you can’t really use it as a global key binding anyway. So replaying it is a good idea so that caja (and potentially other apps) can use it. Now, you also mentioned the pull down menus (I’m assuming that you mean the File, Edit, etc menus). Those are handled through normal input keys (e.g. Alt+f for File) which are already in the replay list. That means that these are not affected, we’re just adding new keys (home, left, right, up, down) to that list.

Note that this list is only used inside the HUD when used with the Alt key. If you change your HUD key binding this list is ignored entirely.

Hope this explains it :slight_smile:


Fantastic! :thumbsup: Thanks for taking the time. I had pictured something totally different like a buffer dropping events.

I’m betting this is related to the underlines not appearing in application menus when ALT is pressed? Caja and Pluma fail to do this only with HUD enabled. This is an old staple where ALT underlines the “File, Edit…” keys to pull them down.

But it does raise a question. Since HUD can’t know every app that uses ALT shouldn’t all non-modifier keys be in that list?

@Bill_MI - to put all modifier keys on that list would mean that when you do something like Alt+Tab, you will get proper window switching, but also whichever window had focus will get a <Tab> character sent to it.

There was a discussion about this a few months back, where we finally figured out the replay whitelist as the best solution

1 Like

@Bill_MI - good news! This fix was just merged :slight_smile:

Keep in mind that it’ll need to be tagged for 18.04 release for it to be available, but the fix is in

1 Like

I released this a couple of days ago.

1 Like

It’s working well and transparently in an updated 29Feb ISO. Thanks @vkareh and @Wimpy!

1 Like