diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/kommander/dcop.docbook | 20 | ||||
| -rw-r--r-- | doc/kommander/extending.docbook | 48 | ||||
| -rw-r--r-- | doc/kommander/parser.docbook | 6 | ||||
| -rw-r--r-- | doc/kommander/tutorials.docbook | 2 |
4 files changed, 38 insertions, 38 deletions
diff --git a/doc/kommander/dcop.docbook b/doc/kommander/dcop.docbook index 1fd7c170..e13db5e6 100644 --- a/doc/kommander/dcop.docbook +++ b/doc/kommander/dcop.docbook @@ -30,7 +30,7 @@ This assumes you are inside a &kommander; file and have access to the special @p &kommander; evolved the much faster internal &DCOP; function. Using it from another application window (console &DCOP; is very slow) is more complicated because you must give lots of information, including a prototype of the call. The above call would become: (Note that @dcopid is actually internal to the dialog, but you could replace it with a valid process ID) </para> <screen> -@dcop(@dcopid, KommanderIf, <quote>enableWidget(QString, bool)</quote>, Widget, true) +@dcop(@dcopid, KommanderIf, <quote>enableWidget(TQString, bool)</quote>, Widget, true) </screen> <para> In the early &kommander; nesting &DCOP; calls inside script language structures (like <application>bash</application>) used console method calls. <emphasis>If you use internal &DCOP; all &kommander; specials will be executed first and then the script will be executed.</emphasis> Please read that again as it will cause you no end of grief with a <application>bash</application> loop using &kommander; specials. @@ -49,7 +49,7 @@ As you can see the new syntax is very easy, as well as consistent visually with <title>&DCOP; for Global Variables</title> <variablelist> <varlistentry> -<term>global(QString variableName)</term> +<term>global(TQString variableName)</term> <listitem> <para> Returns the value of the specified global variable. When a script is run from within a &kommander; window any (non-global) variables set in that script will cease to exist after the script completes and therfore will not be available to other script processes or in a new instance of the calling process. The global <quote>scope</quote> means the variable will exist for any process of the window until that window is closed. You may change these variables at any time with a new call to <function>@setGlobal</function>. @@ -57,10 +57,10 @@ Returns the value of the specified global variable. When a script is run from w </listitem> </varlistentry> <varlistentry> -<term>setGlobal(QString variableName, QString value)</term> +<term>setGlobal(TQString variableName, TQString value)</term> <listitem> <para> -Creates a variable that is global to the window process and assigns the value to it. This value can be retrieved with global(QString variableName) or set again. +Creates a variable that is global to the window process and assigns the value to it. This value can be retrieved with global(TQString variableName) or set again. </para> </listitem> </varlistentry> @@ -75,7 +75,7 @@ The following list is old and left here for reference purposes only. For a compl </para> <variablelist> <varlistentry> -<term>setText(QString text)</term> +<term>setText(TQString text)</term> <listitem> <para> This removes the text displayed in the widget and replaces it with the text supplied. @@ -99,7 +99,7 @@ Returns the text associated with the specified widget. This is not the same as </listitem> </varlistentry> <varlistentry> -<term>setAssociatedText(QString text)</term> +<term>setAssociatedText(TQString text)</term> <listitem> <para> This sets the &kommander; Text default string. This is typically set to <quote>@widgetText</quote> to display what is entered into the widget. It is unlikely you will have much need for this, but if you do it is there. Applies to all widgets that can contain data. @@ -113,7 +113,7 @@ This sets the &kommander; Text default string. This is typically set to <quote> <title>&DCOP; for ListBox and ComboBox Widgets</title> <variablelist> <varlistentry> -<term>addListItem(QString item, int index)</term> +<term>addListItem(TQString item, int index)</term> <listitem> <para> Adds an item to a ListBox widget at the specified index. List index starts at zero. To add to the end of the list use -1. @@ -129,7 +129,7 @@ This adds a list of strings all at once. The list should be delimited by <acron </listitem> </varlistentry> <varlistentry> -<term>addUniqueItem(QString item)</term> +<term>addUniqueItem(TQString item)</term> <listitem> <para> addUniqueItem will add an item to the end of the list only if it is unique. @@ -175,7 +175,7 @@ Set the current (or selected) item to the index specified. Applies to ListBox a <title>&DCOP; for CheckBox and RadioButton Widgets</title> <variablelist> <varlistentry> -<term>setChecked(QString widgetName, bool checked)</term> +<term>setChecked(TQString widgetName, bool checked)</term> <listitem> <para> Checks/unchecks CheckBox or RadioButton widgets. @@ -189,7 +189,7 @@ Checks/unchecks CheckBox or RadioButton widgets. <title>&DCOP; for TabWidget Widgets</title> <variablelist> <varlistentry> -<term>setCurrentTab(QString widgetName, int index)</term> +<term>setCurrentTab(TQString widgetName, int index)</term> <listitem> <para> Selected the tab by index for TabWidgets. Index starts at 0. diff --git a/doc/kommander/extending.docbook b/doc/kommander/extending.docbook index 353390ca..8006bdef 100644 --- a/doc/kommander/extending.docbook +++ b/doc/kommander/extending.docbook @@ -63,31 +63,31 @@ class KomLineEdit : public KLineEdit, public KommanderWidget { TQ_OBJECT - TQ_PROPERTY(QString populationText READ populationText WRITE setPopulationText DESIGNABLE false) + TQ_PROPERTY(TQString populationText READ populationText WRITE setPopulationText DESIGNABLE false) TQ_PROPERTY(QStringList associations READ associatedText WRITE setAssociatedText DESIGNABLE false) TQ_PROPERTY(bool KommanderWidget READ isKommanderWidget) public: - KomLineEdit(QWidget *a_parent, const char *a_name); + KomLineEdit(TQWidget *a_parent, const char *a_name); ~KomLineEdit(); - virtual QString widgetText() const; + virtual TQString widgetText() const; virtual bool isKommanderWidget() const; virtual void setAssociatedText(const QStringList&); virtual QStringList associatedText() const; - virtual QString currentState() const; + virtual TQString currentState() const; - virtual QString populationText() const; - virtual void setPopulationText(const QString&); + virtual TQString populationText() const; + virtual void setPopulationText(const TQString&); public slots: - virtual void setWidgetText(const QString &); + virtual void setWidgetText(const TQString &); virtual void populate(); protected: void showEvent( QShowEvent *e ); signals: void widgetOpened(); - void widgetTextChanged(const QString &); + void widgetTextChanged(const TQString &); }; </screen> <para>Most of this is just template code that you don't need to worry about. @@ -99,7 +99,7 @@ widget we wish to integrate with &kommander;, and secondly from KommanderWidget. There are a few parts in the cpp file that are important to each particular widget. </para> <screen> -KomLineEdit::KomLineEdit(QWidget *a_parent, const char *a_name) +KomLineEdit::KomLineEdit(TQWidget *a_parent, const char *a_name) : KLineEdit(a_parent, a_name), KommanderWidget(this) { QStringList states; @@ -115,9 +115,9 @@ that had different kinds of states, such as a check box, you might set three states <emphasis>unchecked</emphasis>, <emphasis>semichecked</emphasis> and <emphasis>checked</emphasis> here. </para> <screen> -QString KomLineEdit::currentState() const +TQString KomLineEdit::currentState() const { - return QString("default"); + return TQString("default"); }</screen> <para>We set the states in the constructor above, and this just returns the current state of the widget. For our widget @@ -126,12 +126,12 @@ that checks what state your widget is currently in and return the appropriate string here. </para> <screen> -QString KomLineEdit::widgetText() const +TQString KomLineEdit::widgetText() const { return KLineEdit::text(); } -void KomLineEdit::setWidgetText(const QString &a_text) +void KomLineEdit::setWidgetText(const TQString &a_text) { KLineEdit::setText(a_text); emit widgetTextChanged(a_text); @@ -139,7 +139,7 @@ void KomLineEdit::setWidgetText(const QString &a_text) </screen> <para>These are the two most important methods, where the bulk of the functional code goes. -<emphasis>QString KomLineEdit::widgetText() const</emphasis> method returns the widget text of the +<emphasis>TQString KomLineEdit::widgetText() const</emphasis> method returns the widget text of the widget (the text that the <emphasis>@widgetText</emphasis> special is expanded to in text associations). For our widget, the widget text is simply the text inside the line edit, so we just return that. Similarly when setting the widget text, @@ -162,17 +162,17 @@ enum Functions { Function2, LastFunction }; -KomLineEdit::KomLineEdit(QWidget *a_parent, const char *a_name) +KomLineEdit::KomLineEdit(TQWidget *a_parent, const char *a_name) : KLineEdit(a_parent, a_name), KommanderWidget(this) { ... //code like described above KommanderPlugin::setDefaultGroup(Group::DCOP); - KommanderPlugin::registerFunction(Function1, "function1(QString widget, QString arg1, int arg2)", i18n("Call function1 with two arguments, second is optional."), 2, 3); - KommanderPlugin::registerFunction(function2, "function2(QString widget)", i18n("Get a QString as a result of function2."), 1); + KommanderPlugin::registerFunction(Function1, "function1(TQString widget, TQString arg1, int arg2)", i18n("Call function1 with two arguments, second is optional."), 2, 3); + KommanderPlugin::registerFunction(function2, "function2(TQString widget)", i18n("Get a TQString as a result of function2."), 1); } </screen> <para>This registers two functions: <emphasis>function1 and function2</emphasis>. The number assigned to the functions (here <emphasis>1160</emphasis> and <emphasis>1161</emphasis>) must be unique, not used in any other plugin or -inside &kommander;. <emphasis>function1</emphasis> takes two arguments, one is optional, <emphasis>function2</emphasis> takes no argument and returns a string. The <emphasis>QString widget</emphasis> argument in the signatures notes that this functions work on a widget, like: <emphasis>KomLineEdit.function1("foo", 1)</emphasis>. +inside &kommander;. <emphasis>function1</emphasis> takes two arguments, one is optional, <emphasis>function2</emphasis> takes no argument and returns a string. The <emphasis>TQString widget</emphasis> argument in the signatures notes that this functions work on a widget, like: <emphasis>KomLineEdit.function1("foo", 1)</emphasis>. </para> <para>To teach &kommander; that the widget supports these functions, add a method like this: </para> @@ -187,7 +187,7 @@ function. The function code should be handled inside the handleDCOP method: </para> <screen> -QString KomLineEdit::handleDCOP(int function, const QStringList& args) +TQString KomLineEdit::handleDCOP(int function, const QStringList& args) { switch (function) { @@ -203,7 +203,7 @@ QString KomLineEdit::handleDCOP(int function, const QStringList& args) default: return KommanderWidget::handleDCOP(function, args); } - return QString::null; + return TQString::null; } </screen> <para>There are cases when the widget should appear differently in the editor than in @@ -226,7 +226,7 @@ derive from QLabel, and use this in the constructor: functions, like in the <emphasis>execute</emphasis> function. Here is an example from the AboutDialog widget: </para> <screen> -QString AboutDialog::handleDCOP(int function, const QStringList& args) +TQString AboutDialog::handleDCOP(int function, const QStringList& args) { switch (function) { ... @@ -287,7 +287,7 @@ class MyKomPlugin : public KommanderPlugin { public: MyKomPlugin(); - virtual QWidget *create( const QString &className, QWidget *parent = 0, const char *name = 0 ); + virtual TQWidget *create( const TQString &className, TQWidget *parent = 0, const char *name = 0 ); }; </screen> <para> @@ -313,7 +313,7 @@ etc. Regarding the icon, the above example loads a medium sized icon called <emphasis>iconname</emphasis> from the standard &kde; icon location. </para> <screen> -QWidget *MyKomPlugin::create( const QString &className, QWidget *parent, const char *name ) +TQWidget *MyKomPlugin::create( const TQString &className, TQWidget *parent, const char *name ) { if( className == "KomLineEdit" ) return new KomLineEdit( parent, name ); @@ -410,7 +410,7 @@ You need to add to the <emphasis>editor/widgetfactory.cpp</emphasis> as well: ... #include "mywidget.h" ... -QWidget *WidgetFactory::createWidget( const QString &className, QWidget *parent, const char *name, bool init, +TQWidget *WidgetFactory::createWidget( const TQString &className, TQWidget *parent, const char *name, bool init, const QRect *r, Qt::Orientation orient ) { ... diff --git a/doc/kommander/parser.docbook b/doc/kommander/parser.docbook index a008c431..a8bec882 100644 --- a/doc/kommander/parser.docbook +++ b/doc/kommander/parser.docbook @@ -307,8 +307,8 @@ And now you access those with <emphasis>_xcount</emphasis> and <emphasis>_xquote </para> <para> DCOP can be complex, which is why we recommend using the tools we develop to enable creating DCOP for remote &kommander; dialogs with something like a function browser. Here is an example DCOP call issued from a dialog opened from a parent &kommander; window. Since it knows who its parent is it can send information back while it is open and freely access all its parent's functionality with the exception of slots. Of course that can be done internally with a script which can be called externally, so in practice there is no limit to what can be done. -<screen>dcop("kmdr-executor-"+parentPid, "KommanderIf", "setText(QString,QString)", "StatusBar8", "Hello")</screen> -Let's look at this piece by piece. First of all we add <emphasis>parentPid</emphasis> to "kmdr-executor-" as we make no assumption a &kommander; window was the caller. You could use this with Quanta or KSpread or whatever. Next we are addressing <emphasis>KommanderIf</emphasis>, which is a <emphasis>nice</emphasis> interface for end users which has been cleaned up. We hope eventually as KDE moves from DCOP to DBUS on KDE4 that more applications adopt a nice interface for integration. The next parameter, <emphasis>"setText(QString,QString)"</emphasis> is important because it <emphasis>prototypes</emphasis> the parameters allowed. Otherwise &kommander; could not validate the call. So without a definition of the DCOP call being used you will get an error. The remaining parameters are of course what is being passed. We recommend you look at applications with <command>kdcop</command> to see how this works and practice dcop calls from the shell to get your syntax right. +<screen>dcop("kmdr-executor-"+parentPid, "KommanderIf", "setText(TQString,TQString)", "StatusBar8", "Hello")</screen> +Let's look at this piece by piece. First of all we add <emphasis>parentPid</emphasis> to "kmdr-executor-" as we make no assumption a &kommander; window was the caller. You could use this with Quanta or KSpread or whatever. Next we are addressing <emphasis>KommanderIf</emphasis>, which is a <emphasis>nice</emphasis> interface for end users which has been cleaned up. We hope eventually as KDE moves from DCOP to DBUS on KDE4 that more applications adopt a nice interface for integration. The next parameter, <emphasis>"setText(TQString,TQString)"</emphasis> is important because it <emphasis>prototypes</emphasis> the parameters allowed. Otherwise &kommander; could not validate the call. So without a definition of the DCOP call being used you will get an error. The remaining parameters are of course what is being passed. We recommend you look at applications with <command>kdcop</command> to see how this works and practice dcop calls from the shell to get your syntax right. </para> </sect2> </sect1> @@ -557,7 +557,7 @@ file with given <emphasis>key</emphasis>; if there is no such value <emphasis>de for best control. </para></listitem> <listitem> -<para><command>connect(<parameter>sender</parameter>, <parameter>signal</parameter>, <parameter>receiver</parameter>, <parameter>slot</parameter>)</command> - connect a widget signal to a widget slot. See the connection dialog and select similar widgets for possibilities. If for instance a signal looks like looks like <command>execute(const QString&)</command> that is exactly what must be in quotes there. +<para><command>connect(<parameter>sender</parameter>, <parameter>signal</parameter>, <parameter>receiver</parameter>, <parameter>slot</parameter>)</command> - connect a widget signal to a widget slot. See the connection dialog and select similar widgets for possibilities. If for instance a signal looks like looks like <command>execute(const TQString&)</command> that is exactly what must be in quotes there. </para></listitem> <listitem> <para><command>disconnect(<parameter>sender</parameter>, <parameter>signal</parameter>, <parameter>receiver</parameter>, <parameter>slot</parameter>)</command> - undo the connection as listed above. Again, exact syntax is essential. diff --git a/doc/kommander/tutorials.docbook b/doc/kommander/tutorials.docbook index 6071c60c..a9ccafa8 100644 --- a/doc/kommander/tutorials.docbook +++ b/doc/kommander/tutorials.docbook @@ -83,7 +83,7 @@ One of the very useful features inherited from Qt Designer was signals and slots <para> To access the connection tool you can open it by right clicking anywhere on the dialog and selecting it. Click the menu and you will see a list of connections made at the bottom. Above that are two lists of signals and slots and above them the respective sender and receiver are selected. An easy way to make connections is visually. Look at the toolbar or the Tools menu. There are three items grouped there. A pointer, signals and slot connections and the tab order or widgets. Selecting this sets connection mode for the curios. Click on your widget to send the signal and drag it to your widget to receive it in a slot. As you do this you will see a line and drop indications on the widget under the mouse. The StatusBar on the Editor will tell you what is being connected. </para> -<note><para>In version 1.3 there is a &kommander; function connect() which allows you to connect signals and slots on the fly. This is useful if you just used createWidget. Obviously you can't use the dialog for something &kommander; doesn't yet know exists. Unfortunately there are too many combinations to list so you have to type out signals and slots. <emphasis>These must be typed verbatim or they will fail.</emphasis> This is where the connection tool is handy again. Open it and select two widgets like the two you want to connect and read the connection information. if it says <command>execute(const QString&)</command> that is exactly what you must type.</para></note> +<note><para>In version 1.3 there is a &kommander; function connect() which allows you to connect signals and slots on the fly. This is useful if you just used createWidget. Obviously you can't use the dialog for something &kommander; doesn't yet know exists. Unfortunately there are too many combinations to list so you have to type out signals and slots. <emphasis>These must be typed verbatim or they will fail.</emphasis> This is where the connection tool is handy again. Open it and select two widgets like the two you want to connect and read the connection information. if it says <command>execute(const TQString&)</command> that is exactly what you must type.</para></note> </sect2> <sect2 id="slot-functions"> |