[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:       zander () kde ! org
Date:       2010-09-21 8:31:26
Message-ID: 201009211031.26529.zander () kde ! org
[Download RAW message or body]

On Monday 20. September 2010 22.37.11 Marijn Kruisselbrink wrote:
> 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.

Thanks, makes sense now :)

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

Oh, I was still under the impression it was just one, the enhanced path shape. 
Can you give an example of another type?
I'm personally thinking we should not add API to KoShape lightly, so if the 
need is there then fine, but the thrashold for adding it should be high.

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

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