On Thu, 11 Aug 2022 16:43:29 GMT, Damon Nguyen <dngu...@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
