On Fri, 12 Aug 2022 12:03:23 GMT, Prasanta Sadhukhan <psadhuk...@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
