1. 03 Oct, 2014 1 commit
  2. 06 Apr, 2013 1 commit
    • Halla Rempt's avatar
      Make all KDE includes consistent · 83da42dc
      Halla Rempt authored
      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
  3. 30 May, 2012 1 commit
  4. 08 Oct, 2011 1 commit
    • Halla Rempt's avatar
      Separate KoResourceManager for canvas and document · 0b2d5353
      Halla Rempt authored
      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.
  5. 01 Oct, 2011 1 commit
    • Halla Rempt's avatar
      rename KoShapeControllerBase to KoShapeBasedDocumentBase · 21ad769c
      Halla Rempt authored
      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..
  6. 21 May, 2011 1 commit
    • Halla Rempt's avatar
      Add convenience method to disconnect signals to a canvas · 98e7e20d
      Halla Rempt authored
      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.
  7. 13 Dec, 2010 1 commit
    • Halla Rempt's avatar
      Remove read-only canvas/tool flag · 6dd2f236
      Halla Rempt authored
      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
  8. 10 Sep, 2010 1 commit
  9. 15 Jul, 2010 1 commit
    • Thomas Zander's avatar
      Make ensureVisible aware of kword viewmodes · 63567a11
      Thomas Zander authored
      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()
      svn path=/trunk/koffice/; revision=1150162
  10. 07 May, 2010 1 commit
    • Thomas Zander's avatar
      Add concept of readonly/readwrite to KoTool. · f09c2166
      Thomas Zander authored
      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
      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
  11. 25 Feb, 2010 1 commit
  12. 23 Jan, 2010 2 commits
  13. 19 Dec, 2009 1 commit
  14. 23 Aug, 2009 1 commit
    • Thomas Zander's avatar
      SVN_SILENT · b96c4fa1
      Thomas Zander authored
      At least write *some* api docs.
      Whitespace cleanups too.
      svn path=/trunk/koffice/; revision=1014697
  15. 07 Apr, 2009 1 commit
  16. 28 Dec, 2008 1 commit
    • Thomas Zander's avatar
      Remove the concept of configuring antialiasing the painter. · 5964c73e
      Thomas Zander authored
      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
  17. 29 Sep, 2008 1 commit
  18. 24 Aug, 2008 1 commit
  19. 28 Jun, 2008 1 commit
    • Jan Hambrecht's avatar
      Implemneted dragging of guide lines from the rulers. · f8a25284
      Jan Hambrecht authored
      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
  20. 10 Feb, 2008 1 commit
  21. 28 Oct, 2007 2 commits
  22. 20 May, 2007 1 commit
  23. 26 Mar, 2007 1 commit
    • Thomas Zander's avatar
      API docs · e1b939f0
      Thomas Zander authored
      Alter one param in KoCanvasBase to const.
      svn path=/trunk/koffice/; revision=646709
  24. 19 Mar, 2007 1 commit
  25. 07 Mar, 2007 1 commit
  26. 03 Mar, 2007 1 commit
  27. 22 Feb, 2007 1 commit
    • Thomas Zander's avatar
      dpointer · 24eecb81
      Thomas Zander authored
      svn path=/trunk/koffice/; revision=636186
  28. 07 Jan, 2007 1 commit
  29. 29 Dec, 2006 1 commit
    • Peter Simonsson's avatar
      * Remove KoShapeAddRemoveData · a911ddd6
      Peter Simonsson authored
      * 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
  30. 24 Dec, 2006 1 commit
    • Thorsten Zachmann's avatar
      This is my christmas present :-) · b94fb59b
      Thorsten Zachmann authored
      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
      svn path=/trunk/koffice/; revision=616199
  31. 07 Dec, 2006 1 commit
  32. 23 Nov, 2006 1 commit
  33. 22 Nov, 2006 1 commit
    • Thorsten Zachmann's avatar
      This one is rather large commit. · 13d3c0cb
      Thorsten Zachmann authored
      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
  34. 21 Nov, 2006 1 commit
  35. 17 Nov, 2006 1 commit
  36. 14 Nov, 2006 1 commit
  37. 27 Mar, 2006 1 commit
  38. 02 Oct, 2005 1 commit