-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Update Slider for #2435 #3152
base: ucr
Are you sure you want to change the base?
Update Slider for #2435 #3152
Conversation
Can one of the admins verify this patch? |
@AppInventorWorkerBee ok to test |
How can I display what failed the test? How can I run a test myself that failed here? Do I need an iOS build environment for this? Could someone who knows ios components well help me with this? |
@AppInventorWorkerBee retest this please |
I see the logs, and I see that there are two errors somewhere, but I can't find where these errors occur or their description. |
I'm taking a look at it. |
@patryk84a OK, it looks like it was just a small type checking issue between int and Int32. Swift is incredibly picky. Could you further explain the scaleGraduation property? I don't think that's the name we want to use. It looks like it's the same as the max value? |
Currently, the Slider has a real Max value set to 100. When we enter a Max value greater than 100 in the designer, the slider becomes inaccurate. For example, if we enter 500, while moving the slider the values will change by 5. We could fix this so that the Max value from the designer is the Max value of the SeekBar view, but there were claims that this could break previous projects. Therefore, another idea was to introduce an additional parameter that defines the precision of the slider scale. It defines how many points on the scale the slider will have between Min and Max. If we set Min to 0, Max to 100, and ScaleGraduation to 1000, then while moving the slider the values will change by 0.1. Perhaps there is a better English name for this parameter. The problem is presented here: |
OK, I understand. I think we will want to make some changes to this feature to make it a bit easier to understand for a user. I think it would be clearer if the property were increment (or "step") and it were the size of each step. In your last example, this would be Min 0, Max 100, Step 0.1 |
I think that for better understanding of the function there is documentation that adequately describes a given property. Apart from that, people who are not experienced or do not need high precision of the slider do not have to change anything. The slider will work the same as before if someone does not modify this function. On the other hand, I think that it is possible to connect it to the Max slider, but then all calculations will have to be done in the code. For example, if we wanted to have a slider from 0 to 100, with a division of 0.1. Then we set the max to 1000 and the displayed result will be the result of progress/10. And yes, you are right, what you suggested seems easier to understand. But maybe it would be enough to simply "release" Max from the limitation of 100. You have to think about whether this could break any previous projects. The number of steps would definitely change automatically. It would be good to think about which version would be best, make appropriate corrections and it would be nice if the new version was included in nb199. |
I collected some slider issues from our community and made some fixes: