summaryrefslogtreecommitdiffstats
path: root/tde-i18n-da/docs/tdemultimedia/artsbuilder/porting.docbook
blob: 89f1d0789e48552773a0463a907d0a8772bdcf02 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
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
>Overfør programmer til at passe sammen med &arts;</title>

<sect1 id="using-artsdsp">
<title
>Brug af &artsdsp;</title>

<para
>Værktøjet &artsdsp;, <link linkend="artsdsp"
>tidligere beskrevet</link
>, tillader de fleste ældre lydprogrammer som taler direkte med lydenheder at virke rigtigt med &arts;. Programmer som er skrevet til at bruge Enlightenment Sound Daemon (<application
>esd</application
>) virker også i de fleste tilfælde ved at køre <application
>esd</application
> med &artsdsp;. </para>

<para
>Dette giver en god løsning på kort sigt for at ændre eksisterende programmer til &kde;. Det tillader dog ikke programmet direkte at drage fordel af hele &arts;' kraftfulde funktioner, såsom at bruge moduler og andre multimedietyper end digitallyd. Hvis programmet gør mere end kun helt enkelt at afspille lydfiler, er det oftest bedre at tilføje indbygget støtte for &arts; i programmet. </para>

<para
>At bruge &arts; betyder også at programmet ikke behøver gøre så meget arbejde - det kan drage fordel af funktioner i &arts; til at håndtere ting såsom kodning for forskellige mediaformater og kontrol af lydkort. </para>

</sect1>

<sect1 id="adding-native-arts-support">
<title
>Tilføjelse af indbygget støtte for  &arts;</title>

<para
>Når du bruger &arts;, er der et antal forskellige <link linkend="arts-apis"
>programmeringsgrænseflader</link
> (<acronym
>API</acronym
>) at vælge blandt. Beslutningen om hvilket som skal bruges afhænger af et antal forskellige faktorer, blandt andet hvilken slags medietype der bruges (lyd, &MIDI;, lyd-CD, etc.), de funktioner der kræves af grænsefladen, og om programmet er skrevet i C++. I de fleste tilfælde bør valget være ganske klart baseret på de nødvendige funktioner. </para>

<para
>For flytbarhed mellem platforme kan programmer som skal kunne køre i andre miljøer end &kde; ikke stole på at &arts; er tilgængeligt. At bruge en plugin-paradigme er en god måde at støtte forskellige multimediemiljøer. At lave et plugin-<acronym
>API</acronym
> åbent og dokumenteret (især for programmer uden adgang til kildekode) har også den fordel at en anden end programudvikleren kan implementere plugin til &arts;. </para>

</sect1>

</chapter>