https://kotlinlang.org logo
Join Slack
Powered by
Why is the `compose-jb` github project not named `...
# compose-desktop
s
Why is the 
compose-jb
github project not named 
compose-multiplatform
? I think it'd be way more intuitive to people.
➕ 8
j
And removing 
androidx
imports for 2.0 should be great
c
naming things is hard, y’all 😅
j
the 
androidx
part were more a mix of bureaucracy plus trolling IMO 🙃
c
I think the 
compose-jb
naming is more just a historical thing. Back when it first came out, it was only targeting Desktop and used skija (the Java-only Skia wrapper). It was just “Jetbrains’s Compose, for desktop”. It was later when skija was fully replaced by the multiplatform skiko and work started on other Skia-based targets, and by that time the artifacts and project name were already established, and it’s usually not worth the trouble for a name change at that point
c
@Javier 
kotlinx.compose
!
j
As google is the owner of it (or something so) probably they want its brand on it too
c
Well JetBrains dropped the "Jetpack" branding when creating Compose for Desktop and Compose for Web
IMO it's for the best, Jetpack Compose should be the name of the Android-only layer. At this rate, we'll call the Android version Jetpack Compose, and the multiplatform variant JetBrains Compose with an 
androidx
import. Plus, Google is part of the Kotlin foundation, so naming 
kotlinx.
doesn't really take anything away from them?
Well of course they'll make the decision they want. I just wish they had any idea how bad the packages being named 
androidx
is for adoption. Compose Web is IMO great, and I've been trying to pitch it to multiple React/Angular teams who already write their backends in Kotlin, and the "it's just an android library, why should I care about it?" feeling is very common.
I'm part of the minority who uses CfW without being an Android developer or having used Jetpack Compose, and I don't see that group growing any time soon.
j
problem is KMP
seeing androidx import in common is awful as you can think on it as error but they aren't
k
That ship has probably sailed now and it’s not returning
s
At the end of the day - the project is owned by the android team. As great as it would be to get a package rename, that's not what I'm trying to discuss here. I'm trying to discuss something that can be easily changed, that would help adoption, changing the github project name to 
compose-multiplatform
c
@spierce7 would it help adoption? You essentially never need to see it in regular usage (it's not in the package name, it's not in the website name, it's not in the documentation, it's not in the artifact name).
j
compose-ui-multiplatform
would be better 😁
l
It doesn’t help that compose-jb doesn’t actually build the android artifacts. They just redirect to the androidx artifacts. As long as this happens, they can’t rename the package.
j
it builds them for all targets except Android
the multiplatform source is primarily hosted in AOSP, but there are JB-specific customizations in https://github.com/JetBrains/androidx which is the repository included into compose-jb such that all non-Android targets can be built.
l
I was a little disappointed when I saw a while back that compose-jb just had a submodule for a whole androidx fork. It would have been nice if it just pulled in compose from the androidx project and didn’t bring in all the other projects.
I say a while back as if it hasn’t been a whole year now.
c
If they did that it would be hell to contribute back to androidx/pull from it
j
not really. git subtree can sync bi-directionally
We used a submodule for a year or so to build multiplatform Compose before JetBrains' artifacts were on Central. Not sure what the problem is.
l
You could even go as simple as an alias for git pull/add/push that only does androidx/compose.
j
you are describing git subtree. or perhaps git sparse-checkout, although i'm not sure the latter works with submodules.
l
I can’t find it anymore, but I swear there was a youtrack to be able to typealias a package. That seems like it would help in this case.
s
I can’t find it anymore, but I swear there was a youtrack to be able to typealias a package. That seems like it would help in this case.
That's actually a really interesting potential solution.
j
If you find it, please share it here. I know you can use import aliases but not package aliases
l
I believe I was thinking of this ticket: https://youtrack.jetbrains.com/issue/KT-34281/Access-nested-classes-including-sealed-class-subclasses-through-typealias but it doesn't mention packages, only nested classes
5 Views
Open in Slack
PreviousNext
Powered by