I’m working on a multiplayer game project, and I am currently evaluating (and leaning heavily towards using) Lemur for the client’s UI. I’m working on sketching out the client’s start screen, which for now consists of a TextField for the username and another TextField for the password. Naturally, I do not want the password to be visible while the user is typing it in - the field should be filled with **** or something like that. I looked through the Lemur wiki and the Lemur/Lemur Proto Javadocs without finding any suggestions or hints on how to achieve this.
I’ve thought of a couple of ways to make a hidden password field: (a) subclass TextField/DocumentModel to support this, or (b) do some input listener trickery to fetch each character as it’s typed and replace it with a dummy character, building up the actual password string in a separate control.
Is there a standard “Lemur way” to do things like this that I’m just missing, or do I just need to come up with something on my own?
There is not yet a standard way but it is high on my to-do list because I need it also.
Most likely way would be to have a special PasswordField subclass of TextField that swaps out the TextEntryComponent for one that just displays * for every character in the DocumentModel.
I figured I’d get cracking on doing this and pass it along to you as a contribution if you wanted it. (Or wind up with a password field for myself if you didn’t )
This makes sense, but I fail to see a good OO way to do this right now. I looked at the TextEntryComponent source and it only sets the BitmapText value in one place, making it easy to override. However, TextEntryComponent keeps the BitmapText instance private so it’s not possible to do that without using reflection (a really horrible hack). Without the overridden TextEntryComponent, the PasswordField really can’t do a whole lot. With the TextEntryComponent the way it is now the only way I see to accomplish this is copy-pasting the source and changing the one line to fill the BitmapText with asterisks, which seems pretty clunky. I tried this, but quickly ran into a host of issues related to various bits of Lemur expecting a TextEntryComponent without being able to properly subclass a new implementation of it.
Yeah, that may be true. Hopefully I can look at it this weekend.
It also kind of bugs me that TextEntryComponent doesn’t just defer to a TextComponent for its display. There may be some refactoring in order. (TextEntryComponent is my least favorite lemur code from a design deficit point of view.)
Thanks, let me know if I can help out with testing or anything.
That design makes sense to me, and I think it would make the text entry/display system more powerful for handling corner cases (like hiding passwords) since input and display would be decoupled.
)