[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-20 17:46:34
Message-ID: 201009201946.35049.zander () kde ! org
[Download RAW message or body]

On Monday 20. September 2010 15.28.13 Marijn Kruisselbrink wrote:
> Currently KoTextOnShapeContainer always creates a text shape that is the
> same  size as the shape it is wrapping. However this is not always
> correct.

Yes, the current implementation is the most common one, but there should be 
different layout algoritms.  Think differnet QLayout (or QGraphicsLayout)  
subclasses having different algorithms.  But instead of having a setLayout() and 
a class (the Strategy design pattern) I started the design with
enum ResizeBehavior
KoTextOnShapeContainer::setResizeBehavior(ResizeBehavior rb);

> For draw:enhanced-geometry type shapes (EnhancedPathShape) there
> could be a draw:text-areas attribute specified, which specifies where
> exactly on the shape the text area should be (with possible different text
> areas depending on style:writing-mode). This is used for example in shapes
> with rounded corners and things like that to have the text properly
> positioned inside the shape.

the ODF spec seems to say there is a square that can be specified on top of te 
enhanced path shape where the text should go. Ok, sounds sane.

> So somehow there would need to be some API for KoTextOnShapeContainer to 
> figure out what area the textshape should have (or for EnhancedPathShape
> to  tell KoTextOnShapeContainer this).
> To make it even more complicated, if a user moves around one of the handles
> of  an EnhancedPathShape, the text area can change, and thus somehow
> EnhancedPathShape will need to be able to notify KoTextOnShapeContainer
> about  this change.

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?

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


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.

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.

c) So, on resizing the EnhancedPathShape you get a new textArea (apparently) 
and why not set the text-shape to that directly.
This looks like the logic is in the wrong place for this option to be nice, 
though. The text-shape is owned by another shape and it sounds wrong to have 
layout in two different places.


> 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

> So, anybody got suggestions on how to add this possibility to the current 
> text-on-shape support?

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