1 files changed, 50 insertions, 0 deletions
diff --git a/tde-i18n-de/docs/kdemultimedia/artsbuilder/porting.docbook b/tde-i18n-de/docs/kdemultimedia/artsbuilder/porting.docbook
new file mode 100644
index 00000000000..d6579f178bf
--- /dev/null
+++ b/tde-i18n-de/docs/kdemultimedia/artsbuilder/porting.docbook
@@ -0,0 +1,50 @@
+<!-- <?xml version="1.0" ?>
+<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd">
+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="porting">
+<title
+>Anwendungen auf &arts; portieren</title>
+
+<sect1 id="using-artsdsp">
+<title
+>&artsdsp; verwenden</title>
+
+<para
+>Die Anwendung &artsdsp;, die <link linkend="artsdsp"
+> weiter oben</link
+> beschrieben wird, erlaubt den meisten Standardanwendungen, die direkt auf die Audio-Geräte zugreifen, unter &arts; problemlos zu funktionieren. Die meisten Anwendungen, die den Enlightenment Sound Daemon (esd) verwenden, funktionieren ebenfalls, indem <application
+>esd</application
+> unter &artsdsp; gestartet wird. </para>
+
+<para
+>Damit existiert eine gute Übergangslösung, um Anwendungen auf &kde; zu portieren. Es erlaubt natürlich keiner Anwendung, direkt von &arts; zu profitieren und alle Fähigkeiten von &arts;, wie z.B. die Verwendung von Modulen und Multimediaströmen, zu verwenden. Wenn die Anwendung mehr können soll, als nur einfache Audiodateien abzuspielen, sollte man Unterstützung für &arts; hinzufügen. </para>
+
+<para
+>Die Anwendung kann dann viele Aufgaben an &arts; übertragen -- sie kann die in &arts; enthaltenen Funktionen verwenden, um Dinge wie unterschiedliche Codecs, Medienformate oder die Kontrolle der Audiogeräte. </para>
+
+</sect1>
+
+<sect1 id="adding-native-arts-support">
+<title
+>&arts;-Unterstützung hinzufügen</title>
+
+<para
+>Wenn Sie &arts; verwenden, können Sie zwischen verschiedenen <link linkend="arts-apis"
+><acronym
+>API</acronym
+>s</link
+> auswählen. Die Entscheidung wird unter anderem davon abhängen, welche Art von Medienstrom (Klang, &MIDI;, &CD;-Audio &etc;) Sie verwenden wollen, welche <acronym
+>API</acronym
+>-Fähigkeiten Sie benötigen und ob Sie in C++ programmieren. In den meisten Fällen sollte die Entscheidung abhängig von den benötigten Fähigkeiten klar sein </para>
+
+<para
+>Anwendungen, die auf anderen Architekturen als &kde; funktionieren sollen, können nicht davon ausgehen, das &arts; immer vorhanden ist. Durch eine Plugin-Architektur können Sie geschickt verschiedene Multimediaumgebungen unterstützen. Wenn Sie das Plugin-<acronym
+>API</acronym
+> außerdem veröffentlichen und gut dokumentieren (besonders für nicht als Quelltext verfügbare Anwendungen), ermöglichen Sie auch anderen Entwicklern, ein &arts;-Plugin für Ihre Anwendung zu schreiben. </para>
+
+</sect1>
+
+</chapter>
+