[REVIEW REQUEST] Add text property to ComboBox

[Alexandre (Shura) Iline]

On 03/15/2012 12:00 PM, Tom Eugelink wrote:
>
> I think I agree in essence with Jonathan on his reasoning, I may want to
> push it even a nudge further. It is a fact that the usage of letters
> (and other symbols) will stay one of the most used data entry methods.
> The other entry method being gestures, whether made by mouse, finger or
> motion (I'm swiping everything onto a single pile; click, drag, swipe,
> shake, etc). All other inputs all translate to these two, for example
> speech recognition equals text. So, as I see it, after parsing the raw
> events, we end up with either text or gestures (this is the syntax layer).

I would argue that you really should be talking about keyboard and 
gestures - not text and gestures.

But that aside, you really are assuming having the editor to be a text 
component of some sort. For entering color I may, for example have a 
container with three text fields (RGB). Can I not do so?

Shura

>
> In the next layer these text and gestures must get a meaning (this is
> the sematics layer). Is a text a number? Is a gesture a list scroll?
> Jonathan's text property hooks at the syntax level (where the input has
> not been validated so to speak), the reasoning below is at the sematics
> level (where a text already has been identified as a number). AFAIK
> there is a call back for the semantics level (at least there is in my
> spinner and I think I copied that from ComboBox).
>
> So since we know that text is a main input method, there would be IMHO
> no harm in adding the text property to the base class. There is a good
> chance a color picker also allows for entering a HTML color code (and if
> not, it simply is unused).
>
> Independent of this discussion, exposing the actual TextField from the
> skin remains a bad idea. Maybe some one will be using a TextArea. So the
> TextInputThingy is a good solution, and as said, that can be on base
> level class IMHO.
>
> Tom
>
>
>
>
>
> On 2012-03-14 21:17, Jonathan Giles wrote:
>> I'm not sure that I agree with this line of thought, but I'm also
>> quite likely wrong.
>>
>> My thinking is that on ComboBox, the text property should exist and be
>> of type String, not T. I think this because ComboBox is a
>> specialisation of the ComboBoxBase class, which I foresee as being the
>> logical point of extension for future ComboBox-esque controls (e.g.
>> Colour Picker). For this reason, the ComboBox specialises in showing a
>> TextField for editing, and a ListView for selection, and there is no
>> escaping the fact that all input is String-based. The text property
>> essentially represents the 'raw' text prior to commit.
>>
>> In other words, I think the current patch on RT-19589 is correct for
>> the text property use case. Future use cases will be handled in the
>> same way - by adding API to ComboBox directly. The text property would
>> be added to ComboBox, not ComboBoxBase, so future combo box
>> implementations can go ahead without the text property clogging up the
>> API.
>>
>> -- Jonathan
>>
>>
>> On 15/03/2012 12:28 a.m., Alexandre (Shura) Iline wrote:
>>> Jonathan,
>>>
>>> Judging from the javadoc, combobox component could handle different
>>> types - not only String. I could redefine the skin, I assume, and
>>> have any editor within it, so, there may not be a text field to get a
>>> text from in the first place.
>>>
>>> Should the "text" property be of a type T and named somehow else?
>>>
>>> Shura.
>>>
>>> On 03/14/2012 04:53 AM, Jonathan Giles wrote:
>>>> Hi all (yet again),
>>>>
>>>> A quick one this time: http://javafx-jira.kenai.com/browse/RT-19589
>>>>
>>>> I'm wanting to add a text property to ComboBox, to allow for people to
>>>> easily set the text in the ComboBox without committing it to being a
>>>> value. More importantly, this also allows for developers to extract the
>>>> content of the ComboBox TextField without having to have end-users
>>>> press
>>>> the Enter key to commit the text into the value property.
>>>>
>>>> Without this end users who want to support Enter-less committing of
>>>> content have to reach into the ComboBox skin, which is not particularly
>>>> pleasant.
>>>>
>>>> Any thoughts?
>>>>
>>
>
>