`Theme` checklist.

[mitchmindtree]

Basic Themes are now implemented #139, but there's still a lot of stuff left to do.

• [ ] json serialization easier customisation/configuration (either some sort of deserialization or perhaps a nice macro).
• [ ] user friendly way of creating / editing themes without touching code (maybe something like .yml?).
• [x] add the option to specify unique styling for each widget rather than just one general style.
• [x] include default widget dimensions in the theme.
• [x] come up with a more elegant way of retrieving style data in widget modules.
• [ ] an example of loading, saving and creating custom themes.

If you think of something feel free to add a comment and I'll add it to the list.

[Spencer-H]

Is yml the preferred theme format? Or would it be reasonable to use CSS, perhaps the crates from Servo for dealing with CSS parsing?

[mitchmindtree]

Hey @Spencer-H, sorry again for missing this and thanks for trying to push this discussion along!

I think fully supporting CSS might be overkill for conrod, however I personally don't have enough experience with it to see how we would map it to the Theme type.

.yml as you mentioned could be a nice possibility. However, if we do opt for de-serialization as the way to write custom Themes, I think my personal preference would be to use the .toml format, seeing as most rustaceans should be familiar with it due to it's use with cargo.

That said, I'm currently leaning towards writing a macro to solve custom themes. Some benefits would include:

• We could make its syntax as ergonomic (or at least close to) the other serialization formats mentioned above.
• We wouldn't require any 3rd party crate dependencies
• The custom Theme could be loaded at compile time rather than from a separate file during run time.
• The user doesn't have to leave rust or learn any other configuration formats.

Would be great to get your thoughts if you're still interested!

[Spencer-H]

It's fine. And as for macros and toml, I assumed that themes would be meant to be something dropped in for a whole system like Qt and GTK themes, I didn't realize we meant for them to be application specific and static. In that case though, a macro makes plenty of sense.

On Aug 28, 2016 4:24 AM, "mitchmindtree" notifications@github.com wrote:

Hey @Spencer-H https://github.com/Spencer-H, sorry again for missing this and thanks for trying to push this discussion along!

I think fully supporting CSS might be overkill for conrod, however I personally don't have enough experience with it to see how we would map it to the Theme type.

.yml as you mentioned could be a nice possibility. However, if we do opt for de-serialization as the way to write custom Themes, I think my personal preference would be to use the .toml format, seeing as most rustaceans should be familiar with it due to it's use with cargo.

That said, I'm currently leaning towards writing a macro to solve custom themes. Some benefits would include:

• We could make its syntax as ergonomic (or at least close to) the other serialization formats mentioned above.
• We wouldn't require any 3rd party crate dependencies
• The custom Theme could be loaded at compile time rather than from a separate file during run time.
• The user doesn't have to leave rust or learn any other configuration formats.

Would be great to get your thoughts if you're still interested!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PistonDevelopers/conrod/issues/140#issuecomment-242962812, or mute the thread https://github.com/notifications/unsubscribe-auth/AOQ2a5XxumOUtk8w5P7ZipX6a804VIalks5qkUXUgaJpZM4Cu7re .

[louy2]

+1 for CSS. Maybe also a step in the direction of a XML based layout description language that's all the hype these days in GUI dev, from WAML.C# to HTML.Electron to QML.QtQuick.

[drunkwcodes]

There is a Rust implementation of CSS Syntax Level 3.

https://github.com/servo/rust-cssparser