Selection2 the come back

[clement-roblot]

(This is a followup suggestion to #911)

Hi there,

As discussed, I integrated the selection system deeper into the lib. In the code you can add a decorator selectable() that will make the pixels of your Element selectable and then you have a method in your screen object that allows you to fetch the currently selected text.

In the example, I added only the label " Last name : " and the entire line of phone number (including whatever you typed in the input for it) are selectable.

This is still a work in progress, but I would like your feedback @ArthurSonzogni. This implementation pleases me a lot more than the previous one. Does this solution look acceptable to you?

I can see 2 issues for now:

• When something is selected, and then you click inside an input, this makes the selection freaks out.
• When selecting across 2 lines, I would like the selection to go to the end of the first one in x.

[ArthurSonzogni]

Thanks for your response!

I really like the public facing API where decorating an element with "selectable" makes it selectable by FTXUI.

Here are some requirements I believe would make this functionality even more user-friendly:

Visual Selection: Instead of a block selection, using a visual selection would be more intuitive for users. This means being able to select multiple lines even if they don't entirely fall within the top-left and bottom-right bounds of the selection area.

Tree-Aware Selection: The selection mechanism should be intelligent enough to consider the rendering tree structure. For example, if there are two side-by-side text boxes, selecting content from one box shouldn't spill over into the other. Similarly, when selecting from the parent, and going hover/through one child should select the whole child.
We can probably "find the two element where the select start and end. Find the common ancestor. From the common ancestor, select all the child that overlap with the rectangle.

Mouse Capture: When initiating a selection, capturing the mouse would prevent conflicts with hovering over other components. This functionality is already built into FTXUI and can be leveraged here.

I understand this might be a significant request, but I'm confident it would be valuable. I plan to work on your branch and submit patches soon if you would like.

---

On a separate note, I'm also working on an experimental project: building a kind of HTML/CSS/Reactive engine for C++. You can check out a draft here: draft.
Think that FTXUI is "functional", and RTXUI is "reactive". RTXUI would let less freedom to developers, but I would be able to implement all the nice features easily: selection, etc...

[clement-roblot]

Glorious that we seam to have a similar vision. I should have time to make some progress on this tomorrow.

Don't hesitate to add to this branch if you see issues or improovements to be made 👍

That react style c++ framework is super weird and also super cool 😁. I'm wondering how such a reactive system would impact performances 🤔 . Even is performance get impacted such a programming paradigme seams very popular on the web side of the dev world and would certainly be helpfull for many web dev people to jump into desktop software.