-
-
Notifications
You must be signed in to change notification settings - Fork 443
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
base: main
Are you sure you want to change the base?
Conversation
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. ;-) |
(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()>); |
f353474
to
c5357ac
Compare
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. |
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:
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?