GitLab

We used CamelCase and .h includes all mixed up. This patch chances all
includes to .h style.

I choose that style over CamelCase for the following reasons

* the change was easier to automate
* CamelCase include files are created manually and so have inconsistencies
* the majority of Calligra KDE includes were .h style

KoResourceManager was used in two places: the canvas and document
classes. This gave rise to endless confusion about which resource
manager should be used where and contains what. The KoResourceManager
api also contained methods that were only relevant when used from
a document and others that were only relevant when used from a canvas.

This patch splits the resourcemanager into two public and one private
class. The public classes are KoDocumentResourceManager and
KoCanvasResourceManager, the private class is KoResourceManager. The
public classes defer to the private class for code-sharing purposes.

The old KoCanvasResource and KoDocumentResource enums have been taken
into the classes themselves.

KoShapeControllerBase is _not_ (aha! got you!) the base class for
KoShapeController, instead it's an interface that document classes that
own shapes can implement to allow adding/removing shapes to their
internal shape data structure.

In other words, it's a base class for documents whose content is based
on shapes, in other words, a KoShapeBasedDocumentBase class...

Until 2006, it was called KoShapeControllerInterface, which made
sort of sense.

As discussed on irc:

15:29:42 < boud> I'm getting completely confused between KoShapeController and KoShapeControllerBase...
16:04:43 < sebsauer> boud: a good indicator that they are bad designed
16:10:03 < boud> yes, I totally agree
16:12:10 < svuorela> they need a AbstractKoShapeControllerBaseInterface to derive from
16:13:42 < boud> with one implemenation: SimpeKoShapeControllerBaseInterfaceImpl
16:14:14 < boud> I was browsing the git log, and it turns out that last summer I was hurting because of this design as well
16:15:53 < boud> actually, KoShapeControllerBase used to be called KoShapeControllerInterface, but that was renamed in 2006
16:17:19 < boud> jaham called it "Interface" -- and that still seems more accurate, since most methods are pure abstract. Thomas Zander renamed it.
16:24:49 < boud> I really wish I could get the shapecontroller right out of the canvasbase
16:27:18 < boemann> boud: to be far the renaming was idscussed on the ml and base is if it also implements base behaviour
16:27:22 < boemann> be fair
16:27:43 < sebsauer> lol re AbstractKoShapeControllerBaseInterface ... maybe turn it to a AbstractKoShapeControllerBaseInterfaceFactory ?
16:28:11 < sebsauer> or even a AbstractKoShapeControllerBaseInterfaceFactorySingleton
16:28:17 < boemann> sebsauer: no a factory cant return interfaces :)
16:28:27 < sebsauer> boemann: in C++ it can :-)
16:28:38 < sebsauer> interfaces without pure virtual
16:28:40 < sebsauer> 's
16:28:51 < boemann> ok it can but not accoring to our defs
16:29:22 < sebsauer> but yes, it's not nice and also misses a strategy-pattern
16:30:01 < boemann>  AbstractKoShapeControllerStrategyBaseInterfaceFactorySingleton
16:30:16 < sebsauer> sounds like a good name
16:30:30 < boemann> ok boud go ahead implementing our new design ;)
16:30:34 < sebsauer> :)
16:32:05 < svuorela> it's especially a good name for people who are paid by character ...
16:32:31 < boemann> :)
16:32:53 < boud> boemann: but this class doesn't implement the base behaviour for KoShapeController...
16:33:10 < boud> boemann: it's kind of an interface a document class implements so KoShapeController can add/remove shapes to the document
16:33:28 < boemann> oh
16:33:33 < boemann> nasty
16:33:43 < boud> the ***base renamings were last year, this was already in 2006
16:33:55 < boemann> ah
16:34:15 < boemann> i'd say we need to rename it
16:34:25 < boud> and every time, every time I look at these classes I am just as confused as you were just now -- surely KoShapeController must implement KoShapeControllerBase?
16:34:55 < boud> maybe KoShapeControllerDelegate?
16:35:21 < boemann> yeah
16:35:41 < boemann> if not a completely different name
16:36:25 < boud> it also creates a KoResourceManager and sets that on the shape factories for some reason... need to dig in again
16:36:34 < sebsauer> Ko42
16:37:20 < boud> lol
16:37:59 < svuorela> that's a great name. and then it can be subclassed to Ko43 when more virtuals are needed
16:38:26 < boud> how about KoShapeBasedDocumentBase...
16:38:53 < boemann> fine with me
16:39:05 < sebsauer> :-)
16:39:23 < boud> ok, will do
16:39:32 < svuorela> KoBasedShapeBasedDocumentBasedBase
16:39:32 < boud> I can't think of anything better
16:40:08 < boud> done..

