RFR: 8054572: [macosx] JComboBox paints the border incorrectly [v5]

Prasanta Sadhukhan psadhukhan at openjdk.org
Fri Aug 12 12:07:14 UTC 2022


On Thu, 11 Aug 2022 16:43:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed comment. Added space.

I am not sure if this is correct approach...
Have you seen any macos documentation citing combobox height should not increase even if font size change? 
That might be problematic for say, accessibility usecase, for slight visually impaired more hearing impaired, where we need to draw them big, right?

So, assuming it's a issue, I think
Since textField height changes with font size, why can't we use the same rectangleForCurrentValue() with which we draw the textField height, for arrowButton height
 as seen here (https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java#L470)

I see that we call [AquaCombobBoxButton](https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java#L163) with `height`. 
Are you saying this height, even you change according to font size,  is ignored?

Then it seems this painter.paint() which calls AquaPainter.paintFromSingleCachedImage() which calls MultiResolutionCachedImage to create a MRI maybe is not creating proper MRI image as per the given arrowbutton size.
Can you find out why?  

Maybe non-editable combobox can have "single cached image" to have single-sized arrowbutton, but it may not be correct for editable combobox where font size can be changed 
OR maybe non-editable combobox not changing height for diff. fontsize, also is a result of the above MRI creation issue.

-------------

PR: https://git.openjdk.org/jdk/pull/9473



More information about the client-libs-dev mailing list