-
-
Notifications
You must be signed in to change notification settings - Fork 58
View/textSelectionEnabled #220
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
Conversation
philocalyst
commented
Oct 11, 2025
yas
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few suggested changes (mostly minor formatting stuff). I'll test out the example on my devices to make sure everything works, but looks like it should.
Sources/SwiftCrossUI/Views/Modifiers/TextSelectionModifier.swift
Outdated
Show resolved
Hide resolved
Sources/SwiftCrossUI/Views/Modifiers/TextSelectionModifier.swift
Outdated
Show resolved
Hide resolved
Additionally I changed the default value of isTextSelectionEnabled to be set in the initializer, where the other values get set. Should help to get an impression of the default values faster than setting it in the property definition.
Thanks for implementing all of the requested changes. I'm currently in the process of testing this PR out on iOS (faced some difficulties cause my phone wasn't paired to my current Xcode version and I didn't have the iOS platform support installed yet).
The modifier seems to work well on both Windows and Linux. (削除) On macOS the text seems to remain selectable forever after it's been made selectable at least once. (削除ここまで)
I've found a fix. Add these lines before setting isSelectable
;
if field.isSelectable && !environment.isTextSelectionEnabled { field.abortEditing() }
This fix also clears the current selection when text selection gets disabled.
Each editable/selectable text field in the app has a currentEditor()
method which returns the editor being used on that text field if applicable. That instance stores the selected range etc. I guess NSTextField.isSelectable
just controls whether or not someone can begin selecting, but doesn't actually stop them from continuing to select if they already started.
Finally managed to test it on my iPhone. What would we have to do to support proper iOS text selection? For small text like the greetings generator this copy button is ok, but for large paragraphs the text selection ux would be nicer. Do we have to switch to a different text view type?
Finally managed to test it on my iPhone. What would we have to do to support proper iOS text selection? For small text like the greetings generator this copy button is ok, but for large paragraphs the text selection ux would be nicer. Do we have to switch to a different text view type?
We would need to, yes. Like this its actually equal to the swiftui implementation https://developer.apple.com/documentation/swiftui/view/textselection(_:) so in my opinion it can stay like that. (Aside from maybe adding the sharebutton)
Ah interesting, yeah I agree that it can stay like this for now then.
As Philocalyst requested I added a modifier to control wether Text() could be selected by the user.
On UIKitBackend I switched from UILabel to a new Class inheriting from UILabel to show a Menu on long press.
Oob selectability is not built into UILabels.
I tested using UITextView like NSTextView in the AppKitBackend, but it lead to rendering issues.
The custom class solution should work as a drop in replacement, rendering exactly the same as before, only with more funktionality.
The isTextSelectionEnabled boolean gets set in the environment.
AppKitBackend, WinUIBackend and GtkBackend required a single line change in the updateTextView function, setting the flag on the native View.
On AppKitBackend the cursor is not always reacting to a change in the reactability instantly and it also doesn’t unselect it (Gtk and WinUI do unselect it) but this seems to be an AppKit Limitation and shouldn't affect the majority of usecases.
I’m sorry for the huge amount of confusing added and removed top level files, I assume a compile process placed them there for some reason.
It should be mergable with my other pr without conflicts.