-
Notifications
You must be signed in to change notification settings - Fork 98
Size SwingPanel according to its content #2310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Size SwingPanel according to its content #2310
Conversation
.../ui/src/desktopMain/kotlin/androidx/compose/ui/viewinterop/SwingInteropViewHolder.desktop.kt
Outdated
Show resolved
Hide resolved
2f12380
to
296317d
Compare
compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/awt/SwingPanel.desktop.kt
Show resolved
Hide resolved
.../ui/src/desktopMain/kotlin/androidx/compose/ui/viewinterop/SwingInteropViewHolder.desktop.kt
Show resolved
Hide resolved
compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/awt/SwingPanel.desktop.kt
Outdated
Show resolved
Hide resolved
0d1fc37
to
668dca5
Compare
private val MaxSupportedRadix = 36 | ||
private const val MaxSupportedRadix = 36 | ||
|
||
private class AwtContentMeasurePolicy( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please move it into SwingInteropViewHolder
or separate file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the advantage of doing that?
Under the same reasoning you would move SwingInteropViewGroup
into SwingInteropViewHolder
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not component directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to ask this in the next conversation down below?
I could ask the component directly, but it seems a bit more correct to follow the hierarchy. Maybe tomorrow we'll want SwingPanel
s to have a border for debugging purposes or something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's basically the same consern as with assigning the size directly - it's not supposed to be the same, and I'm wonder if this might break it in some cases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to ask this in the next conversation down below?
Yep, sorry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Under the same reasoning you would move
SwingInteropViewGroup
intoSwingInteropViewHolder
.
As far as I remember @igordmn wanded to keep them file-private, but it's no longer the case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It delegates directly to the child, so I don't see how it can break.
Also, it's not actually possible to ask the component directly. When SwingInteropViewHolder
calls its super constructor, it needs to pass it measurePolicy
, but at this point the component (typedInteropView
) doesn't exist yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it's not possible to create AwtContentMeasurePolicy
unless it would be an inner class of SwingInteropViewHolder
, or it would need to take a getter () -> Component
rather than the Component
itself. Seems too much...
@@ -149,9 +161,72 @@ internal class SwingInteropViewGroup( | |||
} | |||
isFocusCycleRoot = true | |||
} | |||
|
|||
override fun getPreferredSize(): Dimension? { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to override getPreferredSize
/getMinimumSize
/getMaximumSize
if we control sizing manually now? Does it really related to the fix of the issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AwtContentMeasurePolicy
queries SwingInteropViewGroup
for its min/pref/max size.
668dca5
to
e327909
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main blocker from previous iteration was resolved - not blocking anymore.
The main review should still on @igordmn
e327909
to
93dac40
Compare
Size
SwingPanel
according to its min/pref/max sizes.Fixes https://youtrack.jetbrains.com/issue/CMP-3206
Screen.Recording.2025-08-15.at.15.12.41.mp4
Testing
Added a unit test and tested manually with
Release Notes
Fixes - Desktop
SwingPanel
no longer requires to be manually sized to a fixed value; it will size according to its content's min/pref/max sizes.