Användarmanual KDevelop
Copyright © 2002 Bernd Gehrmann
Copyright © 2002 Caleb Tennis
Copyright © 2004 Bernd Pol
Copyright © 2005 Volker Paul
Härmed ges tillåtelse att kopiera, distribuera och/eller ändra detta dokument under villkoren i GNU Free Documentation License, Version 1.1 eller någon senare version publicerad av Free Software Foundation; utan invarianta avsnitt, utan framsidestexter och utan baksidestexter. En kopia av licensen inkluderas i avsnittet som heter "GNU Free Documentation License".
KDevelop är en integrerad utvecklingsmiljö som kan användas för ett brett spektrum av programmeringsaktiviteter.
Innehållsförteckning
Figurförteckning
Tabellförteckning
Den här användarmanualen är avsedd att beskriva innehållet och användningen av den integrerade utvecklingsmiljön (IDE) KDevelop 3.3.91 från användarens perspektiv. Det är inte en programmeringsmanual, och inte heller beskriver den utvecklingsprocessen i detalj. Det enda målet är att hjälpa dig med hanteringen av den integrerade utvecklingsmiljön.
Här hittar du information om följande ämnen:
Ger dig en snabb genomgång av hur det grafiska gränssnittet används, med en introduktion av de grundläggande stegen för att arbeta med ett projekt.
Fördjupar den guidade turen i föregående kapitel, ger en översikt av vad som är inbyggt i KDevelop och gör dig bekant med utseendet och känslan i den integrerade utvecklingsmiljön.
Visar hur du kan skräddarsy den integrerade utvecklingsmiljön för att passa dina behov.
Beskriver grunderna i hur ett nytt projekt ställs in i KDevelop med den inbyggda programguiden.
Allt du behöver för att skriva källkoden. Från hur editorn används, hur textsökning både lokalt och i hela projektet görs, till hur nya filer och klasser integreras i projektet.
Demonstrerar diverse verktyg för att titta på projektets struktur och hur du kommer åt filerna du vill arbeta med.
Beskriver ett av de mest kraftfulla verktygen i KDevelop, som låter dig navigera i klassberoenden och låter dig enkelt skapa och komma åt de klasser och metoder du behöver.
Visar hur man kommer åt den omfattande inbyggda dokumentationen som KDevelop tillhandahåller, och talar om hur du skapar dokumentation av projektet, en koncis och kraftfull dokumentation av programmeringsgränssnittet, som ger dig en översikt över all källkod i projektet samt en docbook-baserad användardokumentation.
Handlar om att skapa och hantera projekt, beskriver grunderna i användning av autoconf och automake, samt hur egna byggfiler skapas och hur kompilator- och bygginställningar används för att skräddarsy programmet för att passa dina behov.
Tittar på sätt att hålla flera bygginställningar, för att korskompilera till olika plattformar, eller skapa inbyggda system med biblioteket Qt/embedded.
Beskriver hur det integrerade avlusargränssnittet till avlusaren gdb används, så att du kan jaga fel utan att lämna KDevelop.
Talar om för dig hur du kan underhålla projektet med CVS-versionshanteringssystem, en nödvändighet särskilt om många utvecklare arbetar med samma projekt.
En del ofta använd information har placerats i appendix. Bland annat består den av:
Talar om var man skaffar KDevelop, och hur man får det att köra.
En snabbreferens till de oftast använda kommandona och åtgärderna, och en kort guide för att lösa vanliga problem vid arbete med KDevelop.
En historisk översikt över programutveckling på UNIX®, de viktigaste verktygen som behövs och varför man behöver en integrerad utvecklingsmiljö.
Listar filerna som KDevelop använder för att spara sin interna information. Detta är särskilt användbart om något har blivit fel i dina inställningar.
Listar insticksverktygen du kan använda för att skräddarsy KDevelops möjligheter för dina behov.
Visar lägen för användargränssnittet.
Hämta information, rapportera fel, etc.
Visar dokumentets historik.
Bibliografi
När du nu har installerat KDevelops integrerade utvecklingsmiljö, hur ska du använda den på ett bra sätt? Eftersom det här är ett komplext program, kan inlärningskurvan vara något brant, särskilt om du inte redan är van vid den här sortens integrerade utvecklingsmiljö.
Vi försöker att göra inlärningskurvan mindre brant genom att stegvis gå igenom hur ett enkelt KDE C++ program skapas. Därigenom tar vi en (översiktlig) titt på:
Innan vi börjar, måste ett viktigt begrepp klargöras.
Vad kan man förvänta sig? Som sagt är KDevelop en integrerad utvecklingsmiljö. Det betyder väsentligen att KDevelop inte själv är ett utvecklingsverktyg, utan snarare ett grafiskt gränssnitt för att enkelt komma åt ett omfattande antal utvecklingsverktyg, där många i själva verket skulle kräva komplicerade tangentbordskommandon om de kördes i en textterminal.
Även om KDevelop förenklar många av dessa programmeringsuppgifter, återstår ändå mycket av komplexiteten i denna uppsättning verktyg, vilket betyder att för en fullständig förståelse av den integrerade utvecklingsmiljön KDevelop måste du ändå begripa dig på verktygen som verkligen körs i bakgrunden.
Därför kan vi inte lära dig hur man skapar programvara, utan snarare introducera några av de sätt KDevelop konstruerats för att förenkla denna process. Om du vill lära dig mer om vad en integrerad utvecklingsmiljö är avsedd för, kan du ta en titt på den historiska översikten Utveckling på UNIX®, i synnerhet kapitlet Integration av koncept och verktyg.
Följande beskrivning gäller normalfallet, där KDevelop startar med Förenklat IDEA-fönsterläge. Om du redan har bytt till ett annat användargränssnitt, kanske inte vissa objekt finns enligt beskrivningen, eller beter sig något annorlunda. Om du inte är säker på vilket användargränssnitt som KDevelop för närvarande använder, kontrollera i dialogrutan ->->.
Här handlar det enbart om vad du ser när du först startar KDevelop. Du finner preliminär information om:
| Vad är det som syns på ytan? |
| Hur man får hjälp. |
| Vad finns i menyerna? |
| Vad är verktygsvyerna till för? |
När du startar KDevelop allra första gången ser du en skärm som liknar den här:
Ursprunglig layout i KDevelop
(I själva verket är KDevelops ursprungliga fönster större, men elementen du ser är samma.)
Arbetsområde och verktygsflikar. I det här ursprungliga fallet använder KDevelop det så kallade IDEA-användargränssnittet. Ett maximalt stort arbetsområde omges till vänster, under, och till höger av en serie knappar som fungerar på liknande sätt som flikarna på en skärm med flikar. Om du klickar på en av flikarna visas ett så kallat verktygsvyfönster, som låter dig arbeta med en speciell aktivitet.
Menyer och verktygsrader. Längst upp finns den vanliga menyraden, följd av flera rader med verktygsrader, där vissa är tomma från början. De förses med knappar så fort ett projekt har öppnats för verkligt arbete.
Statusrad. Till sist finns en statusrad längst ner i fönstret, som visar kortfattad information om flera aktiviteter.
Förutom menyn , som erbjuder svar på specifika frågor, tillhandahåller statusraden och två olika sorters verktygstips en del snabbinformation.
Vad gör det här menyalternativet? När du placerar muspekaren över ett menyalternativ, visas oftast kortfattad information i statusraden. Även om det i de flesta fall bara upprepar alternativets namn, tillhandahålls ibland ytterligare information om menyalternativets syfte.
Vad är det här objektets namn? För många objekt visas ett kort verktygstips med funktionsnamnet när du håller markören över det några sekunder. Det är användbart för snabb orientering i verktygsrader eller verktygsvyflikar i IDEA-läge, när den integrerade utvecklingsmiljön har ställts in att bara visa ikoner på dessa knappar.
Vad gör det här objektet? Mer information är tillgänglig genom utökad hjälp med verktygstips för många objekt i den integrerade utvecklingsmiljön. Välj -> eller tryck på Skift-F1, välj därefter objektet som du vill veta mer om med markören i form av ett frågetecken. Du kan också visa vilken meny som helst på detta sätt, och klicka på ett visst menyalternativ (både aktiva och inaktiva) för att se om mer information finns tillgänglig.
Det finns tio menyer som kan väljas i menyraden. De flesta förses med alla alternativ när ett projekt väl har öppnats för verkligt arbete, medan andra kräver att att minst ett dokument är öppnat. I korthet tillåter de följande sorters åtgärder.
Det här är bara en översikt. För en detaljerad beskrivning av menyerna, se Kommandoreferensen.
Vanliga åtgärder. Detta är ganska standardmässigt. Det tillåter att dokumentfiler skapas, öppnas, sparas, skrivs ut och stängs, samt att avsluta programmet KDevelop som vanligt.
Återställ alla. Låter dig återställa alla senaste ändringar som ännu inte sparats, genom att ladda filen igen från disk. Det fungerar för alla filer du redigerar, inte bara de som ingår i ett projekt.
Den här menyn är bara användbar om ett dokument är öppnat.
Vanliga åtgärder. Tillhandahåller de vanliga åtgärderna för att ångra, göra om och klippa ut, kopiera eller klistra in. Dessutom tillåter den att markera textblock på olika sätt.
Sök och ersätt. Det finns två mycket kraftfull sökfunktioner tillgängliga, -> och ->. Förutom de vanliga sök- och ersättningsfunktionerna begränsade till det nuvarande dokumentet, kan du dessutom utföra globala sök- och ersättningsåtgärder på en gång.
Avancerad textredigering. Det finns möjlighet att formatera om nuvarande dokument och att automatiskt komplettera delvis inskriven text på olika sätt.
Som menyn , är den här menyn bara användbar om ett projekt är öppet. I detta fall är (bland annat) följande alternativ tillgängliga:
Navigeringshistorik. Byt fram och tillbaka mellan dokumenten du tittat på, etc.
Felspårning. Navigera till källkodsraderna för fel som stöttes på i den senaste kompilerings- eller byggprocessen.
Åtgärder som hör ihop med editorn. Visa alternativ i menyn styr utseendet och vyn för editorn du använder. När det gäller Kate-programdelen (den inbäddade avancerade texteditorn) finns följande alternativ tillgängliga:
Styr radbrytningsbeteendet i dokumentfönstret.
Visa eller dölj olika kolumner längs dokumentfönsterkanter: radnummer, ikoner och dessutom bokmärken i rullningslisten.
Styr visning av ihopdragna (tillfälligt dolda) avsnitt i en källkodstext.
Allt arbete i KDevelop är baserat på projekt, som i grunden samlar källkodsfiler, bygghanteringsfiler och annan information i en projektkatalog. Med den här menyn bestämmer du vilket projekt som används, vilka egenskaper det har och några andra hanteringsalternativ. I synnerhet:
Öppna ett projekt. Tillåter att nya projekt skapas, befintliga öppnas och import av projekt från andra miljöer.
Projektalternativ. Gör det möjligt att definiera en hel mängd olika projektegenskaper.
Klasshantering. Lägg till nya klasser i projektet och gå igenom arvträdet för en klass.
Distribuera projekt. Hjälper till att bygga paket för distribution av projektet.
Den här menyn handlar helt och hållet om att kompilera och dokumentera projektet. Sålunda är den bara användbar när ett projekt verkligen är öppet. I detta fall tillhandahåller den följande alternativ:
Kompilera, länka och köra. Tillåter att hela projektet eller delar av det kompileras och länkas, samt kör programmet inifrån den integrerade utvecklingsmiljön.
Förberedande byggåtgärder. Det här beror i själva verket på byggsystemet som du använder för projektet. I fallet med automake-projekt tillåter de att köra Makefile.cvs och configure enskilt. Det finns också möjlighet att ta bort skapade filer från projektet, på olika nivåer.
Installera programmet. Tillåter att programmet installeras, både i lokala kataloger och i systemkataloger som bara är tillgängliga för systemadministratören.
Dokumentation av programmeringsgränssnittet. Bygg eller ta bort dokumentation av projektets programmeringsgränssnitt baserad på doxygen, enligt definitionen i projektalternativen.
Även om menyn fylls i så fort ett projekt är aktivt, är den förstås bara användbar om själva projektet tidigare har kompilerats med avlusningsinformation (det ställs i huvudsak in under ->). I detta fall finns följande alternativ tillgängliga:
Vanliga avlusningsåtgärder. Den första delen i menyn tillhandahåller ett grafiskt gränssnitt till GDB, GNU:s symboliska avlusare. Den gör det möjligt att starta och stoppa programmet i avlusaren och stega igenom det på olika sätt.
Brytpunkter. KDevelop tillhandahåller flera möjligheter att ange brytpunkter i programmets källkod. Ett är genom användning av menyalternativet .
Avancerad avlusning. Andra alternativ i menyn tillåter mer avancerad analys av programmet. Använd Skift-F1 för att få mer information om deras syfte.
Du kan anropa diverse skript från menyn för att enklare åstadkomma långtråkiga ändringar av texten i editorfönstret som för närvarande används. Tillgängliga åtgärder beror dock på skriptet som väljes.
Det här är ganska standardmässigt. Du kan välja alla öppna dokumentfönster samt stänga ett eller flera dokumentfönster här. Du kan till och med välja en uppsättning dokumentfönster som ska stängas på en gång.
Beroende på editorinsticksprogrammet du använder, kanske det också finns andra menyalternativ. Kate, det förvalda editorinsticksprogrammet, tillåter exempelvis också att editorfönstret delas horisontellt eller vertikalt.
KDevelop är mycket anpassningsbart. Du kan välja din favoriteditor för dokument samt tillhandahålla externa och insticksverktyg för att utöka funktionerna i den grundläggande integrerade utvecklingsmiljön. Menyn avspeglar de flesta av dessa inställningar.
Avancerad redigering. Den övre delen av menyalternativ i tillhandahålls av editorinsticksprogrammet som används. Du kan välja din favoriteditor via ->+Editor. Så fort en redigerbar dokumentfil väljes, tillhandahåller den övre delen av menyn avancerade redigeringskommandon, specifika för editorn som används.
Hantering av webbsidor. Om det aktiva dokumentfönstret innehåller en HTML-sida (som t.ex. visas från Dokumentation), visar ytterligare menyalternativ som tillhandahåller olika sätt att hantera webbsidor.
Övriga verktyg. Oftast finns det en mängd andra alternativ enligt de verktyg som för närvarande är tillgängliga. Använd Skift-F1 för att få mer information om deras syfte.
Den här menyn låter dig visa och dölja menyraden, verktygsrader och statusraden. Dessutom kan du anpassa genvägar, verktygsrader, underrättelser, editorn och KDevelops allmänna beteende.
Här kan du visa KDevelops handbok, slå upp begrepp i diverse dokumentationsfiler, visa manualsidor (det traditionella Unix manualformatet) och infosidor (GNU manualformatet). Dessutom kan du rapportera fel och få viss information om den nuvarande versionen av KDevelop och dess upphovsmän.
Med användargränssnittet IDEA-fönsterläge omges arbetsytan av tre rader med knappar, så kallade verktygsvyflikar. De gör att man kan komma åt verktygsvyfönster som åstadkommer viktiga uppgifter under programvaruutvecklingen. Var och en av dessa tre rader verktygsvyer tjänar olika huvudsyften.
Vänster sida. Ger möjlighet att komma åt verktyg för navigering och urval.
Underkanten. Vyerna visar meddelanden som skapas av olika verktyg.
Höger sida. Ger möjlighet att komma åt dokumentation och verktyg för källkodshantering.
Antal verktygsvyflikar som visas kommer att ändras när ett projekt väl har öppnats att arbeta med. Fler verktyg för att arbeta med projektet kommer då att vara tillgängliga. Det verkliga antalet verktygsvyer beror på de insticksverktyg som för närvarande är tillgängliga i KDevelop. Du hittar mer om detta ämne i kapitlet Anpassa KDevelop.
För närvarande, när inget projekt är öppet, och det normala antalet insticksverktyg är laddade, finns följande verktygsvyer. Genom att klicka på en flik öppnas eller stängs verktygsvyns fönster.
Filväljare. Tillhandahåller en ruta för att navigera i katalogträdet och välja filer att arbeta med precis som du gör i Konqueror. Att klicka på en fil öppnar den i ett lämpligt redigeringsfönster på arbetsytan. Ett högerklick i filväljarens område gör att en meny för navigering och filhantering visas.
Fillista. Listar filer som för närvarande är öppna. Att klicka på en fil väljer oftast dess redigeringsfönster på arbetsytan. Använd det för att snabbt navigera bland ett stort antal öppna filer. Dessutom ger vyn ett sätt att organisera öppna filer i olika sessioner. Det är särskilt användbart i mycket stora och komplexa projekt, för att hjälpa utvecklaren att koncentrera sig på olika uppgifter. Att högerklicka på en fil gör att en filhanteringsmeny dyker upp.
Program. Visar utmatningen från ett program som startas inifrån KDevelop.
Jämförelse. Används för att visa innehållet i filer med programfixar. Visar utmatningen från verktyget för visning av skillnader, som startas från menyn ->.
Meddelanden. Visar meddelanden som skapas av byggverktygen som anropas inifrån KDevelop, oftast från menyn .
Sök i filer. Visar listan med objekt som hittas av den allmänna sökfunktionen som startas från menyn ->. Genom att klicka på en rad här, öppnar automatiskt filen på angiven position i ett redigeringsfönster.
Ersätt. Listar resultat av den allmänna sök- och ersättningsfunktionen som startas från menyn ->. I den vyn kan du för varje hittat objekt bestämma dig för om du verkligen vill ersätta det eller inte.
Den allmänna sök- och ersättningsfunktionen är i själva verket bara tillgänglig efter ett projekt har laddats i KDevelop. Annars är verktyget i menyn -> inte aktiverat.
Konsol. Öppnar ett terminalemuleringsfönster som liknar Konsole i KDE där du kan använda tangentbordskommandon med ett traditionellt UNIX® kommandoradsgränssnitt.
Dokumentation. KDevelop ger tillgång till en mängd dokumentation via det här verktyget. Här kan du komma åt dokumentfiler, oftast direkt från en annan dator, på ett strukturerat sätt. Det finns flera sätt att direkt komma åt värdefull information från handböcker om KDE och Qt™.
Se kapitlen Dokumentation och Anpassa dokumentationen för mer information.
Kodsnuttar. Verktyget låter dig lagra utvald text permanent för senare användning vid andra redigeringsomgångar. Det är ett mycket flexibelt verktyg, eftersom alla textsnuttar som lagras här kan innehålla en uppsättning variabler, som får sina verkliga värden när en sådan textsnutt infogas i någon annan text.
Mer information om detta är tillgänglig i kapitlen Kodsnuttar och Ställa in verktyget för kodsnuttar.
Innan vi påbörjar det första exempelprojektet på riktigt, bör vi anpassa KDevelops beteende efter våra behov. Även om de flesta standardinställningarna redan är lämpliga, finns det några ställen som det vore bra att ändra.
Om du vill veta mer om inställning av KDevelop, ta en titt på kapitlet Anpassa KDevelop.
Klicka på menyn för att anpassa KDevelop och välj . Dialogrutan Anpassa KDevelop dyker upp, och visar följande inställningssida, Allmänt, till höger.
Den allmänna inställningsdialogrutan i KDevelop
De flesta standardinställningarna är ok, men två av inställningarna kanske du vill ändra.
Standardprojektkatalog. När KDevelop startas för första gången är den troligen förinställd till din hemkatalog. De flesta föredrar dock en särskild projektkatalog för programvaruutveckling. Ändra textrutan till huvudkatalogen för utveckling som du föredrar. Du kan välja det i katalogträdet om du klickar på knappen Öppna fildialog markerad med en katalogikon, till höger om textrutan.
I vårt exempel antar vi (i brist på bättre) en användare som kallas utvecklare. Ersätt därför alltid “utvecklare” med ditt användarnamn. Vår utvecklare utnyttjar huvudkatalogen /home/utvecklare/projekt för själva utvecklingen. Återigen, ersätt projekt med namnet på din utvecklingskatalog.
KDevelop skapar normalt en egen underkatalog under huvudkatalogen för varje nytt projekt du skapar. Alla filer i ett projekt som till exempel heter “Hello” kommer i vårt fall att placeras i katalogen /home/utvecklare/projekt/hello.
Du kan förstås tillfälligt överskrida dessa kataloginställningar om du behöver det. Se kapitlet Programguide för mer information om det.
Kompilatorutmatning. Så fort KDevelop kompilerar någon källkod, visas meddelanden från byggverktygen, som make, i fönstret Meddelanden längst ner på arbetsytan. Oftast är meddelandena överväldigande ordrika. För att få en bättre överblick av vad som händer, har KDevelop ett antal inbyggda sätt att förkorta meddelandena.
Beroende på vilken version av KDevelop du använder, kan inställningen Kompilatorutmatning vara förinställd till “fullständig”, vilket gör att allt innehåll i meddelanden visas i sin helhet. Du vill nog ändra det till den mycket mer praktiska inställningen “mycket kort”. Välj den helt enkelt i kombinationsrutan.
Var medveten om att bara den mest grundläggande informationen visas i fönstret Meddelanden med denna inställning. Om fel skulle uppstå när du bygger, behöver du troligen se mer av, om inte hela, meddelandetexten. Meddelandena är dock inte borta. Högerklicka bara i fönstret Meddelanden och välj t.ex. “Fullständig kompilatorutmatning” i den sammanhangsberoende menyn.
Det finns en annan, inte så uppenbar, inställning som helst ska göras innan själva utvecklingsarbetet påbörjas. Det beror på att du regelbundet kommer att vilja göra sökningar i dokumentationen under utvecklingen. KDevelop kräver att ett antal sökindex skapas innan en sådan sökåtgärd kan genomföras. Låt oss initiera dem innan vi utför de första stegen i det verkliga arbetet med KDevelop.
Öppna verktygsvyn Dokumentation på höger sida i KDevelops huvudfönster. Öppna där dialogsidan Sök.
Var sökindex ska skapas.
Klicka nu på knappen för att försäkra dig om att de grundläggande sökverktygen är riktigt inställda. En dialogruta ska dyka upp, som säger “Configuration file updated”. Klicka på för att stänga den.
När det här är gjort, är KDevelop klar att tolka känd dokumentation och bygga några användbara sökindex från den. Klicka på knappen till höger. Nu dyker dialogrutan Skapar sökindex upp, och visar förloppet när index skapas.
KDevelop skapar sökindex för dokumentation.
Det tar en viss tid beroende på dokumentationens storlek och datorns prestanda. Men till sist ändras knappen till . Klicka bara på knappen för att fortsätta.
Det bör normalt fungera direkt, men i vissa fall kanske inte programmet htdig som KDevelop använder för att utföra fulltextsökning kanske inte är riktigt inställt. Titta i kapitlet Inställning av index för textsökning för mer hjälp i detta fall.
För att kunna slå upp specifik information om KDE:s och Qt™:s programmeringsgränssnitt, krävs att KDELibs Apidocs fanns när KDevelop installerades. Om du har problem med att skapa index eller utföra exemplen med uppslagning av identifierare senare i kapitlet, försäkra dig om att dokumentationen finns och att KDevelop kan komma åt den. Se Installera KDevelop för mer information.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Nästan alla program består av dussintals, hundratals eller till och med tusentals filer som måste hållas strukturerade och möjliga att underhålla. För att åstadkomma det, organiserar KDevelop utveckling av programvara i projekt. Därför är det första praktiska steget för att utvecklar programvara i KDevelop oftast att skapa ett nytt projekt.
Tursamt nog är det ganska lätt att åstadkomma det. KDevelop tillhandahåller verktyget Programguide för att göra det. (Se kapitlet Komma igång: Programguiden för mer information.)
Nu skapar vi ett enkelt KDE-programprojekt för att åskådliggöra hur enkelt det kan åstadkommas, och vilka filer och verktyg som KDevelop tillhandahåller. Därigenom tar vi en snabbtitt på:
| Hur man skapar ett nytt projekt med hjälp av programguiden. |
| Vilka filer som programguiden skapade från början. |
| Vad som gäller för de ytterligare verktygsvyer som visas ihop med projektet? |
Låt oss skapa ett ganska enkelt KDE-projekt, “Hello World”. Utför bara följande steg:
Klicka på menyalternativet -> för att starta programguiden.
Dialogrutan Skapa nytt projekt dyker upp. I fönstret längst upp till vänster, Alla projekt, finns ett antal programspråk listade.
Vi vill bygga ett vanligt KDE-program i C++. Klicka därför på knappen + till vänster om C++ för att visa innehållet.
En uppsättning möjliga programtyper visas. Vi ska bygga ett KDE-program, och visa därför nästa undernivå via knappen + intill KDE.
Nu erbjuds du ett antal möjliga projektmallar. Gå till början av listan och klicka på Enkelt KDE-program.
En förhandsgranskning och kort beskrivning av programmet som projektmallen kommer att skapa dyker upp i de två fönstren till höger.
Välja projektmallen “Hello World”
Vårt program behöver ett namn. Hitta rutan Egenskaper längst ner i dialogrutan och skriv in ett lämpligt namn i inmatningsfältet Programnamn.
Vi använder “Hello” i vårt exempel, men du kan använda vad du vill, under förutsättning att namnet bara består av bokstäver, siffror och understreck. Du kommer att märka att programguiden inte accepterar några andra tecken.
Försäkra dig om att textrutan Plats under inmatningsfältet visar namnet på huvudkatalogen för projekt, som vi ställde in i kapitlet Några inställningar ovan. Om den inte gör det, skriv in ett lämpligt katalognamn eller välj ett i kataloglistan som tillhandahålls av knappen med katalogikonen till höger.
Om allt gick bra, visar raden Slutgiltig plats katalogsökvägen som det nya projektet kommer att använda. Om suffixet “(ogiltig)” är tillagt, prova med ett annat namn på projektet och/eller försäkra dig om att huvudkatalogen för projekt i textrutan Plats verkligen finns och är skrivbar.
När allting väl är riktigt, aktiveras knappen på raden längst ner i dialogrutan. Klicka på den för att fortsätta.
Det för dig till dialogsidan Projektinställningar. Försäkra dig om att textrutorna Upphovsman och E-post är riktigt ifyllda. Oftast är de förinställda till de allmänna användarinställningarna i KDE som anges i dialogrutan Lösenord och användarkonto i KDE:s inställningscentral. Om de inte är det, ändra dem till värden som du föredrar för programmet.
Ange ditt namn och (valfritt) e-postaddress.
Du måste åtminstone ange namn för Upphovsman. Det krävs för inställning av programmets filer.
Om allt är riktigt, är knappen aktiverad. Klicka på den för att gå vidare igen.
Följande dialogsidor, Versionskontrollsystem, Mall för .h-filer och Mall för .cpp-filer, är inte intressanta för tillfället. Hoppa över dem genom att klicka på knappen , och till sist knappen .
Det var allt! Programguiden tar över och skapar en uppsättning ursprungliga filer i katalogen Slutgiltig plats du tillhandahöll i steg 2c ovan.
När fasen att skapa filer är klar, öppnar KDevelop ett redigeringsfönster med implementeringsfilen för programmets huvudfönster (som är hello.cpp i vårt exempel), så att du enkelt kan gå vidare.
Även om vårt exempelprojekt Hello är ganska enkelt, skapade programguiden en hel mängd källkod och projekthanteringsfiler. Det enklaste sättet att lista dem är att öppna verktygsvyn Filträd längst ner till vänster. Då visas en fillista som liknar den nedan.
Ursprungliga filer i projektet “Hello World”
För att förevisa de huvudsakliga filerna som programguiden skapade, visar vi de flesta kataloggrenarna i verktygsvyn Filträd till vänster. Klicka bara på grenarnas namn i trädet för att se själv.
Dessutom, enbart i demonstrationssyfte, visar vi också de flesta grenarna i verktygsvyn Hantering av automake till höger, där några av projektets källfiler också listas.
Alla program som uppfyller kraven enligt GNU måste ha en copyright. Det finns två nivåer där copyright krävs, i enskilda källkodsfiler och vid programkörning. Programguiden har redan lagt till lämplig copyright- och licensinformation i projektfiler.
Copyright på källkodsnivå. Kommer du ihåg dialogsidan Projektinställningar när det nya projektet skapades? Där var du tvungen att ange ditt (utvecklarens) namn och en valfri e-postadress. Titta nu längst upp i redigeringsfönstret hello.cpp som för närvarande visas på arbetsytan. Programguiden skrev in denna text längst upp i licenshuvudet för varje källkodsfil som skapades.
/*************************************************************************** * Copyright (C) 2006 by Ditt Namn * * ditt.namn@adress.se * * * * This program is free software; you can redistribute it and/or modify *
Du hittar exakt samma texthuvuden i varje källkodsfil som skapas inne i KDevelop (under förutsättning att du använder lämpliga inbyggda verktyg för att skapa filer). KDevelop kommer ihåg inställningarna i några mallfiler som du hittar i katalogen templates.
Copyright när programmet körs. När väl KDE-programmet kör, kan användaren visa data Om programmet, oftast via menyn . Programguiden tog också hand om det. Om du tar en titt i filen main.cpp hittar du en post som liknar den nedan.
int main(int argc, char **argv)
{
KAboutData about("hello", I18N_NOOP("Hello"), version, description,
KAboutData::License_GPL, "(C) 2006 Ditt Namn", 0, 0,
"ditt.namn@adress.se");
about.addAuthor( "Ditt Namn", 0, "ditt.namn@adress.se" );
Det lägger till huvudutvecklarens namn (“Ditt Namn” i vårt fall) och e-postadress på copyrightsidan Om när den visas, och dessutom ange namnet och adressen på sidan Upphovsmän.
Så snart du gör betydande ändringar i ett befintligt projekt, försäkra dig om att skriva in ditt namn och e-postadress i copyrightmeddelandet för varje fil du ändrar, och även i copyrightmeddelandet som visas när programmet körs. Var inte tveksam. Du hjälper samfundet för öppen källkod betydligt om du gör det.
Programguiden placerade källkodsfiler i underkatalogen src i projektets katalog. Du hittar filerna main.cpp, hello.h och hello.cpp där, som du kanske förväntade dig.
Det finns ytterligare några filer som du ofta hittar i ett typiskt KDE-program, närmare bestämt:
hello.desktop innehåller en del metadata som KDevelop använder för att hantera och starta programmet.
hi16-app-hello.png och hi32-app-hello.png innehåller några ursprungliga standardikoner, som KDevelop använder för att visa programmet.
Till sist, innehåller helloui.rc en beskrivning av programmets användargränssnitt, för närvarande menyerna som programmet tillhandahåller.
I projektets underkatalog doc/en hittar du filen index.docbook. Det är en standardmall som kan vara utgångspunkt för att börja skriva lämplig användardokumentation.
Du har säkert märkt att filerna vi hittills har introducerat anges med fetstil i verktygsvyn Filträd, medan de flesta andra filer inte gör det. Det illustrerar den väsentligt annorlunda användning dessa filer har. Innehållet i filer som anges med fetstil påverkar programmet direkt. Källkodsfiler skapar koden som ska köras, andra filer tillhandahåller nödvändig data eller dokumentation. Filerna måste hanteras och behandlas av projektet under byggetapperna, och kallas därför projektfiler.
Om du tar en titt på det nedre fönstret i Hantering av automake till höger på arbetsytan ser du också alla projektfiler listade. Verktyget Hantering av automake använder denna kunskap för att ta hand om bygghantering, som vi inom kort kommer att se.
De andra filerna utan fetstil är mer av stödnatur. De tillhör flera särpräglade klasser, enligt följande:
Bygghantering av projekt. Dessa filer styr processer för kompilering, installation, skapade av dokumentation, etc. Om projektet använder GNU autotools, som vårt exempel, hittar du filen Makefile.am i varje projektkatalog. De är en sorts grundläggande kärnfiler för att bygga projektet, som innehåller styrkommandon, och som behandlas tillsammans med diverse configure-filer under byggetapperna. En sådan byggprocess skapar slutligen Makefile i varje katalog. Från dessa bygger verktyget make slutligen programmets binärfiler.
Makefile.am-filerna måste underhållas genom hela utvecklingsprocessen. Tursamt nog, befriar KDevelop dig från det mesta av denna börda med verkyget Hantering av automake, som i grunden är ett grafiskt gränssnitt för att underhålla innehållet i Makefile.am-filerna.
Andra filer som styr projektets byggprocess som för närvarande listas är configure.in.in och subdirs i projektets rotkatalog. De behandlas av några av filerna i den KDE-specifika administrationskatalogen admin för att skapa fler filer av typen configure och Makefile, och slutligen programmets binärfiler.
Administrationsfiler för KDevelop. KDevelop behöver viss egen hanterings- och administrationsdata. Den är placerad i projektets rotkatalog, i vårt exempel hello.kdevelop, hello.kdevelop.pcs, och hello.kdevses.
Filen xxx.kdevelop (där “xxx” anger projektnamnet) är särskilt viktig. Den är huvudsaklig projektfil i KDevelop 3, och behövs om du senare vill ladda projektet i den integrerade utvecklingsmiljön.
Försök aldrig ändra, byta namn eller ta bort någon av administrationsfilerna i KDevelop själv. Den integrerade utvecklingsmiljön fungerar sannolikt inte på rätt sätt för ditt projekt efteråt.
Filer för projektbeskrivning enligt GNU. Några filer i projektets rotkatalog krävs för alla program som uppfyller kraven enligt GNU. De är AUTHORS, ChangeLog, INSTALL, COPYING (som innehåller GNU GENERAL PUBLIC LICENSE), INSTALL, NEWS, README och TODO.
Andra filer. Några andra filer som ännu inte nämnts är:
Doxyfile styr hur den projektspecifika dokumentationen av det interna programmeringsgränssnittet skapas.
Katalogen templates innehåller filmallar som den integrerade utvecklingsmiljön använder som grund när nya källkodsfiler skapas. Du kan redigera mallarna när som helst. Det nya innehållet syns i nästa källkodsfil av motsvarande typ som du skapar.
Du kanske vill justera asteriskerna till höger på raderna med copyright som programguiden infogade i mallfilerna för cpp och h, så att källkodsfilerna som skapas med dem ser mindre aviga ut.
Katalogen po används i översättningssyfte. Den är väsentligen en del av projektfilerna (innehåller Makefile.am), men kommer i huvudsak att användas vid behandling av översättningar. Den är dock inte så intressant för programutvecklaren.
Till sist krävs katalogen admin särskilt av KDE-baserade program. Den tillhandahåller en mängd filer som är nödvändiga för att underhålla programmets källkod och binärfiler så att de kan integreras på ett riktigt sätt i KDE-miljön.
Som du märkte visades flera ytterligare verktygsvyer så fort programguiden var klar med det nya projektet. De är bara vettiga under utveckling av projektet, och erbjuder i korthet följande funktioner:
Vilka verktygsvyer som verkligen syns beror på insticksprogrammen som för närvarande är laddade i KDevelop. Det finns sätt att styra det. Se kapitlet Insticksverktyg för instruktioner.
Bokmärken. Du kan markera vilken rad som helst i en textfil för att snabbt komma tillbaka till positionen varifrån som helst. KDevelop kommer ihåg alla sådana bokmärken, även om du senare stänger redigeringsfönstret. Verktygsvyn Bokmärken listar alla bokmärken enligt filnamn och radnummer. Du behöver bara klicka på en sådan post för att öppna motsvarande redigeringsfönster och placera markören på angiven rad.
Klasser. Listar klasser, metoder, etc. kända i projektet. Att klicka på en post öppnar lämplig deklarationsfil eller källkodsfil i ett redigeringsfönster och placerar markören på respektive deklaration eller definition.
Filgrupper. Sorterar projektets filer i diverse grupper enligt användningsområde, t.ex. Sources (källkod), User Interface (användargränssnitt), Icons (ikoner), Translations (översättningar) och Others (övriga).
Variabler. Används av avlusningsverktyget för att visa, utvärdera och bevaka variabler när avlusaren körs.
Valgrind. Valgrind är ett analysverktyg för program som körs. Verktygsvyn listar resultatet av en sådan analyskörning. Det används till exempel för att hitta minnesläckor.
Säkerhetsproblem. Det finns ett insticksverktyg i KDevelop för säkerhetskontroll. Det analyserar källkodsfilen som för närvarande redigeras, för att hitta flera vanliga säkerhetsproblem som kan uppstå i programmet och underrättar användaren om dem i verktygsvyns fönster.
Brytpunkter. Verktygsvyn möjliggör att explicit sätta, ta bort och hantera brytpunkter för avlusaren i programmets källkodsfiler. Den används i samband med avlusning.
Ctags. Gör det möjligt att skapa databaser med index av identifierare med det populära programmet Ctags. Databasen med taggar kan därefter användas från verktygsvyns fönster för att slå upp alla identifierare som behövs i projektets källkod. Genom att klicka på en rad med ett sådant funnet objekt, öppnar ett redigeringsfönster och placerar markören på motsvarande identifierar i fönstret.
Problem. KDevelop håller reda på vanliga programmeringsproblem i källkodsfilen som för närvarande redigeras, och underrättar användaren om dem i verktygsvyns fönster.
Hantering av automake. Verktyget Hantering av automake är egentligen ett grafiskt gränssnitt för att hantera innehållet i Makefile.am-filer i varje projektkatalog. Verktygsvyn använder två fönster för att styra arbetet. Det övre fönstret speglar en del av projektets underkataloger, närmare bestämt de som explicit innehåller projektfiler. Varje underkatalog av denna typ måste innehålla en Makefile.am-fil, och kallas ett delprojekt i samband med Hantering av automake.
Genom att klicka på ett delprojekt öppnas en lämplig vy av delprojektets projektfiler i det undre fönstret. Filerna som listas här är grupperade enligt sin funktion i Makefile.am för detta delprojekt.
Hantering av automake är ett mycket kraftfullt verktyg för att hantera projektet och dess delprojekt, samt de roller projektfiler spelar när programmet byggs. Vi tar en snabbtitt på några viktigare delar nedan. Se kapitlet Bygga och projekthantering för en utförligare beskrivning.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
I vårt exempelprojekt lämnade programguiden filen hello.cpp öppen i ett redigeringsfönster, så att du omedelbart kan börja arbeta med den. Vi förutsätter att du har god kunskap om hur man använder en editor, så vi säger inte så mycket om det här. Det finns dock ett antal praktiska funktioner i KDevelop för att hantera redigeringsfönster med flikar och dokumenten du arbetar med. Vi ger en kortfattad beskrivning av några, närmare bestämt:
KDevelop tillhandahåller ett snabbt och enkelt sätt att byta från en given implementeringsfil (.cpp) till motsvarande deklarationsfil (.h) och vice versa. Högerklicka bara på redigeringsfönstret du vill byta. En meny som liknar den följande dyker upp.
Hur man byter mellan implementeringsfiler och deklarationsfiler.
Leta rätt på alternativet och välj det. KDevelop slår upp motsvarande deklarationsfil eller implementeringsfil och öppnar den i ett annat redigeringsfönster. I vårt exempel, om du högerklickade i källkoden hello.cpp, visas filen hello.h och markören placeras där.
Det finns mer än så. Om du högerklickar inne i en klassimplementeringstext, placerar KDevelop markören på motsvarande deklarationsrad i deklarationsfilen. Det omvända fallet, ett högerklick på en deklarationsrad, tar dig till motsvarande klassimplementering.
Om redigeringsfönstret med filen att byta till redan finns, aktiverar KDevelop förstås det och placerar markören i det om det behövs.
Men ifall du arbetar med en källkodsfil och vill slå upp deklarationen eller definitionen av en identifierare du just hittade i den? Jo, det kan åstadkommas lika lätt. Det enda du egentligen måste göra är att högerklicka på identifieraren ifråga.
Det finns dock två olika fall att ta hänsyn till, nämligen:
| Komma åt externt definierade identifierare, och |
| hantera projektinterna textobjekt. |
Det vanligaste fallet är att du vill slå upp en identifierare som definierats utanför projektet. I KDE-projekt är sådana identiferare troligen dokumenterade i olika KDE- eller Qt™-bibliotek. Om KDE och KDevelop är riktigt installerade, kan KDevelop komma åt sådan så kallad dokumentation av programmeringsgränssnitt, och kunna söka efter identifierare av denna typ.
Låt oss titta på ett exempel. Leta rätt på följande rader i redigeringsfönstret hello.cpp.
Hello::Hello()
: KMainWindow( 0, "Hello" )
{
Högerklicka på KMainWindow. En meny dyker upp. Välj där alternativet och släpp musknappen. Nu öppnas verktygsvyn Dokumentation, med värdet KMainWindow som sökbegrepp på sidan Sök. Därefter öppnas ett annat redigeringsfönster på arbetsytan som visar KDE:s referenssida i programmeringsgränssnittet för klassen KMainWindow.
Allt detta ser ut som följer. (Vi öppnade med avsikt redan sidan Dokumentation Sök för att åskådliggöra resultatet av menyvalet.)
Hur man slår upp en externt dokumenterad identifierare.
Du kan lika väl välja . I detta fall visas sidan Sökning i verktygsvyn Dokumentation, som oftast tillhandahåller ett urval sidor som innehåller sökbegreppet. (I vårt exempel är det troligen klasserna KMainWindow och KMainWindowInterface.) Välj den du är intresserad av så visas motsvarande dokumentation i ett redigeringsfönster.
Om det inte fungerade, finns det förmodligen inget dokumentindex ännu. Initierade du indexet enligt ovan? Om inte, gör det först, och kom sedan tillbaka hit för ett nytt försök.
Sådana sökfunktioner i extern dokumentation har dock sina begränsningar. Man kan förstås inte slå upp en extern identifierare om den bara definieras och används inne i det aktuella projektet. Men det finns hjälp för det. KDevelop kan använda index skapade av programmet Ctags för att söka i projektets källkod.
Innan vi kan använda det i vårt eget exempelprojekt Hello, måste vi först skapa ett lämpligt index. Det görs i verktygsvyn Ctags längst ner på arbetsytan.
När du klickar på fliken öppnas en dialogruta där du hittar följande text i nedre högra hörnet:
Bygg ett Ctags-index med knappen .
Klicka på knappen och vänta några sekunder. Då ersätts Ingen Ctags-databas hittades med dagens datum. Nu är du redo att slå upp några identifierare i projektets källkod.
Datumet intill knappen Skapa om finns där för att påminna dig om index som möjligtvis kan vara för gamla. Så fort du uppenbarligen inte kan slå upp en identifierare i projektet, fundera på att skapa om indexet. I stora projekt kan det ta en avsevärd tid, men du bör ta för vana att skapa om indexet regelbundet efter större ändringar i källkodsfiler.
Det finns flera möjligheter att slå upp en identifierare i projektets källkod.
Använd verktygsvyn Ctags. Det är enkelt. Börja bara skriva namnet på identifieraren som du är intresserad av i inmatningsfältet Uppslagning längst ner till vänster. KDevelop försöker komplettera ordet du har skrivit så långt, och visa alla förekomster av identifierare som inleds med teckenföljden.
Om du till exempel vill veta om identifieraren “Hello” används i vårt exempelprojekt, skriv in "H" i inmatningsfältet Uppslagning. KDevelop börjar omedelbart arbeta och visar ett liknande resultat:
Hur en identifierare slås upp i verktygsvyn Ctags.
Om du klickar på en av de listade posterna, öppnar KDevelop ett redigeringsfönster med filen och placerar markören på lämplig plats.
Använda en sammanhangsberoende meny i en källkodsfil. Det är bekvämt om du arbetar med en viss källkodsfil. Antag att du studerar filen main.cpp i vårt exempelprojekt Hello. Där hittar du följande rad:
Hello *mainWin = 0;
Du undrar kanske vad “Hello” användes för i programmet. För att ta reda på det, högerklicka helt enkelt på identifieraren Hello. En meny dyker upp som svar på högerklicket, med följande rader nära slutet.
Hämta Ctags-information om en av projektets interna identifierare.
Klicka på det du är intresserad av, låt oss säga Ctags - Gå till definition: Hello, så visar KDevelop omedelbart redigeringsfönstret hello.cpp och placerar markören precis framför klassdefinitionen:
Hello::Hello()
: KMainWindow( 0, "Hello" )
{
Gör en allmän sökning. Det är särskilt användbart om du vill slå upp godtycklig text i projektets källkod. Det finns två möjligheter att starta en allmän sökning inne i KDevelop.
Starta en allmän sökning med menyalternativet ->. Eller
Direkt använda den sammanhangsberoende menyn med ett högerklick av musen i redigeringsfönstret.
Vi åskådliggör den andra möjligheten i exempelprojektet Hello. Slutresultatet av menyanropet är i stort sett likadant. Låt oss anta att du studerar källkodsfilen hello.cpp och har placerat markören på den första förekomsten av Hello i den. Nu undrar du var ordet “Hello” användes i projektets källkod, och hur många förekomster det finns. Det är ett typiskt fall då KDevelops allmänna sökfunktion bör användas.
Medan du nu fortfarande håller pekaren någonstans över “Hello” i källtexten, klicka med höger musknapp. Den vid det här laget välkända sammanhangsberoende menyn dyker upp, där du ska välja alternativet Flerfilsökning: Hello.
Initiera en allmän sökning inifrån ett redigeringsfönster.
Det gör att följande dialogruta Sök i filer dyker upp (exakt samma som om du använt menyn->).
Ett flexibelt grafiskt gränssnitt för att utföra allmänna sökningar i projektet.
Som du märker är det ett mycket flexibelt verktyg för att starta sökningar med find och grep i hela projektet. Vi går inte in på fler detaljer här, men du kan experimentera på egen hand. För ögonblicket, ska “Hello” redan vara markerat i fältet Mönster. Om det inte är det, skriv bara in det, och klicka därefter på knappen längst ner till höger.
Nu öppnas verktygsvyn Sök i filer längst ner, och visar filnamn och rader för alla förekomster av “Hello” i vårt exempelprojekt. Som vanligt, om du klickar på en rad, går KDevelop till den exakta platsen i ett redigeringsfönster på arbetsytan.
Det finns två särskilt intressanta rader i verktygsvyns fönster.
Längst upp hittar du kommandosekvenserna som KDevelop i själva verket använde för att utföra sökningen. Det är användbart för att noggrannare styra sökningens resultat.
Längst ner anges antal förekomster som hittas när en sökning utförs. I vårt exempel ska det vara “*** 11 träffar hittades ***”.
KDevelop kommer ihåg sökresultatet under hela sessionen som kör. Om du startar en ny allmän sökning, visas dess resultat med ett annat flikfönster i verktygsvyn Sök i filer.
När du arbetar med stora komplexa projekt råkar du ofta ut för att ha en hel mängd flikar med redigeringsfönster i flikraden. Det gör det nödvändigt att ha särskilda funktioner för att rensa, ordna och gruppera alla redigeringsflikarna. KDevelop tillhandahåller flera sätt att göra det. Vi tar en snabbtitt på några av dem.
Om ett enormt antal flikar med redigeringsfönster på något sätt blir dåligt arrangerade, vill man oftast stänga alla flikar som inte längre behövs. KDevelop tillhandahåller flera funktioner för att göra det, det vanliga sättet att totalt stänga alla öppna redigeringsfönster, och ett mer specifikt sätt där du uttryckligen kan bestämma vilka som ska stängas och vilka som ska behållas öppna.
Stänga flera flikar på en gång. Det här är en sorts totalmetod för att stänga onödiga öppna flikar, som du också kan hitta i andra KDE-program. Du kan använda menyn eller högerklicka på en flik, för att antingen
stänga redigeringsfönstret som för närvarande är valt,
stänga alla andra öppna redigeringsfönster, eller
stänga alla redigeringsfönster på en gång (bara tillgängligt i menyn ).
Stänga markerade uppsättningar flikar. Sättet att steg för steg stänga enskilda flikar med redigeringsfönster kan bli krånglig om det finns en stor mängd flikar och du fortfarande vill lämna flera öppna. Istället för att leta rätt på och stänga en flik åt gången, erbjuder KDevelop möjligheten att välja kandidater i en lista och enbart stänga dem, med ett enda musklick.
Låt oss illustrera det med ett enkelt exempel. Låt oss anta att det finns flera filer öppna för redigering i vårt exempelprojekt Hello: hello.cpp, hello.h, helloui.rc, hello.desktop och main.cpp. Du vill nu stänga alla utom hello.cpp och hello.h. Det enklaste sättet att göra det är med verktygsvyn Fillista. Eftersom denna lista med öppna filer är alfabetiskt ordnad, är det enklare att hitta de du vill stänga. Fortsätt enligt följande:
Öppna Fillista, håll nere tangenten Ctrl, och klicka på filerna du vill stänga i listan.
Klicka därefter med höger musknapp, medan du håller muspekaren på ett filnamn i listan.
Välj från den sammanhangsberoende menyn i .
Hur markerade redigeringsfönster kan stängas på en gång.
Det är det hela. KDevelop har stängt alla redigeringsfönster som du önskade, och du är klar att fortsätta igen med en rensad flikrad.
Även om du bara har de redigeringsfönster som verkligen behövs öppna, kanske du ändå vill arrangera flikarna på något logiskt sätt. KDevelop erbjuder några vanliga sätt att göra det. I korthet:
Grundläggande inställning: Var nya flikar ska placeras. I normalfall, när ett nytt redigeringsfönster öppnas, infogas fliken till höger om fliken för redigeringsfönstret som för närvarande används. Det kan ändras så att den nya fliken öppnas längst till höger på flikraden.
Du måste ändra en grundläggande inställning i KDevelops användargränssnitt för att aktivera beteendet.
Välj ->
Klicka på ikonen Användargränssnitt i ikonraden till vänster i dialogrutan. Dialogsidan Användargränssnitt visas nu.
Hitta rutan som heter Bläddring med flikar. Ta bort markeringen av kryssrutan på raden Öppna ny flik efter nuvarande flik.
Stäng KDevelop och starta om det. Nu öppnas flikarna för nya redigeringsfönster längst bort till höger i nuvarande flikrad.
Tyvärr kan inte inställningen ändras i farten under en utvecklingssession. Du måste bestämma dig för vilket beteende du föredrar i det långa loppet, och därefter hålla dig till det, åtminstone till nästa gång KDevelop startas.
Hur flikarna kan arrangeras om. Eftersom utvecklingsuppgifer varierar med tiden, kommer behov att arrangera om flikarna för redigeringsfönster uppstå då och då. Det kan enkelt åstadkommas i KDevelop.
Klicka bara på fliken du vill flytta med musens mittenknapp och flytta musen lite grand. Markören ändras till ett mönster med korsande pilar. Nu kan du dra fliken, medan du håller nere mittenknappen, till det hoppar på plats där du vill ha det.
Vid första påseende finns det aldrig mer än ett enda redigeringsfönster öppet för att arbeta med en källkodsfil. Även om du snabbt kan byta mellan flikar, finns det tillfällen då du vill ha flera filer öppna på en gång, t.ex. för referenssyfte eller för att få bättre kontroll av komplexa uppgifter. För att åstadkomma det, tillhandahåller KDevelop ett sätt att dela arbetsytan i olika delar som syns samtidigt, och var och en kan innehålla en egen följd av flikar.
Det finns två delningskommandon som du antingen kan nå via menyn , eller genom att högerklicka i ett fönster som hör till en flik eller på själva fliken. Vi beskriver också delningsbeteendet utgående från vårt exempelprojekt Hello.
Antag att det finns två källkodsfiler öppna i flikraden: hello.cpp and hello.h. Medan du arbetar med källkoden i hello.cpp behöver du ofta titta på deklarationerna i filen hello.h, så du vill ha båda filerna öppna samtidigt.
För att få det gjort, högerklicka till exempel på fliken för hello.h. Följande meny dyker då upp:
Hur den aktuella arbetsytan kan delas i två delar.
Välj alternativet . Det delar arbetsytan på mitten och flyttar redigeringsfönstret som innehåller filen hello.h till den nedre delen.
Arbetsytan har delats horisontellt.
Observera den streckade skiljelinjen mellan de båda fönstren. Du kan ta tag i den med musen och justera redigeringsfönstrens höjd efter dina behov.
Det finns ett antal saker att lägga märke till.
De delade arbetsytorna fungerar helt och hållet på egen hand. Det betyder att nya flikfönster öppnas i arbetsytan som innehåller redigeringsfönstret som för närvarande är aktivt. Du kan också dela alla delområden igen som du önskar, och på så sätt ha så många fönster öppna samtidigt som du behöver.
Varje delning flyttar redigeringsfönstret som för närvarande är aktivt till den nya delarbetsytan, antingen neråt eller åt höger. Övriga flikfönster förblir alla där de var. Du kan inte direkt flytta flikfönster mellan delade områden, utan istället måste du explicit stänga fönstret på en arbetsyta och öppna det igen på en annan, för att gruppera om.
Det finns heller inget direkt sätt att stänga ett delat område igen. Det stängs automatiskt, när väl det sista fönstret med en flik i det stängs.
Det finns en trevlig användning av den ovannämnda funktionen med delade arbetsytor inbyggd i KDevelop. Den låter dig automatiskt ha en källkodsfil, .cpp, och dess tillhörande deklarationsfil, .h, öppna sida vid sida på arbetsytan. Dessutom tillåter den valfritt att arbeta synkront med filerna, på så sätt att vid markering av en deklaration i deklarationsfilen går KDevelop till motsvarande definition i källkodsfilen och omvänt.
Funktionen är dock normalt inte aktiverad. Om du vill använda den i projektet måste du aktivera den.
Välj ->. Dialogrutan Projektinställningar dyker upp. Välj C++ stöd i ikonraden till vänster, och därefter fliken Navigering på dialogsidan som visas till höger.
Låta C++ källkod och deklarationsfiler visas sida vid sida.
Markera nu rutan Aktivera delning av deklarationsfiler och källkodsfiler. Det aktiverar normalt Automatisk synkronisering och Vertikal. Behåll inställningarna för tillfället och klicka på .
Stäng nu båda redigeringsfönstren hello.cpp och hello.h i vårt exempelprojekt Hello, om det behövs. Välj därefter hello.cpp igen i projektets underkatalog src. Redigeringsfönstret öppnas som vanligt, men om du nu öppnar tillhörande hello.h, delar KDevelop automatiskt arbetsytan och öppnar deklarationsfilens redigeringsfönster precis under fönstret hello.cpp.
Det finns ännu mer, som vi redan nämnt. Leta till exempel rätt på definitionsraden för följande konstruktor i fönstret hello.cpp
Hello::Hello()
och placera markören där. Titta därefter i fönstret hello.h nedanför och observera hur KDevelop gick till motsvarande deklarationsrad för konstruktorn.
KDevelop går automatiskt till konstruktorns deklaration.
Det fungerar också omvänt. Så fort du placerar markören någonstans i en konstruktor i ett redigeringsfönster, går KDevelop till motsvarande konstruktor i det andra.
När projektet växer sig större, och utvecklingsuppgifterna blir mer och mer komplexa, tvingar det dig att ofta byta mellan olika, till och med distinkta, uppsättningar filer. Nu är det dags att organisera utvecklingsarbetet i skilda sessioner. Verktygsvyn Fillista i KDevelop tillåter dig att göra precis det.
Längst upp i fönstret för verktygsvyn Fillista finns en verktygsrad där du kan skapa, spara, välja och ta bort sådana sessioner. Använd alternativt undermenyn ->.
Vi beskriver också funktionen utgående från vårt exempelprojekt Hello. Antag att du alltid vill öppna filerna hello.cpp, hello.h och main.cpp med ett steg, oberoende av vilken utvecklingsuppgift du precis utförde i projektet. Du måste först skapa en ny utvecklingssession, som exempelvis kallas “källkod”, för att åstadkomma det.
Använda utvecklingssessioner för att komma ihåg filgrupper.
Det är en procedur i flera steg, enligt följande:
Skapa en ny session
Klicka på ikonen Ny session längst upp till vänster i verktygsvyn Fillista.
En dialogruta dyker upp. Ge den nya sessionen ett namn i inmatningsfältet Skriv in sessionens namn, t.ex. “källkod”.
Stäng dialogrutan med . Den nya sessionen anges nu i kombinationsrutan i verktygsraden.
Den nya sessionen är tom från början. Du måste lägga till filerna du vill ska ingå i den.
Öppna alla filer du vill ska grupperas i utvecklingssessionen. I vårt exempel bestämde vi oss för att behålla hello.cpp, hello.h och main.cpp som planerat.
När fillistan väl är fullständig, klicka på ikonen Spara session i verktygsraden. Hoppa inte över detta steg. Annars glömmer KDevelop bort fillistan.
Det är allt. Så fort du väljer sessionen källkod i kombinationsrutan Öppna session, stänger KDevelop alla redigeringsfönster som för närvarande är öppna, och öppnar de ihågkomna istället (hello.cpp, hello.h och main.cpp i vårt exempel).
Du kan definiera hur många sessioner som du vill i samband med projektet. Om du vill ändra sessionernas innehåll, uppdatera bara den ihågkomna fillistan med ett klick på Spara session. Och om du vill bli av med en session, välj den i kombinationsrutan, och klicka därefter på ikonen Ta bort session till höger i verktygsraden.
Du kan göra ännu mer. Du kan tvinga KDevelop att öppna en given förvald session när projektet laddas. Välj bara sessionen i kombinationsrutan på inställningssidan ->-> i projektinställningarna.
Låt KDevelop öppna en specifik session när projektet laddas.
När ett redigeringsfönster som innehåller en källkodsfil öppnas, tolkar KDevelop dess innehåll. Det gör det möjligt för den inbyggda problemrapportören att söka i källkodstexten efter några vanliga fel som den känner till. Den kan också informera användaren om olika platser som har markerats för specialbehandling.
Låt oss åskådliggöra funktionen med vårt exempelprojekt Hello.
Öppna ett editorfönster med källkodsfilen main.cpp.
Försäkra dig om att det fortfarande innehåller följande rad någonstans nära slutet:
/// @todo do something with the command line args here
Det infogades av programguiden när projektet Hello skapades i kapitlet Starta ett nytt projekt ovan.
Öppna nu verktygsvyn Problem i raden med flikar längst ner. Om allt har fungerat, rapporterar den för närvarande följande uppgift:
KDevelop informerar om att en källkodsrad innehåller markeringen todo.
Formatet på kommandot /// @todo är till för särskild behandling av verktyget för koddokumentation, Doxygen, som vi tar en snabb titt på i avsnittet Dokumentation nedan. Det krävs inte att du använder detta format, de vanligare kommentarerna TODO och FIXME känns också igen.
Om du till exempel infogar följande kommentarrader med TODO och FIXME i vår exempelfil hello.cpp:
Hello::Hello()
: KMainWindow( 0, "Hello" )
{
// set the shell's ui resource file
// TODO check the user interface
setXMLFile("helloui.rc");
// FIXME change to a better suited greeting
new QLabel( "Hello World", this, "hello label" );
}
ser du dem också angivna i verktygsvyn Problem:
Problemrapporten som anger rader som kräver uppmärksamhet i nuvarande fil som redigeras.
Observera övriga flikar i verktygsvyn Problem, i synnerhet Fixa och Uppgift. Om du öppnar den ser du alla rader markerade med FIXME och TODO som KDevelop hittills har hittat i sessionen. Informationen om TODO set för närvarande ut på följande sätt:
Problemrapporten har samlat information om TODO.
Fliken Fel listar dock inte varje kodningsfel som du gör. Det arbetet utförs av andra verktyg under byggprocessen. Här hittar du information om några vanliga programmeringsmisstag, som troligen annars skulle förbli obemärkta och troligen med svårighet hittas via komplicerade avlusningssessioner.
Du kommer att märka att problemrapportfunktionen i KDevelop är ett mycket värdefullt verktyg, så kontrollera verktygsvyn Problem regelbundet under utvecklingsprocessen.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Att kompilera ett projekt i KDevelop kräver flera inställningssteg och därefter att programmet byggs. Allt detta är tillgängligt via menyn .
Att bygga ett projekt kräver flera steg.
För närvarande är vi bara intresserade av menyns övre del. Alternativen är där sorterade efter hur viktiga de är. Därför är kommandot som oftast behövs längst upp, alternativet som gör att hela projektet initieras, kompileras och länkas efter behov. Andra alternativ finns för att kompilera valda delar av projektet, eller bara en enstaka fil, för att utföra flera olika initieringssekvenser, eller för att installera det färdiga programmets binärfiler.
För tillfället koncentrerar vi oss på flera funktioner som KDevelop tillhandahåller för att ställa in projektet, initiera, bygga och köra programmet. I allmänhet omfattar det:
| Ta en snabb titt på den grundläggande byggcykeln. |
| Titta på några enkla sätt att anpassa ett projekt. |
När man väl har skapat ett nytt projekt, vill man oftast kontrollera om allt hittills har gått bra. Det omfattar att bygga projektet för första gången och testköra programmet, vilket vi ska göra nu. För att kompilera ett projekt för första gången finns det flera steg att utföra, som vi tar en snabb titt på:
| Hur projektet initieras för att bygga det första gången. |
| Hur de ursprungliga inställningarna görs. |
| Hur man bygger projektet. |
| Hur programmet körs inifrån KDevelop. |
Beskrivningen förutsätter att projektet är baserat på GNU autotools, vilket aktiverar Hantering av automake i KDevelop, liksom vårt exempelprojekt Hello. Om du skapar en annan projektttyp, t.ex. för Qt™-baserad projekthantering med QMake, finns andra funktioner tillgängliga i menyerna, eller kanske inte några av dem. Du måste använda respektive leverantörs dokumentation om projekthantering och hur man bygger projekt i dessa fall.
När programguiden skapade vårt exempelprojekt Hello, lämnade den det i ett sorts “orört” utgångstillstånd. Verktygskedjan i GNU autotools kräver att flera initieringssteg utförs innan programmet verkligen kan kompileras och länkas. Om du försöker bygga ett projekt när det är i detta utgångstillstånd, t.ex. genom att välja -> eller trycka på funktionstangenten F8, får du följande varning:
Försöker bygga ett obehandlat projekt baserat på automake.
Du kan klicka på knappen , vilket gör att KDevelop automatiskt försöker köra alla inställningssteg som krävs innan programmet kompileras och länkas. Men vi ska titta på de inledande stegen i följd, så avbryt dialogrutan genom att klicka på .
Som redan har nämnts utförs kompilering och länkning av programmet via menyn . Visa den och välj .
Starta en grundläggande initieringskörning.
KDevelop öppnar nu verktygsvyn Meddelanden längst ner och visa en följd av meddelanden som skapas av flera olika byggverktyg. Om allting gick bra, ska den sista raden lyda: “*** Lyckades ***”.
Om du rullar tillbaka längst upp, hittar du kommandoraden som KDevelop utförde för att anropa verktygen i bakgrunden:
cd '/home/devel/projects/hello' && \ WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake -f Makefile.cvs
Det säger att KDevelop först bytte till vårt exempelprojekts rotkatalog. Därefter skapades en särskild miljö, som talar om för byggsystemet vilka versioner av autoconf och automake som används för initieringen. Till sist instruerades byggverktyget (GNU gmake i detta fall) att behandla byggfilen Makefile.cvs.
Byggfilen skapades automatiskt när projektet Hello skapades.Den innehåller alla kommandon som behövs för att initiera projektet rätt, så att programmet som skapas kan köras i KDE. I synnerhet skapar den skripfilen configure som är nödvändig för att utföra nästa inställningssteg.
Att konfigurera betyder att anpassa byggprocessen till egenheter hos hårdvaran och programvaran i systemet. Det är ett grundkrav i byggprocesser baserade på GNU autotools, som du troligen redan vet.
Du kan först beordra en konfigureringssekvens när den grundläggande initieringen av automake har avslutats med lyckat resultat, eftersom de nödvändiga configure-filerna inte är tillgängliga förrän efter den inledande körningen. När den är gjord, välj menyalternativet -> för att påbörja konfigureringssekvensen.
KDevelop öppnade verktygsvyn Meddelanden igen om det behövdes, och listade meddelanden från körningen av configure i den. Om allt gick bra, är de sista meddelandena “Good - your configure finished. Start make now” (som skrevs ut av configure) följt av meddelandet “*** Lyckades ***” från KDevelop.
Längst upp i fönstret Meddelanden hittar du åter kommandoraden som KDevelop använde för att starta konfigurationen:
mkdir '/home/devel/projects/hello/debug' && \ cd '/home/devel/projects/hello/debug' && \ CXXFLAGS="-O0 -g3" "/home/devel/projects/hello/configure" --enable-debug=full
Du kan se flera intressanta detaljer i kommandona.
 |
|
Alla inställningarna kan anpassa för varje projekt. Du kommer att lära dig mer om det i kapitlet Projekthantering.
När du väl har kommit så här långt är du klar att verkligen bygga, dvs. kompilera och länka programmet. Genom att titta i menyn , ser du att det finns tre sådana kompileringsalternativ att välja bland.
Kommandon i KDevelop för att bygga binärfiler.
Nerifrån och uppåt, finns det:
: Det kompilerar källkodsfilen i redigeringsfönstret som för närvarande är öppet. Används oftast för snabb kontroll av fel.
: Det används i huvudsak i samband med Hantering av automake, som vi tar en snabb titt på nedan.
: Det är vad vi nu är intresserade av. Det går igenom hela projektet, kompilerar och länkar filer där det är nödvändigt.
Det kan vara intressant att se vad som händer med katalogen debug som skapades under föregående körning av configure. Därför är det bäst att behålla den öppen med alla underkataloger synliga, som visas ovan. Välj därefter -> (eller tryck på tangenten F8) för att påbörja byggsekvensen. Som tidigare öppnas verktygsvyn Meddelanden längst ner och listar resultatet av byggkörningen. Dessutom dyker några filer upp i underkatalogträdet debug.
Det finns inte många källkodsfiler i vårt exempelprojekt Hello, alltså kommer fönstret Meddelanden bara innehålla några få rader. Leta återigen rätt på kommandoraden ovanför dem som KDevelop skickade till skalet i bakgrunden.
cd '/home/devel/projects/hello/debug' && \ WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake -k
KDevelop bytte till debug-delträdets rot, vilket inte borde vara förvånande, för att köra filen Makefile som finns där. En särskild delmiljö skapades igen, som tidigare i initieringssteget, i vilken verktyget gmake anropades.
Observera väljaren -k i anropet av gmake. Den tvingar byggprocessen att fortsätta till sitt slut, även om fel skulle uppstå. Det är vettigt eftersom KDevelop kommer att lista alla felmeddelanden i fönstret Meddelanden. Om det finns några, dra nytta av fördelarna med den integrerade utvecklingsmiljön: klicka bara på felmeddelandet i fönstret Meddelanden så går KDevelop till det exakta stället där felet uppstod i källkodsfilen.
Och vad hände inne i delträdet debug? Inte så mycket. Några få filer dök upp i grenarna doc/en och src, i synnerhet filen hello i /home/devel/projects/hello/debug/src/. Den är, till sist, programmets binärfil som vi sökte. Allt som är kvar att göra i vår inledande kontroll av projektet är att köra hello.
Det finns inte några extra steg inblandade för att köra det nya programmet hello. Välj antingen ->, tryck på Skift-F9 eller använd knappen i byggverktygsraden som visas nedan.
Köra ett program från Byggverktygsraden.
Det är allt. KDevelop startar nu det nya programmet i ett särskilt terminalfönster som verktygsvyn Program längst ner. Där visas kommandot som KDevelop utförde för att köra programmet på raden längst upp:
./hello
som visar att den integrerade utvecklingsmiljön har en uppfattning om var programmet som ska köras finns. Denna uppfattning kan ställas in på många sätt. Se mer om detta i kapitlet Projekthantering.
Raden ./hello följs troligen av ett varningsmeddelande. Ignorera det för tillfället. Det förhindrar inte att vårt program hello kör.
Vårt ursprungliga Hello-program.
Stäng programfönstret Hello som vanligt. Om inga fel uppstod rapporterar KDevelop det som “*** Avslutade normalt ***” i verktygsvyn Program.
Det finns åtskilliga sätt att hantera ett projekt i KDevelop. Beteendet kan ställas in för varje projekt, och är mest intressant för avancerade utvecklare. Det finns dock några få projektspecifika inställningar som du bör känna till ända från början.
| Varför är bygginställningar användbara? |
Var beteendet hos skriptet configure ska definieras. |
| Några överväganden om hur make ska köras. |
| Var ska det körbara programmet finnas, och vad ska det heta? |
När vi körde skriptet configure i avsnittet Inledande konfiguration av Hello ovan, noterade vi att KDevelop hade skapat den särskilda underkatalogen debug för detta syfte. I detta avsnitt behandlar vi kortfattat några konsekvenser av denna funktion.
För det första använder KDevelop inte nödvändigtvis särskilda byggkataloger skilda från källkoden. Förberedelser för att automatiskt använda särskilda bygginställningar görs via de mallar som programguiden använder när ett nytt projekt skapas.
För att ta reda på vilka bygginställningar som för närvarande är tillgängliga, ta en titt på menyn ->.
Det finns olika bygginställningar tillgängliga i projektet.
I detta fall, som i vårt exempelprojekt Hello, finns det tre olika tillgängliga bygginställningar. I andra fall kanske det bara finns en sådan bygginställning från början, nämligen .
Bygginställningen som för närvarande används har en bock till vänster. Välj helt enkelt menyalternativet för att byta till en annan bygginställning.
Låt oss nu ta en snabbtitt på vad bygginställningarna tillhandahåller.
Du bör använda bygginställningen som standard under utvecklingsprocessen. Den byggs separat från källkodskatalogerna i den särskilda underkatalogen debug, dvs. alla objektfiler, extrafiler och körbara filer placeras i dess underkataloger istället för motsvarande kataloger i projektets rot. Skriptet configure får väljaren --enable-debug=full och argumentet CXXFLAGS="-O0 -g3" talar om för gcc-kompilatorn att inte optimera koden och att infoga omfattande avlusningsinformation i de binärfiler som skapas.
Den här används för att bygga det slutliga C++ programmet. Den byggs separat från källkodskatalogerna i den särskilda underkatalogen optimized. Skriptet configure har inga särskilda förinställda väljare, medan CXXFLAGS="-O2 -g0" talar om för gcc-kompilatorn att optimera koden och inte infoga avlusningsinformation i de binärfiler som skapas.
Beteckningen “default” anger standardinställningen när ett program byggs i en terminal med t.ex. GNU byggverktygen configure och make/gmake på kommandoraden. I motsats till eller används ingen särskild byggkatalog. Programmet byggs istället normalt i källkodskatalogerna. Inga särskilda konfigurationsväljare är fördefinierade. När programmet byggs och körs används de underliggande verktygens standardinställningar (t.ex. gcc, etc.).
Tänk efter ordentligt innan du bestämmer dig för att använda bygginställningen .
Den kan inte användas parallellt med de särskilda inställningarna och . Alla byggåtgärder som använder gör att de båda andra bygginställningarna blir oanvändbara. Det beror på några egenheter hos processen som skapar Makefile med mekanismerna i automake och autoconf, som inte är enkelt att få bukt med.
Varför vill man då använda olika bygginställningar överhuvudtaget, när de till och med inte verkar fungera tillsammans? Svaret är att det förenklar cykler med redigering, kompilering och avlusning. De extra avlusningsinstruktionerna som infogas i binärfilerna samt alla de subtila strukturändringarna som görs av programkoden under optimering påverkar beteendet när det körs för programmet som skapas. När den logiska strukturen hos en viss rutin verkar vara riktig, borde du testa om den fortfarande beter sig riktigt under mer realistiska förhållanden.
Det är då bygginställningarna i KDevelop gör nytta. Eftersom byggobjekt och körbara filer i varje särskild byggkatalog, och byggkommandon, hålls åtskilda från varandra behöver bara ändringar av källkod hanteras när du byter mellan bygginställningarna.
Istället för att rensa och kompilera om allt från början med andra inställningar, behöver du alltså bara byta från bygginställningen till , kompilera ändringarna av källkoden och därefter starta om programmet under dessa förhållanden. Om något olämpligt visar sig, byt helt enkelt tillbaka till , och fortsätt omedelbart arbeta där.
En sista anmärkning: Många bygginställningar kan anpassas. Du kan till och med definiera dina egna bygginställningar om utvecklingsprocessen kräver det. Vi tar en snabb titt på dessa möjligheter i nästa avsnitt.
Att konfigurera programmet riktigt är livsviktigt i byggkedjan baserad på GNU autotools. Det styrs ofta av väljare för skriptet configure och/eller särskilda argumentinställningar i miljön innan configure körs, som t.ex. CXXFLAGS i vår tidigare beskrivning.
Du kan ställa in de flesta konfigurationsalternativen för ett givet projekt från KDevelops grafiska gränssnitt. Välj -> och därefter ikonen Inställning av configure på ikonraden till vänster i dialogrutan. Sidan Inställning av configure som innehåller flera flikfönster visas till höger.
De flesta inställningarna av configure kan anges här.
Som du märker, finns det ett ganska stort antal alternativ som kan anges i dialogrutan. För tillfället tittar vi kortfattat på ett fåtal av dem med avseende på vårt exempelprojekt Hello. För detaljerade instruktioner, se kapitlet Konfigurera projekt. Om du vill veta mer om betydelsen hos olika argument som kan anges, slå upp info make i en terminal (eller info:make inne i Konqueror) och titta i avsnittet ->.
Det finns flera inställningsfönster med flikar i dialogrutan, där det första, Allmän, visar ofta använda inställningar, medan de övriga är ganska kompilatorspecifika. Under alla omständigheter, styrs dock det verkliga innehållet i dialogrutorna av angiven bygginställning.
Du väljer bygginställningen vars inställningsalternativ ska definieras i kombinationsrutan Inställning längst upp i dialogrutan Inställning av configure.
Välj bygginställning vars inställningar ska definieras.
Välj nu en annan bygginställning i kombinationsrutan och observera hur innehållet i t.ex. textrutorna Configure-argument och Byggkatalog ändras enligt inställningarna vi nämnde för bygginställningslistan ovan.
Följande inställningsalternativ kan definieras på sidan Allmänt i dialogrutan:
Configure-argument. Detta är alternativen som KDevelop tilldelar till anropet av skriptet configure i byggprocessen. Se exemplet i avsnittet “Inledande konfiguration av Hello” ovan.
Byggkatalog. Detta är underkatalogen i nuvarande projektrot, där KDevelop placerar alla filer som skapas under byggprocessen. Idealiskt borde det motsvara namnet på bygginställningen som används, men du har möjlighet att använda vilket namn du vill, under förutsättning att det är annorlunda än alla andra byggkataloger.
Övre källkatalog. Du behöver inte den här ofta. Dess standardvärde är projektets rotkatalog, och den behöver bara definieras om om projektets källkod är placerad någon annanstans.
C/C++ preprocessorargument(CPPFLAGS). Skriv in särskilda instruktioner för preprocessorn här. KDevelop använder det för att skapa en tillfällig miljö innan själva byggverktyget anropas. Se återigen exemplet i avsnittet “Inledande konfiguration av Hello” ovan hur det görs.
Länkargument (LDFLAGS). Det här är extra information för länkarverktyget ld, om var det ska leta efter ytterligare bibliotek. Den används också för att skapa den tillfälliga byggmiljön.
Miljövariabler. Här kan du definiera ytterligare variabler som ska ställas in i den tillfälliga byggmiljön som KDevelop skapar innan respektive byggverktyg anropas. Återigen, måste du definiera miljövariablerna för varje bygginställning där de ska användas.
Övriga flikar på dialogsidan Inställning av configure är till för kompilatorspecifika inställningar. De är strukturerade på liknande sätt, så det är tillräckligt att snabbt titta på sidan C++.
Välj kompilator som KDevelop ska använda och dess arbetsomgivning här.
Här kan du ställa in följande:
C++ kompilator. Välj den C++ kompilator som KDevelop normalt ska använda i kombinationsrutan. Den listar dock bara de kompilatorer som KDevelop redan känner till.
Kompilatorkommando (CXX). Bara för experter. Det behövs bara om en annan C++ kompilator än standardkompilatorn används. Skriv in namnet som den anropas med här.
Kompilatorargument (CXXFLAGS). Här kan du skriva in eventuella extra alternativ som KDevelop ska skicka till kompilatorn (via Makefile). Vissa alternativvärden är förinställda enligt bygginställning som valts med kombinationsrutan Inställning.
Observera att många vanliga kompilatoralternativ kan väljas i en dialogruta som dyker upp när du klickar på knappen till höger om textrutan.
Använd dialogrutan för att definiera beteendet hos GNU C++ kompilatorn.
Vi valda med avsikt fliken Optimering här. Observera att alternativet Ingen optimering är förvald (enligt det förinställda alternativet -O0 i bygginställningen debug).
Tyvärr kan du för närvarande inte välja alla alternativ från dialogrutan Exempelvis alternativet -g3 som används av bygginställningen debug måste ändras för hand om det någonsin behövs.
Du kan dessutom anpassa sättet som KDevelop anropar verktyget make när projektet byggs. Välj -> och därefter ikonen Bygginställningar till vänster i dialogfönstret. Dialogsidan Bygginställningar visas då till höger.
Definiera hur KDevelop anropar verktyget make.
Det finns inte så mycket att göra här just nu. Den enda intressanta inställningen i de flesta fall är alternativet Avbryt vid första fel. Du kommer att märka att den är inaktiverad i de flesta projekt. Den motsvarar väljaren -k i anropet till gmake som vi hittade den första gången som exempelprojektet Hello byggdes.
Det är vettigt i en integrerad utvecklingsmiljö som KDevelop, där alla felmeddelanden under byggningen lagras. Efter byggprocessen kan du enkelt gå till vilket felmeddelande som helst i verkygsfönstret Meddelanden. Använd -> och -> eller tangenterna F4 och Skift-F4 för att göra det. KDevelop aktiverar automatiskt redigeringsfönstret för källkodsfilen i fråga och placerar markören på den felaktiga raden.
Om du å andra sidan hellre vill att byggningen ska stoppas så snart ett fel uppstår, markera alternativet Avbryt vid första fel i dialogrutan. KDevelop anropar du gmake utan väljaren -k.
När byggningen väl är färdig, kan du enkelt köra programmet inifrån KDevelop. Använd antingen ->, snabbtangenten Skift-F9 eller knappen i KDevelops byggverktygsrad.
Kör programmet här.
Men var finns det körbara programmet som ska köras? Hur får man KDevelop att lägga till väljare i anropet? Eller hur kan man få programmet att köras i en egen terminal för att testa interaktivt beteende i terminalen?
Allt det kan lösas genom att ställa in några projektorienterade köralternativ i KDevelop. Välj -> och därefter ikonen Körinställningar i ikonraden till vänster i dialogfönstret. Dialogsidan Körinställningar visas till höger.
Definiera var och hur programmet ska köras.
Det finns en hel del som kan ställas in i dialogrutan. Det finns egentligen fyra grupper av inställningsalternativ.
Katalog. Talar om för KDevelop vad det ska förutsätta att det körbara programmet kallas. Det finns tre möjligheter att välja bland.
Observera dock att bara rotkataloger definieras här. KDevelop letar oftast efter det körbara programmet i någon underkatalog som anges i följande grupp av inställningar.
Kör från katalogen där det körbara programmet senast byggdes. Det är normalvärdet. Du kan behålla det för ögonblicket.
Kör från byggkatalogen enligt bygginställning som för närvarande är vald. Katalognamnet ställdes in på dialogsidan Allmän.
Detta är rotkatalogen där KDevelop ska hitta det körbara programmet. Den ändras automatiskt enligt valet du gjorde i menyn ->. Prova det.
Förutom att alltid köra det senast byggda körbara programmet enligt inställningen ovan, låter det dig byta program att köra genom att helt enkelt välja en annan bygginställning i menyn .
Kör programmet som hittas i en fast egen katalog. Återigen är det bara rotkatalogen där själva den körbara filen finns.
Använd det om du t.ex. vill köra programmet som verkligen har installerats istället för versionen som finns i projektkatalogen.
Program. Detta talar om relativ plats och namn på programmet som verkligen ska anropas för KDevelop. Det är relativt i förhållande till rotkatalogen som definieras i inställningsgruppen ovan. Dessutom kan du definiera alla argument som KDevelop ska skicka till programmet när det verkligen anropas.
Om textrutan Huvudprogram lämnas tom, används inställningen av aktivt mål i Hantering av automake. Även om detta är en expertinställning, är en vanlig orsak till problem att detta inmatningsfält har lämnats tomt. Kontrollera inställningen om KDevelop inte verkar anropa det körbara program du ville.
Miljövariabler. KDevelop skapar en särskild skalmiljö att köra programmet i. Definiera eventuella extra miljövariabler i denna grupp av inställningar.
Diverse. Ytterligare två kryssrutor finns längst ner på dialogsidan.
Kompilera automatiskt innan körning är oftast praktiskt. KDevelop kontrollerar om projektet har ändrats och utför nödvändiga konfigurerings- och byggsteg åt dig så snart du ger kommandot att köra programmet.
Avmarkera det om du vill köra en programversion tidigare än den senaste ändringen.
Starta i extern terminal är intressant om du vill prova in- och utmatningsbeteende för program utan grafiskt gränssnitt i ett terminalprogram. Det är normalt inte markerat, så KDevelop startar programmet i ett eget fönster utan in- och utmatningsmöjlighet via en terminal.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
(ännu inte skrivet ...)
(ännu inte skrivet ...)
Var försiktig när du väljer filnamn för klasser. Det är extremt svårt att ändra dem senare.
(ännu inte skrivet ...)
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
KDE-projektet använder docbook för att skapa projektets handbok (dvs. användarmanualen). Hanboken är tillgänglig via programmets menyrad genom att välja -> när programmets grafiska gränssnitt visas i KDE. Efter att projektet har byggts, visas handboken i KDE:s Hjälpcentral. Den ska förklara för användaren hur programmet fungerar, vilka huvudfunktionerna är och hur det anpassas. Den ska också förklara avancerade funktioner, om några sådana finns.
Alla KDE-baserade mallar i KDevelop har underkatalogen doc, som innehåller mallen index.docbook i katalogen en, för att komma igång med att skriva användarhandboken. Du redigerar index.docbook i KDevelop, och börjar med att ändra personlig information som namn, e-post, etc. Titta på kommentarerna i filen och försök följa anvisningarna för att påbörja programdokumentationen. Bygg om projektet för att se ändringarna i Hjälpcentralen.
Du måste installera projektet med -> eller i KDevelop för att kunna se handboken i hjälpcentralen.
Du hittar mer information om syntaxen för docbook på KDE:s webbplats för dokumentation.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
(ännu inte skrivet ...)
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
KDevelop integrerar många verktyg, skript och mallar med ett gemensamt användargränssnitt. De grundläggande delarna är
flera lägen för användargränssnittet som du kan använda för att välja arbetsområdets utseende och känsla,
en programguide, som hjälper dig ställa in ett nytt projekt,
flera system för projekthantering, som hjälper till att bygga och hantera projektet,
några redigeringsverktyg för att enkelt kunna arbeta med programtexten,
diverse filbläddrare, som ger dig olika vyer av filsystemet,
diverse klassbläddrare för att hjälpa dig underhålla klasser och deras förhållanden i ett objektorienterat programmeringsprojekt,
ett avlusningsgränssnitt för att hitta och ta bort programfel inifrån KDevelop, och
flera insticksverktyg, utökningsbara moduler, eller delprogram, som laddas när programmet kör och vid behov. Det gör det möjligt för dig att bara aktivera de funktioner som du verkligen behöver.
en uppsättning andra diagnos-, dokumentations- och optimeringsverktyg.
Det finns i själva verket tre KDevelop-baserade program:
Den integrerade utvecklingsmiljön KDevelop: Det här är platsen där du oftast arbetar.
Den fristående dokumentationsbläddraren KDevelop assistent: Isolerar alla kraftfulla dokumentationsfunktioner i utvecklingsmiljön KDevelop i ett separat verktyg. Det här är praktiskt när du vill slå upp någon programmeringsdokumentation, men inte vill starta den fullständiga utvecklingsmiljön.
KDevelop Designer: Utökar Qt™ Designer för grafiska gränssnitt med element specifika för KDE och integreras på ett bra sätt i utvecklingsmiljön KDevelop.
KDevelop erbjuder fyra olika gränssnittslägen (klicka på lägesnamnet för att se ett exempel):
Det här är ett nytt sorts användargränssnitt som både optimerar arbetsutrymmet och ger en intuitiv användning av verktygen.
Alla verktygsfönster är dockade som en flikrad omkring huvudramens område. De är grupperade till vänster, längst ner och till höger enligt de tjänster de erbjuder.
Editor- och bläddrarfönster överlagras i ett stort fönster med flikar mitt i huvudramens område.
Alla verktygsvyer är från början dockade i huvudramen.
Editor- och bläddrarfönster existerar som toppnivåfönster inne i ett vyområde i huvudramen.
Alla verktygsvyer är från början dockade i huvudramen.
Editor- och bläddrarfönster överlagras i ett fönster med flikar.
Alla editor-, bläddrar- och verktygsfönster är toppnivåfönster direkt på skrivbordet.
Huvudkomponenten innehåller bara menyraden, verktygsrader och statusraden.
För att byta läge för användargränssnittet, välj -> i menyraden. Dialogrutan Anpassa KDevelop dyker upp, där du måste välja Användargränssnitt i trädet till vänster. Då öppnas inställningssidan som visas nedan:
Välj ett användargränssnittsläge
(Äldre versioner av KDevelop erbjuder bara valet Toppnivåläge.)
i rutan Huvudsakligt användargränssnitt välj alternativknappen för användargränssnittsläget du vill arbeta med.
Beroende på användargränssnittsläget du valde, blir andra inställningsrutor tillgängliga där du kan skräddarsy ytterligare detaljer för utseende och känsla i dina inställningar. Se kapitlet Välja användargränssnitt för mer information.
Glöm inte att starta om KDevelop för att dina val ska få effekt.
Det finns ett fullskärmsläge tillgängligt för att maximera utrymmet, som expanderar huvudramens område till skärmkanterna. Ytterligare utrymme kan återtas genom att dölja menyraden. Du kan förstås också dölja alla verktygsrader, som vanligt i KDE-program.
För att byta till eller från fullskärmsläge, välj -> i menyraden, eller tryck på Ctrl-Skift-F. Det finns också en ikon för Fullskärmsläge tillgänglig i Bläddringsverktygsraden..
För att dölja menyraden, välj -> i menyraden, eller tryck på Ctrl-M. Du kan också lägga till ikonen Visa menyrad på en lämplig verktygsrad, t.ex. Bläddringsverktygsraden för ändamålet. För att visa menyraden igen, måste du trycka på Ctrl-M, eller använda ikonen Visa menyrad, om den är tillgänglig.
(... ännu inte skrivet ...)
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Totalt sett beror ett projekt på någon form av projekthanteringssystem. KDevelop erbjuder fyra projekthanteringssystem som programmeraren kan välja bland när ett nytt projekt skapas.
Automake-projekt använder de vanliga utvecklingsverktygen för GNU.
Qmake-projekt använder Trolltechs Qmake-projekthantering.
ANT-projekt använder Apaches ANT-projekthantering för Java-utveckling.
Eget projekt kräver att du underhåller din egen Makefile.
Projekt som skapats med Hantering av automake i KDevelop gör det mycket lätt för utvecklare att använda de vanliga GNU utvecklingsverktygen. De tillhandahåller
ett bättre sätt att skapa en Makefile och
ett bra och säkert sätt för snabb anpassning till olika system med configure-skript skapade av autoconf.
För utvecklare som glädjer sig åt flexibiliteten och känslan i Qt™:s qmake-system, erbjuder KDevelop möjlighet att hantera qmake-baserade projekt (.pro-filer) inne i det grafiska gränssnittet.
För mer information om Qmake-projekthantering se Qmake User Guide, som ska finnas med i distributionen, eller ta en titt på hemsidan Trolltech Documentation där du hittar Qmake-dokumentationen under “Qt C++ GUI Application Development Toolkit”.
CMake kommer att vara KDE:s byggsystem för KDE 4 och KDevelop tillhandahåller redan några mallar baserade på CMake för C och C++. Du behöver bara programmet cmake i $PATH för att bygga dem.
För att ställa in ett nytt C eller C++ projekt i KDevelop välj ->->->->.
Java™-utvecklare kan vilja använda Apaches ANT-projekthantering för sina projekt. För att skapa ett nytt ANT-projekt i KDevelop, välj ->->->->.
För mer information se Ant-projektets hemsida.
Om du föredrar att underhålla din egen Makefile för projektet, kan du använda alternativet med ett eget projekt i KDevelop. Det kan vara passande i projekt med ovanlig struktur, eller om du vill behålla fullständig kontroll över byggprocessen.
Om du ändå inte verkligen behöver den egna projekthanteringens extra flexibilitet och kontroll, bör du fundera på Hantering av automake eller någon annan projekthantering, eftersom de förenklar bygg- och distributionsprocessen för program väsentligt.
Distributionen av ditt program kräver inte att slutanvändaren har installerat något ytterligare än
en lämplig kompilator,
en länkare, och
de lämpliga utvecklingsbiblioteken,
vilket åtminstone för C++ program oftast är fallet. Men du kan lika väl distribuera binärpaket av programmet. Hur som helst, behöver inte slutanvändaren av produkten installera KDevelop.
Om du ger bort din källkod, råder vi dig att också ta med projektfilen för KDevelop. Det gör det mycket enkelt för andra utvecklare, om de använder KDevelop, att arbeta med källkoden.
För projekt där flera utvecklare, som kanske arbetar på olika ställen, är inblandade, bör detta vara fallet ändå. Du kan försäkra dig om överensstämmelse för alla Makefile, för att inte råka ut för bekymmer.
Särskilt för program med flera språk, arbetar inte översättare direkt med källkoden, utom i fall som kräver rättning för att göra det möjligt med översättningsstöd.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
KDevelop är en mycket kraftfull och flexibel integrerad utvecklingsmiljö, som erbjuder många möjligheter för anpassning enligt dina behov. För att göra inställningar, välj ->. Det gör att inställningsdialogrutan dyker upp, som består av ett fönster för att välja inställningar till vänster och inställningsdialogrutan till höger, vars innehåll varierar beroende på gruppen av inställningar du valt.
Välj en grupp av inställningar
Vi beskriver inställningarna i en annan ordning, uppdelat i huvudämnena Allmänna inställningar, Anpassa dokumentationen och Avancerade inställningar, vilket leder till en intuitivare läsupplevelse.
Om du vill slå upp en viss grupp av inställningar direkt, använd en av följande länkar.
| Allmänt |
| Användargränssnitt |
| Filmallar |
| Editor |
| Förkortningar |
| Skript |
| Menyn Verktyg |
| Externa verktyg |
| Dokumentation |
| Kodsnuttar |
| Fillista |
| Filväljare |
| Skapa ny klass i C++ |
| Formatering |
| Tolkning av C++ |
Allmänna inställningar rör de vanligare aktiviteterna för att anpassa KDevelop, där det finns:
Aktiviteter för källkodsredigering
Inställningsdialogrutan Allmänt låter dig definiera grundläggande beteende hos KDevelop som sällan ändras under dagligt arbete. Det rör:
definiera en standardprojektkatalog som KDevelop ska använda för nya projekt.
bestämma om du vill att KDevelop automatiskt ska ladda projektet du senast arbetade med.
Meddelandeutmatningen som KDevelop använder för att visa t.ex. kompileringsprocesser, och
Programutmatningen, som visar fel- och tillståndsinformation som rör ett program som kör.
om långa rader radbryts, och
om meddelanden om katalogbyte som ges av make visas.
Detaljnivån för meddelanden om kompileringsprocessen som visas i fönstret Meddelandeutmatning.
Dialogrutan för allmänna inställningar
Markera den här kryssrutan om du vill fortsätta att arbeta med det senaste projektet du arbetade med. Det gör att KDevelop automatiskt laddar projektet vid start. Det visas oftast med samma tillstånd som du lämnade arbetet, så att du enkelt kan fortsätta.
Normalt använder KDevelop en gemensam överliggande katalog för alla nya projekt. Skriv in absolut sökväg till denna gemensamma katalog i rutan eller välj den i katalogstrukturen. KDevelop placerar alla nya projekt här som underkataloger.
Du kan förstås ändra katalogsökvägen för ett nytt projekt när du ställer in det i Projektguiden.
Fönstret Programutmatning används för att visa fel- och tillståndsinformation från program som körs inne i KDevelop. Det är information som programmen oftast skickar till konsollen när de körs fristående. Alltså behöver du inte lämna den grafiska utvecklingsmiljön när du testar programmet du för närvarande arbetar med.
För att välja ett lämpligt teckensnitt för fönstret Meddelandeutmatning, klicka på knappen Fönsterteckensnitt som visar teckensnittet som för närvarande är valt (det står “Arial” på bilden ovan). KDE:s vanliga dialogruta Välj teckensnitt dyker upp, där du kan välja teckensnittet som ska användas.
När KDevelop först startar initieras teckensnittsinställningen till det standardteckensnitt som KDE-användaren har inställt. Den här inställningen är fast, så om du ändrar ->-> i Inställningscentralen påverkas inte KDevelops teckensnittsval. Du måste explicit välja ett nytt teckensnitt för fönstret Meddelandeutmatning.
KDevelop förbehandlar meddelanden som fönstret Meddelandeutmatning visar under byggprocessen för att filtrera onödig information. Du kan styra detaljnivån som KDevelop visar med kombinationsrutan i det här fältet.
Visa bara varningar, fel och filnamnen som kompileras.
Undertryck alla kompileringsflaggor, och ändra format till något mer läsbart.
Visa all utmatning utan förändring.
Det finns ett alternativt sätt att ändra detaljnivå för kompilatorutmatning. Högerklicka bara i fönstret Meddelandeutmatning och välj motsvarande detaljnivå i menyn som dyker upp.
Normalt radbryter KDevelop långa rader i fönstret Meddelandeutmatning så att värdefull information inte lätt förbises. Ibland kan detta skräpa ner långa meddelandelistor. Ta bort kryssmarkeringen om du inte vill att radbrytning ska ske.
Det finns ett alternativt sätt att ändra radbrytningen. Högerklicka bara i fönstret Meddelandeutmatning och markera eller avmarkera alternativet i menyn som dyker upp.
Verktyget make visar oftast meddelanden som “Entering directory” eller “Leaving directory” när byte av arbetskatalog sker. Eftersom det här skräpar ner listan med meddelanden i fönstret Meddelandeutmatning undertrycker KDevelop normalt dessa meddelanden. Markera kryssrutan om du vill observera vilka kataloger som make arbetar i.
Ändringar av inställningen påverkar bara behandling av nya meddelanden. Gamla katalogbytesmeddelanden förblir synliga när den här funktionen stängs av.
Det här låter dig välja hur du vill att .ui-filer ska visas i KDevelop. KDevelop levereras med sin egen Designer för grafiska gränssnitt som heter KDevDesigner. Den kan antingen inbäddas eller köras som ett separat program. Qt Designer kan också användas för att redigera .ui-filer.
Använd KDevelops inbäddade Designer
Använder KDevelops egen Designer inbäddad i KDevelop.
Kör KDevelop Designer som ett separat program
Programmet KDevDesigner körs separat i ett eget fönster.
KDevDesigner i eget fönster
Kör Qt Designer
Qt-Designer från installationen av Qt kommer att startas externt, när du klickar på en .ui-fil i KDevelop.
Här väljer du vilken terminal du vill ska integreras i KDevelop.
Använd KDE-inställning
Använder KDE:s inställning som anges i Inställningscentralen under fliken KDE-komponenterKomponentväljare, som anger vilket terminalprogram som används av alla KDE-program som behöver en terminal.
Annan:
Välj någon annan terminal som skiljer sig från den förvalda.
Som redan nämnts i kapitlet Tillgängliga lägen för användargränssnitt finns det fem olika sätt som KDevelops arbetsområde kan ställas in, nämligen:
Det här är en förenklad version av IDEA-användargränssnittet. Det är konstruerat för att vara enkelt och rent. Det använder inte heller dockade verktygsvyer.
Det här är en klon av IDEA-användargränssnittet som liknar fliksidläge, och är förvalt läge.
Alla verktygsvyer är dockade i huvudramen från början. Editorn och bläddringsvyer existerar som toppnivåfönster inne i huvudramens vyområde. Ett typiskt exempel på detta användargränssnitt är MS Visual Studio 6.0.
Alla verktygsvyer är dockade i huvudramen från början. Editorn och bläddringsvyer läggs ovanpå varandra i ett flikfönster. Ett typiskt exempel på detta användargränssnitt är KDEStudio, en annan C++ integrerad utvecklingsmiljö i KDE-världen.
Alla editorvyer, bläddringsvyer och verktygsvyer är toppnivåfönster (direkt på skrivbordet). Huvudkomponenten innehåller bara menyn, verktygsrader och statusraden. Ett typiskt exempel på detta användargränssnitt är Borland Delphi 6.0.
För att byta användargränssnittets läge välj -> i menyraden. Dialogrutan Anpassa KDevelop dyker upp, där du ska välja Användargränssnitt i trädet till vänster. Då visas följande inställningsdialogruta till höger:
Välj ett användargränssnittsläge
Markera alternativknappen för gränssnittsläget du vill byta till, och klicka därefter på .
Glöm inte att starta om KDevelop för att alla dessa val ska få effekt.
Om du antingen valt Förenklat IDEA-fönsterläge, IDEA-fönsterläge eller Fliksidläge blir ytterligare två inställningsrutor tillgängliga: Använd flikar och Använd stäng när musen hålls stilla. De gör det möjligt att anpassa under vilka omständigheter flikar visas ovanför dokumentfönster, och om du kan stänga dokument med ett klick på flikens ikon.
I Förenklat IDEA-fönsterläge och IDEA-fönsterläge finns ännu en inställningsruta tillgänglig, Fliklayout för verktygsvy som låter dig välja mellan olika storlekar hos flikarna för verktygsvyer som omger huvudarbetsytan i dessa lägen.
Med IDEA-fönsterläge och fliksidläge finns det normalt namngivna flikar ovanför dokumentfönstren, så att du enkelt kan välja olika dokument med ett vänsterklick. Om du föredrar att ge mer utrymme till dokumentfönstren på huvudarbetsytan i KDevelop, kan du byta till ett annat beteende i inställningsrutan Använd flikar.
Det här är standardvärdet: Visa en flik som består av en ikon och dokumentnamnet ovanför varje dokumentfönster på huvudytan av skärmen i KDevelop.
Visa inte en flik när bara ett dokument är öppet. Om mer än ett dokument är öppet, visar KDevelop dock en flikrad som motsvarar valet Alltid ovan. Du kan vilja använda det här läget om du oftast arbetar med ett enda dokument, eftersom läget tillhandahåller ett större vertikalt utrymme.
Visa aldrig en flikrad för att välja dokument. Du kanske föredrar det här läget om du sällan använder musen för att byta mellan dokument. Det tillhandahåller ett större vertikalt utrymme för alla dokumentfönster. Använd menyn i KDevelop för att välja ett annat dokumentfönster eller stänga något.
När du anpassar KDevelop att visa flikraden för dokument, antingen alltid eller när mer än ett dokument är öppet på huvudarbetsytan, kan du lägga till ytterligare en funktion till flikarna förutom möjligheten att välja dokument. Använd inställningsrutan Använd stäng när musen hålls stilla för detta.
Det här är standardbeteendet. Ingen extra funktion läggs till för flikarna. De kan bara användas för att välja dokumentfönster med vänsterklick.
När du markerar den här alternativknappen, låter KDevelop dig stänga ett dokumentfönster med ett vänsterklick. Använd musen för att peka på den lilla ikonen till vänster i flikraden. Den ändras till en stängningssymbol. Klicka nu med vänsterknappen på den ändrade symbolen, så stänger KDevelop motsvarande dokumentfönster.
När den här alternativknappen är markerad, låter KDevelop dig stänga ett dokumentfönster som beskrivits för fallet Ja ovan. Ikonen ändras dock inte omedelbart, utan det blir en kort fördröjning innan stängningsikonen dyker upp.
Inställningsrutan Fliklayout för verktygsvy är bara tillgänglig i IDEA-fönsterläge. Använd alternativknapparna för att ställa in utseendet för verktygsvyernas flikar som omger huvudarbetsytan i detta läge.
Varje flik visar bara en ikon. Om motsvarande verktygsvy visas, öppnas fliken och en beskrivande text för verktygsvyn visas. Du kan vilja använda det här läget om du arbetar med en bildskärm med begränsad upplösning.
Ikonerna är dock inte särskilt beskrivande. Om du vill ta reda på vilken verktygsvy som hör ihop med en given flik, peka på den med musen och vänta en sekund. Ett kort verktygstips dyker då upp med verktygsvyns namn.
Det här är standardläget för visning av verktygsvyernas flikar. Varje flik visar namnet på tillhörande verktygsvy.
Om du tycker att den vanliga visningen av text för verktygsvyerna verkar för trist, och du arbetar på en bildskärm med hög upplösning, kan du vilja markera den här alternativknappen. Den gör att namnet för motsvarande verktygsvy visas på varje flik med en ikon till vänster om det, vilket gör det enklare att skilja på flikarna. Ett exempel visas på illustrationen Radbrytning av verktygsvyernas flikar nedan.
Om du valde att låta IDEA-fönsterlägets flikar för verktygsvyer visa text (med eller utan tillhörande ikoner) behöver du inte oroa dig för att de döljs bakom något verktygsvyfönster. Om ett av de nedre verktygsvyfönstren upptar mer utrymme än vad som är tillgängligt för att visa alla (vertikala) flikar, radbryts de som illustrationen visar:
Det aktiva verktygsvyfönstret måste visas fast (utan överlappning), och dela arbetsytan med andra fönster, för att tvinga fram en sådan radbrytning av flikar. Klicka på den lilla fyrkanten i fönsterramen för att åstadkomma läget som visas i exemplet.
KDevelop låter dig välja ditt favoritverktyg för textredigering. Markera raden Editor i trädet till vänster i fönstret Anpassa KDevelop. Följande dialogruta visas till höger:
Välja en editor
För att välja en ny editor, klicka på pilen i kombinationsrutan. Beroende på gränssnitten för redigeringsdelprogram som KDE-versionen har kompilerats med, ser du en lista med editorer som du kan välja bland (se den viktiga anmärkningen nedan om detta). Klicka på editorn som du vill ha och klicka på Ok. För närvarande finns två möjligheter:
Det här är KDE:s vanliga Kate redigeringsdelprogram.
Det här är editorn som Qt™ tillhandahåller i sin Designer-komponent.
Dessa redigeringsgränssnitt är fullständigt integrerade med KDevelops integrerade utvecklingsmiljö. I synnerhet tillhandahålls möjligheten att hoppa till källkodsraden som orsakat ett fel genom att bara klicka på felmeddelandet i fönstret Meddelandeutmatning.
Att byta editor påverkar inte filer som redan är öppna. Det finns två sätt att fortsätta. Stäng antingen alla öppna textfönster och öppna dem igen ett i taget. Eller stäng helt enkelt hela projektet och öppna det igen. Fönstren öppnas då automatiskt med det nya texteditorgränssnittet.
KDevelop låter dig använda editorgränssnitt som har registrerats med KDE och som tillhandahåller ett KatePart-gränssnitt. Om du saknar en av möjligheterna som visas ovan, kontrollera i din KDE-installation om motsvarande KPart installerats på ett riktigt sätt.
Vad som ska göras om filen har ändrats externt:
Filen markeras som ändrad externt, och användaren blir tillfrågad om att bekräfta alla försök att skriva över den.
En dialogruta underrättar användaren att filen har ändrats, och erbjuder användaren att uppdatera filen.
Alla filer som inte är ändrade i minnet, uppdateras och en varning visas vid eventuella konflikter.
(... ännu inte skrivet ...)
KDevelop formaterar automatiskt källkodstext med en fördefinierad stil. Stilen är mycket anpassningsbar.
Funktionen för att formatera om källkod är för närvarande bara tillgänglig för C, C++ och Java™. I synnerhet kan du inte använda den för skriptspråk som t.ex. PHP. Det beror på att KDevelop använder programmet astyle för att implementera funktionen.
För att ställa in en specifik formateringsstil, välj -> i menyraden. Dialogrutan Anpassa KDevelop dyker upp, där du ska välja Formatering av källkod i trädet till vänster. Då visas en serie av tre flikar med inställningar till höger, benämnda Allmän, Indentering och Annan.
Alla stiländringar gäller bara för nyinmatad text. Om du vill ändra formateringsstil för en befintlig källkodstext måste du uttryckligen använda kommandot ->.
Det exakta resultatet av dessa definitioner av formateringsstil beror på editorn du använder. För närvarande är de flesta inställningar anpassade för redigeringsdelprogrammet Kate (“Inbäddningsbar avancerad texteditor”). Vissa andra editorer (t.ex. Qt-editorn) kan bero på sina egna formateringsinställningar. I dessa fall måste du experimentera för att ta reda på exakta effekterna av stilinställningarna som tillhandahålls här.
Det kan finnas oförenligheter mellan inställning av stilar som tillhandahålls här och editorn du använder, i sådan utsträckning att det i extrema fall till och med kan förstöra dina filer. Försäkra dig om att du har en säkerhetskopia av dina källkodsfiler innan du provar inställningarna med en editor som inte är standard i KDE.
Fliken Allmänt i dialogrutan Formatering av källkod låter dig välja en av fem fördefinierade formateringsstilar för källkod.
Allmän inställning av formateringsstil för källkod
Ett exempel på formaterad källkod visas i fältet till höger. Om du inte tycker om någon av de fördefinierade stilarna kan du klicka på den översta alternativknappen Användardefinierad, och definiera en egen formateringsstil för källkod du föredrar under de övriga två flikarna som då blir tillgängliga.
För närvarande illustreras bara de fördefinierade formateringsstilarna för källkod med en exempeltext. Om du bestämmer dig för att definiera din egen stil, finns ingen visning av exempel tillgänglig. Du måste experimentera med verklig källkodstext för att skräddarsy inställningarna som du vill ha dem.
Lämplig indentering är det huvudsakliga sättet att öka läsbarhet för källkodstext. Om du väljer fliken Indentering i dialogrutan Formatering av källkod visas en serie med formateringsval för indentering grupperade i följande tre rutor:
Inställning av indenteringsstil för källkod
Fördefinierade formateringsval gör att källkodstexten liknar formateringsstilen enligt ANSI:
namespace foospace
{
int Foo()
{
if (isBar)
{
bar();
return 1;
}
else
return 0;
}
}
Alternativknapparna grupperade under Utfyllnad anger hur indentering av källkodstexten visas.
Det här gör att editorn infogar ett tabulatortecken för varje indenteringsnivå. Tabulatorbredden är fördefinierad i editorns inställningar (oftast kolumner om 8 eller 4 tecken). Använd -> för att definiera om den.
Proceduren för att definiera verklig tabulatorbredd beror på editorn du valt under inställningssteget Välja en editor. Du måste slå upp motsvarande editors hjälp för att ta reda på den.
Om du markerar alternativknappen, lägger editorn till det antalet mellanslag för varje indenteringsnivå. Ändra värdet från normalvärdet 2 till indenteringsbredden du föredrar.
Det här anger vilka (av C/C++) konstruktioner som formateras med en extra indentering från den aktuella indenteringsnivån.
Normalt används bara extra indentering för namnrymder och etiketter. Du kanske vill experimentera med olika inställningar för att anpassa extra indenteringar som du vill ha dem.
Inställningarna som är grupperade här gäller de fall när källkodsformateringen automatiskt radbryter långa källkodsrader. De tar hänsyn till två specialfall, nämligen att det ska finnas tillräckligt med utrymme för källkoden för djupa indenteringsnivåer och att villkor ska få extra indentering för fortsättningsrader så att de utmärks på ett riktigt sätt.
Det här gäller bara för fall med statisk radbrytning när en fast maximal radlängd används i källkodstexten. Om du ställer in editorn för att bara dynamiskt radbryta långa rader vid visning (som är möjligt i redigeringsdelprogrammet Kate) visas oftast inte effekten av de här inställningarna.
Den här inställningen begränsar maximal möjlig indentering av fortsättningsrader så att det finns tillräckligt med utrymme för att texten ska förbli läsbar. Inga fortsättningsrader indenteras någonsin förbi kolumnantalet som du väljer i det här fältet.
Standardinställningen är 40 kolumner (en halv standardsida på 80 kolumner). Du kan vilja öka det här värdet för att hantera bredare papper (t.ex. om du använder utskrift av källkod på liggande format). Eller minska värdet på motsvarande sätt för att ta hänsyn till större marginalinställningar för dina utskrifter.
Villkor eller källkod som till exempel följer en tilldelningsoperator ska ofta få en extra indentering för fortsättningsrader för att göra texten läsbar. Värdet på den extra indenteringen definieras här.
Standardvärdet är “Två gånger nuvarande”, vilket betyder att fortsatta villkor får en extra indenteringsnivå jämfört med indenteringsstorleken du valt i gruppen Utfyllnad. Du kan ändra den extra indenteringen till ett annat fast värde (inklusive noll) med pilarna, eller genom att direkt skriva in värdet.
Annan inställning av formateringsstil för källkod
Alternativknapparna i (den något felaktigt benämnda) gruppen Hakparenteser styr positionen av klamrar som avdelar (C/C++) källkodstext. Det finns tre möjligheter att välja bland.
Det här infogar en radbrytning innan varje inledande klammer. Båda avdelande klamrar i alla block placeras på samma indenteringsnivå som blockets huvudsats.
namespace foospace
{
int Foo()
{
if (isBar)
{
bar();
return 1;
}
else
return 0;
}
}
Det här behåller inledande klammern i ett block på samma nivå som blockets huvudsats. Avslutande klamrar är på samma indenteringsnivå som blockets huvudsats. Det avslutande else i en if-sats hålls på samma nivå som avslutande klammer i föregående block.
namespace foospace {
int Foo() {
if (isBar) {
bar();
return 1;
} else
return 0;
}
}
Det här är en kompromiss mellan stilarna som anges ovan. Avgränsande klamrar för funktionsblock placeras på nya rader. Klamrar som inleder ett block i en villkorssats eller snurra behålls på samma rad.
namespace foospace
{
int Foo()
{
if (isBar) {
bar();
return 1;
} else
return 0;
}
}
Normalt minimerar KDevelop användning av mellanslag i källkodstext.
if (isBar(fooArg)==barValue)
Du kan öka läsbarheten om du tvingar källkodsformateringen att infoga extra mellanslag på särskilda platser.
Vad som i själva verket avses är att lägga till mellanslag omkring text som är inom parenteser. Det ökar läsbarheten för funktionsargument och villkor.
if ( isBar( fooArg )==barValue )
Det här lägger till mellanslag omkring tilldelningar och jämförelseoperatorer för att öka läsbarheten.
if (isBar(fooArg) == barValue)
Det finns några få tillfällen då du inte vill att källkodsformateringen ska dela en lång rad. Detta kan styras här för C/C++ kod.
Det här behåller enradssatser tillsammans i vissa situationer även om de överskrider en fast maximal radlängd.
Det här behåller enradsblock tillsammans i vissa situationer även om de överskrider en fast maximal radlängd.
När du redigerar i KDevelop kan du lagra delar av kod som ofta används som kodsnuttar. För att anpassa funktionerna hos delprogrammet för kodsnuttar, välj -> i menyraden. Dialogrutan Anpassa KDevelop dyker upp, där du ska välja Kodsnuttar i trädet till vänster. Då visas följande dialogruta till höger:
Anpassa verktyget för kodsnuttar
Markera kryssrutan Visa kodsnuttens text i verktygstips om du vill visa den lagrade texten i ett verktygstipsfönster så fort du håller musmarkören över den kodsnuttens rubrik.
Verktyget Kodsnuttar tillåter varierande text på fördefinierade platser när som helst när du infogar en kodsnutt i en fil. För att åstadkomma det, tillhandahåller Kodsnuttar sin egen variabelmekanism. Du kan ställa in dess beteende i gruppen Variabler.
Verktyget Kodsnuttar känner igen variabler i texten genom att omge variabelnamnet med särskilda skiljetecken. För att använda ett eget skiljetecken, ändra det fördefinierade tecknet $ i fältet Avskiljare.
En dialogruta för varje variabel i en kodsnutt visar i tur och ordning en särskild dialogruta för varje variabel som verktyget hittar när den valda kodsnutten infogas.
En dialogruta för alla variabler i en kodsnutt visar en gemensam dialogruta där användaren måste fylla i värden för alla variabler innan kodsnutten infogas.
KDevelop tillhandahåller insticksprogrammet Filväljare som när det laddas vid start, gör det möjligt att navigera till vilken fil eller katalog som helst på systemet.
Filväljaren (IDEA-läge)
Beteendet hos Filväljaren kan anpassas i stor utsträckning. Välj -> i menyraden. Dialogrutan Anpassa KDevelop dyker upp, där du ska välja Filväljare i trädet till vänster. Då visas följande dialogruta till höger.
Anpassa filväljaren
Det finns en verktygsrad längst upp i Filväljaren som kan anpassas som vanligt i gruppen Verktygsrad.
Procedur 4.1. Lägg till en åtgärd i verktygsraden
Markera ett objekt till listan till höger Aktuella åtgärder, som den nya åtgärden ska infogas efter.
Markera åtgärden som ska infogas i listan till vänster Tillgängliga åtgärder.
Klicka på (den övre) högerpilen mellan de båda listorna.
Åtgärden tas bort från listan Tillgängliga åtgärder och infogas i listan Aktuella åtgärder under den markerade åtgärden.
Att uppdatera innehållet i fönstret Filväljare tar tid och resurser, särskilt vid byte till en annan katalog. Därför är Filväljaren normalt inställd på så sätt att dess innehåll bara ändras på begäran, dvs. när du väljer en annan katalog eller när du uttryckligen vill uppdatera innehållet.
Klicka på knappen Uppdatera i verktygsraden för att uppdatera innehållet i Filväljaren. Den här verktygsradsknappen är dock inte normalt tillgänglig. Du måste först lägga till den där.
Du kan ställa in Filväljaren att omedelbart visa vissa ändringar i ditt arbete. Inställningarna i gruppen Automatisk synkronisering är ansvariga för detta.
Om du markerar den här kryssrutan, uppdateras innehållet i Filväljarens fönster så fort du går till ett annat dokument som redan är öppnat, t.ex. när du klickar på fliken för motsvarande redigeringsfönster i IDEA-läge. Om det behövs byter Filväljaren till katalogen som filen tillhör och uppdaterar skärmen för att visa det verkliga innehållet där.
Om du markerar den här kryssrutan, uppdateras innehållet i Filväljarens fönster så fort ett dokument öppnas, t.ex. via menyn ->. Om det behövs byter Filväljaren till katalogen som filen tillhör och uppdaterar skärmen för att visa det verkliga innehållet där.
Om du markerar den här kryssrutan uppdateras Filväljarens fönster så fort det blir synligt igen. Om det behövs byter det till katalogen som aktuellt dokument tillhör och uppdatera skärmen så att det verkliga innehållet där visas.
Du kan kombinera inställningarna fritt för att skräddarsy verkligt beteende hos Filväljaren som du vill.
Det finns två kombinationsrutor längst upp och längst ner i Filväljarens innehållsfönster som styr katalogen som visas (den övre kombinationsrutan) och filter som används för visningen (den nedre kombinationsrutan). En historik av de senaste inställningarna finns i urvalsfältet i varje kombinationsruta. Du kan ställa in antalet historikposter enligt följande.
Skriv in maximalt antal katalogval som den övre kombinationsrutan ska komma ihåg här.
Skriv in maximalt antal filterdefinitioner som den nedre kombinationsrutan ska komma ihåg här.
Normalt är Filväljaren inställd så att den visar den senaste sessionen igen när KDevelop startas nästa gång. Du kan ändra beteendet i inställningsgruppen Session.
Om KDevelop automatiskt startades om av KDE:s sessionshantering, så har ändringar av dessa inställningar ingen effekt. I detta fall återställs alltid plats- och filterinställningar från den senaste KDE-sessionen.
Ta bort kryssmarkeringen här om du inte vill att platser som visas ska kommas ihåg mellan sessioner.
Om du markerad en av inställningarna för automatisk uppdatering kan platserna som visas automatiskt ändras oberoende av vad som har kommits ihåg från den tidigare sessionen.
Ta bort kryssmarkeringen här om du inte vill att filter som används för visningen ska kommas ihåg mellan sessioner.
KDevelop innehåller en mycket kraftfull dokumentationsfunktion som tillhandahåller möjlighet att komma åt flera olika sorters omfattande dokumentation. I IDEA-läge hittar du till exempel fliken Dokumentation vid arbetsområdets högerkant.
Dokumentationsträdet i KDevelop (IDEA-läge)
KDevelop måste ha laddat insticksprogrammet Dokumentation för att kunna visa dokumentationsträdet. Se avsnittet Insticksverktyg för mer information.
Du kan ställa in innehållet i dokumentationsträdet om du väljer -> i menyraden. Dialogrutan Anpassa KDevelop dyker upp, där du ska välja Dokumentation i fönstret till vänster.
Inställningssidan som visas på så sätt, har tre inställningsdialogsidor med flikar, närmare bestämt:
| Dokumentationssamlingar |
| Fulltextsökning |
| Annat |
Anpassningen av dokumentationsinställningarna har delats upp i en serie dokumentationssamlingar, där var och en ger åtkomst till dokumentationsfiler av något unikt format och någon typ av innehåll. Inställningarna styr vilka dokumentationsposter som listas på sidan Innehåll under funktionen Dokumentation i KDevelop, och hur användaren kan komma åt detaljer i dokumentationen med indexerade sökningar och fulltextsökningar.
Fliken Dokumentation tillhandahåller en serie inställningssidor som är ordnade vertikalt som en hög med indexkort. En sida i taget visas efter ett klick på titeln för dess indexkort:
| Qt™-dokumentationssamling |
| CHM-dokumentationssamling |
| Doxygen-dokumentationssamling |
| KDevelop innehållsförteckning-dokumentationssamling |
| DevHelp-dokumentationssamling |
| Egen dokumentationssamling |
Ställa in dokumentationssamlingar
Alla inställningssidor under fliken Dokumentation använder en gemensam layout. Du hittar dokumentationsposter som för närvarande är tillgängliga, av typen som listas på den öppna sidan, till vänster och en uppsättning knappar till höger.
Det finns tre knappar tillgängliga för att underhålla innehållet på inställningssidorna för dokumentation:
Visar dialogrutan Egenskaper för dokumentationskatalog som visas nedan, där du kan välja källan för dokumentationsposten som ska läggas till och namnge den.
Visar dialogrutan Egenskaper för dokumentationskatalog som visas nedan, där du kan ändra källan för dokumentationsposten tidigare markerad i listan och byta namn på den.
Tar bort markerad dokumentationspost från listan.
Posten tas bara bort från listan. De verkliga källorna till dokumentationen förblir orörda. Du måste ta bort dem explicit på annat sätt.
Lägga till eller ändra en dokumentationspost
Knappen till höger om fältet Plats visar en katalogdialogruta vars poster oftast är filtrerade enligt den valda inställningssidans filtyp.
Fältet Titel kanske inte går att komma åt, beroende på dokumentationstypen som underhålls.
Varje inställningssida för dokumentation visar listade dokumentationsposter i en tabell med fyra kolumner:
Om kryssrutan är markerad, visas dokumentationsposten på sidan Innehåll under funktionen Dokumentation i KDevelop.
Genom att avmarkera kryssrutan Innehållsförteckning inaktiverar i sin tur kryssrutorna Index och Sök (se nedan). Alltså kan du inte ha poster i dokumentationssamlingen indexerade utan att visa deras innehåll.
Om kryssrutan är markerad byggs ett internt index för dokumentationsposten. Det ger snabb åtkomst till dokumentationen genom att använda sidan Index och (valfritt) Sökning under funktionen Dokumentation i KDevelop.
Det interna indexet byggs första gången användaren väljer sidan Index. Det fördröjer den första åtkomsten väsentligt, eftersom indexet läses från disk och lagras i en cache.
Alla efterföljande indexsökningar använder dock cachen och är därför väsentligt snabbare.
Om kryssrutan är markerad, inkluderas innehållet i dokumentationsposten i den sökvägen för fulltextsökning på sidan Sök under funktionen Dokumentation i KDevelop.
KDevelop utnyttjar programsamlingen htdig för att utföra fulltextsökningar. Sökningen görs i ett internt index, som htdig-maskineriet måste bygga innan den kan användas.
Alla ändringar av kryssrutorna under Sök påverkar alltså bara sökningar efter att du har byggt om indexet på sidan Sök under funktionen Dokumentation i KDevelop.
Det här är namnet på dokumentationsposten som den visas på sidan Innehåll under funktionen Dokumentation i KDevelop.
Tidigare versioner av KDevelop tillät att dokumentationsposterna visades baserat på varje projekt. Det är inte längre tillgängligt.
På den här inställningssidan anpassas all Qt™-dokumentation.
Ställa in Qt™-dokumentationssamlingen
Normalt fyller KDevelop i detta vid första start. Det tittar efter vanliga *.xml, eller *.dcf dokumentationsfiler i Qt™-installationskatalogen. Tabellen till vänster listar filerna som KDevelop hittade med deras vanliga titlar.
Om du har en installation som inte följer standard, finns det antingen ingen information listad alls, eller kanske adresserna pekar på felaktiga platser (t.ex. på en annan installation av Qt™ som är tillgänglig på systemet). Du kan justera posterna med knapparna till höger om listfältet.
KDevelop använder titlar som redan tillhandahålls av den installerade Qt™-dokumentationen. Därför är inte fältet Titel i dialogrutan Egenskaper för dokumentationskatalog åtkomligt.
Normalt visas inte all Qt™-dokumentation på sidan Innehåll under funktionen Dokumentation i KDevelop. Använd kryssrutan Innehållsförteckning i inställningstabellen för att välja vilken dokumentation som ska visas.
Om du vill att viss specifik Qt™-dokumentation ska inkluderas i sökindex eller fulltextsökning, använd kryssrutorna Index och Sök i inställningstabellerna.
På den här inställningssidan kan du samla dokumentation enligt Microsoft® CHM-hjälpfilstandard.
Ställa in Microsoft® CHM-standarddokumentationsfiler
Normalt är inställningssidan tom (som visas ovan). Du kan lägga till nya poster med knapparna till höger om listan. KDevelop filtrerar *.chm-filer i katalogdialogrutan som hör ihop med knapparna och .
För mer information om formatet för Microsoft® *.chm-filer, se t.ex. "PHP: Documentation - Extended CHM Format" på http://de2.php.net/docs-echm.php.
På den här inställningssidan anpassas all dokumentation av programmeringsgränssnitt som skapats av Doxygen.
Ställa in dokumentationen av programmeringsgränssnitt skapat av Doxygen
I kortet dokumenterar ett sådant programmeringsgränssnitt gränssnittet för vissa biblioteksfunktioner. Dokumentationen av programmeringsgränssnittet på den här sidan ska skapas av det externa verktyget Doxygen.
Dokumentation av programmeringsgränssnitt skapad av Doxygen består av en serie html-filer, som börjar med index.html. Dessutom kan det finnas tag-filer, som innehåller information med länkar till befintlig dokumentation av programmeringsgränssnitt. Alltså tittar KDevelop efter index.html och *.tag-filer vid sökning efter dokumentation av programmeringsgränssnitt skapad av Doxygen.
Vissa begränsningar i strukturen antas vid sökning efter dokumentation av programmeringsgränssnitt skapad av Doxygen. Katalogen där filen index.html finns ska innehålla underkataloger med separata dokumentationssamlingar. Var och en av underkatalogerna antas innehålla en .tag-fil och en underkatalog vid namn html/.
Du kan ta en titt på $ där det finns ett exempel på en sådan layout för dokumentation av programmeringsgränssnitt med Doxygen. KDEDIR/share/doc/HTML/en/kdelibs-apidocs
KDE:s äldre dokumentation av programmeringsgränssnitt skapat med KDoc stöds inte direkt längre. Om du fortfarande vill använda sådan dokumentation, kan du lägga till den på sidan Egen dokumentationssamling.
KDevelop har fyllt i en länk till aktuellt programmeringsgränssnitt för KDE-biblioteket, under förutsättning att någon hittades. Det finns flera sätt för KDevelop att få reda på den:
Antingen angav du väljaren --with-kdelibsdoxy-dir till kommandot configure när du kompilerade KDevelop (se kapitlet Hur man skaffar dokumentation av programmeringsgränssnittet för KDevelop).
Eller hittade kommandot configure automatiskt ett programmeringsgränssnitt för KDE-biblioteken som skapats med Doxygen på en av flera standardplatser som det känner till.
Eller som en sista utväg hittades $ när KDevelop först startade. KDEDIR/share/doc/HTML/en/kdelibs-apidocs/
Om KDevelop inte hittade ett giltigt programmeringsgränssnitt för KDE-biblioteken som skapats med Doxygen vid första start, är listan Dokumentation skapad av Doxygen tom.
Du kan lägga till dina egna poster med dokumentation av programmeringsgränssnitt (t.ex. från dina nuvarande projekt) genom att använda knapparna till höger. Om du vill att de ska inkluderas i indexerad sökning och/eller fulltextsökning, markera kryssrutorna Index eller Sök i inställningstabellen.
KDevelop använder titelinformationen från index.html. Därför är inte fältet Titel i dialogrutan Egenskaper för dokumentationskatalog åtkomligt.
KDE-systemet tillhandahåller mer dokumentation av programmeringsgränssnittet än bara KDE-bibliotekens programmeringsgränssnitt. Du behöver ytterligare information om gränssnitt om du t.ex. vill inkludera Kate-delprogrammet i dina program. För Kate-delprogrammet ska du till exempel kompilera och installera KDE:s programmeringsgränssnitt för basbiblioteken från källkoden (genom att använda kommandona make apidox och make install för källkoden i kdebase) och därefter lägga till en post i listan Dokumentation skapad av Doxygen på detta sätt:
Lägga till ett basprogrammeringsgränssnitt för KDE i listan
(Du ska förstås ersätta exempelkatalogen /opt/kde-cvs/ i fältet Plats med sökvägen till din KDE-installation.)
Du måste också lägga till programmeringsgränssnittet för ditt nuvarande projekt i Doxygen-dokumentationssamling. Tidigare versioner av KDevelop lade till det i dokumentationsträdet baserat på varje projekt. Det är inte längre tillgängligt.
Huvuddelen av KDevelops dokumentationsfunktion tillhandahåller omedelbar åtkomst av strukturerad dokumentation, både lokal och fjärrdokument. Du kan ställa in det på sidan KDevelop-innehållsdokumentation.
Tillhandahålla dokumentationsåtkomst strukturerad med KDevelop innehållsförteckning
KDevelop levereras med en samling fördefinierade KDevelop innehållsförteckningsfiler som automatiskt läggs till i tabellen vid installation. För att hålla visningen hanterbar, är bara de oftast använda markerade för att visas. Om du vill se annan dokumentation, markera kryssrutan Innehållsförteckning i inställningstabellen.
KDevelop innehållsförteckningsfiler kan inte indexeras för att utföra fulltextsökning eftersom de oftast pekar på fjärrplatser. Å andra sidan, kan en sådan .toc-fil ha ett manuellt definierat index, med taggen <index>. Alltså aktiveras kryssrutan index bara när KDevelop hittar taggen <index> i .toc-filen. (För mer information, se beskrivningen nedan i avsnittet om KDevelop innehållsförteckningsfiler.)
Kryssrutan Sök i inställningstabellen är alltid inaktiv.
Du kan lägga till nya poster med knapparna till höger om listan. KDevelop filtrerar *.toc-filer i katalogdialogrutan som hör ihop med knapparna och .
I motsats till tidigare versioner av KDevelop, så ändrar inte knappen *.toc-filerna på disk, så borttagningsåtgärden är nu säker.
Det finns en särskild funktion som hör ihop med detta. Som illustration, utför följande steg: Hitta en post strax under dokumentationen för Qt™ och KDE (t.ex. “KDE2 Development Book (kde.org)”). Klicka på plustecknet intill den. Ett träd visas, där du snabbt kan navigera till efterföljande kapitel som finns på en hierarkisk nivå flera nivåer djupare, allt utan att vara uppkopplad. Men om du till sist väljer ett av kapitlen, försöker KDevelop i många fall komma åt en fjärrfil med dokumentation.
Den logiska grunden för detta är inte bara att lokalt kunna navigera i fjärrdokumentation utan att slösa med nätverksresurser, utan också att ge utvecklare en enkel strukturerad åtkomst till dokumentation som behövs. Med verktygen som tillhandahålls här kan man komma åt nästan vilken lokal eller fjärrdokumentation som helst på ett strukturerat sätt, även om originalet är utan struktur eller strukturerat på ett annat sätt. Allt som behövs är åtkomst till filer och/eller delar av filer som kan visas av Konqueror.
Sådan strukturerad åtkomst blir möjlig genom användning av särskilda filer med “innehållsförteckning”, som anges med filändelsen .toc. Alla sådana KDevelop-innehållsförteckningsfiler innehåller en strukturerad XML™-beskrivning av dokumentet som ska kommas åt.
När KDevelop installerades har en serie med fördefinierade .toc-filer oftast placerats i katalogen $KDEDIR/share/apps/kdevdocumentation/tocs. De är ganska enkla, strukturerade textfiler. Du kan titta på dem med en texteditor eller ett annat verktyg för att visa text.
Grundstruktur för KDevelop innehållsförteckningsfiler
<!DOCTYPE kdeveloptoc>
|
<kdeveloptoc>
|
| (titel) |
| (basadress) |
| (innehållsstruktur) |
| (indexstruktur) |
</kdeveloptoc>
|
XML™-strukturen tolkas av KDevelops insticksprogram Dokumentation för att skapa dokumentationsträdets innehåll och hjälpa användaren att navigera i dokumentationen. Den innehåller all information som behövs för att visa titlar och komma åt dokumentationsfilernas innehåll.
<title> (någon titelsträng) </title> |
Det här är titeln som KDevelop visar på grundnivån i dokumentationsträdet.
Titeln som visas kan inte ändras av användaren. Om du vill att en annan text ska visas, måste du ändra posten <title> för hand i .toc-filen.
<base href=" (basdokumentets webbadress) "/> |
Webbadressen pekar på platsen där alla dokumentationens filer finns. Den läggs till i början av varje avsnittswebbadress i följande innehållsstrukturlista. Om du t.ex. laddar ner dokumentation från en fjärrserver, är allt du behöver göra för att visa filerna på den nya platsen att ändra webbadressen <base>.
<tocsect1 name=" (avsnittstitel) " url=" (avsnittswebbadress) "> |
| ... |
<tocsectn name=" (avsnittstitel) " url=" (avsnittswebbadress) "/> |
| ... |
</tocsect1>
|
All återstående navigerings- och åtkomstinformation lagras i en serie hierarkiska <tocsecti> ... </tocsecti> par. Varje i anger följande hierarkiska nivå ner till talet n som motsvarar dokumentationsavsnittet som visas sist.
Alla poster <tocsecti> måste ha motsvarande egenskap name="xxx" ("xxx" representerar den verkliga titelsträngen). Den visas som nivåns titel i dokumentationsträdet. Den ska motsvara ett verkligt avsnitt av dokumentationen.
Det kan finnas en egenskap url="" som hör ihop med vilken hierarkisk nivå i som helst. När användaren klickar på en avsnittstitel i dokumentationsträdet försöker KDevelop komma åt filen på platsen som pekas på den kombinerade bas- och avsnittswebbadressen.
Posten <tocsectn/> måste hur som helst ha egenskapen url="". Detta sista hierarkiska <tocsectn/> ingår inte i ett par, utan avslutas omedelbart av / innan tecknet >.
Vilken adress som helst som kombinerar bas- och avsnittswebbadress måste peka på en textfil som går att visa. Oftast är det en HTML strukturerad fil. Det är möjligt att länka till ankarmärken inne i en sådan HTML-fil genom att använda den vanliga #-beteckningen med formatet /baswebbadress/sektionswebbadress#ankarmärke.
<index>
|
<entry name=" (indexposttitel) " url=" (webbadress till indexavsnitt) "/> |
</index>
|
Index är en enkel lista med indexposter, par med titel och webbadress. Ett index krävs inte.
DevHelp-dokumentation är ett annat sätt att komma åt strukturerad dokumentation. Den använder en strukturerad innehållsförteckning som anges av filändelsen .devhelp på liknande sätt som KDevelop-innehållsfiler för att komma åt dokumentation för GNOME 2- skrivbordet.
Du kan styra vilka DevHelp-filer som ska vara tillgängliga på inställningssidan DevHelp-dokumentationssamling.
Tillhandahålla DevHelp-dokumentation
DevHelp-filer kunde ursprungligen kommas åt på webbplatsen LIDN, men det verkar som om den inte underhålls sedan en tid tillbaka. Senare DevHelp-dokumentation är tillgänglig på webbsidan DevHelp Books Download.
När KDevelop installeras, försöker det hitta alla .devhelp-filer på vissa standardplatser i systemet, t.ex. underkatalogerna i /opt/gnome/share/. Från början markeras inte filerna för visning. Om du vill se annan dokumentation, markera kryssrutan Innehållsförteckning i inställningstabellen.
Du kan lägga till nya poster med knapparna till höger om listan. KDevelop filtrerar *.toc-filer i katalogdialogrutan som hör ihop med knapparna och .
Det här är till för dina egna syften. Du kan lägga till nästan vilka dokumentationsfiler som helst här, under förutsättning att de kan visas av insticksprogram i Konqueror.
Tillhandahålla egen dokumentation
Oftast är den här samlingen tom när KDevelop först startas. Vi har avsiktligt fyllt i den med ett objekt för att visa poststrukturen.
Här är hanteringen är rättfram. Använd knapparna till höger om listan för att lägga till, redigera eller ta bort dokumentationsposter. KDevelop filtrerar inte någonting i katalogdialogrutan som hör ihop med knapparna och .
Du måste explicit välja posterna för att visa dem i KDevelops dokumentationsfunktion. Markera kryssrutan Innehållsförteckning för posten i inställningstabellen.
Egen dokumentation kan inte indexeras eller sökas. Därför har inte kryssrutorna Index och Sök någon effekt här, som visas ovan.
(... ännu inte skrivet ...)
Inställning av index för textsökning
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Arbete med att utveckla programvara i KDevelop organiseras i projekt. Ett sådant projekt håller samman allt som hör till en fullständig programmeringsuppgift: källkodsfiler, ytterligare datafiler, alla hanteringsfunktioner som behövs som byggsystemet samt åtkomst till alla komponenter och ytterligare verktyg som behövs för att få programmet klart att köras.
Att organisera utvecklingsarbetet i projekt låter dig enkelt byta mellan befintliga övergripande uppgifter. Det här riktigt bekvämt om du till exempel arbetar med flera program samtidigt, vilket ofta är fallet. Tala om för KDevelop att öppna projektet du vill arbeta med, och du kan fortsätta i miljön precis där du tidigare lämnade den.
Så fort du vill starta ett nytt programmeringsprojekt, behöver en hel del formella inställningsprocedurer göras. En startstruktur för kataloger måste skapas, nya deklarationsfiler och källkodsfiler måste skapas, byggsystemet måste initieras, etc.
KDevelop tillhandahåller ett enkelt sätt att starta ett nytt programmeringsprojekt: programguiden. Du hittar programguiden via menyalternativet ->.
Det behövs bara ett fåtal steg för att skapa ett nytt programmeringsprojekt med programguiden:
Välj programspråk du vill använda, och typ av program som du vill skapa från en uppsättning fördefinierade mallar.
Tillhandahåll en del allmän information som programnamn, katalog där programmet ska byggas, etc.
Bestäm om du vill använda ett versionskontrollsystem, som t.ex. CVS, och tillhandahåll nödvändig information som behövs.
Ställ in några mallar för ursprunglig deklarationsfil och källkodsfil (om nödvändigt).
Tala till sist om för programguiden att skapa alla nya saker, katalogstruktur, startmallar för deklarationsfiler och källkodsfiler, och hanteringsverktyg som ett startskelett för att bygga programmet, etc.
Voilà, det är allt. Programguiden har nu gett dig en första fungerade uppsättning programfiler, där du enkelt kan börja arbeta.
Låt oss nu ta en mer detaljerad titt på allt detta...
För att skapa ett nytt projekt i KDevelop, välj i menyn . Du ska då se guiden för att skapa nytt projekt, som visas nedan:
Inledande dialogruta för att skapa ett nytt projekt
Som du kan se, är dialogrutan uppdelad i en övre och undre del. I den övre delen kan du bestämma dig för programspråk och programtyp. Den under delen innehåller en del allmän information.
Du gör dina val på vänstersidan längst upp i dialogrutan. När den visas finns en lista med kataloger, var och en med namnet på ett programspråk, som till exempel:
För att precisera, innehåller katalogerna i själva verket inte riktiga programmeringsverktyg. De leder till fördefinierade mallar som du kan använda som utgångspunkt för utveckling i ett språk. För att få en idé om vad som erbjuds, öppna bara en katalog i taget. Det finns en följd underkataloger i vissa, men bara en eller flera enkla beteckningar i andra. Underkatalogerna du ser organiserar de tillgängliga mallarna enligt vissa uppgifter, de enkla beteckningarna namnger mallar som du kan välja.
Här kan vi inte i detalj gå in på vilka uppgifter varje mall tillhandahåller, men det är enkelt att ta reda på. Så fort du markerar en mallbeteckning, visas viss information i fälten till höger. I det nedre fältet ser du en kort beskrivning om vad mallen är avsedd att göra. I fältet ovanför visas en bild, om tillgänglig, med hur programmet som mallen producerar ser ut om du kompilerar och kör det utan ändring. Oftast är det en skärmbild av huvudfönstret som programmet visar.
Välj mallen som bäst passar målen för ditt program som startpunkt. Skriv därefter in information om allmänna egenskaper i de nedre fälten, som visas i nästa kapitel.
Välja ett projekthanteringssystem. Varje mall är kopplad till ett särskilt projekthanteringssystem. För närvarande finns det inget direkt sätt att helt fritt välja ett sådant projekthanteringssystem. Du måste hitta en mall som passar dina behov, eller ändra projektet på motsvarande sätt efter det har skapats.
Den undre delen av sidan Allmänt i dialogrutan Skapa nytt projekt är ett inramat fält som heter Egenskaper. Du måste tillhandahålla en del allmän information om projektet här, så att programguiden vet hur den ursprungliga strukturen ska byggas.
Programnamn. Ditt program behöver förstås ett namn. Skriv in det i det övre fältet under Egenskaper, som heter Programnamn. Vi använder Mitt_program som exempel.
När du gör det, märker du att programguiden vägrar att acceptera specialtecken av något slag. De enda tecken som accepteras är:
små och stora bokstäver
siffror
tecknet understreck
En framträdande orsak till begränsningen är att programguiden kommer att använda programnamnet som bas för vissa klassnamn som den skapar när den bygger upp projektet från början. Alltså måste projektets namn följa reglerna för programspråket som används.
Projektkatalogen. Den andra utmärkande orsaken för begränsningen ser du på nedersta raden i området Egenskaper. Den heter Slutgiltig plats, och visar katalogen där programguiden skapar programmet.
När du skriver in programmets namn märker du att programguiden repeterar det du skriver in längst ner på raden Slutgiltig plats, men bara med små bokstäver.
Alltså måste du välja namn på det nya programmet med försiktighet. Om du slutar med en katalog som redan används, låter inte programguiden dig fortsätta till nästa steg, genom att behålla knappen inaktiv (grå). Den varnar dig också genom att lägga till “(fil eller katalog finns redan)” sist på raden Slutgiltig plats.
Startsökväg. Det finns två sätt att välja en annan sökväg till det nya programmet. En är att använda ett annat namn. Det är dock inte alltid möjligt (t.ex. skapar du kanske en ny version av ett befintligt program). Som ett alternativ kan du välja en annan sökväg till programkatalogen.
Det görs i den andra radens inmatningsfält under Egenskaper, som heter Plats. Det du skriver in här är överliggande sökväg för det nya programmets utvecklingskatalog. Programguiden lägger till programnamnet sist i sökvägen när det nya projektet skapas. Resultatet visas på raden Slutgiltig plats för att bättre visa vad som händer.
Programguiden kopierar ett startvärde till fältet Plats från början. Det hämtas från det du har valt under fältet Standardprojektkatalog under den allmänna inställningen. I vårt fall har vi ställt in KDevelop att använda /home/utveckling/projekt/ som ursprunglig sökväg för nya projekt.
Ändra innehållet i fältet Plats, så att utvecklingskatalogen för programmet som visas på raden Slutgiltig plats är unik.
Försäkra dig om att sökvägen du skriver in i fältet Plats redan finns. Annars kommer du inte att kunna fortsätta till nästa steg. Programguiden varnar dig om sökvägar som inte finns, genom att lägga till “(ogiltig)” sist på raden Slutgiltig plats.
Ställa in ett nytt projekt för CVS
Personlig information. Fälten som följer är inte så kritiska. Ange bara ditt namn (dvs. namnet på personen som är ansvarig för programmet) i fältet Upphovsman, och en giltig e-postadress i fältet E-post, så att användare kan ge dig återmatning om programmet.
Programguiden fyller i fälten med vissa förvalda värden, som tas från e-postinställningarna i KDE:s inställningscentral. Om de förvalda värdena i fälten Upphovsman och E-post under Skapa nytt projekt inte passar, bör du kontrollera e-postinställningarna i KDE:s inställningscentral.
Programguiden sammanställer informationen till startprogrammallar om de finns. För KDE C++ program, hittar du den till exempel i början av källkodsfilen main.cpp.
Fältet E-post är det valfria bland fälten, vilket beror på att alla utvecklare kanske inte har tillgång till Internet. Du kan lämna fältet tomt om du vill, och ändå fortsätta.
Versions- och licensinformation. Skriv till sist in startversion för det nya programmet i fältet Version, och välj licensen du vill ska gälla för ditt program i kombinationsrutan Licens.
Om du väljer en programtyp där programguiden tillhandahåller gemensamma källkodstextmallar (t.ex. C/C++), bör du titta på licensinformationstexten på tredje sidan i dialogrutan Skapa nytt projekt (se kapitlet Ange mallar för deklarationer och källkod nedan).
Om du valde “Egen” i kombinationsrutan Licens måste du själv tillhandahålla en licenstext.
Både version och licensinformation kommer också att infogas i startmallarna på ett lämpligt format som tillhandahålls av programtypen du väljer.
När du har skrivit in all den här informationen på ett riktigt sätt, tryck på knappen för att fortsätta, som visas i följande kapitel.
I det andra steget, leder programguiden dig till sidan Versionskontrollsystem, där du kan bestämma vilket versionskontrollsystem du vill använda.
Den här beskrivningen koncentreras endast på behoven för att skapa projekt. För mer information om CVS, se kapitlet Använda CVS nedan.
Inget versionskontrollsystem önskas. Från början är “Inget” valt i kombinationsrutan Versionskontrollsystem, och sidan är för övrigt tom. Om du inte vill använda ett versionskontrollsystem, klicka bara på knappen för att fortsätta.
Använda CVS. Annars måste du välja versionskontrollsystemet som du vill använda i kombinationsrutan Versionskontrollsystem. Vi använder “CVS” i vårt exempel. Om du väljer det, visar programguiden sidan igen, men nu innehåller den ett antal fält som du måste fylla i.
Ställa in ett nytt projekt för CVS
Ett versionskontrollsystem som CVS (vilket betyder “Concurrent Versions System”) lagrar kopior av valda projektfiler i någon sorts databas. Om du använder CVS, kan du bland annat ladda upp (“arkivera”) filerna eller ladda ner dem till din projektkatalog (“checka ut”, eller “uppdatera”). Det särskilda med detta är att filerna i versionsdatabasen lagras på ett strukturerat sätt, vilket gör att du alltid kan återgå till ett tidigare utvecklingssteg om du behöver. CVS tillåter också flera utvecklare att ganska enkelt samarbeta i ett stort projekt (som KDevelop), utan att störa varandras arbete.
CVS-rot. CVS måste hantera versionsdatabasen som det har med dina projektfiler. För att åstadkomma det har det en del speciell databasinformation i en egen katalog, som kallas CVS-roten. Det första steget för att ställa in CVS för det nya projektet, är alltså att tala om för KDevelop var roten finns.
Lokal CVS-rot. Det finns två grundläggande möjligheter. Antingen vill du använda en lokal CVS-databas, eller använder du en databas som finns på en fjärrserver. Om du utvecklar på egen hand, kan du vilja använda CVS-databasen som ett sorts säkerhetskopieringssystem på din egen dator. Oftast skapas den i din hemkatalog och ges namnet cvsroot. Det kan se ut på följande sätt:
/home/utveckling/cvsrootdevel helt enkelt anger användaren “utveckling”, bara som ett exempel)
I själva verket är det här en förkortad form. Mer fullständigt ska den lokala CVS-roten adresseras med prefixet :local:. Den förkortade formen tillåts bara i fallen då filnamnet börjar med ett snedstreck (/). Det fullständiga namnet på vår lokala CVS-rot i exemplet skulle exakt se ut som: :local:/home/utveckling/cvsroot.
Skriv in namnet på CVS-rotkatalogen som systemet har ställts in för i fältet CVS-rot. I princip kan du välja vilket namn som helst, och till och med använda flera CVS-databaser, men det är lämpligt att behålla CVS-roten när den väl har ställts in.
Initiera en ny CVS-rot. Om det inte finns en CVS-root, ännu kan KDevelop ställa in CVS-systemet att skapa ett åt dig i den givna katalogen. Markera bara kryssrutan Initiera rot under fältet CVS-rot.
Som sagt, beordrar bara KDevelop CVS-systemet att initiera en ny CVS-rot. Det gör ingenting själv med katalogen. Som tur är, är CVS smart nog att kontrollera om CVS-rotkatalogen redan finns. Därför gör det ingen skada om du skulle ha markerat Initiera rot för en befintlig CVS-rotkatalog.
Fjärr CVS-rot. Det finns tillfällen då CVS-databasen ska finnas på en fjärrserver, särskilt när flera utvecklare arbetar med samma projekt. Då måste du skriva in CVS-rotens webbadress till servern i fältet CVS-rot. Om du till exempel vill komma åt KDE:s CVS-server:
:pserver:min_inloggning@cvs.kde.org:/home/kdemin_inloggning anger inloggningsnamnet som är inställt i ditt KDE CVS-konto)
Servertyper för fjärr-CVS. Det finns i huvudsak två fjärrservertyper för CVS med bred användning: pserver som använder ett lösenordssäkrat okrypterat protokoll, och ext-servern som använder krypterad dataöverföring via rsh eller ssh. De skiljs åt av webbadressprefixet de använder:
:pserver:
för den okrypterade typen “lösenordsskyddad server”, och
:ext:
för en servertyp krypterad med rsh eller ssh. Till exempel
:ext:min_inloggning@cvs.cervisia.sourceforge.net:/cvsroot/cervisia
kommer åt CVS-roten för det brett använda CVS-hanteringsverktyget Cervisia på servern SourceForge.
Om du vill använda en krypterad server via rsh eller ssh för att komma åt CVS, måste du tala om för KDevelop vilket krypteringsprotokoll som ska användas. Skriv bara in rsh eller ssh i fältet CVS_RSH på sidan Versionskontrollsystem i Skapa nytt projekt.
Det finns ett problem om du använder en krypterad server för CVS inne i KDevelop. Se kapitlet Använda CVS för detaljinformation.
CVS-arkivet. Hittills har du talat om för KDevelop var CVS-roten finns, som hanterar versionsdatabasen och hur den ska kommas åt. Nu måste du tala om för KDevelop vilket namn du vill att CVS ska använda för att spara dina projektfiler i databasen. Ett sådan ställe där projektfilerna lagras i CVS, kallas ett arkiv.
I princip kan du använda vilket namn som helst för projektfilernas CVS-arkiv, så länge det uppfyller specifikationerna för att namnge en fil. Oftast använder ändå de flesta utvecklare själva programmets namn. CVS bygger en katalog med namnet under CVS-roten, därför hittas det enklare om du behåller programnamnet för det.
Skriv bara in arkivnamnet som du vill använda i fältet CVS-arkiv på sidan Versionskontrollsystem under Skapa nytt projekt. I vårt exempel är det Mitt_program.
Försäkra dig om att inte använda ett arkiv som redan finns!. CVS-systemet varnar inte för duplicerade filer, utan skyfflar in allting som inte producerar en formell konflikt. Du ställer till allting!
Återstående fält. Det återstår inte mycket arbete. Programguiden har redan ställt in återstående fält åt dig. Mer detaljerat:
Fältet Leverantörstagg används endast av kompatibilitetsskäl. Du kan behålla standardvärdet “leverantör” som programguiden skrivit in här.
Fältet Meddelande gör det möjligt att skriva in en kommentar om innehållet i CVS från början. Använd vilken text du vill, eller behåll bara standardvärdet nytt projekt som programguiden skrivit in.
Utgåvetagg innehåller namnet som används som tagg för det ursprungliga tillståndet för projektet. En sådan tagg namnger ett visst tillstånd i CVS-arkivet, som du senare kan använda för att komma åt det tillståndet för utvecklingen. (Se vidare i kapitlet Använda CVS.)
Programguiden har skrivit in standardtaggen “start” här, som är ett värdigt förslag. Behåll det bara.
Om någon information om versionskontroll är fel, märker KDevelop det oftast inte förrän projektet skapas. Det är CVS-systemet som hittar felen när det försöker skapa arkivet. Därför måste du hålla ett öga på fönstret Meddelanden i KDevelop när projektet skapas under det sista inställningssteget. Om det var något fel med CVS, ser du oftast ett felmeddelande som det här:
* cd '/home/utveckling/test' && cvs -d '/home/utveckling/min_cvsrot' \
import -m 'nytt projekt' '' 'leverantör' 'start' &&\
sh /opt/kde3/share/apps/kdevcvs/buildcvs.sh . '' \
'/home/utveckling/min_cvsrot'
* cvs [import aborted]: /home/utveckling/min_cvsrot/CVSROOT: No such file or
directory
* *** Exited with status: 1 ***
Om det här händer, måste du antingen ställa in CVS för hand (KDevelop ska ha lyckats initiera dina projektfiler vid detta tillfälle) eller ta bort projektkatalogen och börja om igen med i menyn .
Efter du har skrivit in all informationrelaterad till CVS, klicka på knappen för att fortsätta.
Om du vill rätta ett fel på föregående sida i Skapa nytt projekt, tryck bara på knappen . Programguiden kommer ihåg dina inställningar på nuvarande sida, så du kan enkelt fortsätta när du kommer tillbaka.
Nästa steg tar dig till en serie sidor, där du kan ställa in vanlig information som du vill inkludera i dina källkods- och deklarationsfiler, om uppgiften i fråga tillåter.
Både deklarationsmallar och källkodsmallar tillhandahålls för C och C++ program, var och en på sin egen sida. För andra språk kanske det bara finns källkodsmallar. I vissa fall ser du till och med att mallsidan är tom.
Om sidan används, fyller programguiden i några vanliga kommentarer i sidhuvudet, som kan se ut så här för ett C++ baserat program:
/***************************************************************************
* Copyright (C) 2003 by Ditt namn *
* du@du.se *
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation; either version 2 of the License, or *
* (at your option) any later version. *
* *
* This program is distributed in the hope that it will be useful, *
* but WITHOUT ANY WARRANTY; without even the implied warranty of *
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
* GNU General Public License for more details. *
* *
* You should have received a copy of the GNU General Public License *
* along with this program; if not, write to the *
* Free Software Foundation, Inc., *
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *
***************************************************************************/
Andra mallar tillhandahåller liknande information på ett format enligt definitionen av programspråket du vill använda.
Som du kanske märkt, har programhanteringen redan fyllt i viss information som du angav på den fösta sidan Allmänt i dialogrutan Skapa nytt projekt, närmare bestämt innehållet i fälten Upphovsman och E-post. Riktig licensinformation har också infogats, enligt ditt val i kombinationsrutan Licens.
Mallarna som du ställer in i dialogrutan Skapa nytt projekt behandlas varje gång du talar om för KDevelop att skapa en ny källkodsfil och/eller deklarationsfil. Informationen som du anger här, inkluderas längst upp i ett dokumentationshuvud, innan koden börjar.
Du är dock inte begränsad till ren text. KDevelop känner till flera variabler, som låter dig inkludera riktig information i filen. Programguiden använda i själva verket just några sådana variabler för att inkludera information om Upphovsman, E-post och Licens i den ursprungliga malltexten.
Om du till exempel vill att dokumentationen av programvarugränssnittet som Doxygen skapar, ska visa ytterligare information om filens innehåll i listan med filnamn, kan du lägga till följande rader i källkodsfilens mall:
/**
* \file $MODULE$.cpp
* \brief (skriv en kort beskrivning här).
**/
Så fort du skapar en ny källkodsfil, ersätter KDevelop variabeln $MODULE$ med namnet på den nyskapade filen. Om du till exempel skapar en ny C++ klass som heter EnEnkelTest, ser du följande rader i filen enenkeltest.cpp:
/**
* \file enenkeltest.cpp
* \brief (skriv en kort beskrivning här).
**/
Du måste fortfarande tillhandahålla den korta beskrivningen efter nyckelordet “\brief”, men en del av jobbet har redan gjorts automatiskt åt dig.
Som ett annat exempel skulle du kunna inkludera en explicit referens till licenstexten som du vill använda i mallen. Använd variabeln $LICENSEFILE$ för detta, och lägg till exempel till följande rad:
// Se $LICENSEFILE$ för den fullständiga licenstexten.
Programguiden ersätter $LICENSEFILE$ med namnet på filen där den fullständiga licenstexten finns, nämligen:
// Se COPYING för den fullständiga licenstexten.
för GPL-licensen, eller
// Se LICENSE.BSD för den fullständiga licenstexten.
om du bestämmer dig för att använda BSD-licens för programmet.
Det finns förstås fler variabler som KDevelop känner till. Se avsnittet Redigera mallarna i kapitlet Redigeringsverktyg för att hitta vad som är möjligt.
Mallarna som du definierar här får ingen effekt förrän programguiden skapar det nya projektet. Du hittar informationen längst upp i filerna som du själv skapar under utvecklingsprocessen. När de ursprungliga filerna skapas, använder programguiden några fördefinierade standardmallar. Du måste anpassa de ursprungliga filerna till dina behov för hand.
Nu är nästan allt klart. På den sista sidan i mallen, har knappen ändrats så att den nu lyder .
Tänk efter innan du klickar på den! Du har fortfarande möjlighet att granska allting genom att använda knappen upprepade gånger. Eftersom programguiden kommer ihåg all information du hittills matat in, kan det vara lämpligt att ta dig tid att titta tillbaka en gång till. Om du använder lokal CVS, glöm inte att kontrollera namnet på CVS-arkivet igen (det ska inte redan finnas någon underkatalog med det namnet i CVS-rotkatalogen. Om det gör det, försök med ett annat arkivnamn).
Om du någon gång inte vill att det nya projektet ska byggas, avbryt dialogrutan Skapa nytt projekt med knappen . Klicka annars på , och se i fönstret Meddelanden hur programguiden skapar projektet.
Om du vill använda ett versionshanteringssystem (CVS), sker det i själva verket två genomgångar. Programguiden bygger först projektkatalogerna och anropar sedan CVS-programmet som återstartar fönstret Meddelanden med sitt eget innehåll. Om något fel uppstår i någon av genomgångarna, stannar processen och visar dig motsvarande felmeddelande i fönstret.
I många fall, när det nya projektet har skapats på det här sättet, laddar KDevelop automatiskt källkodsfilen eller filerna för en eller fler av de grundläggande viktiga modulerna, så att du kan enkelt börja arbeta. (Vilka källkodsmoduler som visas, om några alls, beror dock på mallen som från början valdes i programguiden.)
Glöm inte att kontrollera vad programguiden tillhandahåller från början. Du kanske till exempel vill ändra ursprunglig information i filhuvuden enligt dina egna mallar. Oftast hittar du dem i underkatalogen templates i projektkatalogen. Några enkla kopieringsåtgärder räcker oftast.
Därefter är det lämpligt att du kompilerar det ursprungliga projektet innan du försöker ändra någon kod. I de flesta fall ska den här första kompileringen vara möjlig. På så sätt kan du avgöra om projektet verkligen skapades enligt dina behov. Om det inte gjorde det, ta helt enkelt bort projektkatalogen (i den lokala CVS-roten också, om du använder en) och börja om.
Innan du kompilerar det nya projektet för första gången, ta en titt på ->. Om det finns tre alternativ som visas: , och , med markerat, behåll det för all del, eller använd istället.
På grund av vissa begränsningar i den nuvarande inställningen av autoconf och automake, ska du under inga omständigheter bygga med inställningen . Det förstör vissa interna kataloginställningar, och gör att configure klagar när du senare försöker använda det med bygginställningarna eller .
(Det här gäller bara för dessa flervalsmöjligheter. Om programtypen du valde bara tillhandahåller bygginställningen , ska du förstås använda den.)
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Funktioner (inledande översikt)
Delprogrammet för kodsnuttar lägger till en verktygsvy som normalt dockas till höger
Tillägg, redigering och borttagning av kodsnuttar är tillgängligt via en sammanhangsberoende meny.
Ett dubbelklick på en kodsnutt i listan infogar den i den aktiva vyn på markörens plats
Verktygstips visar innehållet i en kodsnutt
Kodsnuttar lagras i användarens hemkatalog, så varje användare kan ha sina egna kodsnuttar
Kodsnuttar kan innehålla variabler på formen $VARNAMN$. När kodsnutten används, frågas användaren efter ersättningsvärden för variablerna
I det följande listar vi normala tangentbindningar för standardeditorn. Du kan anpassa dem som du vill (hur då?).
Vänster | Flyttar ett tecken åt vänster |
Höger | Flyttar ett tecken åt höger |
Ctrl- Vänster | Flyttar ett ord åt vänster |
Ctrl- Höger | Flyttar ett ord åt höger |
Upp | Flyttar upp en rad |
Ner | Flyttar ner en rad |
Page Up | Flyttar upp en sida |
Page Down | Flyttar ner en sida |
Ctrl- Page Up | Går till början av filen |
Ctrl- Page Down | Går till slutet av filen |
Home | Går till början av raden |
End | Går till slutet av raden |
För alla tangenter ovan, kan dessutom skifttangenten tryckas ner, för att markera text från markörens nuvarande position till den nya.
Backsteg | Tar bort ett tecken åt vänster |
Delete | Tar bort tecknet under markören |
Ctrl- C | Kopierar den markerade texten till klippbordet |
Ctrl- V | Klistrar in den markerade texten från klippbordet |
Ctrl- X | Tar bort den markerade texten och lägger den på klippbordet |
Ctrl- Z | Ångra |
Skift-Ctrl- Z | Gör om |
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Den vanliga sökningen med -> kräver att du anger hela sökbegreppet innan du startar. Oftast är det mycket snabbare att söka inkrementellt. Om du klickar på sökfältet som heter I-sök i verktygsraden, sker sökningen medan du skriver. Du kommer att märka att det önskade resultatet ofta redan hittas när du har skrivit in 3 eller 4 tecken.
Båda sökmekanismerna som beskrivs ovan är begränsade till sökning i en källkodsfil. Ett ytterligare verktyg som låter dig söka igenom ett (möjligtvis stort) antal filer är tillgängligt via alternativet i menyn . Det är i grunden ett gränssnitt för programmet grep(1).
I dialogrutan kan du ange vilka filer som ska sökas i. Det finns ett antal jokertecken tillgängliga i en kombinationsruta. Genom att använda dem kan du enkelt begränsa sökmekanismen till exempel för deklarationsfiler. Dessutom kan du också ange en katalog där sökningen startas. Om du markerar rutan , går sökningen igenom alla kataloger i hierarkin under den angivna.
Sökbegreppet är i grunden ett reguljärt uttryck som följer POSIX-syntax. Du kan till exempel använda begreppet "\<K.*", om du vill hitta alla ord som börjar med bokstaven K. Följande tecken tolkas på ett särskilt sätt:
.
| Matchar alla tecken |
^
| Matchar början av en rad |
$
| Matchar slutet av en rad |
\<
| Matchar början av ett ord |
\>
| Matchar slutet av ett ord |
?
| Föregående objekt matchas mindre än en gång |
*
| Föregående objekt matchas noll eller flera gånger |
+
| Föregående objekt matchas en eller flera gånger |
{n}
| Föregående objekt matchas exakt n gånger |
{n,}
| Föregående objekt matchas n eller flera gånger |
{,n}
| Föregående objekt matchas mindre än n gånger |
{n,m}
| Föregående objekt matchas minst n gånger, men mindre än m gånger |
Bakåtreferenser till deluttryck inom parenteser är också tillgängliga med notationen \n.
Som en särskild bonus för C++ programmerare, finns några sökmallar tillgängliga för typiska mönster. De låter dig till exempel söka efter alla anrop av medlemsfunktioner för ett visst objekt.
När du väl har startat sökningen genom att klicka på knappen , utförs den av en yttre, asynkron process. Alla objekt som hittas syns i vyn som heter Flerfilsökning. Därefter kan du hoppa till objekt som hittas genom att klicka på dem. Observera att grep söker igenom filerna som är lagrade i filsystemet. Om du har ändrade versioner av dem i editorn, kan du få felaktiga radnummer, eller vissa ogiltiga hittade objekt. Du kan undvika detta genom att spara alla filer innan.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
På vänstra sidan i huvudfönstret, kan KDevelop visa olika sorters listor och träd för att välja filer:
Det visar en trädvy av filhierarkin under projektkatalogen. Om du klickar på en fil, laddas den i editorn. För filer som inte innehåller text, startar KDevelop ett program som kan hantera motsvarande MIME-typ.
Filträdet uppdateras regelbundet så fort någonting ändras i filsystemet. Om du till exempel skapar nya filer eller kataloger (till och med utanför KDevelop), syns det omedelbart i fillistan. På Linux använder den här funktionen FAM-biblioteket. På andra operativsystem, eller via NFS, kontrolleras katalogerna som visas med korta intervall.
Filträdet döljer filer som oftast inte är intressanta, som objektfiler. I under , kan du anpassa vilka mönster som används för att filtrera bort ointressanta filer (som en lista med jokertecken, åtskilda med kommatecken).
Du kan dessutom välja att begränsa filträdet så att det bara visar filer som hör till projektet som för närvarande är laddat. Det kan ändras genom att klicka med höger musknapp på trädets rot.
Det här visar filerna som tillhör projektet, grupperade enligt filändelsen. Som i filträdet, kan du redigera en fil genom att klicka på den med vänster musknapp.
Grupperna som visas i vyn kan ställas in under i dialogrutan . För att anpassa vyn enligt dina behov, är det viktigt att förstå hur filer tilldelas till grupperna. För varje fil, går KDevelop igenom grupperna uppifrån och ner. I varje grupp kontrolleras om filnamnet matchar ett av mönstren. Vid en träff, visas filen i gruppen och upprepningen avbryts. Detta klargör att mer generella mönster ska placeras under mer specifika. Till exempel ska en asterisk för gruppen Övriga vara det sista mönstret.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Vid arbete med ett projekt i ett objektorienterat språk, läggs inte tonvikten på källkodsfilerna och deras namn, utan på klasserna och deras samband. För att hjälpa dig navigera bland definierade klasser och symboler, innehåller KDevelop diverse klassbläddrare som synliggör klasstrukturen på olika sätt.
Den här vyn visas till vänster i huvudfönstret och innehåller en linjär lista av alla klasser, variabler och funktioner i projektet. Den är konstruerad som en trädvy. Om du öppnar en klassnod genom att klicka på den, visas en lista med alla metoder och egenskaper som respektive klass har.
Klassvyn arbetar i två olika lägen. Normalt grupperas alla symboler i “Klasser”, “Struct:ar”, “Funktioner”, “Variabler” och “Namnrymder”. I den sammanhangsberoende menyn, kan du välja . Med detta läge, visas namnrymdshierarkin, och symboler grupperas i respektive namnrymd där de definieras. Det här kan vara mer användbart i projekt som använder många (hierarkiska) namnrymder. Det är mindre användbart i projekt utan namnrymder.
Du kan också ändra sättet som klassnamn visas. Normalt visas klassernas namn, utan namnrymden där de definieras. Det betyder att du inte omedelbart kan skilja på klasser med samma namn i olika namnrymder. Om du håller musen still ett ögonblick över ett namn, visas dock det fullständiga namnet som ett verktygstips. Du kan välja att alltid visa det fullständiga klassnamnet genom att välja i den sammanhangsberoende menyn.
Genom att klicka på en klass eller metod i en klassvy kommer du till dess definition. Du kan också hoppa till en metods deklaration genom att välja i den sammanhangsberoende menyn. I den sammanhangsberoende menyn för klasser finns också alternativen och De öppnar dialogrutor där du kan skapa nya metoder och variabeldeklarationer för den relevanta klassen, tillsammans med en tom implementering.
Klassverktygsdialogrutan aktiveras genom att högerklicka på en klass i klassvyn och välja .
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Dokumentation är tyvärr en av de mest förbisedda delarna av programmering. Ändå så erbjuder riktigt upprättad och underhållen intern och extern dokumentation ytterst värdefull hjälp.
Dokumentation har flera aspekter. Det finns
intern projektdokumentation, som i huvudsak består av
kommentarer i deklarationsfiler och källkodsfiler
Intern dokumentation av programmeringsgränssnittet för projektet, som har skapats från programfilerna av särskilda verktyg, t.ex. Doxygen
extern projektdokumentation, som bland annat består av
extern dokumentation av programmeringsgränssnitt, till exempel för gemensamma systembibliotek (KDE, Qt™, etc.)
all övrig dokumentation (manualer för programspråk, allmän systeminformation, handledningar och liknande)
All denna dokumentation ska vara enkel att underhålla och lätt tillgänglig så fort du behöver den. KDevelop har stöd för just detta.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Det här kapitlet behandlar bara kompilerade projekt, som projekt med C++, Java™ eller Fortran. Projekt för skriptspråk som Python och PHP, fungerar mycket annorlunda.
Här hittar du information om följande ämnen:
Sammanfattning av Hantering av automake innehåller en översikt över Hantering av automake,
Användning av Hantering av automake beskriver grunderna i hur man arbetar med Hantering av automake.
I kapitlet Byggsystem har vi gett en grov översikt av de byggsystem som vanligen används på Unix-system. I följande avsnitt tittar vi på detta i mer detalj.
Det finns en viss förvirring angående hur sådana ting ska namnges. GNU kallar dem “byggsystem” när Automake, Autoconf och Libtool beskrivs. Qmake kallas “ett verktyg att skriva Makefiles för olika kompilatorer och plattformar”. I KDE används ofta uttrycket “projekthanteringssystem”. Vi använder det uttrycket i en vidare bemärkelse för att beskriva de inbyggda miljöer i KDevelop som används för att organisera och bygga projekt. I det här avsnittets sammanhang, talar vi dock i huvudsak om “automatiserade byggsystem”.
Om du har ett enkelt program som skriver ut “Hej allihop”, skrivet i C, kan du kompilera och länka det med gcc -o hej hej.c och köra det med ./hej, så du behöver inte ens en Makefile.
Om du har ett C-program med flera moduler och deklarationsfiler och du bara ska köra det på din dator (dvs. det är ett lokalt program), behöver du bara en vanlig Makefile, som är ganska enkel att skriva för hand (använd info make för att lära dig mer).
Komplikationerna börjar när:
Din källkod, dokumentation, grafik, ljud, översättningar, datafiler etc. finns i mer än en katalog,
Du har en hierarki av kataloger och underkataloger,
Du använder bibliotek som inte är en del av den traditionella uppsättningen på UNIX®, som Qt™-objektbiblioteket eller KDE-skrivbordsbibliotek,
Du använder en preprocessor för att skapa en del av din källkod, som Qt:s MOC prekompilator,
Du siktar på att distribuera programmet i hela världen, till personer som inte har samma UNIX®- eller Linux®-system, programvara och hårdvara som du,
Du kräver en automatisk funktion för installation och avinstallation,
Du siktar på att göra ditt program en del av KDE:s uppsättning med skrivbordsprogram.
Om du befinner dig i några eller alla av ovanstående situationer, behöver du troligen ett byggsystem. I exemplet ovan använde vi gcc för att kompilera och bygga programmet “Hej”, men alla C-kompilatorer heter inte “gcc”. Så om du distribuerar programmet till någon som använder en annan C-kompilator, måste din Makefile på något sätt använda namnet på den personens kompilator, annars misslyckas kompileringen av programmet. Detta är bara ett av många exempel på vad som kan gå fel.
Ett byggsystem jämnar ut skillnaderna åt dig.
Det kontrollerar att biblioteken som behövs finns på varje dator som tar emot programmet,
avsöker automatiskt alla programkataloger efter filer att förbehandla, kompilera eller installera och
installerar komponenterna som programmet består av i rätt kataloger, och försäkrar att
katalogerna på datorn som tar emot programmet skapas efter behov.
I korthet erbjuder ett byggsystem säkra metoder för att kompilera och installera programmet på alla datorer som tar emot programmet. Som vi har visat tidigare i översikten Projekthanteringssystem, erbjuder KDevelop tre automatiserade byggsystem och möjlighet att skapa din egen Makefile. I korthet (klicka på projektnamnen för mer information):
Automake-projekt som använder de vanliga utvecklingsverktygen för GNU.
Qmake-projekt som använder Trolltechs Qmake-projekthantering.
ANT-projekt som använder Apaches ANT-projekthantering för Java™-utveckling.
Eget projekt som kräver att du underhåller din egen Makefile.
Ett av de fyra alternativen måste väljas när du skapar ett projekt, och valet är svårt att senare ändra, så du bör tänka efter innan du börjar.
Det finns flera handledningar tillgängliga om GNU:s byggsystem (Autoconf, Automake och Libtool) som Hantering av automake använder sig av.
En kort handledning om autoconf, skriven av Christopher W. Curtis finns tillgänglig på KDevelops hemsida. Den koncentrerar sig på några grundläggande steg för att ändra en Makefile.
En mer detaljerad handledning finns som en del av en större uppsättning handledningar under “Utveckla programvara med GNU”.
Den berömda “getboken”, som heter “Autoconf, Automake, and Libtool”, finns också. Den är en lättläst, men ändå kortfattad, introduktion till alla viktiga aspekter av GNU:s autoverktyg.
Programguiden har skapat några ursprungliga Makefile.am filer när du skapade ett nytt projekt av en typ som använder GNU:s byggsystem, som ->->. Under utvecklingen skapar Hantering av automake alla ytterligare Makefile.am filer för projekt som använder GNU:s byggsystem, och underhåller alla, både de som skapats med programguiden och Hantering av automake.
Det finns en Makefile.am i varje projektkatalog som innehåller filer som ska kompileras eller installeras. Den innehåller dina specifikationer för att kompilera, bygga och installera filer och en referens till alla underkataloger som också har en Makefile.am och möjligen några filer att kompilera, bygga och installera.
Projektets kataloger och källkodsfiler kan struktureras till vilket djup som helst, eller du kanske föredrar en platt projektstruktur med alla underkataloger på toppnivå.
Målet med GNU:s byggsystem är att skapa filstrukturer för källkod som kan kompileras, byggas och installeras på vilket UNIX®- eller Linux®-system som helst med de enkla kommandona:
./configure make make install # Oftast som systemadministratör.
och kan avinstalleras med kommandot make uninstall (oftast som systemadministratör).
Hur fungerar det? Ja, configure är ett skript som:
arbetar fram detaljinformation om systemet som det körs på, som vilken kompilator och vilka bibliotek som ska användas, var de finns, och därefter
rekursivt skapar filerna Makefile genom att fylla i det som ska ersättas i motsvarande Makefile.in.
Filen Makefile.am är “indata”, en mall som ger grundläggande information för den Makefile som ska skapas, genom att fylla i viss systemberoende information. Den skapas av verktyget Automake från filen Makefile.am.
Processen att komma från en Makefile.am (där .am anger mallfiler för “Automake”) till Makefile hanteras automatiskt av KDevelops Hantering av automake med verktyget Autoconf, M4-makron och andra mysterier vi inte behöver gå in på här.
Så när make kör, hämtar det automatiskt rätt information från den nuvarande miljön, som kompilatorer och bibliotek. På samma sätt, placerar make install delarna av programmet, som körbara filer, dokumentation och datafiler på rätt plats i den miljön.
Om du distribuerar programmet som ett “tar-arkiv” (en enda komprimerad fil som KDevelop kan skapa åt dig), innehåller den filerna Makefile.in och skriptfilen configure, så att mottagaren kan kompilera, bygga och installera programmet utan att ha Automake, Autoconf eller KDevelop på sin dator. Filerna Makefile.am ingår också, ifall mottagaren måste göra några ändringar i källkoden.
Reglerna är väsentligt annorlunda om du distribuerar via ett webbaserat källkodsarkiv som KDE:s CVS.
Skapar filerna Makefile.am i underkatalogerna som det känner till som “delprojekt”.
Uppdaterar filerna Makefile.am när projektstrukturen ändras.
Uppdaterar filerna Makefile.am när filer läggs till i eller tas bort från projekt.
Accepterar definitioner om hur de olika filerna ska byggas eller installeras, och ändrar Makefile.am enligt dem.
Accepterar parametrar som används vid byggning eller installation (t.ex. biblioteksnamn), och försäkrar att de används i de nödvändiga kompilerings- och byggstegen.
Filen Makefile.am har rader som innehåller variabelnamn följda av ett likhetstecken och en lista med filer eller parametervärden. “Variabler” har tvådelade namn, som bin_PROGRAMS, mittpgm_SOURCES eller kdelnk_DATA. Den andra delen kallas den primära och representerar något som ska byggas eller installeras. Den första delen kallas prefix och representerar:
En katalog där installationen ska göras (t.ex. bin),
En kvalifikation för den primära delen (t.ex. mittpgm för SOURCES, som anger att källkodsfiler som listas efter mittpgm_SOURCES ingår i att bygga mittpgm.
Ett särskilt prefix noinst (kort för “ingen installation”), som oftast används för att lista programmets deklarationsfiler (.h),
Eller det speciella prefixet EXTRA, för konfigurationsberoende saker.
För mer information om Automake och filerna Makefile.am, slå upp den med info Automake.
I huvudsak skapar och uppdaterar Hantering av automake variabelnamn och fillistor eller parametrar. Se följande exempel på en Makefile.am för ett typiskt program, som kallas mittpgm.
## Makefile.am för mittpgm # det här är programmet som installeras. dess namn används för alla # andra Makefile.am variablerna bin_PROGRAMS = mittpgm # ställ in sökvägen för deklarationsfiler till X, Qt och KDE INCLUDES = $(all_includes) # bibliotekssökvägen. mittpgm_LDFLAGS = $(KDE_RPATH) $(all_libraries) # biblioteken att länka med. mittpgm_LDADD = $(LIB_KFILE) $(LIB_KDEPRINT) # vilka källkodsfiler ska kompileras för mittpgm mittpgm_SOURCES = main.cpp mittpgm.cpp mittpgmvy.cpp # det här är deklarationsfilerna för projektet noinst_HEADERS = mittpgm.h mittpgmvy.h # låt automoc hantera alla metakällfiler (moc) METASOURCES = AUTO KDE_ICON = mittpgm # det är här kdelnk-filen hamnar kdelnkdir = $(kde_appsdir)/Utilities kdelnk_DATA = mittpgm.desktop # det är här XML-GUI resursfilen hamnar rcdir = $(kde_datadir)/mittpgm rc_DATA = mittpgm_ui.rc AM_CXXFLAGS = -DMITT_C++_PREPROCESSOR_ALTERNATIV
Som du kan se är många av objekten på högersidan symboler på formen $(xxxx). De är miljövariabler som definieras i själva KDE-miljön och ersätts med riktiga värden när ./configure skapar de slutliga filerna Makefile på datorn som tar emot programmet.
Det är också en god idé att köra kommandot ./configure --help någon gång efter du har börjat med KDevelop, som visar dig de olika saker du kan ändra vid bygg- och installationstid, såsom en testmiljö. I synnerhet kommandot:
./configure --prefix=/var/du/villflyttar hela installationen till en katalogstruktur som du väljer, genom att ändra den interna variabeln
$(prefix) till värdet /var/du/vill. I det här kapitlet hittar du en grundläggande beskrivning av elementen i Hantering av automake, och hur de används. Det täcker:
Fönstret Hantering av automake beskriver den grundläggande strukturen hos huvudfönstret i Hantering av automake.
Översiktsfönstret beskriver elementen i det övre delfönstret.
Detaljfönstret beskriver elementen i det undre delfönstret.
Navigera i Hantering av automake listar några grundläggande åtgärder du kan utföra i Hantering av automake.
Sammanhangsberoende menyer i Hantering av automake beskriver menyerna som dyker upp när du väljer en åtgärd i Hantering av automake.
 |
|
Översiktsfönstret innehåller en trädlista med alla kataloger i projektet som innehåller programfiler, dokumentation eller data. Varje sådan katalog innehåller en fil Makefile.am och är känd som ett delprojekt i Hantering av automake. Det finns tre typiska delprojekt i ett KDE-baserat projekt, som visas på bilden ovan:
src: källkodsfiler för programmet,
doc: användarmanualen eller handboken,
po: utdrag av strängar i dina källkodsfiler som kräver översättning till andra mänskliga språk (t.ex. fönsterrubriker, menynamn, namn på knappar, text i dialogrutor och meddelanden av olika slag).
Observera att delprojektet doc alltid har ett delprojekt som heter en, som du kan se om du klickar på symbolen + intill ordet doc. Det beror på att grundspråket för all dokumentation i KDE är engelska (en). Om programmet blir en del av KDE, kan KDE:s översättningsgrupper översätta din dokumentation från engelska till andra språk, och översättningarna hamnar då i andra delprojekt, som sv (svenska), de (tyska) eller fr (franska). Strängarna i delprojektet po kan också översättas och lagras i andra filer under po, för att på så sätt låta programmet hanteras av personer som inte kan engelska.
Delprojekten doc och po tjänar olika syften. doc innehåller dokumentation, som en användarhandbok, medan po innehåller textsträngar som kan översättas från användargränssnittet som ingår i programmets källkod.
Översiktsfönstret fungerar bland annat som ett navigeringsverktyg. Om du väljer ett delprojekt i översiktsfönstret, visas motsvarande detaljinformation i detaljfönstret.
Detaljfönstret innehåller en lista med alla filer i delprojektet som för närvarande är markerat i översiktsfönstret, samt kompilerings-, bygg- och installationsreglerna för delprojektet. På så sätt kan fönstren tillsammans ge dig möjlighet att komma åt alla komponenter i programmet, och all information om hur det ska kompileras, byggas och installeras.
Trädlistan i detaljfönstret har två nivåer. Den översta nivån består av så kallade mål i Hantering av automake, och nästa nivå innehåller listor med filer som används för att skapa varje mål.
Det här konceptet med ett mål i Hantering av automake, skiljer sig något från vad ett mål i en Makefile oftast är. I korthet:
Definitionen av hur ett antal filer ska kompileras, byggas eller installeras är känt som ett mål i Hantering av automake, men som en variabel i själva Automake.
Ett mål i make är ofta något helt annat, eftersom det kan vara en väljare till kommandot make (t.ex. make install, make clean).
Vissa av variablerna i Makefile.am representerar dock ett underliggande delmål för make.
Både i översiktsfönstret och detaljfönstret kan du vänsterklicka på + eller - intill ett delprojekt eller målnamn för att expandera eller dra ihop trädvyn. Om du gör det med ett delprojekt i översiktsfönstret, visas eller döljs delprojektets nästa underliggande nivå (om det finns någon). Om du gör det med ett mål i detaljfönstret, visas eller döljs listan med filer som ingår i målet.
Om du vänsterklickar på ett filnamn i detaljfönstret, öppnas motsvarande fil i KDevelops redigeringsfönster.
Om du vänsterklickar på ett delprojektnamn i översiktsfönstret eller ett mål i detaljfönstret, markeras namnet och vissa knappar i verktygsraden blir aktiva längst upp i fönstret.
Du rekommenderas använda höger musknapp och sammanhangsberoende menyer, istället för knapparna i verktygsraden, eftersom det är då mycket enklare att se och förstå vad du gör.
Åtgärder för delprojekt och mål har långtgående effekter för struktur, kompilering, byggning och installation av programmet.
Om du högerklickar på ett delprojektnamn, mål eller fil, dyker en meny upp och du kan därefter välja åtgärder att utföra för delprojektet, målet eller filen, som att lägga till ett mål i delprojektet, lägga till en fil i målet eller logiskt ta bort den markerade filen från sitt mål.
Följande avsnitt förklarar kortfattat vilka åtgärder som menyerna gör tillgängliga, som dyker upp vid klick med höger musknapp i fönstret Hantering av automake. Avsnitten är bara avsedda som en översikt. Du hittar detaljerade beskrivningar av de flesta åtgärderna i ett senare kapitel.
När du högerklickar på ett filnamn i detaljfönstret, dyker följande meny upp som låter dig välja en av flera åtgärder att utföra med filen. I bilden nedan, markerades ikonfilen hi-16app-mittpgm.png i målet Ikondata i kde_icon från delprojektet mittpgm/src.
 |
|
När du högerklickar på ett mål i detaljfönstret, dyker följande meny upp som låter dig välja en av flera åtgärder att utföra med det. I bilden nedan, markerades målet mittpgm (Program i bin) i delprojektet mittpgm/src.
 |
|
När du högerklickar på ett delprojekt i översiktsfönstret, dyker följande meny upp som låter dig göra större ändringar i projektets struktur och sättet det kompileras, byggs och installeras. Du kan använda den för att utöka eller ändra den grundläggande projektstrukturen som programguiden har skapat.
 |
|
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
(... ännu inte skrivet ...)
Makefile.in till Makefile
prefix = @prefix@ INSTALL = @INSTALL@ build_triplet = @build@ CXX = @CXX@
prefix = /home/bernd/kde3 INSTALL = /usr/bin/ginstall -c -p build_triplet = i686-pc-linux-gnu CXX = g++
config.h.in till config.h
/* Define if you have libz */ #undef HAVE_LIBZ /* The size of a `int', as computed by sizeof. */ #undef SIZEOF_INT
/* Define if you have libz */ #define HAVE_LIBZ 1 /* The size of a `int', as computed by sizeof. */ #define SIZEOF_INT 4
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Om du har lämpliga korskompilatorer tillgängliga, kan du kompilera dina program för processorer och operativsystem som skiljer sig från systemet där KDevelop och kompilatorn kör. GNU-kompilatorn, gcc, kan konfigureras och kompileras som en korskompilator om du kompilerar den själv. Rådfråga GCC infosidorna för mer information. Vissa Linux-distributioner tillhandahåller också binärpaket.
Ett automake-baserat paket kan lätt korskompileras genom att ange väljaren --host till configure-skriptet och ställa in miljövariablerna CC och CXX till motsvarande korskompilatorer. Ofta vill du byta mellan en korskompilerad version av programmet, och en som kompilerats för utvecklingssystemet. För att göra det, är det en fördel att använda möjligheten i KDevelop att skapa flera byggkonfigurationer, som förklaras under “Flera bygginställningar”. När du har skapat en ny byggkonfiguration för korskompilering i dialogrutan ->, lägg till väljaren
--host=plattform
till configure-väljarna. Värdet plattform är en kombination av formen
cpu-tillverkare-operativsystem
eller
cpu-tillverkare-kärna-operativsystem
För många kombinationer kan du använda en kortform, till exempel i386-linux eller arm-elf.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Qt/embedded är en version av Qt™-biblioteket som inte använder X-window systemet, utan ritar direkt i rambuffern på Linuxsystem. Den är därför intressant för inbäddade system som har hårda begränsningar för minnesanvändningen i hela systemet. Dess programmeringsgränssnitt överensstämmer fullständigt med X11-versionen.
Att utveckla ett program för Qt/embedded med KDevelop skiljer sig inte mycket från att utveckla ett program för X11-versionen av Qt™. I själva verket kan du använda samma grundkod för båda versionerna. Om du använder projekthantering med autoprojekt, kan du byta till den inbäddade versionen genom att skicka väljaren --enable-embedded till configure-skriptet. Du kan ställa in det i dialogrutan -> under Inställning av configure. Med väljaren --with-qt-dir=KATALOG, kan du ställa in katalogen där Qt/embedded är installerad.
Efter att ha konfigurerat och kompilerat programmet med dessa väljare, länkas det med biblioteket libqpe.so. Den här versionen av programmet kör inte normalt när du använder X11. För att prova den, kör den med hjälp av programmet qvfb (Qt:s virtuella rambuffer). Det görs genom att starta qvfb och därefter starta programmet med
program -qws -display QVFb:0
När du har en version av programmet som fungerar, vill du naturligtvis använda den på målprocessorn. Det kan troligen vara bekvämt att kunna skapa flera byggkonfigurationer, som förklaras ovan, så att du snabbt kan byta mellan versionen som kör på utvecklingssystemet och versionen som kör på målsystemet.
Program för Qt/embedded kör normalt som enkla program på enheten de är konstruerade för. Trolltech stöder också Qtopia, som är en samling program för personlig information, webbläsning och diverse andra områden som fungerar tillsammans på ett konsekvent sätt. Det är till exempel standardomgivningen på Sharp Zaurus. Du kan skriva program som passar in i denna omgivning genom att använda Qtopias utvecklingsmiljö (SDK). Det medför att ditt program måste vara en delklass till QPEApplication och det måste länkas med biblioteket libqpe.so. Om du utvecklar programmet med projekthanteringen autoprojekt, måste du lägga till --enable-qtopia till konfigurationsväljarna.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
KDevelop innehåller en intern avlusare för C och C++, som är direkt integrerad med editorn. Tekniskt sett är den implementerad som ett gränssnitt som använder den flyttbara GNU-avlusaren gdb via en rörledning. Avlusaren kan startas på flera sätt:
Huvudprogrammet i projektet laddas i avlusaren med ->.
Genom att använda ->->, laddar du en minnesdump till minnet, som skapats av operativsystemets kärna när programmet kraschade. (Att skapa minnesdumpar kan vara avstängt på systemet, se ulimit(1)). Det här är användbart för en post-mortem analys av ett program.
Du startar avlusaren för ett program som redan kör med ->->. En processlista visas där du kan välja processen som avlusaren ska överta.
Observera att avlusning bara är möjlig om projektet har kompilerats med avlusningsinformation aktiverad. Den kan aktiveras i dialogrutan . När alternativet är aktiverat, skapar kompilatorn ytterligare information som låter avlusaren associera filnamn och radnummer med adresser i det körbara programmet.
Gränssnittet till avlusaren erbjuder flera vyer “in i” processen:
Om du försöker avlusa ett projekt utan avlusningsinformation, får du meddelandet Ingen källkod... i statusraden. Om du försöker sätta brytpunkter, visas de som Vilande (lägg till) i brytpunktsfönstret (se nedan).
Det här fönstret visar värden för alla lokala variabler vid det nuvarande stället i programmet. Det täcker variablerna i kompilatorns anropsstack, dvs. funktionen där processen bröts, funktionen som anropade den här funktionen, och så vidare hela vägen till funktionen main().
En annan gren i variabelfönstret innehåller bevakningsvariabler. Du kan själv ställa in vilka variabler som syns här. Både lokala och globala variabler kan bevakas. Du kan antingen lägga till en variabel genom att klicka på knappen eller trycka på returtangenten när posten Bevaka är markerad. Variablerna kan tas bort igen med den sammanhangsberoende menyn.
(...ännu inte skrivet...)
Fönstret låter dig se och behandla brytpunkterna. Kom ihåg att KDevelop använder GDB, så för att förstå KDevelops avlusningsfunktioner fullständigt, måste du veta lite grand om GDB.
Om du vill titta på källkoden, definieras brytpunkter i kdevelop/languages/cpp/debugger/breakpoint.h.
I vänsterkanten har fönstret knappar för att:
Lägga till en tom brytpunkt
Redigera den markerade brytpunkten
Ta bort den markerade brytpunkten
Ta bort alla brytpunkter
Huvuddelen av fönstret är en tabell med sju kolumner. Varje rad i tabellen är en brytpunkt. Kolumnerna är:
Markeringskryssruta
Typ: en av: Ogiltig, Fil:Rad, Bevakningspunkt, Adress, Funktion
Status. Värdena är:
Aktiv
Inaktiverad: Varje brytpunkt kan “aktiveras” eller “inaktiveras”. Om den är inaktiverad har den ingen effekt på programmet till den aktiveras igen.
Vilande (lägg till): En brytpunkt är markerad så här om ingen avlusningsinformation är tillgänglig. Från GDB:s informationssida:
Om en specificerad brytpunktsplats inte kan hittas, kan det bero på det faktum att platsen är i ett delat bibliotek som ännu inte har laddats. I ett sådant fall, kan du vilja att GDB skapar en speciell brytpunkt (känd som en “vilande brytpunkt”) som försöker lösa upp sig själv i framtiden när ett lämpligt delat bibliotek laddas.
Vilande (rensa)
Vilande (ändra)
Plats på formatet filnamn:radnummer
Villkor
Ignorera antal: Om det är ett tal ANTAL större än noll, stoppas inte programmets körning följande ANTAL gånger som brytpunkten nås, förutom att minska antalet att ignorera, utför gdb ingen åtgärd.
Träffar: Räknar hur många gånger en brytpunkt har träffats.
(...ännu inte skrivet...)
Funktionsnamn i det körbara programmet är “behandlade” för C++, dvs. funktionsnamnet innehåller information om argumentens typer. Detta är nödvändigt för att stödja överlastade funktioner. Behandlingsalgoritmen är inte standardiserad, och skiljer sig till och med mellan olika versioner av GNU:s C++ kompilator.
I assemblerkodfönstret visas normalt obehandlade namn, så funktionssignaturer liknar utseendet i källkoden, och är lätt läsbara. Alternativt, kan du välja att se behandlade namn.
Avlusarens bakgrundsprogram gdb tillåter inte att brytpunkter sätts i kod som inte för närvarande är laddad. I ett riktigt modulärt program, där kod ofta bara laddas vid behov som insticksprogram (med användning av C-bibliotekets funktion dlopen(3)), kan detta vara besvärande. Därför hanterar KDevelop själv stöd för brytpunkter i delade bibliotek. Om du aktiverar det här alternativet, kan du sätta brytpunkter i bibliotek som inte laddats. Därefter, så fort gdb talar om att ett bibliotek har laddats, försöker KDevelop sätta de vilande brytpunkterna.
(...ännu inte skrivet...)
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
CVS är versionshanteringssystemet som många projekt med öppen källkod, inklusive KDE, använder. Det lagrar all källkod på en centralt plats, som kallas arkivet. Utvecklare hämtar en aktuell version av projektet eller versioner av det vid godtyckliga tidpunkter, från arkivet. I motsats till vissa andra versionshanteringssystem, är det inte nödvändigt att låsa filer som man ska arbeta med. Alltså kan utveckling ske parallellt i stor utsträckning.
Så fort en utvecklare är klar med en uppgift, arkiverar han sin kod (tillsammans med ett loggmeddelande). CVS tar hand om arbetet att sammanfoga ändringar som görs av flera utvecklare. Det kan förstås hända att utvecklare arbetar med samma kodavsnitt, vilket ger upphov till ändringar med konflikter (i praktiken inträffar detta sällan, och är ofta ett tecken på bristande kommunikation). I detta fall, förkastar CVS arkiveringen. En fil kan bara arkiveras efter alla konflikter har lösts upp.
Hittills har de grundläggande funktionerna i CVS, som man oftast måste hantera, beskrivits. Men CVS erbjuder mycket mer: Man kan hantera flera grenar av ett projekt (t.ex. var KDE 1.1.2 och KDE 2 grenar i KDE:s utvecklingsträd), sammanfoga ändringar från en gren till en annan, fråga efter skillnader mellan versioner och filers versionshistorik, etc.
CVS implementeras som ett klient-serversystem. Som användare, sker all kommunikation med arkivet via kommandoradsprogrammet CVS. Gränssnitt på högre nivå är tillgängligt via program som Cervisia ( ) eller TkCVS (http://tkcvs.sf.net). Bara en liten del av CVS funktioner, som är viktiga under det dagliga arbetet, kan användas direkt i KDevelop.
Grundläggande kunskap om användning av CVS förutsätts. I synnerhet bör du veta hur ett givet projekt hämtas från arkivet. Vi rekommenderar boken Open Source Development With CVS av Karl Fogel, som kan spridas fritt (utom de icke-tekniska kapitlen). Se http://cvsbook.red-bean.com/cvsbook.html.
Följande alternativ är tillgängliga i filvyernas sammanhangsberoende menyer:
Förbereder en fil för att läggas till i arkivet. Filen överförs till arkivet när du arkiverar den (eller katalogen som den finns i) nästa gång.
Förbereder en fil för att tas bort från arkivet. Det här tar också bort filen från det lokala filsystemet, så använd funktionen med försiktighet!
Kör kommandot cvs update för att sammanfoga eventuella ändringar från andra användare till din arbetskatalog. När du använder menyalternativet för en katalog, sker uppdateringen normalt rekursivt, utom om du har stängt av det i inställningsfilen .cvsrc.
Kör cvs commit för att arkivera alla lokala ändringar i arkivet. Observera att du bör uppdatera innan du gör detta. Om en annan användare tidigare har arkiverat sina ändringar, kan CVS annars ge ett felmeddelande.
Alla kommandon startas som underprocesser av KDevelop, utan ytterligare kommandoradsväljare eller miljövariabler. Det här kan vara ett problem om anslutningen till CVS-servern går via en ssh-anslutning, och kräver att du skriver in ett lösenord varje gång du arkiverar eller uppdaterar. Det här är till exempel nödvändigt om projektets värd är sourceforge.net. Ett sätt att gå runt problemet beskrivs i vanliga frågor om CVS/SSH, som du hittar i SourceForge-dokumentationen.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Det ursprungliga innehållet i den här handboken är skrivet av Bernd Gehrmann (bernd AT kdevelop.org) och Caleb Tennis (caleb AT aei-tech.com).
Kapitlen Sammanfattning av Hantering av automake och Användning av Hantering av automake är skrivna av Ian Wadham, (ianw AT netspace.net.au)).
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Innehållsförteckning
I det här kapitlet beskriver vi alla steg som behövs för att kompilera och installera den integrerade utvecklingsmiljön KDevelop:
Hur man skaffar KDevelop koncentrerar sig på hur man laddar ner den senaste källkoden för KDevelop från SVN.
Krav för KDevelop listar programmen och biblioteken som du måste ha installerade för att kompilera den integrerade utvecklingsmiljön med lyckat resultat.
Kompilering och installation av KDevelop leder dig igenom alla steg för kompilering och installation av programmet.
Hur man skaffar dokumentation av programmeringsgränssnittet för KDevelop talar om vad ett programmeringsgränssnitt är och hur du skaffar ett så användbart verktyg för navigering i källkoden för KDevelop.
KDevelop är tillgänglig i binärform från många olika Linux®-distributioner som SuSE, RedHat med flera. Binärfilerna är paketerade på något bekvämt sätt, oftast RPM, för att enkelt kunna installeras. Följ standardinstruktionerna som ges i distributionen för att installera.
Du kan mycket väl skaffa källkoden för KDevelop, kompilera och installera den själv. Källkoden hittas via projektets hemsida på http://www.kdevelop.org eller via KDE:s FTP-plats.
Om du vill ta del av aktuell utveckling, är versioner från det anonyma SVN-arkivet tillgängliga.
Modulnamnet är kdevelop med svn co svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/kdevelop.
För att skaffa en ursprunglig version av KDevelop måste du ladda ner den från anonym SVN. Följ bara stegen nedan för den här så kallade utcheckningsåtgärden.
Vi antar att du vill placera din kopia av KDevelop i underkatalogen kde3src i din hemkatalog (~).
| # Skapa målkatalogen, om det behövs: |
~> mkdir kde3src |
~> cd kde3src |
~/kde3src> svn co svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/kdevelop |
~/kde3src> cd kdevelop |
När du väl har lyckats checka ut din version av KDevelop, kan du hänga med i ändringarna genom att använda uppdateringsproceduren som visas i nästa avsnitt.
Håll serverns last nere. Var vänlig att inte checka ut varje gång du vill få en aktuell version av KDevelop! Använd SVN update för detta syfte.
Nu kan du kompilera din version av KDevelop som visas i avsnittet Kompilering och installation av KDevelop.
Efter du checkat ut KDevelop från SVN som visas ovan (och kompilerat med lyckat resultat), vill du hålla den aktuell för att få med alla programfixar. Följ då stegen nedan. (Återigen antar vi att du har placerat din kopia av KDevelop i katalogen kde3src.)
Observera kommandot up (= update) istället för co (vilket betyder checkout).
~> cd kde3src |
~/kde3src> cd kdevelop |
~/kde3src> svn up |
Håll ett öga på meddelanden som SVN visar under uppdateringssekvensen. De exakta stegen i kompileringssekvensen beror på dem.
Nu kan du kompilera en ny version av KDevelop som visas i kapitlet Särskilda hänsyn vid kompilering från SVN.
För att kompilera och använda KDevelop med lyckat resultat, behöver du följande program och bibliotek. De är tillgängliga på de flesta plattformar som distributionspaket, och kan därigenom lätt installeras.
Krävs
gcc/g++ 2.95.3 eller senare (eller motsvarande)
Tillgänglig från gcc.gnu.org
Tillgänglig från www.gnu.org/software/make
Tillgänglig från www.perl.com
autoconf ≥ 2.52 (eller senare)
Tillgänglig från www.gnu.org/software/autoconf
Tillgänglig från www.gnu.org/software/automake
Tillgänglig från www.gnu.org/software/flex
Tillgänglig från www.trolltech.com/products/qt
Tillgänglig från www.kde.org
Valfritt:
Verktyget ctags för källkodsnavigering, från http://ctags.sourceforge.net, som ger dig snabb åtkomst till deklarationer och definitioner med några få enkla klick på ett namn i editorn.
Kompilatorn dot för grafikspråk, från http:/www.graphviz.org. Verktyget behövs tillsammans med Doxygen nedan, om du vill visa klassförhållanden grafiskt (vilket starkt rekommenderas).
Dokumentationsverktyget Doxygen, från http://www.doxygen.org, om du vill skapa koncis och kraftfull dokumentation av programmeringsgränssnittet för dina projekt.
Valgrind från http://developer.kde.org/~sewardj/ hjälper dig att hitta minneshanteringsproblem i dina program.
SVN från http://subversion.tigris.org/, om du vill använda versionshanteringssystemet SVN.
Eventuellt andra kompilatorer och/eller verktyg om du vill utveckla för ett annat språk eller plattform än C++/KDE, eller använda någon annan specialfunktion.
Du kan i viss utsträckning kringgå behovet av autoconf ≥ 2.52 och automake ≥ 1.6. Ta bara bort katalogen admin i installationskatalogen för KDevelop, och skriv:
(din kdevelop-katalog)> ln -s $KDEDIR/share/apps/kdelibs/admin admin |
i terminalen. Det gör att KDevelop använder standardinställningarna i KDE:s admin-katalog istället.
Var försiktig så att du inte blandar olika versioner av Qt™. Länka alltid KDevelop med samma version av Qt™ som KDE-biblioteket kompilerades med. Annars råkar du troligen ut för mycket konstigt beteende.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
När alla krav väl är uppfyllda är du redo att kompilera och installera KDevelop. Det här appendixet beskriver nödvändiga steg för att göra det.
Förberedande steg berättar hur du ställer in en riktig miljö.
Kompilera KDevelop handlar om hur källkoden för KDevelop skaffas från SVN, hur den förbereds för installationsprocessen, och visar till sist stegen som är nödvändiga för att kompilera och installera KDevelop.
Några anmärkningar om väljare till configure talar om hur man kör KDevelop om det har installerats på en annan plats än i KDE-katalogen.
Innan du påbörjar kompileringssekvensen, måste du försäkra dig om att alla bibliotek och verktyg är tillgängliga för byggsystemet. För att uppnå detta, måste vissa miljövariabler ställas in riktigt. Stegen som ska utföras beror på vilket skal du använder i terminalen.
För att undvika att skriva in alla satserna som ställer in nödvändiga miljövariabler varje gång du vill kompilera, kan du placera dem i filen .bashrc eller .cshrc. På så sätt ställs miljövariablerna in riktigt varje gång du startar skalet.
Om du använder bash-skalet, lägg till följande rader:
export KDEDIR=(sökväg till KDE-installationen) |
export QTDIR=(sökväg till Qt-biblioteket) |
export LD_LIBRARY_PATH=$QTDIR/lib:$KDEDIR/lib:$LD_LIBRARY_PATH |
export LIBRARY_PATH=$QTDIR/lib:$KDEDIR/lib:$LIBRARY_PATH |
export PATH=$QTDIR/bin:$KDEDIR/bin:$PATH |
Om du använder tcsh-skalet, lägg till följande rader:
setenv KDEDIR (sökväg till KDE-installationen) |
setenv QTDIR (sökväg till Qt-biblioteket) |
setenv LD_LIBRARY_PATH=$QTDIR/lib:$KDEDIR/lib:$LD_LIBRARY_PATH |
setenv LIBRARY_PATH $QTDIR/lib:$KDEDIR/lib:$LIBRARY_PATH |
setenv PATH $QTDIR/bin:$KDEDIR/bin:$PATH |
I följande beskrivning antar vi att du har placerat källkoden för KDevelop i katalogen ~/kde3src/kdevelop.
Om du använder en aktuell version av KDevelop från SVN, beror de första kompileringsstegen på om du just gjort en fullständig utcheckning, eller bara uppdaterat källkoden.
Du måste initiera byggsystemet efter en ny utcheckning. Samma sak gäller varje gång du måste starta om från början. Skriv:
~/kde3src/kdevelop> make -f admin/Makefile.common svn-clean |
och därefter alla följande steg.
Du kan behöva komma åt SVN-arkivet för att rensa det om några skadade eller saknade filer måste återskapas.
Kommandot svn-clean tar bort alla filer som inte finns i SVN från katalogen. Försäkra dig om att säkerhetskopiera viktig information innan du använder det här rensningskommandot.
Nästa steg beror på utmatningen från SVN-uppdateringssekvensen. Om du fick något som liknar följande (markeringarna U eller P kan finnas i kolumnen längst till vänster, båda anger att filen har ändrats):
U /någon_sökväg/Makefile.am
eller om du precis gjort en fullständig utcheckning, måste du skriva:
~/kde3src/kdevelop> make -f Makefile.svn |
innan du fortsätter med alla följande steg.
När det grundläggande byggsystemet har ställts in, måste du bestämma dig för vilken typ av KDevelop-system du vill använda. Det görs med följande konfigureringssteg, som bygger de verkliga filerna med namn Makefile, som kommandot make kommer att använda.
Du kan utelämna väljaren --prefix i följande kommandorader med configure, om du vill att KDevelop ska installeras i KDE:s standardkatalog. Se kapitlet Några anmärkningar om väljare till configure om detta.
Om du vill hålla ordning på vad programmet KDevelop gör när det kör, kan du bygga en version kompilerad med avlusning. Tala bara om för configure att göra det:
~/kde3src/kdevelop> ./configure --enable-debug=full --prefix=(där din kde3 finns) |
Om du bara vill använda KDevelop som det är (mindre och snabbare), räcker det med en version kompilerad för distribution. Det är förvalt i configure.
~/kde3src/kdevelop> ./configure --prefix=(där din kde3 finns) |
Om du vill skapa din egen dokumentation av programmeringsgränssnittet för KDevelop, måste du ta med ytterligare en väljare i kommandot configure:
~/kde3src/kdevelop> ./configure --(väljare enlikt ovan) \ |
--with-kdelibsdoxy-dir=$KDEDIR/share/doc/HTML/en/kdelibs-apidocs |
Kommandot configure kontrollerar systemet och skapar några filer vid namn Makefile enligt vad det hittar. Kommandot make använder normalt den huvudsakliga filen Makefile. Alltså är
~/kde3src/kdevelop> make |
tillräckligt. Om nödvändigt, skaffa rättigheter som systemadministratör genom att använda kommandot
~/kde3src/kdevelop> su |
och ange systemadministratörens lösenord. Installera sedan programmet:
~/kde3src/kdevelop> make install |
Det är allt. Om du installerade KDevelop i KDE:s standardkatalog, kan du nu köra den integrerade utvecklingsmiljön. Annars är några ytterligare steg nödvändiga, som visas i avsnittet Annan installationskatalog än standard nedan.
I själva verket har tre KDevelop-baserade program installerats:
Den integrerade utvecklingsmiljön KDevelop: Det här är platsen där du oftast arbetar.
Den fristående dokumentationsbläddraren KDevelop assistent: Isolerar alla kraftfulla dokumentationsfunktioner i utvecklingsmiljön KDevelop i ett separat verktyg. Det här är praktiskt när du vill slå upp någon programmeringsdokumentation, men inte vill starta den fullständiga utvecklingsmiljön.
KDevelop Designer: Utökar Qt™ Designer för grafiska gränssnitt med element specifika för KDE och integreras på ett bra sätt i utvecklingsmiljön KDevelop.
Normalt förbereder configure för att installera den grafiska utvecklingsmiljön i KDE:s standardkatalog. Det behövs, eftersom KDevelop antar att det går att direkt komma åt vissa verktyg och delprogram som finns där. Om du vill använda din egen installationskatalog, måste du tala om det för configure med väljaren --prefix:
~/kde3src/kdevelop> ./configure --prefix=(där din kde3 finns) |
Det finns ett problem om du gör det. Du måste ge möjlighet för KDevelop att komma åt nödvändiga verktyg och delprogram i KDE:s katalog när det kör. (Du kan fortfarande använda den integrerade utvecklingsmiljön utan att göra det, men med mycket begränsade funktioner.)
Starta ett skal och se till att köra följande kommandon innan du startar KDevelop från skalet.
Försäkra dig om att använda pluralis: Det är “KDEDIRS”, inte bara “KDEDIR”.
~> export KDEDIRS=/usr/local/kde:/opt/kde3 |
~> kbuildsycoca |
| (Starta nu KDevelop:) |
~> kdevelop |
Miljövariabeln KDEDIRS måste vara inställt till listan med aktiva KDE-bibliotek i systemet. Vi använder |
/usr/local/kde:/opt/kde3 |
| bara som ett exempel. |
Katalogen /usr/local/kde kan till exempel innehålla en ofullständig KDE-version som du kompilerat i avlusningssyfte, och katalogen /opt/kde3 innehåller dessutom den vanliga KDE-versionen från distributionen som används för dagligt arbete. |
I ett tcsh-skal måste du ställa in miljövariablerna genom att använda:
~> setenv KDEDIRS /usr/local/kde:/opt/kde3 |
Kommandot kbuildsycoca (“bygg systemkontrollcache”) söker efter bibliotek och lagrar deras plats och version i en cache, så att KDevelop kan hitta dem. Problemet är att det tar märkbart med tid, och måste köras varje gång du använder skalet för att starta KDevelop med en annan installationskatalog än standardkatalogen. Du skulle kunna skriva in ovanstående kommandon i ett skalskript för att reducera ansträngningen att skriva in det.
(Du skulle också kunna skriva in raderna i filen .bashrc eller .cshrc, men det är inte önskvärt eftersom då körs kbuildsycoca varje gång du använder skalet.)
Kommandot kbuildsycoca kör inte för systemadministratören. Du måste anropa det som en annan användare. (Men det är inte en särskild god idé att utveckla programvara som systemadministratör!)
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Programmeringsgränssnittet, “Application Program Interface” på engelska, ofta förkortat API, innehåller i själva verket en följd av beskrivningar (dvs. anropsmodeller) som ett program kan använda för att komma åt operativsystem och andra tjänster. I vårt fall har dock en mer omfattande definition använts. Programmeringsgränssnittet för ett KDE- eller Qt™-program är en sammanfattning av klasser och metodgränssnitt, en översikt som kan användas som uppslagsbok för navigation i källkoden.
Det finns en version av det senaste programmeringsgränssnittet på KDevelops hemsida. Den uppdateras automatiskt varje dygn så att du kan hänga med.
Tyvärr används den här versionen bäst för att bara läsa via Internet. Om du inte alltid är uppkopplad, kan du lika väl bygga din egen dokumentation av programmeringsgränssnittet från källkoden för KDevelop. För att göra det, måste du tala om det för automake-systemet var KDELIBS programmeringsgränssnitt finns på din dator. Det kan åstadkommas med den särskilda väljaren --with-kdelibsdoxy-dir i kommandot configure när du förbereder kompilering av källkoden för KDevelop.
~/kde3src/kdevelop> ./configure --(vanliga väljare) \ |
--with-kdelibsdoxy-dir=$KDEDIR/share/doc/HTML/en/kdelibs-apidocs
|
(make ersätter den globala variabeln $KDEDIR med den verkliga inställningen av KDE-katalogen som finns där). Utför sedan kommandot make som vanligt. Efter att den integrerade utvecklingsmiljön KDevelop har byggts, har du möjlighet att också bygga programmeringsgränssnittet. För att göra det måste du skriva:
~/kde3src/kdevelop> make apidocs |
Detta bygger en Doxyfile i baskatalogen för KDevelop, som i sin tur behandlas av programmet Doxygen för att skapa en hel del .html-filer för programmeringsgränssnittet. När den ganska långa byggprocessen (den kan ta mer än en timme på en långsam dator) av programmeringsgränssnittet till sist är klar, måste du installera programmeringsgränssnittet precis som du måste installera själva den integrerade utvecklingsmiljön KDevelop. Skaffa rättigheter som systemadministratör om det behövs med:
~/kde3src/kdevelop> su |
och ange systemadministratörens lösenord. Installera sedan dokumentationsfilerna:
~/kde3src/kdevelop> make install-apidox |
När det här väl är gjort, informerar make dig om katalogen där du till sist kan titta på innehållet i dokumentationen av programmeringsgränssnittet. Observera adressen, eftersom du kan använda den från Konqueror samt inne i KDevelop, om du har ställt in den egna källkoden för KDevelop som projektet att arbeta med.
Du ser troligen en mängd varningar och/eller felmeddelanden under tiden programmeringsgränssnittet byggs av Doxygen. Det är bäst att ignorera dem. De är bara av intresse för utvecklare av KDevelop. Om programmeringsgränssnittet väl skapats med lyckat resultat, blir dess .html-filer användbara.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Informationen i det här kapitlet är avsett som en snabbreferens för att genast komma igång om du (tillfälligt) glömt bort några grundläggande koncept. Det finns också korta tips om hur några vanliga problem vid arbete med KDevelop kan lösas.
Om du vill ha mer information om ett ämne, följ bara länken i rubriken som erbjuder det.
Information om följande ämnen är tillgänglig:
| Utseende och känsla |
| Projekt |
| Kompilering |
| Hantering av automake |
| Problem med att kompilera och bygga |
| Övriga ämnen |
Utseende och känsla
Normalt startar KDevelop med flikar som har stora textbaserade verktygstips omkring arbetsytan. Du kan ändra detta utseende, för att spara utrymme, i inställningsdialogrutan för KDevelop (->->).
Om du använder en äldre version av KDevelop 3, kanske den här inställningsdialogrutan inte är tillgänglig. För att ändra utseendet hos verktygsvyernas flikar för hand, lägg till posten MDIStyle under rubriken [UI] i inställningsfilen $KDEHOME/share/config/kdeveloprc enligt följande:
MDIStyle=0: Bara ikoner |
MDIStyle=1: bara text (normalvärde) |
MDIStyle=3: ikoner och text |
Om du observerar slumpmässigt färgade bokstäver överallt (dvs. på flikar, verktygsrader, etc.) och KDevelops fönster verkar använda en felaktig skärmstil, kan följande hjälpa:
Hitta raden “Style=Checked” i inställningsfilen $KDEHOME/share/config/kdeveloprc och ta bort den. Starta därefter om KDevelop.
(Beteendet uppstår ibland efter du vänsterklickat på en .ui-fil i en av filbläddrarna och KDevelop laddat KUIViewer för att visa det grafiska gränssnittet som skapats från filen.)
Välj -> i menyraden, eller tryck på Ctrl-Skift-F.
För att dölja menyraden, välj -> i menyraden, eller tryck på Ctrl-M. För att visa menyraden igen, är bara Ctrl-M tillgängligt.
Projekt
-> startar programguiden.
Det finns inte något sätt att direkt skapa ett eget projekt (dvs. ett projekt som använder sina egna byggfiler). Använd istället ->. Kom ihåg att ange passande Projekttyp i dialogrutan, med den extra texten “(Custom Makefiles)”.
Så fort du skapat ett nytt projekt, glöm inte att ställa in -> enligt dina behov.
Kompilering
Om du märker att en del värdefull information saknas i fönstret Meddelandeutmatning vid kompilering,kan du ha valt en detaljnivå för meddelanden som är för låg. Högerklicka på fönstret och välj en annan detaljnivå i menyn som dyker upp.
Välj delprojekt i övre delen av Hantering av automake, och högerklicka sedan i nedre delen på grupprubriken där du vill lägga till filerna och välj .
Välj delprojekt i övre delen av Hantering av automake, och högerklicka sedan i nedre delen på grupprubriken där du vill lägga till filerna och välj .
Välj delprojekt i övre delen av Hantering av automake, och högerklicka sedan i nedre delen på grupprubriken där du vill ta bort filerna och välj .
Problem med att kompilera och bygga
Det finns ett problem med automake och autoconf maskineriet. Om -> ger möjlighet att välja bland tre byggkataloger: , och , håll dig för allt i världen antingen till målet default eller målen debug/optimize.
När du väl har ställt in projektet med default, byggs det inte längre med debug eller optimized.
När du väl har ställt in projektet med debug eller optimized, byggs det inte längre med default.
Det finns flera felmeddelanden som berör för gamla versioner av autoconf, etc. som förhindrar att configure fungerar som det ska. Kör autoreconf i katalogträdet där filerna configure.in i fråga finns. Kommandot försöker uppdatera informationen i GNU byggsystemfiler. Se man autoreconf för mer information.
Övriga ämnen
Oftast ska du inte behöva bry dig om det, men det är mycket användbart att känna till om något har gått fel med dina inställningar.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Innehållsförteckning
Från början har UNIX® upprätthållit två mycket olika utvecklingsmodeller. Den ena är sfären av programspråk för system och tillämpningar, där en källkod översätts till maskinkod med en kompilator eller tolk. 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.)
Den andra modellen är sfären med skriptspråk, 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. grep, sed eller find. 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 rörledning, 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.
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.
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.
Alla skriptspråk har gemensamt att de ofta är flyttbara mellan många UNIX®-varianter, Microsoft® Windows®, Mac® OS eller till och med VMS. Dessutom har de alla implementeringar som kan distribueras fritt.
Perl 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 mod_perl för webbservern Apache. Bland Perls styrkor är dess inbyggda stöd för avancerade reguljära uttryck, och rika arkiv med fritt distribuerade moduler.
För mer information se webbplatsen Comprehensive Perl Archive Network (CPAN).
Python 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.
PHP 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.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
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.
Försök har gjorts att tillhandahålla liknande mekanismer som fungerar på en högre programnivå, bland de mest nämnvärda är CORBA, och i KDE-miljön, DCOP.
CORBA (Common Object Request Broker Architecture) är ett försök att låta datorprogram arbeta tillsammans via nätverk. Det togs fram av den privata, leverantörsoberoende kommittén OMG (Object Management Group).
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.
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.
En annan evolution av UNIX®-liknande skript är DCOP-protokollet, som uppfanns för kommunikation mellan KDE-program för att bemästra CORBA:s begränsningar.
DCOP betyder Desktop COmmunikation Protocol (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®.
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.
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.
För ytterligare information, se artikeln DCOP: Desktop COmmunications Protocol eller The DCOP Desktop Communication Protocol library, dokumentation av användargränssnittet för KDE:s DCOP-bibliotek.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
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.
För att åstadkomma detta, är de grundläggande verktyg som behövs:
en texteditor för att skriva källkodsfilerna,
ett översättningsprogram, oftast en kompilator för att omvandla källkoden till objektfiler,
ett biblioteksprogram som samlar objektfiler i bibliotek, som enkelt kan återanvändas utan att behöva kompileras om,
en länkare, som binder ihop flera objektfiler och bibliotek till ett körbart program,
ett byggsystem, som erbjuder något sätt att hantera allt detta, och inte att förglömma,
en avlusare för att (förhoppningsvis) hitta alla fel i programmet, och möjligen ytterligare diagnosverktyg för att få allt att köra smidigt.
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.
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.
Ett verktyg som tar hand om omkompileringar är make. Det håller reda på allt arbete med en uppsättning regler, 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 Makefile, som behandlas av make så fort du vill uppdatera arbetet.
Varje regel består av flera byggblock, närmare bestämt
ett mål, dvs filen som ska byggas
en uppsättning beroenden, 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
de kommandon som ska köras för att “bygga” målet (dvs. för att kompilera det eller länka ihop andra objektfiler för att skapa en körbar programfil).
Enkelt uttryckt, läser kommandot make 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.
Det finns flera ytterligare möjligheter att styra en sådan byggprocess, och en Makefile 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 make. Även om du inte normalt använder det direkt, kan en förståelse för grunderna i byggsystemet vara användbar. Se GNU make manualen för mer information.
För mer detaljinformation specifik för KDevelop, se Bygga och projekthantering i den här handboken.
Det finns flera handledningar tillgängliga, se referenserna i kapitlet Bygga och projekthantering.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
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.
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.
För utveckling av grafiska gränssnitt för KDE finns en stilguide tillgänglig. Den finns som KDE:s guide för användargränssnitt på sidan KDE:s utvecklingshörna.
En kort introduktion till gemensamma principer för konstruktion av grafiska gränssnitt finns här.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
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.
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.
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?
För att enklare uppnå ett sådant fall, togs integrerade utvecklingsmiljöer (IDE:er) fram. En sådan miljö integrerar alla mallar, verktyg och skript som ofta behövs i utvecklingsprocessen i en enda omgivning.
KDevelop ä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.
Hanterar alla utvecklingsverktyg som behövs för C++ programmering, som kompilator, länkare, avlusare och byggsystem.
Tillhandahåller en programguide som skapar fullständiga, körklara exempelprogram.
Låter användaren välja en integrerad editor baserad på KDE:s programmeringseditor KWrite, TrollTechs Qeditor eller andra.
En klassgenerator för att skapa nya klasser och integrera dem i det nuvarande projektet.
Filhantering för källkod, deklarationer, dokumentation, etc. som ska ingå i projektet.
Hjälp med att skapa en användarhandbok för programmet skriven med KDE-verktyg.
Automatisk HTML-baserad dokumentation av programmeringsgränssnittet för projektets klasser med korsreferens till använda bibliotek.
Översättningsstöd 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.
Stöd för att hantera ett projekt via ett av flera versionshanteringssystem (t.ex. CVS), genom att tillhandahålla ett lättanvänt gränssnitt till funktionerna som oftast behövs.
Ett integrerat gränssnitt för avlusning.
En integrerad emulator av en skalkonsol.
Syntaxfärgläggning i källkodstext.
En funktion för automatisk kodkomplettering för klassvariabler, klassmetoder, funktionsargument med mera.
Mallar för att skapa diverse projekt (moduler i inställningscentralen, miniprogram i panelen Kicker, I/O-slavar, insticksprogram till Konqueror och skrivbordsstilar).
Fyra trädvyer för att enkelt byta mellan källkodsfiler, deklarationsfiler, klasser och dokumentation, vilket gör det onödigt med en extern filhanterare.
Stöd för korskompilering, med möjlighet att ange olika kompilatorer, kompilatorflaggor, målarkitektur etc.
Stöd för projekt med Qt/Embedded (som Zaurus och IPAQ).
Möjlighet att inkludera vilket annat program som helst som du behöver för utveckling genom att lägga till det i menyn , enligt dina individuella behov.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Innehållsförteckning
KDevelop använder en uppsättning inställningsfiler som är fördelade bland flera kataloger. Det finns två huvudgrupper med inställningsfiler att skilja på:
| KDevelop standardinställningar: Filer som ställdes in när KDevelop installerades. |
| Användarorienterade inställningar: Filer som innehåller användarändringar av standardvärden samt inställningar som gjorts av själva KDevelop-programmet och dess insticksprogram. |
Vid installation skriver KDevelop några standardinformationsfiler i inställnings- och konfigurationssyfte till underkataloger i installationskatalogen $ (oftast något som liknar KDEDIR/opt/kde, /usr/local/kde eller en annan användardefinierad installationskatalog, se Installera KDevelop).
Det finns bara en KDevelop-specifik standardinställningsfil i katalogen $: KDEDIR/share/config
kdeveloprcFilen innehåller de grundläggande inställningarna som KDevelop behöver för att starta. Den kopieras till användarens katalog $ när KDevelop inte hittar filen KDEHOME/share/configkdeveloprc där vid start.
De flesta KDevelop funktioner tillhandahålls av delprogram. De är egentligen program som är särskilt konstruerade att köra i KDevelops ramverk (se översikten i appendix Insticksverktyg). Varje delprogram har sin egen uppsättning med inställningsfiler vars standardvärden lagras i flera underkataloger i installationskatalogen $. KDEDIR/share/apps/
Det finns en hel mängd underkataloger för standardinställningar i $ med namn som börjar med bokstavsföljden KDEDIR/share/apps/kdev. De flesta av dem är bara till för KDevelops interna användning. De kan vara avsiktligt grupperade för läsbarhet som:
| Fristående program |
| Aktivitetsspecifika delprogram |
| Delprogram för att skapa projekt |
| Språkspecifika delprogram |
Fristående program
kdevelop/: Innehåller filer för att anpassa KDevelops integrerade utvecklingsmiljö.
licenses/: Innehåller diverse licenstexter.
pics/: Innehåller bildfilerna som används av startskärmarna i KDevelop, KDevelop assistent och KDevelop designer.
profiles/: Innehåller standardprofilinställningar för insticksprogram. (För närvarande finns det bara en profil tiny, som definierar en minimal uppsättning aktiva insticksprogram i KDevelop.)
eventsrc: Innehåller en mängd lokaliseringssträngar för “Processen lyckades”.
kdevelopui.rc: Tillhandahåller de grundläggande menyalternativen och verktygsradsikonerna som KDevelop använder.
kdevhtml_partui.rc: Tillhandahåller alternativet i menyn , alternativet i menyn , och pilarna Tillbaka och Framåt i verktygsraden Bläddra vid bläddring i en HTML-fil från insticksprogrammet Dokumentation.
kdevassistant/: Tillhandahåller menyer och verktygsrader för den fristående dokumentationsbläddraren, KDevelop assistent.
kdevdesigner/ och kdevdesignerpart/: Tillhandahåller menyer och verktygsrader i det fristående programmet för konstruktion av användargränssnitt, KDevelop designer.
Aktivitetsspecifika delprogram
kdevabbrev/: Innehåller filer som används av insticksprogrammet Expansion av förkortningar:
sources/: Innehåller definitionsfiler av nyckelord som används av kommandot Expandera text.
templates/: Innehåller definitionsfiler för mallar som används av kommandot Expandera förkortningar.
kdevabbrev.rc: Tillhandahåller alternativen och i menyn .
kdevappwizard/: Innehåller filer som används av delprogrammet Programguide:
importfiles/: Innehåller .kdevelop-projektfiler som styr initieringen av ett nytt projekt.
imports/: Innehåller mallar för att skapa projektspecifika .desktop-filer.
template-common/: Innehåller diverse filer som ofta ingår i projektets källkataloger.
templates/: Innehåller inställningsfiler som beskriver informationen som ska ingå i ett givet projekts källkatalog.
*.png: Förhandsgranskningsbilder av projekt som används av programguiden.
*.tar.gz: komprimerade arkiv som innehåller källkodsfiler som ska ingå i en nyskapad projektkatalog.
kdevastyle/: Tillhandahåller alternativet i menyn .
kdevautoproject/: Tillhandahåller de flesta alternativen för menyn och verktygsraden Bygg (KDevelop).
kdevclassview/: Innehåller filer som används av projektinsticksprogrammet Klassvisning:
pics/: Innehåller ikonerna som används i klassvisningsträdet Klasser.
kdevclassview.tc: Tillhandahåller alternativet i menyn samt kombinationsrutan för klassnavigering i Bläddringsverktygsraden.
kdevcloser/: Tillhandahåller stängningsalternativen i menyn .
kdevctags/: Tillhandahåller alternativet i menyn för projektinsticksprogrammet Ctags-gränssnitt.
kdevcvsservice/: Tillhandahåller ikonen som används av fliken CVS-tjänst och ett kort skalskript för att lägga till en ny post i CVS-arkivet, som båda används av projektinsticksprogrammet Integrering av CVS.
kdevdebugger/: Tillhandahåller menyalternativen under för projektinsticksprogrammet Gränssnitt för avlusare.
kdevdiff/: Tillhandahåller alternativet i menyn .
kdevdistpart/: Tillhandahåller alternativet i menyn för projektinsticksprogrammet Stöd för slutpaketering.
kdevdocumentation/: Innehåller filer som används av insticksprogrammet Dokumentation:
en/ och pics/: Innehåller filer som används av sökverktyget htdig.
tocs/: Innehåller innehållsbeskrivningsfiler för KDevelops standarddokumentation (se beskrivningen i Grundstruktur för KDevelop innehållsförteckningsfiler).
kdevpart_documentation.rc: Tillhandahåller sökrelaterade alternativ i menyn .
kdevdoxygen/: Tillhandahåller menyalternativ för projektinsticksprogrammet Doxygen-stöd.
kdevfilecreate/: Innehåller filer som används av Guide för ny fil:
file-templates/: Tillhandahåller det ursprungliga textinnehållet som ska infogas i en ny källkodsfil av en given typ.
kdevpart_filecreate.rc: Tillhandahåller alternativet i menyn .
template-info.xml: Innehåller beskrivningar av de tillgängliga filtyperna som ska visas i verktygsvyn Ny fil.
kdevfilter/: Tillhandahåller alternativen och i menyn som används av insticksprogrammet Skalfiltrering och infogning.
kdevfullscreen/: Tillhandahåller alternativet i menyn och motsvarande ikon i verktygsraden.
kdevgrepview/: Tillhandahåller alternativet i menyn som används av insticksprogrammet Gränssnitt till grep.
kdevhistory/: Tillhandahåller alternativen och i menyn .
kdevjavadebugger/: Tillhandahåller menyn för att avlusa ett Java™-program.
kdevoutputviews/: Tillhandahåller alternativen och i menyn .
kdevpartexplorer/: Tillhandahåller alternativet i menyn som används av insticksprogrammet Delutforskningsverktyg.
kdevquickopen/: Tillhandahåller alternativet i menyn samt alternativen och i menyn som används av projektinsticksprogrammet Snabböppna.
kdevregexptest/: Tillhandahåller alternativet i menyn som används av insticksprogrammet Test av reguljära uttryck.
kdevreplace/: Tillhandahåller alternativet i menyn som används av insticksprogrammet Ersättning.
kdevtipofday/: Tillhandahåller alternativet i menyn samt HTML-filen som innehåller tillgängliga tips.
kdevtools/: Styr de olika menyalternativen som skapas av inställningarna och Externa verktyg som tillhandahålls av insticksprogrammet Tillägg i verktygsmenyn.
kdevvalgrind/: Tillhandahåller alternativen och i menyn som används av insticksprogrammet Valgrind-gränssnitt.
Delprogram för att skapa projekt
kdevadaproject/: Tillhandahåller alternativ för menyn och motsvarande ikoner i verktygsraden för att bygga ett Ada-program.
kdevantproject/: Tillhandahåller alternativ för menyn när skapa projekt med Ant används.
kdevautoproject/: Tillhandahåller alternativ för menyn och motsvarande ikoner i verktygsraden vid arbete med automake projektgenerering baserat på GNU-verktygen. Tillhandahåller dessutom alternativen och i menyn .
kdevcustomproject/: Tillhandahåller alternativ för menyn och motsvarande ikoner i verktygsraden när projektet är baserat på en egen Makefile.
kdevgenericproject/: Innehåller menydefinitioner för en experimentell generell projektgenerering. För närvarande (version 3.1.0) oanvänd.
kdevhaskellproject/ Tillhandahåller alternativ för menyn och motsvarande ikoner i verktygsraden för att bygga ett Haskell-program.
kdevpascalproject/ Tillhandahåller alternativ för menyn och motsvarande ikoner i verktygsraden för att bygga ett Pascal-program.
kdevtrollproject/ Tillhandahåller alternativ för menyn och motsvarande ikoner i verktygsraden för att bygga ett projekt med användning av Qt™ QMake projekthanteraren.
Språkspecifika delprogram
kdevadasupport/: Tillhandahåller alternativ i menyn och motsvarande ikoner i verktygsraden som behövs för att utveckla Ada-program.
kdevbashsupport/: Tillhandahåller alternativ i menyn och motsvarande ikoner i verktygsraden som behövs för att utveckla Bash-skript.
kdevcppsupport/: Innehåller filer som används av programguiden för att bygga C++ program:
newclass/: Innehåller deklarations- och källkodsmallar som programguiden bygger motsvarande källkodsfiler.
subclassing/: Innehåller mallar som programguiden använder för att skapa ursprungliga klassdeklarationer och klassdefinitioner i källkodsfilerna.
templates: Innehåller mallar som programguiden använder för att skapa standardhuvud och mallfiler för källkod som används av New File Wizard.
configuration: Mall för att lägga till makron.
kdevcppsupport.rc: Tillhandahåller alternativen och i menyn , alternativet för menyn , och alternativet för menyn samt ikonen Ny klass för Bläddringsverktygsraden.
kdevfortransupport/: Tillhandahåller alternativ i menyn som behövs för att utveckla Fortran-program.
kdevhaskellsupport/: Tillhandahåller alternativ i menyn och motsvarande ikoner i verktygsraden som behövs för att utveckla Haskell-program.
kdevjavasupport/: Innehåller gränssnittsdefinitionerna som behövs för att utveckla Java™-program.
kdevpascalsupport/: Innehåller gränssnittsdefinitionerna som behövs för att utveckla Pascal-program.
kdevperlsupport/: Tillhandahåller alternativ i menyerna och som behövs för att utveckla Perl-skript.
kdevphpsupport/: Innehåller gränssnittsdefinitioner och PHP-definitioner som behövs för att utveckla PHP-skript.
kdevpythonsupport/: Tillhandahåller alternativ i menyerna och samt motsvarande ikoner i verktygsraden som behövs för att utveckla Python-skript.
kdevrubysupport/: Tillhandahåller alternativ i menyn och motsvarande ikoner i verktygsraden som behövs för att utveckla Ruby-skript.
kdevscriptproject/: Tillhandahåller gränssnittsdefinitionerna som behövs för att utveckla egna projekt. För närvarande (version 3.1.0) oanvänd.
kdevsqlsupport/: Tillhandahåller gränssnittsdefinitionerna som behövs för att utveckla SQL-projekt. För närvarande (version 3.1.0) oanvänd.
All information om användardefinierade inställningar finns i två underkataloger i $, nämligen: KDEHOME
Programspecifika inställningar i katalogen $, och |
Resursinställningsfiler i katalogen $. |
Alla användarens ändringar av standardinställningar i KDevelop samt användarspecifika inställningar som inte lagras i någon av resursinställningsfilerna finns i underkatalogerna kdev... i katalogen $. KDEHOME/share/apps/
De flesta av dessa inställningsfiler används dock av diverse insticksprogram i KDevelop för att tillhandahålla någon specifik meny och/eller verktygsradsikon. Därför är de bara intressanta om något verkligen har gått fel i användargränssnittet.
I det fallet du innehållet i katalogerna speglar det i de standardinställningarna, har KDevelop kopierat dem från $ till katalogen KDEDIR/apps/$ vid den första starten. Alla följande ändringar görs bara i kopiorna. Standardinställningarna förblir hur som helst orörda. KDEHOME/apps/
kdevabbrev/: Innehåller filer som används av insticksprogrammet Expansion av förkortningar:
sources/: För närvarande tom. KDevelop använder standarddefinitionsfiler för nyckelord till kommandot Expandera text.
templates/: Innehåller definitionsfiler ändrade av användaren för mallar som används av kommandot Expandera förkortningar.
kdevabbrev.rc: Tillhandahåller alternativen och i menyn .
kdevappwizard/: Tillhandahåller alternativen och i menyn . Programguiden använder standardinställningar för den verkliga funktionen.
kdevastyle/: Tillhandahåller det verkliga alternativet i menyn .
kdevautoproject/: Tillhandahåller de verkliga alternativen i menyn och verktygsraden Bygg (KDevelop).
kdevclassview/: Tillhandahåller alternativet i menyn samt kombinationsrutan för klassnavigering i Bläddringsverktygsraden från projektinsticksprogrammet Klassvisning.
kdevcloser/: Tillhandahåller alternativet i menyn .
kdevcppsupport/: Innehåller de verkliga inställningarna som används av programguiden för att skapa C++ program. Programguiden använder den största delen av sina inställningar direkt från katalogen med standardinställningar. Titta där för mer detaljinformation.
newclass/: Innehåller de verkliga deklarations- och källkodsmallar som programguiden använder för att bygga motsvarande källkodsfiler.
pcs/: Innehåller databasfiler som KDevelop använder för att bygga den verkliga filen för bestående kodlagring (.pcs) för ett KDE C++ projekt.
kdevcppsupport.rc: Tillhandahåller alternativen och i menyn , alternativet för menyn , och alternativet för menyn samt ikonen Ny klass för Bläddringsverktygsraden.
kdevctags/: Tillhandahåller alternativet i menyn för projektinsticksprogrammet Ctags-gränssnitt.
kdevdebugger/: Tillhandahåller menyalternativen under för projektinsticksprogrammet Gränssnitt för avlusare.
kdevdiff/: Tillhandahåller alternativet i menyn .
kdevdocumentation/: Innehåller de verkliga filerna som används av insticksprogrammet Dokumentation förutom de standardinställningsfilerna. Titta där för mer detaljinformation.
Katalogerna under kdevdocumentation/ innehåller i huvudsak bokhållningsinformation. De verkliga inställda dokumentationsfilerna finns i filerna “doc...pluginrc” i katalogen $.KDEHOME/share/config/
bookmarks/: Underhåller posterna under fliken Bokmärken som används av insticksprogrammet Dokumentation i KDevelop.
index/: Innehåller diverse cachefiler som KDevelop använder för att snabba upp indexerade sökningar i dokumentationen under fliken Index med insticksprogrammet Dokumentation.
search/: Innehåller filer som används av sökverktyget htdig som hanterar sökanrop från fliken Sök i insticksprogrammet Dokumentation.
kdevpart_documentation.rc: Tillhandahåller sökrelaterade alternativ i menyn .
kdevdoxygen/: Tillhandahåller menyalternativ för projektinsticksprogrammet Doxygen-stöd.
kdevelop/: Innehåller några verkliga alternativ som KDevelop använder som grundläggande inställning:
profiles/: Tillhandahåller de verkliga profilinställningarna för insticksprogram (från början finns det bara en profil FullIDE som definierar en fullständig uppsättning med aktiva insticksprogram i KDevelop.)
kdevelopui.rc: Tillhandahåller de grundläggande menyalternativen och verktygsradsikonerna som KDevelop använder.
kdevfilecreate/: Innehåller filer som används av Guide för ny fil:
file-templates/: Tillhandahåller det verkliga textinnehållet som ska infogas i en ny källkodsfil av en given typ. Fler filmallar finns i katalogen med standardinställningsfiler.
kdevpart_filecreate.rc: Tillhandahåller alternativet i menyn .
template-info.xml: Innehåller beskrivningar av de tillgängliga filtyperna som ska visas i verktygsvyn Ny fil.
kdevfilter/: Tillhandahåller alternativen och i menyn som används av insticksprogrammet Skalfiltrering och infogning.
kdevfullscreen/: Tillhandahåller alternativet i menyn och motsvarande ikon i verktygsraden.
kdevgrepview/: Tillhandahåller alternativet i menyn som används av insticksprogrammet Gränssnitt till grep.
kdevoutputviews/: Tillhandahåller alternativen och i menyn .
kdevpartexplorer/: Tillhandahåller alternativet i menyn som används av insticksprogrammet Delutforskningsverktyg.
kdevquickopen/: Tillhandahåller alternativet i menyn samt alternativen och i menyn som används av projektinsticksprogrammet Snabböppna.
kdevregexptest/: Tillhandahåller alternativet i menyn som används av insticksprogrammet Test av reguljära uttryck.
kdevreplace/: Tillhandahåller alternativet i menyn som används av insticksprogrammet Ersättning.
kdevtipofday/: Tillhandahåller alternativet i menyn . HTML-filen som innehåller tillgängliga tips tillhandahålls bara som en standardinställningsfil.
kdevtools/: Styr de olika menyalternativen som skapas av inställningarna och Externa verktyg som tillhandahålls av insticksprogrammet Tillägg i verktygsmenyn.
kdevvalgrind/: Tillhandahåller alternativen och i menyn som används av insticksprogrammet Valgrind-gränssnitt.
Det finns två grupper av KDevelop inställningsfiler i katalogen $, som åtskiljs av omgivande bokstavssekvenser: KDEHOME/share/config/
“doc...pluginrc” anger filer som används av insticksprogrammet för dokumentations |
“kdev...rc” anger inställningsfiler som används av KDevelop själv och tillgängliga insticksprogram. |
Inställningsfiler som används av KDevelop
kdevabbrevrc: Innehåller nuvarande tillstånd för inställningen Förkortningar som tillhandahålls av insticksprogrammet Expansion av förkortningar.
Det här lagrar om förkortningarna kommer att användas eller inte. De verkliga definitionerna av nya förkortningar hamnar i filen $.KDEHOME/share/apps/kdevabbrev/templates/templates
kdevassistantrc: Innehåller vissa specifika inställningstillstånd för den fristående dokumentationsbläddraren KDevelop assistent.
De flesta vanliga inställningar delas med filen för KDevelops integrerade utvecklingsmiljö kdeveloprc.
kdevassistantuimode4rc: Innehåller nuvarande inställningstillstånd för flerfönsterläge (dockningspositioner, etc.) för den fristående dokumentationsbläddraren KDevelop assistent.
kdevclassviewrc: Innehåller inställningarna för Visningsläge för klassbläddrarfliken Klasser som tillhandahålls av projektinsticksprogrammet Klassvisning.
Det här är en global inställning, även om insticksprogrammet Klassvisning kan vara inaktiverad för varje projekt. Alla ändringar av inställningen uppdateras globalt så fort det aktuella projektet stängs, och påverkar därför alla följande projekt som laddas.
kdevcppsupportrc: Innehåller vissa inställningar som används för att skapa CPP-källkodsfiler. I synnerhet hittar du inställningarna som gjorts i inställningsdialogrutan Skapa ny klass i C++.
kdevdocumentationrc: Innehåller verkliga inställningar som insticksprogrammet Dokumentation använder.
kdeveloprc: Innehåller globala inställningar som den integrerade utvecklingsmiljön KDevelop och den fristående dokumentationsbläddraren KDevelop assistent använder.
kdevelopuimode4rc: Innehåller nuvarande inställningstillstånd för flerfönsterläge (dockningspositioner, etc.) för den integrerade utvecklingsmiljön KDevelop.
kdevfileselectorrc: Innehåller verkliga inställningar som insticksprogrammet Filväljare använder.
kdevfileviewrc: Innehåller verkliga inställningar av filnamnsfärger som projektinsticksprogrammet Integrering av CVS (Cervisia) använder för visning.
kdevfilterrc: Innehåller verkliga inställningar som insticksprogrammet Skalfiltrering och infogning använder.
kdevgrepviewrc: Innehåller verkliga inställningar som insticksprogrammet Gränssnitt till grep använder.
kdevsnippetrc: Innehåller verkliga inställningar som insticksprogrammet Kodsnuttar använder.
kdevtoolsrc: Innehåller verkliga inställningar som insticksprogrammet Tillägg i verktygsmenyn använder.
Inställningsfiler som används av insticksprogrammet för dokumentation
docchmpluginrc: Innehåller information om de verkliga Microsoft® CHM-hjälpfilerna som de definieras på inställningssidan CHM-dokumentationssamling.
doccustompluginrc: Innehåller information om alla egna dokumentationsfiler som de definieras på inställningssidan Egen dokumentationssamling.
docdevhelppluginrc: Innehåller information om de verkliga GNOME 2 DevHelp-dokumentationsfiler som de definieras på inställningssidan DevHelp-dokumentationssamling.
docdoxygenpluginrc: Innehåller information om de verkliga dokumentationen av programmeringsgränssnittet skapade av Doxygen som de definieras på inställningssidan Doxygen-dokumentationssamling.
dockdevtocpluginrc: Innehåller information om de verkliga strukturerade KDevelop innehållsdokumentationsfilerna som de definieras på inställningssidan KDevelop innehållsdokumentationssamling.
docqtpluginrc: Innehåller information om de Qt-dokumentationsfilerna som verkligen ingår på inställningssidan Qt-dokumentationssamling.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
De flesta projektberoende inställningarna bevaras i KDevelops projektinställningsfiler <projektnamn>.kdevelop och <projektnamn>.kdevses istället för i separata filer som andra, mer globala, konfigurationsinställningar. I korthet är de här filerna avsedda för:
<projektnamn>.kdevelop: Global projektinställningsinformation. |
<projektnamn>.kdevses: Inställningsinformation som behövs för att återställa det specifika beteendet hos sessionen som kör. |
Båda filerna är kodade med XML™. De kan visas och ändras (med försiktighet) i vilken texteditor som helst.
Det finns en tredje projektberoende inställningsfil, filen för lagringen av bestående kod <projektnamn>.kdevelop.pcs. Det är en binärkodad fil som innehåller en tolkningscache i huvudsak för att snabba upp laddningssekvensen för projektet. Dessutom innehåller den här bestående kodlagringen information som används av funktionen för kodkomplettering i KDevelop.
Ytterligare filer för bestående kodlagring kan ställas in under fliken Kodkomplettering på den C++ specifika projektinställningssidan. Information om dessa ytterligare .pcs-filer lagras globalt i katalogen $. KDEHOME/share/apps/kdevcppsupport/pcs/
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
KDevelop innehåller ett stort antal små verktyg, som hjälper dig att utföra vissa uppgifter. De flesta fungerar som insticksprogram. Det betyder att om du inte behöver ett insticksprogram kan du helt enkelt inaktivera det.
Det betyder också att om du letar efter funktioner som ska finnas, men inte gör det, kanske de är implementerade i ett insticksprogram och det insticksprogrammet är inaktiverat. Det finns till exempel en funktion för snabböppning i menyn Arkiv, men bara om den är aktiverad i dialogrutan Projekt - Projektinställningar.
Tekniskt är insticksprogram baserade på klassen KDevPlugin definierad i lib/interfaces/kdevplugin.h. Det följande kommer från en kommentar där.
KDevPlugin är basklassen för alla insticksprogram i KDevelop. Ett insticksprogram är en komponent som laddas i KDevelop-skalet vid start eller på begäran. Ett insticksprogram har en omfattning som antingen kan vara:
Kärninsticksprogram är globala insticksprogram som erbjuder någon viktig funktion för "kärnan", och sålunda inte kan väljas av användaren på inställningssidorna för insticksprogram.
Globala insticksprogram är de som bara kräver att skalet är laddad och inte använder sig av gränssnittet KDevProject och/eller använder information rörande hela projektet. Till exempel tillåter insticksprogrammet grafiskt gränssnittsläge utvecklare att välja vilket användargränssnitt de vill använda.
Projektinsticksprogram kräver att att projekt är laddad, och laddas eller laddas ur tillsammans med projektet. Om ett insticksprogram använder sig av projektrelaterad information är det ett projektinsticksprogram. Hantering av Automake behöver till exempel bara vara aktivt när ett projekt baserat på Automake för tillfället är laddat.
Som nämnts ovan kan inte kärninsticksprogram inaktiveras. Globala insticksprogram kan aktiveras eller inaktiveras med -> under . Projektinsticksprogram kan aktiveras eller inaktiveras med -> under . Aktiva insticksprogram kan ge många effekter i KDevelop. Beroende på deras funktion kan de lägga till extra menyer, extra menyalternativ, extra knappar i verktygsraden, etc.
Insticksprogram som är inaktiverade skräpar inte ner menyerna och laddas inte i minnet.
Följande lista över insticksprogram skapas av ett litet skript (listplugins.sh) skrivet av Volker Paul. Alla insticksprogram har en .desktop-fil där information som namn och kommentarer skrivs. Om kommentarerna i det följande inte är särskilt användbara, beror det på att insticksprogrammets upphovsmän gjorde dem på detta sätt.
Insticksprogrammen är grupperade enligt omfattning (Kärna, Global, Projekt).
Omfattning: Kärna
Omfattning: Global
Expansion av förkortningar. Ger stöd för anpassningsbara förkortningar: korta ord som expanderas till vanligt använda kodstrukturer.
Dokumentation. Dokumentationsinsticksprogrammet erbjuder bläddring och sökning i lokal dokumentation och dokumentation på nätet, med stöd för flera dokumentationssystem.
Fillista. Tillhandahåller en lista av alla för närvarande öppna filer. (Praktiskt när flikraden inte är riktigt bred nog.)
Filväljare. Kraftfullt nätverkstransparent filbläddringsverktyg.
Skalfiltrering och infogning. Erbjuder ett sätt att behandla editortext med kommandoradsverktyg. Finns i verktygsmenyn.
Gränssnitt till grep. Integrerar "find | grep" med KDevelop - tillåter snabb sökning i flera filer med mönster eller reguljära uttryck.
Inbäddad terminal. Insticksprogrammet ger KDevelop en inbyggd terminal för snabb och enkel åtkomst av kommandoraden.
Menytillägg till "Öppna med". Insticksprogrammet tillhandahåller ytterligare "öppna" alternativ i diverse sammanhangsberoende menyer i KDevelop.
Delutforskningsverktyg. Ett grafiskt verktyg för att utföra KTrader-liknande förfrågningar om registrerade tjänster.
Test av reguljära uttryck. Verktyg för att skapa och testa reguljära uttryck mot vanlig syntax för reguljära uttryck.
Ersättning. Insticksprogrammet är ett interaktivt verktyg för att "söka och ersätta" i hela projektet. Sök med en sträng eller reguljärt uttryck, och välj ersättningen som ska göras från en förhandsgranskning innan åtgärden slutförs. När det laddats visas det i redigeringsmenyn.
Skriptanvändning. Skriptinsticksprogrammet erbjuder KScript-baserad styrning av programmet KDevelop.
Kodsnuttar. Det här insticksprogrammet gör det möjligt att lagra kodsnuttar och lägga till dem i din kod
Textstruktur. Tillhandahåller en strukturöversikt och navigering för HTML- och Tex-filer
Tillägg i verktygsmenyn. Insticksprogrammet tillhandahåller ett enkelt sätt att lägga till yttre program i verktygsmenyn och verktygsraden.
Valgrind-gränssnitt. Valgrind är ett verktyg som hjälper dig hitta minneshanteringsproblem i program. http://developer.kde.org/~sewardj/
Omfattning: Projekt
Källkodsformatering. Ett insticksprogram för att formatera källkod enligt en given uppsättning regler. När det laddats finns det i verktygsmenyn.
Bokmärken. Insticksprogram som tillhandahåller navigering och översikt över aktiva källkodsbokmärken och gör dem bestående mellan sessioner.
Klassvisning. Insticksprogrammet visar en grafisk bild av alla klasser i ett projekt, tillsammans med metoder och egenskaper, och ger möjlighet till direkt navigering i källkoden.
Kopiera till. Enkelt insticksprogram för uppladdning av filer. Det utför en filkopiering med alla protokoll som stöds av KIO.
Ctags-gränssnitt. Ctags är ett verktyg för källkodsnavigering med stöd för många språk. När det laddats tillhandahåller det en sammanhangsberoende meny för att hitta typdeklarationer eller definitioner, och dessutom en frågedialogruta. http://ctags.sourceforge.net/
Stöd för slutpaketering. Hjälper till att bygga och publicera det färdiga projektet. Endast RPM-paketformatet stöds för närvarande.
Doxygen-stöd. Doxygen-insticksprogrammet tillhandahåller ett sätt att ange och styra hur dokument skapas för ett projekt, baserat på källkodens innehåll. Du måste ha installerat Doxygen för att kunna använda det. För mer information besök http://www.doxygen.org.
Snabböppna. Erbjuder ett effektivt sätt att hitta och öppna filer, klasser och metoder i ett stort projekt. Finns i menyn Arkiv och Verktyg när det laddats.
Så långt den skapade listan över insticksprogram.
Tabell E.1. Insticksprogram för projekthantering i KDevelop
| antproject | ANT-projekthantering (Java™-program) |
| autoprojekt | Automake projekthantering |
| customproject | Egen projekthantering |
| trollproject | Qmake-baserad projekthantering |
Ovanstående insticksprogram är för närvarande (maj 2005) tomma. Kanske projekthanteringsstöd kommer att implementeras som insticksprogram i framtiden.
Tabell E.2. Insticksprogram för språkstöd i KDevelop
| cppsupport | Stöd för C/C++ |
| fortransupport | Stöd för Fortran |
| javasupport | Stöd för Java™ |
| perlsupport | Stöd för Perl |
| phpsupport | Stöd för PHP |
| pythonsupport | Stöd för Python |
Vissa av insticksprogrammen beskrivs i detalj i det följande.
Insticksprogrammet Förkortningar. Det här insticksprogrammet fyller i förkortningar av ofta använda kodfragment. Det aktiveras genom att trycka på Ctrl-Mellanslag. Om du till exempel skriver in "ife" i C++ editorn, och trycker på Ctrl-Mellanslag, får du en if-else kodmall och sparar några tangentnertryckningar. Uppsättningen med förkortningar som stöds beror på den redigerade filens programspråk. För till exempel PHP är du naturligtvis intresserad av andra kodmallar än för Java™.
Uppsättningen med kodmallar kan anpassas. Om insticksprogrammet är aktiverat, kan du se vilka som är tillgängliga med dialogrutan -> under .
Insticksprogrammet filter. Detta erbjuder två funktioner. Om du väljer -> kan du skriva in ett skalkommando. Utmatningen från kommandot infogas i editorns buffer när du trycker på knappen .
En liknande funktion är tillgänglig med ->. För att använda den måste du markera ett textområde i editorn. Om du nu skriver in ett skalkommando och klickar på knappen , startas kommandot och markeringen används som standardinmatning till det. Standardutmatningen från kommandot infogas därefter i editorn, och ersätter markeringen.
Om du till exempel skriver dokumentation, behöver du ofta hänvisa till menyalternativ. För att gör det på rätt sätt för t.ex. kopieringskommandot i menyn Redigera, måste du skriva
<menuchoice><guimenu>Redigera</guimenu><guimenuitem>Kopiera</guimenuitem></menuchoice>Det är omständigt, alltså skriver du hellre bara "Redigera" - "Kopera" och låter datorn utföra taggningen. Du kan göra det så här: Du skriver ett litet skalskript som heter mef, som du till exempel placerar i underkatalogen bin i din hemkatalog:
sed s/"^\(.*\) - \(.*\)\$"/"<menuchoice><guimenu>\1<\/guimenu><guimenuitem>\2<\/guimenuitem><\/menuchoice>"/Glöm inte att göra det körbart. Det är allt. Nu skriver du "Redigera" - "Kopiera" i dokumentationens .dokbook-källkod. Du markerar texten du just skrivit in, väljer -> och anropar ~/bin/mef. Omedelbart ersätts "Redigera" - "Kopiera" med
<menuchoice><guimenu>Redigera</guimenu><guimenuitem>Kopiera</guimenuitem></menuchoice>
Insticksprogrammet Doxygen. Detta hjälper dig att använda API-dokumentationsverktyget Doxygen (http://www.doxygen.org). Du kan välja -> för att skapa API-dokumentation för det nuvarande projektet baserat på konfigurationen som anges av filen Doxyfile i projektkatalogen.
Dessutom kan du anpassa Doxygen med dialogrutan ->. Dialogrutan är mycket lik verktyget doxywizard.
Insticksprogrammet ctags. Även om klassbläddraren ger dig utförlig överblick över symboler och klasser i projektet, kan du också vilja använda ctags-verktyget. Det stöder i synnerhet många fler språk än klassbläddraren.
Du aktiverar insticksprogrammet under ->. När du startar det för första gången, blir du tillfrågad om att först skapa en sökdatabas. När du accepterar detta, startas ctags-programmet och skapar en fil som heter tags i projektkatalogen. Detta är en textfil som innehåller alla symboler i källkodsfilerna.
Du kan söka på två sätt i symboldatabasen: när rutan Matcha med reguljärt uttryck är markerad, tolkas texten som du skriver in som ett reguljärt uttryck (POSIX-varianten) och matchas med befintliga symboler. Texten .*Widget söker till exempel efter alla symboler som slutar med Widget. Om rutan inte är markerad, är sökningen verbatim.
Under sökningen visas en lista med matchade symboler, tillsammans med radnummer där de definieras. Du hoppar till respektive ställe genom att klicka i listan.
För vissa språk skiljer ctags mellan olika typer av symboler. Python har till exempel klasser och funktioner. Du kan söka enbart efter klasser genom att kryssa in motsvarande typ i dialogrutan.
Symboldatabasen uppdateras normalt inte när källkoden ändras. På grund av detta kommer inte radnumren vara riktiga längre efter ett tag, och nytillagda klasser och funktioner kommer att saknas. Därför bör du uppdatera filen tags med regelbundna intervall, genom att trycka på knappen .
Insticksprogrammet A-stil. A-stil är ett insticksprogram för att formatera källkoden enligt en specificerad uppsättning regler.
Insticksprogrammet regexptest. Att konstruera reguljära uttryck kan vara ett hårt arbete. Ofta matchar det första försöket med ett uttryck för många strängar. I synnerhet vid arbete med ett kompilerat språk kan cykeltiden vid avlusning av ett reguljärt uttryck vara besvärlig. Insticksprogrammet regexptest låter dig direkt utforska ändringar i ett reguljärt uttryck. Det aktiveras genom att välja ->.
I variantkombinationsrutan kan du välja vilken variant av reguljära uttryck som ska användas. För närvarande stöds varianten som definieras av POSIX-standarden, som används av programmet grep, och den utökade POSIX-syntaxen som används av programmet egrep.
När du skriver in ett uttryck, får du omedelbart återmatning om eventuella syntaxfel i det. Genom att skriva in en text under Teststräng, kan du se om uttrycket matchar strängen. I synnerhet om det reguljära uttrycket innehåller grupper, som "([a-z])", visas innehållet av de matchade delgrupperna i en listruta.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Innehållsförteckning
Klicka här för att återgå till översikten över lägen.
KDevelop IDEA-fönsterläge
Klicka här för att återgå till översikten över lägen.
KDevelop IDEA-fönsterläge, stängda flikar
Det här skärmbildsexemplet visar en av de huvudsakliga fördelarna med IDEA-läge, att det finns en maximal arbetsyta tillgänglig. Ändå är alla verktygsvyer lätt tillgängliga genom att klicka på motsvarande flik.
Du behöver troligen en viss tid innan du har vant dig vid ikonerna i flikraden. Om du är vilse, placera bara musen över en flik och vänta några sekunder. En beskrivning i form av ett kort verktygstips dyker då upp. På skärmbilden visas verktygstipset “Hantering av automake” som exempel. Det beskriver den nedre fliken i högra flikraden.
Klicka här för att återgå till översikten över lägen.
Klicka här för att återgå till översikten över lägen.
KDevelop underramsläge
Klicka här för att återgå till översikten över lägen.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Klicka här för att återgå till översikten över lägen.
KDevelop fliksidläge
Klicka här för att återgå till översikten över lägen.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Klicka här för att återgå till översikten över lägen.
KDevelop toppnivåläge
Klicka här för att återgå till översikten över lägen.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Snabbtangenterna som visas i det här kapitlet är de förvalda. De kan ändras.
Observera att vissa menyalternativ bara visas när de passar in. I synnerhet är vissa alternativ kopplade till funktioner i insticksprogram som bara är tillgängliga när insticksprogrammet är aktiverat.
Skapa en ny fil. Användaren blir tillfrågad om att välja katalog (förval är nuvarande projekts källkodskatalog) och skriva in ett filnamn. Filtypen kan väljas i en lista. Dessutom kan användaren välja om filen ska läggas till i projektet. Därefter frågar Hantering av automake vilket mål som den nya filen ska läggas till i.
Öppnar en befintlig fil med en enkel dialogruta.
Visar en undermeny med filer som senast öppnades. Att välja en av dem gör att KDevelop öppnar filen.
Visar en lista med filer i det nuvarande projektets källkodskatalog. Användaren kan välja från listan eller skriva in ett filnamn. Filen öppnas därefter.
Sparar nuvarande fil.
Använder dialogrutan Spara som... för att låta dig spara en kopia med ett annat namn.
Sparar alla öppna filer.
Laddar om nuvarande fil för att visa ändringar gjorda av andra program. (Observera att sådana ändringar normalt detekteras automatiskt och användaren blir tillfrågad om filen ska laddas om.)
Återställer alla ändringar i öppnade filer. Frågar om du vill spara ändringar så att återställningen kan avbrytas för varje ändrad fil.
Skriv ut.
Exportera
Stänger nuvarande fil.
Stänger alla öppna filer.
Stänger alla filer utom den nuvarande. Mycket användbart om du öppnade många filer och vill koncentrera dig på den nuvarande. Utan det här skulle du behöva stänga alla och därefter öppna den nuvarande igen.
Observera att det finns ett liknande kommando i menyn Fönster.
Stäng KDevelop.
Ångra
Gör om
Klipp ut
Kopiera
Klistra in
Markera alla
Avmarkera
Blockmarkeringsläge
Överskrivningsläge
Sök
Sök igen
Sök föregående
Ersätt
Gå till rad
Sök i filer
Sök-välj-ersätt
Formatera om källkod
Expandera text
Expandera förkortningar
Komplettera text
Skapa medlem
Tillbaka
Framåt
Byt till...
Höj editor
Nästa fel
Föregående fel
Fullskärmsläge
Byt till deklaration/implementering
Verktygsvyer
Dockning av verktyg
Byt till kommandorad
Schema
Dynamisk radbrytning
Dynamiska radbrytningsmarkörer
Visa/Dölj statisk radbrytningsmarkör
Visa/Dölj ikonkant
Visa/Dölj radnummer
Visa/Dölj rullningslistmarkeringar
Visa/Dölj vikmarkörer
Kodvikning
Ange kodning
Nytt projekt...
Öppna projekt...
Öppna senaste projekt
Aktivt språk
Importera befintligt projekt...
Ny klass...
Arvdiagram för klasser
Lägg till översättning...
Bygginställning
Distribution och publicering
Projektinställningar...
Stäng projekt
Bygg projekt
Bygg aktivt mål
Kompilera fil
Kör configure
Kör automake och besläktade program
Installera
Installera (som systemadministratör)
Rensa projekt
Dist-rensning
Bygg meddelanden och samsortera
Kör program
Bygg dokumentation av programgränssnitt
Rensa dokumentation av programgränssnitt
Stoppa
Starta
Stoppa
Avbryt
Kör till markör
Stega förbi
Stega förbi instruktion
Stega in i
Stega in i instruktion
Stega ur
Växla brytpunkt
Visare
Undersök minnesdump...
Anslut till process
Valgrind kontroll av minnesläckor
Profilera med Kcachegrind
Skrivskyddat läge
Filtyp
Färgläggning
Radslut
Stavning
Indentera
Avindentera
Rensa indentering
Justera
Kommentera
Avkommentera
Stora bokstäver
Små bokstäver
Inledande stor bokstav
Kombinera rader
Bryt rader mellan ord i dokumentet
Visning av skillnader...
Kör kommando...
Filtrerar markeringen genom ett externt kommando genom att använda filterinsticksprogrammet.
Avlusa reguljärt uttryck...
Delutforskare
Snabböppna klass...
Snabböppna metod...
Förhandsgranska utmatning från Doxygen
Dokumentera nuvarande funktion
Visa/Dölj menyraden.
Öppnar en undermeny där du kan välja att visa eller dölja de olika verktygsraderna.
Visa statusraden.
Anpassa genvägar...
Anpassa verktygsrader...
Anpassa meddelanden...
Anpassa editor...
Anpassa KDevelop...
Visa det här dokumentet.
Ritar ett frågetecken (?) intill muspekaren. Att klicka på ett objekt i ett fönster som knappen Stoppa visar då en kortfattad förklaring.
Dagens tips
Titta i dokumentationsindex...
Sök i dokumentationen...
Manualsida...
Infosida...
Rapportera fel.
Visa en del kortfattad information om KDevelops versionsnummer, upphovsmän och licensavtal.
Visa en del information om versionen av KDE som du kör.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Innehållsförteckning
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Den här dokumentationen licensieras under villkoren i GNU Free Documentation License.
Det här programmet licensieras under villkoren i GNU General Public License.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Innehållsförteckning
2003-01-03 Bernd Gehrmann, Caleb Tennis
ursprunglig layout av handbok
disposition för innehållet i många kapitel
2004-08-01 Bernd Pol, Ian Wadham
handboken något omorganiserad
några saknade kapitel skrivna
2005-05-02 Volker Paul — Många ändringar, inklusive:
delad i en fil per kapitel och appendix
tillägg av kommandoreferens sorterad enligt meny (beskrivningar ännu inte fullständiga)
handledning för programguiden i getting-started.docbook
omorganisering av kapitel, inspirerad av Konquerors handbok
flyttade Installation, Utveckling på Unix, “I korthet” till appendix
skrev om appendix om insticksprogram, inklusive generering av insticksprogramlista med listplugins.sh
Fortfarande långt ifrån komplett, men ett litet steg framåt.
2006-05-20 Bernd Pol — Fyllde i några flera hål med “ännu inte skrivet”:
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Innehållsförteckning
(... ännu inte skrivet ...)
GNU Autoconf, Automake, and Libtool. 1st edition. October 2000. New Riders Publishing. ISBN 1578701902.
Advanced Programming in the UNIX® Environment. 1st edition. June 1992. Addison-Wesley Pub Co. ISBN 0201563177.
Thinking in C++, Volume 1: Introduction to Standard C++. 2nd Edition. April 15, 2000. Prentice Hall. ISBN 0139798099.
Open Source Development with CVS. 2nd Edition. October 12, 2001. The Coriolis Group. ISBN 158880173X.
Programming PHP. 1st edition. March 2002. O'Reilly & Associates. ISBN 1565926102.
Programming Python. 2nd Edition. March 2001. O'Reilly & Associates. ISBN 0596000855.
Gui Programming With Python : Using the Qt Toolkit. Bk&Cd-r edition. January 2002. Opendocs Llc. ISBN 0970033044.
Programming Perl. Kamelboken. 3rd Edition. July 2000. O'Reilly & Associates. ISBN 0596000278.
Learning Perl. Lamaboken. 3rd Edition. July 15, 2001. O'Reilly & Associates. ISBN 0596001320.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team