-
Notifications
You must be signed in to change notification settings - Fork 44
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
Give various widgets a readOnly mode #93
Conversation
This mode allows text to be selected (and copied), but does not allow editing. See issue fjvallarino#87
@@ -33,6 +33,7 @@ module Monomer.Widgets.Singles.DateField ( | |||
dateField_, | |||
dateFieldV, | |||
dateFieldV_, | |||
dateFieldD_, |
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.
This change makes many of the ...D_
constructors public.
This is because the other constructors require a change event or a lens -- which you might not have if the user is never allowed to change the value.
On the other hand the same argument already applies to disabled widgets, so maybe there is a reason these constructors are not public. What do you think @fjvallarino ?
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.
I'm fine with exporting those constructors if they are useful (colorPickerD_
, for example, is exported). I had not exported them because I did not think they were useful for users and, when in doubt, I prefer not to export things since changing them later may break user code. I don't think the signatures of the D versions of these widgets will change in any way, so the risk is very low.
To confirm: the idea of exposing, for example, textFieldD_
is to allow users to set a value without providing a change event? If that's the case, it makes total sense, yes.
Note: The objective of having the V versions require a change event was to help remind users that, without that event, the content of the widget could never change.
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.
...when in doubt, I prefer not to export things since changing them later may break user code.
I think this is sensible.
To confirm: the idea of exposing, for example, textFieldD_ is to allow users to set a value without providing a change event? If that's the case, it makes total sense, yes.
Exactly that, yes.
@@ -254,6 +264,7 @@ makeTextArea !wdata !config !state = widget where | |||
!caretMs = fromMaybe defCaretMs (_tacCaretMs config) | |||
!maxLength = _tacMaxLength config | |||
!maxLines = _tacMaxLines config | |||
!editable = not (fromMaybe False (_tacReadOnly config)) |
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.
Alternatively you can do:
!editable = _tacReadOnly /= Just True
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.
Indeed, that is neater: I just pushed the change.
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.
@Dretch looks great! 👍
Thanks!
This mode allows text to be selected (and copied), but does not allow
editing. See issue #87