You shouldn't need any external tools if you use Dev Mode in Figma fwiw <https://www.figma.com/dev-m...

# compose

[seb]

You shouldn't need any external tools if you use Dev Mode in Figma fwiw https://www.figma.com/dev-mode/

[Filip Wiesner]

Yeah, and HEX is really easily converted imho. #FF0000 is just 0xFFFF0000

[seb]

indeed

[romainguy]

When it's a color long. If it's a color int you need a toInt() after the constant if alpha is > 7f (in Kotlin, Java handles hex constants more sensibly)

[ephemient]

the androidx.compose.ui.graphics.Color(Long) overload makes the .toInt() unnecessary though, doesn't it?

[ephemient]

https://developer.android.com/reference/kotlin/androidx/compose/ui/graphics/package-summary#Color(kotlin.Long)

This is useful for specifying colors with alpha greater than 0x80 in numeric form without using `Long.toInt`:

[romainguy]

It does yes, but if you use Compose with Android you may end up calling APIs that take a @ColorInt, so watch out for that

[romainguy]

(Compose itself shouldn’t have such APIs, but android.* very much will)

[ephemient]

honestly it would be nice if numeric literals could be used as an unsigned integer without requiring a U suffix (as long as it fits), then a single Color(UInt) function would cover that case. oh well…

[ephemient]

can't remove that nor the old @ColorInt APIs :-\

[romainguy]

Yeah, it’s one of the few things I never liked about Kotlin. I don’t know why they decided to do it differently than pretty much all other programming languages here

[romainguy]

It doesn’t even need to be about unsigned, hex constants are just a handy way to set specific bits, and it’s fine if the resulting value is negative

[romainguy]

in Java you’d write 0xFF000000L (note the L suffix) if you wanted a long, whereas 0xFF000000 would just be a negative integer

[romainguy]

(while we’re at it, I also strongly dislike shl and shr, they make bitwise code manipulation error-prone)

[ephemient]

and the lack of precedence between them and and and or, bitwise in Kotlin is so difficult to translate

[romainguy]

Yeah I’m never confident when I write bitwise code in Kotlin, even though it’s never an issue in C++/Java 😅

[ephemient]

I'm kinda OK with 0xFFFFFFFF being positive, since 0xFFFFFFF8.0p0 would be positive (if Kotlin had hex floating point literals)

[ephemient]

but the whole thing with the type of literals being "Byte ∪ Short ∪ Int ∪ Long" is just weird

[romainguy]

Now I want custom suffixes like in C++ 🙂