More floating elements migrated to use begin_overlay_reuse function

[jmbejar]

This is a follow up for #192, where we started to migrate out from our custom widgets used for floating elements, Portal and PortalView. In this PR, we achieved the following goals:

• Reimplemented Tooltip and created PopupNotification widget. Both are ready to be extracted out to Makepad.
• Updated ChatHistoryCardOptions to rely on the existing Modal widget
• Modal emits an action when the dialog is dismissed (by clicking outside for now, new ways can be added later).
• Added OverlayWidgetAction::Close to have a common action to cause any of our floating elements to close programatically.

Ideally, the floating menu we implemented in ChatHistoryCardOptions should be extracted to a specific and reusable widget, but it is out of the scope of this PR.

Summary of our overlay widgets:

Modal
It is presented centered in the screen and with an gray overlay layer behind by default. It takes all finger events and only propagates them to its inner content. It can be dismissed by clicking outside or receiving the OverlayWidgetAction::Close action.

PopupNotification
It is similar to Modal but it can not be dismissed by clicking outside. Also, it is default position is in the top-right corner of the screen. In the future, this widget could implement a stack of notifications to be displayed.

Tooltip
It has an API to show, close, position and set the text of the tooltip. All of this function are meant to be used by the owner of the tooltip by listing hover events in the related UI elements (such as Label instances). This widget does not lock touch events as other overlay widgets, since the control should be in the owner context. It does not support including nested UI elements for now (its content is it only a text label).

[noxware]

Shouldn't we keep these functions without the conditional part inside impl Tooltip and simply call them conditionally in impl TooltipRef?

[noxware]

Is there a reason why this is not 2 separate functions set_text and set_pos?

It may be a bit off that the widget actually has a set_text method because of the Widget trait, but will do nothing.

Since we already have a set_text method, I would fill that implementation first.

[jmbejar]

I went further and to only leave two functions: show(cx, position, text) and hide().

This is because I'm pretty sure you will want to provide a text and position when displaying a tooltip, so let's do it in one shot.

[noxware]

Not a very important opinion:

I fell as a user of the related widgets, would like to trigger ModalAction::Close, PopupNotification::Close, etc.

I imagine this can conflict in cases like tooltips inside modals and also, if we add an action like this to makepad, any contributor of makepad will need to use this action when they create overlay widgets to be consistent (and will need to know about it's existence). Also, it's more obvious the usage of this action if it lives near the widget it affects. So there may be no value on being DRY here if that is the intention.

It would also let you be explicit about what you are closing.

But I also feel I may be missing something, so I'm not completely sure about what I'm saying :P

[jmbejar]

This is a good point. In fact, I was able to reproduce a situation where closing a modal also closed a popup notification, and it was not the desired behavior. Will change to ModalAction::Close and PopupNotification::Close for now, but we will need in the future a more granular way to say "close this specific modal instance".

[jmbejar]

I actually removed everything :) I found confusing to use "Action enums" to communicate to modals/popups from the outside or from the inner contents) because those "Action enums" tends to be used to emit internal events of te widgets.

So, I think it is a safe bet for now to rely on custom actions emitted by the inner content of modals/popups and have the owner widgets of those responsible to directly invoke the .close() function. It is a bit more manual, but the dev has full and granular control.

See my last commit to check the approach.

[noxware]

Works like charm 👍

Left a tiny comment but approving anyways.