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

Damon Nguyen dnguyen at openjdk.org
Mon Aug 15 17:54:11 UTC 2022


On Fri, 12 Aug 2022 12:03:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> 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.

The best documentation I have is the webpage for pull-down buttons here:
[https://developer.apple.com/design/human-interface-guidelines/components/menus-and-actions/pull-down-buttons](url)

There's no text describing the behavior, but the image shows a bracket and lines with arrows on each end to show variable width of a pull-down button. However, for height, the bracket has no arrows, which indicate that the height is fixed.

I'm currently looking at the MRI image issued, but that image combined with the behavior of non-editable comboboxes (even with larger fonts) led me to believe this approach was acceptable.

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

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



More information about the client-libs-dev mailing list