[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:       Marijn Kruisselbrink <m.kruisselbrink () student ! tue ! nl>
Date:       2010-09-20 20:37:11
Message-ID: 201009202237.12110.m.kruisselbrink () student ! tue ! nl
[Download RAW message or body]

On Monday 20 September 2010 19:46:34 Thomas Zander wrote:
> You say the text area can change; I'm wondering how you see that would work
> in practice as the spec doesn't go into that. I don't see how the text area
> would change when that happens. What would happen?
EnhancedPathShapes in odf can define various handles, than when manipulated by 
the user affect the actual path of the shape, by changing values of certain 
shape-internal variables. The text area for an enhanced path shape is also 
specified with functions that can refer to those variables, so when a handle 
gets moved (for example to change the roundness of a corner, or the waviness 
of some wavy box), the area that text on that shape can contain should also 
change following those equations. So it is not a question of resizing the 
enhanced path shape, but actually when the path inside the path shape is 
edited, this could result in the text area as specified by the path shape 
being changed.

> In ODF we have this rather odd situation where the concept of text-on-shape
> is essentailly repeated various times. By which I mean that instead of
> having a nice abstraction the stuff is a bit intertwined and in this case a
> feature that *could* be used on all text-on-shape-supporting shapes is only
> availabe under the enhancedPathShape.
Well, the whole equation and handle thing is something rather specific to the 
enhanced path shape. A different shape could potentially have something 
similar, but I think it sort of makes sense that a user only gets one set of 
handles/controls to manipulate both the shape and the area the text can 
contain in that shape.
> So it looks a bit like the situation we had where it could make sense to
> have text-on shape for all types (text-on-music-shape for instance) but we
> don't because ODF doesn't support it.
> The solution we choose there is to have the ability in the API for all
> shape types (i.e. you could write code to get that text-on-music-shape) but
> not provide any user interface to do so. And no loading-saving code to do
> so.
>
>
> So it looks like we have the choice of putting this functionality in 3
> places a) KoShape gets a textArea property and the text-on-shape class
> listens to changes.
> b) KoTextOnShapeContainer gets a layout-strategy thats based on a property
> set on the TextOnShapeContainer by the tool or the enhancedPathShape on
> resize.
> c) KoTextOnShapeContainer gets a layout-strategy that says it 
> should not do layout and the EnhancedPathShape does the layout itself.

Both b) and c) seem to imply that the tool or shape would need to know about 
the KoTextOnShapeContainer, and somehow figure out if the shape is wrapped in 
one (not sure of any easy ways to do that except a dynamic_cast on the 
parent). But maybe I'm missing something that would make this more feasible.

> My comments on these options;
> a) The design should look pretty straight forward. Easy to implement.
> On the other hand it looks like overkill and its following ODFs mess of
> entanglement. Just one shape type can use this and that one is not even in
> flake itself, sounds odd to have a property for that.
Yeah, this would not be the nicest way to implement this, but certainly the 
most straightforward. Either of the other options seems to rather go against 
the whole decoration pattern by having to make the enhanced-path-shape aware 
of if it is being decorated by a KoTextOnShapeContainer (which might not even 
be the first parent if multiple decorators are in use), which would make the 
code in that place a lot more complicated (and fragile).
Adding interface for this to KoShape also would seem to be more in line with 
making the API more powerfull and potentially usefull than what potentially 
can be stored in odf. Odf might not support custom text areas for shapes 
besides the enhanced-path-shape, but no reason to limit flake to that I would 
think? Various shapes probably will have different algorithms to actually 
calculate their text area of course.
>
> b) A layout strategy based on size sounds pretty generic to me, which is
> good and re-usable. There is still the mixing of an enhancedShape resizing
> (apparently) adjusting its text-area. But that seems to be present in all
> options. The negative here is that this mixing is expressed in the
> pathShape finding out if there is a KoTextOnShapeContainer by casting.
> Not nice, and it would be nice to avoid. But that entirely depends on what
> you mean with the EnhancedPathShape changing the text area on resize. What
> speaks for this option is that if there is entanglement in the
> enhancedPathShape inherent due to ODF, then lets keep that uglyness
> contained there.
Well, I'm not so sure I consider it uglyness. I think it is not very strange 
to have a link between the actual shape and what area of that shape is usable 
to put text on, and something that could potentially be usefull even for 
other shapes (although odf unfortunately does not support it that way).
And as said, it is not just about changing the text area on resizing of the 
enhanced path shape, but also on actual changing of parameters of the path.
>
> > The first part of this problem could be solved by adding a virtual QRectF
> > textArea() method to KoShape, although I'm not sure if that would be the
> > best  solution.
>
> That would by my option (a)
>
> > The second part is a bit harder, and I don't really have
> > any ideas at the moment how that could be best solved using the current
> > KoTextOnShapeContainer design. If KoShape would be a QObject adding a
> > signal  to it for this purpose would work, but that's not really a nice
> > solution (and KoShape is not a QObject, so it's not an option anyway).
>
> KoShape has signals as such; see the
>      virtual void KoShape::shapeChanged(ChangeType type, KoShape *shape =
> 0); callback and several similar ones in KoShapeContainerModel
Ah yes, I see; KoTextOnShapeContainer could implement childChanged() to listen 
to a change in the text-area of its wrapped shape, that would definitely 
work, yes.

> My personal preference would go to my option (b), but I don't have all the
> details and as such I wrote a pretty long email to go over all relevant
> details.
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?

Marijn
_______________________________________________
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]