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

["Rob Grzywinski" <rgrzywinski@xxxxxxxxxxxxxxxxxxxxxx>]

> 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.

By the way, with an "underline" border (a Border that only draws along the 
bottom), you get "free" underline support for text.  So I can certainly say 
that borders on TextFlows are a good thing.  (This is something that I 
didn't consider before.)  I have my reservations about the boolean approach 
that you've outlined but if it's easy to implement then run with it.

> 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,

I outlined this slighly in my other posting but what I envision is using 
Figure's getMaximumSize(), getMinimumSize() and getPreferredSize() to 
specify the max, min and preferred sizes accordingly.  By default the 
preferred width is remaining line size (make sure that there is easy access 
to this value in the code as it will help with implementing a sane 
getMaximumSize() (or maybe you could just use the old override and called 
super.getMaximumSize() trick to determine what the max allowed is)).  I have 
no thoughts on the default preferred height -- just follow the paradigm used 
in Figure I suppose.  By default the max and min are the preferred.  If 
someone makes the max larger than the remaining line then they're just SOL 
(i.e. it gets cut off) -- this is true both horizontally and vertically.

As I mentioned in my other posting, if one makes the "context.endLine()" 
calls in BlockFlowLayout variable based on if the BlockFlow is inline or not 
(i.e. call context.endLine() if non-inline otherwise do not).  I haven't 
seen any other changes that are necessary.

One other requirement that seems to be a must with all of this is making 
InlineFlow and by extension TextFlow have the ability to be set to 
"non-break" (i.e. any TextFlows in an InlineFlow or the TextFlow itself will 
never be broken into fragments).  It seems that if ParagraphTextLayout (at 
least in the TextFlow case) had a WORD_WRAP_NONE and 
FlowUtilities.getTextForSpace() was enhanced to simply return the total 
width, then the requirement would be satisfied.  (I don't have any thoughts 
on how to do with with InlineFlow unfortunately.)  It would certainly be 
possible for a string to be cut off if it was larger than the allowed width 
but this is to be expected.  Combining InlineFlows and TextFlows with this 
"no wrapping" would provide great flexibility on how lines are wrapped.

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

One concern I have is with getAscent() and getBaseline().  In order to 
ensure that text lines up vertically, all baselines (which does not include 
any insets) must match.  I know this is obvious when you're working on it, 
but currently FlowBox's getAscent() returns getHeight().  This is one of the 
few places that it should have been "height" =D

As for vertically aligning the inline BlockFlows, (I'm assuming that if text 
is aligned on its baseline) the baseline of a BlockFlow will be changed 
based on its vertical alignment.  One could extend this idea further by 
allowing a subclass to override this and allow arbitrary vertical alignment.


-- 
Rob Grzywinski