PistonDevelopers / conrod

An easy-to-use, 2D GUI library written entirely in Rust.
Other
3.35k stars 297 forks source link

Filtered Textbox #532

Open TheNeikos opened 9 years ago

TheNeikos commented 9 years ago

I have worked up a small change to the textbox so that one could indicate a filter method that will be called on insert allowing to have some control over what gets put into a textbox.

The changes can be seen here: https://github.com/TheNeikos/conrod/tree/add-filter_to_textbox

However I have not put this as a PR yet because of two things:

  1. Is something like this wanted? In my current project I would definitely find several uses, but if 2 is not resolved it might not be worth it.
  2. This is a breaking change to the TextBox as for now it requires static dispatch (I implemented it like the react callback), it also means if you do not want to filter you will have to write at least:
.filter(|_string: &mut String, _ch: char|{true})

This does not differ from the react callback, but for those that do not want to filter their input it adds more boilerplate. (Which also exists for the react callback, but I believe that react is a lot more used than a potential filter)

Could I have some input on whether to drop/continue working on it and whether it should be dynamic dispatch.

mitchmindtree commented 9 years ago

Thanks @TheNeikos, this is sweet! I think it'd be super useful :)

However perhaps we can hold off on adding this until this and implementing the Fn/FnMut/FnOnce traits becomes stable? That way we could make empty function objects to use as defaults for .react and .filter which would mean a user wouldn't have to deal with the boilerplate if they didn't need it?

Btw, does the .filter method need the &mut String as the first param? It should only need the char right?

TheNeikos commented 9 years ago

@mitchmindtree Thanks for the feedback!

Well I thought about it, but I was thinking of a specific scenario where you could only insert for example 4 lowercase letters and 4 uppercase? I agree that it is an edge case, but I didn't think that it gave a huge downside for all the possible upsides. (And I believe in llvm to optimize that closure!)

And Function Objects sound like the right thing if they are what I believe them to be.