Material.ButtonStyle="Contained"
. One thing to note with this is that Android will be hard, if not impossible, to dynamically change. iOS just has a theme that you apply (not so sure if it supports undoing a style and may not actually work). Android has a style resource that probably needs to be applied in the constructor of the renderer. To support dynamic changes like this, we will probably not be able to use the "fast renderer" style and would need to use the ViewRenderer<T, T>
base. iOS is already using this, so we can always recreate the control, but for Android we may lose the optimizations gained.```XAML
````
Attached properties can easily be split up according to the Element it's going to be applied to.
having to import custom namespaces is cumbersome for developers.
Because dotnet MAUI inverts the dependencies and now a Button knows about its renderer we could use that detail to customize visual
https://github.com/dotnet/maui/issues/28
```XAML
````
Once we have xplat controls we could also use this same technique
```XAML
````
If the user specifies a MaterialButtonTemplate than they don't have to specify the Material Visual. This doesn't obsolete Visual though because Visual is still used to hierarchically style an application. When you apply Visual at the parent level it will indicate what control template to use down the hierarchy
```XAML
````
```XAML
````
This could possibly be extended to enabling users to set native properties as well
```XAML
````
Specifying visual attached properties in css will take the following format
visual-material-button-style
Hi, here from the .NET Standup Video which mentioned this PR.
I love this feature :heart:
Would it be possible to specify something at the App level to auto-import the material
namespace into the Views?
like App.UseMaterial = true;
Then you could have something like:
<Button MaterialStyle="Outline"></Button>
Also, regarding :
One thing to note with this is that Android will be hard, if not impossible, to dynamically change
What do you mean specifically by this? Do you mean the styles.xml
file android uses?
Ooo I like the suggestion in #5487 , around the assembly-level attribute attach.
@arggrande something like
<Button MaterialStyle="Outline"></Button>
Is a possible option. If we were to put all the material things into the same namespace then you wouldn't need the prefix. My only concern with this was discoverability or possibly having too many things show up by default
MaterialEditorProp1, MaterialEditorProp2, MaterialEditorProp3,
MaterialButtonProp1, MaterialButtonProp2, etc...
whereas with
material:Editor.Prop1
A conditional like you have is an interesting thought. I wonder if we could just enable intellisense if you set the visual
that'd be kind of neat
@PureWeen we can use new XmlnsDefinitionAttribute to combine multiple CLR namespace with single XML namespace
@pranshaggarwal Right! Which is a good point. Because we could just leave it in its own namespace and then if people wanted to just combine them they could
One Question, Doesn't this code make the xml invalid?
<Button MaterialStyle="Outline"></Button>
@pranshaggarwal yes :-/ that wasn't one of the case I had even initially proposed and just wasn't thinking of it straight when I commented above.
My main point with that still stands even with using XmlnsDefinitionAttribute
I wonder if that will put too many properties under one place
Material.ButtonStyle vs material:Button.Style
I played around with it a little bit here with using XmlnsDefinitionAttribute
https://github.com/xamarin/Xamarin.Forms/tree/visual_buttonstyle
The other nuance of XmlnsDefinitionAttribute is that the cross platform library has to have an init call or something calling into Xamarin.Forms.Material otherwise it runs into issues with the linker.
For example if you just call init on the platform project then the cross platform fails to compile with a namespace not found exception
@PureWeen yes you are right, XmlnsDefinitionAttribute will not solve this problem.
Another option is to defines all the attached property in their respective class then have a clone of all the properties in one class(Material).
Btw if we are able to somehow simplify the attached property syntax as I describe here #5487 then we will not have to worry about this.
to avoid reinventing the wheel again and again, I'd go for something very similar to PlatformSpecific
<Button m:Button.Style="Outline" />
everyone being able to redefine his own MaterialButton and include the properties directly. This is also what gives us the best options to move forward if we decide at some point to move the Material Style property directly to the Button class
I really like the simplicity of these especially @StephaneDelcroix cut down version to save on keyboard strokes after all you only have so many key presses in your life.
However I think that to have Button twice inside the statement is a waste so maybe something like:
<Button m:style="Outline" />
It's short sweet and to the point, maybe you could INCLUDE the longer version as well for readability:
<Button Material:style="Outline" />
just my thoughts, but great work and really like it.
Will style Outline make icon stick to left border of button?
I need to have icon to have constant location from left when i have a couple of buttons with images and different text, example use case:
Currently Material button shows icon this. Which kind of looks ugly:
Something I don't think I've seen discussed - where will the attached properties be defined? I notice that there is currently no cross-platform project included in the Xamarin.Forms.Visual.Material package. Maybe adding one would be the ideal place, so as to not clutter up the namespaces of people not using Material.
@jcmanke Yea! This was one of the reasons for naming the DLLs all the same as well so material would just bait and switch. In a perfect world the material projects would just be one multi targeted project but that support isn't quite there yet from the IDE. So at this point we'll most likely just have a file that gets linked into each material project
Leading and trailing icons are going to be a problem on text fields until xamarin/AndroidSupportComponents#201 is resolved.
I added another option based on our conversations this past week
If the user specifies a MaterialButtonTemplate than they don't have to specify the Material Visual. This doesn't obsolete Visual though because Visual is still used to hierarchically style an application. When you apply Visual at the parent level it will indicate what control template to use down the hierarchy
```XAML
````
@PureWeen I feel like if XF Visual Material could integrate with this WPF XAML Material Design Library, that would solve all of the issues. I'm currently using it for my WPF apps and it's amazing how much control I have!
https://github.com/MaterialDesignInXAML/MaterialDesignInXamlToolkit
Yea! We'd looked at that a little with WPF and that would be really cool
Now if only someone would finish the UWP part of that one
Yeah that's a downside I guess :/
Most helpful comment
to avoid reinventing the wheel again and again, I'd go for something very similar to PlatformSpecific
everyone being able to redefine his own MaterialButton and include the properties directly. This is also what gives us the best options to move forward if we decide at some point to move the Material Style property directly to the Button class