pharo
pharo copied to clipboard
RubTextEditor: Bind the MENU key to open the context menu
Fixes #11658
- Adds an additional key binding to RubTextEditor, binding the menu key (≣) to the context menu
KeyboardKey class >> menuis also added to facilitate further bindings elsewhere in Pharo later
I have no effect in Windows 10 x64. I made the changes manually. Whether it is necessary or not, but the KeyboardKey class >> #initialize I called just in case.
@NSUSpray Interesting. Did you try it on a new edit window? Changing this on a running image would only affect new RubTextEditor instances. Existing instances won't be affected.
Sure. When I open a new System Browser or a new Playground, I don't see any effect. However, I noticed that the classes of these text editors is not RubTextEditor, but RubScrolledTextMorph and SpRubScrolledTextMorph.
You are right. I tested on a Windows 10 VM just now and it has no effect. This only seems to work on Linux.
Hi all, this is a super great work, I love having more shortcutty interactions :)
The cause of that could be multiple:
- SDL events do not send us key presses to the menu key (unlikely?)
- we don't have a correct mapping with Window's menu key in
KeyboardKey=> I'd look for the cause around here!
The missing mapping might be a problem. KeyboardKey.class.st contains this:
{ #category : #windows }
KeyboardKey class >> initializeWindowsVirtualKeyTable [
self flag: #pharoTodo. "Some values are missing, need to gather them from users who are able to."
WindowsVirtualKeyTable := Dictionary new.
...
I found that in KeyboardKey class >> # initializeKeyTable the key corresponding to the virtual code 0xA5 (VK_RMENU) is designated not as Menu, but as Alt_R (kVK_RightOption). Could this be the issue?
@NSUSpray Would you mind testing again with the latest commit. The extra symbol mapping in revision c3f06a0eb4b71a94a7e6ef97cda0204c066bae35 works for me on a Windows VM
Yes, now it works!
I found that the corresponding Windows constant is correctly named VK_APPS (VK_MENU is the Alt key and VK_RMENU is the right Alt key). Maybe the original name of the constant as OSK_APPLICATION is reasonable and should not be changed?
I would also like to note that the menu opens at the position of the mouse cursor (pointer), while according to the canons it should open at the position of the text cursor (caret).
Failing tests not related:
- [CI] Failing test: ProperMethodCategorizationTest>>testNoUncategorizedMethods #11669
- [CI] Failing test: ReleaseTest>>testUndeclared #11670
- #skipOnPharoCITestingEnvironment seems to not work on WIN and MAC #11425
So is this block only for not categorised methods?
I don't see the uncategorized methods. All added methods in the PR have a category.