Phil Fried

I opened up [this PR](https://github.com/PistonDevelopers/conrod/pull/618) as a first draft of how this could work. Currently, this works as follows: ``` let mut focus_next: Option = None; TextBox::new(&mut my_string) .react(|new_val| {...

@mitchmindtree I like that idea! Definitely adding whatever method to `UiCell` makes sense, too. Doesn't seem like Widgets should really ever interact with the `Ui` directly. I'm thinking, though, that...

@bvssvni Scratch I like this idea, too. Just assigning a tab order sounds better. Then the widget graph could just keep track of all the tab orders and provide the...

I finally got around to really working on this, and it's going to be a rather large pull request when it's done. I've struggled to find a clean way of...

@Yamakaky Yeah, exactly. It's probably easy enough to do that it wouldn't be all that bad to just add that boilerplate into every project that uses Futures, but I'm wondering...

Good idea about using the `Carrier` trait once it's stabilized. Yeah, I can take a stab at it and send a PR over.

You mean in the futures crate? I don't think it could really be implemented there since the trait is defined in the macro, right?

5 minutes ago, I didn't see any problems with that, but now I've realized that it probably can't work. The problem I see is that a `Future` doesn't itself represent...

Sure. In the example, the methods in `tokio_core::io` all return `Future`s where the error type is `std::io::Error`, but `my_future_fn` returns a `Future` with an associated error type of, `MyError`. ```rust...

I found this issue after running into the same problem with a Rust library that's being called from Go. I wrote a little test program and was able to confirm...