MouseCursor on links #543
MouseCursor on links #543
Conversation
cgestes
force-pushed
the
hit-test-children
branch
from
bfbc24b to
5b46ea6
Compare
|
So just pushed a rebase, with everything figured out. |
The previous behavior is hard to understand, it feels like it's broken. Some apps do it like this, because you probably want to open it much more than to edit it. In anycase it seems like a good quickfix before we do something better.
| } else { | ||
| // TODO: Implement a toolbar to display the URL and allow to launch it. | ||
| // editor.showToolbar(); | ||
| } |
There was a problem hiding this comment.
Wondering if we can extract this into a separate PR? I'm not convinced yet this is a good solution for now.
To edit: just remove it and make another one.
This would require keyboard navigation to the linked text, which is pretty annoying, to say the least.
It'd be nice to merge the hitTestChildren fix without waiting on this conversation to get resolved.
There was a problem hiding this comment.
Tried... I don't know what to extract actually. Can you pick the commits you are interested in? they are split properly already.
Changing the mouse cursor imho make sense only if you can actually click. Otherwise it's miss-leading.
The current situation I am trying to fix here: it's impossible to follow or edit a link while editing.
Follow workaround: none I know of. Links are just unusable when editing.
Edit workaround: just remove the text and make a new one.
So I actually believe everything should be merged. It's really small changes that can be easily adapted when we have better support for links.
Also this could be made a plugin so that anyone can pick the appropriate behavior for their cases.
There was a problem hiding this comment.
Follow workaround: none I know of. Links are just unusable when editing.
Some editors implement link launching in edit mode using the Ctrl+LeftClick (or Cmd+LeftClick for macOS).
Obviously this is not an option for mobile platforms and for those implementing a toolbar with an option to follow the link is probably the most common approach.
That said, if your use case only requires desktop support how about adding the Ctrl+LeftClick support? This is kind of similar to what Web Browsers do for "Open link in new tab" action, which is pretty close to what the user wants here.
For mobile platforms there is also an option of a "Long Tap", by the way, which I've seen being used in some cases. Though usually it also triggers a toolbar, but can be simplified by popping up a modal dialog as a temporary solution.
There was a problem hiding this comment.
My cents on this (the product manager in me speaking):
- edition mode: I'm editing a link, I don't really need to follow the link (unless I want to check but shouldn't happen that often)
- read only mode: I just want to follow the link
| return body!.hitTest(result, position: position); | ||
| }); | ||
| } | ||
|
|
|
I've cherry-picked the hit test fix in #557 and merged. Let me know if you're planning to spend more time on the links support here per our discussion above? Otherwise we can probably close it? |
This implements hitTestChildren for RenderEditableTextLine.
This also set the mouseCursor to "click" for links and always open links on click. :D
The previous behavior was hard to understand for a user. Some apps do it like this, because you probably want to open a link more than you want to edit it. To edit: just remove it and make another one.
In anycase it seems like a good quickfix before we do something better.
In practice this forward events to RichText & (probably) embeds.
We could use TextSpan gesture detector for handling clicks on link. Your call :)