is there anything about this composable which shou...

# compose

[Trejkaz]

is there anything about this composable which should cause odd issues with local content colour? 🤔 >>

[Trejkaz]

/**
 * A box which supports flashing a message over the top.
 *
 * @param state the state of the flash box. Can get from [rememberFlashBoxState].
 * @param content the content of the box.
 */
@Composable
fun FlashBox(
    state: FlashBoxState,
    content: @Composable () -> Unit
) {
    Surface {
        Box(modifier = Modifier.wrapContentSize()) {
            content()
            Column(modifier = Modifier.align(Alignment.BottomCenter)) {
                Text(
                    text = "Copied!",
                    textAlign = TextAlign.Center,
                    modifier = Modifier
                        .width(150.dp)
                        .alpha(state.alpha)
                )
            }
        }
    }
}

[Trejkaz]

What I get is, the text is black, on a black background

[Trejkaz]

I try to go more explicit even:

Surface(
        color = MaterialTheme.colors.surface,
        contentColor = MaterialTheme.colors.onSurface,
    ) {

[Trejkaz]

still black on black

[Trejkaz]

setting contentColor to Color.White specifically shows white

[Trejkaz]

I guess I'm mystified as to why onSurface should be black when surface is black

[Trejkaz]

and I'm just using the default. darkColorScheme()

[Chrimaeon]

your code sniped works fine for for me.

[Arsildo Murati]

Yep, no problems for me either

[Skaldebane]

and I'm just using the default. darkColorScheme()

That's really weird, it should work properly. Which version of Compose are you using (specifically compose-material)?

[Trejkaz]

implementation(compose.material3)
compose = {id = "org.jetbrains.compose", version.ref = "compose"}
compose = "1.6.11"

[Trejkaz]

oh I wonder if it's particularly a material3 quirk and maybe material would have been fine

[Skaldebane]

Mmm, haven't worked with Material 3 so can't tell for sure

[Chrimaeon]

My test was with material 3

[Trejkaz]

hmmm, the colours look right when I print them out too
surface = Color(0.10980392, 0.105882354, 0.12156863, 1.0, sRGB IEC61966-2.1)
onSurface = Color(0.9019608, 0.88235295, 0.8980392, 1.0, sRGB IEC61966-2.1)

[Trejkaz]

oh but then over in my component...
surface = Color(1.0, 1.0, 1.0, 1.0, sRGB IEC61966-2.1)
onSurface = Color(0.0, 0.0, 0.0, 1.0, sRGB IEC61966-2.1)

[Trejkaz]

huh

[Trejkaz]

this is many many levels deep in the hierarchy so I dunno

[Trejkaz]

I just pushed the code but it's around here https://github.com/ephemeral-laboratories/GlyphPlay/blob/main/src/main/kotlin/components/FlashBox.kt#L118

[Trejkaz]

Context: Looking at colorScheme before I set it into the theme
surface = Color(0.10980392, 0.105882354, 0.12156863, 1.0, sRGB IEC61966-2.1)
onSurface = Color(0.9019608, 0.88235295, 0.8980392, 1.0, sRGB IEC61966-2.1)

Context: Directly inside AppTheme{}()
surface = Color(1.0, 1.0, 1.0, 1.0, sRGB IEC61966-2.1)
onSurface = Color(0.0, 0.0, 0.0, 1.0, sRGB IEC61966-2.1)

[Trejkaz]

OK I believe I have figured out what's going on, somewhere in the code there are some references to material2's MaterialTheme.colors

[Trejkaz]

it would be nice if I could have material2 not on the classpath but 😞

[Trejkaz]

I can't ban using compose.material outright because of material.icons

[Trejkaz]

I don't suppose there is a material3.icons hahaha

[Skaldebane]

yeah, that kinda sucks

[Trejkaz]

I can't stop $some_random_library I call out to from using Material2 either

[Trejkaz]

I guess one option would be, when setting up the Material3 theme, also set up a matching Material2 one just in case

[Trejkaz]

which might be good practice anyway

[Trejkaz]

the other thing is uh... the whole point of Material3 was to get theming that somehow fits the environment, but in desktop, I wonder how to get that to happen

[Trejkaz]

I would like ideally for my apps to follow the user's preferred accent colour on desktop too

[Trejkaz]

it's a nice bonus that I'm not even sure how to fetch the hard way if I wanted it

[Skaldebane]

I guess it could be feasible on desktop, but since Compose Desktop runs on JVM (on top of Java AWT), it may not be very trivial to do so.

[Trejkaz]

Swing never made it easy to get access to the stuff either but they used to at least set things like the selection colour to match the desktop setting

[Trejkaz]

I see the APIs to do this more or less require C++ which is the worst possible option haha

[Skaldebane]

You'll essentially want to interact with native APIs from each platform. Again, since Compose Desktop is only on Kotlin/JVM (not Kotlin/Native), you'll have to use JNI for that.

[Trejkaz]

yeah

[Trejkaz]

we were using JN*A* quite a bit at work to fill these sorts of holes but C++ APIs were the bit where it got hard

[Trejkaz]

native C was always nicer but with MS APIs sometimes they just never gave us one

[Trejkaz]

I suppose there might be a way to finagle it by running some js script

[Skaldebane]

yep
i'm not sure how Windows handles its theming (and if it's possible to get like, a "singular" color or a palette), but macOS certainly supports this and exposes it to apps. Linux, on the other hand, has a bit of a complicated story. You could either rely on the GTK themes (bad idea), or there's a new "Color scheme" portal, but it's still being adopted (for example, GNOME doesn't expose this to users just yet)...

[Trejkaz]

yes Linux is particularly painful for this and we never figured out good unified ways to deal with it over there

[Trejkaz]

KDE users expect things to match theirs too

[Trejkaz]

you'd think FreeDesktop probably has some kind of way

[Skaldebane]

yeah, but it's now finally getting unified in the new FreeDesktop Color Scheme portal (iirc)

[Skaldebane]

KDE already supports this, works exactly like macOS

[Skaldebane]

GNOME will probably ship it in the next release

[Skaldebane]

and others will follow suit sooner or later

[Trejkaz]

excellent

[Skaldebane]

as for C++, i always avoid it like the plague. I mean, i could do with it, but the fact that it's not easy to write memory-safe code always scares me (aside from the hellish syntax, every basic feature is in 'std', the C legacy remains...).

[Skaldebane]

so i use Rust where many people have already made crates containing safe (and unsafe) wrappers for most system APIs

[Skaldebane]

and it's just a lot more pleasant to work with (as long as you can fight/work with the borrow checker)

[Trejkaz]

yeah that is fine too

[Trejkaz]

and then we just need a nice clean way to call that from here

[Skaldebane]

i've used JNI for such use-cases
there's even a nice Rust macro that spares me writing the Java_com_myapp_me_myFunction as well as handling type conversions from both sides

[Trejkaz]

JNI is so last era though

[Trejkaz]

vs JNA

[Trejkaz]

I was using JNA to call a lot of macOS native APIs even

[Skaldebane]

i mean, JNA uses JNI under-the-hood

[Trejkaz]

yeah

[Skaldebane]

they're both quite last-era lol

[Trejkaz]

but you don't have to write all the native interop code

[Skaldebane]

the new kid on the block is FFM (on JDK 22+ i guess)

[Trejkaz]

haven't touched that yet

[Trejkaz]

didn't even get around to using JNR

[Skaldebane]

me neither, but looks like the future of interop

[Trejkaz]

as usual I wait until it's in an LTS

[Trejkaz]

but yeah some new JDK features I jumped on as soon as they appeared just to see how life would be, like vector ops

[Trejkaz]

I wish Windows would ship more APIs with C options for calling them because foreign calls to C++ are usually cursed

[Trejkaz]

it annoys me that MS people don't see the issues with C++

[Skaldebane]

yeah indeed
honestly personally i'm just hoping that Compose Desktop eventually supports Kotlin/Native
it's more work per each platform, but it'll lead to faster startup times, lower memory footprint, and extremely easy interop with native C/C++ APIs (or Swift/ObjC APIs in macOS)

[Trejkaz]

it would be nice anyway if kotlin gave us a nice path to doing wrappers for native actually

[Trejkaz]

like being able to call kotlin native from kotlin jvm

[Skaldebane]

yesssss sir

[Trejkaz]

so we could at least write the shims in kotlin

[Trejkaz]

I'm sure there is a way

[Trejkaz]

it isn't very obvious how to do it

[Skaldebane]

i was dreaming about that recently, it would be awesome if there's a way

[Trejkaz]

personally I dream of shaders in kotlin too

[Trejkaz]

but I will let that happen by itself

[Skaldebane]

haha yeah that would be cool too
i've seen it done in Rust before, so it's not impossible, just need that one dehydrated sleep-deprived dude to make it in his free time 😛

[Trejkaz]

I also wanted someone to want C# interop enough to make a kotlin IL target but it turns out .NET people are way more insane than you'd expect and would rather just make a new language than make kotlin capable of targeting .NET

[Trejkaz]

some guys literally created a new language marketing it as "kotlin for C#"

[Trejkaz]

they wanted a name for it, I suggested "couldn't you actually use kotlin"

[Skaldebane]

i mean, Kotlin and C# have lots of similarities, but the burden would fall on Jetbrains to maintain a proper backend for C# in the compiler

[Trejkaz]

I mean someone else could make that backend in the compiler

[Skaldebane]

and i don't see much financial sense in doing so lol

[Trejkaz]

and just hand it to them

[Trejkaz]

and yeah it's a question of what is the use case

[Trejkaz]

personally for me it would be Unity

[Skaldebane]

yeah, but it's still a hellish work to do
and maintaining it is also not easy

[Trejkaz]

being able to write in a language that isn't C# for Unity

[Trejkaz]

well

[Trejkaz]

I suppose there are probably some people using F#

[Trejkaz]

Unity having better interop for other languages would be nice honestly

[Trejkaz]

Godot can use Kotlin

[Trejkaz]

it's a bit of a clunky interface to it like it was written by someone preferring the Godot way of doing things, but it works

[Skaldebane]

we probably went off track for this thread
let's continue in DMs if you wish

[Trejkaz]

I mean it's fine, it's my thread anyway haha

[Skaldebane]

yeah, but there's a couple other people who participated, they'll be bombarded with unrelated notifications

[Trejkaz]

so yeah the end result of this one was - I had pulled FlashBox from another project which used Material2, so it was referencing Material2's Surface function

[Trejkaz]

really hard to spot that bug when you're reading the code and imports are collapsed

[Skaldebane]

was a fun discussion tho, it seems like we have similar dreams about native interop 😄