BerndPol udvikling UNIX udvikling historie scriptsprog UNIX historie UNIX pipe UNIX skal skal UNIX Fra begyndelsen har Unix opretholdt to meget forskellige udviklingsmodeller. Den ene er sfæren af programmeringssprog for systemer og programmeringssprog, hvor en kildekode oversættes til maskinkode med en oversætter eller tolk. Programmeringssproget C er et eksempel på dette. Unix var den første operativsystemkerne som blev skrevet i et højniveausprog i stedet for den maskinnære assembler, som var almindeligt tidligere. (I virkeligheden blev sproget C til og med opfundet for at skrive Unix-kernen, og tilhørende programmer, på en DEC PDP-11 maskine.) Den anden model er sfæren med scriptsprog, som startede med opfindelsen af Unix-skallen, som samtidigt var operativsystemets brugergrænseflade — og et programsprog på meget højt niveau. Et skalscript bygges op af en mængde små værktøjer som f.eks. grep, sed og find. Hvert sådant værktøj er konstrueret til en afgrænset opgave. Tricket er at alle sådanne værktøjer kan forbindes med hinanden via en enkel overføringsmekanisme, der hedder pipe, som sender udskriften fra det foregående værktøj til indtastningen for den næste. Det giver grundlaget for en meget kraftfuld og fleksibel programmeringsmetode. Med tiden er begge sfærerne udviklet. Mens C stadigvæk i hovedsagen bruges som et systemprogrammeringssprog, har C++, som en variant af C beriget med objektorienterede og generiske udvidelser, fundet sin plads i udvikling af komplekse programmer i 1990'erne. Der er mange andre programmeringssprog, til og med ældre beholder deres plads — FORTRAN77 og Ada har f.eks. stadigvæk deres tilhængere specielt i numeriske programmer. På scriptområdet er der sket et skift væk fra skallen, som lider af flytbarhedsproblemer, til sprog som samler alle almindelige funktioner i standardbiblioteker, mens de stadigvæk kan have grænseflader mod omverden via pipes når det behøves. Alle scriptsprog har det tilfælles at de ofte er flytbare mellem mange Unix-varianter, &Microsoft; &Windows;, &MacOS; eller til og med VMS. Desuden har de alle implementeringer som kan distribueres frit. Perl scriptsprog Perl &perl; er blevet populært som tekstbehandlings- og systemadministrationssprog. Fra starten af internettet anvendtes CGI-scripter skrevet i &perl; som en udbredt måde at lave dynamiske netsider fra databaser. I dag er denne metode ofte erstattet med pluginnet mod_perl for net-serveren &apache;. Blandt &perl;s styrker er dets indbyggede støtte for avancerede regulære udtryk, og rige arkiver med frit distribuerede moduler. For mere information se hjemmesiden Comprehensive Perl Archive Network (CPAN). Python scriptsprog Python &python; skinner med elegancen i sit klassesystem og enkelheden og fleksibiliteten som ydre biblioteker kan pakkes ind i, på en sådan måde at de ser ud til at være standardklasser og -funktioner i &python;. I modsætning til &perl;, har &python; en klar og koncis indlejringsgrænseflade, som gør den til det bedste valg for at muliggøre scripter for C og C++ programmer. PHP scriptsprog PHP &php; blev opfundet som et sprog til direkte indlejring på &HTML;-sider, og har af den grund hovedbrugen at leverere dynamisk indhold for nettet. Højere-niveau UNIX-programmer mangler sædvanligvis den hastighed og fleksibilitet som de traditionelle tegn-orientede skal-script mekanismer har. Dette er især sandt i verdenen af grafiske brugergrænseflader (GUI) som f.eks. &kde;. Der har været forsøg på at sørge for lignende mekanismer som vil virke på et højere programniveau, især CORBA og, i &kde;-miljøet, &DCOP;. CORBA scriptsprog CORBA kommunikation CORBA CORBA (Common Object Request Broker Architecture) er et forsøg på at lade computerens programmer arbejde sammen henover netværk. Det blev lavet af den private, leverandøruafhængige OMG (Object Management Group) standardkomite. CORBA-baserede programmer bruger IIOP standardprotokollen til at kommunikere. Implementationer baseret på IIOP er tilgængelige på et vidt område af operativsystemer, programmeringssprog og netværk og er således ekstremt flytbart. Hovedbagdelen ved CORBA er dens temmelig langsomme hastighed. Mens dette kan tolereres i netværk, er det en ægte hindring for interprogram kommunikationer i et miljø uden netværk såsom &kde; kørende på en enkelt computer. DCOP scriptsprog DCOP kommunikation DCOP En anden udvikling af UNIX-lignende scripter er DCOP-protokollen som blev lavet til kommunikation mellem &kde; programmer for at komme ud over CORBA's begrænsninger. &DCOP; betyder Desktop COmmunikation Protocol (protokollen for desktopkommunikation), og er implementeret som en enkel IPC/RPC-mekanisme bygget til at virke via udtag. Sluteffekten er at tilbyde funktioner som ligner den traditionelle pipe-mekanisme i Unix. Traditionelle skalscripter er baserede på ganske små programværktøjer, som blev konstrueret til at virke baseret på ren tekst. &DCOP; tillader at avancerede grafiske programmer kommunikerer med hinanden på en tilsvarende måde. Det gør det for eksempel muligt for et &kde;-program at sende meddelelser til et andet &kde;-program, eller tage imod data fra det til sine egne formål. Der er dog bagdele. For at bruge &DCOP;, skal programmet være konstrueret med en speciel &DCOP;-grænseflade. Desuden går &DCOP;-kommunikationsprocessen noget langsomt (selvom den går hurtigere end CORBA). Alligevel så giver det meget af styrken og fleksibiliteten i Unix-scripter til højniveauprogrammer som er baserede på en grafisk brugergrænseflade. For yderligere information, se DCOP Desktop COmmunication Protocol library artiklen eller The &DCOP; Desktop Communication Protocol library, dokumentation af brugergrænsefladen for &kde;'s DCOP-bibliotek. Undtagen i meget enkle tilfælde, vil programmeringsprojekter bestå af mange byggeblokke med kildekode, hvert af dem placeret i en enkelt fil for enklere vedligeholdelse. For at få alt til at køre, skal du effektivt kunne oversætte alt dette til nogen få maskinkodeenheder med passende format, som gør at operativsystemet kan indlæse og køre programmet. For at opnå dette, er de grundlæggende værktøjer du behøver en teksteditor til at skrive kildekodefilerne, et oversættelsesprogram, oftest en oversætter til at lave kildekoden om til objektfiler, et biblioteksprogram som samler objektfiler i biblioteker, som nemt kan genbruges uden at behøve at kompileres igen, en linker, som binder flere objektfiler og biblioteker sammen til et kørbart program, et byggesystem, som tilbyder nogle måder at håndtere alt dette, og ikke at forglemme, en fejlsøger til (forhåbentlig) at finde alle fejl i programmet, og muligvis yderligere diagnoseværktøjer for at få alt til at køre smidigt. Når man har et stort projekt, som kan bestå af op til hundredvis af kildekodefiler, kan kompileringsprocessen blive rigtigt arbejdsintensiv. Man vil ikke kompilere alle filer om hver gang en af dem er ændret. I stedet vil man kun kompilere de filer om som er påvirket af ændringen. I almindelighed er det ikke klart hvilke det er. Når en funktionsprototype i en deklarationsfil er ændret, skal alle filer som afhænger af deklarationsfilen kompileres om. Når du f.eks. ændrer en funktionsprototype i en deklarationsfil, skal du kompilere hver fil som inkluderer denne deklarationsfil. Hvis dit projekt indeholder mange sådanne filer, kan du nemt glemme en eller to af dem hvis du skal gøre det manuelt. Således er automatiseringsmetoder en nødvendighed. make Makefile regel genkompileringer mål afhængigheder kommandoer Et værktøj som tager sig af omkompileringer er make. Det holder styr på alt arbejde med et sæt regler, som beskriver hvad der skal gøres hvis en vis information (oftest en kildekode- eller objektkodefil) er ændret. Alle regler som hører til et vist projekt opbevares i en såkaldt Makefile, som behandles af make så snart du vil opdatere dit arbejde. Hver regel består af flere byggeblokke, nærmere bestemt et mål, &ie; filen som skal bygges et sæt afhængigheder, egentlig navnene på de filer som målet afhænger af (⪚ navnet på en kildekodefil, når målet er navnet på objektfilen som skal bygges) og de kommandoer som skal køres for at make målet (dvs. for at kompilere det eller linke det sammen med andre objektfiler for at lave en kørbar programfil). Enkelt udtrykt, læser kommandoen make reglerne en af gangen, kontrollerer hver fil i afhængighedslisten for et givet mål, og bygger målet igen hvis nogen af filerne er ændrede, med de kommandoer som er på listen i den regel. Der er adskillige yderligere muligheder for at styre en sådan byggeproces, og en Makefile kan således vokse og blive meget kompleks. Vi kan ikke gå ind på detaljer her. Under alle omstændigheder, anbefaler vi at du gør dig bekendt med syntaksen for make. Selv om du ikke normalt bruger det direkte, kan en forståelse for det fundamentale i byggesystemet være nyttigt. Se GNU make manualen for mere information. For mere detaljeret information specifik for &tdevelop;, se Bygge og projekthåndtering i denne håndbog. Der er flere vejledninger tilgængelige, se referencer i kapitlet Bygge og projekthåndtering. GUI grafisk brugergrænseflade brugergrænseflade GUI Programudviklere bliver endnu mere belastede ved at de ikke kun skal lave programbibliotekerne og logikken, men også sørge for let anvendelige egenbyggede brugergrænseflader som både er nemme at forstå og funktionelle. De fleste programmører får lidt eller ingen uddannelse i udvikling af grafiske grænseflader, og som et resultat er brugergrænseflader ofte dårligt konstruerede. Gennem mange år er nogle fælles designprincipper blevet udviklet. Du anbefales stærkt at holde dig til dem. På den måde beholder din brugergrænseflade fælles udseende og fornemmelse, hvilket brugere af programmet vil sætte pris på. For udvikling af grafiske grænseflader for &kde; er der en stilguide tilgængelig. Den findes som &kde;'s guide for brugergrænseflade på siden &kde;'s udviklingshjørne. En kort introduktion til almindelige GUI design-principper kan findes her. IDE integreret udviklingsmiljø udvikling IDE miljø IDE Der er separate værktøjer tilgængelige for næsten hvert skridt i programmeringsprocessen — planlægning, redigering, processen for at håndtere filer og kompilering, fejlsøgning, dokumentation med mere. Men når projekterne vokser, bliver programmeringsprocessen sandsynligvis ganske omstændelig. Meget gentagent arbejde skal gøres ved konstruktion, kompilering og fejlsøgning af et program. En hel del arbejde kan gemmes ved at bruge skabeloner og scripter. Yderligere arbejde kan gemmes ved at have værktøjer let tilgængelige, og med mulighed for at kommunikere med hinanden i en fælles grafisk grænseflade. For eksempel — ville det ikke være bekvemt hvis en fejlsøger kunne åbne kildekoden det drejer sig om i en editor, og placere markøren direkte på stedet for fejlen som netop blev fundet. For nemmere at opnå et sådant system kom integrerede udviklingsmiljøer (IDE) frem. Et sådant miljø integrerer alle skabeloner, værktøjer og scripter som behøves i udviklingsprocessen i en enkelt omgivelse. &tdevelop; er et sådant integreret udviklingsmiljø for &kde;-platformen. Den tilbyder et bredt spektrum af værktøjer som letter programudvikling og vedligeholdelse, til og med for forskellige programsprog og forskellige platforme. &tdevelop; funktioner funktioner Håndterer alle udviklingsværktøjer som behøves for C++ programmering, såsom oversætteren, linkeren, fejlsøgeren og byggesystemet Sørger for en programguide som laver fuldstændige, køreklare eksempelprogrammer Tillader brugeren at vælge en integreret editor baseret på &kde;'s programmeringseditoren &kwrite;, Trolltec's QEditor, eller andre. En klassegenerator til at oprette nye klasser og integrere dem i det nuværende projekt Filhåndtering for kildekode, deklarationer, dokumentation, osv. som skal indgå i projektet Hjælp med at lave en brugerhåndbog for programmet skrevet med &kde;-værktøjer. Automatisk &HTML;-baseret dokumentation af programmeringsgrænseflade for projektets klasser med krydsreference til de brugte biblioteker Oversættelsesunderstøttelse som gør det muligt for oversættere enkelt at tilføje deres modersmål til projektet, inklusive understøttelse for &kbabel;. Støtte for at håndtere et projekt via et af adskillige versionssystemer (f.eks. &CVS;), ved at sørge for en letanvendelig grænseflade til funktionerne som oftest behøves En integreret fejlsøger forende. En integreret skal-konsol emulator. kommentarer i deklarationsfiler og kildekodefiler. Automatisk kodekomplettering for klassevariabler, klassemetoder, funktionsargumenter med mere Skabeloner til at oprette diverse projekter (moduler i kontrolcentret, miniprogrammer i panelet &kicker;, I/O-slaver, plugin til &konqueror; og desktopstiler) Fire navigationstrævisninger for nemt at kunne skifte mellem kildekodefiler, deklarationsfiler, klasser og dokumentation, hvilket gør det unødvendigt med en ekstern filhåndtering Støtte for krydskompilering, med mulighed for at angive forskellige oversættere, oversætterflag, målarkitektur osv. Støtte for projekter med Qt/Embedded (som Zaurus og IPAQ) Mulighed for inklusion af et hvilket som helst andet program du behøver til udvikling ved at tilføje det i menuen Værktøjer, ifølge dine individuelle behov