User should be able to copy text from visualization

[wdanilo]

This task is automatically imported from the old Task Issue Board and it was originally created by Sylwia Brodacka. Original issue is here.

---

Team

Technical Designer: ... Implementer: ... Acceptance/QA: ...

Why

As I want <to be able to select text in visualization (JSON, Table or Text)> So that

Acceptance Criteria

Scenario: 
GIVEN [I open a table visualization on a node]
WHEN [I can select one or more cells/rows]
THEN [I can paste it to another node or excel spreadsheet]

Notes

Resources

[xvcgreg]

@MichaelMauderer please update this ticket with the information you have after discussion with Wojciech.

[MichaelMauderer]

We need to implement custom text selection here to be able to work with lazy text backend.

These steps will need to be undertaken:

• we need functionality to determine which character was clicked on (in text position coordinates,.i.e., line and character index).
• we require functionality to highlight characters on dragging of a selection area with animations.
• we require functionality to transfer the selected text to the clipboard.
• we require extra functionality to scroll the visualization on dragging outside the currently visible area. This includes keeping in memory the selected text, and requesting new text from the backend. This extends the current functionality, which would discard text outside the visible window.

[farmaazon]

I wonder if the first three points could not be replaced with just changing the implementation of lazy text view: instead of the Grid View we could just show a single div with multiple lines of text and position it properly. Perhaps this would be easier?

[MichaelMauderer]

This would mean mostly re-implementing a lot of the text-grid logic. I wonder if it would be possible to extend the Grid View to access the visible items in order (or by index). That would make it easy to transfer them to a DIV while keeping all the heavy lifting in the Grid View. But we would need APIs to get updates for the visible items, their content and position.

I guess all of that should already be in the Grid View, we would just add a new “Rendering Layer” to the content update logic. So instead of re-implementing, some refactoring might be asked for here.

[farmaazon]

I think there is already a method for getting the entry by row and column.

Also, instead of using the entire grid view, we have methods in https://github.com/enso-org/enso/blob/a003654b6363d70d465103b69acbaa81f868e394/lib/rust/ensogl/component/grid-view/src/visible_area.rs especially all_visible_locations which gives iterator over all rows and columns basing on the entry size and Viewport. We could just call it on every scroll change and reset div text accordingly.

GitHub

enso/visible_area.rs at a003654b6363d70d465103b69acbaa81f868e394 · enso-org/enso

Hybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.

[MichaelMauderer]

That sounds like what I had in mind. We might want to try this approach, as this could make text handling a fair bit easier.

[wdanilo]

I wonder if the first three points could not be replaced with just changing the implementation of lazy text view: instead of the Grid View we could just show a single div with multiple lines of text and position it properly. Perhaps this would be easier?

I don't think this will work. Sure, it would allow you to select them, but lines can be VERY long, so we will be displaying only portion of them. Then, scrolling right, should preserve the selection, which would be then very tricky. I believe that custom selection implementation is more robust and it should not be very hard to implement.

[farmaazon]

If it's possible to read selection from HTML, then there is still an option to read it and restore properly after scroll. May be considered.

[MichaelMauderer]

I think even with that approach, we will need all the points that I mentioned above, as we will need to be able to handle the selection and copying of “offscreen” text. To achieve that, we will still need to (1) determine the position of the selected characters within the text (to buffer the offscreen text when scrolling). (2) programmatically update the selection when scrolling and modifying the rendered text. (3) transfer the whole offscreen and onscreen text to the clipboard.

So in the end, we'd do the same amount of work on a different set of APIs (JS/DOM manipulation versus EnsoGL text manipulation). Some things might be easier to do in JS (no handling of different chunks in a Grid when manipulating the visible text) some in EnsoGL (probably better APIs to work with the selections and easier to work with mouse events in the Grid).

[farmaazon]

Task related to lazy table visualization, which is not present in GUI2.