1. 17 Dec, 2008 1 commit
  2. 29 Sep, 2008 1 commit
  3. 05 Sep, 2008 1 commit
  4. 24 Aug, 2008 1 commit
  5. 06 Apr, 2008 1 commit
  6. 02 Sep, 2007 1 commit
    • Thomas Zander's avatar
      I realized the other day that our plugin versioning system is a bit weak; it... · 07fe64ae
      Thomas Zander authored
      I realized the other day that our plugin versioning system is a bit weak; it doesn't scale well beyond the simple usage of 1 codebase. So I thought lets fix that :)
      Specifically I made the following possible;
      * allowing users to download a plugin that a 3rd party made and just install it without things breaking.  This specifically means that if the user is running KOffice 2.2 and the plugin uses features in KOffice 2.3, we will not load the plugin.  But if the user is running KOffice 2.4 we will load it.
      The latter was impossible before.
      * The user can install a plugin in his homedir that supersedes the same plugin installed on the system.
      I want to allow a user to download a new version and get it loaded without silly things like suddenly seeing 2 versions in his apps.
      For this reason I made all registries (in the libs) use both a MinVersion and a PluginVersion variable.
      MinVersion basically is a 'minimum required application version for this plugin to run'.  So it won't be used if the plugin requires a higher number version of KOffice.
      PluginVersion means the version of the plugin.  If multiple are found, the highest number is used.
      The version I put as the current one is '0', so any plugin that should have a minimum version of 0. This may sound a bit weird as we normally start counting at 1, but I did this on purpose due to 2 reasons.
      1) it fits nicely with the KOffice minor version. So KOffice2.3 will have a minimum version of 3.
      2) we won't freeze the APIs until KOffice2.1, so the first real version that external plugin implementers will actually see is version 1.
      CCMAIL: koffice-devel@kde.org
      svn path=/trunk/koffice/; revision=707597
  7. 27 Aug, 2007 1 commit
  8. 14 Apr, 2007 1 commit
  9. 28 Feb, 2007 1 commit
  10. 08 Feb, 2007 1 commit
  11. 01 Jan, 2007 1 commit
    • Jan Hambrecht's avatar
      Fix loading of tools. Loading the tool plugins inside · df832a9b
      Jan Hambrecht authored
      the KoToolRegistry ctor does not work, as the static
      instance member is not initialized yet. So trying to 
      add the tool factories from the plugin ctor causes a 
      new registry instance to be created.
      svn path=/trunk/koffice/; revision=618603
  12. 16 Nov, 2006 1 commit
  13. 14 Nov, 2006 1 commit
    • Thomas Zander's avatar
      Finish migration to have one plugin loader for flake plugins. · e258d195
      Thomas Zander authored
      Each plugin will have a KService factory only one time and it can now
      choose from being a Shape-only plugin, a Tool-only plugin or to be
      a plugin of type "KOffice/Flake" which can contain both types.
      This solves the weirdness that if you had both a shape and a tool
      you had to choose one and do some magic in the constructor to have
      the other type known as well.
      svn path=/trunk/koffice/; revision=604907
  14. 13 Nov, 2006 1 commit
    • Boudewijn Rempt's avatar
      Create one single flake (and other stuff) plugin loader that · acf27c59
      Boudewijn Rempt authored
      doesn't use kparts and loades the current crop of flake plugins.
      This means we no longer sneakily add the tool plugin while the
      shape is loaded or vice versa. It's up to Jan to make the shapes
      into one plugin: I will go through the Krita tools and pigment
      colorspaces to de-kpart them.
      svn path=/trunk/koffice/; revision=604699
  15. 10 Nov, 2006 1 commit
  16. 30 Oct, 2006 1 commit
  17. 05 Sep, 2006 1 commit
  18. 17 Aug, 2006 1 commit
    • Jan Hambrecht's avatar
      Start of a path editing tool which does nothing for now · b48e0f86
      Jan Hambrecht authored
      but is already integrated into the tools framework.
      The path tool and the path shape are manually registered 
      in their corresponding registries so they do not need to
      be loaded dynamically.
      svn path=/trunk/koffice/; revision=574044
  19. 17 Jul, 2006 1 commit
  20. 16 Jun, 2006 1 commit
  21. 14 Jun, 2006 1 commit
  22. 07 Jun, 2006 1 commit
    • Thomas Zander's avatar
      Better debug; · e030dadd
      Thomas Zander authored
      David, what about moving that switch to a method on ComponentFactory ?
      svn path=/trunk/koffice/; revision=549032
  23. 06 Jun, 2006 1 commit