@ -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}.
exists a class \class{ConduitConfig} which is a subclass of \class{KDialog}.
This dialog does most of the basic work for you.
This dialog does most of the basic work for you.
\subsection{The dialog template, using QT Designer}
\subsection{The dialog template, using TQt Designer}
Of course, first we need to have a dialog template in the form of a QT
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
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:
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:
\includegraphics[width=14cm]{pictures/ProxyTab}
\includegraphics[width=14cm]{pictures/ProxyTab}
@ -437,7 +437,7 @@ The first two lines create an instance of our dialog template and add it
as the tab widget to the dialog. Since we will have to set and read the
as the tab widget to the dialog. Since we will have to set and read the
values of the controls in that tab widget, we need to store a pointer to
values of the controls in that tab widget, we need to store a pointer to
the instance in the variable \code{fConfigWidget} which is of the same type
the instance in the variable \code{fConfigWidget} which is of the same type
(\code{MALWidget}) we assigned to our dialog template in QT Designer. The
(\code{MALWidget}) we assigned to our dialog template in TQt Designer. The
third line of code adds the about page (which is created by the factory,
third line of code adds the about page (which is created by the factory,
see last section) to the tab widget, while the last two line just adjust
see last section) to the tab widget, while the last two line just adjust
the size of the dialog box and are not always needed.
the size of the dialog box and are not always needed.
@ -453,7 +453,7 @@ char*} variable of the conduit factory class), and then we can use the methods
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}
{\footnotesize\begin{verbatim}
/* virtual */ void MALWidgetSetup::readSettings()
/* virtual */ void MALWidgetSetup::readSettings()
@ -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"));
emit logMessage(i18n("My own log message"));
\end{verbatim}
\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
{\footnotesize
\begin{verbatim}
\begin{verbatim}
@ -1632,7 +1632,7 @@ This is also varpoware
> 5) How about responsiveness of the front end? I realized there are no
> 5) How about responsiveness of the front end? I realized there are no
> QTimer::singleShot to let qt process the queue between syncing two records.
> TQTimer::singleShot to let tqt process the queue between syncing two records.
> Or did I miss something?
> Or did I miss something?
currenlty this is true. While we aim for ASYNC the syncing is currently
currenlty this is true. While we aim for ASYNC the syncing is currently
