blob: 4cec99f2c2b3d2b986b4094db5cee4662ef97619 (
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
>Ändra program för att passa &arts;</title>
<sect1 id="using-artsdsp">
<title
>Att använda &artsdsp;</title>
<para
>Verktyget &artsdsp;, <link linkend="artsdsp"
>tidigare beskrivet</link
>, låter de flesta äldre ljudprogram som pratar direkt med ljudenheter fungera riktigt med &arts;. Program som är skrivna för att använda Enlightenment Sound Daemon (<application
>esd</application
>) fungerar också i de flesta fall genom att köra <application
>esd</application
> med &artsdsp;. </para>
<para
>Det här ger en bra lösning på kort sikt för att ändra befintliga program för &kde;. Det här låter dock inte programmet direkt dra nytta av hela &arts; kraftfulla funktioner, som att använda moduler och andra multimediatyper än digitalljud. Om programmet gör mer än att bara helt enkelt spela ljudfiler, är det oftast vettigt att lägga till inbyggt stöd för &arts; i programmet. </para>
<para
>Att använda &arts; betyder också att programmet inte behöver göra så mycket arbete - det kan dra nytta av funktioner i &arts; för att hantera saker som kodning för olika mediaformat och kontroll av ljudhårdvara. </para>
</sect1>
<sect1 id="adding-native-arts-support">
<title
>Lägga till inbyggt stöd för &arts;</title>
<para
>När du använder &arts;, finns det ett antal olika <link linkend="arts-apis"
>programmeringsgränssnitt</link
> (<acronym
>API</acronym
>) att välja bland. Beslutet om vilket som ska användas beror på ett antal olika faktorer, bland annat vilket sorts medietyp som används (ljud, &MIDI;, ljud-CD, etc.), de funktioner som krävs av gränssnittet, och om programmet är skrivet i C++. I de flesta fall bör valet vara ganska klart baserat på de nödvändiga funktionerna. </para>
<para
>För flyttbarhet mellan plattformar kan inte program som måste kunna köra i andra miljöer än &kde; förlita sig på att &arts; är tillgängligt. Att använda en insticksprogramparadigm är ett bra sätt att stödja olika multimediamiljöer. Att göra ett insticksprogram-<acronym
>API</acronym
> öppet och dokumenterat (särskilt för program utan tillgång till källkod) har också fördelen att någon annan än programutvecklaren kan implementera insticksprogram till &arts;. </para>
</sect1>
</chapter>
|
