https://kotlinlang.org logo
Join Slack
Powered by
:wave::skin-tone-5: I'm building with Compose for...
# compose-desktop
t
๐Ÿ‘‹๐Ÿพ I'm building with Compose for mac on desktop and noticed that with the awt flags for a transparent title bar, window insets for the status bar don't work like I expect:
Copy code
window.rootPane.apply {
    rootPane.putClientProperty("apple.awt.fullWindowContent", true)
    rootPane.putClientProperty("apple.awt.transparentTitleBar", true)
    rootPane.putClientProperty("apple.awt.windowTitleVisible", false)
}
Is there a convenient way to update the logic for status bar inset calculation? 
LocalPlatformWindowInsets
seemed promising, but it looks set to be removed
a
PlatformWindowInsets
are not relevant on the desktop. Can you explain the problem? Itโ€™s hard to understand just from the screenshot.
t
Ah sorry about that. By default, Compose Desktop on Mac renders with a titlebar. I can make the title bar transparent using AWT client flags, which I want to:
Copy code
window.rootPane.apply {
    rootPane.putClientProperty("apple.awt.fullWindowContent", true)
    rootPane.putClientProperty("apple.awt.transparentTitleBar", true)
    rootPane.putClientProperty("apple.awt.windowTitleVisible", false)
}
Upon making the title bar transparent, I now render underneath it, similar to going edge to edge on Android. I thought, the WindowInset API would let me achieve on Desktop what I can achieve on Android. I've attached screenshots of before and after to show what I'm going for.
a
I see. I don't know if we have the information from the system to provide that in PlatformWindowInsets.
t
I understand, I was hoping I could provide the insets myself. I'm okay specifying them, I just don't know how to provide it to the rest of the system.
Which is why I was hoping I could set it at the 
LocalPlatformWindowInsets
level at the root of my hierarchy and let the rest of the composition tree consume them as normal
I'll try to see if I can create my own implementation of 
WindowInsets
and provide that to the Compose hierarchy
u
@Tunji Dahunsi I'm not sure I fully understand your problem, but I think this will help you : https://nucleus.kdroidfilter.com/runtime/decorated-window/
blob ty sign 1
a
Compose for Desktop does not allow drawing custom content in the title bar while keeping native window controls and native behavior (drag, resize, double-click maximize). You must choose between a native title bar you cannot customize, or a fully undecorated window where you reimplement everything from scratch.
Not sure thatโ€™s strictly correct. Compose doesnโ€™t, but Swing does.
on macOS anyway
u
Ah yes, I didn't know that, how do I do it?
a
But yeah, nothing is preventing you from doing 
Modifier.windowInsetsPadding(WindowInsets(top = 40.dp))
Ah yes, I didnโ€™t know that, how do I do it?
See the JRootPane client properties in the code above
๐Ÿ‘ 1
u
I'll check that and fix it, thank you very much.
a
There are quite a few cool options on macOS. Some of them you can find in 
CPlatformWindow.java
โž• 2
t
I can definitely do 
Modifier.windowInsetsPadding(WindowInsets(top = 40.dp))
, but I'd need to do this differently per platform per call site. This is why I was hoping to centralize it with 
LocalPlatformWindowInsets
; i.e not make any changes to the calling code, just provide a platform specific inset provider. I may still be able to pull it off, I'm looking at the 
expect/actual
impls here: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[โ€ฆ]in/androidx/compose/foundation/layout/WindowInsets.android.kt
a
You can define an expect/actual, like
Copy code
expect val statusBarInsets: WindowInsets
and implement it on Android via
Copy code
actual val WindowInsets.Companion.myStatusBarInsets: WindowInsets
    get() = WindowInsets.statusBars
and on the desktop
Copy code
actual val WindowInsets.Companion.myStatusBarInsets: WindowInsets
    @Composable get() = WindowInsets(top = 40.dp)
