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

List:       koffice-devel
Subject:    Re: text-on-shapes and EnhancedPathShape's text-areas attribute
From:       Thomas Zander <zander () kde ! org>
Date:       2010-09-21 20:10:40
Message-ID: 201009212210.40956.zander () kde ! org
[Download RAW message or body]

On Tuesday 21. September 2010 20.45.35 Marijn Kruisselbrink wrote:
> On Tuesday 21 September 2010 10:31:26 zander@kde.org wrote:
> > > I'm not quite sure yet how option (b) would work, especially in the
> > > presence of potentially multiple decorators. The EnhancedPathShape (or
> > > its tool) would basically have to walk up the tree of parents until it
> > > encounters a KoTextOnShapeContainer, or until it encounters the first
> > > container that is not a decorator? But how would it detect if a
> > > specific shape is or is not a decorator?
> > 
> > When we brainstormed about the concept of multiple decorators some months
> > ago we realized that its actually only a theoretical concept, not an
> > actual issue. We failed to find any usecase where walking up the tree
> > was useful, let alone needed.
> > The end result is that you need to dynamic cast only the parent() for
> > option (b).
> 
> Hmm, okay. Then I guess we'll just have to hope we'll still remember all
> the places we made use of the assumption that never more than one
> decorator will exist if we ever do come up with a usecase for multiple
> decorators on one shape.

Oh, we will have multiple decorators for one shape. Thats clear in my mind. 
Sorry if I was not being clear.
The point that I wanted to make is that if you decorate Shape S1 with D1 and 
decorate D1 with D2 which is a TextOnShape based docorator, then whatever S1 
looks like is completely irrelevant to D2.
Hence you only need to every do one parent().

> Anyway, attached is my attempt to implement option (b).

Actually, from your explanation below it seems you implemented (c) ;-)
As I wrote in my initial mail; the setting of the position and size is now 
spread over two classes. The extra 'if' in line 161 of your patch and the need 
to move the 'addShape' around gives me the impression the two are too much 
intertwined now.

> I needed to make a
> couple of changes to KoTextOnShapeContainer for this:
> - expose the internal text shape so it is actually possible to resize this
> from the outsize

Maybe you can add a setter instead, something like 
KoTextOnShapeContainer::setPreferredTextRect(const QRectF &rect);
and this rect would be used.
This would simply be a proxy method but it can also store the rect so a later 
creation of the shape can properly set the size.
Rationale; the text shape member can be null, this is an implementation detail 
that should not be exposed to the world.

> - add a ResizeBehavior that tells KoTextOnShapeContainer to leave the
> size&position of the text shape alone
You named it; ContentDictatesTextSize
Which I initially interpreted to mean that the resize behavior is based on the 
content *size* ;)
Anyway; if we get the new method above the naming is easier; 
TextFollowsPreferredTextRect

> With these changes, and the corresponding extra code in EnhancedPathShape,
> the text shape seems to get the proper size&position, even when moving
> around it's handles and things like that.

Awesome! :-)

I'd say this is a new feature, so for after 2.3 is branched off. But I like it 
for sure.
-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]