RFR: 8301606: JFileChooser file chooser details view "size" label cut off in Metal Look&Feel
Tejesh R
tr at openjdk.org
Wed Jun 28 06:06:06 UTC 2023
On Tue, 20 Jun 2023 20:33:32 GMT, Phil Race <prr at openjdk.org> wrote:
>>> This change will have broad impact everywhere the Border is used. And it seems to me to be a workaround for the problem that Metal isn't correctly calculating the length of the text at the scaled resolution.
>>
>> It is possible that the width of the sting isn't calculated correctly, which could explain “cut off” label. At the same time, the text flushed to the very edge doesn't look either. When there's a margin, text looks better and is easier to read. Perhaps, we should address both issues.
>
>> > This change will have broad impact everywhere the Border is used. And it seems to me to be a workaround for the problem that Metal isn't correctly calculating the length of the text at the scaled resolution.
>>
>> It is possible that the width of the sting isn't calculated correctly, which could explain “cut off” label. At the same time, the text flushed to the very edge doesn't look either. When there's a margin, text looks better and is easier to read. Perhaps, we should address both issues.
>
> So long as such a margin doesn't just become another workaround fix, so
>
> Step 1 - measure it correctly
> Step 2 - add a pixel of clear margin space for added aesthetics.
@prrace @aivanov-jdk I don't see much impact w.r.t to Label position/width for different scaling factors.
The width is computed in [stringWidth(String)](https://github.com/openjdk/jdk/blob/48e61c1df53c11ed49603abd70a3dd62a25f7be5/src/java.desktop/share/classes/sun/font/FontDesignMetrics.java#L457) which is same for all scaling factors (though their are slight differences between scaling factor, its corrected due to 0.5 addition at the end). The position is computed in [layoutCompoundLabelImpl()](https://github.com/openjdk/jdk/blame/526dba1a2942e444bf11d03d8eaf014b5ef20ccf/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1073) which seems to be correct, since the calculation for XPos which is `dx = (viewR.x + viewR.width) - (labelR_x + labelR_width);` seems straight forward.
Is there anything else which I should check or can we move ahead with current fix i.e., setting margin to 2pixels for RIGHT Aligned header text for Metal L&F?
Parallelly I will raise a bug and PR for header border alignment.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14464#issuecomment-1610798256
More information about the client-libs-dev
mailing list