t
That is so much easier than what I was trying, thanks!
s
I take a bit of an exception to this as it makes it sound like Jewel depends on Material ๐Ÿ™‚
But that said, nice stuff as usual ๐Ÿ™‚
u
Yes, sorry, the documentation really needs to be redone. ๐Ÿ˜ถโ€๐ŸŒซ๏ธ
I've corrected the documentation; I think it's better now ๐Ÿ™‚
โค๏ธ 1
s
Awesome ๐Ÿ˜Ž I still don't know why someone would not want to depend on Jewel, but that's just me being silly ๐Ÿ˜œ
u
Thanks ๐Ÿ™‚ Well, if I want to change the window theme to a Material Design theme, for example, it's not practical to depend on Jewel.
I think Material Design is probably the theme to choose when you want to write a single UI that runs everywhere. (Among the things I still need to do, I should write a guideline on how to properly use Material on desktop, because I see far too many atrocities) And most of the apps I see built with Compose all use Material anyway. Personally, I think Jewel is the ideal theme when you want a desktop UI across all platforms. Even though it isnโ€™t native, it feels intuitive and modern everywhere. The API is really designed with desktop in mind, even in the small details. I was actually surprised when I saw that you can customize the scrollbar behavior, like jump or seek. I find it really unfortunate that it isnโ€™t well documented, and that there isnโ€™t a gallery with lots of components and copy-paste code examples. It almost feels as if it were reserved purely for internal use. Fortunately, the lack of documentation isnโ€™t as limiting as it used to be. When I work with Jewel, I keep my AI agent open in the repository and ask it how to do this or that, so I can still manage to use it quite well ๐Ÿ˜†
s
I'm joking, of course ๐Ÿ™‚ I do believe if you are only targeting desktop, Material is an objectively poor choice as it is definitely a mobile-oriented implementation. But yeah if you want portability and are ok with the UX compromises, Material is fine
โž• 1
The Int UI design system is purely desktop-oriented and Jewel is as well as a result
a
I think โ€œportabilityโ€ is not applicable here. There's no way a serious app is going to have the same UI on mobile and desktop.
โž• 3
and if you're writing a new UI, you might as well use the right widgets
โž• 1
s
We have better docs on the roadmap for Jewel โ€” starting from requiring proper KDocs for all new code, and filling it back in as we go. But it does help to point the agents to the local intellij-community checkout to use as a reference for Jewel ๐Ÿ˜„
u
Material is an objectively poor choice as it is definitely a mobile-oriented implementation.
Well, this might surprise you, but I donโ€™t agree. I think Material Design can actually be a very good choice on desktop. However, I completely agree with @Alexander Maryanovsky that a serious application cannot have the same UI on desktop and mobile. If you look at apps like Google Chrome, Google Docs, or Gmail, they use Material and they look very nice. The real problem is when people use it the same way they would on Android.
Bottom sheets and snackbars should be banned on desktop. It shouldnโ€™t even be legal
a
They use a different kind of material. The material in Compose is, at minimum, too large for the desktop.
u
Yes, thatโ€™s why I use it at 75% of the DPI, and it already works much better.
In fact, if we use Material Design on desktop, we need to reduce the DPI as mentioned, and most importantly stick to only the basic components. On desktop thereโ€™s no need for things like a FAB, a top bar, or a bottom bar. All of that is superfluous. We simply shouldnโ€™t use them. If we look at apps like Google Chrome or Gmail, none of the components they use are unusual or exotic. Theyโ€™re all very classic UI elements, and thatโ€™s exactly why it works.
a
That only helps a bit. Spacing is still too large (relatively).
โž• 1
s
Yeah the "material" Google apps you see on desktop/web use entirely different specs and impls
They're Material-inspired I'd say
They DEFINITELY do not use the Compose or web libraries for components
โž• 1
u
Well, that's exactly what we need, I think.
They DEFINITELY do not use the Compose or web libraries for components (modifiรฉ)
Yes, I figured as much, I'm just saying that with a few tricks we can make something acceptable
s
The biggest issues of the Compose Material (and other public Material design) is that everything is strictly optimised for touchscreen and low density. That's the opposite of desktop optimised
Not just as an implementation but as design as well
u
On all Google desktop apps, I don't experience any problems; I find it pleasant.
s
But that's because they are not using the public, touch-optimised, Material components
They use an internal version that actually has desktop optimised designs and impls
That is absolutely fine!
But it's just not the same thing you get from the public Material stuff
u
I'm just saying that with today's Material Design components and a little ingenuity, I don't think it's complicated to replicate the Google Chrome design on a desktop.
s
But Chrome's entire design ethos is that it doesn't have much "chrome" at all
Even the settings are very basic and sparse
But try implementing anything more complex UI-wise and you'll be stuck
โž• 1
u
Yes, I understand.
That's why I say that for simple applications that share their UI with the mobile device, we can still create something nice with the current Material Components; I'm not talking about recreating IntelliJ.
s
There are no trees, no selectable lists, no real context menus, etc etc. It's not just the density (which you can somewhat cheat at and pretend it's fine to have 1.dp lines all fuzzy because they're now subpixel-width). It's the components that are available and what they do and how they do it
u
I resign myself ๐Ÿ˜…
s
I'm sorry I have very strong opinions on this topic lol
๐Ÿ˜… 1
I had them before Jewel too, to be honest
u
I just think that you don't design desktop apps that can be simple enough, a simple administration panel, and I'm not saying it will be the best experience in the world but that it will be pleasant nonetheless, today in cmp, we find many pleasant components
s
Yeah yeah again I did say if you're ok with the compromises you can make material work. It's never going to be great on desktop, or probably even more than passable, but it'll do
u
I think we agree ๐Ÿ™‚ I use Jewel, hehe
โค๏ธ 1
c
I sent the CMP team a Material Design desktop spec two years ago, but no one moved on it it seems. ๐Ÿ˜…
Itโ€™s effectively the Material Web spec but better density options. But to Sebs point, it really only covers density and lacks a lot of desktop specific componentry. And clear guidance for mouse/keybaord
77 Views
Open in Slack
PreviousNext
Powered by