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

Error in typed_input #308

Open
Ultraxime opened this issue Nov 28, 2024 · 10 comments
Open

Error in typed_input #308

Ultraxime opened this issue Nov 28, 2024 · 10 comments

Comments

@Ultraxime
Copy link
Contributor

Hi,

@genusistimelord, you pushed some new modification to typed_input with commits 55d23d8 and 1bed9d4.

With commit 55d23d8, you seemed to have followed some queries in issues like #306 that I explained why they were irrelevant to add, like having the on_change returning a result.
For example, now the number_input does not work.

With the commit 1bed9d4, you seemed to fix issue #299. In this commit you change the behavior of the typed_input when the text finishes with a . which changes the generality of the widget. This modification should have been done in number_input.

Is there a reason behind this modification?

@genusistimelord
Copy link
Collaborator

Well we do want typed input to output errors for the change as this is relevant to how it should work since we are dealing with Text to Values and since we support both integers and floats this is indeed needed. Also the . issues could not be fully resolved in number input itself so i had to do it in typed input. I did run the number input and it was working from the Example just fine? so i don't know what you mean by no longer working?

Also number input should know when Typed input doesn't process something so it can do its own work. These are just steps to making it more Relevant to taking any input and allowing it to return if its needed or not to the end user. However I do seem to have a issue where the formatting of Strings removes the . due to anything .0 being reduced down to the main number via formatting rounding. Was thinking the only way to fix that would be to handle each number to character manually rather than rely on formatting. Which would be better as we could better control the input too.

@genusistimelord
Copy link
Collaborator

Ok so after your fixes the only 2 issues I noticed were

The layout messing up and not shrinking the typed input to be before the Arrow buttons.
image

and when typing in all 99999 after the input one turned into an 8
image

though this could be a format issue of some kind maybe. though it always seems to be the 5th number after the decimal that does it. regardless of what the main number is.

The one issue I did not check is if they tried to fit the number input into a Lower height Zone which should Move the buttons down to a single line and set the box to a minimal height for Text size and buttons.

@Ultraxime
Copy link
Contributor Author

Ultraxime commented Dec 3, 2024

Are the arrow buttons supposed to be after the typed input? I thought it was meant to be above the typed input.
I checked on a former version of iced and it was already that.

For the eight, the issue comes from the fact that float 32 goes from 249.9999847412109375 to 250 and that the formatting rounds it to 249.99998, and after that anything you add can't make it closer to any other number

@genusistimelord
Copy link
Collaborator

ahh ok making sure as i did not know how the rounding and such went for formatting. And yeah the Arrow Keys are in the Box But the Text should not be above or Below them. it should be next to them otherwise you wont be able to Select the Text easily.

@Ultraxime
Copy link
Contributor Author

Do you mean that the number shouldn't be below the arrows?
Because I'm not sure that it was already the case and I don't know a way to do it

@genusistimelord
Copy link
Collaborator

genusistimelord commented Dec 3, 2024

notice where the last 9 is in this image how it is above the Arrow buttons.
image
it should not be there and should of ended Before the arrow buttons as to not overlap them. its fine if it cant be fixed currently. Just stating this is a layout issue.

Everything else I tested seems to be working just fine though.

Only way to fix this would be to Hide the Border of Typed input and Render a border for number input that encapsulates it all. This way it would Seem like the arrow buttons are still within the input.

@Ultraxime
Copy link
Contributor Author

I looked at the previous version and it was already the case.
But I agree with you, it would be nice to have a better widget where the text is not under or over the arrows.

Currently, I don't see a solution for that but if I think of one I'll do it

@genusistimelord
Copy link
Collaborator

Anyways I think once some others Try it out and verify too we can then close all of the issues for number input

@Ultraxime
Copy link
Contributor Author

As well as #286 because content_width disappeared, I left the method and marked it as deprecated.
This is now, just a wrapper around width to prevent breaking updates.

And I don't know if it's update on Grid or this but it seems to resolved #278

@genusistimelord
Copy link
Collaborator

ok thank you. When you get a chance can you add your changes to the Changelog under unreleased.

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

No branches or pull requests

2 participants