Status Update
Comments
cl...@google.com <cl...@google.com>
ve...@gmail.com <ve...@gmail.com> #2
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
kp...@gmail.com <kp...@gmail.com> #3
hl...@gmail.com <hl...@gmail.com> #4
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
ks...@gmail.com <ks...@gmail.com> #5
ri...@gmail.com <ri...@gmail.com> #6
sh...@gmail.com <sh...@gmail.com> #7
ej...@gmail.com <ej...@gmail.com> #8
de...@gmail.com <de...@gmail.com> #10
op...@gmail.com <op...@gmail.com> #11
ma...@gmail.com <ma...@gmail.com> #12
ra...@gmail.com <ra...@gmail.com> #13
Yu...@icloud.com <Yu...@icloud.com> #14
ai...@googlemail.com <ai...@googlemail.com> #15
Would be good to see this in Compose also.
ri...@gmail.com <ri...@gmail.com> #16
The important thing is that we should be backward compatible, this is androidx after all
ta...@gmail.com <ta...@gmail.com> #17
ez...@gmail.com <ez...@gmail.com> #18
+1
Android 28 (Pie) added support for custom shadows. It's very strange that, 2 years later, MDC for Android still don't support it.
And it's even stranger why a freshly made UI toolkit like Compose did not account for custom shadows.
mo...@google.com <mo...@google.com> #19
Which features do you want from the shadow that Compose doesn't provide? I thought that we had supported most of Android's shadow capabilities.
nj...@google.com <nj...@google.com> #20
I think the main feature request is to be able to color the shadows. Right now they are always the grey/blackish ones. Framework introduced both ambient and spot color shadows back in API level 28 I believe
ai...@gmail.com <ai...@gmail.com> #21
I don't think it's a problem with the support of Android Framework shadows, it's already a problem on the framework itself, the main request (at least for me) to implement custom shadows only for Compose which are more flexible than Framework ones, even if they are not as performant as ones provided by the framework, after all, ad-hoc implementation will be probably even less performant than officially supported modifier for shadows.
Maybe it worth keeping drawShadow as it is and introduce an additional modifier like drawCustomShadow, so it will be more clear that it doesn't use an optimized version of shadows.
ja...@gmail.com <ja...@gmail.com> #22
Colors, positions and offsets. For all API levels and desktop as previous comment said.
nj...@google.com <nj...@google.com> #23
It is important to note that shadows in the framework are consistent with a singular light source placed in a virtual space above the top of the display. This ensures that shadows are rendered consistently with content to the left/right closer/further away from the content as well. This configuration is more part of the rendering environment vs configuration of parameters for a single drawing instruction like drawRect. This is what makes positions and offsets less likely to be configurable vs color information.
ja...@gmail.com <ja...@gmail.com> #24
IMO a multiplatform library should allow more things, not only material one.
If I want to create a neumorphism theme I will have to do from scratch.
Why all future targets of compose have to place the light in the same exact point?
I can understand how shadows have to work if using material, but the generic one should be more flexible.
ai...@gmail.com <ai...@gmail.com> #25
Such behavior of shadows makes sense in the context of Material design paradigm but makes it less controllable by developers.
When in most of cases I want to replicate a design from my design team, and shadow is just an instrument for me to emulate shadows from their design tool (photoshop/figma/sketch etc), and they not only do not use single light source, but often used shadows in different cases and with different settings, which now is hard to emulate (or possible, but tedious and require usage of custom drawables or custom rendering)
I would expect drawShadow modifier (or some additional) which works closer to
ri...@gmail.com <ri...@gmail.com> #26
That's right. This design requirement exists between many development teams, should not allow everyone to follow Material Design, this will reject many people, I really hope that Compose can do better than Flutter, in the current point of view, Compose is really bad than Flutter in addition to Kotlin this feature..
m....@futuremind.com <m....@futuremind.com> #27
I strongly support that - shadows are a general design thing, not material design specific. Compose allows for theming outside of material design paradigm, same principle should be applied to shadows.
se...@gmail.com <se...@gmail.com> #28
[Deleted User] <[Deleted User]> #29
wi...@gmail.com <wi...@gmail.com> #30
gu...@gmail.com <gu...@gmail.com> #31
ig...@gmail.com <ig...@gmail.com> #32
df...@hotmail.com <df...@hotmail.com> #33
wo...@gmail.com <wo...@gmail.com> #34
[Deleted User] <[Deleted User]> #35
li...@gmail.com <li...@gmail.com> #36
[Deleted User] <[Deleted User]> #37
se...@gmail.com <se...@gmail.com> #38
Please stop spamming "+1". This only creates noise in notifications. Press the ⭐ button and stay calm.
sn...@gmail.com <sn...@gmail.com> #39
ch...@gmail.com <ch...@gmail.com> #40
do...@gmail.com <do...@gmail.com> #41
ke...@gmail.com <ke...@gmail.com> #42
ra...@gmail.com <ra...@gmail.com> #43
ne...@gmail.com <ne...@gmail.com> #44
ci...@gmail.com <ci...@gmail.com> #45
du...@gmail.com <du...@gmail.com> #46
ni...@gmail.com <ni...@gmail.com> #47
tu...@gmail.com <tu...@gmail.com> #48
mb...@gmail.com <mb...@gmail.com> #49
kt...@threenitas.com <kt...@threenitas.com> #50
na...@gmail.com <na...@gmail.com> #51
la...@gmail.com <la...@gmail.com> #52
ze...@gmail.com <ze...@gmail.com> #53
+1
zo...@gmail.com <zo...@gmail.com> #54
ry...@gmail.com <ry...@gmail.com> #55
Do not +1.
Star the issue instead. This isn't a forum.
sh...@gmail.com <sh...@gmail.com> #56
ra...@gmail.com <ra...@gmail.com> #57
so...@gmail.com <so...@gmail.com> #58
di...@gmail.com <di...@gmail.com> #59
zh...@gmail.com <zh...@gmail.com> #60
ta...@mercury.com <ta...@mercury.com> #61
Here's a change request to add the ambientShadowColor
and spotShadowColor
layer properties and expose them via GraphicsLayerScope
:
If desired, the Surface
, Card
, Button
, etc. layouts could then expose these values before passing them on to GraphicsLayerModifier
, but this is usable with custom layouts in non-Material design systems.
ri...@gmail.com <ri...@gmail.com> #62
Unfortunately, they need to run on android greater than sdk28, which is far from androidx compose's argument for minimum support for sdk21.
I mean compose is a androidx ui toolkit rather than a system-level framework, so it should be backwards compatible, at least compatible to the same level as the compose core, instead of letting people implement different codes for different android versions when using it.
ta...@mercury.com <ta...@mercury.com> #63
Re: #62:
Compose already supports RenderEffect for blurring graphics layers, which was added in API 31, so that argument wouldn't be consistent with what Compose currently supports.
ri...@gmail.com <ri...@gmail.com> #64
Compose already supports RenderEffect for blurring graphics layers, which was added in API 31, so that argument wouldn't be consistent with what Compose currently supports.
emm...Yes, I know that, maybe it is the technical difficulties of the lower version implementation that makes it impossible to use other methods to achieve backwards compatibility, so I am a little disappointed
po...@gmail.com <po...@gmail.com> #65
na...@gmail.com <na...@gmail.com> #66
ks...@gmail.com <ks...@gmail.com> #67
+1
ou...@gmail.com <ou...@gmail.com> #68
de...@gmail.com <de...@gmail.com> #69
al...@gmail.com <al...@gmail.com> #70
an...@gmail.com <an...@gmail.com> #71
su...@gmail.com <su...@gmail.com> #72
ap...@google.com <ap...@google.com> #73
Branch: androidx-main
commit eb5a07a3e10da9818d386fa9533372fd4316ddaa
Author: Nader Jawad <njawad@google.com>
Date: Fri Mar 04 16:30:21 2022
Minor tweaks to support shadow colors
Updated ReplaceWith usage to pull in proper import
Ran ignoreApiChange to handle deprecationlevel hidden
deprecation instances.
Relnote: "Updated shadow/ambient colors to be trailing
parameters of Modifier.graphicsLayer for API compatibility
Added default implementations to shadow/ambient color on
GraphicsLayerScope to ensure non-breaking API changes"
Moved spot/ambientShadowColor parameters to the end
of argument lists to avoid breaking existing usages
of Modifier.graphicsLayer
Bug: 160665122
Test: re-ran compose tests
Change-Id: I3f8645838aa5b8dc9e5ef22dc112329abcc46b55
M compose/ui/ui/api/restricted_current.ignore
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/graphics/GraphicsLayerScope.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/OwnedLayer.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeLayer.android.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/AndroidLayoutDrawTest.kt
M compose/ui/ui/src/desktopTest/kotlin/androidx/compose/ui/platform/SkiaLayerTest.kt
M compose/ui/ui/src/skikoMain/kotlin/androidx/compose/ui/platform/SkiaLayer.skiko.kt
M compose/ui/ui/api/current.txt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/draw/Shadow.kt
M compose/ui/ui/src/test/kotlin/androidx/compose/ui/node/LayoutNodeTest.kt
M compose/ui/ui/api/current.ignore
M compose/ui/ui/api/restricted_current.txt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeApi23.android.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/ViewLayer.android.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/input/pointer/HitPathTrackerTest.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/graphics/GraphicsLayerModifier.kt
M compose/ui/ui/api/public_plus_experimental_current.txt
ap...@google.com <ap...@google.com> #74
Branch: androidx-main
commit 8edcbf9e0b6d057d1108040206dff5d5dae70049
Author: Tad Fisher <tadfisher@gmail.com>
Date: Thu Jan 20 12:54:38 2022
Add ambientShadowColor and spotShadowColor layer properties
Relnote: compose-ui: Add ambientShadowColor and spotShadowColor properties to GraphicsLayerScope
Test: GraphicsLayerModifierTest.kt, ShadowTest.kt
Bug: 160665122
Change-Id: I1ba1a4da6942817ad8593fc9052060d7c48b3064
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/graphics/GraphicsLayerScope.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/AndroidLayoutDrawTest.kt
M compose/ui/ui/src/desktopTest/kotlin/androidx/compose/ui/platform/SkiaLayerTest.kt
M compose/ui/ui-android-stubs/api/public_plus_experimental_current.txt
M compose/ui/ui/src/skikoMain/kotlin/androidx/compose/ui/platform/SkiaLayer.skiko.kt
M compose/ui/ui/api/current.txt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeApi29.android.kt
M compose/ui/ui/src/test/kotlin/androidx/compose/ui/node/LayoutNodeTest.kt
M compose/ui/ui-android-stubs/api/current.txt
M compose/ui/ui-android-stubs/src/main/java/android/view/RenderNode.java
M compose/ui/ui/api/restricted_current.txt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/DeviceRenderNode.android.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/ViewLayer.android.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/graphics/GraphicsLayerModifier.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/input/pointer/HitPathTrackerTest.kt
M compose/ui/ui-android-stubs/api/restricted_current.txt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/OwnedLayer.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeLayer.android.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/draw/GraphicsLayerModifierTest.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/draw/Shadow.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/draw/ShadowTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeApi23.android.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/LayoutNodeWrapper.kt
M compose/ui/ui/api/public_plus_experimental_current.txt
sk...@stripe.com <sk...@stripe.com> #75
ka...@dext.com <ka...@dext.com> #76
ma...@gmail.com <ma...@gmail.com> #77
pa...@gmail.com <pa...@gmail.com> #78
di...@mindera.com <di...@mindera.com> #79
ti...@gmail.com <ti...@gmail.com> #80
+1
st...@gmail.com <st...@gmail.com> #81
ma...@gmail.com <ma...@gmail.com> #82
ci...@gmail.com <ci...@gmail.com> #83
ca...@gmail.com <ca...@gmail.com> #84
ph...@gmail.com <ph...@gmail.com> #85
It's pretty weird, if I understand the comment
I understand this has to do with Material single light source, but I believe that Compose as a UI framework should not be restricted by Material guidelines. Elevation is something only Material related, and it seems more appropriate for Modifier.shadow(elevation = ...)
to be inside androidx.compose.material
, and androidx.compose.material
could have a modifier that is independent of light source or elevation, and can be configured.
It is very strange to limit this possibility, because for the most part there are no restrictions on creating non Material UI on Android. Often apps are made with platform-independent designs, and it should be possible to create them as designed.
The only possibility to draw a shadow, which I found, on older devices requires to turn off hardware acceleration, as well as has a number of limitations during the animation.
This is by far the most popular issue of Compose, which shows how much people really need this kind of feature.
mi...@gmail.com <mi...@gmail.com> #86
On top of it I also don't understand why compose must be a limb version of View system. If a feature is not in View we don't get something here. For example we cannot use Concave shapes although it worked on early 1.0 versions but was stripped to match View system.
Same in this topic. We need new features to be able to create projects as they were designed.
we...@gmail.com <we...@gmail.com> #87
wa...@gmail.com <wa...@gmail.com> #88
mf...@gmail.com <mf...@gmail.com> #89
vc...@gmail.com <vc...@gmail.com> #90
any upd?
a....@futuremind.com <a....@futuremind.com> #91
mr...@gmail.com <mr...@gmail.com> #92
at...@gmail.com <at...@gmail.com> #93
ba...@gmail.com <ba...@gmail.com> #94
I do not understand why there has to be a virtual global singlular light source in order to cast shadows? The reason why we have that in the real world is because we do have actual physical light sources in the environment that we are able to perceive. But having a virtual one on your screen that you cannot actually see or perceive is just non-intuitive. Unless you try to also include real world light source detection, it is very stupid to have a mandatory virtual light source in the design system.
pa...@gmail.com <pa...@gmail.com> #95
Definitely agree with
This has always sounded to me as "over-designeered"
ma...@arsaga.jp <ma...@arsaga.jp> #96
+1
fr...@gmail.com <fr...@gmail.com> #97
+1 Shadows near the edge look like garbage on big screens like tablets. The "single global light" idea just doesn't look good. I only want box-shadows like css.
di...@gmail.com <di...@gmail.com> #98
te...@gmail.com <te...@gmail.com> #99
ab...@decentury.io <ab...@decentury.io> #100
+1 It's so disappointing that we can't use colored shadows in the View system, but more disappointing is that we can't do it in Compose also!
to...@gmail.com <to...@gmail.com> #101
ro...@gmail.com <ro...@gmail.com> #102
ol...@gmail.com <ol...@gmail.com> #103
eb...@gmail.com <eb...@gmail.com> #104
xd...@gmail.com <xd...@gmail.com> #105
Css supports box shadow even on android, iOS supports box shadow. Why on Earth don't we have box shadow in any way on Android/Compose?
It could be a 28+ only api, or something experimental. What I see now looks like google is pretending that elevation is enough, despite the fact that it is a material specific mechanic
da...@gmail.com <da...@gmail.com> #106
CSS box-shadow
-like Modifier
implementation
In response to
This modifier must be placed before any contents (including background
) or the shadow covers the contents.
Usage example
Draws a cyan rounded rectangle with a soft drop shadow. When pressed, the shadow is blurred even more (the animation demonstrates performance of this implementation; in fact, on my physical device, even in debug mode it looks as smooth as my eyes can see).
@Composable
fun App() {
AppTheme {
Column(
modifier = Modifier
.systemBarsPadding()
.padding(24.dp)
) {
val interactionSource = remember { MutableInteractionSource() }
val isPressed by interactionSource.collectIsPressedAsState()
Box(
modifier = Modifier
.size(100.dp, 70.dp)
.boxShadow(
color = Color.Black.copy(alpha = 0.24f),
blurRadius = animateDpAsState(
targetValue = when {
isPressed -> 12.dp
else -> 6.dp
}
).value,
offset = DpOffset(x = 0.dp, y = 4.dp),
shape = RoundedCornerShape(size = 8.dp)
)
.background(Color.Cyan)
.clickable(
interactionSource = interactionSource,
indication = LocalIndication.current
) {}
)
}
}
}
Implementation
/**
* Applies a shadow to the current box.
*
* @param color The color of the shadow.
*
* @param blurRadius The larger this value, the bigger the blur, so the shadow
* becomes bigger and lighter.
* If set to `0`, the shadow's edge is sharp.
*
* @param spreadRadius Positive values will cause the shadow to expand and grow
* bigger, negative values will cause the shadow to shrink.
*
* @param offset Offsets the shadow from the box.
*
* @param shape The shape of the box, which is applied to the shadow as well.
*
* @param clip Whether to clip the content to [shape].
*
* @param inset Whether the shadow should be inset to [shape]; otherwise, it is
* a drop shadow.
*
* @exception IllegalArgumentException Any of the following conditions holds:
* - [color] is [Color.Unspecified],
* - [blurRadius] is [Dp.Unspecified] or negative,
* - [spreadRadius] is [Dp.Unspecified],
* - [offset] is [DpOffset.Unspecified].
*/
@Stable
fun Modifier.boxShadow(
color: Color,
blurRadius: Dp,
spreadRadius: Dp = 0.dp,
offset: DpOffset = DpOffset.Zero,
shape: Shape = RectangleShape,
clip: Boolean = true,
inset: Boolean = false
): Modifier {
require(color.isSpecified) { "color must be specified." }
require(blurRadius.isSpecified) { "blurRadius must be specified." }
require(spreadRadius.isSpecified) { "spreadRadius must be specified." }
require(blurRadius.value >= 0f) { "blurRadius can't be negative." }
require(offset.isSpecified) { "offset must be specified." }
return drawWithCache {
onDrawWithContent {
if (inset)
drawContent()
drawIntoCanvas { canvas ->
val colorArgb = color.toArgb()
val hasBlurRadius = blurRadius.value.let { it.isFinite() && it != 0f }
val paint = Paint()
paint.asFrameworkPaint().let { frameworkPaint ->
if (hasBlurRadius) {
frameworkPaint.maskFilter = BlurMaskFilter(
blurRadius.toPx(),
BlurMaskFilter.Blur.NORMAL
)
}
frameworkPaint.color = colorArgb
}
val spreadRadiusPx = spreadRadius.toPx().let { spreadRadiusPx ->
when {
inset -> -spreadRadiusPx
else -> spreadRadiusPx
}
}
val hasSpreadRadius = spreadRadiusPx != 0f
val size = size
val layoutDirection = layoutDirection
val density = Density(
density = density,
fontScale = fontScale
)
val shadowOutline = shape.createOutline(
size = when {
hasSpreadRadius -> size.let { (width, height) ->
(2 * spreadRadiusPx).let { outset ->
Size(
width = width + outset,
height = height + outset
)
}
}
else -> size
},
layoutDirection = layoutDirection,
density = density
)
val nativeCanvas = canvas.nativeCanvas
val count = nativeCanvas.save()
if (inset) {
val boxOutline = when {
hasSpreadRadius -> shape.createOutline(
size = size,
layoutDirection = layoutDirection,
density = density
)
else -> shadowOutline
}
canvas.clipToOutline(boxOutline)
val bounds = boxOutline.bounds
nativeCanvas.saveLayer(
bounds.left,
bounds.top,
bounds.right,
bounds.bottom,
NativePaint().apply {
colorFilter = ColorMatrixColorFilter(
ColorMatrix(
floatArrayOf(
1f, 0f, 0f, 0f, 0f,
0f, 1f, 0f, 0f, 0f,
0f, 0f, 1f, 0f, 0f,
0f, 0f, 0f, -1f, 255f * color.alpha
)
)
)
}
)
}
canvas.translate(
dx = offset.x.toPx() - spreadRadiusPx,
dy = offset.y.toPx() - spreadRadiusPx
)
canvas.drawOutline(
outline = shadowOutline,
paint = paint
)
nativeCanvas.restoreToCount(count)
}
if (!inset)
drawContent()
}
}.run {
when {
clip -> clip(shape)
else -> this
}
}
}
fun Canvas.clipToOutline(
outline: Outline,
clipOp: ClipOp = ClipOp.Intersect
) {
when (outline) {
is Outline.Generic ->
clipPath(path = outline.path, clipOp = clipOp)
is Outline.Rectangle ->
clipRect(rect = outline.rect, clipOp = clipOp)
is Outline.Rounded ->
clipPath(
path = Path()
.apply { addRoundRect(outline.roundRect) },
clipOp = clipOp
)
}
}
ma...@gmail.com <ma...@gmail.com> #107
However the IDE throws the error saying method not found for - canvas.clipToOutline(boxOutline)
Any suggestions?
da...@gmail.com <da...@gmail.com> #108
Oh, sorry, I forgot to share that method as well. Just edited my post to include the implementation of clipToOutline
, which is pretty trivial.
ts...@thinkdesquared.com <ts...@thinkdesquared.com> #109
ra...@gmail.com <ra...@gmail.com> #110
We generate the entire design system with Figma, for shadows figma uses x-axis, y-axis, spread and blur just like iOS, but Android we can only use the elevations which is nothing like what they ask of us. I came across this ticket and I'm crying a little but I see that for some strange reason they don't want to provide a more personalized function. Very disappointed, let's see how I get out of this, my designers are amazed.
po...@gmail.com <po...@gmail.com> #111
gu...@gmail.com <gu...@gmail.com> #112
+1
ja...@gmail.com <ja...@gmail.com> #113
ed...@gmail.com <ed...@gmail.com> #114
+1 Compose should be more than Material. Similar to what others have stated, my design system now needs a completely different mapping from our shadow styles or use a cumbersome solution that doesn't work for anything but newer API levels.
Description
all required information.
Android Studio Build: 4.2
Version of Gradle Plugin: 4.2.0-alpha03
Version of Gradle: 6.5-rc-1
Version of Java: 8
OS: Mac OS
I was trying to implement Neumorphism design components using Compose but found limitations in the shadow modifier.
The drawShadow modifier only takes a few parameters like elevation, shape, etc. and casts the shadow based on the elevation. This implementation is oriented towards material specs. But a UI toolkit should be able to cater to other design languages as well. Just like TextField is raw and bare-bones but its implementation is provided in the Material Design module.
The shadow should also be customizable, eg. its opacity, radius, the sides, color, etc similar to the box-shadow property in CSS