@ -371,8 +371,8 @@ To provide a consistent experience to KPilot users, there already
exists a class \class{ConduitConfig} which is a subclass of \class{KDialog}.
This dialog does most of the basic work for you.
\subsection{The dialog template, using QT Designer}
Of course, first we need to have a dialog template in the form of a QT
\subsection{The dialog template, using TQt Designer}
Of course, first we need to have a dialog template in the form of a TQt
Designer file (which has an extension .ui). Start up \file{designer} and
create a new widget (no dialogbox, i.e. no OK or cancel buttons, these will be added automatically). The dialogbox should contain a QTabWidget, even if you only need one tab. A second tab "About" will be added more or less automatically by the conduit listing the copyright and the authors of your conduit. A typical example of the coknduit setup widget dialog is shown in the following screenshot:
to retrieve the settings from the configuration file. We then use the methods of the QT and KDE widgets to assign the text or value to the controls:
to retrieve the settings from the configuration file. We then use the methods of the TQt and TDE widgets to assign the text or value to the controls:
{\footnotesize\begin{verbatim}
/* virtual */ void MALWidgetSetup::readSettings()
@ -584,7 +584,7 @@ All conduits are subclasses of \class{SyncAction}, which provides the following
environment will deal with \code{syncDone()}.
\item
\code{void addSyncLogEntry(const QString \&e,bool suppress=false)} ... Write a log entry to the pilot. Causes signal \code{logEntry(const char *)} to be emitted.
\code{void addSyncLogEntry(const TQString \&e,bool suppress=false)} ... Write a log entry to the pilot. Causes signal \code{logEntry(const char *)} to be emitted.
\item
\code{int pilotSocket()}\qquad ... returns the pilot socket (needed if you use your own functions to talk to the handheld. This is not recommended, but necessary in some cases)
\item
@ -596,9 +596,9 @@ In addition to these functions the class also has some signals you can emit to d
\begin{itemize}
\item\code{void syncDone(SyncAction *)} ... tell KPilot that the conduit has finished. Every conduit that returns true in its \code{exec()} method needs to emit this signal, otherwise KPilot will wait forever for the conduit to return.
\item\code{void logMessage(const QString \&)} ... Adds a message to KPilot's log, but not to the handheld's log.
\item\code{void logError(const QString \&)} ... Adds an error message to KPilot's log
\item\code{void logProgress(const QString \&,int)} ... Adds a log message and sets the progress bar to the given percentage.
\item\code{void logMessage(const TQString \&)} ... Adds a message to KPilot's log, but not to the handheld's log.
\item\code{void logError(const TQString \&)} ... Adds an error message to KPilot's log
\item\code{void logProgress(const TQString \&,int)} ... Adds a log message and sets the progress bar to the given percentage.
\end{itemize}
@ -611,9 +611,9 @@ In addition to \class{SyncAction}'s methods it adds the following methods:
\item\code{PilotLocalDatabase(const TQString \&name)} ... open database by name only
(no explicit path). The path \file{\$TDEHOME/share/apps/kpilot/DBBackup/PalmUserName/}
is set by KPilot automatically.
\end{itemize}
@ -945,7 +945,7 @@ Another issue is how to propagate log messages from the external library to KPil
emit logMessage(i18n("My own log message"));
\end{verbatim}
The problem with these slots is that they are Qt-specific, while most libraries are written in C, and expect a hook function that will be called whenever a message needs to be written out. Unfortunately you cannot pass a member of your SyncAction-derived class, either, so the way out is to store a pointer to the current conduit instance (only one will be active at any time, anyway) in a static variable, and call the member method from this pointer:
The problem with these slots is that they are TQt-specific, while most libraries are written in C, and expect a hook function that will be called whenever a message needs to be written out. Unfortunately you cannot pass a member of your SyncAction-derived class, either, so the way out is to store a pointer to the current conduit instance (only one will be active at any time, anyway) in a static variable, and call the member method from this pointer:
{\footnotesize
\begin{verbatim}
@ -976,7 +976,7 @@ int malconduit_logf(const char *format, ...) {
return rval;
}
void MALConduit::printLogMessage(QString msg) {
void MALConduit::printLogMessage(TQString msg) {
FUNCTIONSETUP;
emit logMessage(msg);
}
@ -1012,7 +1012,7 @@ The conduit has to find out
\item if a local copy is kept, if the local copy of a database has been changed or added (again using the modified flat of the records inside the database).
\end{itemize}
To assure a responsive user interface, we will once again use \texttt{QTimer::singleShot(this, 0, SLOT(whatever()));} for each of these steps.
To assure a responsive user interface, we will once again use \texttt{QTimer::singleShot(this, 0, TQ_SLOT(whatever()));} for each of these steps.
The \code{DOCConduit::exec()} function is just the entry point and calls syncNextDB, which will go through all PalmDOC databases on the handheld and determine if any of them has been changed:
@ -1022,7 +1022,7 @@ The \code{DOCConduit::exec()} function is just the entry point and calls syncNex
TDE Gitea
Michele Calgaro
Slávek Banko