Re: A couple of problems with KoShapePaste

Thomas Zander <[email protected]>
Newsgroups gmane.comp.kde.devel.koffice
Message-ID <[email protected]>
On Thursday 4. November 2010 10.11.57 Dmitry Kazakov wrote:
> Hi, All!
> 
> I have a problem with KoShapePaste.
> 
> 1) We have two way of adding a shape into the document. And both of them do
> different things. I can't get what is the right way to do this.
>     a) We can simply add a shape to some other shape, that is already part
> of the document
>     b) We can add a shape to the document using a shape controller
> (KoShapeControllerBase)

The first is not a complete way of adding a shape. The first way also requires 
you to add the shape to *all* shapeManagers.  Which in case of a multi-view 
KPresenter is pretty hard to do.
Or, in other words, adding a shape requires you to always add it to the 
controller.

One thing has to be pointed out;  if you have a shape that has various children 
(and they may have children) then adding that top-level shape to the controller 
will automatically add all child shapes to all the current views too.

So, if you add a shape hierarchy like a kchartshape to the shapeController you 
add all shapes in one go.
If at a later time the user enables the legend and thus the new legend shape 
should be painted from then on too. This means the legend should set its parent 
to the kchartShape and then the legend shape should be added to the controller.

> As far as i understand, the variant b) implies the variant a), that is when
> you add the shape to the controller, it is automatically added to some
> parent shape. Is it so?

Its possible, yes.
In practice you want to make sure you set the proper parent before adding it to 
the controller. The controller is able to set a parent, for example to add the 
shape to the current layer.
KWord doesn't have layers currently and in most cases the parent will not be 
changed when you add a shape to kword.

> It brings the first question, why KoShapePaste::process() first sets the
> parent of the shape (uses way a) ) and then adds the same shape into a
> controller (using way b) )? Why can't it just add this shape to the
> controller in the end of the function?

This way it ensures the parent is who it should be, instead of anticipating 
what the pure virtual controller would do.

> 2) And one more question, if i add a shape using method a) to some other
> shape that already is a part of some manager, will this shape be painted on
> the screen (in a KoShapeManager) ?

In most cases, no it won't.
The shape will also not be found in an update call or when clicking on top of 
the shape.
The child shape has to be explicitly added to all shapeManagers that own its 
parent if you want to show it. Adding a shape means the shapeManager puts it 
into its rtree which is the managers entire view of the world.
 
> 3) And the last question, why KoShapePaste searches for "a nice place for
> our shape" in the shape manager instead of a parental shape? I think it
> would be more logical to search for collisions inside a parental shape? Or
> there are some problem present?

A shape doesn't have to have a parent. :)
If you have KWord with each text-frame is a shape and it doesn't have a parent. 
Then if you copy the text frame and paste it as a new frame without a parent, 
it would not be possible to find out the little offset that we want.

Notice that a shapeManager uses an rtree to map the 2d space of the document 
and thus finding a shape at a position is not very expensive.
The cost is payed once only, upon insertion of the shape into the rtree. Lookup 
is cheap from then on.
-- 
Thomas Zander
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.