diff options
Diffstat (limited to 'tde-i18n-de/docs/tdemultimedia/artsbuilder/helping.docbook')
| -rw-r--r-- | tde-i18n-de/docs/tdemultimedia/artsbuilder/helping.docbook | 168 |
1 files changed, 40 insertions, 128 deletions
diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/helping.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/helping.docbook index bc8f518eb16..cc40735cfd3 100644 --- a/tde-i18n-de/docs/tdemultimedia/artsbuilder/helping.docbook +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/helping.docbook @@ -4,71 +4,38 @@ To validate or process this file as a standalone document, uncomment this prolog. Be sure to comment it out again when you are done --> <chapter id="contributing"> -<title ->&arts; unterstützen</title> +<title>&arts; unterstützen</title> <sect1 id="how-to-help"> -<title ->Wie Sie helfen können</title> +<title>Wie Sie helfen können</title> -<para ->Das &arts;-Projekt benötigt einerseite Hilfe von Entwicklern, um existierende Multimedia-Anwendungen für &arts; anzupassen, neue Anwendungen zu schreiben und die Möglichkeiten von &arts; zu erweitern. Andererseits gibt es auch viele Aufgaben, die von Anderen übernommen werden können. Es werden Tester benötigt, die Fehlermeldungen liefern, Übersetzer, die die Anwendungstexte und die Dokumentation in andere Sprachen übersetzen, Graphiker, die Bitmaps (besonders für die <application ->artsbuilder</application ->-Module) entwerfen, Musiker, die Beispiele für &arts; erzeugen, und Autoren, die die Dokumentation schreiben und korrigieren. </para> +<para>Das &arts;-Projekt benötigt einerseite Hilfe von Entwicklern, um existierende Multimedia-Anwendungen für &arts; anzupassen, neue Anwendungen zu schreiben und die Möglichkeiten von &arts; zu erweitern. Andererseits gibt es auch viele Aufgaben, die von Anderen übernommen werden können. Es werden Tester benötigt, die Fehlermeldungen liefern, Übersetzer, die die Anwendungstexte und die Dokumentation in andere Sprachen übersetzen, Graphiker, die Bitmaps (besonders für die <application>artsbuilder</application>-Module) entwerfen, Musiker, die Beispiele für &arts; erzeugen, und Autoren, die die Dokumentation schreiben und korrigieren. </para> </sect1> <sect1 id="mailing-lists"> -<title ->Mailinglisten</title> - -<para ->Viele Diskussionen zur Entwicklung von &arts; finden in einer von zwei Mailinglisten statt. Hier werden neue Fähigkeiten und Umsetzungsideen diskutiert, hierhin kann man sich bei Problemen wenden. </para> - -<para ->Die &kde;-Multimedia-Mailingliste ist für allgemeine Multimediathemen sowohl &arts; als auch andere Multimediaprogramme wie &noatun; und &aktion; betreffend. Sie können sich auf der Internetseite <ulink url="http://www.kde.org/mailinglists.html" ->http://www.kde.org/mailingslists.html</ulink -> oder durch eine E-Mail mit dem Betreff (subject) <userinput ->subscribe <replaceable ->Ihre-E-Mail-Adresse</replaceable -></userinput -> an <email ->kde-multimedia-request@kde.org</email -> anmelden. Die Liste wird unter <ulink url="http://lists.kde.org" ->http://lists.kde.org</ulink -> archiviert. </para> - -<para ->In der &arts;-Mailingliste geht es um &arts;-spezifische Themen einschließlich der Nutzung von &arts; außerhalb von &kde;. Zur Anmeldung senden Sie eine E-Mail mit dem Inhalt <userinput ->subscribe <replaceable ->Ihre-E-Mail-Adresse</replaceable -></userinput -> an <email ->arts-request@space.twc.de</email ->. Die Liste wird unter <ulink url="http://space.twc.de/~stefan/arts-archive" -> http://space.twc.de/~stefan/arts-archive</ulink -> archiviert. </para> +<title>Mailinglisten</title> + +<para>Viele Diskussionen zur Entwicklung von &arts; finden in einer von zwei Mailinglisten statt. Hier werden neue Fähigkeiten und Umsetzungsideen diskutiert, hierhin kann man sich bei Problemen wenden. </para> + +<para>Die &kde;-Multimedia-Mailingliste ist für allgemeine Multimediathemen sowohl &arts; als auch andere Multimediaprogramme wie &noatun; und &aktion; betreffend. Sie können sich auf der Internetseite <ulink url="http://www.kde.org/mailinglists.html">http://www.kde.org/mailingslists.html</ulink> oder durch eine E-Mail mit dem Betreff (subject) <userinput>subscribe <replaceable>Ihre-E-Mail-Adresse</replaceable></userinput> an <email>kde-multimedia-request@kde.org</email> anmelden. Die Liste wird unter <ulink url="http://lists.kde.org">http://lists.kde.org</ulink> archiviert. </para> + +<para>In der &arts;-Mailingliste geht es um &arts;-spezifische Themen einschließlich der Nutzung von &arts; außerhalb von &kde;. Zur Anmeldung senden Sie eine E-Mail mit dem Inhalt <userinput>subscribe <replaceable>Ihre-E-Mail-Adresse</replaceable></userinput> an <email>arts-request@space.twc.de</email>. Die Liste wird unter <ulink url="http://space.twc.de/~stefan/arts-archive"> http://space.twc.de/~stefan/arts-archive</ulink> archiviert. </para> </sect1> <sect1 id="coding-standards"> -<title ->Programmierstandards (in Englisch)</title> +<title>Programmierstandards (in Englisch)</title> -<para ->For getting a consistent reading through all the sources, it is important to keep the coding style the same, all over the &arts; source. Please, even if you just write a module, try to write/format your source accordingly, as it will make it easier for different people to maintain the source tree, and easier to copy pieces of from one source to another. </para> +<para>For getting a consistent reading through all the sources, it is important to keep the coding style the same, all over the &arts; source. Please, even if you just write a module, try to write/format your source accordingly, as it will make it easier for different people to maintain the source tree, and easier to copy pieces of from one source to another. </para> <variablelist> <varlistentry> -<term ->Naming of member functions</term> +<term>Naming of member functions</term> <listitem> -<para ->&Qt;/&Java; style, that means capitalization on word breaks, and first letter always without capitalization; no underscores. </para> -<para ->This means for instance:</para> +<para>&Qt;/&Java; style, that means capitalization on word breaks, and first letter always without capitalization; no underscores. </para> +<para>This means for instance:</para> -<programlisting ->createStructureDesc() +<programlisting>createStructureDesc() updateWidget(); start(); </programlisting> @@ -76,94 +43,54 @@ this prolog. Be sure to comment it out again when you are done --> </varlistentry> <varlistentry> -<term ->Class members</term> +<term>Class members</term> <listitem> -<para ->Class members are not capitalized, such as menubar or button. </para> +<para>Class members are not capitalized, such as menubar or button. </para> -<para ->When there are accessing functions, the standard should be the &MCOP; way, that is, when having an long member <function ->foo</function ->, which shouldn't be visible directly, you create: </para> +<para>When there are accessing functions, the standard should be the &MCOP; way, that is, when having an long member <function>foo</function>, which shouldn't be visible directly, you create: </para> -<programlisting ->foo(long new_value); +<programlisting>foo(long new_value); long foo(); </programlisting> -<para ->functions to get and set the value. In that case, the real value of <function ->foo</function -> should be stored in <returnvalue ->_foo</returnvalue ->. </para> +<para>functions to get and set the value. In that case, the real value of <function>foo</function> should be stored in <returnvalue>_foo</returnvalue>. </para> </listitem> </varlistentry> <varlistentry> -<term ->Class names</term> +<term>Class names</term> <listitem> -<para ->All classes should be wordwise capitalized, that means <classname ->ModuleView</classname ->, <classname ->SynthModule</classname ->. All classes that belong to the libraries should use the &arts; namespace, like <classname ->Arts::Soundserver</classname ->. </para> -<para ->The implementations of &MCOP; classes should get called <classname ->Class_impl</classname ->, such as <classname ->SoundServer_impl</classname ->. </para> +<para>All classes should be wordwise capitalized, that means <classname>ModuleView</classname>, <classname>SynthModule</classname>. All classes that belong to the libraries should use the &arts; namespace, like <classname>Arts::Soundserver</classname>. </para> +<para>The implementations of &MCOP; classes should get called <classname>Class_impl</classname>, such as <classname>SoundServer_impl</classname>. </para> </listitem> </varlistentry> <varlistentry> -<term ->Parameters</term> +<term>Parameters</term> <listitem> -<para ->Parameters are always uncapitalized. </para> +<para>Parameters are always uncapitalized. </para> </listitem> </varlistentry> <varlistentry> -<term ->Local variables</term> +<term>Local variables</term> <listitem> -<para ->Local variables are always uncapitalized, and may have names like <varname ->i</varname ->, <varname ->p</varname ->, <varname ->x</varname ->, &etc; where appropriate. </para> +<para>Local variables are always uncapitalized, and may have names like <varname>i</varname>, <varname>p</varname>, <varname>x</varname>, &etc; where appropriate. </para> </listitem> </varlistentry> <varlistentry> -<term ->Tab width (Shift width)</term> +<term>Tab width (Shift width)</term> <listitem> -<para ->One tab is as long as 4 spaces. </para> +<para>One tab is as long as 4 spaces. </para> </listitem> </varlistentry> <varlistentry> -<term ->Leerzeichen in Ausdrücken</term> +<term>Leerzeichen in Ausdrücken</term> <listitem> -<para ->Normalerweise müssen in Ausdrücken keine Leerzeichen verwendet werden. Man kann sie allerdings zwischen Operatoren und ihren Operanden setzen. Falls man allerdings ein Leerzeichen direkt vor einen Operator (wie z.B. +) setzt, muss man auch nach dem Operator ein Leerzeichen setzen. Die einzige Ausnahme von dieser Regel bilden listenartige Ausdrücke (mit ,), bei denen man nur hinter dem "," ein Leerzeichen setzen darf. Man kann es aber auch weglassen. </para> -<para ->Die folgenden Beispiele demonstrieren die sinnvolle Verwendung von Leerzeichen: </para> -<programlisting ->{ +<para>Normalerweise müssen in Ausdrücken keine Leerzeichen verwendet werden. Man kann sie allerdings zwischen Operatoren und ihren Operanden setzen. Falls man allerdings ein Leerzeichen direkt vor einen Operator (wie z.B. +) setzt, muss man auch nach dem Operator ein Leerzeichen setzen. Die einzige Ausnahme von dieser Regel bilden listenartige Ausdrücke (mit ,), bei denen man nur hinter dem "," ein Leerzeichen setzen darf. Man kann es aber auch weglassen. </para> +<para>Die folgenden Beispiele demonstrieren die sinnvolle Verwendung von Leerzeichen: </para> +<programlisting>{ int a,b; int c, d, e; int f = 4; @@ -181,12 +108,8 @@ this prolog. Be sure to comment it out again when you are done --> arts_debug("%d\n", c); } </programlisting> -<para ->Die folgenden Beispiele demonstrieren, wie Leerzeichen <emphasis ->nicht</emphasis -> verwendet werden dürfen. Bei Funktionsaufrufen, nach "if", "for", "switch" und so weiter dürfen keine Leerzeichen stehen. </para> -<programlisting ->{ +<para>Die folgenden Beispiele demonstrieren, wie Leerzeichen <emphasis>nicht</emphasis> verwendet werden dürfen. Bei Funktionsaufrufen, nach "if", "for", "switch" und so weiter dürfen keine Leerzeichen stehen. </para> +<programlisting>{ // FALSCH: In einer Liste dürfen Leerzeichen nur nach dem "," stehen int a , b , c , d , e , f; @@ -213,22 +136,11 @@ this prolog. Be sure to comment it out again when you are done --> <varlistentry> -<term ->Naming of source files</term> +<term>Naming of source files</term> <listitem> -<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 &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 <filename -><replaceable ->foo</replaceable ->_impl</filename ->, if Foo was the name of the interface. </para> - -<para ->&IDL; files should be called in a descriptive way for the collection of interfaces they contain, also all lower case. Especially it is not good to call an &IDL; file like the class itself, as the .mcopclass trader and type info entries will collide, then. </para> +<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 &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 <filename><replaceable>foo</replaceable>_impl</filename>, if Foo was the name of the interface. </para> + +<para>&IDL; files should be called in a descriptive way for the collection of interfaces they contain, also all lower case. Especially it is not good to call an &IDL; file like the class itself, as the .mcopclass trader and type info entries will collide, then. </para> </listitem> </varlistentry> </variablelist> |