summaryrefslogtreecommitdiffstats
path: root/tde-i18n-sv/docs/kdevelop/kdevelop/unixdev.docbook
blob: be8d66dbc9bd78a0e378f06e3b49c38cc0e02069 (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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
<appendix id="unixdev">

<appendixinfo>
  <authorgroup>
    <author
><firstname
>Bernd</firstname
><surname
>Pol</surname
></author>
    <!-- ROLES_OF_TRANSLATORS -->
  </authorgroup>
</appendixinfo>

<title
>Utveckling på &UNIX;</title>

<indexterm zone="unixdev"
><primary
>utveckling</primary
></indexterm>
<indexterm zone="unixdev">
  <primary
>&UNIX;</primary>
  <secondary
>utveckling</secondary
></indexterm>

<sect1 id="history">
<title
>Några historiska anmärkningar</title>

<indexterm zone="history"
><primary
>historia</primary
></indexterm>
<indexterm zone="history"
><primary
>skriptspråk</primary
></indexterm>
<indexterm zone="history">
  <primary
>&UNIX;</primary>
  <secondary
>historia</secondary
></indexterm>
<indexterm zone="history">
  <primary
>&UNIX;</primary>
  <secondary
>rörledning</secondary
></indexterm>
<indexterm zone="history">
  <primary
>&UNIX;</primary>
  <secondary
>skal</secondary
></indexterm>
<indexterm zone="history">
  <primary
>skal</primary>
  <secondary
>&UNIX;</secondary
></indexterm>

<para
>Från början har &UNIX; upprätthållit två mycket olika utvecklingsmodeller. Den ena är sfären av programspråk för <emphasis
>system och tillämpningar</emphasis
>, där en källkod översätts till maskinkod med en <emphasis
>kompilator</emphasis
> eller <emphasis
>tolk</emphasis
>. Programspråket C är ett exempel på detta. Unix var den första operativsystemkärnan som skrevs i ett högnivåspråk istället för maskinnära assembler, som var vanligt innan dess. (I själva verket uppfanns till och med språket C för att skriva Unix-kärnan, och tillhörande program, på en DEC PDP-11 dator.) </para>
<para
>Den andra modellen är sfären med <emphasis
>skriptspråk</emphasis
>, som startade med uppfinningen av &UNIX;-skalet, som samtidigt var operativsystemets användargränssnitt, och ett programspråk på mycket hög nivå. Ett skalskript byggs upp av en mängd små verktyg som t.ex. <command
>grep</command
>, <command
>sed</command
> eller <command
>find</command
>. Varje sådant verktyg är konstruerat för en väl avgränsad uppgift. Tricket är att alla sådana verktyg kan kopplas ihop med varandra via en enkel överföringsmekanism, kallat <emphasis
>rörledning</emphasis
>, som skickar utmatningen från föregående verktyg till inmatningen för nästa. Det ger grunden till en mycket kraftfull och flexibel programmeringsmetod. </para>
<para
>Med tiden har båda sfärerna utvecklats. Medan C fortfarande i huvudsak används som ett systemprogramspråk, har C++, som en variant av C berikad med objektorienterade och generiska utökningar, funnit sin plats vid utveckling av komplexa program under 1990-talet. Det finns många andra programspråk, till och med äldre behåller sin plats. FORTRAN77 och Ada har t.ex. fortfarande sina fästen i numeriska tillämpningar. </para>
</sect1
> <!-- history -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-scripting-languages">
<title
>Moderna skriptspråk</title>
<para
>I skriptområdet har det skett ett skifte bort från skalet, som lider av flyttbarhetsproblem, till språk som samlar alla vanliga funktioner i standardbibliotek, medan de fortfarande kan ha gränssnitt mot omvärlden via rörledningar när det behövs.  </para>
<para
>Alla skriptspråk har gemensamt att de ofta är flyttbara mellan många &UNIX;-varianter, &Microsoft; &Windows;, &MacOS; eller till och med VMS. Dessutom har de alla implementeringar som kan distribueras fritt. </para>

<sect2 id="unixdev-SL-Perl">
<title
>&perl;</title>

<indexterm zone="unixdev-SL-Perl"
><primary
>Perl</primary
></indexterm>
<indexterm zone="unixdev-SL-Perl">
  <primary
>skriptspråk</primary>
  <secondary
>Perl</secondary
></indexterm>

<para
><ulink url="http://www.perl.com"
>&perl;</ulink
> har blivit populärt som textbehandlings- och systemadministrationsspråk. Från starten av webben användes CGI-skript skrivna i &perl; som ett utbrett sätt att skapa dynamiska webbsidor från databaser. Idag har den metoden ofta ersatts med insticksprogrammet <command
>mod_perl</command
> för webbservern &apache;. Bland &perl;s styrkor är dess inbyggda stöd för avancerade reguljära uttryck, och rika arkiv med fritt distribuerade moduler. </para>
<para
>För mer information se webbplatsen <ulink url="http://cpan.org"
>Comprehensive Perl Archive Network (<acronym
>CPAN</acronym
>)</ulink
>. </para>
</sect2
> <!-- unixdev-SL-Perl -->

<sect2 id="unixdev-SL-Python">
<title
>Python</title>

<indexterm zone="unixdev-SL-Python"
><primary
>Python</primary
></indexterm>
<indexterm zone="unixdev-SL-Python">
  <primary
>skriptspråk</primary>
  <secondary
>Python</secondary
></indexterm>

<para
><ulink url="http://www.python.org"
>&python;</ulink
> glänser med elegansen i sitt klassystem och enkelheten och flexibiliteten som yttre bibliotek kan förpackas, på så sätt att de förefaller vara standardklasser och -funktioner i &python;. I motsats till &perl;, har &python; ett klart och koncist inbäddningsgränssnitt, som gör det till bästa val för att möjliggöra skript för C och C++ program. </para>
</sect2
> <!-- unixdev-SL-Python -->

<sect2 id="unixdev-SL-PHP">
<title
>PHP</title>

<indexterm zone="unixdev-SL-PHP"
><primary
>PHP</primary
></indexterm>
<indexterm zone="unixdev-SL-PHP">
  <primary
>skriptspråk</primary>
  <secondary
>PHP</secondary
></indexterm>

<para
><ulink url="http://www.php.net"
>&php;</ulink
> uppfanns som ett språk för direkt inbäddning på HTML-sidor, och har av den orsaken huvudanvändningen att leverera dynamisk innehåll för webben. </para>
</sect2
> <!-- unixdev-SL-PHP -->
</sect1
> <!-- unixdev-scripting-languages -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1 id="unixdev-hl-script">
<title
>Högnivåskript</title>

<para
>Högnivåprogram i &UNIX; saknar ofta snabbheten och flexibiliteten hos de traditionella teckenbaserade skalskriptmekanismerna. Det är särskilt sant i de grafiska gränssnittens värld, som t.ex. &kde;. </para>
<para
>Försök har gjorts att tillhandahålla liknande mekanismer som fungerar på en högre programnivå, bland de mest nämnvärda är <link linkend="unixdev-corba"
>CORBA</link
>, och i &kde;-miljön, <link linkend="unixdev-dcop"
>&DCOP;</link
>. </para>

<sect2 id="unixdev-corba">
<title
>CORBA-protokollet</title>

<indexterm zone="unixdev-corba"
><primary
>CORBA</primary
></indexterm>
<indexterm zone="unixdev-corba">
  <primary
>skriptspråk</primary>
  <secondary
>CORBA</secondary
></indexterm>
<indexterm zone="unixdev-corba">
  <primary
>kommunikation</primary>
  <secondary
>CORBA</secondary
></indexterm>

<para
><ulink url="http://www.omg.org/gettingstarted/corbafaq.htm"
>CORBA</ulink
> (<emphasis
>Common Object Request Broker Architecture</emphasis
>) är ett försök att låta datorprogram arbeta tillsammans via nätverk. Det togs fram av den privata, leverantörsoberoende kommittén <ulink url="http://www.omg.org"
>OMG</ulink
> (Object Management Group). </para>
<para
>CORBA-baserade program använder IIOP-standardprotokollet för att kommunicera. Implementeringar baserade på IIOP är tillgängliga för ett stort antal operativsystem, programspråk och nätverk, och är därför mycket flyttbara. </para>
<para
>Den huvudsakliga nackdelen med CORBA är dess ganska långsamma hastighet. Även om det kan tolereras i nätverk, är det ett verkligt hinder för kommunikation mellan program i en miljö utan nätverk, såsom &kde; när det kör på en enda dator. </para>

</sect2
> <!-- unixdev-corba -->

<sect2 id="unixdev-dcop">
<title
>&DCOP;-gränssnittet</title>

<indexterm zone="unixdev-dcop"
><primary
>DCOP</primary
></indexterm>
<indexterm zone="unixdev-dcop">
  <primary
>skriptspråk</primary>
  <secondary
>DCOP</secondary
></indexterm>
<indexterm zone="unixdev-dcop">
  <primary
>kommunikation</primary>
  <secondary
>DCOP</secondary
></indexterm>

<para
>En annan evolution av &UNIX;-liknande skript är <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html"
><emphasis
>DCOP</emphasis
></ulink
>-protokollet, som uppfanns för kommunikation mellan &kde;-program för att bemästra CORBA:s begränsningar. </para>
<para
>&DCOP; betyder <emphasis
>Desktop COmmunikation Protocol</emphasis
> (protokollet för skrivbordskommunikation), och är implementerat som en enkel IPC/RPC-mekanism byggd för att fungera via uttag. Sluteffekten är att erbjuda funktioner som liknar den traditionella rörledningsmekanismen i &UNIX;. </para>
<para
>Traditionella skalskript är baserade på ganska små programverktyg, som konstruerades för att enbart fungera baserade på ren text. &DCOP; tillåter att avancerade grafiska program kommunicerar med varandra på ett motsvarande sätt. Det gör det till exempel möjligt för ett &kde;-program att skicka meddelanden till ett annat &kde;-program, eller ta emot data från det för sitt eget syfte. </para>
<para
>Det finns dock nackdelar. För att använda &DCOP;, måste programmet vara konstruerat med ett speciellt &DCOP;-gränssnitt. Dessutom går &DCOP;-kommunikationsprocessen något långsamt (även om den är mycket snabbare än CORBA). Ändå så återger det mycket av styrkan och flexibiliteten i &UNIX;-skript till högnivåprogram som är baserade på ett grafiskt användargränssnitt. </para>
<para
>För ytterligare information, se artikeln <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html"
>DCOP: Desktop COmmunications Protocol</ulink
> eller <ulink url="developer.kde.org/documentation/library/cvs-api/dcop/html/index.html"
>The DCOP Desktop Communication Protocol library</ulink
>, dokumentation av användargränssnittet för &kde;:s DCOP-bibliotek. </para>
</sect2
> <!--  unixdev-dcop -->

</sect1
> <!--  unixdev-hl-script -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-buildsystems">
<title
>Byggsystem</title>

<para
>Utom i mycket enkla fall, kommer ett programmeringsprojekt att bestå av många byggblock med källkod, vart och ett placerat i en enskild fil för enklare underhåll. För att få allt att köra, måste man effektivt kunna översätta allt detta till några få maskinkodsenheter med lämpligt format, som gör att operativsystemet kan ladda och köra programmet. </para>
<para
>För att åstadkomma detta, är de grundläggande verktyg som behövs: <itemizedlist>
  <listitem
><para
>en <emphasis
>texteditor</emphasis
> för att skriva källkodsfilerna, </para
></listitem>
  <listitem
><para
>ett översättningsprogram, oftast en <emphasis
>kompilator</emphasis
> för att omvandla källkoden till objektfiler, </para
></listitem>
  <listitem
><para
>ett <emphasis
>biblioteksprogram</emphasis
> som samlar objektfiler i bibliotek, som enkelt kan återanvändas utan att behöva kompileras om, </para
></listitem>
  <listitem
><para
>en <emphasis
>länkare</emphasis
>, som binder ihop flera objektfiler och bibliotek till ett körbart program, </para
></listitem>
  <listitem
><para
>ett <emphasis
>byggsystem</emphasis
>, som erbjuder något sätt att hantera allt detta, och inte att förglömma, </para
></listitem>
  <listitem
><para
>en <emphasis
>avlusare</emphasis
> för att (förhoppningsvis) hitta alla fel i programmet, och möjligen ytterligare diagnosverktyg för att få allt att köra smidigt. </para
></listitem>
</itemizedlist>
</para>

<para
>När man har ett stort projekt, som kan bestå av upp till hundratals källkodsfiler, kan kompileringsprocessen bli riktigt arbetsintensiv. Man vill inte kompilera om alla filer varje gång några av dem har ändrats. Istället vill man bara kompilera om de filer som påverkas av ändringen. I allmänhet är det inte alltid helt uppenbart vilka av filerna som måste kompileras om. </para>
<para
>När t.ex. en funktionsprototyp i en deklarationsfil ändras, måste alla filer som beror på deklarationsfilen kompileras om. Om projektet innehåller många sådana filer kan man enkelt missa en eller två av dem om arbetet måste göras för hand. Därför behövs någon form av automatisering. </para>

<sect2 id="unixdev-buildsystems-make">
<title
>Byggprocessen</title>

<indexterm zone="unixdev-buildsystems-make">
  <primary
>bygg</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>Makefile</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>regel</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>omkompileringar</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>mål</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>beroenden</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>kommandon</primary
></indexterm>

<para
>Ett verktyg som tar hand om omkompileringar är <command
>make</command
>. Det håller reda på allt arbete med en uppsättning <emphasis
>regler</emphasis
>, som beskriver vad som ska göras i händelse någon viss information (oftast en källkods- eller objektkodsfil) ändrades. Alla regler som hör till ett visst projekt lagras i en så kallad <filename
>Makefile</filename
>, som behandlas av <command
>make</command
> så fort du vill uppdatera arbetet. </para>
<para
>Varje regel består av flera byggblock, närmare bestämt <itemizedlist>
  <listitem
><para
>ett <emphasis
>mål</emphasis
>, dvs filen som ska byggas </para
></listitem>
  <listitem
><para
>en uppsättning <emphasis
>beroenden</emphasis
>, i grunden namnen på de filer som målet beror på (t.ex. namnet på en källkodsfil, när målet är namnet på objektfilen som ska byggas) och </para
></listitem>
  <listitem
><para
>de <emphasis
>kommandon</emphasis
> som ska köras för att <quote
>bygga</quote
> målet (dvs. för att kompilera det eller länka ihop andra objektfiler för att skapa en körbar programfil). </para
></listitem>
</itemizedlist>
</para>
<para
>Enkelt uttryckt, läser kommandot <command
>make</command
> reglerna en i taget, kontrollerar varje fil i beroendelistan för ett givet mål, och bygger målet igen om någon av filerna har ändrats, med de kommandon som listas i regeln. </para>
<para
>Det finns flera ytterligare möjligheter att styra en sådan byggprocess, och en <filename
>Makefile</filename
> kan på så sätt växa sig mycket komplex. Vi kan inte gå in på detaljer här. Hur som helst, rekommenderar vi att du gör dig bekant med syntaxen för <command
>make</command
>. Även om du inte normalt använder det direkt, kan en förståelse för grunderna i byggsystemet vara användbar. Se <ulink url="info://make/Top"
><citetitle
>GNU make manualen</citetitle
></ulink
> för mer information. </para>
<para
>För mer detaljinformation specifik för &tdevelop;, se <link linkend="project-management"
>Bygga och projekthantering</link
> i den här handboken. </para>
<para
>Det finns flera handledningar tillgängliga, se <link linkend="automake-references"
>referenserna</link
> i kapitlet Bygga och projekthantering. </para>
</sect2
> <!-- unixdev-buildsystems-make -->

</sect1
> <!-- unixdev-buildsystems -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-guidevelopment">
<title
>Utveckling av grafiska gränssnitt</title>

<indexterm zone="unixdev-guidevelopment">
  <primary
>GUI</primary
></indexterm>
<indexterm zone="unixdev-guidevelopment">
  <primary
>grafiskt användargränssnitt</primary
></indexterm>
<indexterm zone="unixdev-guidevelopment">
  <primary
>användargränssnitt</primary>
  <secondary
>GUI</secondary
></indexterm>

<para
>Programutvecklare blir ännu mer belastade genom att de inte bara måste skapa programbibliotek och logiken, men också tillhandahålla lättanvända egenbyggda användargränssnitt som både är enkla att förstå och funktionella. De flesta programmerare får liten eller ingen utbildning i utveckling av grafiska gränssnitt, och som ett resultat är användargränssnitt ofta dåligt konstruerade. </para>
<para
>Under många år har några gemensamma designprinciper utvecklats. Du rekommenderas starkt att hålla dig till dem. På så sätt behåller ditt användargränssnitt ett gemensamt utseende och känsla, som användare av programmet tacksamt uppskattar. </para>
<para
>För utveckling av grafiska gränssnitt för &kde; finns en stilguide tillgänglig. Den finns som <ulink url="http://developer.kde.org/documentation/standards/kde/style/basics/index.html"
>&kde;:s guide för användargränssnitt</ulink
> på sidan &kde;:s utvecklingshörna. </para>
<para
>En kort introduktion till gemensamma principer för konstruktion av grafiska gränssnitt finns <ulink url="http://axp16.iie.org.mx/Monitor/v01n03/ar_ihc2.htm"
>här</ulink
>. </para>

</sect1
> <!-- unixdev-guidevelopment -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-ide">
<title
>Integration av koncept och verktyg: den integrerade utvecklingsmiljön</title>

<indexterm zone="unixdev-ide">
  <primary
>IDE</primary
></indexterm>
<indexterm zone="unixdev-ide">
  <primary
>integrerad utvecklingsmiljö</primary
></indexterm>
<indexterm zone="unixdev-ide">
  <primary
>utveckling</primary>
  <secondary
>IDE</secondary
></indexterm>
<indexterm zone="unixdev-ide">
  <primary
>miljö</primary>
  <secondary
>IDE</secondary
></indexterm>

<para
>Det finns separata verktyg tillgängliga för nästan varje steg i programmeringsprocessen: planering, redigering, processen för att hantera filer och kompilering, avlusning, dokumentation med mera. Men när projekten växer, blir programmeringsprocesserna troligtvis ganska omständliga. </para>
<para
>Mycket repetitivt arbete måste göras vid konstruktion, kompilering och avlusning av ett program. En hel del sådant arbete kan sparas genom att använda mallar och skript. Ytterligare arbete kan sparas genom att ha verktygen lätt tillgängliga, och med möjlighet att kommunicera med varandra i ett gemensamt grafiskt gränssnitt. </para>
<para
>Vore det till exempel inte bekvämt om en avlusare kunde öppna källkoden i fråga i en editor, och placera markören direkt på platsen för felet som just hittats? </para>
<para
>För att enklare uppnå ett sådant fall, togs <emphasis
>integrerade utvecklingsmiljöer</emphasis
> (IDE:er) fram. En sådan miljö integrerar alla mallar, verktyg och skript som ofta behövs i utvecklingsprocessen i en enda omgivning. </para>
<para
>&tdevelop; är en sådan integrerad utvecklingsmiljö för &kde;-plattformen. Den erbjuder ett brett spektrum av verktyg som underlättar programutveckling och underhåll, till och med för olika programspråk och olika plattformar. </para>

<sect2 id="unixdev-ide-tdevelop">
<title
>Grundläggande funktioner i &tdevelop; &kdevrelease;</title>

<indexterm zone="unixdev-ide-tdevelop">
  <primary
>&tdevelop;</primary>
  <secondary
>funktioner</secondary
></indexterm>
<indexterm zone="unixdev-ide-tdevelop">
  <primary
>funktioner</primary
></indexterm>

<!-- ### copied from web page, needs to be updated -->

<itemizedlist>
  <listitem>
  <para
>Hanterar alla <emphasis
>utvecklingsverktyg</emphasis
> som behövs för C++ programmering, som kompilator, länkare, avlusare och byggsystem.</para>
  </listitem>
  <listitem>
  <para
>Tillhandahåller en <emphasis
>programguide</emphasis
> som skapar fullständiga, körklara exempelprogram.</para>
  </listitem>
  <listitem>
  <para
>Låter användaren välja en <emphasis
>integrerad editor</emphasis
> baserad på &kde;:s programmeringseditor &kwrite;, TrollTechs <application
>Qeditor</application
> eller andra.</para>
  </listitem>
  <listitem>
  <para
>En <emphasis
>klassgenerator</emphasis
> för att skapa nya klasser och integrera dem i det nuvarande projektet.</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Filhantering</emphasis
> för källkod, deklarationer, dokumentation, etc. som ska ingå i projektet.</para>
  </listitem>
  <listitem>
  <para
>Hjälp med att <emphasis
>skapa en användarhandbok</emphasis
> för programmet skriven med &kde;-verktyg.</para>
  </listitem>
  <listitem>
  <para
>Automatisk HTML-baserad <emphasis
>dokumentation av programmeringsgränssnittet</emphasis
> för projektets klasser med korsreferens till använda bibliotek.</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Översättningsstöd</emphasis
> som gör det möjligt för översättare att enkelt lägga till sitt modersmål i projektet, inklusive stöd för &kbabel;.</para>
  </listitem>
  <listitem>
  <para
>Stöd för att hantera ett projekt via ett av flera <emphasis
>versionshanteringssystem</emphasis
> (t.ex. &CVS;), genom att tillhandahålla ett lättanvänt gränssnitt till funktionerna som oftast behövs.</para>
  </listitem>
  <listitem>
  <para
>Ett integrerat gränssnitt för <emphasis
>avlusning</emphasis
>.</para>
  </listitem>
  <listitem>
  <para
>En integrerad emulator av en <emphasis
>skalkonsol</emphasis
>.</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Syntaxfärgläggning</emphasis
> i källkodstext.</para>
  </listitem>
  <listitem>
  <para
>En funktion för <emphasis
>automatisk kodkomplettering</emphasis
> för klassvariabler, klassmetoder, funktionsargument med mera.</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Mallar för att skapa diverse projekt</emphasis
> (moduler i inställningscentralen, miniprogram i panelen &kicker;, I/O-slavar, insticksprogram till &konqueror; och skrivbordsstilar).</para>
  </listitem>
  <listitem>
  <para
>Fyra <emphasis
>trädvyer</emphasis
> för att enkelt byta mellan källkodsfiler, deklarationsfiler, klasser och dokumentation, vilket gör det onödigt med en extern filhanterare.</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Stöd för korskompilering</emphasis
>, med möjlighet att ange olika kompilatorer, kompilatorflaggor, målarkitektur etc.</para>
  </listitem>
  <listitem>
  <para
>Stöd för projekt med <emphasis
>Qt/Embedded</emphasis
> (som Zaurus och IPAQ).</para>
  </listitem>
  <listitem>
  <para
>Möjlighet att <emphasis
>inkludera vilket annat program</emphasis
> som helst som du behöver för utveckling genom att lägga till det i menyn <guimenuitem
>Verktyg</guimenuitem
>, enligt dina individuella behov.</para>
  </listitem>
</itemizedlist>

</sect2
> <!-- unixdev-ide-tdevelop -->

</sect1
> <!-- unixdev-ide -->

</appendix
> <!-- unixdev -->