From 0580616e20b68c764cdbbd9a01c9dd21f99766d4 Mon Sep 17 00:00:00 2001 From: Michele Calgaro Date: Mon, 25 Sep 2023 13:59:20 +0900 Subject: Replace QObject, QWidget, QImage, QPair, QRgb, QColor, QChar, QString, QIODevice with TQ* version Signed-off-by: Michele Calgaro --- doc/kommander/parser.docbook | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'doc/kommander/parser.docbook') 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 _xcount and _xquote 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. -dcop("kmdr-executor-"+parentPid, "KommanderIf", "setText(QString,QString)", "StatusBar8", "Hello") -Let's look at this piece by piece. First of all we add parentPid 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 KommanderIf, which is a nice 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, "setText(QString,QString)" is important because it prototypes 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 kdcop to see how this works and practice dcop calls from the shell to get your syntax right. +dcop("kmdr-executor-"+parentPid, "KommanderIf", "setText(TQString,TQString)", "StatusBar8", "Hello") +Let's look at this piece by piece. First of all we add parentPid 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 KommanderIf, which is a nice 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, "setText(TQString,TQString)" is important because it prototypes 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 kdcop to see how this works and practice dcop calls from the shell to get your syntax right. @@ -557,7 +557,7 @@ file with given key; if there is no such value de for best control. -connect(sender, signal, receiver, slot) - 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 execute(const QString&) that is exactly what must be in quotes there. +connect(sender, signal, receiver, slot) - 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 execute(const TQString&) that is exactly what must be in quotes there. disconnect(sender, signal, receiver, slot) - undo the connection as listed above. Again, exact syntax is essential. -- cgit v1.2.1