Styles vs Themes Namespaces

[amkuchta]

Is your feature request related to a problem? Please describe.

Within MA.M, there are two separate namespaces for Theme vs Style (which also contains a Theme directory). This is not intuitive, as the Theme Directory contains some styles (e.g. HamburgerMenu), and the actual themes for the application are located in the Style/Theme directory.

Describe the solution you'd like

I suggest re-ordering the name spaces as follows:

• Move the application theme and accents under MA.M/Themes
• Move all styles under MA.M/Styles; include custom templates in the file with the appropriate themes (e.g. HamburgerMenuTemplate belongs in Styles/Controls.HamburgerMenu.xaml)

This makes it much easier to find the code needed to make an update to a control for a user's personal implementation. It also makes application theme information much easier to find, as it is in the most logical location.

Additional context

N/A

Closed Issues

N/A

[amkuchta]

I could also see creating a new directory or set of directories specifically for templates:

• MA.M/Templates or
• MA.M/Templates/ControlTemplates and MA.M/Templates/DataTemplates or
• MA.M/ControlTemplates and MA.M/DataTemplates

These could also be nested in Styles:

• MA.M/Styles/Templates or
• MA.M/Styles/Templates/ControlTemplates and MA.M/Styles/Templates/DataTemplates or
• MA.M/Styles/ControlTemplates and MA.M/Styles/DataTemplates

A more extreme approach would be to create sub-directories or naming conventions for each control type:

• MA.M/Styles/Button/Button.Styles.xaml and MA.M/Styles/Button/Button.Templates.xaml
• MA.M/Styles/HamburgerMenu/HamburgerMenu.Styles.xaml and MA.M/Styles/Button/HamburgerMenu.Templates.xaml
• etc.

or (I personally find this one the easiest to read / navigate, and it strikes a great balance between separation and not having to nest things down too many directory layers):

• MA.M/Styles/Button.Styles.xaml and MA.M/Styles/Button.Templates.xaml
• MA.M/Styles/HamburgerMenu.Styles.xaml and MA.M/Styles/HamburgerMenu.Templates.xaml
• etc.

Again, although the separation will be difficult and tedious now, it makes things much easier to find later down the line, not just for users, but for future contributors. One of the things I struggle with the most (even as a long time user of the library) is finding where the exact item is that I need to change.

[bigworld12]

this has been bugging me for years, it is so hard to find a specific style or a template without searching every folder in the project, would love to see that change, i also agree on the last convention you proposed. (MA.M/Styles/Button.Styles.xaml and MA.M/Styles/Button.Templates.xaml)

[amkuchta]

@punker76 how do you feel about this? I can start tackling it, but given the scope of the changes, I am worried that it will affect the work that you are putting in with regards to #3585 . If you don't think it will mess you up, I can take a swing at this.

[punker76]

@amkuchta I’m still investigating this, how we can provide this in an easy way. The upcoming Visual Studio will help us, because it has a better Intellisence for own resource dictionaries included. R# helps me and other since years. So please wait for a change for this issue. I’m not a friend for such a big change of separating each style and template to it’s own file. Thx

[amkuchta]

@punker76 I agree that improved Intellisense will help, but that does not help advanced users who have to search through the code to find entire templates or styles that they may need to override (or modify in a way that requires copying large chunks of code). For that reason, I think that a refactor should occur, especially since there are multiple locations where directories like Styles and Themes occur.