The need for a FixedText control
steve.x.northover at oracle.com
steve.x.northover at oracle.com
Wed Jun 20 13:13:20 PDT 2012
setContentType (the second approach) is good in that it allows HTML
parsing to be controlled. If the default is "true" (or "content type
html"), then you get the first approach and the ability to turn it off.
Steve
On 20/06/2012 3:48 PM, Richard Bair wrote:
> That's correct, it just gets more cumbersome (having to escape the<html> tag or something for example). Or I guess it could be some API, I hadn't thought of that. disableHTMLParsing. But for compatibility it would have to be set to true, so maybe have enableHTML and then having to specify the HTML string.
>
> Personally I liked having setContentType and making it more open ended.
>
> Richard
>
> On Jun 20, 2012, at 9:42 AM, steve.x.northover at oracle.com wrote:
>
>> Even if you take the first approach, you will still need a way to turn off the default behavior in the (rare) case where you actually want to show the markup.
>>
>> Steve
>>
>> On 15/06/2012 2:57 PM, Richard Bair wrote:
>>> I would just use a Label. The use of labelFor is optional, and without it, it is exactly what you're looking for (pending support for rich text, more in a second). I don't think adding a new class / control for the use case is justified when you can just use a Label for it.
>>>
>>> Now, what I've wanted (and hopefully will get in Lombard) is the ability to set rich text on any Labeled. So on a Label, Button, CheckBox, etc you would be able to set rich text. There have been two ideas, principally, around this. The first is to just semantically inspect the string, much like Swing, such that "<html>Rich<b>Text</b></html>" ends up being handled properly. The second idea is to add a "contentType" property, such that you can set the contentType to TEXT_HTML (or whatever) and then we know what to interpret the String of characters as.
>>>
>>> The benefit of the first approach is that it requires less tinkering and we don't have to figure out what the "content type" is (do we just reuse javafx.scene.input.DataFormat? It has HTML, PLAIN_TEXT, RTF, etc. FILES and IMAGE don't make sense, but what the heck). We would just have built in support for HTML and that's it.
>>>
>>> The benefit for the second approach is that it is (a) clear how you intend for the string to be interpreted and (b) extensible. We could add new supported formats (such as, for example, bbcode or something) and it would still be as easy to set. Basically you just set the string and tell us how to interpret it, and for supported formats, this would just work.
>>>
>>> Richard
>>>
>>>
>>>
>>> On Jun 15, 2012, at 10:58 AM, Randahl Fink Isaksen wrote:
>>>
>>>> I think JavaFX is missing a text control for presenting uneditable, styled text - a FixedText control. As I am about to file a feature request, I thought it would be relevant to discuss it here first.
>>>>
>>>> In the following UI the left column shows three labels implemented using Label, and the the right column has a field showing the Customer ID, a CheckBox for editing the VIP status of the customer, and finally a TextField for adding some kind of note about the VIP status:
>>>>
>>>> Customer ID: 12345678 (non-editable text)
>>>> VIP: [x] (editable CheckBox)
>>>> VIP note: |_________| (editable TextField
>>>>
>>>> In this UI, the user is always able to edit the VIP CheckBox, and if it is checked, the previously uneditable VIP note TextField becomes editable. The customer ID is never editable. So what component do we choose when implementing the uneditable customer ID field? Our options are:
>>>>
>>>> 1. Implementing the customer ID field as a label.
>>>> 2. Implementing the customer ID as a TextField which is marked uneditable.
>>>> 3. Implementing the customer ID as a raw Text instance.
>>>>
>>>> None of these options are very pleasing:
>>>>
>>>> - 1. Using a label is semantically incorrect, since it does not label anything (the labelFor property would have no meaning). Also, it would at least require a special style class to distinguish it from real labels, and it would not be efficient to have to set this style class everywhere we have a non-editable text field.
>>>>
>>>> - 2. Using a TextField for which editable has been set to false is not that good an idea either - by default, TextFields are rendered as a box, which indicates that the user can input something here, at least at least in some situations (like the VIP status field above). Again, we would require special styling for it to look different from other real TextFields, and we would have to set a specific style class everywhere we had a non-editable text field.
>>>>
>>>> -3. Using a raw Text instance is a bad idea too, since it is not a real JavaFX Control, which means it does not automatically have a style class of "text", it is not skinnable, cannot be copied using mouse gestures, is not draggable, etc.
>>>>
>>>> So my thoughts are, that JavaFX could benefit from a FixedText control. This would work much like a TextField, only it would mean "a forever uneditable text control". It would by default have a style class of "fixed-text", the user would be able to mark and copy its contents, drag it, etc. - just like the contents of a TextField.
>>>>
>>>> Any thoughts?
>>>>
>>>> Randahl
More information about the openjfx-dev
mailing list