Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use consistent key bindings in FindReplaceOverlay on MacOS #2007 #2008

Merged
merged 1 commit into from
Jul 12, 2024

Conversation

HeikoKlare
Copy link
Contributor

@HeikoKlare HeikoKlare commented Jun 28, 2024

Currently, the opening action for the find/replace overlay uses a key binding with the OS-dependent "modifier 1" (mapping to CTRL on Windows and CMD on MacOS), while all key bindings within the overlay (such as activating search options) use key bindings with CTRL as a modifier.

In order to unify the key bindings, this change adapts the key bindings within the overlay to also use the OS-dependent "modifier 1", such that on MacOS the CMD modifier is used. The change also adapts the tooltips to (1) reflect the changed keys and (2) represent the MacOS modifier keys via icons like at all other places.

Fixes #2007

@HeikoKlare
Copy link
Contributor Author

@BeckerWdf Can you confirm that these changed key bindings make sense on MacOS?

Example

Current

Open find/replace overlay: CMD+F
Move focus to find input field within find/replace overlay: CTRL+F
Activate whole word search: CTRL+W

New

Open find/replace overlay: CMD+F
Move focus to find input field within find/replace overlay: CMD+F
Activate whole word search: CMD+W

@BeckerWdf
Copy link
Contributor

Activate whole word search: CMD+W

With your patch it's CMD-Shift-W. But the tooltip still says CTRL-W

@BeckerWdf
Copy link
Contributor

and btw:
in the UI CMD should be rendered with the CMD-Icon like e.g. in the menu entries:
image

Can these bindings be changes on the "Keys" preference page?

Copy link
Contributor

github-actions bot commented Jun 28, 2024

Test Results

 1 210 files   -   605   1 210 suites   - 605   1h 0m 24s ⏱️ - 32m 2s
 7 668 tests ±    0   7 436 ✅  -     4  231 💤 +  3  1 ❌ +1 
16 110 runs   - 8 055  15 596 ✅  - 7 820  513 💤  - 236  1 ❌ +1 

For more details on these failures, see this check.

Results for commit ca7b586. ± Comparison against base commit 337f4ba.

This pull request skips 3 tests.
UiTestSuite org.eclipse.ui.tests.api.ApiTestSuite org.eclipse.ui.tests.api.WorkbenchPluginTest ‑ testGetImageRegistryFromAdditionalDisplay
org.eclipse.jface.text.tests.contentassist.ContextInformationTest ‑ testContextInfo_hide_focusOut
org.eclipse.urischeme.internal.registration.TestUnitWinRegistry ‑ testWinRegistry

♻️ This comment has been updated with latest results.

@HeikoKlare
Copy link
Contributor Author

You are right, the tooltip has to be adapted as well, thanks! I think we should try to adapt the tooltip to use the proper modifier icon like in the menus. I will check that.

But do you agree with me that, in general, CMD instead of CTRL should be used on MacOS for these shortcuts?

Can these bindings be changes on the "Keys" preference page?

I don't think so, they are currently hard coded.

@BeckerWdf
Copy link
Contributor

But do you agree with me that, in general, CMD instead of CTRL should be used on MacOS for these shortcuts?

Yes.

I don't think so, they are currently hard coded.

I think this should also be changed.

@Wittmaxi
Copy link
Contributor

Wittmaxi commented Jul 1, 2024

@BeckerWdf I am not sure if that is sensible - the keybindings are not actions like the actions which are targetted by the settings of the "keys" page. Maybe the keybindings should be editable somewhere else?

@BeckerWdf
Copy link
Contributor

@BeckerWdf I am not sure if that is sensible - the keybindings are not actions like the actions which are targetted by the settings of the "keys" page.
Is it a must to be an action to be on the "keys" pref page?

Maybe the keybindings should be editable somewhere else?

Pls. don't a second possibility to configure shortcuts.

@Wittmaxi
Copy link
Contributor

Wittmaxi commented Jul 1, 2024

Pls. don't a second possibility to configure shortcuts.

I understand! Then let's use the "keys" page.

Is it a must to be an action to be on the "keys" pref page?

I am not really sure - from my understanding yes, but my understanding is extremely limited! Maybe somebody can shed light on this?

@HeikoKlare
Copy link
Contributor Author

