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

TextBox cursor can break #341

Closed
dcampbell24 opened this issue Mar 28, 2015 · 3 comments
Closed

TextBox cursor can break #341

dcampbell24 opened this issue Mar 28, 2015 · 3 comments

Comments

@dcampbell24
Copy link
Member

The TextBox widget seems to assume that the String it modifies is only modified by it and lives for the lifetime from the first creation of the widget to the last even though this is not enforced. Create a text box and pass in a new string to TextBox::new() every time the widgets is drawn and two things will happen.

  1. If the cursor is advanced two characters past the end of the string, the program will panic and crash.
  2. If a character is entered that is a different width than the character that will be in front of it the next time the box is rendered, the cursor will advance into the middle of the next character or somewhere past the end of it.

One idea to solve this issue is to give ownership of the String to the text box. My understanding is that this would be associated with the UIID of the text box and stored in a UiContext. So there would also need to be a method to get the string from the UiContext and a way to set the String without interacting with the text box which would properly reset the cursor.

@mitchmindtree
Copy link
Contributor

Thanks for the issue! I wrote TextBox in my early days of rust and it hasn't had much testing, so I appreciate it. Been meaning to come back to conrod and comb over everything, but I've been so busy with a personal project.

The TextBox widget seems to assume that the String it modifies is only modified by it and lives for the lifetime from the first creation of the widget to the last even though this is not enforced.

I'm not quite sure what you mean by this. Are you trying to store the widget by any chance? (I'm not entirely sure if you know this already, but I just thought I'd check) Each widget in Conrod is designed to work in an "immediate mode" style (i.e. it behaves more like a function than an object - there's almost never a reason why you'd want to store a Conrod widget). Here's an example of a typical TextBox usage. You shouldn't have to worry about storing it or maintaining it's state (it will store its own state within the UiContext automatically and retrieve it each time it's constructed by using its unique ID). You may know all this already but just thought I'd clarify.

  1. If the cursor is advanced two characters past the end of the string, the program will panic and crash.
  2. If a character is entered that is a different width than the character that will be in front of it the next time the box is rendered, the cursor will advance into the middle of the next character or somewhere past the end of it.

These sound concerning 😟 The code for cursor movement [is here] if you want to have a look - I'm a few days behind the nightly atm and am unable to build conrod, but I'll have a look soon once I catch up.

@dcampbell24
Copy link
Member Author

What I was trying to say above is that there is an issue because the text that a TextBox displays can be updated without the UiContext being aware that the update has taken place, which is a problem because the x position of the cursor is based on where it was after the last update rather than where it should be in the text based on its index into the string.

In other words, the x position should be re-calculated every time the box cursor is drawn. If the cursor index goes past the end of the text, it should be placed after the last character.

I also notice that text is allowed to go past the end of the text box, but the cursor just stops at the end of the box. I think it would make sense the chop off the text that goes past the end and then either scroll the text as one moves the cursor past the end of the box or have the cursor not be drawn, but semantically continue on past the end on the box into invisible characters.

@dcampbell24
Copy link
Member Author

It looks like #71 answers the question about what should happen when the cursor tries to go past the end of the box in the View section. Closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants