Emit Action when link is clicked

[PoignardAzur]

When porting from Druid to Masonry, I've removed the ability to trigger commands from links.

While I'm not sure how to handle that feature on the long term, on the short-term it should be fairly easy to re-enable. Most of the code is still there, just commented out.

Essentially, we just want Label widgets to send some Action during PointerDown events when the pointer is over a link. Ideally we'd want to handle pointer capture and cursor changes and stuff, but we'll keep it simple for now.

[failingprovince]

I tried to solve this issue but I'm stuck on a couple of points.

I managed to come up with this:

fn on_pointer_event(&mut self, _ctx: &mut EventCtx, event: &PointerEvent) {
    match event {
        PointerEvent::PointerMove(_point) => {
            let position = Point::new(_point.position.x, _point.position.y);

            if self.text_layout.link_for_pos(position).is_some() {
                _ctx.set_cursor(&CursorIcon::Pointer);
            } else {
                _ctx.clear_cursor();
            }
        }
        PointerEvent::PointerDown(_button, _state) => {
            // TODO: Start tracking currently pressed
            // (i.e. don't press)
        }
        PointerEvent::PointerUp(_button, _state) => {
            let position = Point::new(_state.position.x, _state.position.y);

            if let Some(link) = self.text_layout.link_for_pos(position) {
                todo!();
            }
        }
        _ => {}
    }
}

I can't figure out two things:

1. How do I send an action for a link? I figured it must be Action::Other, but what else?
2. What does it mean that Start tracking currently pressed?

I want to specify that I'm new to this codebase, so if there are things that could be written in a better way, please tell me.

[DJMcNab]

Unfortunately, our latent link support is going to be imminently removed in #515. This issue would likely be re-purposed for tracking link support in general.
I'm not sure about the first point currently. One option would be for it to send a new kind of action - LinkPressed(Arc<dyn Any + Send>), and store that same Arc<dyn Any + Send> in the Link structure. But as I say, this will need to be re-thought later.

"Start tracking currently pressed" is trying to say that if you start holding down on a link, then move the mouse away, then release the mouse, the link shouldn't be followed. This matches the normal behaviour (if there isn't a click-and-drag for links/urls available).

[PoignardAzur]

I think for a first implementation you should just open links on mouse down, and forget about tracking mouse movement.

Proper support for click-and-drag, pointer capture, etc, would require links to essentially be their own widgets. Implementing that requires inline widget layout (eg being able to lay widgets out across several rows of text) and we're not there yet.

Re: actions, I'd suggest creating a new action like Daniel says. I'd even say the payload should be a string, eg LinkPressed(String), so you don't have to worry about storing arbitrary payloads in your link structure.

[failingprovince]

Because of #515 now I can't access anymore the link at given position.

I have seen this comment:

I'm removing references to links for now. They were copy-pasted from Label's implementation, but I don't see links in editable text being implemented any time soon.

Which makes me think that this issue won't be implemented for the moment.
If it isn't the case, I could try to reimplement links from scratch but I need some starting point.

[PoignardAzur]

Note that the comment referred to links in textboxes, not links in general.

[failingprovince]

From what I found there is currently no way to access links from a TextLayout.

I could try to implement that but I'm not sure I understand the TextLayout.links field.
This is what I understood of the implementation:

• The Rect is used for positioning of the link char.
• The usize is used for describing the utf-8 code for the char.

[PoignardAzur]

You might need to re-implement a lot of the groundwork.

Honestly, this will likely be easier once the text refactor is implemented. (Not sure when that'll be, hopefully before next week.)