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.

[clement-roblot]

Hi @ArthurSonzogni

Sorry I just re-read my previous message and I seam to have forgotten to mention that I live on Mercury so the concept of "tomorrow" might be distorted compared to earth (where I think you are based).

Here is a small recording that shows that state of the implementation. you already implemented the mouse capture part. I added the wrap around selection: if you select down, it will select until the end of the selectable line.

Screencast.from.2024-10-31.21-54-38.webm

I moved a few logics from the screen to the text block as this is where the end/length of the line info is available.

I didn't implement anything around the tree aware selection. Would it be ok with you if we integrate a non tree aware selection?

[ArthurSonzogni]

I didn't implement anything around the tree aware selection. Would it be ok with you if we integrate a non tree aware selection?

I think this is important for the feature to become useful. I would love to help with that, but I am a bit busy at the moment 🤕

[clement-roblot]

Oki doki.

First of all: get well soon (based on the emoji).

For the feature, I'll take a look. Weirdly, for once I think I understand it from the code perspective (travelling through the tree of elements etc...) but I am unsure how it looks from the user perspective. I'll probably message here with "use cases" to make sure I understand well the ins and out of how it is supposed to look like from the user's perspective.

[clement-roblot]

I implemented part of the "tree aware" selection. Now when 2 text fields are side by side, when starting the selection in the first text will not overflow into the next one.

The other part of your requirement seams more obscure to me as I'm only selecting texts, nothing structural. So the idea of a "parent" text in the dom sounds weird to me. And even if I push the analogy with html, we have effectively prevented here the selection from going from one

tag to the next (which I think makes sens in this lib), but the idea of the parent selection would mean that if you start your selection in the <title> of the page then you can select the

under it.

I am a bit confused as to how this is supposed to be looking and what would be the use case. Here is a video showing how things are working for now:

2024-11-06.19-00-20.mp4

[ArthurSonzogni]

test-2024-11-13_21.45.43.mp4

[clement-roblot]

Hi Arthur,

Sorry for the delay in my answer. I understand better what you have in mind now. I'm still fuzzy on when selecting an entire block makes sens. But it is most probably cause I plan on using this feature to do copy past of data, when many people seam to be using this lib for games where more flexibility is appreciated. What is undeniable is that your implementation is a lot more generic and clean than anything I suggested until now.

Testing what you committed I see a lot of things that works perfectly (the hbox part in particular).

I saw that you removed the concept of "backward selection" (selecting from the bottom right to the top left) with your modifications. Did you do that to focus on your implementation logic, or do you think this shouldn't be implemented at all? (I re-implemented part of it (from bottom right to top left), but the 2 other directions are still weird, I want your opinion on it before I mess things up to make the 2 last directions work properly)

I modified a few logic to get better wrap around/saturated selections (in the nested vbox in particular).

I saw that we could select the titles of the windows and the top border of the window in the process. So I changed the way the text selection works to select up to the last glyph an not up to the end of the box. (I mention it cause you might have objections with this approach)

I still have to implement the API you eluded to in node.h

(my goal is for me to implement that this week)