Development/Tutorials/KOffice Overview - Revision history

Thomas: /* Dockers */

2011-11-15T09:55:16Z

‎Dockers

Thomas at 09:54, 15 November 2011

2011-11-15T09:54:27Z

Atomopawn: Add link to the userbase docker install page.

2010-01-11T20:00:35Z

Add link to the userbase docker install page.

Cyrille at 18:57, 31 July 2009

2009-07-31T18:57:40Z

Zander: /* Inline Objects */

2009-03-18T10:56:15Z

‎Inline Objects

Zander: /* Inline Objects */

2009-03-18T10:14:42Z

‎Inline Objects

Zander: /* Text Editing */

2009-03-18T10:13:22Z

‎Text Editing

Zander: /* Considerations */ Wikify

2007-11-05T17:29:03Z

‎Considerations: Wikify

Dipesh: /* Dockers */

2007-11-05T17:17:11Z

‎Dockers

Tampakrap: /* Dockers */ Some tips provided by ThomasZ, found in the Krush Day

2007-11-03T21:33:12Z

‎Dockers: Some tips provided by ThomasZ, found in the Krush Day

@@ Line 47: / Line 47: @@
 API docs start at; [http://www.koffice.org/developer/apidocs/libs-flake/classKDockRegistry.html KDockRegistry]
-Within KOffice dockers could also be written in a scripting language like Python or Ruby. The [[Development/Tutorials/KSpread_Scripting#Scripting_Docker_Widgets|KSpread Scripting Docker]] tutorial shows how it was done within KCells.
+Within KOffice dockers could also be written in a scripting language like Python or Ruby. The [[Development/Tutorials/KSpread_Scripting#Scripting_Docker_Widgets|KCells Scripting Docker]] tutorial shows how it was done within KCells.
 === Considerations ===

@@ Line 14: / Line 14: @@
 To get a feel for what a shape is, here are some examples of existing shapes, sometimes referred to as Flake shapes because shapes are one of the two main parts of the Flake library.
-We have a PathShape which is a generic vector shape capable of showing and printing any sort of vector art like SVG or EPS vector graphics.
+We have a PathShape which is a generic vector shape capable of showing and printing any sort of vector art like SVG vector graphics.
 There is a Text plugin that is capable of showing marked up text with a huge feature set including HTML capabilities and a big part of the more extensive OpenDocument format.
-KSpread exports a tableShape, to allow a spread-sheet table to be embedded in other KOffice applications.
+KCells exports a tableShape, to allow a spread-sheet table to be embedded in other KOffice applications.
-API docs start at; [http://www.koffice.org/developer/apidocs/libs-flake/classKoShapeRegistry.html KoShapeRegistry]
+API docs start at; [http://www.koffice.org/developer/apidocs/libs-flake/classKShapeRegistry.html KShapeRegistry]
 The tutorial on how to write your own shape plugins can be found at [[Development/Tutorials/Write a Flake Plugin|Write a Flake Plugin]]
@@ Line 29: / Line 29: @@
 All user input mouse and keyboard events that are send to the document area (canvas), will be passed to the active tool.  The active tool can use them to, for example, move shapes around or rotate them. If you combine a tool with a shape plugin you can make the tool manipulate the data of the shape.  A good example is the text tool which is bundled with the text shape.  The text tool takes all keyboard events and thereby lets the user type text in the text shape.
-This gives a clear separation of control and content.  The shape holds the content and a tool is required to control that content.
+This gives a clear separation of control and content. The shape holds the content and a tool is required to control that content.
 In general there are two types of Tools;
@@ Line 35: / Line 35: @@
 * bundled tools that come with a specific flake shape and is made to manipulate that shapes data.
-API docs start at; [http://www.koffice.org/developer/apidocs/libs-flake/classKoToolRegistry.html KoToolRegistry]
+API docs start at; [http://www.koffice.org/developer/apidocs/libs-flake/classKToolRegistry.html KToolRegistry]
 The tutorial on how to write your own shape plugins can be found at [[Development/Tutorials/Write a Flake Plugin|Write a Flake Plugin]]
@@ Line 41: / Line 41: @@
 == Dockers ==
-Plugins that provide a docker are basically plugins that provide a graphical user interface element for KOffice applications.  In KOffice2 the focus on toolbars and dialogs will be less as they have been proven to be confusing to users because they clutter the interface.
+Plugins that provide a docker are basically plugins that provide a graphical user interface element for KOffice applications.  In KOffice the focus on toolbars and dialogs will be less as they have been proven to be confusing to users because they clutter the interface.
 Instead the focus is shifted to widgets that can be docked along the sides of a document window but also moved to be a separate window. The real change is that, unlike dialogs, they don't have an 'Ok' button but instead change the content life and immediately.
 Examples of dockers are; the toolbox, the shape selector and the tool-options but also the color selector.
-API docs start at; [http://www.koffice.org/developer/apidocs/libs-flake/classKoDockRegistry.html KoDockRegistry]
+API docs start at; [http://www.koffice.org/developer/apidocs/libs-flake/classKDockRegistry.html KDockRegistry]
-Within KOffice dockers could also be written in a scripting language like Python or Ruby. The [[Development/Tutorials/KSpread_Scripting#Scripting_Docker_Widgets|KSpread Scripting Docker]] tutorial shows how it was done within KSpread.
+Within KOffice dockers could also be written in a scripting language like Python or Ruby. The [[Development/Tutorials/KSpread_Scripting#Scripting_Docker_Widgets|KSpread Scripting Docker]] tutorial shows how it was done within KCells.
 === Considerations ===
@@ Line 54: / Line 54: @@
 The proper way to do this is to let the application tell you there is a new document or a new image, etc. And listen on that.
 This involves a couple of steps;
-* The application should use the KoCanvasResourceProvider to put content on. Like the current layer, the current document etc.
+* The application should use the KCanvasResourceProvider to put content on. Like the current layer, the current document etc.
-* The docker should (also) inherit from KoCanvasObserver which means it will get notified when its canvas changes.
+* The docker should (also) inherit from KCanvasObserver which means it will get notified when its canvas changes.
-* Using the KoCanvasBase received from the KoCanvasObserver it can fetch the document from the KoCanvasResourceProvider.  It can also connect to the provider to be informed about any changes.
+* Using the KCanvasBase received from the KCanvasObserver it can fetch the document from the KCanvasResourceProvider.  It can also connect to the provider to be informed about any changes.
-An extra tip is to use the KoCanvasResource::DocumentIsLoading boolean, dockers should listen to it to avoid doing work while the document is loading.
+An extra tip is to use the KCanvasResource::DocumentIsLoading boolean, dockers should listen to it to avoid doing work while the document is loading.
 == Colorspaces ==
@@ Line 75: / Line 75: @@
 An inline object does not have to have content, it can just be a placeholder as well. Which makes it ideal for things like in-text comments/annotations and Bookmarks.
-API docs start at; [http://www.koffice.org/developer/apidocs/libs-kotext/classKoInlineObjectRegistry.html KoInlineObjectRegistry]
+API docs start at; [http://www.koffice.org/developer/apidocs/libs-kotext/classKInlineObjectRegistry.html KInlineObjectRegistry]
 === Text Editing ===
@@ Line 84: / Line 84: @@
 Examples of usages of this plugin type are; a word count in a docker updated continuesly, auto correction of text, replacing formatted text with calculated values or custom shape plugins.
-API docs start at; [http://www.koffice.org/developer/apidocs/libs-kotext/classKoTextEditingRegistry.html KoTextEditingRegistry]
+API docs start at; [http://www.koffice.org/developer/apidocs/libs-kotext/classKTextEditingRegistry.html KTextEditingRegistry]
-−
-== Krita's plugins ==
-* filters (effects)
-* paintop (plugin that are in charge of painting when the user uses a drawing tool)
-* viewplugin (aka misc)
-See [http://docs.kde.org/development/en/koffice/krita/developers-plugins.html Krita's handbook]
 == Installing Plugins ==
 Userbase has a short guide [http://userbase.kde.org/KOffice/Building_Dockers] to installing custom/third-party plugins.

← Older revision		Revision as of 20:00, 11 January 2010
Line 91:		Line 91:
	* viewplugin (aka misc)		* viewplugin (aka misc)
	See [http://docs.kde.org/development/en/koffice/krita/developers-plugins.html Krita's handbook]		See [http://docs.kde.org/development/en/koffice/krita/developers-plugins.html Krita's handbook]
		+
		+	== Installing Plugins ==
		+
		+	Userbase has a short guide [http://userbase.kde.org/KOffice/Building_Dockers] to installing custom/third-party plugins.

@@ Line 45: / Line 45: @@
 Examples of dockers are; the toolbox, the shape selector and the tool-options but also the color selector.
-API docs start at; [http://www.koffice.org/developer/apidocs/libs/classKoDockRegistry.html KoDockRegistry]
+API docs start at; [http://www.koffice.org/developer/apidocs/libs-flake/classKoDockRegistry.html KoDockRegistry]
 Within KOffice dockers could also be written in a scripting language like Python or Ruby. The [[Development/Tutorials/KSpread_Scripting#Scripting_Docker_Widgets|KSpread Scripting Docker]] tutorial shows how it was done within KSpread.

@@ Line 75: / Line 75: @@
 An inline object does not have to have content, it can just be a placeholder as well. Which makes it ideal for things like in-text comments/annotations and Bookmarks.
-API docs start at; [http://www.koffice.org/developer/apidocs/libs-kotext/classKoVariableRegistry.html KoInlineObjectRegistry]
+API docs start at; [http://www.koffice.org/developer/apidocs/libs-kotext/classKoInlineObjectRegistry.html KoInlineObjectRegistry]
 === Text Editing ===

← Older revision		Revision as of 17:17, 5 November 2007
Line 46:		Line 46:

	API docs start at; [http://www.koffice.org/developer/apidocs/libs/classKoDockRegistry.html KoDockRegistry]		API docs start at; [http://www.koffice.org/developer/apidocs/libs/classKoDockRegistry.html KoDockRegistry]
		+
		+	Within KOffice dockers could also be written in a scripting language like Python or Ruby. The [[Development/Tutorials/KSpread_Scripting#Scripting_Docker_Widgets\|KSpread Scripting Docker]] tutorial shows how it was done within KSpread.

	=== Considerations ===		=== Considerations ===

← Older revision		Revision as of 21:33, 3 November 2007
Line 46:		Line 46:

	API docs start at; [http://www.koffice.org/developer/apidocs/libs/classKoDockRegistry.html KoDockRegistry]		API docs start at; [http://www.koffice.org/developer/apidocs/libs/classKoDockRegistry.html KoDockRegistry]
		+
		+	=== Considerations ===
		+	Dockers should never be passed a document or a view in the constructor.
		+	The reasons for that is simple; the lifetime of the docker is longer then
		+	the lifetime of the document and also of the view.
		+
		+	The proper way to do this is to let the application tell you there is a
		+	new document or a new image, etc. And listen on that.
		+	This involves a couple of steps.
		+	* The application should use the KoCanvasResourceProvider to put content
		+	on. Like the current layer, the current document etc.
		+	* The docker should (also) inherit from KoCanvasObserver which means it
		+	will get notified when its canvas changes.
		+	* Using the KoCanvasBase received from the KoCanvasObserver it can fetch
		+	the document from the KoCanvasResourceProvider. It can also connect to
		+	the provider to be informed about any changes.
		+
		+	An extra tip is to use the KoCanvasResource::DocumentIsLoading boolean.
		+	* Applications should set/unset the boolean in the resourceProvider (like KWord
		+	already does).
		+	* Dockers/etc should listen to it to avoid doing work while the document
		+	is loading.

	== Colorspaces ==		== Colorspaces ==