6 files changed, 14 insertions, 27 deletions

diff --git a/doc/artsbuilder/artsbuilder.docbook b/doc/artsbuilder/artsbuilder.docbook
index b5f4f68c..63e39e0b 100644
--- a/doc/artsbuilder/artsbuilder.docbook
+++ b/doc/artsbuilder/artsbuilder.docbook
@@ -339,7 +339,7 @@ Finally, you can delete the Synth_SEQUENCE module, and rather
 connect connect the frequency input port of the structure to the
 Synth_FREQUENCY frequency port. Hm. But what do do about
 pos?</para> <para>We don't have this, because with no algorithm in the
-world, you can predict when the user will release the note he just
+world, you can predict when the user will release the note they just
 pressed on the midi keyboard. So we rather have a pressed parameter
 instead that just indicates wether the user still holds down the
 key. (pressed = 1: key still hold down, pressed = 0: key
diff --git a/doc/artsbuilder/detail.docbook b/doc/artsbuilder/detail.docbook
index c7ed7319..37d5e328 100644
--- a/doc/artsbuilder/detail.docbook
+++ b/doc/artsbuilder/detail.docbook
@@ -1415,7 +1415,7 @@ once you assigned something else (like a null reference).
 <para>
 The equivalent C++ terms would be
 <programlisting>
-   QWidget* w;
+   TQWidget* w;
    w-&gt;show();
 </programlisting>
 
@@ -1662,8 +1662,8 @@ objects that are send over wire are tagged before transfer.
 </para>
 
 <para>
-If the receiver receives an object which is on his server, of course he
-will not <function>_useRemote()</function> it. For this special case,
+If the receiver receives an object which is on their server, of course
+they will not <function>_useRemote()</function> it. For this special case,
 <function>_cancelCopyRemote()</function> exists to remove the tag
 manually. Other than that, there is also timer based tag removal, if
 tagging was done, but the receiver didn't really get the object (due to
diff --git a/doc/artsbuilder/faq.docbook b/doc/artsbuilder/faq.docbook
index 8bb7ae4c..65a14c87 100644
--- a/doc/artsbuilder/faq.docbook
+++ b/doc/artsbuilder/faq.docbook
@@ -414,7 +414,7 @@ Short answer: no, &arts; will not work if you compile it with gcc-3.0.
 <para>
 Long answer: In the official release, there are two gcc-3.0 bugs which affect
 &arts;. The first, gcc-3.0 bug c++/2733 is relatively harmless (and has to do
-with problems with the asm statement). It breaks compilation of convert.cc. It
+with problems with the asm statement). It breaks compilation of convert.cpp. It
 has been fixed in the gcc-3.0 CVS, and will no longer be a problem with
 gcc-3.0.1 and higher. A workaround has also been added to the CVS version
 of KDE/aRts.
@@ -1018,7 +1018,7 @@ succeeds, which eventually leads to consuming all CPU power and reporting
 might get supplied with wrong information how much to write. Artsd will then
 <emphasis>stop with an assertion</emphasis> like:
 <screen>
-artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int):
+artsd: audiosubsys.cpp:458: void Arts::AudioSubSystem::handleIO(int):
 Assertion `len == can_write' failed.
 Aborted
 </screen>
diff --git a/doc/artsbuilder/helping.docbook b/doc/artsbuilder/helping.docbook
index 72b2ff2b..dc635701 100644
--- a/doc/artsbuilder/helping.docbook
+++ b/doc/artsbuilder/helping.docbook
@@ -224,7 +224,7 @@ written.
 <para>
 Source files should have no capitalization in the name. They should have
 the name of the class when they implement a single class. Their
-extension is <literal role="extension">.cc</literal> if they refer to
+extension is <literal role="extension">.cpp</literal> if they refer to
 &Qt;/&GUI; independent code, and <literal
 role="extension">.cpp</literal> if they refer to &Qt;/&GUI; dependant
 code. Implementation files for interfaces should be called
diff --git a/doc/artsbuilder/index.docbook b/doc/artsbuilder/index.docbook
index 89706495..7308f2f9 100644
--- a/doc/artsbuilder/index.docbook
+++ b/doc/artsbuilder/index.docbook
@@ -378,16 +378,3 @@ url="http://www.kde.org/documentation/faq/index.html">&kde;
 &arts-glossary;
 
 </book>
-<!--
-Local Variables:
-mode: sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:0
-sgml-indent-data:nil
-End:
--->
diff --git a/doc/artsbuilder/mcop.docbook b/doc/artsbuilder/mcop.docbook
index f140bff9..ca4a195a 100644
--- a/doc/artsbuilder/mcop.docbook
+++ b/doc/artsbuilder/mcop.docbook
@@ -1093,7 +1093,7 @@ interface Hello {
 You pass that through the &IDL; compiler by calling
 <userinput><command>mcopidl</command>
 <parameter>hello.idl</parameter></userinput>, which will in turn generate
-<filename>hello.cc</filename> and <filename>hello.h</filename>.  To
+<filename>hello.cpp</filename> and <filename>hello.h</filename>.  To
 implement it, you need to define a C++-class that inherits the skeleton:
 </para>
 
@@ -1476,7 +1476,7 @@ Marshalling should be easy to implement.
 
 <listitem>
 <para>
-Demarshalling requires the receiver to know what type he wants to
+Demarshalling requires the receiver to know what type they want to
 demarshall.
 </para>
 </listitem>
@@ -1991,7 +1991,7 @@ objects</quote> and <quote>the <acronym>CORBA</acronym>
 interface</quote> look natural, but it didn't, because
 <acronym>CORBA</acronym> knew nothing at all about streams. &MCOP;
 does. Look at the code (something like
-<filename>simplesoundserver_impl.cc</filename>). Way better!  Streams
+<filename>simplesoundserver_impl.cpp</filename>). Way better!  Streams
 can be declared in the interface of modules, and implemented in a
 natural looking way.
 </para>
@@ -2197,12 +2197,12 @@ that, I am certainly proven wrong.
 While I do know that &DCOP; basically doesn't know about the data types
 it sends, so that you could use &DCOP; without using &Qt;, look at how
 it is used in daily &kde; usage: people send types like
-<classname>QString</classname>, <classname>QRect</classname>,
+<classname>TQString</classname>, <classname>QRect</classname>,
 <classname>QPixmap</classname>, <classname>QCString</classname>, ...,
 around. These use &Qt;-serialization. So if somebody choose to support
-&DCOP; in a GNOME program, he would either have to claim to use
-<classname>QString</classname>,...  types (although he doesn't do so),
-and emulate the way &Qt; does the streaming, or he would send other
+&DCOP; in a GNOME program, they would either have to claim to use
+<classname>TQString</classname>,...  types (although they don't do so),
+and emulate the way &Qt; does the streaming, or they would send other
 string, pixmap and rect types around, and thus not be interoperable.
 </para>