path: root/tde-i18n-sv/docs/kdevelop/kdevelop/unixdev.docbook

<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 -->