ComboBox and cell factories
omurata at ga2.so-net.ne.jp
Wed Apr 18 18:53:45 PDT 2012
Hello, Jonathan Giles
'buttonCell' property is a great idea.
I agree with approach 1
(2012/04/19 7:16), 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
> 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