[Tracker] some shortcuts doesn't work

[diver]

For example Alt+n works in desktop, but if you open Home folder it will not create a floder.

[axeld]

Could you have a look at it, Stefano? What obviously happens is that the menu item shortcuts in the submenus aren't set. It looks like BView::AttachedToWindow() is not called for submenus before they are actually shown on screen - unlike R5.

[jackburton]

Ok, I'll have a look.

[jackburton]

I had a look, and I don't think your diagnosis is correct. Alt-N doesn't work in any tracker window, unless you click once on the menubar, but it works even if you click on the empty space in the menubar. I think it's more a focus or target problem. Might be app_server or BWindow related.

[axeld]

No, there is no shortcut created for the window. The key down message comes in (that's why you select an entry starting with "n" when you press the Alt-N shortcut). IIRC the BMenuItem shortcut is added in Install(), and that's apparently *not* called before.

[jackburton]

I investigated it a bit, looks like tracker' ContainerWindow enables these shortcuts in UpdateMenu, called from MenusBeginning; that's why shortcuts work once you click once on the BMenuBar (BWindow::MenusBeginning is called, then).

ContainerWindow::MenusBeginning() has this interesting code snippet: if (CurrentMessage() && CurrentMessage()->what == B_MOUSE_DOWN)

don't commit active pose if only a keyboard shortcut is invoked - this would prevent Cut/Copy/Paste from working

So, apparently, MenusBeginning() could also be called when a shortcut is invoked , or at least, not only when menus are opened.

[axeld]

Okay, that could even make some weird sense :-) Thanks for having a look into it, I'll add MenusBeginning() & MenusEnd() calls into the shortcut processing, then - that should do the trick.

[axeld]

Thanks Stefano, that did the trick! Fixed in hrev18338.