BTW I find it a bit disturbing that `LocalAppWindow current

Question

BTW I find it a bit disturbing that `LocalAppWindow current width|height ` are of datatype `Int` but represent height|width in `Dp` so if you wanna have e g the window width in Float to compare it to a `Size` or `Offset` you have to do `LocalAppWindow current width LocalDensity current density` Even more at the root of all Apps `fun main = Window title = Compose for Desktop size = IntSize 300 300 ` The window doesn t have an IntSize of 300 300 in fact it has a DpSize of 300 300 and an `IntSize 600 600 ` if density == 2 0f

Kirill Grouchnikov · Answer

It s a rather awkward seam between the density independent world of Compose and pixel world of Swing which has very little to no API awareness of screen density making it really cumbersome to do anything related to high DPI displays Unless the Desktop version of compose completely abstracts away those Swing AWT APIs that work with the underlying windowing APIs you ll still have that seam somewhere in either the API surface or when you need to interact with the windowing APIs of Swing AWT

Brian G · Answer

But since they represent dp why not type them `Dp` Everywhere else in the Compose API dimensions are given in `Dp`

Kirill Grouchnikov · Answer

If you are talking specifically about the `size` parameter in the `Window` composable you ll probably want to make sure that the initial size matches the display size percentage wise or at least doesn t overflow the width and or height I don t think Compose has APIs to get the dp size of all the available screens at least not in the desktop edition So you d still be doing dp to pixel conversion just in a different place in your code

Brian G · Answer

Yes sorry I m referring to the `Window` composable Since it is treated as dp why not type it `Dp` to make the API more self documenting

Brian G · Answer

The developer doesn t need to do manual dp pixel conversion unless they want specific window screen ratios like you were saying

uli · Answer

< Kirill Grouchnikov> if i understand right it is about units type safety semantics Compose has an inline class As I understand Dirk is disturbed by the fact that the data type of `width` `height`is `Int` but the semantics is `Dp`

Kirill Grouchnikov · Answer

The `IntSize` values are passed directly to `java awt Window setSize` in and that is one of the few places that covered the conversion to real pixels happens under the hood

uli · Answer

Understood that this is how it is implemented But why Why can t AppWindow accept Dp and pass it on as Int

Kirill Grouchnikov · Answer

I m not arguing either way I m saying that this is where it shows the seam between Compose which is all in on Dp and Swing AWT which is partway in on that in some cases treating pixel values as real pixels and in some cases treating pixel values as abstracted pixels which are kinda the same as Dp in Compose

Kirill Grouchnikov · Answer

Run this

Kirill Grouchnikov · Answer

```fun main SwingUtilities invokeLater val appWindow = AppWindow title = My title size = IntSize 400 300 location = IntOffset Zero centered = true icon = null menuBar = null undecorated = false resizable = true events = WindowEvents onDismissRequest = null appWindow show println Requested compose window width was 400 val composeWindow = appWindow window println On screen AWT window width is $ composeWindow size width ```

Kirill Grouchnikov · Answer

The window width returned by `java awt Window getSize ` is 400 even though the window on a 2x retina display is 800x600 pixels

Kirill Grouchnikov · Answer

It will need to be a very careful dance to make sure that the idiosyncrasy of the underlying APIs is abstracted away in a consistent fashion

Kirill Grouchnikov · Answer

For example if you want to render Swing content offscreen to a bitmap the `BufferedImage` that you create will need to account for the display density So you essentially draw a `JFrame` that declares itself a 400x300 pixels into a `BufferedImage` that is 800x600 pixels Because otherwise you lose all that detail

Dirk Hoffmann · Answer

the case where I stumbled over this thing was when trying to implement my own popup I get the offset where to place the popup via the `onGloballyPositioned ` callback of the component under which it should appear THEN I have to determinine how much space I have for the popup that is windowWidth offset and windowHeight offset And the calculations are just nasty if one of them is in Dp and the other in Float On top that I have to care for how heigh the window title is which both is oh not so plain to see from when you re said that `LocalAppWindow current height` is your friend slightly smiling face

Kirill Grouchnikov · Answer

This where our early feedback is important to shape the APIs

Dirk Hoffmann · Answer

I d a change the `Window` parameter from IntSize to width Dp height Dp letting height be the content I as a developer will have available = contentHeight in Dp b introduce additional fields in LocalAppWindow current for contentHeight Float height without the title contentWidth Float

Brian G · Answer

Thanks for listening smile I think everything in the androidx compose namespace should use Compose types whenever applicable When dropping down to calling Swing APIs directly then handling density becomes the developer s problem same as dealing with legacy Views Bitmaps etc on Android Makes sense to me

Igor Demin · Answer

gt change the `Window` parameter from IntSize to width Dp height Dp We done this in <https android googlesource com platform frameworks support + refs changes 23 1674523 17 compose desktop desktop samples src jvmMain kotlin androidx compose desktop examples windowapi Examples jvm kt 415|the new API > that is not available yet

Igor Demin · Answer

gt b introduce additional fields in LocalAppWindow current for <https kotlinlang slack com archives C01D6HTPATV p1621963609115800 thread ts=1621962519 115500 amp cid=C01D6HTPATV|variants >without accessing window directly didn t work Probably it is better to use them instead of `AppWindow` Imagine you have a custom window that is not a window at all but some Box with shadow slightly smiling face

Michael Paus · Answer

I d just like to add that Compose is not all in on Dp All Canvas data is in pixels and not Dp

Dirk Hoffmann · Answer

but if you are down to canvas or Swing then you dev should know what you do using pure compose should be as consistant and easy as possible also for the novice developer

Michael Paus · Answer

Sure no doubt about that I just wanted to clarify the statement that Compose is all in on Dp Canvas is a part of Compose and it only deals with pixels