Altering TextField (And any TextArea Class) editability also affects selections.

[Smithor]

I have noticed this issue with TextFields, but it probably also relates to other classes as well. Changing the field from editable to non-editable also changes it from selectable to not selectable. There are many situations in which you might want to be able to select content, but not have it be editable.

The code bringing this change appears to be TextPainter#paintTextAdapterTextSel(Painter, TextAdapter), specifically line 165. While I can also imagine that there are situations where you might not want to have the information be selectable either, I think it would be better to have the defaults still retain selectability, with the functionality able to be turned off if such is required for descendant purposes.

[Smithor]

I looked into it a little bit more, removing that line is not enough, something else is preventing selections, but I am not sure what.

[reportmill]

You're right - there are some issues here. I only recently made TextField a subclass of TextArea and I think it's the right thing to do (as opposed to the prior encapsulation), but I wish it didn't have the setEditable() method. The canonical way of making a TextField non-editable should really be with setDisabled(true).

Maybe the right thing to do is add a Selectable property to separate out that functionality. And maybe even make setSelectable() and setEditable() both protected.

[Smithor]

I'll be honest, the disable enable language of Swing was always a little confusing to me, since disabling and enabling are very broad terms. Disabling a feature could mean that the feature is unable to have any interaction at all, or it could mean that it is removed from the pane, or it could mean that editing and selecting were disabled but not back-end updates. If it was something like "disableText", well then it would be a bit more clear, but "setEditable" is just so straight forward, it doesn't even need documentation. Made it easy to tell this was a bug rather than the opposite, if it had been something like "disable" I would have assumed it was working as intended, since it "disabled" all elements of the view except visibility, which has its own method for control.

Besides, Swing, while it works, is hardly the standard for eloquence, with all of its layout systems (none of which work together), is like throwing together 5 different languages together in the same language learning book. Taking a stand for improvements is much better than following the status quo, if that status quo is defined by Swing haha. When I first starting using SnapKit, and the BorderView had all the methods for easily setting itself up, it was like "Yeah, this is what Swing should have been all along", I definitely wouldn't want to take a step back that way.

Maybe the right thing to do is add a Selectable property to separate out that functionality. And maybe even make setSelectable() and setEditable() both protected.

I do like the idea of having both selectable and editable properties, because I can see many situations where you might want exactly what the current functionality is. I have a utility at work that shows all the editable fields ahead of time, but disables all selection and editing functionality of the fields so that you don't accidentally think you can change them, and so you can understand you aren't connected yet (but can still see the details that you will need once you are). Pretty handy. But there are also lots of situations where you might need to select text, and I notice that you can't select labels, which leaves basically no options for having small areas of text that aren't editable, but can be copied from, in all of SnapKit.

Actually made me reconsider the entire use of SnapKit for the project I am working on, since it was all about accessing information. All of the nice API and other handy constructions don't matter if I can't do something so simple as select text that someone can't edit.

I guess it is then a related question, why would you make the methods protected? I don't see how it would do anything other than what it does right now in that case. Applications using the library wouldn't be able to make use of the editable/selectable functionality unless they extended the class.

[reportmill]

So I added a Selectable property to TextAdapter so now any TextArea or subclass can support selection without editing. I still think that developers shouldn't need to call this on TextField (via myTextField.getAdapter().setSelectable(true/false)), and should instead only need setDisabled(true/false). I ended up moving isEditable/setEditable to TextView from TextArea so developers aren't confused about calling that instead of disabled.

I still need to iron out a few things and do some testing, but I think this is looking pretty good.