GitLab

There was a weird recursion problem in setParent()/addShape()
functions. Now KoShape can use only specialized interface of
the container that should not be used by anyone else.

This is a mandatory function to be able to load shapes from SVG,
because the same shape may be instantiated from different places.
We still need to discuss whether we need to really "share" the
shape template, but for now I just deep-copy them (which is the
easiest because of shape normalization problem we have).

There are the following drawbacks/hacks in this patch:

1) Not all the shapes have KoShape::cloneShape() implemented! Basically,
   it is defined only for group shape and all the descendants of a path
   shape (which are the only shapes used in SVG). Other shapes use the
   default implementation which simply returns null.

   Ideally, there should be no default implementation and all the shapes
   should define it. But, given that we are going to deprecate quite a lot
   of stuff, I'll keep them just unimplemented for now.

2) The following shape properties are not yet copied during cloning:

   * toolDelegates
   * dependees
   * shadow
   * border
   * filterEffectStack

   All the properties, except of tool delegates will probably be
   deprecated soon. And for the tool delegates we need to invent
   something ingenious to handle the pointers to recover pointers
   to the *cloned* shapes.

3) I cannot guarantee TextShape's work anymore. I just blindly
   refactored it to use QScopedPointer to QTextDocument instead of
   the previous raw pointers trickery and never tested it. Hope it
   still works...

Differential Revision: https://phabricator.kde.org/D879

At the moment it's an empty class but soon it will be used to pass various settings like
showFormttingCharacters in text etc.

The paintDecorations method has been removed. any such functionality can be done much better
using the KoShapePaintingContext.

REVIEW: 102809

This makes sure that pages are always deleting there layers and children of them what fixes a crash in the textlayout-branch.
Also I merged the both ctor's together, introduced a KoShapeContainer::removeAllShapes method and improved the documentation.
BUG:270960

This makes sure that pages are always deleting there layers and children of them what fixes a crash in the textlayout-branch.
Also I merged the both ctor's together, introduced a KoShapeContainer::removeAllShapes method and improved the documentation.
BUG:270960

svn path=/trunk/koffice/; revision=1151041

When the KoShapeContainer was introduced it had a 'clipped'
property which implied two things;
 * the shape is clipped to the outline of its parent container.
 * the shape inherits the transformation of its parent container.

When I used a container, now 4 years later, I was confused why my
shape didn't inherit the transformation and only by reading the code
did I figure out thats because I designed it that way...
Now it doesn't make sense to me anymore that one implies the other,
the connection between them is a bit thin.
So, split up the two properties and provide plenty of API docs on the
matter.

Incidentally, this helps a usecase where I need the inherit concept
but not the clipping concept ;)

svn path=/trunk/koffice/; revision=1129452

svn path=/trunk/koffice/; revision=1127827

Make the methods much more consistent both with each other
and with other classes which follow a Qt-ish api.
childClipped() -> isClipped()
setClipping() -> setClipped()

etc.

svn path=/trunk/koffice/; revision=1124024

The patch adds a KoPageProvider that can give back a KoTextPage for
shape. This is done in the paint event of the textshape. It will
relayout the textshape if needed (when the page number changed) and
will block all update calls when doing so to avoid retriggering of
the paint event.

If a application does not offer a page provider the behaviour is the
same as before. It is possible to use this behaviour for selected
shapes only if an app whishes.

BUG: 187838

svn path=/trunk/koffice/; revision=1025130

less malloc and object allocation for each shapeContainer :)

svn path=/trunk/koffice/; revision=990517

  as discussed in Berlin


svn path=/trunk/koffice/; revision=979525

class to also change all the implementations of this method in derived classes


svn path=/trunk/koffice/; revision=978533

svn path=/trunk/koffice/; revision=956586

Somehow flake/ got left out.

svn path=/trunk/koffice/; revision=865831

svn path=/trunk/koffice/; revision=791217

This should fix the case when you move a container and shapes that are not clipped to its container were not properly redrawn.

svn path=/trunk/koffice/; revision=782003

svn path=/trunk/koffice/; revision=694289

svn path=/trunk/koffice/; revision=690223

svn path=/trunk/koffice/; revision=671631

to ask if that shape can be moved / rotated.
This has the effect that the layer can return false when the layer is locked,
while the other containers just return the locked bool on the shape.

Fixes moving of inline objects in KWord to work again.

svn path=/trunk/koffice/; revision=664968

Make KoShapeContainerModel compile on its own
Replace all 'object' references to 'shape' as a long time ago we renamed the classes

svn path=/trunk/koffice/; revision=650925

Noted that the KoShapeLayer had a copy paste of a SimpleShapeContainerModel
from KoShapeGroup, so splitted that out into its own file and remove the
duplicate.

svn path=/trunk/koffice/; revision=650915

svn path=/trunk/koffice/; revision=650829

I always wanted to write that word :)

svn path=/trunk/koffice/; revision=642823

apparantly private inner classes are not a smart thing to have an a public
and installable header file.

svn path=/trunk/koffice/; revision=638066

many changes in flake lead to a big recompile of the whole of koffice.
So, lets do this at one go; convert most public classes to use a d-pointer
which will result is much less changes in the header files.

svn path=/trunk/koffice/; revision=636203

svn path=/trunk/koffice/; revision=630084

Split up koffice_export.h into individual files, so that a new lib or a macro fix doesn't necessarily mean recompiling all of koffice; it also makes it easier to move a lib somewhere else later etc

svn path=/trunk/koffice/; revision=624955

model to use the KoShapeContainer.  Thats certainly not the case, the
default constructor will use a model that provides all the functionality
you want from a container.
Only when you want less features or special actions should you write your
own model.

svn path=/trunk/koffice/; revision=617454

rename KoGraphicsContainerModel to KoShapeContainerModel

svn path=/trunk/koffice/; revision=604799

have a resource provider, but we still check whether it's 0, and fix
a few spello's in the dox.

svn path=/trunk/koffice/; revision=602092

- Use consistently American English


svn path=/trunk/koffice/; revision=588325

Also rename some enum values to be CamelCase like the rest

svn path=/trunk/koffice/; revision=569625

svn path=/trunk/koffice/; revision=568304