ComboBox and cell factories
richard.bair at oracle.com
Wed Apr 25 14:57:36 PDT 2012
On Apr 23, 2012, at 12:46 PM, Jonathan Giles wrote:
> Thanks everyone for the feedback on this issue. I am now seeking a +1 from Richard. I guess I will follow normal procedure and give 24 hours notice for this, and will otherwise assume approval by neglect :-)
> -- Jonathan
> On 19/04/2012 10:16 a.m., Jonathan Giles wrote:
>> Hi all,
>> Today I have a new topic I'd like opinions on:
>> The ComboBox control, being the specialisation of the ComboBoxBase class, is a Button/TextField and ListView specific control, as I mentioned yesterday. The basic issue is that there was an oversight when developing Combobox for 2.1. The issue is that, whilst it is great to support a cell factory in not just the popup listview, but also in the button area itself, it is often the case that you want the representation to be different. Currently, one cell factory is used for both the Button and the ListView.
>> The jira issue has screenshots demonstrating where this is an issue in the HTMLEditor control. Basically, you don't want to render a font name in the button area, and you don't want the font size to be shown in the button area (as large font sizes will grow the height of the button).
>> So, to resolve this, we need to support having a way to configure a separate cell to be shown in the button area and / or to use the default cell in the button area (whilst using the custom cell factory for the listview). The question comes down to how obvious we want the API to be. Some options I can think of include:
>> 1. Adding a separate ComboBox 'buttonCell' property of type
>> ListCell<T>. If this property is set, it is used for the button
>> area. If it is not set, we should use the default 'toString' cell
>> (rather than using the ComboBox.cellFactory to generate a cell, as
>> we do now). If a developer wants the same rendering in the button
>> as the ListView, they will now need to create a cell from the cell
>> factory they have set in the ComboBox.cellFactory property, and
>> manually set that in buttonCell property.
>> 2. We can make the API less obvious by setting some property in the
>> ListCell used in the button (from the skin). This property can
>> then be watched for in the custom cell instances, drawing as
>> appropriate. The place to set any property would be in the
>> properties map, rather than adding new API to ListCell.
>> My preference is strongly towards approach 1, but I would be interested in hearing your feedback, on these options, as well as other options. I would like to fix this for 2.2, but time is short so I would appreciate your feedback as soon as possible.
More information about the openjfx-dev