Re: A couple of problems with KoShapePaste

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

Ok then, but why does it set the parent in the beginning of the function and
add it to the controller in the beginning of the function? Isn't it possible
to write these two lines together one-under-the-other-one? I mean not to
split them with this big loop in the middle.


Actually, as far as i understood it, it looks like one logically single
action of adding a shape to the document became split into two different
(and a bit self-duplicating) calls. That is surely not good from the point
of view of thread-safety of flake.



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

Why so? Why not just paint the children recursively? Is there any objective
reason against it?



-- 
Dmitry Kazakov

_______________________________________________
koffice-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/koffice-devel