Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Selection of content to then use the clipboard #911

Open
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

clement-roblot
Copy link
Contributor

Hi there 👋 ,

I would like the user of my app to be able to copy the content being displayed in the app. The clipboard being OS related, I don't intend to add this as a feature in the lib to avoid adding dependencies. But I would like to add the ability to select with the mouse some text being displayed on the screen.

This is a first draft of the feature, allowing us to discuss the implementation and what/how to improve it.

I added a new example named "selectable_input", which is a copy of the input example with the selection added.

I'm happy with the simplicity of use of the feature, but to reach this simplicity I did have to do something that might be considered a Lèse-majesté crime: I added some Event management in my selectable DOM NodeDecorator. Is the mixing of the DOM part of the lib with the component part acceptable?

This is a work in progress, the features that I would still like to implement (once we agree on a basic implementation) would be:

  • Implement the double click on word to select the word
  • Add a "selectable" flag in the pixel class and take it into account when selecting things

This last one being more impactful on the lib as it would add a new flag for each and every pixel on screen and thus would increase the RAM usage of the lib. Is this something thinkable?

@ArthurSonzogni
Copy link
Owner

ArthurSonzogni commented Aug 9, 2024

Thanks! I like the idea.

I was only thinking about supporting selection in Input, but with your idea, we would be able to select arbitrary parts. this sounds interesting.

I would need to dig deeper. Unfortunately, I am busy the next 10 days without internet access. You can expect more involvement on my side on my return. ;-)

@ArthurSonzogni
Copy link
Owner

(I took a brief look this morning)

I am considering some alternatives:

Same solution, but as a component.

Instead of using an element + event handler, the two would be merged. This would provide an easier to user API.

Component Selectable(SelectableOption option = {})
struct SelectableOption {
  Component inner;
  
  // Register event handlers:
  ...
}

A more deeply integrated solution.

Selection would be handled by FTXUI totally, without relying on Component/Element. As you said, we would likely add a field to the pixels to determinate what is "selectable" and what isn't.

The user would be provided element to "fill" the "selectable" bit. If elements aren't handling mouse events, it would be handled by ftxui builtin. There would be global accessor to the selection and ways to register observers.

// Define what is / isn't selectable.
Decorator selectable();

std::string GetSelection()
void OnSelectionChange(std::function<void()>);

@ArthurSonzogni ArthurSonzogni force-pushed the main branch 5 times, most recently from f353474 to c5357ac Compare August 18, 2024 08:46
@clement-roblot
Copy link
Contributor Author

I think I like your second suggestion. It is a bit fuzzy in my head so I will try to make a POC first to make sure we are thinking the same thing.

I also want to make sure those changes don't mess up already existing applications. Some people seam to be using the lib for some games. Forcing the selection by default would probably mess up those applications. So I will make sure to have a global flag of sorts that disable any selection system.

@clement-roblot clement-roblot mentioned this pull request Aug 27, 2024
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants