summaryrefslogtreecommitdiffstats
path: root/koffice-i18n-nl/docs/koffice/chalk/developers-plugins.docbook
diff options
context:
space:
mode:
Diffstat (limited to 'koffice-i18n-nl/docs/koffice/chalk/developers-plugins.docbook')
-rw-r--r--koffice-i18n-nl/docs/koffice/chalk/developers-plugins.docbook16
1 files changed, 6 insertions, 10 deletions
diff --git a/koffice-i18n-nl/docs/koffice/chalk/developers-plugins.docbook b/koffice-i18n-nl/docs/koffice/chalk/developers-plugins.docbook
index b1780627..9411b6f2 100644
--- a/koffice-i18n-nl/docs/koffice/chalk/developers-plugins.docbook
+++ b/koffice-i18n-nl/docs/koffice/chalk/developers-plugins.docbook
@@ -42,11 +42,7 @@
>KisID</classname
>, that is the combination of a unique untranslated string (used when saving, for instance) and a translated string for GUI purposes. </para
><para
->A word on compatibility: &chalk; is still in development. From &chalk; 1.5 to 1.6 not many API changes are expected, but there may be some. From &chalk; 1.6 to 2.0 we will move from &Qt;3 to &Qt;4, from &kde;3 to &kde;4, from <command
->automake</command
-> to <command
->cmake</command
->: many changes are to be expected. If you develop a plugin for &chalk; and choose to do so in &chalk;’s subversion repository, chances are excellent that we’ll help you porting. These changes may also render parts of this document out of date. Always check with the latest API documentation or the header files installed on your system. </para>
+>A word on compatibility: &chalk; is still in development. From &chalk; 1.5 to 1.6 not many API changes are expected, but there may be some. If you develop a plugin for &chalk; and choose to do so in &chalk;’s subversion repository, chances are excellent that we’ll help you porting. These changes may also render parts of this document out of date. Always check with the latest API documentation or the header files installed on your system. </para>
<sect3 id="developers-plugins-introduction-chalkcolor">
<title
@@ -152,7 +148,7 @@
>Creating plugins</title>
<para
->Plugins are written in C++ and can use all of &kde; and &Qt; and the &chalk; developer API. Only viewplugins should use the &koffice; API. Don’t worry: &chalk;’s API’s are quite clear and rather extensively documented (for free software) and coding your first filter is really easy. </para
+>Plugins are written in C++ and can use all of &tde; and &TQt; and the &chalk; developer API. Only viewplugins should use the &koffice; API. Don’t worry: &chalk;’s API’s are quite clear and rather extensively documented (for free software) and coding your first filter is really easy. </para
><para
>If you do not want to use C++, you can write scripts in Python or Ruby; that is a different thing altogether, though, and you cannot currently write tools, colorspaces, paintops or import/export filters as scripts. </para
><para
@@ -788,7 +784,7 @@ public:
<itemizedlist>
<listitem
><para
->Use &Qt; Designer to create a widget base, and subclass it for your filter</para
+>Use &TQt; Designer to create a widget base, and subclass it for your filter</para
></listitem>
<listitem
><para
@@ -802,7 +798,7 @@ public:
></listitem>
<listitem
><para
->Hand-code a widget. This is not recommended, and if you do so and want your filter to become part of &chalk;’s official release, then I’ll ask you to replate your hand-coded widget with a &Qt; Designer widget.</para
+>Hand-code a widget. This is not recommended, and if you do so and want your filter to become part of &chalk;’s official release, then I’ll ask you to replate your hand-coded widget with a &TQt; Designer widget.</para
></listitem>
</itemizedlist>
@@ -907,7 +903,7 @@ std::list&lt;KisFilterConfiguration*&gt; KisOilPaintFilter::listOfExamplesConfig
>KisTool</classname
> for painting tasks (i.e., changing pixels) , non-painting tasks and shape painting tasks. </para
><para
->A tool has an option widget, just like filters. Currently, the option widgets are shown in a tab in a dock window. We may change that to a strip under the main menu (which then replaces the toolbar) for &chalk; 2.0, but for now, design your option widget to fit in a tab. As always, it’s best to use &Qt; Designer for the design of the option widget. </para
+>A tool has an option widget, just like filters. Currently, the option widgets are shown in a tab in a dock window. We may change that to a strip under the main menu (which then replaces the toolbar) for &chalk; 2.0, but for now, design your option widget to fit in a tab. As always, it’s best to use &TQt; Designer for the design of the option widget. </para
><para
>A good example of a tool is the star tool: </para>
@@ -962,7 +958,7 @@ chalktoolstar.desktop tool_star.cpp tool_star.png
>move</methodname
> and <methodname
>buttonRelease</methodname
->) are called by &chalk; when the input device (mouse, stylus, eraser etc.) is pressed down, moved or released. Note that you also get move events if the mouse button isn’t pressed. The events are not the regular &Qt; events, but synthetic &chalk; events because we make use of low-level trickery to get enough events to draw a smooth line. By default, toolkits like &Qt; (and GTK) drop events if they are too busy to handle them, and we want them all. </para>
+>) are called by &chalk; when the input device (mouse, stylus, eraser etc.) is pressed down, moved or released. Note that you also get move events if the mouse button isn’t pressed. The events are not the regular &TQt; events, but synthetic &chalk; events because we make use of low-level trickery to get enough events to draw a smooth line. By default, toolkits like &TQt; (and GTK) drop events if they are too busy to handle them, and we want them all. </para>
<programlisting
>void KisToolStar::buttonPress(KisButtonPressEvent *event)