We have extracted the custom binding of keys into a separate issue: #2015.

I have adapted this PR so that tooltips show the OS-dependent shortcuts and also use modifier icons on MacOS to be consistent with the presentation of shortcuts at other places (in particular, menus).

@HeikoKlare HeikoKlare marked this pull request as ready for review July 8, 2024 16:49
@BeckerWdf
Copy link
Contributor

I have some improvement suggestion regarding the formatting of the keybindings. It's up to you if you want to consider this or not.

@HeikoKlare
Copy link
Contributor Author

I have some improvement suggestion regarding the formatting of the keybindings. It's up to you if you want to consider this or not.

Improvement suggestions are always appreciated 🙂 I will gladly adopt them.
@BeckerWdf Can you share those suggestions?

@@ -70,6 +74,8 @@
* @since 3.17
*/
public class FindReplaceOverlay extends Dialog {
private static final String MOD1_KEY_STRING = OS.isMac() ? "⌘" : "Ctrl+"; //$NON-NLS-1$//$NON-NLS-2$
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a util that does that for you:
See: org.eclipse.jface.bindings.key.KeySequence#org.eclipse.jface.bindings.key

This is also used for formatting they shortcuts in the empty text editor's onboarding implementation.
See: ModeledPageLayout#addEditorOnboardingCommandId

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks great, thank you! I will try to adapt this PR using that functionality.

@BeckerWdf
Copy link
Contributor

@BeckerWdf Can you share those suggestions?

Ups....

@HeikoKlare HeikoKlare marked this pull request as draft July 9, 2024 11:44
@HeikoKlare HeikoKlare force-pushed the issue-2007 branch 4 times, most recently from b2c0218 to 2445c9f Compare July 9, 2024 19:19
@HeikoKlare HeikoKlare marked this pull request as ready for review July 9, 2024 20:08
Copy link
Contributor

@BeckerWdf BeckerWdf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works fine and looks good

Copy link
Contributor

@Wittmaxi Wittmaxi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very Sensible way of extracting keyboard shortcuts from the handler code and at the same time address the formatting of the shortcuts! Thanks 😀

searchUpButton = new AccessibleToolItemBuilder(searchTools).withStyleBits(SWT.PUSH)
.withImage(FindReplaceOverlayImages.get(FindReplaceOverlayImages.KEY_FIND_PREV))
.withToolTipText(FindReplaceMessages.FindReplaceOverlay_upSearchButton_toolTip)
.withSelectionListener(SelectionListener.widgetSelectedAdapter(e -> performSearch(false))).build();
.withToolTipText(MessageFormat.format(FindReplaceMessages.FindReplaceOverlay_upSearchButton_toolTip,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: How about extracting the formatting of tooltips into a "addShortcutToToolTipText" method?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe even add a "withShortcutHint" method to the ToolItemBuilder, which takes a shortcut and adds it to the ToolTip?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! I have added a helper method in ca7b586.
Integrating the shortcut into the tool item (or its builder) would be even better. I am already working on a follow-up cleanup that better integrates shortcuts with operations, as well as the operations assigned to shortcuts and "usual" item clicks, which will cover that proposal in some way. Currently, there is quite some manual effort to initialize everything consistently. But that should not prevent us from having this improvement merged and is also easier to review in separation.

…atform#2007

Currently, the opening action for the find/replace overlay uses a key
binding with the OS-dependent "modifier 1" (mapping to CTRL on
Windows/Linux and CMD on MacOS), while all key bindings within the
overlay (such as activating search options) use key bindings with CTRL
as a modifier.

In order to unify the key bindings, this change adapts the key bindings
within the overlay to also use the OS-dependent "modifier 1", such that
on MacOS the CMD modifier is used. The change also adapts the shortcuts
to be represented as KeyStroke instances and uses them to match actual
key combinations as well as to produce the string representation of the
shortcuts for the tooltips.

Fixes eclipse-platform#2007
@HeikoKlare HeikoKlare merged commit 4888a8c into eclipse-platform:master Jul 12, 2024
15 of 16 checks passed
@HeikoKlare HeikoKlare deleted the issue-2007 branch July 12, 2024 08:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Find/Replace Overlay: unexpected key bindings on MacOS
3 participants