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

Give various widgets a readOnly mode #93

Merged
merged 2 commits into from
Mar 7, 2022

Conversation

Dretch
Copy link
Contributor

@Dretch Dretch commented Mar 6, 2022

This mode allows text to be selected (and copied), but does not allow
editing. See issue #87

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_,
Copy link
Contributor Author

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 ?

Copy link
Owner

@fjvallarino fjvallarino Mar 7, 2022

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.

Copy link
Contributor Author

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))
Copy link
Owner

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

Copy link
Contributor Author

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.

Copy link
Owner

@fjvallarino fjvallarino left a 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!

@fjvallarino fjvallarino merged commit 2ad5012 into fjvallarino:main Mar 7, 2022
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