-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Material Design 3 Roadmap #2475
Comments
In previous PR, you said:
Do you want to support both styles at once? Because I'm currently replacing each ResourceDictionary, not appending them. |
@MichelMichels Yes, let me see if I can explain better. Part of not changing or duplicating the namespace is to try to keep some separation between the controls (code) and the Styles/Template (it matches the look-less nature of many WPF components). What I am imagining is something like this (obviously this does not work at the moment): <Window.Resources>
<ResourceDictionary Source="pack://application:,,,/MaterialDesignThemes.Wpf;component/Themes/MaterialDesign3.TextBlock.xaml" />
<ResourceDictionary Source="pack://application:,,,/MaterialDesignThemes.Wpf;component/Themes/MaterialDesign2.TextBlock.xaml" />
</Window.Resources>
....
<TextBlock Style="{StaticResource MaterialDesign3.DisplayLargeTextBlock}" />
<TextBlock Style="{StaticResource MaterialDesign2.DisplayLargeTextBlock}" /> One thing that would go along with that would be adding (not renaming) additional styles with those different key names. The reason for wanting to add additional keys, rather than renaming is to both keep people's existing code working, as well as to make it easy for someone to toggle Material Design 3 styles on by simply adding So for someone's app to "update" to include MD3, my hope would be that they change their App.xaml <materialDesign:BundledTheme BaseTheme="Inherit" PrimaryColor="DeepPurple" SecondaryColor="Lime"
ColorAdjustment="{materialDesign:ColorAdjustment}" />
<ResourceDictionary Source="pack://application:,,,/MaterialDesignThemes.Wpf;component/Themes/MaterialDesignTheme.Defaults.xaml" /> To: <materialDesign:BundledTheme BaseTheme="Inherit" PrimaryColor="DeepPurple" SecondaryColor="Lime"
ColorAdjustment="{materialDesign:ColorAdjustment}" />
<ResourceDictionary Source="pack://application:,,,/MaterialDesignThemes.Wpf;component/Themes/MaterialDesign3.Defaults.xaml" /> This second point I believe is exactly what your existing work accomplishes (which is great!). Hopefully that makes more sense, and thank you for all of your help! |
Thanks for the explanation. How would you handle naming changes for Typography? I'm singling this issue out as I already implemented the Material 3 typography styles for TextBlock and I noticed they are different from the Material 2 guidelines. Wouldn't it be confusing mixing those 2 typography set of styles? On the other hand, if the route of separation is choosen, this would be a fairly large breaking change. |
Good question. So initially when I wrote that, my intention had been to make it so that someone could easily switch over by simply changing their "default" resource dictionary. However, I am realizing now, that is somewhat wishful thinking, as they will also need to go through and update any merged resource dictionaries that are pointing to In one of the next 4.x releases, I would love to create additional styles with the better name. Something like this: <Style
TargetType="{x:Type TextBlock}"
x:Key="MaterialDesign2.BodySmallTextBlock">
<Setter
Property="FontWeight"
Value="Regular" />
<Setter
Property="FontSize"
Value="12" />
<Setter
Property="LineHeight"
Value="16" />
</Style>
<Style
TargetType="{x:Type TextBlock}"
x:Key="MaterialDesignBodySmallTextBlock"
BasedOn="{StaticResource MaterialDesign2.BodySmallTextBlock}" /> That way the old style keys continue to work, but it also allows people the opportunity to use the newer ones if they wish. At some point in the future the old styles could be deleted. I would probably put a copy of the old style keys in the Release notes or similar, so if it did end up being a large breaking change for someone, they could simply pull that into their project and continue working. I am already queuing up breaking changes that will come in the library in the 5.0.0 release, so there is a bit of a decision to make as to exactly when this breaking change should occur. If it is ready (or close to ready) then I might just make it a bigger release and do it all at once (I keep saying that I want to do more frequent smaller releases, and then fail miserably at it...). Otherwise, I think the plan will be to bring in those breaking changes in a 6.0 timeframe. |
@Keboo I like the Maybe we should consider putting the work for Material Design 3 on a different branch as to not clutter the current project until most standing questions are resolved? Or at least communicate that it's currently a WIP. |
I am fine leaving it in for now. For any releases that go out before this item is resolved I will make sure it is noted as a WIP. |
Google has release Material Design 3. The intent here is to outline the needed work to support it in this library.
You can find the latest details here.
All of the tasks listed here can be considered up for grabs and I am happy to accept PRs for any of them.
New control resource dictionaries should be named as:
MaterialDesign3.<ControlName>.xaml
High level changes
At a minimum these tasks and the color changes need to be implemented to start releasing these new styles.
Tasks
MaterialDesignTheme.Defaults.xaml
resource dictionary, it should be calledMaterialDesign2.Defaults.xaml
.MaterialDesignTheme.Defaults.xaml
it should be calledMaterialDesign3.Defaults.xaml
. For all of the new M3 styles, they should get referenced by this resource dictionary.Color
This library already support some amount of the new Dynamic Colors, will need to evaluate the M3 implementation to determine how viable it will be to implement here as well.
Because the color brushes are all going in the same code path (ie will be treated and available at the app level), there will be some un-used brushes depending on which control styles are being used.
Tasks
Typography
There is another font Noto Sans that could be included in this library. Right now the fonts make up a significant percentage of size, this would add approximately 1.3MB. Alternatively we could pull fonts out, and make them opt-in with a csproj flag or similar. I am interested in hearing feedback on this, not sure if file size of the assembly matters much to people.
Tasks
MaterialDesignFontExtension
and name itRobotoFontExtension
.MaterialDesignFontExtension
should be marked as obsolete.NotoFontExtension
(similar to the one above) and include the Noto Sans font files.Buttons
This will be the largest portion of the work as there is quite a bit to do.
Tasks
Cards
The cards here are not that different from the ones in the existing library. We should still copy the style into a new M3 card resource dictionary, but it may initially be the same as the M2 version.
Tasks
Chips
Most of this functionality should already be in place. Just the colors and the corner radius look to be the big differences.
For all of these styles, I suspect a single template could be shared as the look and elements of each of these is pretty similar.
Tasks
Dialogs
For the most part, the dialogs are already done. This library only supports the "Basic dialog" not the "Full screen dialog". For the most part, none of the new features of the dialog affect the DialogHost (our implementation) directly.
Navigation Bar
This is a control has not been implemented. Though happy to accept a PR for it, not a requirement for initial release. See #652 for details.
Navigation Drawer
This is a control has not been implemented. Though happy to accept a PR for it, not a requirement for initial release.
Navigation rail
This is largely done, just a few minor updates to how the selected item appears.
Tasks
Top app bar
This is a control has not been implemented, nor do I believe a very useful control for WPF apps. Happy to hear suggestions and use cases if you think otherwise.
The text was updated successfully, but these errors were encountered: