[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    A DOM for JavaFX (Re: High performance text component)
From:       zonski () gmail ! com (Daniel Zwolenski)
Date:       2012-08-31 0:46:21
Message-ID: CANbPsPz2Gs6vKes_MfK=CgA-24Ffa6HRbppC+-c-aDwNX6gDpA () mail ! gmail ! com
[Download RAW message or body]

I think maybe the topic here should change, this sounds huge to me. Some
big things I like about this, but some bigger concerns.

First reaction is why do we have two things a "Scene Graph" and a "DOM",
why not just one. Also "laying out" will inevitably creep in here for 'rich
text' if you go down this road (see 'overflow: hidden' comment below,
what's next, 'padding', 'height', or shudder 'position', 'float', etc).

Your comment:
> which might make sense in some document heavy scenarios

A webapp (even the richest of rich) is a 'document heavy scenario', i.e.
all things can be seen in this category, where's the line (lessons from the
web would say there isn't one).

I think I need to digest a little more though, this feels like a
fundamental change in the way things could/should be done.


On Fri, Aug 31, 2012 at 9:33 AM, Richard Bair <richard.bair at oracle.com>wrote:

> Either, both, and neither ;-)
>
> The rich text support that Felipe is targeting is two-fold: a new Parent
> node (possibly extending from Region) which would take Text nodes as well
> as ImageViews, MediaViews, Buttons, Tables, etc, and lay them all out. For
> runs of Text nodes of different styles, it would lay them all out such that
> bidi, complex text, etc all work correctly. So basically, a programmatic
> way to lay out text, and to be able to flow any other Node with the Text
> (as any good rich text layout engine would do).
>
> In addition, we want to add the ability to display rich text to Labeled UI
> controls, such as Label, Button, Cell, etc. For these, we feed it a textual
> string (as we do today) but it ends up being parsed and turned into Div /
> Text rich text Nodes. Much like feeding HTML to a Node in DOM would create
> additional DOM nodes.
>
> So you could use this layout as a flow based layout for constructing your
> UI -- which might make sense in some document heavy scenarios. However it
> doesn't have the full box model (some partial support maybe such as padding
> etc, but no float). It could be used as the basis for a Rich Text Editor --
> I'd probably use a specialized ListView to virtualize rows of RichText
> paragraphs (such that each cell is a Paragraph/Div thing). That would make
> for a blistering fast editor, with full rich text, line wrapping, etc
> almost for free (you have to handle the keystrokes and such, and not to
> discount that, but the rest of it would "just work", assuming we expose
> selection API and hit testing).
>
> You could use it for adding rich text to cells in a ListView without
> having to write a fully custom cell factory. Just feed the cell some rich
> text string which gets turned into nodes and off you go.
>
> Richard
>
> On Aug 30, 2012, at 4:04 PM, Daniel Zwolenski wrote:
>
> I'm a bit confused, are we still talking about a rich text editor here or
> a whole new way to build scenes?
>
>
> On Fri, Aug 31, 2012 at 8:38 AM, Felipe Heidrich <
> felipe.heidrich at oracle.com> wrote:
>
>> Not sure,
>>
>> CSS has the overflow property (visible | hidden | scroll) that specifies
>> what would happen in this case.
>>
>> Do we have this concept in JFX ?
>>
>> What happen if I place a Rect(10, 10, 100, 100) in a Region that is (50,
>> 50) ? it overflows right ?
>>
>> Felipe
>>
>> On Aug 30, 2012, at 3:16 PM, Richard Bair wrote:
>>
>> >>> Extending region to get CSS is a good thing, but Region has width /
>> height and is resizable. We could move CSS support up to Parent, or make
>> sense of DIV having a specific width and height (width is useful because we
>> then wouldn't need "wrappingWidth" -- ie, they are the same thing, and it
>> would be resizable so adding it to a layout container would perfect. But
>> what to do about the height? If the height isn't right, do we just flow the
>> text beyond the given height? Kind of a weird case). Or we can add CSS
>> Background / Border support to TextFlow independent of the Region.
>> >>>
>> >>
>> >>
>> >> I thought about this a little bit yesterday, if we choose to make Div
>> a subclass of Region we would probably remove setWrappingWidth(double) and
>> add:
>> >> setWrapMode (none | word | character) or use CSS names (word-break,
>> word-wrap).
>> >>
>> >> As for the relationship between the width and height, the way I
>> thought, if word wrap is requested then content bias is set to horizontal,
>> otherwise is null.
>> >>
>> >> Does that make any sense ?
>> >> as I said,  I didn't think about this very much?
>> >
>> > But what should we do if the region's width/height is set so small that
>> we can't show all the text. Do we clip, or let it run over?
>> >
>> > Richard
>>
>>
>
>

[prev in list] [next in list] [prev in thread] [next in thread]