Provided Backend trait Implementations - via features or separate crates?

[mitchmindtree]

In #696 I'm adding a new Backend trait to consolidate the set of types and bounds necessary to run an instance of conrod.

As the piston_window crate is used in our examples and will likely be most commonly used by users as a result, I'd like to provide an implementation of the Backend trait for piston_window. It might also be nice to provide backends for other crates in the future also.

I'm currently torn between two ways of doing this:

1. Add a backend::piston_window module behind a feature called backend-piston_window.
2. Add a backends directory with a conrod-piston_window crate (within this repository).

I'm currently leaning towards option 1. for a few reasons:

• The upcoming required-features key for targets will make this very nice to use and give friendly errors when the necessary feature isn't enabled when trying to run examples.
• Don't have to re-arrange the repo. Option 2 would require refactoring the repo into a hierarchy similar to the gfx repo so that the examples may depend on conrod-piston_window.
• It should leave the repo in a simpler, more approachable state for newcomers (without functionality spread across multiple crates).
• Only have to version and publish one crate.

@bvssvni @kvark I'm interested to get your thoughts on this as both of you have experience with managing large multi-crate repos!

If anyone else has any thoughts on this feel free to add them 👍

[kvark]

I think our multi-crate way at GFX works out pretty nice. Can't comment on the features approach, since I haven't used them much, but maybe @tomaka can share his experience.

[bvssvni]

Is it possible to have a blanket impl for Window in pistoncore-window? I would prefer not depending on piston_window, since it is meant to be a window wrapper.

[bvssvni]

I have an idea: http://is.gd/p6MwOJ

Implement Backend for a tuple, then use a type Ui = conrod::Ui<(Texture, CharacterCache)>; in the application.

When we get type macros, this pattern can be used with more complex backend traits.

[kvark]

@bvssvni reminds me of our formats:

                impl Formatted for ($name, $channel) {
                    type Surface = $name;
                    type Channel = $channel;
                    type View = $container< <$channel as ChannelTyped>::ShaderType >;
                }

[mitchmindtree]

Ohhhh niccceee, this blanket impl for (T, C) idea sounds like a much better solution! Going to give it a shot and will let you know how it goes.

[mitchmindtree]

I've gone with the blanket impl in #696 and it seems like a much better solution than either of those I originally mentioned in this issue, as it doesn't require features or extra crates and still allows for users to impl Backend for their own fancy types 👍

[bvssvni]

@kvark Yeah, got the idea from Gfx.