[JEWEL-1298] Fix JDialogRenderer Density Issues

[DanielSouzaBertoldi]

(this description was generated by jewel-pr-preparer)

JDialogRenderer had two density-related bugs affecting popup positioning and content rendering when the app overrides LocalDensity.

Changes

• Replace LocalDensity.current with dialog.density() (the actual screen scale from graphicsConfiguration) when converting Compose layout coordinates to AWT logical pixels in withDensity — the screen scale factor is always the correct ratio here, independent of any app-level density override.
• Fix ProvideValuesFromOtherContext to provide the ComposePanel's defaults as the outer context and the caller's composition locals as the inner context, so the caller's values (including any LocalDensity override) correctly win over ComposePanel defaults instead of being silently discarded.

Release notes

Bug fixes

• Fixed JDialogRenderer incorrectly using LocalDensity for AWT coordinate conversion, causing popups to appear at the wrong position or size when the app overrides the Compose density.
• Fixed ProvideValuesFromOtherContext swallowing caller-provided composition locals (such as LocalDensity) in favor of ComposePanel defaults.

Demo

Before	After
Screen.Recording.2026-04-01.at.09.41.20.mov	Screen.Recording.2026-04-01.at.09.39.03.mov

[DanielSouzaBertoldi]

Yo, btw, why do we have both kotlinter and ktfmt?

We should really just stick to one of them, otherwise we get situations like in this PR, where ktfmt formats the code in a certain way that kotlinter does not like at all:

Even though this is pretty rare, it can happen.

I took a look at the .editorconfig file and most ktlinter rules are disabled anyways:

[rock3r]

@DanielSouzaBertoldi we can disable it if we want to, but it does check more than what ktfmt enforces IIRC

[daaria-s]

I think I found an issue connected to this change, pls correct me if I'm wrong
If I enable Custom Popup Renderer and try to open Sub menus, it just disappears and i cannot open further submenus. Video is attached.
When I revert your change, it works fine.
After some discussion with AI, he told me that "a submenu is itself another popup, opened from inside the first popup, and for that nested popup to appear correctly, the submenu code must see the current popup host component, but because of the change it sees the original parent window component." Does it make any sense? 😄

Screen.Recording.2026-04-08.at.15.26.49.mov

[DanielSouzaBertoldi]

Yeah, that's definitely a bug! Great catch 😄

The problem is that we were providing the local compositions of the parent window to submenus.

The fix was pretty simple, use the local compositions from the parent but override the LocalComponent to be this, pointing to the current component itself, not the parent. With this change I realized that ProvideValuesFromOtherContext is kinda redundant now so I also removed it from the code (one less abstraction layer, hell yeah). Here's the result:

Screen.Recording.2026-04-17.at.10.20.08.mov

Thank you so much for pointing this out! :)

[DanielSouzaBertoldi]

@rock3r I disabled both ktlint_standard_argument-list-wrapping and ktlint_standard_max-line-length. Let ktfmt handle wrapping and detekt can check max line length :)

[DanielSouzaBertoldi]

This code was a bit redundant. The context parameter had its value assigned by val compositionLocalContext by rememberUpdatedState(currentCompositionLocalContext)

Then existingContext also fetched the information from currentCompositionLocalContext.

At the end of the day they were both providing the same values 😵‍💫

[rock3r]

Ready to merge