https://kotlinlang.org
Join Slack
Am I right to find that the default sizes of compose 3 widgets are too big for Desktop (for instance...
# compose-desktop
b
Am I right to find that the default sizes of compose 3 widgets are too big for Desktop (for instance this 
Switch
). For mobile, they need to be big enough to be tapped with a finger - but on Desktop it's odd. And (at least in the example of Switch) these sizes are hardcoded.
all right Slack makes it look worse - it's not THAT big 😅 But still too big.
😁 2
comparing with Switches in Chrome's settings UI (top):
Buttons and TextFields are also quite bigger
c
thats in the specs for material 3 switches. I guess it’s not meant to be used on desktop platforms. https://m3.material.io/components/switch/specs#a4d74dd1-731a-40b3-9516-6dacd407e3f7
b
that was an example but the other components are also quite big by default (some of them can be resized easily though, for instance buttons - others, not that easily)
c
I meant the whole material 3 design specs were not supposed do be used in a desktop environment.
b
that's ... problematic? 😅
🚫 1
or maybe I should look at https://github.com/JetBrains/jewel
c
Maybe it’s just the wrong “scaling” factor on desktop for `dp`’s
b
yes I was wondering about that. Or maybe I could try to scale the whole UI and see what that looks like. I'm a bit worried about perf. Wondering about text rendering too (often scaling text doesn't look very good)
c
I’d check the values of 
LocalDensity.current
if they make sense.
👍 1
b
I'll play with that and report back
(but I can already say that on my machine 1dp = 2px)
a
@Chrimaeon why would you think the whole material spec isn’t meant for large screens?
c
Check the specs - they are all about mobile devices like phones and tablets. Nothing is mentioning desktop monitors and environments. Input is mapped to touch and not mouse. There are no “hover” specs on anything.
a
All the material widgets are indeed too big for the desktop. I work around it by adjusting the LocalDensity
👍 3
e
https://m2.material.io/develop/web/supporting/touch-target (and similar in m3, it's just not as easy to link to)
even in desktop I would say you need the larger touch targets in some cases, e.g. when touchscreen
b
I would say you need the larger touch targets in some cases
I kind of agree, however I think a guiding principle should be that the sizes of the widgets should probably be similar to the OS's ones. I trust Apple/Microsoft to do studies etc. to have the correct sizes.
e
Chrome has support for changing its layout as different input devices are used - at least it works on Chrome OS, and I see that it has code for Windows (but I don't have one to test)
I don't think Compose Desktop has access to the APIs to be able to do that, though
b
left: MacOS settings / right: Compose desktop
m
I wonder how this obvious deficiency relates to this.
e
the sizes of the widgets should probably be similar to the OS's ones
I don't think that's a principle at all. iOS HIG has touch target size 44x44, and Material doesn't change for that even if it could.
b
I guess one interesting question is: how does an Android app running on ChromeOS look like? Is it too big? (I don't have a ChromeOS device, so I have no idea).
e
this isn't related to the size of the screen, just how dense it is
all my chrome os devices have touch screens and the touchability of android apps is the same as on an android tablet
👍 1
b
I don't think that's a principle at all.
but shouldn't it?
e
I don't think so? Material is consistent across platforms, not with the platform
b
I agree consistency is important, but when all your Desktop apps look similar, except those that happen to be developed with Compose, which appear awkwardly bigger, there's a problem
maybe I'm biased, as MacOS notoriously doesn't have a touchscreen hardware (yet?)
e
macos seems to be rejecting touch on "desktop", but then putting more work into iPadOS than traditional computers
so I think you'll have to deal with that in the future eventually
b
(to me this sounds like Compose should have 2 modes - 'bigger' if you're on a touchscreen, 'smaller' if not)
(Or maybe Material rather than Compose)
e
the material design specs don't have a desktop mode at all
and compose doesn't ship with another design library
b
yup I'd say this situation is not ideal
It's kind of an asterisk that I didn't know about before playing around with Compose desktop. I guess if there are workarounds with density/scaling, then it's OK.
e
Jewel is sorta a first-party (from JB)
👍 1
m
One thing you can play with is this
Copy code
CompositionLocalProvider(LocalMinimumInteractiveComponentEnforcement provides isTouchDevice) {
    Your GUI code here
}
where isTouchDevice is a Boolean defined by user input. This makes the GUI look and behave a little bit more desktop like.
👀 1
e
M3 has 
LocalMinimumInteractiveComponentSize
which is allows for finer control, but either way, we don't have the APIs to know if there's a touch digitizer attached or not…
👀 1
m
I have this as a user preference in my apps. Only the user can say which input device he/she primarily wants to use. This cannot be automatically detected because the sole presence of such a device does not mean that I actually want to use it.
a
@Chrimaeon https://m3.material.io/foundations/layout/applying-layout/window-size-classes Weird, because some pages explicitly mention desktops
👍 1
b
I have this as a user preference in my apps. Only the user can say which input device he/she primarily wants to use. This cannot be automatically detected because the sole presence of such a device does not mean that I actually want to use it.
Interesting. I never interacted with in a desktop with touchscreen system before... I'm wondering how they usually behave.
c
That’s layout and not components, @Arjan van Wieringen
a
True, but I was confused because you claimed the whole material spec isn’t meant for Desktop.
e
it doesn't have any customization in the widgets for desktop
M2 web had some support for density but I don't think that made it to android, compose, or M3
https://material-web.dev/about/roadmap/#density-and-spacing-tokens ah… given that the homepage for MWC says "MWC is in maintenance mode pending new maintainers" that doesn't look like a system compose-material could copy from
p
So if i wanted to scale down all the components i should use LocalDensity. Is it editable??
e
it's a composition local so
Copy code
CompositionLocalProvider(LocalDensity provides Density(density, fontScale)) {
    // ...
}
changes it for everything inside the block
p
Yeah i've already tried it and it works, it looks so much better. Maybe it was some internal composition local so thats why i asked, thanks!
🎉 1
c
Jewel is an option for a desktop widget set, though it follows the IntelliJ New UI design system and is intended to support UI development for IntelliJ plugins.
m
@Pau Marzo Could you summarise what your preferred settings are now?
p
the scale value imposed by the pc was 125% which translates to a density of 1.25, i tested a LocalDensity value of 1.00 but it was too small. My current value is now 1.15 which is a medium scale and works well for me but maybe i'll change it to a bigger value my range would be 1.12-1.20). The thing is that the density currently doesn't react to the pc's scale settings because 1.15 is a hardcoded value. I'm also thinking of something like LocalDensity.current*0.92 which would react to user's preferred scale but making only an 92% of its value. (font value is the default one which is 1)
🙏 1
b
On my system (a 'retina' MacBook Pro), the current value was 
2
, and a value of 
1.5
looks good to me. So currently my code does 
LocalDensity.current.density / 4f * 3f
. The Switch looks more reasonably sized (actually still a bit big to be honest but don't want everything else to be too small either).
🙏 1
m
@ephemient Changing the 
LocalDensity
seems to not affect the scale for window sizing, see this example. The 
DpSize(200.dp, 200.dp)
passed to the 
Window
is at 
1.0
density instead of 
2.0
that it should be. Do you know what's the issue here?
The resulting window is 200px, with a 100px red square. Should be a 400px window with a 100px red square.
c
Window might not use Localdesity to calculate it’s „state“. Check the code of rememberWindowState.
m
That's what I'm seeing, but it takes values in Dp instead of pixels, as would be expected in that case.
So is it fake Dp that is actually pixels?
c
It always depends on how the DpSize in the state is used. It might be that window assumes there is no Localdensity available and uses 1 by default to calculate the px. I’d file an issue and ask for clarification as it should not be like this.
If you remove the second CompositionLocalProvider is the box 100 or 50 px?
m
It's 50px then, the composition local set outside the Window does not reach inside. I have now tested this on a different computer where the natural density is 2.0, and the window is 400px there. So it seems the window 
DpSize
does consider density, but it's always the "natural" density and is not affected by setting 
LocalDensity
.
c
okay, then I’d say the 
Window
sets the 
LocalDensity
and overrides your value.
m
That seems to be the case.
107 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by