I checked that Compose Desktop dependency is exposing the material dependency, which should be unnec...

# compose-desktop

[Javier]

I checked that Compose Desktop dependency is exposing the material dependency, which should be unnecessary if you are not using Material.

Is it a requirement or it can be changed from api to implementation?

[Javier]

https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-main/compose/desktop/desktop/build.gradle

[Javier]

...      
        commonMain.dependencies {
            implementation(libs.kotlinStdlibCommon)
            implementation(project(":compose:ui:ui-util"))
            api(project(":compose:foundation:foundation"))
            api(project(":compose:material:material"))
            api(project(":compose:runtime:runtime"))
            api(project(":compose:ui:ui"))
            api(project(":compose:ui:ui-tooling-preview"))
        }
...

[Javier]

it is exposing this theme, which, IMO, should be in its own artifact like material does in Android

https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-main/c[…]Main/kotlin/androidx/compose/desktop/DesktopTheme.jvm.kt

[Igor Demin]

Yes, it is one of the things, which should be changed in my opinion (it is not trivial as replacing api with implementation)

The purpose of desktop was aggregating all Compose modules, and it was introduced at the very beginning of the CfD. But as you mention, not everyone needs material, also not everyone need foundation.

The current workaround is to exclude dependency explicitly.

[Igor Demin]

it is exposing this theme, which, IMO, should be in its own artifact like material does in Android

DesktopTheme will be deprecated in a new build, so this module will no longer have usable classes/functions

[Javier]

but the idea is removing both, no? DesktopMaterialTheme and DesktopTheme?

[Javier]

then I can just wait until this module is deleted

[Javier]

thank you for the detailed info 🙂

[Igor Demin]

DesktopMaterialTheme will be replaced by MaterialTheme, DesktopTheme by CompositionLocalProvider(LocalScrollbarStyle provides...

[Igor Demin]

then I can just wait until this module is deleted

It maybe not in the near future, because it is not trivial to get rid of it currently:
• desktop knows what version of skiko should be used (when we use desktop.currentOs we actually use desktop-windows or desktop-linux).
• we want to keep one-liner dependency for users, which use only material module
the issue suggests how we can fix it.

[Javier]

yeah, I have read it entirely, like this one too

Theoretically we can still ship separate artifacts for each platform (mac-arm64, mac-x64, win64, linux64), and make MPP plugin resolve platform automatically: