Elevation Shadow in Dark Mode

[runette]

Description of the Bug

While testing other things I noticed some issues that I am going to raise for information. All of them from the latest master code base and kitchen sink

The first is best expressed as follows

It seems to me that when in Dark Mode - the Elevation shadow should be a light color to contrast with the Dark background. The current dark shadow on a dark background does not do anything.

Versions

• OS: Macos
• Python: 3.9
• Kivy: 2.0.0
• KivyMD: Latest Master

[podraco]

The material IO only specify that the shadows remain drawn in both modes, except when the element is disabled. It should remain the same color and hue they already are. Even so, the elevation class allows developers to change the color of the shadows, it's in its docs.

[runette]

The material IO only specify that the shadows remain drawn in both modes, except when the element is disabled. It should remain the same color and hue they already are. Even so, the elevation class allows developers to change the color of the shadows, it's in its docs.

Hmm - done a bit more research. You are right but also Material Design does say that in Dark Mode, the change in elevation should change the "lightness" of the card - see this https://material.io/design/color/dark-theme.html#properties.

Compare that to what we have - where there is no visible change in elevation in the Dark theme

https://user-images.githubusercontent.com/2239795/108377395-e5bc8780-71fb-11eb-9773-c813e0473f0b.mp4

I am not sure what the answer is.

I am, however, very positive that the "you can change it yourself" response is not the right one. The reason for having the Dark and Light themes in MD and in kivyMD is to provide two well-formed configurations that look good without having to go through the App individually changing the colors. This issue is constructive feedback about that theme and not an issue saying that the color cannot be changed. You CAN change color yourself, just as you can create an MD app without kivymd or a Python GUI without kivy etc, etc. It is just a lot more work - which is why we all work with frameworks.

[podraco]

Well, that behavior was outside the spec of the elevation page, it is true that it should change color, but, it would directly affect every widget if it's included inside the behaviors. Since a great part of kivymd is its modularity. It would be a great addition to MDCard class rather than the elevation behaviors.

[runette]

I understand completely and I guess it is definitely an enhancement - I am just feeding back as a user that there is a gap here

[podraco]

Any feed back is greatly appreciated

[podraco]

Now, how should we proceed? Since , I'm pretty sure people will be using cards with static colors, and this enhancement might get in the way their cards work. Do you have any idea on which would be the best approach?

[HeaTTheatR]

@podraco Wouldn't it be a good idea to use the shadow_color property in the CommonElevationBehavior class?

[podraco]

I'm not certain if that would be a good idea, since each shadow have a different saturation. Which allows people to set a certain strength to the shadows depending on the alpha value.

maybe we could add a base color thats changed if the background style is set to Auto?

so we could accomplish this.

[podraco]

also, for this, we should take in count this spec.

[podraco]

@podraco Wouldn't it be a good idea to use the shadow_color property in the CommonElevationBehavior class?

Also, remember that the BackgroundColorBehavior class now inherits from the CommonElevationBehavior class, it was an update to allow the event dispatcher work the proper way, and cast the background canvas call after the shadow.

[HeaTTheatR]

The issue is deprecated due to the new API of the KivyMD library 2.0.0 version