Repository navigation
Conversation
… and can be turn on in `Preference - Editor`) along with chinese translation
| PreferencesEditorDescription -> "Customize the editor's appearance and behavior." | ||
| PreferencesEditorPlayerCursorColor -> "Player cursor color" | ||
| PreferencesEditorClickToJumToEntry -> | ||
| "Jump to the cursor position entry by clicking it on canvas in multiple entry edit mode" |
There was a problem hiding this comment.
The title should be simple and short, like "Click to switch entry"
We can add a description to it.
| PreferencesEditor -> "Editor" | ||
| PreferencesEditorDescription -> "Customize the editor's appearance and behavior." | ||
| PreferencesEditorPlayerCursorColor -> "Player cursor color" | ||
| PreferencesEditorClickToJumToEntry -> |
| select = { it.playerCursorColor }, | ||
| update = { copy(playerCursorColor = it) }, | ||
| ) | ||
| switch( |
| cursorStateValue.position?.let { position -> | ||
| getEntryIndexByCursorPosition(position)?.let { index -> | ||
| // having bugs here | ||
| // if the cursor do not move, it would not jump |
There was a problem hiding this comment.
Do you mean, when only clicking and without any moving, this line is not executed?
It doesn't happen on my side.
Could you explain more?
| editorState: EditorState, | ||
| ) { | ||
| val action = keyboardState.getEnabledMouseClickAction(event) ?: return | ||
| if (action.canMoveParameter()) { |
There was a problem hiding this comment.
I think we need to add another mouse action instead of handling it over the existing moving actions, right now, if we enable this, it's very difficult to drag parameter lines, because when you press, it immediately causes the jumping.
Also, it might be better UX if we handle it on mouse release (up), not mouse press (down).
Even if we use another mouse action, we should note that the action def might be the same for multiple actions (e.g. we can simply set Left Click on this new action).
So, e.g. when we handle it on mouse release, we need to check whether this release event is a finishing event of a dragging, and only handle when it's not.
|
Thanks for all the advices and code review and I really appreciate them. I would look into them and try to push myself to finish them in a week or two. And again thanks for your work and the whole project. |
|
Superseded by #112, which reworks this feature on the current |
* Add opt-in click-to-jump-to-entry in multiple entry edit mode Reworks PR #49 on the current dev branch. Adds an editor preference (off by default) that, in multiple entry edit mode, makes clicking an entry on the canvas set it as the current entry. Two fixes over the original PR: - The original passed the group-relative index straight to jumpToEntry, which targets the wrong module entry when the edited group does not start at index 0. Now maps through entries[indexInGroup].index. - The original read cursorState.position (only updated on mouse move), so a press without a preceding move did not jump. Now the click position is derived from the press event itself. The jump is gated on multiple entry edit mode (entries.size > 1); single edit mode is unaffected. Adds the preference field/default to AppConf, the preferences switch, strings for all four languages (en/zh/ja/ko), and direct tests for getEntryIndexByCursorPosition. The declarative switch is additionally covered by the existing PreferencesPagesTraversalTest. Co-Authored-By: RibosomeK <122797zhyktb@gmail.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Skip click-to-jump when the clicked entry is already current Jumping to the current entry is a no-op except that jumpToEntry always fires the auto-centering scroll (scrollFitViewModel.emitNext), so clicking the already-current entry re-centered the view unexpectedly. Guard the jump on the target index differing from the current index. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Only jump on body clicks, not when grabbing a point to drag Clicking the current entry's left border (shared with the previous entry's end) switched the current entry to the previous one, because getEntryIndexByCursorPosition resolves a shared border to the first (left) entry. More generally, grabbing a border/point is a drag intent, not an entry-selection intent. Restrict the click-to-jump to presses that are not hovering a draggable point (i.e. clicks on an entry body), and extract the logic into maybeJumpToClickedEntry. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: RibosomeK <122797zhyktb@gmail.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The reworked version of this PR (#112) has been released in 1.7.0-beta2 — the click-to-jump option is available under Preferences → Editor (off by default). Thank you for the contribution, @RibosomeK! |
2 participants
add click to jumpToEntry in multiple entry edit mode (default is off, and can be turn on in
Preference - Editor) along with chinese translationAfter testing, I found a bug, if your mouse did not move, it would not "jump", I don't know how to fix that, but I would consider it doesn't really affect the actual experience.