[news.eclipse.tools.gef] Re: draw2d.text indent strategy

["Randy Hudson" <none@xxxxxxxxxx>]

> What I -really- want is the ability to place a border on a element in a
> FlowPage.  I want to be able to either place a LineBorder around a word or
> series of words or place image decorations on a piece of text via a Border
> (this one only makes sense to do on a single word).
>
> This want leads to some interesting implications.  If TextFlow supported
> borders then what happens when a single TextFlow is broken into two lines?
> How is the border split between the two lines?  Are there just two borders
> (the same Border's paint() is called twice)?  This can lead to some
> interesting and unexpected results.

Yes, the border would paint for every one of the figure's fragment.  The
modified paint method would contain two booleans indicating whether the left
and right sides are to be closed or open.

> So what we really want is some "indivisible unit" that can be added inline
> to the flow that supports borders.  (This implies that InlineFlow would
> throw UnsupportedThingy on setBorder().)  BlockFlow seems to fit the
> requirements but it would need to be enhanced so that it is less like a
> <div> and more like a <span>.  To be more precise, a BlockFlow needs to be
> enhanced to be either inline or block (ala the CSS "display").  (Yes, I
know
> your goal is to support CSS2-like functionality.  I'm just putting in my
bid
> for the order of functionality implementation.)

> There is already an InlineFlow but this seems to just be a container
rather
> than a "block flow that is inlined".  (If it is decided that BlockFlow
won't
> be modified to add the inline functionality then there might be an
> InlineBlockFlow.)
>
> Having this inlined BlockFlow would allow me to do:
>
>             +--------+
> Before text | Inline | After text
>             | Block  |
>             | Flow   |
>             | Text   |
>             +--------+
>
> (please excuse the ASCII art -- you will need fixed width fonts to view
> correctly but hopefully the idea is evident regardless)

That's an interesting idea but how does the inline-block know how wide it is
going to be?  Is it based on its content, or is it's width hard-coded, or a
percentage of the line width.  This would be easy to implement, if the
requirements were well described,

> This is something else that I really -really- want to be able to do.  This
> obviously brings up questions of alignment and flow issues (i.e.  where
does
> text added after "After text" go?  To the left of the box?  Below the box?
> All of these are already defined by CSS2 so I would follow that.) but that
> can wait.

Wrapping around boxes is not going to be addressed any time soon :-)

> While I was determining the LOE on this inline BlockFlow I cam to a
> screeching halt when it comes to supporting Borders on BlockFlows.  It
seems
> that someone was a bit too liberal with the package local "width" and
> "height" on FlowBox =D.  If TextFlows aren't going to have borders (which
I
> don't think they should for the reasons pointed out above) then the insets
> only need to be incorporated up at the BlockBox level (I don't think that
it
> makes sense anywhere below that).  You would just want to override
> BlockBox's getWidth() and getHeight() to include the insets but everyone
> pokes their grubby fingers directly into FlowBox's width and height.
>
> I'd like the following:
> o  Some validation on what I've been rambling about above (specifically
> inlined BlockFlow, no borders on TextFlow, and borders on BlockFlow)
> o  A feel for where implementing this is on the queue so that I know if I
> should just wait or dig in.  I hesitate to dig in to the whole border
thing
> given FlowBox's width and height nastiness.

I don't see any difficulties with the box stuff.  I'll start looking into
it.

> Thanks!
>
>
> -- 
> Rob Grzywinski
>
>