This sort of hides the breaking of encapsulation, where canvas observers
would grab members of the canvas and connect to them whenever they get
a setCanvas call. This makes it easier to disconnect. But it's still bad
code, and I feel guilty.

Remove the needlessly complicated and basically unused API for making
tools add different actions for read/write and read-only contexts.

Discussed with Thorsten Zachmann

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

Also fix the inconsistentcy that ensureVisible on the KoCanvasController
was being handled in document units while everything else on the
controller is in pixels.
This was needed to avoid a triple conversion since kword viewmodes
already do a documentToView()

BUG:192883

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

In KParts we have both read only and read-write parts. Which is
mirrored from the document being read-only or not.
Introducing this concept into flake means we can use flake tools safely
on a read-only document without the user being able to change the read-only
document.

The new API will mean flake plugin writers have to specify read-only actions
in their call to KoToolBase::addAction().

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

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

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

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

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

At least write *some* api docs.
Whitespace cleanups too.

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

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

I'm not sure why it was added but we never actually change the default and
the configure read the config in KoCanvasBase which is an interface class
used in many unit tests that don't have a KConfig initialisation.

So, since this is unused and it crashes tests, lets remove it.

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

Somehow flake/ got left out.

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

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

When dragging outside of the ruler, the ruler emits
a signal guideLineCreated which when connected to the
KoCanvasControllers slot addGuideLine will temporary 
activate the KoGuidesTool. This tool then positions the
new guide line corresponding to the mouse movement.
When the mouse gets released, the guide line is added
to the guides data provided by the canvas.
To add support for guide lines to an application one
has to do the follwoing steps:
1. when creating your rulers, connect the guideLineCreated 
signal with the canvas controllers addGuideLine slot.
2. In the canvas implementation, reimplement the guidesData
function to provide access to the guides data of the
applications KoDocument implementation.
3. In the canvas implementation call KoGuidesData::paintGuides
to paint the guides.
4. Profit!!! :-)


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

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

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

- painter's antialiasing can be turned on [bool] "antialiasing" option in any flake-based application's rc file - we just need to honour KoCanvasBase::isAntialiased() flag.

An example fore kchart follows.

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

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

Alter one param in KoCanvasBase to const.

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

The former implementation stopped working due to the canvasController refactor.

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

call that.  But the actual code needs to be in the canvasController, so lets route
it through and make sure the call gets there.

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

the new situation. This will break every other KoCanvasBase implementation.
 Please look at http://wiki.koffice.org/index.php?title=Flake/Canvas
for the rationale behind this move and for porting tips. Krita's qpainter
canvas hasn't yet received the optimizations this move makes possible, but
those are easy now.

Also: a unittest for KoZoomHandler.

CCMAIL: koffice-devel@kde.org

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

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

so as not to inconvenience others)
* Fix spello

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

* Make KoPAPageBase a KoShapeContainer
* Fix drawing of child shapes in KoShapeContainer
* Make KoShapeLayer resize correctly depending on the children
* Fix adding and removing of child shapes in KoShapeManager
Plus everything I've forgotten ;)

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

This is the start for a common base lib(kopageapp) for kpresenter and kivio. 
It implements 9.1 Enhanced Page Features for Graphical Applications of the
odf specification. At the moment there is allready a common page class
which includes support for masterpages. Also it has a common canvas.
Additionaly there are common base classes for view and document so that
common stuff only needs to be implemented once.
At the moment the lib kopageapp still is in the kpresenter dir. It will
be move to libs when kivio also uses it.

o Added the possiblity to pass data to the creation of shapes. This
  makes it quite easy to find out the active page/layer which is
  otherwise not so easy as it is not part of the document but of the
  view.


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

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

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

o Split the shape creation as discussed at the flake meeting. 
  The KoCreateShapeTool creates new shapes out of the shape selector.
  The shapes are inserted into the document with the KoShapeContoller.
  The KoShapeContoller can be get from the canvas.
  
I have updated the applications to work with this change. 


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

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

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

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

cmake stored generated lib into "lib" directory)

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

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