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

["Rob Grzywinski" <rgrzywinski@xxxxxxxxxxxxxxxxxxxxxx>]

> I think that LineBox and boxes in general need to support "padding" and
> "insets".  For first line indentation, the LineBox would have left insets 
>  >
> 0.  The BlockFlow is creating the LineBoxes, so I don't see why
> back-pointers are needed or for LineBox to become anything more than a
> struct (ok, with convenience methods).  Padding would be space outside of
> the content.  Sometimes padding will not be additive.  For example, if a
> block requires 10 pixels below, and the next block requires 20 above, then
> just 20 pixels will separate the blocks content areas.

I've been trying to noodle my through through what I want and what might 
happen with those wants.

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.

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)

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.

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.

Thanks!


-- 
Rob Grzywinski