[Feature] Display matrix.to links to a specific pill.

[tyreseluo]

PR content

This PR just extends HtmlLink to create matrix url's special pill and doesn't handle any specific link clicks, they will have a separate PR for processing.

Fixes #84.

• Added new Widget RobrixHtmlLink to handle the normal link and the matrix.to link, normal links are displayed normally using HtmlLink.
• Added room_preview_cache.rs to deal with blocking of UI threads when room info is requested frequently.
• The default title and avatar are displayed when the data has not been requested back.
• When someone is @ you, the pill background color is red.

PR Problems

Not Fixed yet:

• The text is vertically uncentered from the pill, and the pill is below the horizontal position of the text.

• When the latest message in room_preview is zoomed out, the pill is displayed incompletely.

• Highlighting @room tags within a message.
  This should not be implemented by parsing the @room string from the message text; it should be done by checking the mentions of a given message.

• Resolving room aliases within Pill links.
  Currently we only immediately handle and display links that have room IDs.
  To implement this, we need to create a new MatrixRequest variant for Client::get_room_preview(), which internally will resolve a RoomAliasId and return a preview of the room. We then need to deliver those results back to each Pill widget by using Cx::post_action() to send a new action type containing the RoomPreview; that action should be handled by the matrix pill widget.

[ZhangHanDong]

Overall, no suggestions, lgtm.

As for the naming, actually, you don't need to add "Get" since you are already initiating a Request.

[kevinaboos]

Nice work so far, I'm impressed with your code clarity! It's very easy to read, nice job.

I left a few comments below.

One other issue -- I think that caching of RoomPreviews needs to be handled a little bit differently from the other content that we cache (Avatars, UserProfiles). I think we need to re-get a RoomPreview every time a user clicks on an unknown Room link.

• Note: we should also probably save this for a future PR, because this PR only needs to deal with displaying the actual links as special Pill widgets.

[tyreseluo]

One other issue -- I think that caching of RoomPreviews needs to be handled a little bit differently from the other content that we cache (Avatars, UserProfiles). I think we need to re-get a RoomPreview every time a user clicks on an unknown Room link.
Note: we should also probably save this for a future PR, because this PR only needs to deal with displaying the actual links as special Pill widgets.

So, we don't have to think about what room_preview requests for now? Just show only the pill?

[tyreseluo]

One other issue -- I think that caching of RoomPreviews needs to be handled a little bit differently from the other content that we cache (Avatars, UserProfiles). I think we need to re-get a RoomPreview every time a user clicks on an unknown Room link.

• Note: we should also probably save this for a future PR, because this PR only needs to deal with displaying the actual links as special Pill widgets.

yes, we can keep this cache for now until we have a unified solution for cache handling. The problem you mentioned is indeed that if a user clicks on an unknown room we should indeed re-fetch the room preview and determine if the unknown room is allowed to be previewed, and if so re-fetch it while displaying the viewed room message.

[kevinaboos]

One other issue -- I think that caching of RoomPreviews needs to be handled a little bit differently from the other content that we cache (Avatars, UserProfiles). I think we need to re-get a RoomPreview every time a user clicks on an unknown Room link.
Note: we should also probably save this for a future PR, because this PR only needs to deal with displaying the actual links as special Pill widgets.

So, we don't have to think about what room_preview requests for now? Just show only the pill?

My apologies, I made a confusing comment. What I meant to say was that:

1. we need to re-obtain a RoomPreview every time a user clicks on an unknown Room link, we cannot use the old cached value.
2. We should save the feature of handling clicks on matrix rooms/events (jumping to that room) for a future PR. Those are issues Properly handle matrix.to links to a specific event (message) #222 and Properly handle matrix.to links for Rooms #87. This is because we don't yet have support for the fundamental feature of jumping between different rooms. I'm working with YiFei (the GenUI creator) on developing a widget to offer easy navigation between widgets.

[kevinaboos]

Looks good, except for the part about handling the Requested status, which needs to be reworked a bit.

[kevinaboos]

Alrighty, I've rewritten most of this PR again. The primary issue that caused our joint misunderstanding is that you imitated the design of HtmlOrPlaintext and Avatar widgets, but those are actually categorically different from the way this special HTML link widget must work. The way you named the functions (and the manner of calling redraw within a draw context) made it seem like they were not draw-time functions, but they actually were. You shouldn't ever need to call redraw in a draw function.

These functions are actually used to populate the content of the pill widgets (or the HTML link), so I've renamed them as such and completely reimplemented how they work. Also, a lot of them were public functions which made it seem like they were eligible to be called from external modules in the app, but that's not actually possible because all of the content used to populate the pill/link widgets can only come from within the HTML-parsed context, not from other widgets.

I also restored the existing behavior of parsing all bare HTML links as matrix links to ensure that User links can be handled specially (by showing the user profile sliding pane). Not sure how that got removed but it's still important to preserve that behavior.

I also made sure to handle the case where a User link is waiting on a fetched User profile, which occurs on a UI Signal. The way your existing code was structured would never enabled a user pill widget to get refreshed, at least not unless th e user completely scrolled the widget off-screen and then re-scrolled back to it (which would cause the item to get redrawn from scratch).

---

In summary, please take a deeper look at my recent two commits to see what kind of code structure and naming style we're looking for.

[tyreseluo]

Thank you so much, Kevin. I'll go over the comments you left and the changes you made to my code section.