[kde-doc-english] [kmymoney] /: Remove the developer documentation since it is way outdated.
Cristian Oneț
onet.cristian at gmail.com
Fri Jun 17 20:54:15 UTC 2016
Git commit 0507ae7114d6c829fff83dda6bbcaf2952ad8040 by Cristian Oneț.
Committed on 17/06/2016 at 20:51.
Pushed by conet into branch 'master'.
Remove the developer documentation since it is way outdated.
We are going to maintain all the development related information on techbase.
M +0 -15 CMakeLists.txt
D +0 -1 developer-doc/CMakeLists.txt
D +0 -2 developer-doc/phb/CMakeLists.txt
D +0 -320 developer-doc/phb/cfg-mgmt.docbook
D +0 -413 developer-doc/phb/coding.docbook
D +0 -689 developer-doc/phb/cvs-examples.docbook
D +0 -130 developer-doc/phb/dialogs.docbook
D +0 -118 developer-doc/phb/documentation.docbook
D +0 -330 developer-doc/phb/error-mgmt.docbook
D +0 -356 developer-doc/phb/fdl-licence
D +0 -207 developer-doc/phb/index.docbook
D +0 -42 developer-doc/phb/kmymoney-developer.desktop
D +0 -21 developer-doc/phb/licence.docbook
D +0 -864 developer-doc/phb/rel-mgmt.docbook
D +0 -281 developer-doc/phb/rpm-example.docbook
D +0 -109 developer-doc/phb/settings.docbook
D +0 -550 developer-doc/phb/src-examples.docbook
D +0 -99 developer-doc/phb/submissions.docbook
D +0 -112 developer-doc/phb/test-examples.docbook
D +0 -248 developer-doc/phb/translation.docbook
D +0 -405 developer-doc/phb/unit-test.docbook
http://commits.kde.org/kmymoney/0507ae7114d6c829fff83dda6bbcaf2952ad8040
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 64a9d91..75780f9 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -239,9 +239,6 @@ option(USE_MODELTEST
option(USE_QT_DESIGNER
"Install KMyMoney specific widget library for Qt-Designer (default=OFF)" OFF)
-option(USE_DEVELOPER_
- "Install KMyMoney specific developer umentation (default=OFF)" OFF)
-
######################### The Actual Targets ##########################
add_subdirectory( libkgpgfile )
add_subdirectory( tools )
@@ -249,9 +246,6 @@ add_subdirectory( kmymoney )
if(KF5DocTools_FOUND)
add_subdirectory( doc )
endif()
-if (KF5DocTools_FOUND AND USE_DEVELOPER_DOC)
- add_subdirectory( developer-doc )
-endif()
######################### Output Results #############################
@@ -279,9 +273,7 @@ nice_yesno("LIBICAL_FOUND")
nice_yesno("ENABLE_SQLCIPHER")
nice_yesno("USE_QT_DESIGNER")
nice_yesno("USE_MODELTEST")
-nice_yesno("USE_DEVELOPER_DOC")
nice_yesno("DOXYGEN_FOUND")
-nice_yesno("USE_HTML_HANDBOOK")
message("
-------- KMyMoney ${PROJECT_VERSION}${PROJECT_VERSION_SUFFIX} --------
@@ -311,15 +303,8 @@ Qt-Designer library support: ${nice_USE_QT_DESIGNER}
Generate modeltest code: ${nice_USE_MODELTEST}
-Generate developer documentation: ${nice_USE_DEVELOPER_DOC}
-
Generate API documentation with Doxygen: ${nice_DOXYGEN_FOUND}")
-if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/doc")
- message("
-Generate HTML documentation: ${nice_USE_HTML_HANDBOOK}")
-endif()
-
message("
Build type: ${CMAKE_BUILD_TYPE}")
diff --git a/developer-doc/CMakeLists.txt b/developer-doc/CMakeLists.txt
deleted file mode 100644
index 600307a..0000000
--- a/developer-doc/CMakeLists.txt
+++ /dev/null
@@ -1 +0,0 @@
-add_subdirectory(phb)
diff --git a/developer-doc/phb/CMakeLists.txt b/developer-doc/phb/CMakeLists.txt
deleted file mode 100644
index e5532bf..0000000
--- a/developer-doc/phb/CMakeLists.txt
+++ /dev/null
@@ -1,2 +0,0 @@
-kdoctools_create_handbook(index.docbook INSTALL_DESTINATION ${HTML_INSTALL_DIR}/en SUBDIR kmymoney-developer)
-install(PROGRAMS kmymoney-developer.desktop DESTINATION ${XDG_APPS_INSTALL_DIR})
diff --git a/developer-doc/phb/cfg-mgmt.docbook b/developer-doc/phb/cfg-mgmt.docbook
deleted file mode 100644
index b392094..0000000
--- a/developer-doc/phb/cfg-mgmt.docbook
+++ /dev/null
@@ -1,320 +0,0 @@
-<chapter id="cfg-mgmt">
-<title>Configuration Management</title>
-<para>
-Whenever a project is developed in stages, it is very important for the
-people working on the project to know, which version of the project is used
-by the users and how it was built and what the components of this project
-are. This applies to hardware (e.g. automobiles) as well as software.
-Think of the times, when a car manufacturer calls certain cars to be
-repaired due to production problems. The manufacturer
-can track down the relevant cars because he is using a
-configuration management system and knows each car that contains e.g.
-faulty parts.
-</para>
-
-<para>
-The same applies to software development projects: whenever a version (stage of
-development) of the project is made
-public, it has to be given a distinct name or tag - usually the version number -
-and the development team must keep a snapshot of all components that made
-up that stage of the software project. This does not only include the
-source code of the project, but all libraries in their relevant stage as
-well as compilers and tools and all their installation/configuration
-information. If all this information is present, the software development
-team is capable to exactly reproduce each delivered version to search for
-problems occuring with this version. If this capability is not available,
-the development team has a hard time to find these problems.
-</para>
-
-<para>
-CVS helps us in our project to cover one aspect of configuration
-management: version control of the source code. It helps us to keep the
-snapshots of all the files the project team is responsible for in a
-central repository. Another aspect of CVS is concurrent development which
-allows us that some of us can develop
-new features of the project while others fix problems with previous
-versions even if both tasks modify the same source file. This feature is
-called branching. How branches will be organized in our project is
-explained in the chapter about
-<link linkend="version-mgmt">Version management</link>.
-</para>
-
-<para>
-The configuration management also regulates how the development team passes
-information among the members. This includes things like naming
-conventions, how errors are reported, rated and fixed and who is
-responsible for which task. The emphasis on this document though is the
-management of the version control system and how things are handled in this
-area. This does not mean, that the other important issues of configuration
-management are left outside. They are just not in the focus of this
-document.
-</para>
-
-<para>
-Throughout this document a few terms are used. In order to avoid confusion
-because these terms might be used differently in other documents, they are
-defined here.
-
-<table>
-<title>Definition of version control related terms</title>
-<tgroup cols="2">
-<thead>
-<row>
-<entry>Term</entry>
-<entry>Definition</entry>
-</row>
-</thead>
-
-<tbody>
-<row>
-<entry>Revision</entry>
-<entry>
-A <emphasis>revision</emphasis> is the stage of a single file in the
-repository. <emphasis>Revisions</emphasis> start with the value 1.1 upon
-the initial check-in and are incremented with each check-in of that file.
-After the third check-in, the <emphasis>revision</emphasis> of a file has
-the numeric value of 1.3.
-
-Once branches are made, <emphasis>revisions</emphasis> can have values like
-1.6.2.2. Since the <emphasis>revisions</emphasis> differ for all files,
-the revision number is only necessary for certain administrative tasks on
-single files (e.g.
-<link linkend="promoting-changes">merging data from another branch</link>).
-</entry>
-</row>
-
-<row>
-<entry>Tag, Label</entry>
-<entry>
-A <emphasis>tag</emphasis> is a string that represents a single revision of
-a file. Multiple tags can point to the same revision of a file.
-Sometimes, <emphasis>label</emphasis> is used as a synonym for tag.
-</entry>
-</row>
-
-<row>
-<entry>Version</entry>
-<entry>
-A <emphasis>version</emphasis> is the stage of the whole project in the
-repository. As already mentioned, the revisions for the files contained in
-the project differ from each other for a specific
-<emphasis>version</emphasis>. Therefor, each revision contained in a
-<emphasis>version</emphasis> receives the same tag.
-This tag can be used
-to checkout an exact copy of the version of the project.
-</entry>
-</row>
-
-<row>
-<entry>Repository</entry>
-<entry>
-The repository is the central database containing all revisions of all
-files of the &app; project. It is located on the SourceForge.net and can
-be accessed via &cvs;.
-</entry>
-</row>
-
-<row>
-<entry>Sandbox</entry>
-<entry>
-The sandbox is the local work area for the developer. Initially, a sandbox
-is filled by checking out a specific stage of the repository. Changes made
-to the sandbox are moved to the repository by the checkin process. Changes
-made by other developers are transferred to one's own sandbox by the update
-process.
-
-A developer can maintain different sandboxes of the same project in
-different directories on the same machine. This requires thorough attention
-of the developer which sandbox he is modifying. Using several sandboxes is
-usually meaningful if a developer works on changes on a release branch
-(stable release) and on the main-branch (development release) at the same
-time. See <link linkend="multiple-branches">the appendix</link> for an
-example.
-</entry>
-</row>
-
-</tbody>
-</tgroup>
-</table>
-</para>
-<!-- SECTION =================================================== -->
-<sect1 id="vc-tool">
-<title>Version Control Tool</title>
-<para>
-Since the &app; project is hosted on the <ulink
-url="http://www.sourceforge.net/">SourceForge</ulink> platform, <ulink
-url="http://www.cvshome.org">CVS</ulink> is used as the version control
-tool. &cvs; is widely accepted as version control tool in the open source
-community and covers our needs pretty well.
-</para>
-<para>
-The &app; project's central repository is handled on the
-SourceForge platform. Developers do not edit files directly in the
-repository, but rather checkout a working copy into their local
-sandbox. This local sandbox can then be modified without the necessity of
-a direct link to the central repository.
-Once the developer is confident with the changes made, he checks the files
-back into repository.
-</para>
-
-<para>
-During the checkin process, &cvs; keeps track of all the changes made. This
-allows to review a complete history of all modifications ever made to the
-project.
-As mentioned above, it is very important in certain circumstances to have
-such a history.
-</para>
-</sect1>
-
-<!-- SECTION =================================================== -->
-
-<sect1 id="repo-access">
-<title>Access to the repository</title>
-<para>
-Access to the repository is available in two different forms
-<itemizedlist>
-<listitem><para>Read-Only access</para></listitem>
-<listitem><para>Read-Write access</para></listitem>
-</itemizedlist>
-</para>
-
-<sect2>
-<title>Read-Only access</title>
-<para>
-Read-Only access is granted to anybody anonymously to the repository. For
-this type of access you do not need a user account on the SourceForge
-platform. Access is made through the <emphasis>pserver</emphasis>-protocol
-of &cvs;: See <ulink
-url="http://sourceforge.net/">the description on SourceForge</ulink> for more details.
-</para>
-</sect2>
-
-<sect2>
-<title>Read-Write access</title>
-<para>
-In order to get read-write access to the repository, two things are
-necessary. First you need a user account on the SourceForge platform.
-Second you need to qualifiy as a developer with the &app; project
-administrator(s). Once they have added you to the list of developers, you
-can access the repository through an <emphasis>SSH</emphasis> encrypted
-tunnel.
-
-See <ulink
-url="http://sourceforge.net/">the description on SourceForge</ulink> for more details.
-
-</para>
-</sect2>
-</sect1>
-
-<sect1 id="version-controlled-files">
-<title>Version controlled files</title>
-<para>
-This chapter explains which files have to be version controlled. It also
-explains how to configure &cvs; to skip certain files that are generated by
-the compile/build process but should not be stored in the repository.
-</para>
-
-<sect2>
-<title>Files that must be stored in the repository</title>
-<para>
-All files that form an application (e.g. source code, header files, icons,
-documentation, etc.) that are necessary to compile, build and run the
-application <command>must</command> be checked into the central repository.
-</para>
-
-<caution>
-<para>
-Before you add a file to the repository you must check it's format. If it's
-a binary format the special option <command>-kb</command> must be appended
-to the <command>cvs add</command> in order to inform the central repository
-to leave the file as it is
-</para>
-</caution>
-</sect2>
-
-<sect2>
-<title>Files that should not be stored in the repository</title>
-
-<para>
-All files that are automatically generated by the build process (e.g.
-object files, libraries, executables, Makefiles, etc.) should not be checked
-into the repository because they can easily be reconstructed by the
-developer. In very rare circumstances it might be necessary to checkin an
-automatically generated file. This is always an exception.
-
-<note>
-<para>
-I mentioned Makefiles above because I assume that ∾ and &am; are used.
-Using ∾ and &am; supplies the project with a
-<command>configure</command> script that creates the Makefiles. The
-necessary input files are called <command>Makefile.am</command> that must
-be checked into the repository as source to the Makefiles.
-</para>
-<para>
-If you do not use ∾ and &am; and write your Makefiles directly, they
-have to be checked in as they are not automatically generated. Nevertheless,
-using non &am; generated Makefiles should be avoided.
-</para>
-</note>
-</para>
-</sect2>
-</sect1>
-
-
-<sect1 id="version-mgmt">
-<title>Version management</title>
-<para>
-At certain times to be defined by the project's administrators (actually
-configuration manager) a snapshot is taken from the repository. In order to
-fix the stage of this snapshot in the repository, a
-<emphasis>tag</emphasis> is placed on this stage. Tagging the repository
-creates a version of the project.
-</para>
-
-<sect2>
-<title>Layout of the version numbers</title>
-<para>
-The version number is made out of three numeric fields. These are:
-
-<orderedlist>
-<listitem><para>The major release number</para></listitem>
-<listitem><para>The minor release number</para></listitem>
-<listitem><para>The micro release number</para></listitem>
-</orderedlist>
-
-In order to serve as a tag for &cvs;, the text <command>rel-</command> is
-prepended to the version numbers and the three fields are seperated with a
-dash (e.g. rel-0-3-7).
-</para>
-
-<para>
-The major release number will be changed when all the proposed features
-mentioned in the release plan (available on the
-<ulink url="http://kmymoney.org/">project web-site</ulink>)
-are designedi, coded and tested.
-</para>
-
-<para>
-One of the objectives of the minor release number is to differentiate
-between stable and unstable versions of the project. As a widely accepted
-procedure, odd numbers are used for development versions, even numbers
-identify stable versions. Whenever the configuration manager decides that
-to create a new stable release, this will also bump the version number of
-the unstable release by two.
-</para>
-
-<para>
-The micro release number is reset to 0 when the minor release number is
-incremented and then incremented with each version following until the
-minor release number is modified again. Versions tagged between the
-creation of a stable branch and the actual release -0 of this branch will
-be identified by a micro release number of
-<emphasis>pre<subscript>n</subscript></emphasis>, where
-<emphasis>n</emphasis> is incremented each time a version is tagged.
-</para>
-
-</sect2>
-
-</sect1>
-
-</chapter>
diff --git a/developer-doc/phb/coding.docbook b/developer-doc/phb/coding.docbook
deleted file mode 100644
index 75c71c8..0000000
--- a/developer-doc/phb/coding.docbook
+++ /dev/null
@@ -1,413 +0,0 @@
-<chapter id="coding-std">
-<title>Coding Rules</title>
-<para>
-Where-ever possible this document should be referred to when questions
- regarding the format of the source code are raised.
-</para>
-
-<para>
-By the way, we know the code doesn't always conform to the standards at
-the moment, but work is underway to change the code and all new code
-submitted should conform to the standards.
-</para>
-
-<!-- SECTION =================================================== -->
-<sect1 id="general">
-<title>General</title>
-<para>
-The following list shows the general rules that should be regarded by any
-developer working on &app;.
-</para>
-
-<itemizedlist>
-<listitem>
-<para>
-Each file should contain only one declaration or implementation and the
-filename should reflect the class name. e.g ksomethingdlg.h would contain a
-declaration for the KSomethingDlg class.
-</para>
-</listitem>
-
-<listitem>
-<para>
-A tab width of 2 spaces should be used and if your editor supports it, the
-tabs should be changed into spaces. (KDevelop/KWrite supports tab
-translation).
-</para>
-</listitem>
-
-<listitem>
-<para>
-All dialogs should be located in the kmymoney/dialogs directory.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Each class should be as self contained as possible. If for instance, you
-are creating a dialog, then all the signals and slots should be connected
-within that dialog class. Where access is needed to the class details
-methods should be used. This enhances readability and makes maintenance a
-lot easier with each object having it's own state, indentity and behaviour,
-(see Object Oriented Analysis & Design using UML, Bennet & Co).
-</para>
-</listitem>
-
-<listitem>
-<para>
-All user visible text should be wrapped in the i18n internationalisation
-wrapper for translation.
-</para>
-</listitem>
-</itemizedlist>
-
-</sect1>
-
-
-<!-- SECTION =================================================== -->
-<sect1 id="header-files">
-<title>Header Files</title>
-<para>
-The following rules apply to all header files.
-</para>
-
-<itemizedlist>
-<listitem>
-<para>
-Header files shall end with the extension .h not .hpp.
-</para>
-</listitem>
-
-<listitem>
-<para>
-All header files shall begin with a comment block as generated by KDevelop.
-</para>
-</listitem>
-
-<listitem>
-<para>
-The remainder of the header file shall be surrounded by include stoppers.
-The name of the macro used should be the capitalized filename with the dot
-replaced by an underbar (e.g. KSettingsDlg.h --\> KSETTINGSDLG_H)
-<example>
-<title>Using include stoppers</title>
-<screen>
-
- #ifndef KSETTINGSDLG_H
- #define KSETTINGSDLG_H
- /* remainder of header file */
- #endif // KSETTINGSDLG_H
-
-
-</screen>
-</example>
-
-</para>
-</listitem>
-
-<listitem>
-<para>
-All classes designed for use by the KDE interface should begin with a
-<emphasis>K</emphasis>
-with each separate word beginning with an uppercase letter e.g
-KSomethingDlg.
-</para>
-</listitem>
-
-<listitem>
-<para>
-The header file will include other header files in the following fashion
-and same order:
-</para>
-
-<example>
-<title>Including other header files</title>
-<screen>
-
- //-----------------------------------------------------------------------
- // QT Headers
- #include <qtlabel.h>
-
- //-----------------------------------------------------------------------
- // KDE Headers
- #include <kcombobox.h>
-
- //-----------------------------------------------------------------------
- // Project Headers
- #include "mymoney/mymoneyfile.h"
-
-
-</screen>
-</example>
-</listitem>
-
-<listitem>
-<para>
-Each class should have a kdoc compatable comment header to describe the
-class and it's function within kmymoney.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Classes shall begin their declaration as such:
-</para>
-
-<example>
-<title>Class declaration</title>
-<screen>
-
- class KSomethingDlg : public KBaseClass {
-
-
-</screen>
-</example>
-
-<para>
-with an appopriate access declared.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Access modifiers should be left flushed in the class declaration with all
-attributes and methods indented by one tab. The access methods will be in
-order starting with private. The access identifier should exist even if no
-attributes or methods exist. Only one identifier can exist of the same
-type.
-</para>
-
-<example>
-<title>Complete class declaration</title>
-<screen>
-
- class KSomethingDlg : public KBaseClass {
- private:
- QString m_szSomeString;
- void useString(void);
-
- private slots:
-
- protected:
-
- protected slots:
-
- public:
- KSomethingDlg();
-
- public slots:
-
- signals:
- };
-
-
-</screen>
-</example>
-</listitem>
-
-<listitem>
-<para>
-All slot methods should begin with slot and signal methods should start with
-signal. e.g
-</para>
-
-<example>
-<title>Declaration of slot and signal methods</title>
-<screen>
-
- signalFoundTransaction();
- slotFoundTransaction();
-
-
-</screen>
-</example>
-</listitem>
-
-<listitem>
-<para>
-<anchor id="attribute-names"/>
-Attribute names should begin with the m_ prefix to indicate that they are
-member variables. The variable name should begin with a descriptive
-identifier such as qcomboboxMethod. Explicit hungarian notation is also
-fine. Examples of valid variable names can be found below:
-</para>
-
-<example>
-<title>Attribute naming convention</title>
-<screen>
-
- QComboBox m_qcomboboxMethod;
- int m_intCounter;
- int m_nCounter;
-
-
-</screen>
-</example>
-</listitem>
-
-<listitem>
-<para>
-Method names should specify a return and argument(s) unless used in a slot
-or signal where the argument list can be left blank if necessary. The
-method should start with a lower case letter with each subsequent word
-having an upper case start letter.
-</para>
-</listitem>
-</itemizedlist>
-
-</sect1>
-
-<!-- SECTION =================================================== -->
-<sect1 id="source-files">
-<title>Source Files</title>
-<para>
-The following rules apply to all source code files.
-</para>
-
-<itemizedlist>
-<listitem>
-<para>
-C++ source files shall end with the extension .cpp not .cc or .cxx
-</para>
-</listitem>
-
-<listitem>
-<para>
-As with header files these should start with a header block similar to the
-one generated by KDevelop.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Include files shall be included in the same format as for header file e.g
-</para>
-
-<example>
-<title>Including header files in source files</title>
-<screen>
- //-----------------------------------------------------------------------
- // QT Headers
- #include <qtlabel.h>
-
- //-----------------------------------------------------------------------
- // KDE Headers
- #include <kcombobox.h>
-
- //-----------------------------------------------------------------------
- // Project Headers
- #include "mymoney/mymoneyfile.h"
- #include "ksomethingdlg.h"
-
-
-</screen>
-</example>
-</listitem>
-
-<listitem>
-<para>
-Methods should be implemented as such:
-</para>
-
-<example>
-<title>Method implementation</title>
-<screen>
-
- void KSomethingDlg::useString(void)
- {
- .. function body
- }
-
-
-</screen>
-</example>
-
-<para>
-with the function body indented by one tab (equals two spaces).
-</para>
-</listitem>
-
-<listitem>
-<para>
-Flow control statements should preferably follow the Kernighan & Ritchie
-style as such:
-</para>
-
-<example>
-<title>Kernighan & Ritchie flow control style</title>
-<screen>
-
- while (something_is_true) {
- operate on something;
- }
-
-
-</screen>
-</example>
-
-<para>
-although the following Allman style is acceptable:
-</para>
-
-<example>
-<title>Allman flow control style</title>
-<screen>
-
- while (something_is_true)
- {
- operate on something;
- }
-
-
-</screen>
-</example>
-
-<para>
-It is also acceptable for one line body statements to omit the curly braces
-as such:
-</para>
-
-<example>
-<title>One line body flow control style</title>
-<screen>
-
- while (something_is_true)
- operate;
-
-
-</screen>
-</example>
-</listitem>
-
-<listitem>
-<para>
-Local variables should not be prefixed by the m_ member prefix and should
-start with a prefix as discussed for the
-<link linkend="attribute-names">header file</link>.
-For example:
-</para>
-
-<example>
-<title>Local variable nameing convention</title>
-<screen>
-
- QString qstringTemp;
- char *pszTemp;
-
-
-</screen>
-</example>
-</listitem>
-
-<listitem>
-<para>
-Each method should have a comment block preceeding it in a suitable format
-for other developers to see how the method works and what types of return
-and arguments it expects. It does not have to be kdoc compatable because
-kdoc only parses the header files. All kdoc comment blocks should be in the
-header files.
-</para>
-</listitem>
-</itemizedlist>
-</sect1>
-</chapter>
diff --git a/developer-doc/phb/cvs-examples.docbook b/developer-doc/phb/cvs-examples.docbook
deleted file mode 100644
index dc52aec..0000000
--- a/developer-doc/phb/cvs-examples.docbook
+++ /dev/null
@@ -1,689 +0,0 @@
-<appendix id="cvs-examples">
-<title>CVS examples</title>
-<para>
-It is not the intention of this document to give a complete introduction to
-&cvs;. Nevertheless, a few examples should give a quick overview on the basic
-operations to be performed by the developer.
-</para>
-
-<para>
-It is assumed, that the developer is registered with the &app; project and
-has read/write access to the repository. Also, it is assumed, that the
-necessary environment variables are setup, so that &cvs; knows how to access
-the repository. Details about the settings can be found on the <ulink
-url="http://www.sourceforge.net/">SourceForge.net</ulink> web-site.
-</para>
-
-<para>
-Throughout the next sections, the examples given use the &cvs; command line
-interface. The options are abbreviated. The operations described here are also
-accessible through various GUI clients available for &cvs;. Also, I usually
-use the -q (quiet) option to suppress some messages issued by &cvs;. If you
-omit the -q option, the output differs from the one shown here, even though
-the result of the operation is the same.
-</para>
-
-<section id="cvs-checkout">
-<title>Checking out from the repository</title>
-<para>
-The very first operation is to fill the sandbox. This is done using the
-<command>checkout</command> operation. The first time the repository is
-checked-out, it's location must be specified. This is done using the
-<command>-d</command> option. In the example below,
-you must replace <emphasis>username</emphasis> with your real username at
-SourcForge.net.
-
-</para>
-
-<example>
-<title>Filling the sandbox for the first time</title>
-<screen>
-
- <prompt>thb:~> </prompt><userinput>cvs -d &cvs-user;@&cvs-host;:&cvs-dir; co &cvs-module;</userinput>
-
-
-</screen>
-<para>
-During the checkout process, &cvs; lists all filenames on the users screen
-and stores information about the repository's
-location and all the files checked out in the sandbox. Therefor, you do not
-need to specify the repository location during following &cvs; operations
-anymore.
-</para>
-
-<para>
-For the &app; project, a directory named <command>kmymoney</command> is
-created in your current working directory.
-</para>
-</example>
-
-<para>
-The above example fills the sandbox with the HEAD revision of all files.
-This stage is sometimes referred to as the <quote>latest-and-greatest</quote>
-and is the latest development stage.
-</para>
-
-<note>
-<para>
-If you plan to keep two or more branches of the project on your machine,
-please see the chapter <emphasis>
-<link linkend="multiple-branches">Keeping different
-branches on the same machine</link></emphasis> for details.
-</para>
-</note>
-
-<para>
-If for some reason, you need to checkout a version of the project that is
-different from the development stage (e.g. you want to fix a bug in a
-stable version), you can fill an empty sandbox by supplying the version-tag
-as parameter to the checkout command.
-</para>
-
-<example>
-<title>Filling the sandbox for the first time with a specific version</title>
-<screen>
-
- <prompt>thb:~> </prompt><userinput>cvs -d &cvs-user;@&cvs-host;:&cvs-dir; co -r version-tag &cvs-module;</userinput>
-
-
-</screen>
-<para>
-This will store the version labelled with the tag
-<emphasis>version-tag</emphasis> in your sandbox. In case
-<emphasis>version-tag</emphasis> is a branch-tag, you are able to modify
-the files and check-in changes later on. In case,
-<emphasis>version-tag</emphasis> is a standard tag, checkin operations will
-be rejected by &cvs;.
-</para>
-
-<para>
-As in the previous example, the directory kmymoney is created as the
-sandbox.
-</para>
-</example>
-</section>
-
-<section id="cvs-checkin">
-<title>Checking in to the repository</title>
-<para>
-Once the sandbox is filled, changes to the project will be
-applied by the developer. As soon as the developer is confident with the
-changes, he is about to promote these changes to the other developers. He
-does that by checking the changes back into the repository.
-</para>
-
-<para>
-Checking changes back into the repository should start by performing an
-update procedure as described in <link linkend="cvs-update">the next
-section</link>. This may seem strange, but updateing your sandbox will
-transfer changes performed by other developers in the meantime to your
-sandbox. It is good practice to re-compile the project if you notice that
-updateing the sandbox changes it's contents. This assures that the project
-is still compilable when you check-in your changes.
-</para>
-
-<para>
-The next step is to identify the changes you really want to promote. This
-can be performed by the <command>diff</command> operation supported by
-&cvs;.
-</para>
-
-<example>
-<title>Promote changes to the repository</title>
-<para>
-For the following example, I assume a single file that has been changed in
-the sandbox (~/kmymoney/kmymoney/knewbankdlg.cpp) and that the current
-directory is ~/kmymoney/kmymoney. Also, it is assumed, that the file
-README has been updated by another person in the repository. Since the
-README file has no influence on the compile process, we omit recompiling in
-this example.
-</para>
-
-<para>
-The part of the original file that has been changed is shown here to
-understand the output of the <userinput>cvs diff</userinput>
-command shown below. The beginning of
-the file is not included here as it is not changed.
-</para>
-
-<programlisting role="C++">
-
-void KNewBankDlg::okClicked()
-{
- if (nameEdit->text().isEmpty()) {
- KMessageBox::information(this, i18n("The institution name field is empty. Please enter the name."), i18n("Adding New Institution"));
- nameEdit->setFocus();
- return;
- }
-
- m_name = nameEdit->text();
- m_city = cityEdit->text();
- m_street = streetEdit->text();
- m_postcode = postcodeEdit->text();
- m_telephone = telephoneEdit->text();
- m_managerName = managerEdit->text();
- m_sortCode = sortCodeEdit->text();
- accept();
-}
-
-
-</programlisting>
-
-<para>
-The changed version of the method is included here.
-</para>
-
-<screen>
-
-void KNewBankDlg::okClicked()
-{
- if (nameEdit->text().isEmpty()) {
- KMessageBox::information(this, i18n("The institution name field is empty. Please enter the name."), i18n("Adding New Institution"));
- nameEdit->setFocus();
-
- } else {
- m_name = nameEdit->text();
- m_city = cityEdit->text();
- m_street = streetEdit->text();
- m_postcode = postcodeEdit->text();
- m_telephone = telephoneEdit->text();
- m_managerName = managerEdit->text();
- m_sortCode = sortCodeEdit->text();
- accept();
- }
-}
-
-
-</screen>
-
-<para>
-Now as the file has been changed, the changes should be promoted to the
-repository. As explained above, the process starts with checking for
-changes made by other people.
-</para>
-
-<screen>
-
- <prompt>thb:~> </prompt><userinput>cvs -q upd</userinput>
- U README
- M knewbankdlg.cpp
- <prompt>thb:~> </prompt>
-
-
-</screen>
-
-<para>
-The above shown output has the following meaning:
-the file <command>README</command> is udpated (U) from the repository
-to the sandbox because
-it has been changed by someone else in the meantime. The contents of the file
-in the sandbox will be replaced by the contents of the file in the
-repository, because it has not been altered in the sandbox.
-The file <command>knewbankdlg.cpp</command> has been modified (M) in the
-sandbox and needs to be returned to the repository.
-</para>
-
-<para>
-<anchor id="cvs-source-changes"/>
-As the next step, one should check what has been changed in the file
-<command>knewbankdlg.cpp</command>. This is done using the following command:
-</para>
-
-<screen>
-
- <prompt>thb:~> </prompt><userinput>cvs -q diff knewbankdlg.cpp</userinput>
- 74,75d73
- < return;
- < }
- 77,84c75,84
- < m_name = nameEdit->text();
- < m_city = cityEdit->text();
- < m_street = streetEdit->text();
- < m_postcode = postcodeEdit->text();
- < m_telephone = telephoneEdit->text();
- < m_managerName = managerEdit->text();
- < m_sortCode = sortCodeEdit->text();
- < accept();
- ---
- > } else {
- > m_name = nameEdit->text();
- > m_city = cityEdit->text();
- > m_street = streetEdit->text();
- > m_postcode = postcodeEdit->text();
- > m_telephone = telephoneEdit->text();
- > m_managerName = managerEdit->text();
- > m_sortCode = sortCodeEdit->text();
- > accept();
- > }
- <prompt>thb:~> </prompt>
-
-
-</screen>
-</example>
-
-<para>
-The output shows the changes between the current and the original revision
-of the file. If this is what needs to be changed then the next step can be
-started, which is checking the changes back into the repository.
-</para>
-<screen>
-
- <prompt>thb:~> </prompt><userinput>cvs -q ci -m "Avoid return in the middle of a function" knewbankdlg.cpp</userinput>
- Checking in knewbankdlg.cpp;
- kmymoney/kmymoney/knewbankdlg.cpp,v <-- knewbankdlg.cpp
- new revision: 1.10; previous revision: 1.9
- done
- <prompt>thb:~> </prompt>
-
-
-</screen>
-
-
-<note>
-<para>
-If the option -m and the descriptive text is omitted on the command line,
-&cvs; starts an editor where the developer has to enter a descriptive text
-about the changes and save that file. Performing checkin operations that
-way is meaningful, if the description is longer or covers more than one file.
-</para>
-</note>
-
-<para>
-At this point, the changes are stored in the repository. An automatic mail
-is generated and send to the kmymoney-developer mailing list
-<email>kmymoney2-developer at lists.sourceforge.net</email>. This mail
-informs all other developers about your changes and is an indication for
-them to <link linkend="cvs-update">update</link> their sandboxes. The
-contents of the mail looks something like this:
-</para>
-
-<screen>
-
- From: Thomas Baumgart <ipwizard at users.sourceforge.net>
- To: kmymoney2-developer at lists.sourceforge.net
- Date: Sat, 24 Nov 2001 12:23:00 -0800
- Subject: [Kmymoney2-developer] CVS update:
-
- Update of /cvsroot/kmymoney/kmymoney/kmymoney
- In directory usw-pr-cvs1:/tmp/cvs-serv6662
-
- Modified Files:
- knewbankdlg.cpp
- Log Message:
- Avoid return in the middle of a function
- _______________________________________________
- Kmymoney2-developer mailing list
- Kmymoney2-developer at lists.sourceforge.net
- https://lists.sourceforge.net/lists/listinfo/kmymoney2-developer
-
-
-
-</screen>
-
-<para>
-While you checkin your changes, you should maintain the file
-<command>kmymoney/ChangeLog</command>. You could probably use the same
-comments that you use for checkin in your changes or a more general note
-for many changes. That depends on your changes. Once all your changes are
-checked in, you also checkin <command>kmymoney/ChangeLog</command>.
-</para>
-</section>
-
-<section id="cvs-update">
-<title>Updateing changes performed by other developers</title>
-<para>
-In case you noticed that other developers changed the repository -
-fortunately you will be noticed by a mail to the developer mailing list if
-that is the case - you should get those changes to your sandbox. This is
-accomplished using the <command>update</command> command of &cvs;.
-</para>
-
-<example>
-<title>Updating the sandbox</title>
-<para>
-To update the local sandbox the following command is used. As most other
-&cvs; commands, it operates recursively from the current working directory in
-the sandbox.
-</para>
-
-<screen>
-
- <prompt>thb:~> </prompt><userinput>cvs -q upd</userinput>
- U README
- M knewbankdlg.cpp
- <prompt>thb:~> </prompt>
-
-
-</screen>
-
-<para>
-The above shown output has the following meaning:
-the file <command>README</command> is udpated (U) from the repository to
-the sandbox because
-it has been changed by someone else in the meantime. The contents of the
-file
-in the sandbox will be replaced by the contents of the file in the
-repository, because it has not been altered in the sandbox.
-The file <command>knewbankdlg.cpp</command> has been modified (M) in the
-sandbox and needs to be returned to the repository.
-</para>
-
-<para>
-If you run the same command again, the output will change, as the file
-<command>README</command> is now up-to-date.
-</para>
-
-<screen>
-
- <prompt>thb:~> </prompt><userinput>cvs -q upd</userinput>
- M knewbankdlg.cpp
- <prompt>thb:~> </prompt>
-
-
-</screen>
-
-
-</example>
-
-<para>
-Sometimes it is useful to get an overview of what the status of certain
-files in the repository is without modifying the sandbox (updating). This
-can be accomplished by using the -n option to the update command.
-</para>
-
-<example>
-<title>Checking the status of files in the sandbox</title>
-<screen>
-
- <prompt>thb:~> </prompt><userinput>cvs -nq upd</userinput>
- U README
- M knewbankdlg.cpp
- <prompt>thb:~> </prompt>
-
-
-</screen>
-
-<para>
-The status of the files is the same as explained above, but the file
-<command>README</command>
-will <emphasis>not</emphasis> be updated. It remains unchanged in the
-sandbox. If you run this command again, the output remains.
-</para>
-</example>
-
-</section>
-
-<section id="dismissing-changes">
-<title>Dismissing changes</title>
-<para>
-It happens, that a developer tries to modify the source to gain a certain
-functionality and then wants to discard the changes. This is no problem at
-all with &cvs;. All the developer needs to do is to remove the file in the
-sandbox and run the <command>update</command> command of &cvs;. This will
-transfer the original version of the file in question to the sandbox.
-</para>
-
-<para>
-Let's assume, that the changes made to <command>knewbankdlg.cpp</command>
-as outlined in <link linkend="cvs-source-changes">a previous chapter</link> should
-be dismissed. The following commands perform this operation:
-</para>
-
-<example>
-<title>Reverting changes made to the sandbox</title>
-<screen>
-
- <prompt>thb:~> </prompt><userinput>cvs -q upd</userinput>
- M knewbankdlg.cpp
- <prompt>thb:~> </prompt><userinput>rm knewbankdlg.cpp</userinput>
- <prompt>thb:~> </prompt><userinput>cvs -q upd</userinput>
- U knewbankdlg.cpp
- <prompt>thb:~> </prompt><userinput>cvs -q upd</userinput>
- <prompt>thb:~> </prompt>
-
-
-</screen>
-</example>
-
-</section>
-
-<section id="multiple-branches">
-<title>Keeping different branches on the same machine</title>
-<para>
-Whenever a configuration manager of the project decides to create a new
-stable release, the developers face a problem: they are not allowed to add
-new features to the software, only bug-fixes can be checked into the
-repository. Until the configuration manager opens the sources for further
-development, the developers are stuck.
-</para>
-
-<para>
-To avoid this dilemma, the configuration manager creates a branch off the
-main development line when he creates the new stable release. Fixes will be
-made to the release-branch, new developments will be made to the main
-branch. This eliminates two problems: the configuration manager does not
-have to lock the current stage and the developers can continue with the
-implementation of features planned for the next release. Nevertheless, the
-stable version can be changed (fixes can be applied) and those fixes can be
-transferred to the main development branch so that they do not show up in
-future releases of the software.
-</para>
-
-<para>
-Since in our project the developers will work on both, bug fixes and new
-development at the same time, it is convenient to have two sandboxes on the
-development machine. For the following examples, I have two subdirectories
-in my $HOME for the project. One is for the release and the other for the
-develepment branch. I name them <command>stable</command> for the release
-branch and
-<command>devel</command> for the development branch.
-</para>
-
-<para><command>The development branch</command></para>
-<para>
-The development branch is the same as you use it today. Just move it from
-it's current location to $HOME/devel. I kept it directly in my $HOME
-directory so I did it as follows:
-
-<example>
-<title>Keeping stable and development branch on one machine</title>
-<screen>
-
- <prompt>thb:~> </prompt><userinput>md devel</userinput>
- <prompt>thb:~> </prompt><userinput>md stable</userinput>
- <prompt>thb:~> </prompt><userinput>mv kmymoney devel</userinput>
- <prompt>thb:~> </prompt>
-
-
-</screen>
-</example>
-Now the development sources are found in ~/devel/kmymoney/. It is
-important to move all the CVS directories as well. If you start from
-scratch, then you just follow the instructions on how to checkout the
-project and do that in the <command>devel</command> subdirectory. See the
-chapter <emphasis>
-<link linkend="cvs-checkout">Checking out from the repository</link>
-</emphasis> for an example.
-</para>
-
-<para><command>The release branch</command></para>
-<para>
-As soon as a release branch has been created by the configuration manager,
-you should get it to the stable directory. You do this by checking it out
-with the tag that has been assigned. The conventions have been defined in
-the chapter about <link linkend="version-mgmt">Version management</link>.
-For this example, I assume that a release branch for version 0.4 exists in
-the repository.
-
-<footnote>
-<para>Guess when I wrote this chapter ;-)</para>
-</footnote>
-</para>
-
-<example>
-<title>Checking out the stable branch for the first time</title>
-<screen>
-
- <prompt>thb:~> </prompt><userinput>cd stable</userinput>
- <prompt>thb:~/stable> </prompt><userinput>cvs -d &cvs-user;@&cvs-host;:&cvs-dir; \
-The back-slash is inserted here to break the line for readability. For real usage, the command has to be entered on a single line.
- co -r rel-0-4-branch &cvs-module;</userinput>
- <prompt>thb:~/stable> </prompt>
-
-
-</screen>
-</example>
-
-<para>
-At this point it is important to use the <emphasis>branch-tag</emphasis> to
-be able to modifiy the files and check them back into the repository. If
-you are in the subdirectory containing the release-branch and you perform a
-<command>cvs update</command>, you will only get those changes, that were
-made on the branch. Also, changes are checked back into the release branch
-and do <emphasis>NOT</emphasis> show up on the development branch.
-</para>
-
-<note>
-<para>
-If you want to keep more than one stable branch on your development
-machine, you can add the version number to the stable directory (e.g.
-stable-0.4, etc.)
-</para>
-</note>
-</section>
-
-<section id="promoting-changes">
-<title>Promoting bug-fixes to the main branch</title>
-<para>
-Usually, changes made to the release-branch fix a problem. In many cases the
-problem still exists in the development branch. Therefor, it is
-necessary to promote the changes made on the release branch back to the
-development branch.
-</para>
-
-<para>
-In most cases, it is very easy to promote the changes. The developer must
-be very careful though, as the fix might not be applicable in it's form to
-the development branch anymore as things might have changed drastically due
-to new features.
-<footnote>
-<para>
-This is one of the reasons, why I suggest to apply the fix to the release
-branch and promote it to the developer branch, as the fix as it works on
-the release branch might
-break things and broken software is definitly something we do not want
- to happen on the stable branch.
-</para>
-</footnote>
-</para>
-
-<para>
-In this example, I assume changes were made to the single file README.
-<footnote>
-<para>
-Fortunately, the error found was a documentation problem ;-)
-</para>
-</footnote>
-
-A complex fix
-could cover many files. The procedure described in the following is then
-required for each of them seperately. Further on, I assume that the change
-has been checked in and that the revision was 1.14.2.1 before the fix and
-is now 1.14.2.2.
-</para>
-
-<example>
-<title>Promoting a change from the release to the development branch</title>
-<screen>
-
- <prompt>thb:~> </prompt><userinput>cd devel/kmymoney</userinput>
- <prompt>thb:~/devel/kmymoney> </prompt><userinput>cvs -q upd -j 1.14.2.1 -j 1.14.2.2 README</userinput>
- <prompt>thb:~/devel/kmymoney> </prompt><userinput>vi README</userinput>
- <prompt>thb:~/devel/kmymoney> </prompt><userinput>cvs ci -m "Included fix #493920" README</userinput>
- <prompt>thb:~/devel/kmymoney> </prompt>
-
-
-</screen>
-</example>
-
-<para>
-First, I go into the devel directory. Then I promote the changes to the
-README file in the development branch from the repository, verify the
-changes made (and possibly correct them) and checkin the changes to the
-development branch. That's it!
-<footnote>
-<para>
- Of course, a fix to a source code file would
-be followed by a visual inspection (that's where <command>vi</command> or
-<command>kdevelop</command> come into play) and a compile run with further
-testing before the change is checked back into the repository.
-</para>
-</footnote>
-
-</para>
-
-<note>
-<para>
-It's important to perform this procedure for every file affected by the fix
-seperatly, as the revision numbers usually differ significantly between
-the files. Also, I suggest to fix each problem seperately. This reduces
-further problems while promoting the changes back to the development
-branch (e.g. one can leave out a fix completely if it does not apply at all
-to the development branch).
-</para>
-<para>
-If the fix is very simple, it can certainly be promoted manually to the
-development directory tree by merely re-typing it.
-</para>
-</note>
-</section>
-
-<section id="create-stable-example">
-<title>Creating a new stable release</title>
-<para>
-The procedure that needs to be followed is defined in a <link
-linkend="create-stable-procedure">previous chapter</link>.
-On the first glimpse, it seems rather complecated but it is not.
-</para>
-
-<para>
-If you follow the procedure as it has been defined, you will understand the
-commands in our example. I assume to have a current unstable version of
-0.3.x which will result in the stable version 0.4 and the next development
-version of 0.5.x. Further on, I assume, that I already differentiate
-between development and release directories. Also, the version number
-maintained with KDevelop is setup correctly (0.4.pre1) and all files are
-checked into the repository.
-</para>
-
-<example>
-<title>Creating a new stable branch</title>
-
-<screen>
-
- <prompt>thb:~> </prompt><userinput>cd devel/kmymoney</userinput>
- <prompt>thb:~/devel/kmymoney> </prompt><userinput>cvs tag rel-0-4-pre1</userinput>
- <prompt>thb:~/devel/kmymoney> </prompt><userinput>cvs tag -b rel-0-4-branch</userinput>
-
- Now modify the version number in KDevelop to 0.5.0, regenerate the files and
- checkin the changes as usual.
-
- <prompt>thb:~/devel/kmymoney> </prompt><userinput>cvs tag rel-0-5-base</userinput>
- <prompt>thb:~/devel/kmymoney> </prompt>
-
-
-</screen>
-</example>
-
-<tip>
-<para>
-Because I know, that I will need the branch sooner or later to fix some
-problems, I continue to check it out into the stable directory. See <link
-linkend="multiple-branches">Keeping different branches on the same
-machine</link> for details.
-</para>
-</tip>
-
-</section>
-</appendix>
-
diff --git a/developer-doc/phb/dialogs.docbook b/developer-doc/phb/dialogs.docbook
deleted file mode 100644
index 40e847f..0000000
--- a/developer-doc/phb/dialogs.docbook
+++ /dev/null
@@ -1,130 +0,0 @@
- <chapter id="dialogs">
- <title>Creating dialog boxes in &kappname;</title>
- <para/>
- <para>This section is a developer's guide explaining the peculiarities of dialog creation in &kappname;. A basic understanding of Qt GUI programming is assumed, as is a knowledge of &kappname; coding standards as laid out in the Project Handbook.</para>
- <para/>
- <sect1 id="dialogs-language">
- <title>Language</title>
- <para/>
- <para>The default language of &kappname; is American English, but don't let that put you off! All contributions will be welcome, and as long as you have a basic knowledge of the language, the members of the &kappname; developers list will be happy to help you polish it up.</para>
- <para/>
- </sect1>
- <sect1 id="dialogs-naming">
- <title>Naming the dialog</title>
- <para/>
- <para>First step is to choose a meaningful name for your dialog (and preferably one that's not already in use! - see the kmymoney/dialogs source directory). In accordance with &kappname; coding conventions, the name should consist of 2 or 3 (or more) 'words', strung together without spaces. To keep names to a manageable length, these 'words' may be abbreviated, e.g. 'sched' for 'schedule'. Each 'word' should be spelt with an initial upper-case letter. Also, the names of dialogs are always preceded by a letter 'K', thus e.g. KEditSchedTrans. This name will be indicated in the rest of this chapter by <KN>. There are nevertheless occasions where all lower case letters are appropriate, specifically source file names; this will be indicated as <kn>.</para>
- <para/>
- </sect1>
- <sect1 id="dialogs-designing">
- <title>Designing the dialog</title>
- <para/>
- <para>The dialog screen should be built using Qt Designer. This section assumes that you are using version 3.x of Qt. Version 4 is, at present, an unknown quantity.</para>
- <para/>
- <para>Open Designer without specifying a project, and select Dialog from the New File/Project tab. Start by changing the form name; this should be set to '<KN>DlgDecl'.</para>
- <para/>
- <para>Now add your widgets to the form, not forgetting to include a Help button. Remember that users will have many different hardware and screen combinations, and will need to be able to resize windows, so make full use of the various layout and spacer options of Designer. A lot of tutorials can be found on the web to help guide you on this; try your favourite search engine.</para>
- <para/>
- <sect2 id="dialogs-naming-widgets">
- <title>Naming widgets</title>
- <para/>
- <para>Fixed widgets, e.g. text labels, can often use the default names assigned by Designer. Other widgets on your form should be given names which are meaningful in an application context. This is particularly important for those widgets which are to be referenced in code. As per the application programming standards, these names should be prefixed with 'm_' to indicate them as member variables of the dialog.</para>
- <para/>
- </sect2>
- <sect2 id="dialogs-i18n-considerations">
- <title>i18n considerations</title>
- <para/>
- <para>Designer contains an option to generate shortcut (accelerator) keys for various widgets (buttons, menu items) by including an ampersand ('&') before the shortcut letter. This should be used for the more common items, since many users prefer to use keyboard input rather than using the mouse. However, this does have the unfortunate side effect of automatically generating an 'accel' property for the widget, referencing a letter which may not be appropriate when the caption is translated to another language. Use the properties menu, therefore, to remove this value, or see below.</para>
- <para/>
- <para>Fixed text fields and labels in the form do not require any special consideration. Qt Designer and the project's build environment will take care of wrapping the strings into an i18n construct for presentation to translators.</para>
- <para/>
- </sect2>
- <sect2 id="dialogs-saving-ui">
- <title>Saving the UI</title>
- <para/>
- <para>When complete, save the form using the Designer default name (<kn>dlgdecl.ui) in the dialogs source code folder (kmymoney/dialogs).</para>
- <para/>
- </sect2>
- </sect1>
- <sect1 id="dialogs-writing-code">
- <title>Writing code</title>
- <para/>
- <para>Your code to process form actions should be included in source files named <kn>dlg.h/.cpp, in the same folder as the .ui file. You can view these for many examples of how to code. Some requirements are:</para>
- <para/>
- <sect2 id="dialogs-header-file">
- <title>Header (.h) file</title>
- <para/>
- <para>This should start with definitions similar to the following</para>
- <para/>
- <programlisting>
- #ifndef <KN>DLG_H
- #define <KN>DLG_H</programlisting>
- <para/>
- <programlisting>
- #include "../dialogs/<kn>dlgdecl.h"</programlisting>
- <para/>
- <programlisting>
- class <KN>Dlg : public <KN>DlgDecl {
- Q_OBJECT
- public:
- <KN>Dlg(QWidget *parent = 0, const char *name = 0);
- ~<KN>Dlg();
- </programlisting>
- <para/>
- <para>The first two lines are the standard include stoppers, to avoid multiple inclusion of the class data.</para>
- <para/>
- <para>The include file will have been generated by the Qt UIC (User Interface Compiler) from the .ui file for the dialog, under control of the make process.</para>
- <para/>
- <para>The Q_OBJECT macro (written without any punctuation) will cause the Qt MOC (Meta Object Compiler) to generate additional object code and files which are necessary to support the signal/slot functionality (among other things).</para>
- <para/>
- <para>The class declaration must also include a </para>
- <para/>
- <programlisting> public slots:</programlisting>
- <para/>
- <para>and</para>
- <para/>
- <programlisting> signals:</programlisting>
- <para/>
-
- <para>sections if you plan to use the signal/slot mechanism. See the Qt documentation about signals and slots. An example would be slotHelp() which will be connected to the clicked() signal of the help button of your dialog in the constructor of your dialog.</para>
- <para/>
- <para>Terminate the file with</para>
- <para/>
- <programlisting> #endif</programlisting>
- <para/>
- <para>to close off the include stoppers.</para>
- <para/>
- </sect2>
- <sect2 id="dialogs-code-file">
- <title>Code (.cpp) file</title>
- <para/>
- <para>First, don't forget to have #include directives for Qt headers for any widgets you are going to reference.</para>
- <para/>
- <para>In the constructor function, connect all signals to their appropriate slots using the Qt connect() call.</para>
- <para/>
- <para>Then the easy bit; write your code.</para>
- <para/>
- <para>Finally, terminate the source file with the following</para>
- <para/>
- <programlisting> #include "<KN>dlg.moc"</programlisting>
- <para/>
- <para>This is one of the files generated by the Qt MOC (Meta Object Compiler) during the make process; if you finish up with 'vtable' errors, it's probably because you forgot to include this.</para>
- <para/>
- </sect2>
- </sect1>
- <sect1 id="dialogs-updating-makefile">
- <title>Updating the Makefile</title>
- <para/>
- <para>You will need to edit file Makefile.am in the dialogs source folder before building &kappname;. Note that due to the abstruse rules of make, the lists of files should consist of a single logical line, so be careful regarding any editor options which may cause automatic insertion of line breaks. You can however use a continuation character of backslash to spread the list over multiple physical lines. There must be no character following the continuation character, not even a blank.</para>
- <para/>
- <para>- Add <kn>dlgdecl.ui and <kn>dlg.cpp to the libdialogs_a_SOURCES line</para>
- <para>- Add <kn>dlgdecl.ui to EXTRA_DIST</para>
- <para>- Add <kn>dlgdecl.cpp and <kn>dlgdecl.h to DISTCLEANFILES</para>
- <para>- Add <kn>dlg.h to NOINST_HEADERS</para>
- <para/>
- <para>Save the file, and you are ready to build &kappname;. For the first build after updating Makefile.am you should re-run 'make -f Makefile.dist', reconfigure and make. Otherwise, some make rules might not be present and compiling fails.</para>
- <para/>
- <para>That's all, simple wasn't it.</para>
- <para/>
- </sect1>
- </chapter>
-
diff --git a/developer-doc/phb/documentation.docbook b/developer-doc/phb/documentation.docbook
deleted file mode 100644
index b6be082..0000000
--- a/developer-doc/phb/documentation.docbook
+++ /dev/null
@@ -1,118 +0,0 @@
-<chapter id="documentation">
-<chapterinfo>
-
-<keywordset>
- <keyword>documentation</keyword>
-</keywordset>
-
-<authorgroup>
-<author>
- <firstname>Tom</firstname>
- <surname>Browder</surname>
- <affiliation>
- <address><email>tom.browder at gmail.com</email></address>
- </affiliation>
-</author>
-</authorgroup>
-
-</chapterinfo>
-
-<title>Documentation</title>
-
-<para>
-Code documentation is discussed in the section "coding." This section discusses developer and user documentation and generating html and pdf versions of same. Note that all non-source-code documentation, with two exceptions, must be written in docbook form.
-<note>
-<para>
-The two exceptions are
-<filename>./kmymoney/html/home.html</filename>
-and
-<filename>./kmymoney/html/whats_new.html</filename>
-which are used on &kappname;'s internal home page when running the application.
-</para>
-</note>
-</para>
-
-<!-- =============================================== -->
-<sect1 id="documentation-general">
-<title>General</title>
-<para>In general, all documentation for &kappname; should follow guidelines for the KDE project.
-In addition to the KDE guidelines, there are &kappname; guidelines (which take precedence if there are conflicts).
-See the following KDE resources:
-</para>
-<orderedlist>
-<listitem><para><ulink url="http://l10n.kde.org/">http://l10n.kde.org/</ulink></para></listitem>
-<listitem><para><ulink url="http://l10n.kde.org/docs/markup/index.html">http://l10n.kde.org/docs/markup/index.html</ulink></para></listitem>
-<listitem><para><ulink url="http://l10n.kde.org/docs/tools.php">http://l10n.kde.org/docs/tools.php</ulink></para></listitem>
-<listitem><para><ulink url="http://people.fruitsalad.org/phil/kde">http://people.fruitsalad.org/phil/kde</ulink></para></listitem>
-<listitem><para><ulink url="http://people.fruitsalad.org/phil/kde/pdf-stuff/pdf-instructions.html">http://people.fruitsalad.org/phil/kde/pdf-stuff/pdf-instructions.html</ulink></para></listitem>
-
-</orderedlist>
-
-<para>XML entities should be used for commonly used terms and phrases. There is a &kappname; list at
-<orderedlist>
-<listitem><para>./developer-doc/phb/kmymoney-entities.docbook</para></listitem>
-</orderedlist>
-</para>
-
-
-</sect1>
-
-
-<!-- =============================================== -->
-<sect1 id="documentation-entities">
-<title>Style Guide</title>
-<para>
-</para>
-</sect1>
-
-<!-- =============================================== -->
-<sect1 id="documentation-tools">
-<title>Tools</title>
-<orderedlist>
-<listitem><para>meinproc (used to produce HTML from docbook; part of KDE base)</para></listitem>
-<listitem><para>dblatex (used to produce PDF from docbook; add-on from KDE doc team; see resources)</para></listitem>
-<listitem><para>??check?? (used to check docbook formatting, etc.; part of KDE base)</para></listitem>
-<listitem><para>??check?? (used to check consistency of word and phrase usage; add-on from KDE doc team; see resources)</para></listitem>
-</orderedlist>
-</sect1>
-
-<!-- =============================================== -->
-<sect1 id="documentation-style-guide">
-<title>Style Guide</title>
-<para>
-</para>
-</sect1>
-
-
-
-<!-- =============================================== -->
-<sect1 id="documentation-making-docs">
-<title>Producing Final Documents</title>
-
-<sect2 id="documentation-making-html">
-<title>HTML</title>
-<example>
-<title>Using include stoppers</title>
-<screen>
-
- (command)
-</screen>
-</example>
-</sect2>
-
-<sect2 id="documentation-making-pdf">
-<title>PDF</title>
-<para>
-</para>
-</sect2>
-
-<sect2 id="documentation-making-man">
-<title>Man Pages (UNIX only)</title>
-<para>
-</para>
-</sect2>
-
-</sect1>
-
-</chapter>
-
diff --git a/developer-doc/phb/error-mgmt.docbook b/developer-doc/phb/error-mgmt.docbook
deleted file mode 100644
index 588c90d..0000000
--- a/developer-doc/phb/error-mgmt.docbook
+++ /dev/null
@@ -1,330 +0,0 @@
-<chapter id="problem-mgmt">
-<title>Problem Management</title>
-<para>
-This chapter is a first draft. It contains some ideas that have to be
-validated by the developer community.
-</para>
-
-<sect1 id="problem-reporting">
-<title>Reporting problems</title>
-<para>
-Problems (that covers errors, enhancement request, etc.) concerning the
-&app; project are maintained
-using the SourceForge.net platform. This is the sole location, where
-problems have to be reported. The source for such a problem report can be
-one of the developers or any other user of &app;.
-</para>
-
-<sect2 id="problem-reference">
-<title>Referencing problems</title>
-<para>
-Once added to the database, the problem will be assigned a unique problem
-number. This number must be mentioned whenever the problem is referenced
-(e.g. in the subject of a mail to the developer mailing-list, a checkin
-comment or an entry in the ChangeLog file). To allow searches for the number,
-a specific format has to be used for these references.
-
-The format is
-<command>#assigned-number</command>, e.g. #481229.
-</para>
-</sect2>
-</sect1>
-
-
-<sect1 id="problem-attributes">
-<title>Problem attributes</title>
-<para>
-Besides the fixed problem number which is created when the report is filed,
- each
-problem has a couple of attributes that might change during the
-life-cycle of the problem. They will be described in the following
-chapters.
-</para>
-
-<sect2 id="problem-reported-by">
-<title>Reported By</title>
-<para>
-As the problem number, this field is fix. It represents the SourceForge
-username of the individual who filed the report.
-</para>
-</sect2>
-
-<sect2 id="problem-severity-level">
-<title>Severity level</title>
-<para>
-The SourceForge.net platform allows to assign a severity level to each
-problem. It ranges from 1 to 10. The meaning in our project and the
-consequences are defined as follows:
-
-</para> <para> FIXME: A more detailed description of the prios needs to be given
-
-<orderedlist>
-<listitem>
-<para>
-Lowest priority
-</para>
-</listitem>
-
-<listitem>
-<para>
-TBD!
-</para>
-</listitem>
-
-<listitem>
-<para>
-TBD!
-</para>
-</listitem>
-
-<listitem>
-<para>
-TBD!
-</para>
-</listitem>
-
-<listitem>
-<para>
-Medium priority (default)
-</para>
-</listitem>
-
-<listitem>
-<para>
-TBD!
-</para>
-</listitem>
-
-<listitem>
-<para>
-TBD!
-</para>
-</listitem>
-
-<listitem>
-<para>
-TBD!
-</para>
-</listitem>
-
-<listitem>
-<para>
-TBD!
-</para>
-</listitem>
-
-<listitem>
-<para>
-Highest priority
-</para>
-</listitem>
-
-</orderedlist>
-</para>
-</sect2>
-
-<sect2 id="problem-area">
-<title>Area</title>
-<para>
-TBD!
-</para>
-</sect2>
-
-<sect2 id="problem-assignee">
-<title>Assignee</title>
-<para>
-This field represents the SourceForge.net username of the individual
-working on the problem. Each developer should pick problems he feels
-competent to work on. The possibility to assign another developer to a
-problem should be used only to gather a comment from this developer. This
-should be clearly marked as comment with the report.
-</para>
-
-<note>
-<para>
-The number of unassigned problem reports should be 0 most of the time to
-give clear signal to the world that the developers are working on the
-project!
-</para>
-</note>
-</sect2>
-
-<sect2 id="problem-status">
-<title>Status</title>
-<para>
-Each problem has a status. Right after filing a report, it will be assigned
-the status 'open' automatically by the SourceForge.net platform. Whenever a
-developer is working on the problem, he will have to modifiy the value of
-this field to reflect the current status. The following values are
-available and have the associated meaning:
-</para>
-
-<para>
-
-<table>
-<title>Available problem status values</title>
-<tgroup cols="2">
-<thead>
-<row>
-<entry>Status</entry>
-<entry>Meaning</entry>
-</row>
-</thead>
-
-<tbody>
-<row>
-<entry>open</entry>
-<entry>
-The problem is not yet fixed. A developer might be working on it.
-</entry>
-</row>
-
-<row>
-<entry>closed</entry>
-<entry>
-The problem has been closed. No further action is required.
-</entry>
-</row>
-
-<row>
-<entry>deleted</entry>
-<entry>
-???
-</entry>
-</row>
-
-<row>
-<entry>pending</entry>
-<entry>
-The problem has been modified solved and feedback from the original poster
-is required. Pending entries will turn into closed entries after 14 days.
-</entry>
-</row>
-
-</tbody>
-</tgroup>
-</table>
-
-</para>
-</sect2>
-
-
-<sect2 id="problem-resolution">
-<title>Resolution</title>
-<para>
-The following values are available and have the associated meaning:
-</para>
-<para>
-
-<table>
-<title>Available problem resolution values</title>
-<tgroup cols="2">
-<thead>
-<row>
-<entry>Resolution</entry>
-<entry>Meaning</entry>
-</row>
-</thead>
-
-<tbody>
-<row>
-<entry>Accepted</entry>
-<entry>
-The problem report has been accepted by the developers. Nevertheless, it
-has not yet been duplicated but from the initial report it could well
-be a problem with &app;
-</entry>
-</row>
-
-<row>
-<entry>Duplicated</entry>
-<entry>
-The problem has been duplicated by one of the developers.
-</entry>
-</row>
-
-<row>
-<entry>Fixed</entry>
-<entry>
-The problem has been fixed. The code is available via CVS.
-</entry>
-</row>
-
-<row>
-<entry>Invalid</entry>
-<entry>
-The report is not valid. It's not a problem related to &app;.
-</entry>
-</row>
-
-<row>
-<entry>Later</entry>
-<entry>
-???
-</entry>
-</row>
-
-<row>
-<entry>None</entry>
-<entry>
-???
-</entry>
-</row>
-
-<row>
-<entry>Out of date</entry>
-<entry>
-The report is based on an older version of &app; and has been resolved
-in the meantime in a newer release which is available for download or CVS.
-</entry>
-</row>
-
-<row>
-<entry>Postponed</entry>
-<entry>
-The problem has been acknowledged but will be postponed until later. The
-developer changeing the state to Postponed should leave a comment with the
-entry why it is postponed.
-</entry>
-</row>
-
-<row>
-<entry>Rejected</entry>
-<entry>
-The problem has been rejected by the development team. The developer
-changing the state to Rejected should leave a comment with the entry
-nameing the reasons for rejection.
-</entry>
-</row>
-
-<row>
-<entry>Remind</entry>
-<entry>
-???
-</entry>
-</row>
-
-<row>
-<entry>Wont fix</entry>
-<entry>
-???
-</entry>
-</row>
-
-<row>
-<entry>Works for me</entry>
-<entry>
-The problem cannot be duplicated but seems to be a valid problem. The
-entry needs more investigation.
-</entry>
-</row>
-
-</tbody>
-</tgroup>
-</table>
-
-</para>
-</sect2>
-
-</sect1>
-</chapter>
diff --git a/developer-doc/phb/fdl-licence b/developer-doc/phb/fdl-licence
deleted file mode 100644
index fa8fdef..0000000
--- a/developer-doc/phb/fdl-licence
+++ /dev/null
@@ -1,356 +0,0 @@
- GNU Free Documentation License
- Version 1.1, March 2000
-
- Copyright (C) 2000 Free Software Foundation, Inc.
- 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-
-0. PREAMBLE
-
-The purpose of this License is to make a manual, textbook, or other
-written document "free" in the sense of freedom: to assure everyone
-the effective freedom to copy and redistribute it, with or without
-modifying it, either commercially or noncommercially. Secondarily,
-this License preserves for the author and publisher a way to get
-credit for their work, while not being considered responsible for
-modifications made by others.
-
-This License is a kind of "copyleft", which means that derivative
-works of the document must themselves be free in the same sense. It
-complements the GNU General Public License, which is a copyleft
-license designed for free software.
-
-We have designed this License in order to use it for manuals for free
-software, because free software needs free documentation: a free
-program should come with manuals providing the same freedoms that the
-software does. But this License is not limited to software manuals;
-it can be used for any textual work, regardless of subject matter or
-whether it is published as a printed book. We recommend this License
-principally for works whose purpose is instruction or reference.
-
-
-1. APPLICABILITY AND DEFINITIONS
-
-This License applies to any manual or other work that contains a
-notice placed by the copyright holder saying it can be distributed
-under the terms of this License. The "Document", below, refers to any
-such manual or work. Any member of the public is a licensee, and is
-addressed as "you".
-
-A "Modified Version" of the Document means any work containing the
-Document or a portion of it, either copied verbatim, or with
-modifications and/or translated into another language.
-
-A "Secondary Section" is a named appendix or a front-matter section of
-the Document that deals exclusively with the relationship of the
-publishers or authors of the Document to the Document's overall subject
-(or to related matters) and contains nothing that could fall directly
-within that overall subject. (For example, if the Document is in part a
-textbook of mathematics, a Secondary Section may not explain any
-mathematics.) The relationship could be a matter of historical
-connection with the subject or with related matters, or of legal,
-commercial, philosophical, ethical or political position regarding
-them.
-
-The "Invariant Sections" are certain Secondary Sections whose titles
-are designated, as being those of Invariant Sections, in the notice
-that says that the Document is released under this License.
-
-The "Cover Texts" are certain short passages of text that are listed,
-as Front-Cover Texts or Back-Cover Texts, in the notice that says that
-the Document is released under this License.
-
-A "Transparent" copy of the Document means a machine-readable copy,
-represented in a format whose specification is available to the
-general public, whose contents can be viewed and edited directly and
-straightforwardly with generic text editors or (for images composed of
-pixels) generic paint programs or (for drawings) some widely available
-drawing editor, and that is suitable for input to text formatters or
-for automatic translation to a variety of formats suitable for input
-to text formatters. A copy made in an otherwise Transparent file
-format whose markup has been designed to thwart or discourage
-subsequent modification by readers is not Transparent. A copy that is
-not "Transparent" is called "Opaque".
-
-Examples of suitable formats for Transparent copies include plain
-ASCII without markup, Texinfo input format, LaTeX input format, SGML
-or XML using a publicly available DTD, and standard-conforming simple
-HTML designed for human modification. Opaque formats include
-PostScript, PDF, proprietary formats that can be read and edited only
-by proprietary word processors, SGML or XML for which the DTD and/or
-processing tools are not generally available, and the
-machine-generated HTML produced by some word processors for output
-purposes only.
-
-The "Title Page" means, for a printed book, the title page itself,
-plus such following pages as are needed to hold, legibly, the material
-this License requires to appear in the title page. For works in
-formats which do not have any title page as such, "Title Page" means
-the text near the most prominent appearance of the work's title,
-preceding the beginning of the body of the text.
-
-
-2. VERBATIM COPYING
-
-You may copy and distribute the Document in any medium, either
-commercially or noncommercially, provided that this License, the
-copyright notices, and the license notice saying this License applies
-to the Document are reproduced in all copies, and that you add no other
-conditions whatsoever to those of this License. You may not use
-technical measures to obstruct or control the reading or further
-copying of the copies you make or distribute. However, you may accept
-compensation in exchange for copies. If you distribute a large enough
-number of copies you must also follow the conditions in section 3.
-
-You may also lend copies, under the same conditions stated above, and
-you may publicly display copies.
-
-
-3. COPYING IN QUANTITY
-
-If you publish printed copies of the Document numbering more than 100,
-and the Document's license notice requires Cover Texts, you must enclose
-the copies in covers that carry, clearly and legibly, all these Cover
-Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
-the back cover. Both covers must also clearly and legibly identify
-you as the publisher of these copies. The front cover must present
-the full title with all words of the title equally prominent and
-visible. You may add other material on the covers in addition.
-Copying with changes limited to the covers, as long as they preserve
-the title of the Document and satisfy these conditions, can be treated
-as verbatim copying in other respects.
-
-If the required texts for either cover are too voluminous to fit
-legibly, you should put the first ones listed (as many as fit
-reasonably) on the actual cover, and continue the rest onto adjacent
-pages.
-
-If you publish or distribute Opaque copies of the Document numbering
-more than 100, you must either include a machine-readable Transparent
-copy along with each Opaque copy, or state in or with each Opaque copy
-a publicly-accessible computer-network location containing a complete
-Transparent copy of the Document, free of added material, which the
-general network-using public has access to download anonymously at no
-charge using public-standard network protocols. If you use the latter
-option, you must take reasonably prudent steps, when you begin
-distribution of Opaque copies in quantity, to ensure that this
-Transparent copy will remain thus accessible at the stated location
-until at least one year after the last time you distribute an Opaque
-copy (directly or through your agents or retailers) of that edition to
-the public.
-
-It is requested, but not required, that you contact the authors of the
-Document well before redistributing any large number of copies, to give
-them a chance to provide you with an updated version of the Document.
-
-
-4. MODIFICATIONS
-
-You may copy and distribute a Modified Version of the Document under
-the conditions of sections 2 and 3 above, provided that you release
-the Modified Version under precisely this License, with the Modified
-Version filling the role of the Document, thus licensing distribution
-and modification of the Modified Version to whoever possesses a copy
-of it. In addition, you must do these things in the Modified Version:
-
-A. Use in the Title Page (and on the covers, if any) a title distinct
- from that of the Document, and from those of previous versions
- (which should, if there were any, be listed in the History section
- of the Document). You may use the same title as a previous version
- if the original publisher of that version gives permission.
-B. List on the Title Page, as authors, one or more persons or entities
- responsible for authorship of the modifications in the Modified
- Version, together with at least five of the principal authors of the
- Document (all of its principal authors, if it has less than five).
-C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-D. Preserve all the copyright notices of the Document.
-E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-F. Include, immediately after the copyright notices, a license notice
- giving the public permission to use the Modified Version under the
- terms of this License, in the form shown in the Addendum below.
-G. Preserve in that license notice the full lists of Invariant Sections
- and required Cover Texts given in the Document's license notice.
-H. Include an unaltered copy of this License.
-I. Preserve the section entitled "History", and its title, and add to
- it an item stating at least the title, year, new authors, and
- publisher of the Modified Version as given on the Title Page. If
- there is no section entitled "History" in the Document, create one
- stating the title, year, authors, and publisher of the Document as
- given on its Title Page, then add an item describing the Modified
- Version as stated in the previous sentence.
-J. Preserve the network location, if any, given in the Document for
- public access to a Transparent copy of the Document, and likewise
- the network locations given in the Document for previous versions
- it was based on. These may be placed in the "History" section.
- You may omit a network location for a work that was published at
- least four years before the Document itself, or if the original
- publisher of the version it refers to gives permission.
-K. In any section entitled "Acknowledgements" or "Dedications",
- preserve the section's title, and preserve in the section all the
- substance and tone of each of the contributor acknowledgements
- and/or dedications given therein.
-L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section titles.
-M. Delete any section entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-N. Do not retitle any existing section as "Endorsements"
- or to conflict in title with any Invariant Section.
-
-If the Modified Version includes new front-matter sections or
-appendices that qualify as Secondary Sections and contain no material
-copied from the Document, you may at your option designate some or all
-of these sections as invariant. To do this, add their titles to the
-list of Invariant Sections in the Modified Version's license notice.
-These titles must be distinct from any other section titles.
-
-You may add a section entitled "Endorsements", provided it contains
-nothing but endorsements of your Modified Version by various
-parties--for example, statements of peer review or that the text has
-been approved by an organization as the authoritative definition of a
-standard.
-
-You may add a passage of up to five words as a Front-Cover Text, and a
-passage of up to 25 words as a Back-Cover Text, to the end of the list
-of Cover Texts in the Modified Version. Only one passage of
-Front-Cover Text and one of Back-Cover Text may be added by (or
-through arrangements made by) any one entity. If the Document already
-includes a cover text for the same cover, previously added by you or
-by arrangement made by the same entity you are acting on behalf of,
-you may not add another; but you may replace the old one, on explicit
-permission from the previous publisher that added the old one.
-
-The author(s) and publisher(s) of the Document do not by this License
-give permission to use their names for publicity for or to assert or
-imply endorsement of any Modified Version.
-
-
-5. COMBINING DOCUMENTS
-
-You may combine the Document with other documents released under this
-License, under the terms defined in section 4 above for modified
-versions, provided that you include in the combination all of the
-Invariant Sections of all of the original documents, unmodified, and
-list them all as Invariant Sections of your combined work in its
-license notice.
-
-The combined work need only contain one copy of this License, and
-multiple identical Invariant Sections may be replaced with a single
-copy. If there are multiple Invariant Sections with the same name but
-different contents, make the title of each such section unique by
-adding at the end of it, in parentheses, the name of the original
-author or publisher of that section if known, or else a unique number.
-Make the same adjustment to the section titles in the list of
-Invariant Sections in the license notice of the combined work.
-
-In the combination, you must combine any sections entitled "History"
-in the various original documents, forming one section entitled
-"History"; likewise combine any sections entitled "Acknowledgements",
-and any sections entitled "Dedications". You must delete all sections
-entitled "Endorsements."
-
-
-6. COLLECTIONS OF DOCUMENTS
-
-You may make a collection consisting of the Document and other documents
-released under this License, and replace the individual copies of this
-License in the various documents with a single copy that is included in
-the collection, provided that you follow the rules of this License for
-verbatim copying of each of the documents in all other respects.
-
-You may extract a single document from such a collection, and distribute
-it individually under this License, provided you insert a copy of this
-License into the extracted document, and follow this License in all
-other respects regarding verbatim copying of that document.
-
-
-
-7. AGGREGATION WITH INDEPENDENT WORKS
-
-A compilation of the Document or its derivatives with other separate
-and independent documents or works, in or on a volume of a storage or
-distribution medium, does not as a whole count as a Modified Version
-of the Document, provided no compilation copyright is claimed for the
-compilation. Such a compilation is called an "aggregate", and this
-License does not apply to the other self-contained works thus compiled
-with the Document, on account of their being thus compiled, if they
-are not themselves derivative works of the Document.
-
-If the Cover Text requirement of section 3 is applicable to these
-copies of the Document, then if the Document is less than one quarter
-of the entire aggregate, the Document's Cover Texts may be placed on
-covers that surround only the Document within the aggregate.
-Otherwise they must appear on covers around the whole aggregate.
-
-
-8. TRANSLATION
-
-Translation is considered a kind of modification, so you may
-distribute translations of the Document under the terms of section 4.
-Replacing Invariant Sections with translations requires special
-permission from their copyright holders, but you may include
-translations of some or all Invariant Sections in addition to the
-original versions of these Invariant Sections. You may include a
-translation of this License provided that you also include the
-original English version of this License. In case of a disagreement
-between the translation and the original English version of this
-License, the original English version will prevail.
-
-
-9. TERMINATION
-
-You may not copy, modify, sublicense, or distribute the Document except
-as expressly provided for under this License. Any other attempt to
-copy, modify, sublicense or distribute the Document is void, and will
-automatically terminate your rights under this License. However,
-parties who have received copies, or rights, from you under this
-License will not have their licenses terminated so long as such
-parties remain in full compliance.
-
-
-10. FUTURE REVISIONS OF THIS LICENSE
-
-The Free Software Foundation may publish new, revised versions
-of the GNU Free Documentation License from time to time. Such new
-versions will be similar in spirit to the present version, but may
-differ in detail to address new problems or concerns. See
-http:///www.gnu.org/copyleft/.
-
-Each version of the License is given a distinguishing version number.
-If the Document specifies that a particular numbered version of this
-License "or any later version" applies to it, you have the option of
-following the terms and conditions either of that specified version or
-of any later version that has been published (not as a draft) by the
-Free Software Foundation. If the Document does not specify a version
-number of this License, you may choose any version ever published (not
-as a draft) by the Free Software Foundation.
-
-
-ADDENDUM: How to use this License for your documents
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and
-license notices just after the title page:
-
- Copyright (c) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.1
- or any later version published by the Free Software Foundation;
- with the Invariant Sections being LIST THEIR TITLES, with the
- Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
- A copy of the license is included in the section entitled "GNU
- Free Documentation License".
-
-If you have no Invariant Sections, write "with no Invariant Sections"
-instead of saying which ones are invariant. If you have no
-Front-Cover Texts, write "no Front-Cover Texts" instead of
-"Front-Cover Texts being LIST"; likewise for Back-Cover Texts.
-
-If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License,
-to permit their use in free software.
diff --git a/developer-doc/phb/index.docbook b/developer-doc/phb/index.docbook
deleted file mode 100644
index c26fcc7..0000000
--- a/developer-doc/phb/index.docbook
+++ /dev/null
@@ -1,207 +0,0 @@
-<?xml version="1.0" ?>
-<!DOCTYPE book PUBLIC "-//KDE//DTD DocBook XML V4.5-Based Variant V1.1//EN" "dtd/kdedbx45.dtd" [
- <!ENTITY kappname "KMyMoney">
- <!ENTITY % addindex "IGNORE">
- <!ENTITY % English "INCLUDE"><!-- change language only here -->
-
- <!ENTITY version "1.2">
- <!ENTITY app "<command>KMyMoney</command>">
- <!ENTITY cvs "<command>CVS</command>">
- <!ENTITY ac "<command>autoconf</command>">
- <!ENTITY am "<command>automake</command>">
- <!ENTITY GPG "<command>GPG</command>">
- <!ENTITY cvs-host "kmymoney2.cvs.sourceforge.net">
- <!ENTITY cvs-anonuser "anonymous">
- <!ENTITY cvs-user "<emphasis>username</emphasis>">
- <!ENTITY cvs-dir "/cvsroot/kmymoney2">
- <!ENTITY cvs-module "kmymoney2">
-
- <!ENTITY config-management SYSTEM "cfg-mgmt.docbook">
- <!ENTITY release-management SYSTEM "rel-mgmt.docbook">
- <!ENTITY coding-standards SYSTEM "coding.docbook">
- <!ENTITY creating-dialogs SYSTEM "dialogs.docbook">
- <!ENTITY translation-hints SYSTEM "translation.docbook">
- <!ENTITY error-management SYSTEM "error-mgmt.docbook">
- <!ENTITY cvs-examples SYSTEM "cvs-examples.docbook">
- <!ENTITY src-examples SYSTEM "src-examples.docbook">
- <!ENTITY unit-test SYSTEM "unit-test.docbook">
- <!ENTITY test-examples SYSTEM "test-examples.docbook">
- <!ENTITY rpm-example SYSTEM "rpm-example.docbook">
- <!ENTITY documentation SYSTEM "documentation.docbook">
- <!ENTITY submissions SYSTEM "submissions.docbook">
- <!ENTITY settings SYSTEM "settings.docbook">
- <!ENTITY licence SYSTEM "licence.docbook">
- <!ENTITY fdl-licence SYSTEM "fdl-licence">
-]>
-
-<book id="phb" lang="&language;">
-<bookinfo>
-<title>&kappname; Project Handbook</title>
-<subtitle>Version &version;</subtitle>
-
-<authorgroup>
-<author>
-<honorific>Dipl.Ing</honorific>
-<firstname>Thomas</firstname>
-<surname>Baumgart</surname>
-<affiliation>
-<address><email>ipwizard at users.sourceforge.net</email></address>
-</affiliation>
-</author>
-
-<author>
-<firstname>Michael</firstname>
-<surname>Edwardes</surname>
-<affiliation>
-<address><email>mte at users.sourceforge.net</email></address>
-</affiliation>
-</author>
-
-</authorgroup>
-
-<copyright>
-<year>2001</year>
-<year>2002</year>
-<year>2005</year>
-<year>2008</year>
-<holder>Thomas Baumgart</holder>
-<holder>Michael Edwardes</holder>
-<holder>Alvaro Soliverez</holder>
-</copyright>
-
-<legalnotice>
-<para>
-Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.1
-or any later version published by the Free Software Foundation; with
-no Invariant Sections, with no Front-Cover texts, and with no Back-Cover
-Texts. A copy of the license is included in the appendix entitled
-<link linkend="licence">"GNU Free Documentation License"</link>.
-</para>
-</legalnotice>
-
-<date>22.06.2010</date>
-<releaseinfo>3.98.1</releaseinfo>
-
-<abstract>
-<para>
-As for any software development project, certain rules regulate the
-development process of &app;. These rules cover things like coding
-standards, configuration management and error reporting, just to name a few.
-The focus of this document is on configuration management and coding
-standards. More
-information about the &app; project can be found on the
-<ulink url="http://kmymoney.org/">project's hompage</ulink>.
-</para>
-<para>
-If you have any comments to raise about this document please send an email
-to <email>kmymoney2-developer at lists.sourceforge.net</email>,
-the project's developer mailing list and we will try to rectify it.
-
-Please note that the most up-to-date version of this document can be
-found in the source tree and is online on the
-<ulink url="http://kmymoney.org/">project's homepage</ulink>.
-A <ulink url="http://kmymoney.org/phb/kmymoney-phb.pdf">PDF
-version</ulink> is also available for download.
-</para>
-
-<para>
-A prerequisite for this document is a basic understanding on the work with
-&cvs;. Even though this document covers some of the more special topics of
-&cvs; in more detail it is not intended as an introduction to &cvs; in general.
-</para>
-</abstract>
-
-<keywordset>
-<keyword>KDE</keyword>
-<keyword>KMyMoney</keyword>
-<keyword>kmymoney</keyword>
-<keyword>finance</keyword>
-<keyword>accounts</keyword>
-<keyword>accounting</keyword>
-<keyword>financial</keyword>
-</keywordset>
-
-</bookinfo>
-
-<!--
-<dedication>
-<para>
-The dedication will show up here!
-<para>
-</dedication>
-
--->
-
-<preface id="versionhistory">
-<title>History of this document</title>
-<para>
-This chapter contains a list of releases of this document. Each entry in this
-list contains a date, an author and a short description and possibly a
-release number.
-
-<variablelist>
-
-<varlistentry>
-<term>2001-11, Thomas Baumgart, Rev 0.1</term>
-<listitem>
-<itemizedlist>
-<listitem><para>
-Initial work on the project handbook goes back into November 2001.
-Unfortunately, the only history information is available in &cvs;.
-</para></listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-
-<varlistentry>
-<term>2005-09-18, Thomas Baumgart, Rev 1.0</term>
-<listitem>
-<itemizedlist>
-<listitem><para>Added chapter about <link linkend="translation">translation</link>
-provided by J. Rundholz.</para></listitem>
-<listitem><para>Added this version history</para></listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-
-<varlistentry>
-<term>2006-09-11, Thomas Baumgart, Rev 1.1</term>
-<listitem>
-<itemizedlist>
-<listitem><para>Added chapter about <link linkend="documentation">documentation</link>
-provided by Tom Browder.</para></listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-
-<varlistentry>
-<term>2008-01-31, Alvaro Soliverez, Rev 1.2</term>
-<listitem>
-<itemizedlist>
-<listitem><para>Added chapter about <link linkend="submissions">submissions</link></para></listitem>
-<listitem><para>Added chapter about <link linkend="settings">settings</link></para></listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-
-</variablelist>
-
-</para>
-</preface>
-&config-management;
-&release-management;
-&coding-standards;
-&creating-dialogs;
-&settings;
-&unit-test;
-&documentation;
-&submissions;
-&translation-hints;
-&error-management;
-&cvs-examples;
-&src-examples;
-&test-examples;
-&rpm-example;
-&licence;
-</book>
diff --git a/developer-doc/phb/kmymoney-developer.desktop b/developer-doc/phb/kmymoney-developer.desktop
deleted file mode 100644
index 6eb777c..0000000
--- a/developer-doc/phb/kmymoney-developer.desktop
+++ /dev/null
@@ -1,42 +0,0 @@
-[Desktop Entry]
-Name=KMyMoney developer handbook
-Name[ar]=كتيّب مطوّر أموالك
-Name[bs]=KMyMoney finansijski priručnik
-Name[ca]=Manual del desenvolupador de KMyMoney
-Name[ca at valencia]=Manual del desenvolupador de KMyMoney
-Name[da]=KMyMoney udviklerhåndbog
-Name[de]=KMyMoney-Entwicklerhandbuch
-Name[el]=Το εγχειρίδιο του προγραμματιστή του KMyMoney
-Name[en_GB]=KMyMoney developer handbook
-Name[es]=Manual para desarrolladores de KMyMoney
-Name[et]=KMyMoney arendaja käsiraamat
-Name[eu]=KMyMoney-ren garatzaileen eskuliburua
-Name[fi]=KMyMoney kehittäjän käsikirja
-Name[fr]=Manuel du développeur de KMyMoney
-Name[gl]=Manual do programador de KMyMoney
-Name[hu]=KMyMoney fejlesztői kézikönyv
-Name[it]=Manuale dello sviluppatore di KMyMoney
-Name[kk]=KMyMoney құрастырушысының анықтамасы
-Name[lt]=KMyMoney programuotojo vadovas
-Name[mr]=के-माय-मनी विकासकर्ता पुस्तिका
-Name[nds]=Programmschriever-Handbook för KMyMoney
-Name[nl]=Handleiding voor de ontwikkelaar van KMyMoney
-Name[pl]=Podręcznik programisty KMyMoney
-Name[pt]=Manual de desenvolvimento do KMyMoney
-Name[pt_BR]=Manual do desenvolvedor do KMyMoney
-Name[ro]=Manualul dezvoltatorilor KMyMoney
-Name[ru]=Руководство разработчика KMyMoney
-Name[sk]=Vývojárska príručka KMyMoney
-Name[sv]=KMyMoney utvecklarhandbok
-Name[tr]=KMyMoney geliştirici el kitabı
-Name[uk]=Підручник для розробників KMyMoney
-Name[x-test]=xxKMyMoney developer handbookxx
-Name[zh_CN]=KMyMoney 开发者手册
-Name[zh_TW]=KMyMoney 開發者手冊
-Icon=kmymoney
-Exec=kmymoney
-Categories=Qt;KDE;Office;ProjectManagement;
-X-DocPath=kmymoney-developer/index.html
-NoDisplay=true
-Terminal=false
-Type=Application
diff --git a/developer-doc/phb/licence.docbook b/developer-doc/phb/licence.docbook
deleted file mode 100644
index 5a35725..0000000
--- a/developer-doc/phb/licence.docbook
+++ /dev/null
@@ -1,21 +0,0 @@
-<appendix id="licence">
-<title>Licence</title>
-
-<para>
-This document is released under Free Documentation licence; the terms
-of this licence
-are detailed below.
-</para>
-
-<sect1 id="fdl-licence">
-<title>Free Documentation Licence</title>
-
-<para>
-<screen>
-&fdl-licence;
-</screen>
-</para>
-
-</sect1>
-</appendix>
-
diff --git a/developer-doc/phb/rel-mgmt.docbook b/developer-doc/phb/rel-mgmt.docbook
deleted file mode 100644
index 57f2626..0000000
--- a/developer-doc/phb/rel-mgmt.docbook
+++ /dev/null
@@ -1,864 +0,0 @@
-<chapter id="rel-mgmt">
-<title>Release Management</title>
-<para>
-At certain stages, the development team releases a version of &app;. The
-following chapters explain the steps that are performed during this process.
-</para>
-
-<sect1 id="create-new-source-version">
-<title>Creating a new source version</title>
-<para>
-The process of releasing a new version is to build a source tar-ball archive, verify
-that &app; can be built from it and upload it to the SourceForge File Release System.
-This chapter explains the steps of making sure that the version numbers are set
-correctly, creating the source tar-ball, tagging the repository etc.
-</para>
-
-<para>
-Note that in order to perform some of the functions associated with this procedure, you will need to:
- <orderedlist>
- <listitem><para>
- Obtain a userid by registering with Sourceforge; this userid is represented below as <your_sf_userid>
- </para></listitem>
- <listitem><para>
- Be registered as a &kappname; developer; this must be done by a project administrator, the names of which appear on the project home page on Sourceforge.
- </para></listitem>
- </orderedlist>
-</para>
-
-<para>
-The first few steps of the release process should be taken some time in advance of the anticipated release date, in order to give translators a chance to 'do their thing'. The length of time required will depend on how many translatable strings have been changed since the previous release, but something like two weeks for a minor release should suffice.
-<note>
-<para>
-The steps explained apply to both the development and the
-release branches. For convenience, the examples are based on the
-development branch.
-</para>
-</note>
-</para>
-
-<orderedlist>
-<listitem>
-<para>Determine the release number which will identify this release.
-</para>
-<para>
-Two types of versions can be created at this time: a <emphasis>follow-up</emphasis> release or a <emphasis>fresh stable</emphasis>
-release. The follow-up release is based on a previous release with the same major and minor release number. The fresh stable
-release starts a new major and minor release number pair. In the latter case, the major and minor release numbers on the
-development branch in CVS are also adjusted. More details below.
-</para>
-
-<para>
- <orderedlist>
- <listitem><para>
- For follow-up releases increase the micro-release-number by one since the last unstable/stable release.
- </para></listitem>
- <listitem><para>
- For a fresh stable release, increase the minor release number and set the micro-release number to 0.
- </para></listitem>
- </orderedlist>
-</para>
-</listitem>
-
-<listitem>
-<para>Create a new directory for this release
-</para>
-<para>
-Create a new directory specifically for the release process, something like /home/me/distkmm, which will ensure that the following steps are not contaminated by other, existing versions of &app;. From this directory, check out a copy of the app from the CVS branch which forms the basis of this release, e.g. for 0.8.2, the branch will be rel-0-8-branch. The checkout process will create a sub-directory called kmymoney. This is referred to subsequently as the TLD (top level directory).
-</para>
-</listitem>
-
-<listitem>
-<para>
-Update the text source file for translations.
-</para>
-<para> This is done from the TLD by running the command:
-
-<programlisting>
-<prompt>thb: ~> </prompt><userinput>make package-messages</userinput>
-</programlisting>
-</para>
-<para>
-This will create the file kmymoney.pot in TLD/po, and will merge all new and changed messages into the various translation files in the same directory. These files (kmymoney.pot and *.po) should be committed to the appropriate branch of CVS. Also, an announcement should be made on the translator's mailing list that these are ready for updating, and mentioning a date a few days before the proposed release date as a deadline for translations to be submitted.
-</para>
-<para>
-At this point also, a 'string freeze' for the base release should be declared on the developer's list. From now on until the release is complete, the only changes which should be committed to the CVS branch should be fixes which do not change translatable strings, and updated .po files submitted by translators.
-</para>
-<para>
-As each .po file is committed, it is desirable to update the translation statistics on the project web site. This can be performed with the command
- <programlisting>
- make message-stats | ssh <your_sf_userid>@user.sourceforge.net "cat > /home/groups/k/km/kmymoney/htdocs/translate-stable.xml"
- </programlisting>
-You should certainly make sure that this command is run at least once, after all .po files have been committed.
-</para>
-<para>
-Once the anticipated release date is reached, you should make sure that your sandbox is up-to-date. This is probably best achieved by deleting the directory created in step 2, and re-creating it by a full CVS checkout as described there.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Check that the version number is correct.
-</para>
-<para>
-In the TLD, check file configure.in.in for the correct version number. A line near the top should look like</para>
- <programlisting>AM_INIT_AUTOMAKE(kmymoney,0.8.3)</programlisting>
-<para>If the last digits don't match the release number, then change them and commit your change to the repository with the message 'Bumped to release x.y.z'.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Verify the libtool version number
-</para>
-<para>Visit all subdirectories that contain a shared library. In the TLD, issue the command
-<programlisting>find . -name Makefile.am -exec grep -H LIBVERSION= '{}' \;</programlisting>
-(Note that the space before the backslash is necessary.)
-For each match, check whether the code or interface of the shared library has been changed since the last release. If so, modify the LIBVERSION setting in each Makefile.am according to the following recipe, where the LIBVERSION setting controls the libtool versioning system for shared libraries. It is constructed out of the triplet CURRENT:REVISION:AGE.
-</para>
-<para>
- <orderedlist>
- <listitem><para>
- If the library source code has changed at all since the last
- release, then increment REVISION (`C:R:A' becomes `C:r+1:A').
- </para></listitem>
-
- <listitem><para>
- If any interfaces have been added, removed, or changed since the
- last update, increment CURRENT, and set REVISION to 0.
- </para></listitem>
-
- <listitem><para>
- If any interfaces have been added since the last public release,
- then increment AGE.
- </para></listitem>
-
- <listitem><para>
- If any interfaces have been removed since the last public release,
- then set AGE to 0.
- </para></listitem>
- </orderedlist>
-</para>
-
-<caution>
-<para>
-Make sure to modify the numbers in coordination with changes on the release- and development branch.
-It could well be, that the REVISION must be incremented more than 1 if it has been changed on the other branch as well.
-</para>
-</caution>
-</listitem>
-
-<listitem>
-<para>
-Perform an initial build of the application
-</para>
-<para>
-From the TLD, issue the commands:
-</para>
-
-<programlisting>
-<prompt>thb: ~> </prompt><userinput>make -f Makefile.dist release</userinput>
-<prompt>thb: ~> </prompt><userinput>./configure <any-options-you-need></userinput>
-<prompt>thb: ~> </prompt><userinput>make</userinput>
-</programlisting>
-<para>
-This will regenerate all files of the application and rebuild everything automatically.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Check the distribution
-</para>
-<para>
-Before doing this, check that all desktop files conform to the freedesktop specification. From the TLD, issue the following command:
-<programlisting>
-<prompt>thb: ~> </prompt><userinput>find ./kmymoney -name '*.desktop' -exec desktop-file-validate {} \;</userinput>
-</programlisting>
-N.B. Any errors in file x-kmymoney.desktop can be ignored since kde3 does not conform to the specification for this file type.
-</para>
-<para>
-Note: desktop-file-validate is part of the desktop-file-utils package, which may be installed from your distribution repository, or downloaded from
-<ulink url="http://www.freedesktop.org/wiki/Software/desktop-file-utils">http://www.freedesktop.org/wiki/Software/desktop-file-utils</ulink>
-</para>
-<para>
-Then, to check the distribution itself, from the TLD, run the command
-
-<programlisting>
-<prompt>thb: ~> </prompt><userinput>make distcheck</userinput>
-</programlisting>
-
-This will do the following things automatically and stop on any error:
-</para>
-
-<para>
-<orderedlist>
-<listitem><para>create a source tar-ball in tgz form</para></listitem>
-<listitem><para>unpack this source tar-ball in a separate directory</para></listitem>
-<listitem><para>run configure on the unpacked source tar-ball</para></listitem>
-<listitem><para>compile and link the configured package</para></listitem>
-<listitem><para>compile and link all testcases</para></listitem>
-<listitem><para>install the compiled program in a temp directory</para></listitem>
-<listitem><para>check that all files are installed</para></listitem>
-<listitem><para>uninstall the package from the temp space</para></listitem>
-<listitem><para>check that no files are left behind</para></listitem>
-</orderedlist>
-</para>
-
-<para>
-Make sure that everything builds correctly. If errors occur, correct them and
-rerun <command>make distcheck</command>. Once everything is ok, a respective message, that the tar-ball is
-ready for distribution is shown at the end of <command>make distcheck</command>.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Update the ChangeLog
-</para>
-<para>
-Add a line with the text
-<programlisting> * Released x.y.z
-</programlisting>
-to the ChangeLog file.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Commit changes to CVS
-</para>
-<para>
-Commit the updated ChangeLog file, and any Makefiles updated in step 5 to the CVS repository before you proceed with the next step. Use the message 'Released x.y.z'.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Tag the version on CVS
-</para>
-<para>From the TLD, issue the command 'cvs tag rel-x-y-z', where x-y-z is the release number with dots replaced by dashes.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Update and optimize the size of the tar-ball
-</para>
-<para>As the content has changed since the tar-ball was created in step 7, we need to re-create it. Create a more compressed version using the command:
-</para>
- <programlisting>
- <prompt>thb: ~> </prompt><userinput>make dist-bzip2</userinput>
- </programlisting>
-</listitem>
-
-<listitem>
-<para>Make a checksum of the tarball
-</para>
-<para>
-This can be done with the following command from the TLD
-</para>
- <programlisting>
- <prompt>thb: ~> </prompt><userinput>md5sum name-of-tarball.tar.bz2 >/home/me/somewheresafe</userinput>
- </programlisting>
-<para>This checksum may be used to verify downloaded files at a later stage, and may be added to sourceforge at some future time.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Create a Release Note and a release ChangeLog file.
-</para>
-<para> The former should contain a brief description of the release and any new features which have been added. The latter should be a tidied-up version of the application ChangeLog file, though any purely internal changes may be omitted.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Upload the tarball to Sourceforge's 'incoming' directory
-</para>
-<para>
-Upload the tar-ball (bz2-version) to ftp://anonymous:<your-email-address>@upload.sourceforge.net:incoming, making sure to use the binary transfer mode.
-</para>
-<para>
-For GUI users: <emphasis>anonymous</emphasis> is the user-name and
-<emphasis>your-email-address</emphasis> is the password.
-</para>
-<para>
-For command line FTP, from the TLD:
-<programlisting>
-<prompt>thb: </prompt><userinput>ftp</userinput>
-<prompt>ftp> </prompt><userinput>open upload.sourceforge.net</userinput>
-Connected to osdn.dl.sourceforge.net.
-<snip>
-<prompt>Name (upload.sourceforge.net:tonyb): </prompt><userinput>anonymous</userinput>
-331 Please specify the password.
-<prompt>Password:</prompt><userinput><your_sf_userid></userinput>
-230 Login successful.
-Remote system type is UNIX.
-Using binary mode to transfer files.
-<prompt>ftp> </prompt><userinput>cd /incoming</userinput>
-250 Directory successfully changed.
-<prompt>ftp> </prompt><userinput>binary</userinput>
-200 Switching to Binary mode.
-<prompt>ftp> </prompt><userinput>put name-of-tarball.tar.bz2</userinput>
-<prompt>ftp></prompt><userinput> quit</userinput>
-</programlisting>
-</para>
-</listitem>
-
-<listitem>
-<para>
-Move the tarball to the Sourceforge File Release System
-</para>
-<para>
-Next pull the uploaded file into the &app; section
-of the File Release System on SourceForge so that the file will be visible to everyone on the internet.
-To do that, load the following URL in your browser
-</para>
-<programlisting>
-https://sourceforge.net/project/admin/editpackages.php?group_id=4708
-</programlisting>
-<para>At the bottom of the page, click on the 'Edit releases' link. If the release (x.y.z) you've built doesn't appear in the list, go back a page and click on the 'Add release' link to add it, then return to 'Edit releases', then click the 'Edit this release' link for your release.</para>
-<para>In Step 1 of the page, set the status to Hidden for now, paste the Release Notes and ChangeLog into the appropriate boxes and Submit.</para>
-<para>In Step 2, select the kmymoney tarball file and Add.</para>
-<para>In Step 3, set Processor to 'platform-independent', File Type to 'source .bz2', and Submit.</para>
-<para/>
-</listitem>
-
-<listitem>
-<para>
-Activate tarball on Sourceforge
-</para>
-<para>Once you are happy that the tarball was uploaded okay, and the release announcements are all correct, enter the File Release system again, and set the status to Active.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Update bug lists
-</para>
-<para>If the ChangeLog indicates that any Sourceforge or KDE bugs have been fixed in this release, log on to the respective bug sites and ensure that they are marked as closed.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Announce the release
-</para>
-<para>
-(At this point, you may wish to wait a few hours to allow Sourceforge to populate its mirror sites, thus avoiding complaints to the mailing lists.)
-Announce the presence of the source tar-ball archive as described in
-<link linkend="announce-new-version">Announce new version</link>.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Prepare for next release
-</para>
-<para>
-Make sure that you increase the project version to the next version. This is derived as follows:
-</para>
-
-<para>
- <orderedlist>
- <listitem>
- <para>After a follow-up release, increase the micro-release-number by one, e.g. if the release you are currently working on is called 0.7.3 then set the release number to 0.7.4. </para>
- </listitem>
- <listitem>
- <para>After a fresh stable release, increase the minor release number and set the micro-release number to 0, e.g.if the release you are currently working on is called 0.6 then set the release number to 0.7.0. </para>
- </listitem>
- </orderedlist>
-</para>
-
-<para>
-Make the appropriate changes to configure.in.in as described in step 4 above.
-From the TLD, issue the commands:
-</para>
-
-<programlisting>
-<prompt>thb: ~> </prompt><userinput>make -f Makefile.dist</userinput>
-<prompt>thb: ~> </prompt><userinput>./configure <any-options-you-need></userinput>
-<prompt>thb: ~> </prompt><userinput>make</userinput>
-</programlisting>
-<para>
-This will regenerate all files of the application and rebuild everything.
-</para>
-<para>
-Finally, check in the updated configure.in.in to the CVS repository.
-</para>
-
-</listitem>
-
-</orderedlist>
-
-<note>
-<para>
-The version number in the sandbox is <emphasis>always</emphasis> the
-version number that is currently being developed (we're a little ahead of ourselves here).
-</para>
-</note>
-
-</sect1>
-
-
-<sect1 id="create-stable-procedure">
-<title>Creating a new stable version</title>
-<para>
-At a certain time in the project's development cycle, the configuration
-manager decides that a feature freeze is necessary to start a new stable
-version. The exact dates when this will happen are announced on the
-developers mailing list ahead of the event. When the time has come to
-freeze the features, a branch will be created as described in this
-section. From this time on, the stable release will only be changed to make
-the current features of the software more stable. New features are not
-introduced to the stable branch but can be developed on the main
-branch (unstable) in parallel.
-
-</para>
-
-<para>
-When the time has come to create a new stable branch, the following steps
-have to be performed.
-</para>
-
-<orderedlist>
-<listitem>
-<para>
-Run through all the steps explaind in <link linkend="create-stable-example">Creating a new version</link>.
-The version number used in this description for the stable version is 0.4. Follow the path
-for a fresh stable release.
-</para>
-</listitem>
-
-<listitem><para>
-Create a branch off of the tagged version. The branch name is build by appending
-the word <emphasis>-branch</emphasis> to the major- and
-minor-release number of the stable release version.
-
-For our example, the branch tag for versions 0.4 is
-<emphasis>rel-0-4-branch</emphasis>.
-A complete example with all &cvs; commands can be found
-<link linkend="create-stable-example">in the appendix</link>.
-</para></listitem>
-
-<listitem>
-<para>
-From this moment on, the developers working on versions 0.4.x must make
-sure, that they checkout or update their sandbox using the
-tag <emphasis>rel-0-4-branch</emphasis>. This gives them the head revisions of
-the files on the 0.4 branch. Omitting this tag information will leave
-them on the main branch. The main branch is reserved for the unstable
-versions. An example how to keep multiple branches on the same machine is
-presented in the <link linkend="multiple-branches">appendix</link>,
-
-<caution>
-<para>
-The developers really have to
-take care from this point on which version they are modifying in their
-sandbox. Besides that, it is the developers responsibility to make sure
-that bug-fixes are also implemented on the main-branch if applicable.
-</para>
-</caution>
-
-</para>
-
-<para>
-When fixes are applied to the branch, new versions can be created by
-incrementing the micro-release thus rel-0-4-1, rel-0-4-2 are the next
-tags on the release branch.
-</para>
-
-</listitem>
-</orderedlist>
-
-<note>
-<para>
-Since &cvs; does not allow periods inside a tag, we always replace periods
-(.) with dashes (-) inside a tag.
-</para>
-</note>
-
-<para>
-The following diagram shows the above example on two specifc files. Each
-node represented by an asterisk is labelled with it's revision number
-enclosed in parenthesis. If a node has one or more labels attached, then
-they are enclosed in brackets. Nodes may exist without a tag. Such
-revisions never went into a release neither stable nor unstable but are
-valid intermediate steps in the development of the file in question.
-</para>
-
-<example>
-<title>Revisions on the head of a stable branch</title>
-<para>
-The first file is changed rather often between the version tags. All tags
-are on different revisions of the file.
-</para>
-
-<programlisting>
-
-
- * (1.12) [rel-0-3-8]
- |
- * (1.13)
- |
- * (1.14) [rel-0-4]
- |\__________________________
- | \
- | |
- * (1.15) * (1.14.2.1) [rel-0-4-1]
- | |
- * (1.16) [rel-0-5-0] * (1.14.2.2) [rel-0-4-2]
-
- [HEAD] [rel-0-4-branch]
-
-
-</programlisting>
-
-<para>
-The second file is not changed at all between the version
-tags. Nevertheless, all tags are available even though now they are on
-the same revision 1.2.
-</para>
-
-<programlisting>
-
-
- * (1.2) [rel-0-3-8] [rel-0-4]
- | [rel-0-4-1] [rel-0-4-2] [rel-0-5-0]
- |\__________________________
- | \
- | |
-
- [HEAD] [rel-0-4-branch]
-
-
-</programlisting>
-
-</example>
-</sect1>
-
-
-
-
-<sect1 id="announce-new-version">
-<title>Announce a new version</title>
-<para>
-Once the file is visible on the internet, people need to be informed about the new
-release. Besides that, the project maintains certain pages, where information about the
-current release is kept. These pages need to be updated.
-</para>
-
-<sect2 id="announce-new-version-release-system">
-<title>Announce new version via File Release System</title>
-<para>
-The SourceForge File Release System allows to send a short mail about the release of a package to registered
-recipients. On the bottom of the page where the uploaded file is moved into the file space of &app; a checkbox
-can be activated to send out such a mail. This method should only be used for a new source tar-ball release.
-</para>
-</sect2>
-
-<sect2 id="update-web-sites">
-<title>Update information about release on web-sites</title>
-<para>
-Certain web-sites exist that keep version information about &app;. They need to be updated.
-<orderedlist>
-<listitem><para>
-The news system for &app; on SourceForge.net: Create a news entry on https://sourceforge.net/projects/kmymoney2.
-</para></listitem>
-
-<listitem><para>
-The &app; web-site at http://kmymoney.org/: Update all version info
-for the stable and development releases and update the links to the source tar-balls.
-</para></listitem>
-
-<listitem><para>
-The &app; web-site at http://www.kde-apps.arg/: Add the release notes and update the version and minimum requirements.
-</para></listitem>
-
-<listitem><para>
-The &app; web-site at http://kmymoney.org/: Update the links to the latest stable and development release.
-If you created a fresh stable release, comment the development release entry.
-</para></listitem>
-</orderedlist>
-</para>
-</sect2>
-
-<sect2 id="announce-new-version-mail">
-<title>Announce new version on mailing lists</title>
-<para>
-Write a short mail and send it to the developer- and user-mailing list of the project, so that all subscribed
-recipients are informed about the new release. Add links to the project web-site and the www.kde-apps.org page
-of the project.
-</para>
-</sect2>
-
-</sect1>
-
-
-
-
-
-
-<sect1 id="create-new-bin-version">
-<title>Creating a new binary/installable version</title>
-<para>
-Additionally, installable binary versions of &app; should be provided. Since the installable binary
-files differ from distribution to distribution and the generation in general requires the
-target platform, the &app; project relies on the help of people not directly involved in
-the application development. We greatfully appreciate any help in this area.
-</para>
-
-<para>
-Multiple formats exist: RPM, DEB, e-builds, PKG just to name a few. Since the distro I use (SuSE) relies on
-RPMs, I explain the creation in more detail here. If you can provide similar information about other formats,
-we are more than happy to include it in this document. We assume that you follow our licence terms for any
-documentation you supply. Please send your docbook formatted files to the developer mailing list.
-</para>
-
-
-<sect2 id="rpm">
-<title>Creating an RPM file</title>
-<para>
-One possibility to distribute the program is to use the Red-Hat Package
-manager (RPM) format. In order to be able to create such a package for
-&app;, you need to have a source tar-ball as described in <link
-linkend="create-new-source-version">the previous chapter</link>.
-</para>
-
-<para>
-The RPM system uses a directory structure which
-for my system - a SuSE distribution - is located in /usr/src/packages. This
-may be different on your system. The location can be configured in
-/etc/rpmrc.
-I will refer to this directory as the 'RPM base directory' in the remainder
-of this document.
-</para>
-
-<para>
-The RPM base directory has a set of subdirectories. They all serve a
-specific purpose. For us, the directories SOURCES, SPECS, SRPMS and RPMS
-are important. RPMS is further divided into directories for specific
-CPU architectures (e.g. i386, i486, ppc, etc.). In the remainder of this
-document, I will use the names of these directories without mentioning
-the RPM base directory.
-</para>
-</sect2>
-
-<sect2 id="rpm-tar-ball">
-<title>Copying the tar-ball to the RPM structure</title>
-<para>
-The first thing that needs to be done is to copy the tar-ball to a defined
-place where the RPM tool will look for it. For this purpose the SOURCES
-directory is used. Move or copy your <link
-linkend="create-new-source-version">tar-ball</link> to this directory.
-</para>
-</sect2>
-
-<sect2 id="rpm-test-building">
-<title>Test building</title>
-<para>
-<!-- taken from RPM Howto (start) -->
- The first thing you'll probably want to do is get the source to build
- cleanly without using RPM. To do this, unpack the sources, and change
- the directory name to $NAME.orig. Then unpack the source again. Use
- this source to build from. Go into the source directory and follow the
- instructions to build it. If you have to edit things, you'll need a
- patch. Once you get it to build, clean the source directory. Make sure
- and remove any files that get made from a configure script. Then cd
- back out of the source directory to its parent. Then you'll do
- something like:
-
-<programlisting>
-
- <prompt>thb:~> </prompt><userinput>diff -uNr dirname.orig dirname > ../SOURCES/dirname-distroname.patch</userinput>
-
-
-</programlisting>
-
- This will create a patch for you that you can use in your spec file.
- Note that the "distro-name" that you see in the patch name is just an
- identifier. You might want to use something more descriptive like
- "MDK9" or "RPM8" to describe why you had to make a patch. It's also
- a good idea to look at the patch file you are creating before using it
- to make sure no binaries were included by accident.
-<!-- taken from RPM Howto (end) -->
-<note>
-<para>
-This section has been copied from the RPM-Howto and adapted where necessary
-</para>
-</note>
-</para>
-</sect2>
-
-<sect2 id="rpm-specfile">
-<title>Setting up the SPEC file</title>
-<para>
-The next step is to create an RPM SPEC file for the specific distribution.
-The contents may vary between distribution and that is where your knowledge
-is required. An example for an RPM SPEC file is contained in appendix ??.
-It will work on SuSE 8.1 directly. More details on howto setup a SPEC file
-including an explanation of the various sections, commands and options is
-contained in the RPM-Howto.
-</para>
-</sect2>
-
-<sect2 id="rpm-build-package">
-<title>Building the package</title>
-<para>
-Once you have the spec file it's time to try and build your package. The
-usual way to do this is using the following command:
-
-
-<programlisting>
-
- <prompt>thb:~> </prompt><userinput>rpmbuild -ba kmymoney.spec</userinput>
-
-
-</programlisting>
-
-Once the command finishes successfully, you have a source RPM in SRPMS and
-a binary RPM for your distribution in one of the subdirectories of RPMS.
-<note>
-<para>
-More details about this process and a description on the available options
-can be found in the RPM-Howto.
-</para>
-</note>
-</para>
-</sect2>
-
-<sect2 id="rpm-test">
-<title>Testing the package</title>
-<para>
-<!-- taken from RPM Howto (start) -->
- Once you have a source and binary rpm for your package, you need to
- test it. The easiest and best way is to use a totally different
- machine from the one you are building on to test. After all, you've
- just done a lot of make install's on your own machine, so it should be
- installed fairly well.
-</para>
-
-<para>
- You can do an rpm -e packagename on the package to test, but that can
- be deceiving because in building the package, you did a make install.
- If you left something out of your file list, it will not get
- uninstalled. You'll then reinstall the binary package and your system
- will be complete again, but your rpm still isn't. Make sure and keep
- in mind that just because you do a rpm -ba package, most people
- installing your package will just be doing the rpm -i package. Make
- sure you don't do anything in the build or install sections that will
- need to be done when the binaries are installed by themselves.
-<!-- taken from RPM Howto (end) -->
-
-<note>
-<para>
-This section has been copied from the RPM-Howto and adapted where necessary
-</para>
-</note>
-</para>
-</sect2>
-
-<sect2 id="rpm-sign">
-<title>Signing the package</title>
-<para>
-Once you are confident with the RPM package, it is a good idea to sign it
-with your secret &GPG; key before you distribute it. Signing the package
-allows any recipient of the package to verify that it has not been altered
-by an unauthorized party.
-</para>
-
-<para>
- Signing will create a
-separate file that contains the electronic signature for the RPM file.
-In order to allow any
-recipient to verify the signature, two things have to be kept in mind:
-
-<itemizedlist>
-<listitem>
- <para>Always distribute both files together</para>
-</listitem>
-<listitem>
- <para>
- Make your public key available on e.g.
- <ulink url="http://www.keyserver.net/">http://www.keyserver.net</ulink>.
- </para></listitem>
-</itemizedlist>
-
-The following example shows the command sequence necessary to create an
-ASCII armored signature.
-</para>
-
-<para>
-<programlisting>
-
-
- <prompt>thb:~> </prompt><userinput>gpg -b -a kmymoney2-0.5.1-1.i386.rpm</userinput>
- You need a passphrase to unlock the secret key for
- user: "Thomas Baumgart <thb at net-bembel.de>"
- 1024-bit DSA key, ID B75DD3BA, created 2001-06-23
-
- Enter passphrase: <userinput>I WON'T TELL YOU MY PASSPHRASE ;-)</userinput>
- <prompt>thb:~> </prompt><userinput></userinput>
-
-
-</programlisting>
-</para>
-
-<para>
-Once you have entered the correct passphrase the signature file will be
-created under the name kmymoney2-0.5.1-1.i386.rpm.asc. As an example, I
-include it here. <command>THIS IS NOT THE REAL SIGNATURE, EVEN IF IT LOOKS LIKE
-IT</command>.
-</para>
-
-<para>
-<programlisting>
-
- -----BEGIN PGP SIGNATURE-----
- Version: GnuPG v1.0.7 (GNU/Linux)
-
- iD8DBQA+E1DInFnbQLdd07oRAmFQAKDV0I9nzxGEIh1Mx/tzoZ4J3Iyt6gCfTXl1
- LrISXXgD6xELWZlO+NsWbLw=
- =qJIP
- -----END PGP SIGNATURE-----
-
-</programlisting>
-</para>
-
-<para>
-These two files, the RPM and the signature, should be distributed to
-the public. The receiver of these
-two files can now verify if the RPM file is the one you signed or has been
-modified. Therefor, he needs your public key which he gets from one of the
-public key servers (e.g. <ulink
-url="http://www.keyserver.net/">http://www.keyserver.net</ulink>) into his
-keyring. The verification is performed using &GPG; as the following example
-shows:
-</para>
-
-
-<para>
-<programlisting>
-
-
- <prompt>thb:~> </prompt><userinput>gpg --verify kmymoney2-0.5.1-1.i386.rpm.asc</userinput>
- gpg: Signature made Wed 01 Jan 2003 09:16:37 PM CET using DSA key ID B75DD3BA
- gpg: Good signature from "Thomas Baumgart <thb at net-bembel.de>"
- <prompt>thb:~> </prompt><userinput></userinput>
-
-
-</programlisting>
-
-<note>
-<para>
-Besides signing the RPM package, the SRPM (Source-RPM) package should be
-signed as well.
-</para>
-</note>
-</para>
-</sect2>
-
-</sect1>
-</chapter>
diff --git a/developer-doc/phb/rpm-example.docbook b/developer-doc/phb/rpm-example.docbook
deleted file mode 100644
index a45ff52..0000000
--- a/developer-doc/phb/rpm-example.docbook
+++ /dev/null
@@ -1,281 +0,0 @@
-<appendix id="rpm-example">
-<title>RPM SPEC file example</title>
-<para>
-This appendix contains an example of an RPM SPEC file.
-</para>
-
-<programlisting>
-
-#
-# spec file for package kmymoney
-#
-# Copyright (c) 2002,2003,2004,2005 Thomas Baumgart
-# This file and all modifications and additions to the pristine
-# package are under the same license as the package itself.
-#
-# please send bugfixes or comments to kmymoney2-developer at lists.sourceforge.net
-#
-
-%define is_mandrake %(test -e /etc/mandrake-release && echo 1 || echo 0)
-%define is_suse %(test -e /etc/SuSE-release && echo 1 || echo 0)
-%define is_fedora %(test -e /etc/fedora-release && echo 1 || echo 0)
-
-%define dist redhat
-%define disttag rh
-
-%if %is_mandrake
-%define dist mandrake
-%define disttag mdk
-%endif
-%if %is_suse
-%define dist suse
-%define disttag suse
-%define kde_path /opt/kde3
-%endif
-%if %is_fedora
-%define dist fedora
-%define disttag rhfc
-%endif
-
-%define _bindir %kde_path/bin
-%define _datadir %kde_path/share
-%define _iconsdir %_datadir/icons
-%define _docdir %_datadir/doc
-%define _localedir %_datadir/locale
-%define qt_path /usr/lib/qt3
-
-%define distver %(release="`rpm -q --queryformat='%{VERSION}' %{dist}-release 2> /dev/null | tr . : | sed s/://g`" ; if test $? != 0 ; then release="" ; fi ; echo "$release")
-%define distlibsuffix %(%_bindir/kde-config --libsuffix 2>/dev/null)
-%define _lib lib%distlibsuffix
-%define packer %(finger -lp `echo "$USER"` | head -n 1 | cut -d: -f 3)
-
-Name: kmymoney
-Icon: kmymoney.xpm
-Summary: The Personal Finances Manager for KDE.
-Version: 0.8
-Release: 1.%{disttag}%{distver}
-License: GPL
-Vendor: The KMyMoney development team <kmymoney2-developers at lists.sourceforge.net>
-Packager: %packer
-Group: Productivity/Office/Finance
-Source0: %{name}2-%version.tar.bz2
-BuildRoot: %{_tmppath}/%{name}2-%{version}-%{release}-build
-BuildRequires: kdebase3-devel
-Prereq: /sbin/ldconfig
-
-%description
-KMyMoney is the Personal Finance Manager for the KDE environment.
-It provides the functions required to balance your checkbooks,
-manage your personal accounts, investments, loans and
-categorise your incomes and expenses.
-
-For the most up-to-date information and sources please
-visit the project web-site at http://kmymoney.org/.
-
-To stay informed about new releases and other user related topics,
-please register with the KMyMoney User Mailinglist. It's a low volume
-mailing list. More information how to register can be found on the
-projects's web-site.
-
-%package devel
-#Requires:
-Summary: KMyMoney development files
-Group: Productivity/Office/Finance
-Provides: kmymoney-devel
-
-%description devel
-This package contains necessary header files for KMyMoney development.
-
-This package is necessary to compile plugins for KMyMoney.
-
-%package ofx
-Requires: kmymoney
-Summary: KMyMoney OFX plugin
-Group: Productivity/Office/Finance
-Provides: kmymoney-ofx
-
-%description ofx
-This package contains necessary files for the KMyMoney OFX plugin.
-
-
-%prep
-#echo %_target
-#echo %_target_alias
-#echo %_target_cpu
-#echo %_target_os
-#echo %_target_vendor
-echo Building %{name}-%{version}-%{release}
-
-%setup -q -n %{name}2-%{version}
-
-%build
-CFLAGS="%optflags" CXXFLAGS="%{optflags}" \
- ./configure --mandir=%{_mandir}\
- --disable-rpath \
- --with-xinerama \
- --without-gl \
- --disable-debug \
- --disable-cppunit \
- --enable-final
-
-make
-
-%install
-make DESTDIR=%buildroot install
-
-%clean
-[ ${RPM_BUILD_ROOT} != "/" ] && rm -rf ${RPM_BUILD_ROOT}
-
-%post
-cd %_docdir/HTML/*/%{name}2
-ln -s ../common common
-/sbin/ldconfig
-
-%postun
-/sbin/ldconfig
-
-%files
-%defattr(-,root,root)
-
-%dir %_docdir/HTML/en/%{name}2/
-%doc %_docdir/HTML/*/%{name}2/*.docbook
-%doc %_docdir/HTML/*/%{name}2/*.png
-%doc %_docdir/HTML/*/%{name}2/index.cache.bz2
-
-# the binary files
-%{_bindir}/%{name}
-%{_bindir}/%{name}2
-
-# the shared libraries
-%kde_path/%_lib/*.so.*.*.*
-
-#
-%dir %_datadir/apps/
-%dir %_datadir/apps/%{name}2/
-%dir %_datadir/apps/%{name}2/html
-%dir %_datadir/apps/%{name}2/templates
-%dir %_datadir/apps/%{name}2/templates/C
-%dir %_datadir/apps/%{name}2/templates/de_DE
-%dir %_datadir/apps/%{name}2/templates/en_GB
-%dir %_datadir/apps/%{name}2/templates/en_US
-%dir %_datadir/apps/%{name}2/templates/fr_FR
-%dir %_datadir/apps/%{name}2/templates/pt_BR
-%dir %_datadir/apps/%{name}2/templates/ru_SU
-%_datadir/apps/%{name}2/templates/README
-%_datadir/apps/%{name}2/templates/*/*.kmt
-
-%_datadir/apps/%{name}2/*rc
-%_datadir/apps/%{name}2/html/*
-%_datadir/apps/%{name}2/tips
-
-%dir %_datadir/apps/%{name}2/pics/
-%_datadir/apps/%{name}2/pics/*.png
-
-%dir %_datadir/apps/%{name}2/icons/
-%dir %_datadir/apps/%{name}2/icons/hicolor/
-%dir %_datadir/apps/%{name}2/icons/hicolor/16x16/
-%dir %_datadir/apps/%{name}2/icons/hicolor/16x16/actions/
-%dir %_datadir/apps/%{name}2/icons/hicolor/22x22/
-%dir %_datadir/apps/%{name}2/icons/hicolor/22x22/actions/
-%dir %_datadir/apps/%{name}2/icons/hicolor/32x32/
-%dir %_datadir/apps/%{name}2/icons/hicolor/32x32/apps
-%dir %_datadir/apps/%{name}2/icons/hicolor/48x48/
-%dir %_datadir/apps/%{name}2/icons/hicolor/48x48/apps
-%dir %_datadir/apps/%{name}2/icons/hicolor/64x64/
-%dir %_datadir/apps/%{name}2/icons/hicolor/64x64/apps
-%_datadir/apps/%{name}2/icons/hicolor/*/*/*.png
-
-#
-#
-%_datadir/applications/kde/kmymoney.desktop
-%_datadir/mimelnk/application/x-kmymoney.desktop
-%_datadir/servicetypes/*
-
-#
-#
-%_iconsdir/*/*/*/*.png
-
-#
-#
-%doc %_mandir/man1/kmymoney.1.gz
-
-#
-#
-%_localedir/*/*/*.mo
-
-
-# AqBanking plugin related files
-# %dir %_datadir/apps/kmm_kbanking/
-# %_datadir/apps/kmm_kbanking/*rc
-
-# plugin related files
-# %kde_path/%_lib/kde3/*.so
-
-
-
-
-%files ofx
-%_datadir/services/kmm_ofximport.desktop
-%kde_path/%_lib/kde3/kmm_ofximport.so
-
-
-%files devel
-%kde_path/include/kmymoney/*
-%kde_path/%_lib/*.la
-
-# plugin related files
-%kde_path/%_lib/kde3/*.la
-
-%changelog
-* Mon May 26 2005 - ipwizard (at) users.sourceforge.net
-- Added kmymoney-ofx package
-
-* Tue Mar 22 2005 - ipwizard (at) users.sourceforge.net
-- Added more template functionality to provide more
- distributions
-- Added kmymoney-devel package
-
-* Mon Jan 30 2005 - ipwizard (at) users.sourceforge.net
-- Started adding distro independant layout
-
-* Sat Oct 30 2004 - ipwizard (at) users.sourceforge.net
- * Preparations for 0.6.3
-
-* Thu Sep 23 2004 - ipwizard (at) users.sourceforge.net
- * Preparations for 0.6.2
-
-* Sat Jun 5 2004 - ipwizard (at) users.sourceforge.net
-- Preparations for 0.6
-
-* Thu Apr 22 2004 - ipwizard (at) users.sourceforge.net
-- Preparations for 0.6rc4
-
-* Fri Feb 20 2004 - ipwizard (at) users.sourceforge.net
-- Removed the standard directories
-- Uninstall the default account files also
-- Preparations for 0.6rc3
-
-* Thu Feb 5 2004 - ipwizard (at) users.sourceforge.net
-- Remove CVS directories from SRPMS
-- Preparations for 0.6rc2
-
-* Mon Dec 29 2003 - ipwizard (at) users.sourceforge.net
-- Preparations for 0.6rc1
-- Incorporated some changes from SuSE distro
-- added man page file
-
-* Thu Jan 9 2003 - ipwizard (at) users.sourcforge.net
-- Added missing files home.html and kmymoney.css
-
-* Mon Dec 16 2002 - ipwizard (at) users.sourcforge.net
-- Removed make command only required for CVS download
-- Update version to match filename
-
-* Sun Dec 15 2002 - ipwizard (at) users.sourcforge.net
-- Updated for version 0.51
-
-* Tue Jan 15 2002 - ipwizard (at) users.sourcforge.net
-- Initial implementation
-
-</programlisting>
-</appendix>
diff --git a/developer-doc/phb/settings.docbook b/developer-doc/phb/settings.docbook
deleted file mode 100644
index 31985d0..0000000
--- a/developer-doc/phb/settings.docbook
+++ /dev/null
@@ -1,109 +0,0 @@
-<chapter id="settings">
-<chapterinfo>
-<authorgroup>
-<author>
- <firstname>Alvaro</firstname>
- <surname>Soliverez</surname>
- <affiliation>
- <address><email>asoliverez at gmail.com</email></address>
- </affiliation>
-</author>
-</authorgroup>
-</chapterinfo>
-<title>Settings</title>
-
-<sect1 id="settings-page">
-<title>How to create a settings page</title>
-
-<itemizedlist>
-<listitem>
-<para>
-Create the view using designer, name it XxxDecl and store it in <filename>kmymoney/dialogs/settings/xxxdecl.ui</filename>. See more information about naming the items further down
-</para>
-</listitem>
-<listitem>
-<para>
-Create the class that contains the logic for the settings page, name it Xxx and store it in <filename>kmymoney/dialogs/settings/xxx.[cpp|h]</filename>.
-</para>
-<para>
-Don't forget the Q_OBJECT macro at the beginning of the class declaration in the .h file and make the class a public derivative of XxxDecl
-</para>
-</listitem>
-<listitem>
-<para>
-Add the xxxdecl.ui and xxx.cpp filename to the libsettings_a_SOURCES label in <filename>kmymoney/dialogs/settings/Makefile.am</filename>
-</para>
-</listitem>
-<listitem>
-<para>
-Add the xxxdecl.ui filename to the EXTRA_DIST label in <filename>kmymoney/dialogs/settings/Makefile.am</filename>
-</para>
-</listitem>
-<listitem>
-<para>
-Add the xxxdecl.cpp and xxxdecl.h filename to the DISTCLEANFILES label in <filename>kmymoney/dialogs/settings/Makefile.am</filename>
-</para>
-</listitem>
-<listitem>
-<para>
-Add the xxx.h filename to the noinst_HEADERS label in <filename>kmymoney/dialogs/settings/Makefile.am</filename>
-</para>
-</listitem>
-<listitem>
-<para>
-Add the construction code to KMyMoney2App::slotSettings() as
-</para>
-<screen>
-Xxx* xxxPage = new Xxx();
-dlg->addPage(xxxPage, i18n("text"), "icon-name");
-</screen>
-<para>
-where you replace "text" with a short text that shows up under the icon in the settings view and "icon-name" with the name of the icon for that settings page
-</para>
-</listitem>
-<listitem>
-<para>
-Make sure to include xxx.h in <filename>kmymoney/kmymoney.cpp</filename>
-</para>
-</listitem>
-</itemizedlist>
-</sect1>
-
-<sect1 id="settings-items">
-<title>How to add the setting items</title>
-
-<para>
-For auto-generation of setter/getter code of your options, you have to follow certain rules. For each setting item you need an entry in <filename>kmymoney/kmymoney.kcfg</filename>. This is an XML formatted file. The contents of the 'name' attribute will be used as method for the C++-code, eg. a name of "AutoSavePeriod" for an integer parameter results in a setter and getter named
-</para>
-<screen>
-void KMyMoneySettings::setAutoSavePeriod(int)
-int KMyMoneySettings::autoSavePeriod(void)
-</screen>
-<para>
-You should not access those functions directly from within your code but rather use the KMyMoneyGlobalSettings class which contains the same interface as KMyMoneySettings with some additional functionality.
-</para>
-
-<para>
-When you name the GUI widget that controls the setting for this parameter make sure to name it "kcfg_AutoSavePeriod", that is "kcfg_" prepended with the name used in <filename>kmymoney/kmymoney.kcfg</filename>.
-</para>
-
-<para>
-That should be it.
-</para>
-</sect1>
-
-<sect1 id="settings-reference">
-<title>References</title>
-
-<para>
-A more complete - but generic version - can be found on <ulink url="http://techbase.kde.org/Development/Tutorials/Using_KConfig_XT">http://techbase.kde.org/Development/Tutorials/Using_KConfig_XT</ulink> . Currently, &app; does not use the <filename>CMakeLists.txt</filename> file but the above mentioned <filename>Makefile.am</filename> approach. You can safely skip the section about CMakeLists.txt.
-</para>
-</sect1>
-
-<sect1 id="settings-hints">
-<title>Hints</title>
-<para>
-If you run a make 'too early' it could be, that certain entries for the Makefile are not setup correctly and the compiler will complain. In this case, try to run a 'make -f Makefile.dist' followed by './configure' and see if the problem goes away.
-</para>
-</sect1>
-</chapter>
diff --git a/developer-doc/phb/src-examples.docbook b/developer-doc/phb/src-examples.docbook
deleted file mode 100644
index 6b4cc2a..0000000
--- a/developer-doc/phb/src-examples.docbook
+++ /dev/null
@@ -1,550 +0,0 @@
-<appendix id="src-examples">
-<title>Source and Header Examples</title>
-<para>
-This appendix contains an example of a
-<link linkend="header-example">header file listing</link> and a
-<link linkend="source-example">source file listing</link>.
-</para>
-
-<section id="header-example">
-<title>Header File Example</title>
-<screen>
-
-/***************************************************************************
- ksettingsdlg.h
- -------------------
- copyright : (C) 2000,2001 by Michael Edwardes
- email : mte at users.sourceforge.net
- ***************************************************************************/
-
-/***************************************************************************
- * *
- * This program is free software; you can redistribute it and/or modify *
- * it under the terms of the GNU General Public License as published by *
- * the Free Software Foundation; either version 2 of the License, or *
- * (at your option) any later version. *
- * *
- ***************************************************************************/
-#ifndef KSETTINGSDLG_H
-#define KSETTINGSDLG_H
-
-// ----------------------------------------------------------------------------
-// QT Includes
-#include <qcheckbox.h>
-#include <qradiobutton.h>
-#include <qbuttongroup.h>
-#include <qcolor.h>
-#include <qfont.h>
-
-// ----------------------------------------------------------------------------
-// KDE Includes
-#include <kdialogbase.h>
-#include <kfontdialog.h>
-#include <kcolorbutton.h>
-#include <klineedit.h>
-
-// ----------------------------------------------------------------------------
-// Project Includes
-
-/**
- * This class is used to manipulate all the settings available for
- * KMyMoney. It currently stores the values for the list settings
- * and whether to show the start dialog when KMyMoney starts.
- *
- * It uses KDialogBase to implement it's interface.
- *
- * It uses the global KConfig object to read and write the application
- * settings.
- *
- * @see KDialogBase
- *
- * @author Michael Edwardes 2000-2001
- * $Id: src-examples.docbook,v 1.3 2005/05/27 19:05:18 ipwizard Exp $
- *
- * @short A class to manipulate the settings needed for running KMyMoney
-**/
-class KSettingsDlg : public KDialogBase {
- Q_OBJECT
-
-private:
- /** Start prompt dialog */
- QRadioButton *m_qradiobuttonStartPrompt;
- /** Start file */
- QRadioButton *m_qradiobuttonStartFile;
- /** Color list */
- KColorButton *m_kcolorbuttonList;
- /** Color background */
- KColorButton *m_kcolorbuttonBack;
- /** Select font header */
- KFontChooser *m_kfontchooserHeader;
- /** Font cell setting */
- KFontChooser *m_kfontchooserCell;
-
- /** No rows to show in register */
- KLineEdit *m_klineeditRowCount;
-
- /** Show grid in register ? */
- QCheckBox *m_qcheckboxShowGrid;
-
- QRadioButton *m_qradiobuttonPerTransaction;
- QRadioButton *m_qradiobuttonOtherRow;
-
- /** Set page general */
- void setPageGeneral();
- /** Set page list settings */
- void setPageList();
- /** Write settings */
- void configWrite();
- /** Read settings */
- void configRead();
-
- /** Attributes to store the variables so they can be undone when
- * cancelling the apply.
- **/
- QColor m_qcolorTempList;
- QColor m_qcolorTempListBG;
- QFont m_qfontTempHeader;
- QFont m_qfontTempCell;
- QString m_qstringTempRowCount;
- bool m_bTempShowGrid;
- bool m_bTempColourPerTransaction;
- bool m_bTempStartPrompt;
- bool m_bDoneApply;
-
-
-private slots:
- /** Called when OK pressed */
- void slotOk();
-
- /** Called when Apply pressed */
- void slotApply();
-
- /** Called when Cancel pressed */
- void slotCancel();
-
- /** Called when Reset pressed */
- void slotUser1();
-
-public:
- /**
- * Standard constructor.
- *
- * @param parent The QWidget this is used in.
- * @param name The QT name.
- * @param modal True if we want the dialog to be application modal.
- *
- * @return An object of type KSettingsDlg.
- *
- * @see ~KSettingsDlg
- **/
- KSettingsDlg(QWidget *parent=0, const char *name=0, bool modal=true);
-
- /**
- * Standard destructor.
- *
- * @return Nothing.
- *
- * @see KSettingsDlg
- **/
- ~KSettingsDlg();
-
-signals:
- /**
- * Emitted when the Apply button is clicked to allow the application to
- * show the changes without having to close the dialog.
- *
- * @return Nothing
- **/
- void signalApply();
-};
-
-#endif
-</screen>
-</section>
-
-<section id="source-example">
-<title>Source File Example</title>
-
-<screen>
-/***************************************************************************
- ksettingsdlg.cpp
- -------------------
- copyright : (C) 2000,2001 by Michael Edwardes
- email : mte at users.sourceforge.net
- ***************************************************************************/
-
-/***************************************************************************
- * *
- * This program is free software; you can redistribute it and/or modify
- * *
- * it under the terms of the GNU General Public License as published by
- * *
- * the Free Software Foundation; either version 2 of the License, or
- * *
- * (at your option) any later version.
- * *
- * *
- ***************************************************************************/
-
-// ----------------------------------------------------------------------------
-// QT Includes
-#include <qlayout.h>
-#include <qvbox.h>
-#include <qlabel.h>
-#include <qgroupbox.h>
-#include <qtabwidget.h>
-#include <qvalidator.h>
-
-// ----------------------------------------------------------------------------
-// KDE Includes
-#include <klocale.h>
-#include <kstddirs.h>
-#include <kiconloader.h>
-#include <kconfig.h>
-#include <kcolorbutton.h>
-#include <kmessagebox.h>
-
-// ----------------------------------------------------------------------------
-// Project Includes
-#include "ksettingsdlg.h"
-
-/** Standard constructor for the class.
- * The constructor passes some additional parameters to the base class
- * KDialogBase
- * to set the buttons to be showed and the type of dialog to be shown.
-**/
-KSettingsDlg::KSettingsDlg(QWidget *parent, const char *name, bool modal)
- : KDialogBase(IconList, i18n("Configure"), Ok|Cancel|Apply|User1, Ok, parent,
- name, modal, true, i18n("&Reset"))
-{
- // Setup the pages and then read the configuration object.
- setPageGeneral();
- setPageList();
- configRead();
- m_bDoneApply=false;
-}
-
-/** Standard destructor for the class.
-**/
-KSettingsDlg::~KSettingsDlg()
-{
-}
-
-/** Called to create the General page to be shown in the dialog.
-**/
-void KSettingsDlg::setPageGeneral()
-{
- // Create the main frame to hold the widgets
- QVBox *qvboxMainFrame = addVBoxPage( i18n("General"), i18n("General settings"),
- DesktopIcon("misc"));
-
- // Create a group box to hold the available options
- QButtonGroup *qbuttongroup = new QButtonGroup(qvboxMainFrame, "GroupBox1");
- qbuttongroup->setTitle( i18n( "Startup options" ) );
- qbuttongroup->setColumnLayout(0, Qt::Vertical );
- qbuttongroup->layout()->setSpacing( 0 );
- qbuttongroup->layout()->setMargin( 0 );
-
- // Create a layout to organize the widgets.
- QVBoxLayout *qvboxlayout = new QVBoxLayout(qbuttongroup->layout());
- qvboxlayout->setAlignment( Qt::AlignTop );
- qvboxlayout->setSpacing( 6 );
- qvboxlayout->setMargin( 11 );
-
- // Create a check box to be in the group box
- m_qradiobuttonStartPrompt = new QRadioButton("start_prompt", qbuttongroup);
- m_qradiobuttonStartPrompt->setText( i18n( "Start with dialog prompt (default)" ) );
- qvboxlayout->addWidget(m_qradiobuttonStartPrompt);
-
- // Create another check box to the group box
- m_qradiobuttonStartFile = new QRadioButton("start_file", qbuttongroup);
- m_qradiobuttonStartFile->setText( i18n( "Start with last file used" ) );
- qvboxlayout->addWidget(m_qradiobuttonStartFile);
-}
-
-/** Called to create the Main List page shown in the dialog.
-**/
-void KSettingsDlg::setPageList()
-{
- // Create the page.
- QVBox *qvboxMainFrame = addVBoxPage( i18n("Main List"), i18n("List settings"),
- locate("appdata", "pics/setting_list.png"));
-
- // Create the tab widget
- QTabWidget *qtabwidget = new QTabWidget(qvboxMainFrame, "TabWidget2");
-
- // Create the first page
- QWidget *qwidgetPage = new QWidget(this);
-
- // Create the layout for the page
- QVBoxLayout *qvboxlayoutPage = new QVBoxLayout(qwidgetPage);
- qvboxlayoutPage->setSpacing( 6 );
- qvboxlayoutPage->setMargin( 11 );
-
- // Create a horizontal layout to hold two widgets
- QHBoxLayout *qhboxlayout = new QHBoxLayout;
- qhboxlayout->setSpacing( 6 );
- qhboxlayout->setMargin( 0 );
-
- // Create the first widget
- QLabel *qlabel = new QLabel(i18n("Number of lines in the register view:"),
- qwidgetPage);
- qhboxlayout->addWidget(qlabel);
-
- // Create the second widget
- m_klineeditRowCount = new KLineEdit(qwidgetPage);
- QIntValidator *qintvalidator = new QIntValidator(1, 3, m_klineeditRowCount);
- m_klineeditRowCount->setValidator(qintvalidator);
- qhboxlayout->addWidget(m_klineeditRowCount);
-
- // Add the horizontal layout
- qvboxlayoutPage->addLayout(qhboxlayout);
-
- // Ceate another widget
- m_qcheckboxShowGrid = new QCheckBox(i18n("Show a grid in the register view"),
- qwidgetPage);
- qvboxlayoutPage->addWidget(m_qcheckboxShowGrid);
-
- // Create a group to hold two radio buttons
- QButtonGroup *qbuttongroup = new QButtonGroup(qwidgetPage, "ButtonGroup1");
- qbuttongroup->setTitle(i18n("Row Colour options"));
- qbuttongroup->setColumnLayout(0, Qt::Vertical );
- qbuttongroup->layout()->setSpacing( 0 );
- qbuttongroup->layout()->setMargin( 0 );
-
- // Create a layout
- QVBoxLayout *qvboxlayout = new QVBoxLayout(qbuttongroup->layout());
- qvboxlayout->setAlignment( Qt::AlignTop );
- qvboxlayout->setSpacing( 6 );
- qvboxlayout->setMargin( 11 );
-
- // Add the first radio button
- m_qradiobuttonPerTransaction = new QRadioButton(qbuttongroup, "m_per_trans");
- m_qradiobuttonPerTransaction->setText( i18n("Use one colour per transaction") );
- qvboxlayout->addWidget(m_qradiobuttonPerTransaction);
-
- // Add the second radio button
- m_qradiobuttonOtherRow = new QRadioButton(qbuttongroup, "m_every_other");
- m_qradiobuttonOtherRow->setText( i18n( "Change colour every other row" ));
- qvboxlayout->addWidget(m_qradiobuttonOtherRow);
- qvboxlayoutPage->addWidget(qbuttongroup);
-
- // Add a vertical spacer to take up the remaining available space
- QSpacerItem* spacer = new QSpacerItem( 20, 20, QSizePolicy::Minimum,
- QSizePolicy::Expanding );
- qvboxlayoutPage->addItem( spacer );
-
- // Add the page to the tab
- qtabwidget->insertTab(qwidgetPage, i18n("General"));
-
- // Create a new tab for the colour options
- QWidget *qwidgetColour = new QWidget(qtabwidget, "tab");
-
- // Create a vertical layout
- QVBoxLayout *qvboxlayoutColour = new QVBoxLayout(qwidgetColour);
- qvboxlayoutColour->setSpacing( 6 );
- qvboxlayoutColour->setMargin( 11 );
-
- // Create a horizontal layout to include the label and button
- QHBoxLayout *qhboxlayoutColour = new QHBoxLayout;
- qhboxlayoutColour->setSpacing( 6 );
- qhboxlayoutColour->setMargin( 0 );
-
- // Add the label and button
- QLabel *qlabelListColour = new QLabel(i18n( "List view colour :" ),
- qwidgetColour);
- qhboxlayoutColour->addWidget(qlabelListColour);
- m_kcolorbuttonList = new KColorButton(qwidgetColour, "colour_list");
- qhboxlayoutColour->addWidget(m_kcolorbuttonList);
-
- // Add the horizontal layout
- qvboxlayoutColour->addLayout(qhboxlayoutColour);
-
- // Create another horizontal layout to include the label and button
- QHBoxLayout *qhboxlayoutBGColour = new QHBoxLayout;
- qhboxlayoutBGColour->setSpacing( 6 );
- qhboxlayoutBGColour->setMargin( 0 );
-
- // Add the label and button
- QLabel *qlabelListBGColour = new QLabel(i18n( "List background colour :"),
- qwidgetColour);
- qhboxlayoutBGColour->addWidget(qlabelListBGColour);
- m_kcolorbuttonBack = new KColorButton(qwidgetColour, "colour_back");
- qhboxlayoutBGColour->addWidget(m_kcolorbuttonBack);
-
- // Add the horizontal layout
- qvboxlayoutColour->addLayout(qhboxlayoutBGColour);
-
- // Add a vertical spacer to take up the remaining available space
- QSpacerItem* qspaceritemColour = new QSpacerItem( 20, 20,
- QSizePolicy::Minimum, QSizePolicy::Expanding );
- qvboxlayoutColour->addItem( qspaceritemColour );
-
- // Add the page to the tab widget
- qtabwidget->insertTab(qwidgetColour, i18n( "Color"));
-
- // Create another tab adding a font chooser widget
- QVBox *qvboxInsideTab1 = new QVBox( this, "tab1" );
- qvboxInsideTab1->setSpacing( 6 );
- qvboxInsideTab1->setMargin( 11 );
- m_kfontchooserHeader = new KFontChooser(qvboxInsideTab1);
- qtabwidget->insertTab(qvboxInsideTab1, i18n("Header Font"));
-
- // Create another tab adding a font chooser widget
- QVBox *qvboxInsideTab2 = new QVBox( this, "tab2" );
- qvboxInsideTab2->setSpacing( 6 );
- qvboxInsideTab2->setMargin( 11 );
- m_kfontchooserCell = new KFontChooser(qvboxInsideTab2);
- qtabwidget->addTab(qvboxInsideTab2, i18n("Cell Font"));
-}
-
-/** Read all the settings in from the global KConfig object and set all the
- * widgets appropriately.
-**/
-void KSettingsDlg::configRead()
-{
- KConfig *kconfig = KGlobal::config();
- kconfig->setGroup("Settings Dialog");
- QSize *qsizeDefaultSize = new QSize(470,470);
- this->resize(kconfig->readSizeEntry("Geometry", qsizeDefaultSize));
-
- kconfig->setGroup("General Options");
- m_bTempStartPrompt = kconfig->readBoolEntry("StartDialog", true);
- m_qradiobuttonStartPrompt->setChecked(m_bTempStartPrompt);
- m_qradiobuttonStartFile->setChecked(!m_bTempStartPrompt);
-
- kconfig->setGroup("List Options");
-
- QFont qfontDefault = QFont("helvetica", 12);
- QColor qcolorDefault = Qt::white;
- QColor qcolorDefaultBG = Qt::gray;
-
- m_qcolorTempList = kconfig->readColorEntry("listColor", &qcolorDefault);
- m_kcolorbuttonList->setColor(m_qcolorTempList);
-
- m_qcolorTempListBG = kconfig->readColorEntry("listBGColor",
- &qcolorDefaultBG);
- m_kcolorbuttonBack->setColor(m_qcolorTempListBG);
-
- m_qfontTempHeader = kconfig->readFontEntry("listHeaderFont",
- &qfontDefault);
- m_kfontchooserHeader->setFont(m_qfontTempHeader);
-
- m_qfontTempCell = kconfig->readFontEntry("listCellFont", &qfontDefault);
- m_kfontchooserCell->setFont(m_qfontTempCell);
-
- m_qstringTempRowCount = kconfig->readEntry("RowCount", "2");
- m_klineeditRowCount->setText(m_qstringTempRowCount);
-
- m_bTempShowGrid = kconfig->readBoolEntry("ShowGrid", true);
- m_qcheckboxShowGrid->setChecked(m_bTempShowGrid);
-
- m_bTempColourPerTransaction =
- kconfig->readBoolEntry("ColourPerTransaction", true);
- m_qradiobuttonPerTransaction->setChecked(m_bTempColourPerTransaction);
- m_qradiobuttonOtherRow->setChecked(!m_bTempColourPerTransaction);
-}
-
-/** Write out all the settings to the global KConfig object.
-**/
-void KSettingsDlg::configWrite()
-{
- KConfig *kconfig = KGlobal::config();
- kconfig->setGroup("Settings Dialog");
- kconfig->writeEntry("Geometry", this->size() );
-
- kconfig->setGroup("List Options");
- kconfig->writeEntry("listColor", m_kcolorbuttonList->color());
- kconfig->writeEntry("listBGColor", m_kcolorbuttonBack->color());
- kconfig->writeEntry("listHeaderFont", m_kfontchooserHeader->font());
- kconfig->writeEntry("listCellFont", m_kfontchooserCell->font());
- kconfig->writeEntry("RowCount", m_klineeditRowCount->text());
- kconfig->writeEntry("ShowGrid", m_qcheckboxShowGrid->isChecked());
- kconfig->writeEntry("ColourPerTransaction",
- m_qradiobuttonPerTransaction->isChecked());
-
- kconfig->setGroup("General Options");
- kconfig->writeEntry("StartDialog",
- m_qradiobuttonStartPrompt->isChecked());
-
- kconfig->sync();
-}
-
-/** Called on OK being pressed */
-void KSettingsDlg::slotOk()
-{
- int nCount = m_klineeditRowCount->text().toInt();
- if (nCount <= 0 || nCount >= 4) {
- KMessageBox::information(this, i18n("The row count has to be between 1
-and 3"));
- m_klineeditRowCount->setFocus();
- return;
- }
- configWrite();
- this->accept();
-}
-
-/** Called on Apply being pressed */
-void KSettingsDlg::slotApply()
-{
- int nCount = m_klineeditRowCount->text().toInt();
- if (nCount <= 0 || nCount >= 4) {
- KMessageBox::information(this, i18n("The row count has to be between 1
-and 3"));
- m_klineeditRowCount->setFocus();
- return;
- }
- m_bDoneApply = true;
- configWrite();
- emit signalApply();
-}
-
-/** Called on Cancel being pressed.
- * It writes out all the original settings read when it was created.
-**/
-void KSettingsDlg::slotCancel()
-{
- // make sure the config object is the same as we left it
- KConfig *kconfig = KGlobal::config();
- kconfig->setGroup("List Options");
- kconfig->writeEntry("listColor", m_qcolorTempList);
- kconfig->writeEntry("listBGColor", m_qcolorTempListBG);
- kconfig->writeEntry("listHeaderFont", m_qfontTempHeader);
- kconfig->writeEntry("listCellFont", m_qfontTempCell);
- kconfig->writeEntry("RowCount", m_qstringTempRowCount);
- kconfig->writeEntry("ShowGrid", m_bTempShowGrid);
- kconfig->writeEntry("ColourPerTransaction", m_bTempColourPerTransaction);
-
- kconfig->setGroup("General Options");
- kconfig->writeEntry("StartDialog", m_bTempStartPrompt);
-
- kconfig->sync();
-
- if (m_bDoneApply)
- accept();
- else
- reject();
-}
-
-/** Called when the user presses the User1 button. In our case that is the
- * reset button.
- *
- * It just resets all the attributes to the values read on creation.
-**/
-void KSettingsDlg::slotUser1()
-{
- m_qradiobuttonStartPrompt->setChecked(m_bTempStartPrompt);
- m_kcolorbuttonList->setColor(m_qcolorTempList);
- m_kcolorbuttonBack->setColor(m_qcolorTempListBG);
- m_kfontchooserHeader->setFont(m_qfontTempHeader);
- m_kfontchooserCell->setFont(m_qfontTempCell);
- m_klineeditRowCount->setText(m_qstringTempRowCount);
- m_qcheckboxShowGrid->setChecked(m_bTempShowGrid);
- m_qradiobuttonPerTransaction->setChecked(m_bTempColourPerTransaction);
- m_qradiobuttonOtherRow->setChecked(!m_bTempColourPerTransaction);
-}
-
-</screen>
-
-</section>
-</appendix>
diff --git a/developer-doc/phb/submissions.docbook b/developer-doc/phb/submissions.docbook
deleted file mode 100644
index c18a56c..0000000
--- a/developer-doc/phb/submissions.docbook
+++ /dev/null
@@ -1,99 +0,0 @@
-<chapter id="submissions">
-<chapterinfo>
-<authorgroup>
-<author>
- <firstname>Alvaro</firstname>
- <surname>Soliverez</surname>
- <affiliation>
- <address><email>asoliverez at gmail.com</email></address>
- </affiliation>
-</author>
-</authorgroup>
-</chapterinfo>
-<title>Patch Submissions</title>
-<para>
-This section describes how to send patches and additions when you don't have direct CVS access. In that case, you should send the contributions to the developer mailing list. That way, more people can test your contribution than if you send it to a specific developer. It could also happen that this developer has a lot of pending stuff, and your contribution gets delayed.
-</para>
-
-<para>
-For the specifics on how to code, translate or write documentation, refer to the proper sections. Once you are done with the actual work, you have to create the patch file to send.
-</para>
-
-<sect1 id="patch">
-<title>Steps to create a patch</title>
-<para>
-Keep in mind that there are times when all developers have plenty of work, or a patch should be best handled by a specific developer that may not be readily available, so be patient. Also, if you don't receive an acknowledgement after a few days, write to the list asking for the status of your patch. Subscribing to the developer mailing list would be a good idea if you are sending contributions.
-</para>
-
-<sect2 id="prerequisites">
-<title>Prerequisites</title>
-<para>
-Have an updated cvs version of the release you are contributing to (HEAD, stable release, etc)
-</para>
-<itemizedlist>
-<listitem>
-<para>
-Make sure to run 'cvs upd' before you create the patch
-</para>
-</listitem>
-<listitem>
-<para>
-If the update changes your sandbox, make sure that the changes still work
-</para>
-</listitem>
-</itemizedlist>
-</sect2>
-
-<sect2 id="existingfiles">
-<title>If you modified existing Files</title>
-
-<itemizedlist>
-<listitem>
-<para>
-Run 'cvs diff -u' in the root directory. That should the create the patch to be applied to existing files
-</para>
-</listitem>
-<listitem>
-<para>
-Inspect the patch that it does only contain your wanted changes
-</para>
-</listitem>
-</itemizedlist>
-</sect2>
-
-<sect2 id="newfiles">
-<title>If you have added new Files</title>
-
-<itemizedlist>
-<listitem>
-<para>
-Make sure you write down on the email the location of each new file (The developer handling the patch will probably know how to find the correct location, but this will save her/him some precious time)
-</para>
-</listitem>
-</itemizedlist>
-</sect2>
-
-<sect2 id="finalsteps">
-<title>Final Steps</title>
-
-<itemizedlist>
-<listitem>
-<para>
-Compress the patch and any new files into a single .tar.gz file
-</para>
-</listitem>
-<listitem>
-<para>
-Send to the developer mailing list, explaining the nature of the submission
-</para>
-</listitem>
-<listitem>
-<para>
-The developer handling the patch should acknowledge that to the list as well, to avoid duplicate work
-</para>
-</listitem>
-</itemizedlist>
-</sect2>
-
-</sect1>
-</chapter>
\ No newline at end of file
diff --git a/developer-doc/phb/test-examples.docbook b/developer-doc/phb/test-examples.docbook
deleted file mode 100644
index 0d18eb6..0000000
--- a/developer-doc/phb/test-examples.docbook
+++ /dev/null
@@ -1,112 +0,0 @@
-<appendix id="test-examples">
-<title>Unit Test Examples</title>
-<para>
-This appendix contains an example of a
-<link linkend="test-header-example">unit test header file listing</link> and a
-<link linkend="test-source-example">unit test source file listing</link>.
-</para>
-
-<section id="test-header-example">
-<title>Unit Test Header File Example</title>
-<screen>
-
-/***************************************************************************
- mymoneyexceptiontest.h
- -------------------
- copyright : (C) 2002 by Thomas Baumgart
- email : ipwizard at users.sourceforge.net
- ***************************************************************************/
-
-/***************************************************************************
- * *
- * This program is free software; you can redistribute it and/or modify *
- * it under the terms of the GNU General Public License as published by *
- * the Free Software Foundation; either version 2 of the License, or *
- * (at your option) any later version. *
- * *
- ***************************************************************************/
-
-#ifndef __MYMONEYEXCEPTIONTEST_H__
-#define __MYMONEYEXCEPTIONTEST_H__
-
-#include <QtCore/QObject>
-
-#define KMM_MYMONEY_UNIT_TESTABLE friend class MyMoneyExceptionTest;
-
-#include "mymoneyutils.h"
-#include "mymoneyexception.h"
-
-class MyMoneyExceptionTest : public QObject
-{
- Q_OBJECT
-
-private slots:
- void init();
- void cleanup();
-
- void testDefaultConstructor();
-
- void testConstructor();
-
-};
-#endif
-</screen>
-</section>
-
-<section id="test-source-example">
-<title>Unit Test Source File Example</title>
-
-<screen>
-
-/***************************************************************************
- mymoneyexceptiontest.cpp
- -------------------
- copyright : (C) 2002 by Thomas Baumgart
- email : ipwizard at users.sourceforge.net
- ***************************************************************************/
-
-/***************************************************************************
- * *
- * This program is free software; you can redistribute it and/or modify *
- * it under the terms of the GNU General Public License as published by *
- * the Free Software Foundation; either version 2 of the License, or *
- * (at your option) any later version. *
- * *
- ***************************************************************************/
-
-#include "mymoneyexceptiontest.h"
-
-#include <QtTest/QtTest>
-
-QTEST_MAIN(MyMoneyExceptionTest)
-
-void MyMoneyExceptionTest::init()
-{
-}
-
-void MyMoneyExceptionTest::cleanup()
-{
-}
-
-void MyMoneyExceptionTest::testDefaultConstructor()
-{
- const MyMoneyException &e = MYMONEYEXCEPTION("Message");
- QVERIFY(e.what() == "Message");
- QVERIFY(e.line() == __LINE__ - 2);
- QVERIFY(e.file() == __FILE__);
-}
-
-void MyMoneyExceptionTest::testConstructor()
-{
- MyMoneyException e("New message", "Joe's file", 1234);
- QVERIFY(e.what() == "New message");
- QVERIFY(e.line() == 1234);
- QVERIFY(e.file() == "Joe's file");
-}
-
-#include "mymoneyexceptiontest.moc"
-
-</screen>
-
-</section>
-</appendix>
diff --git a/developer-doc/phb/translation.docbook b/developer-doc/phb/translation.docbook
deleted file mode 100644
index 5afbb33..0000000
--- a/developer-doc/phb/translation.docbook
+++ /dev/null
@@ -1,248 +0,0 @@
-
-<chapter id="translation">
-<chapterinfo>
-<authorgroup>
-<author>
- <firstname>J.</firstname>
- <surname>Rundholz</surname>
-</author>
-</authorgroup>
-</chapterinfo>
-
-<title>Translation</title>
-<para>
-This chapter should give any one (in particular people who are not developers) a first overview on how they can translate &app; into another language. The information given here is not only valid for &app; but as serves for the translation of any KDE project.
-</para>
-
-
-<sect1 id="files">
-<title>Basics</title>
-
-<para>
-First of all you need to get the required files. There are two types of files which might be of interest to you.
-Files ending in <literal role="extension">.pot</literal> and files ending
-in <literal role="extension">.po</literal>.
-</para>
-<para>
-Files ending in <literal role="extension">.pot</literal> are the source
-for the translation.
-They only contain the English texts you need to translate and are generated
-for each release of the project. The one for &app; is named <filename>kmymoney.pot</filename>.
-The po file contains the English and the translated text, e.g. German.
-There might be two cases: The first case you can't find a po file for your
-language or the second there is already a po file for your language available.
-In the latter case you can already start &app; in your language, but may be the
-translation is not complete or you simply want to improve the translation.
-
-Now you need to get these files from the project's &cvs; repository.
-You don't need to worry what exactly &cvs; does, for a translater it
-is more or less only a file system from where
-you can download the files you need. For &app; you can either go to the &cvs;
-page and call the &cvs; web front end or follow
-<ulink url="http://kmymoney2.cvs.sourceforge.net/kmymoney2/kmymoney2/po/?pathrev=rel-0-8-branch">this link</ulink>.
-I would recommend to download the pot and po file of the latest stable version
-(at the moment 0.8), not any older files and not the one which is under
-development at the moment. In order to test your translation later you should
-run the same version on your box.
-
-For the actual translation I recommend the program <application>kbabel</application>.
-Other people use <application>emacs</application>, as usual it is just a personal
-choice. All examples given here are based on <application>kbabel</application>.
-
-</para>
-
-<sect2 id="po-file">
-<title>How to get your po file</title>
-<para>
-As explained earlier the actual translation is done by modifying the po file.
-The next step is to create a po file to start the translation.
-</para>
-
-<sect3 id="no-po">
-<title>No po file for my language available</title>
-<para>
-That's the most simple case: Rename <filename>kmymoney.pot</filename> to
-<filename>lang.po</filename> where <emphasis>lang</emphasis>
-is your language code e.g. <emphasis>de</emphasis> for German.
-</para>
-
-</sect3>
-
-<sect3 id="po">
-<title>po file for my language available</title>
-<para>
-In case you already have a language file it is advisable that you check how
-the English text entries in that file differ from the English texts in the
-pot file. Maybe for some reason the pot file is further developed than the
-po file. In this case even though you would translate the whole po file you
-would still see some English texts in &app;. If you know that this is not
-the case, i.e. your po file has all the latest English text inside, you can
-use this one for translation. The minimum check you should perform is to
-compare the number of messages. Just load the po and the pot file into kbabel
-and you see how many messages you have in each file.
-</para>
-<para>
-In case that both files differ you should merge them (since
-you don't want to lose someone else's work). Merging can be
-done using <application>kbabel</application> very easily .
-
-<itemizedlist>
-<listitem>
-<para>
-Copy <filename>kmymoney.pot</filename> to <filename>lang-new.po</filename>
-and open this file with <application>kbabel</application>.
-</para>
-</listitem>
-<listitem>
-<para>
-In <application>kbabel</application> choose
-<guimenu>Tools</guimenu>
-<guimenuitem>Rough translation</guimenuitem>
-from the menu. A dialog pops up. Choose the following options:
-<itemizedlist>
-<listitem><para>What to translate::Untranslated Entries</para></listitem>
-<listitem><para>Options::Mark changed entries as fuzzy</para></listitem>
-<listitem><para>Dictionaries::Use::PO Compendium</para></listitem>
-</itemizedlist>
-Don't select anything else.
-</para>
-</listitem>
-<listitem>
-<para>
-Now press the "configure" button. In the next dialog enter the path to your
-already existing po file. Furthermore set the options:
-<itemizedlist>
-<listitem><para>Options::Case sensitive</para></listitem>
-<listitem><para>A text matches if::Equal to searched text</para></listitem>
-</itemizedlist>
-Don't select anything else.
-</para>
-</listitem>
-</itemizedlist>
-<caution>
-<para>
-The original po file could have entries marked as "fuzzy", that means that
-the translation might be not very good or even horribly wrong. After you
-did this merger process you lose this information. It might be a good
-idea to translate all fuzzy strings in the old, unmerged po file before
-you do this explained merging process.
-</para>
-</caution>
-</para>
-</sect3>
-</sect2>
-</sect1>
-<sect1 id="translating">
-<title>Translating</title>
-<para>
-Now you can take the new po file and start the translation with kbabel
-or any other tool. It might be a good idea to create a glossary of terms
-whenever you use a technical term. Such a glossary is available for the
-German translation, check it out to see how it should look like. You might
-want to check the gnucash project if they have already a glossary for your
-language. This would be a starting point for you, but please extend it.
-</para>
-</sect1>
-<sect1 id="testing">
-<title>Test your work</title>
-<para>
-Last but not least you need to check your translation, especially if the
-translated text fits into the context. Also you shouldn't be surprised
-how many typos and mistakes you make while translating the text. Check
-it carefully! Now a few steps you should perform to test your translation
-(after you used a spellchecker etc.).
-</para>
-<para>
-First you can run the command
-
-<screen>
-
- <prompt>thb:~> </prompt><userinput><command>msgcat</command> <option>--width=77</option> <option>-o</option> <replaceable>lang-output.po</replaceable> <replaceable>lang-input.po</replaceable></userinput>
-
-</screen>
-
-as root. This command just restricts the length of each line to 77
-characters. This is only necessary if you want to read the raw po file in
-some text editor. Some people who do proof reading prefer this instead of
-endless lines. The number of characters depends of some personal taste. I
-prefer about 50 characters per line, then a diff file can be displayed
-without vertical scrolling.
-</para>
-<para>
-Now run as root the command
-
-<screen>
-
- <prompt>thb:~> </prompt><userinput><command>msgfmt</command> <option>-vvv</option> <replaceable>lang.po</replaceable> kmymoney.mo</userinput>
-
-</screen>
-
-The mo file is the language file you need for your program. You just need
-to replace the original mo file of &app; with this one (perform a backup of
-the original file before). The location of your mo file depends on your
-distro, for SuSE it is <filename>/opt/kde3/share/local/lang/LC_MESSAGES</filename> and for Debian
-<filename>/usr/share/local/lang/LC_MESSAGES</filename>. For lang you can use
-any string, like de or even de_test if you want to run it with a test
-language. Be aware that &app; uses some text strings from KDE and since they
-are probably not available with de_test you still might see some English
-text. If you can't find the file on your harddrive try either
-
-<screen>
-
- <prompt>thb:~> </prompt><userinput><command>find</command> / <option>-name</option> kmymoney.mo</userinput>
-
-</screen>
-
-as root or if you used an <command>rpm</command> file for the
-installation you can run
-
-<screen>
-
- <prompt>thb:~> </prompt><userinput><command>rpm</command> <option>-q kmymoney</option> <option>--filesbypkg</option></userinput>
-
-</screen>
-
-</para>
-<para>
-In order to run &app; either start it as usual (if your default KDE language
-is the language you want to test) or call it via
-
-<screen>
-
- <prompt>thb:~> </prompt><userinput>KDE_LANG=de <command>kmymoney</command></userinput>
-
-</screen>
-
-from a <application>konsole</application> or
-<application>xterm</application>.
-</para>
-</sect1>
-<sect1 id="merging">
-<title>Merging an old po file with an updated pot file</title>
-<para>
-There are cases when the pot file is regenerated before you can send your
-updated po file. If you just commit your file after that, it will show up
-as old in the translation stats, because it references an outdated pot file.
-</para>
-<para>
-To fix this, you have to merge the po file with the updated pot file.
-
-First, get the latest pot file. And in the po folder, run this command.
-
-<screen>
-
- <prompt>thb:~/kmymoney/po> </prompt><userinput><command>make</command> <option>-f</option> <option>../admin/Makefile.common</option> <option>package-merge</option> <option>POFILES=<replaceable>"de.po"</replaceable></option> <option>PACKAGE=kmymoney</option></userinput>
-
-</screen>
-
-You can merge multiple po files at the same time. Just list them in the POFILES option.
-
-<screen>
-
- <prompt>thb:~/kmymoney/po> </prompt><userinput><command>make</command> <option>-f</option> <option>../admin/Makefile.common</option> <option>package-merge</option> <option>POFILES=<replaceable>"de.po es.po"</replaceable></option> <option>PACKAGE=kmymoney</option></userinput>
-
-</screen>
-
-</para>
-</sect1>
-</chapter>
diff --git a/developer-doc/phb/unit-test.docbook b/developer-doc/phb/unit-test.docbook
deleted file mode 100644
index 2b4b61e..0000000
--- a/developer-doc/phb/unit-test.docbook
+++ /dev/null
@@ -1,405 +0,0 @@
-<chapter id="unit-test">
-<title>Unit Testing</title>
-<para>
-If this project handbook would have been for a professional project (with
-professional I mean, a project that people make money with), I would have
-written
-</para>
-
-<caution>
-<para>
-<emphasis>Unit tests must be supplied by the developer
-with the classes/source-code he checks into the repository!</emphasis>.
-</para>
-</caution>
-
-<para>
-Since this is
-the handbook for a voluntary work (which is not less professional than any
-other project), I replace the above sentence with
-</para>
-
-<note>
-<para>
-<emphasis>Each developer in this project is strongly encouraged to develop
-unit tests for the code he or she develops and make them available to
- the project team!</emphasis>.
-</para>
-</note>
-
-<sect1 id="why-unit-testing">
-<title>Why unit testing?</title>
-
-<para>
-Before I can give an answer to this question, I should explain what unit
-testing is about. I do not cover all relevant aspects here nor do I start a
-discussion of the various aspects of unit testing. If you want to read more
-about the details of unit testing, the philosophy behind it and about the
-various tools available, please visit the project pages of
-<ulink url="http://doc.trolltech.com/latest/qtestlib-manual.html">QtTest</ulink>,
-<ulink url="http://www.junit.org/">JUnit</ulink> and
-<ulink url="http://cppunit.sourceforge.net/">CPPUNIT</ulink>.
-The following explanation describes what unit testing is:
-</para>
-
-<para>
-For each class developed in a project, an accompanying test container
-is developed when the interface of
-the class is defined but before the implementation of the class starts. The
-test container consists out of testcases that perform all necessary tests
-on the class while verifying the results. One or more of these test
-containers (for more than one class) form a test suite.
-</para>
-
-<para>
-Your might think, that it is strange to first define the interface, then
-develop the tests and then start the development of the actual code, but it
-has shown, that this approach has a couple of interesting side-effects:
-
-<itemizedlist>
-<listitem>
-<para>
-The developer spends time to think about how to test his implementation
-before he actually works on the implementation. This leads to the fact,
-that while working on the implementation, he already knows how his code
-will be tested.
-</para>
-</listitem>
-
-<listitem>
-<para>
-A clear definition of the <emphasis>end of implementation</emphasis> exists
-due to the fact, that the testcases will all fail before the beginning of
-the implementation phase. Once implementation proceeds, more and more
-testcases will pass. When they all pass, the development is finished.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Since the tests will run automated and will be re-run very often during the
-development cycle, a lot of problems will be caught very early on. This
-reduces the number of problems found during integration of the project.
-Believe me, there will be plenty left!
-</para>
-</listitem>
-</itemizedlist>
-</para>
-
-<para>
-Now, the list of all these side-effects is actually the answer to the
-question <emphasis>Why unit testing?</emphasis> or does anyone have a
-argument against it? I agree, that in some cases automated unit testing is
-hard to achieve (e.g. for GUI related code) but I found, that whenever it
-is possible to introduce automated unit tests, the benefit is huge.
-</para>
-</sect1>
-
-<sect1 id="unit-testing-in-kmm">
-<title>Unit testing in &app;</title>
-<para>
-Just about the time, when the &app; project underwent a radical change of
-it's inner business logic (the KMyMoney engine), I read an article about
-the existance of a unit test container for C++ projects named
-<ulink url="http://cppunit.sourceforge.net/">CPPUNIT</ulink>.
-In
-discussions with my colleagues at work, I got the impression, that this
-would be something worth to look into. So I sat down and wrote the first
-test cases for existing code to get a feeling for what is required.
-</para>
-
-<para>
-When &app; was ported to KDE4 the <ulink url="http://cppunit.sourceforge.net/">CPPUNIT</ulink>
-test engine was replaced with the
-<ulink url="http://doc.trolltech.com/latest/qtestlib-manual.html">QtTest</ulink>
-test engine. We did this because &app; is a KDE, thus a Qt, application so it is better
-to use Qt's unit test engine than to have an extra dependency on <ulink url="http://cppunit.sourceforge.net/">CPPUNIT</ulink>.
-</para>
-
-<para>
-I found it annoying to write test cases for code that existed and was
-believed to work (version 0.4 of the project). When the decission was made
-to start with the 0.5 development branch, I started working on the new
-engine code that should introduce a clear interface between the business
-logic and the user interface. Another design goal was to write the engine
-in such a way, that it is not based on any KDE code which the old one was.
-The second goal to free it from Qt based code was not that easy and was
-skipped by the project team at that time.
-</para>
-
-<para>
-Even if it was hard for me at first to follow the above laid out principle
-to design the interface, write the test code and then start with the
-implementation, I followed this trail. It has proven to be very valuable.
-Once the interface was designed, I started thinking in a different manner:
-How can I get this class to fail? What strange things could I do to the
-code from the outside? Those were the design drivers for the test code. And
-in fact, this thinking changed the way I actually implemented the code, as
-I knew there was something that would check all these things over and over
-again automatically.
-</para>
-
-<para>
-A lot of code was implemented and when I was almost done with the first
-shot of the implementation, discussion came up on the developers mailing
-list about a feature called <emphasis>double entry accounting</emphasis>
-that was requested for &app; by a few people. The engine I wrote up to that
-point in time did not cover the aspects of double entry accounting at all,
-though a few things matched. After some time of discussions, we became a
-better understanding of the matter and I changed the code to cover double
-entry accounting. Some of the classes remained as they were, others had to
-be adopted and yet others rewritten entirely. The testcode had to be
-changed as well due to the change in the interfaces, but not the logic
-of the tests. Most of the thoughts how to uncover flaws remained.
-</para>
-
-<para>
-And that is another reason, why unit testing is so useful: You can change
-your internal implementation and still get a feeling, if your code is
-working or not. And believe me: even if some changes are small, one usually
-oversees a little side-effect here and there. If one has good unit tests
-this is not a problem anymore, as those side-effects will be uncovered and
-tested.
-</para>
-
-<para>
-During the course of implementing the engine, I wrote more than 100
-testcases. Each testcase sets up a testenvironment for the class and tests
-various parameters against the class' methods in this environment in so
-called test steps.
-Exceptions are also tested to be thrown. The testcases handle unexpected
-exceptions as well as expected exceptions that do not occur.
-</para>
-</sect1>
-
-<sect1 id="unit-testing-howto">
-<title>Unit testing HOWTO</title>
-<para>
-This section of the developer handbook should give some examples on how to
-organize test cases and how to setup a test environment.
-</para>
-
-<para>
-My examples will all be based on the code of the &app; engine found in the
-subdirectory <command>kmymoney/kmymoney/mymoney</command> and it's
- subdirectory <command>storage</command>.</para>
-
-<sect2 id="unit-test-integration">
-<title>Integration of <ulink url="http://doc.trolltech.com/latest/qtestlib-manual.html">QtTest</ulink> into the &app; project</title>
-<para>
-The &app; build system has been configured to build the unit tests only when the
-<emphasis>KDE4_BUILD_TESTS</emphasis> cmake variable is set to <emphasis>ON</emphasis>.
-To do this pass the -DKDE4_BUILD_TESTS=ON option while configuring the project using cmake.
-</para>
-
-<para>
-In order to add a unit test source file to the build system the following
-cmake macros should be used:
-
-<screen>
-
-IF( KDE4_BUILD_TESTS )
-
- # UnitTestName
- SET(unittestname_SRCS unittestname.cpp)
- KDE4_ADD_UNIT_TEST(unittestname TESTNAME kmymoney-unittestname ${unittestname_SRCS})
- ADD_DEPENDENCIES(unittestname make-targets-upon-which-the-unit-test-depends)
- TARGET_LINK_LIBRARIES(unittestname libraries-upon-which-the-unit-test-depends)
-
-ENDIF( KDE4_BUILD_TESTS )
-
-</screen>
-For an example see <command>kmymoney/mymoney/CmakeLists.txt</command>.
-</para>
-</sect2>
-
-<sect2 id="unit-test-naming">
-<title>Naming conventions</title>
-<para>
-The test containers are also classes.
-For a given class <emphasis>MyMoneyAbc</emphasis>, which
-resides in the files <command>mymoneyabc.h</command> and
-<command>mymoneyabc.cpp</command>,
-the test container is named <emphasis>MyMoneyAbcTest</emphasis> and resides
-in the files
-<command>mymoneyabctest.h</command> and
-<command>mymoneyabctest.cpp</command> in the same directory.
-The test container must be derived
-publicly from <command>QObject</command> and it mus contain the <command>Q_OBJECT</command>
-macro. Each testcase is given a
-descriptive name (e.g. EmptyConstructor) and I found it useful to prefix
-this name with the literal 'test' resulting into something like
-testEmptyConstructor.
-</para>
-
-</sect2>
-<sect2 id="unit-test-includes">
-<title>Necessary include files</title>
-<para>
-In order to use the functionality provided by QtTest, one has to include
-some information provided with QtTest in the test environment. This is
-done with the following include primitive as one of the first things in the
-header file of the test case container (e.g. mymoneyabctest.h):
-
-<screen>
-
-#include <QtTest/QtTest>
-
-</screen>
-</para>
-</sect2>
-
-<sect2 id="unit-test-private">
-<title>Accessing private members</title>
-<para>
-For the verification process it is sometimes necessary to look at some
-internal states of the object under test. Usually, all this information is
-declared private in the class and only accessible through setter and getter
-methods. Cases exist, where these methods are not implemented on purpose
-and thus accessing the information from the test container is not possible.
-</para>
-
-<para>
-Various mechanism have been developed all with pros and cons. The old method
-was by redefining the specifier <emphasis>private</emphasis> through
-<emphasis>public</emphasis> but only for the time when reading the header
-file of the object under test. This leads to a problem when the linker includes
-the access specifiers in the mangled C++ function name. Because in the library where
-the tested object resided one of it's functions had one name and in the unit test
-it had another (due to the different access specifiers) a link error would occur.
-</para>
-
-<para>
-The current method consists in having the <emphasis>KMM_MYMONEY_UNIT_TESTABLE</emphasis>
-macro placed in the declaration of each class that has a unit test. <emphasis>KMM_MYMONEY_UNIT_TESTABLE</emphasis>
-is usually expanded to nothing but when the header of an object is included in a unit test
-<emphasis>KMM_MYMONEY_UNIT_TESTABLE</emphasis> is expanded to the following statement
-<emphasis>friend class UnitTestClassName;</emphasis>. This definition allows the
-unit test class to access all members of the tested class and does not cause the
-linkage error caused by the older method.
-
-<screen>
-
-#define KMM_MYMONEY_UNIT_TESTABLE friend class MyMoneyAbcTest;
-#include "mymoneyabc.h"
-
-</screen>
-</para>
-</sect2>
-
-<sect2 id="unit-test-methods">
-<title>Standard methods for each testcase</title>
-<para>
-
-The init() and initTestCase() slots will be called, if they exist, before
-the execution of any test case. cleanup() and cleanupTestCase() will be
-called after the execution of the test case, no matter if the test case
-passes or fails. Thus init() is used to perform initialization necessary
-for each test case in the unit test class and cleanup() is used to clean
-things up. init() and cleanup() should be written in such a way, that
-all objects created through a test case should be removed by cleanup(),
-i.e. the environment is restored exactly to the state it was before the
-call to init().
-
-<note>
-<para>
-This is not always the case within the testcase for &app;. Espacially when
-using a database as the permanent storage things have to be overhauled for
-e.g. MyMoneyFileTest.
-</para>
-</note>
-
-</para>
-
-<para>
-QtTest comes with a set of macros that help writing testcases. I cover
-them here briefly. If you wish a more detailed description, please visit
-the <ulink url="http://doc.trolltech.com/latest/qtestlib-manual.html">QtTest</ulink> page.
-</para>
-</sect2>
-
-<sect2 id="test-macro-assert">
-<title>QVERIFY</title>
-<para>
-This is the macro used at most throughout the test cases. It checks, that a
-given assumption is true. If it is not, the test case fails and a
-respective message will be printed at the end of the testrun.
-</para>
-
-<para>
-QVERIFY has a single argument which is a boolean expression. The
-expression must be true in order to pass the test. If it is false, the test
-case fails and no more code of the test case is executed. The following
-example shows how the macro is used:
-<screen>
-
- int a, b;
- a = 0, b = 1;
- QVERIFY(a != b);
- a = 1;
- QVERIFY(a == b);
-
-
-</screen>
-The example shows, how two test steps are combined. One checks the
-inequality of two integers, one the equality of them. If either one does
-not work, the test case fails.
-</para>
-<para>
-See the
-<link linkend="test-source-example">Unit Test Source File Example</link>
-for a demonstration of it's use.
-</para>
-
-</sect2>
-
-<sect2 id="test-macro-fail">
-<title>QFAIL</title>
-<para>
-This is the macro used when the execution of a test case reaches a point it
-should not. This usually happens, if exceptions are thrown or not thrown.
-</para>
-
-<para>
-CPPUNIT_FAIL has a single argument which is the error message to be
-displayed. The following example shows how the macro is used:
-<screen>
-
- int a = 1, b = 0;
- try {
- a = a / b;
- QFAIL("Expected exception missing!");
- } catch (const exception &e) {
- }
-
- try {
- a = a / a;
- } catch (const exception &e) {
- QFAIL("Unexpected exception!");
- }
-
-
-</screen>
-The example shows, how two test steps are combined. One checks the
-occurance of an exception, the other one that no exception is thrown.
-If either one does not work, the test case fails.
-</para>
-
-</sect2>
-
-<sect2 id="test-macro-testsuite-start">
-<title>QTEST_MAIN</title>
-<para>
-This macro is used as the first thing in the declaration of the test fixture.
- A single argument is the name of the class for the test fixture. It starts
-the list of test cases defined as slots of the unit test class.
-</para>
-<para>
-See the
-<link linkend="test-header-example">Unit Test Header File Example</link>
-for a demonstration of it's use.
-</para>
-</sect2>
-
-</sect1>
-</chapter>
More information about the kde-doc-english
mailing list