%ISOnum; Gtk--"> Gtk"> GNU"> C++"> C"> %examplelist; ]> Studrer nat MarcusBrinkmann Marcus studerar matematik och and samlar erfarenheter av Linux sedan början av 1996. TeroPulkkinen Tero underhåller och utvecklar >kmm;. En omfattande och lättförståelig guide till det lovande grafiska användargränssnittet >kmm;. 0.1 Juni 1998 M.B. Ursprunglig utgåva. 1998Marcus Brinkmann Det är tillåtet att kopiera och distribuera ordagranna kopior av denna manual förutsatt att copyrighten och denna tillåtelse finns med på alla kopior. Det är tillåtet att bearbeta denna fil med TeX och andra textbearbetningssystem (till exempel DSSSL-motorer) och att skriva ut resultaten, förutsatt att det utskrivna dokumentet innehåller en kopieringstillståndet identiskt med detta bortsett från uteslutandet av denna paragraf (eftersom denna paragraf inte är relevant för den utskrivna manualen). Det är tillåtet att kopiera och distribuera modifierade versioner av denna manual under samma förhållanden som för ordagrann kopiering, förutsatt att hela resultatet av arbetet distribueras med villkor som är identiska med dessa. Det är tillåtet att kopiera och distribuera översättningar av denna manual till andra språk, under ovanstående villkor för modifierade versioner, med undantag gjort för att dessa villkor kan vara i en översättning som är godkänd av den ursprungliga copyright-innehavaren. Exempelprogrammen är allmän egendom. Följande adress finns här endast i informativt syfte.

Free Software Foundation, Inc. 59 Temple Place - Suite 330 Boston, MA 02111-1307 USA

Med Linux finns ett stort urval av applikationer till ingen eller lågt pris, och många av dem är av hög kvalité. Tyvärr är avsaknaden av dokumentation i stor kontrast till detta. Anledningarna är enkla att se: För de flesta utvecklare är programmering mycket roligare än att förklara det tydligt uppenbara. För mig är programmering i &cxx; i >kmm;-miljö nytt och långt ifrån uppenbart, och jag hoppas att nedskrivandet av de grundläggande principer jag förstått längs vägen kommer att hjälpa mig att klargöra mitt tänkande och hjälpa andra att förstå det lättare. Om du har några rättningar, anmärkningar, frågor eller svar om detta dokument, tveka inte att kontakta mig. Min adress är:

Marcus Brinkmann Marcus.Brinkmann@ruhr-uni-bochum.de

Anmärkningar gällande den svenska översättningen kan skickas till:

Fredrik Liljegren cof@ebox.tninet.se

Idag kan mjukvara interagera med användaren på många sätt, och det är inte en lätt uppgift för programmeraren att besluta vilka in- och utdataenheter han skall stödja. Standarder och abstrakta gränssnitt kan vara till stor hjälp för att göra detta beslut mindre viktigt, eftersom många enheter kan användas på ett unikt sätt, åtminstone från programmerarens ståndpunkt. Under Linux, till exempel, finns det ingen anledning att bry sig om informationslagringsenheter, eftersom kerneln tillhandahåller ett filsystem som ett abstrakt gränssnitt och ett bibliotek förser oss med ett rent sätt att komma åt filsystemet. Dock finns det fortfarande tillräckligt många sorters utdata som varierar på ett mer fundamentalt sätt. Det är till exempel sannolikt av viss vikt huruvida utdatan består av endast text (och med text menar jag ett bokstavsflöde kodat i någon standard såsom ANSI), eller om utdatan är grafisk (bestående av pixlar). Situationen blir ännu mer förvirrande när programmeraren måste skriva ett användargränssnitt för interaktiv kommunikation med användaren. Det finns många indataenheter tillgängliga, alltifrån en mängd tangentbord, musar, pads, och det slutar inte med röstigenkänning. Programmeraren kan också använda olika sätt att presentera möjligheterna med vilka användaren kan kontrollera applikationen. Det finns standardprotokoll för in- och utdataenheter, och programmerare kan använda dem för att vara oberoende av det faktiska läget av in- och utdataenheter. Det finns dock flera bibliotek tillgängliga som förser ett konsekvent grafiskt användargränssnitt (GUI, Graphical User Interface). Det är önskvärt att alla program använder samma användargränssnitt för att göra situationen mindre förvirrande för användaren, men det nuvarande läget är långt ifrån detta ideal. Att skriva ett utbyggbart, konsekvent användargränssnitt av hög kvalité som går att porta, och kan användas för att skriva X-applikationer på ett bekvämt sätt är målet med >k;-projektet. Det är skrivet i och för &c;, och många kända särdrag från objektorienterade programspråk var tvungna att återimplementeras i &c;. >kmm; tillhandahåller ett omslag kring >k; för användning i &cxx;, och har fördelarna med en typsäker miljö (till och med för signaler) och integrerade objektorienterade möjligheter såsom arv för utbyggnaden av >k;s möjligheter. Det finns vissa saker du behöver innan du ens kan börja jobba med >kmm;, men även saker som du kommer att behöva lära dig sida vid sida med >kmm; om du inte redan känner till dem. Annars kommer du knappast lyckas med att skriva bra mjukvara, oavsett hur bra redskap eller bibliotek du använder. Var dock försiktig och ta inte orden i detta kapitel för bokstavligt. Det är osannolikt att jag verkligen vet precis vad förutsättningarna är. Fri programvara utvecklas snabbt för tillfället, och fakta är inaktuella efter kort tid. Av denna anledning kommer vissa förutsättningar inte att skrivas ut tydligt utan avsiktligt vara otydliga. Vänligen se den senaste dokumentationen som kommer med mjukvarupaketet för mest aktuell information. Du behöver en plattform som stöds av >k;, en komplett >k;-installation och >kmm;. Förmodligen tillhandahåller distributionen du använder binära paket. I så fall är allt du behöver göra att installera de lämpliga paketen för utveckling med >k; och >kmm;. Om du måste bygga paketen själv av någon anledning, skaffa de senaste källkodspaketen via anonym ftp. Tack vare autoconf bör byggande och installerande vara enkelt. Efter byggande och installerande av biblioteken kan du länka in dem i applikationer som använder >kmm;. Lägg märke till att >kmm;s biblioteksnamn kommer att vara libgtkmm eftersom streck i biblioteksnamn kan vara förvirrande för systemverktygen. Vidare, du behöver en fungerande &cxx;-kompilator. En bra kompilator är gcc, &gnu;s &c;/&cxx;-kompilator. Du måste veta hur man kompilerar och länkar program skrivna i din miljö. På en Linux-plattform kan man till exempel kompilera och länka ett program stardust.cc med gcc med ett kommando: $ g++ -o stardust stardust.cc -lgtkmm `gtk-config --cflags` `gtk-config libs` Den sista delen behövs dock bara om ditt system inte klarar beroenden mellan delade bibliotek korrekt. På vissa system kan du klara dig utan anropet för 'gtk-config libs'. Jag behöver mer information här. ZippyBarn, de sju basala matgrupperna är TUGGUMMI BLOSS, BAKVERK, PIZZA, PESTICIDER, ANTIBIOTIKA, NUTRA-SWEET och SURMJÖLK!! Det finns ett minsta möjliga &cxx;-program som använder >kmm;. Vänligen beakta följande kod; &shortest-program; Den första raden inkluderar de klasser och mallar från vilka du kan härleda dina objekt och signaler. Den tredje raden är deklarationen av funktionen main(). main Detta är den funktion som anropas när programmet är kompilerat och körs. Varje program måste inkludera en och endast en main()-funktion, som skall returnera en värde av typen "int" som returneras till skalet (programmets felvärde). Skalet ger två parametrar till main(), ett int-värde (här kallat argc) och en pekare till en lista av standard &c;-strängar. Det förra är ett tal som är ett högre än antalet argument givet till programmet på kommandoraden, det senare är den kompletta kommandoraden nedbruten i programnamnet (argv[0]) och argumenten (argv[1] till argv[argc-1]). Raderna 4 till 12 är definitionen av main-funktionen. Detta är den kod som faktiskt exekveras. På rad 5 är variabeln eventLoop av typen Gtk_Main deklarerad och definierad. Gtk_Main är den viktigaste klassen i >kmm;. Varje >kmm;-program måste ha en förekomst av klassen Gtk_Main, som handhar signalerna och programflödet. Det finns precis en konstruktör för Gtk_Main, och denna förväntar sig två argument. Dessa är pekare till de två argumenten givna till main-funktionen av skalet. Anledningen är att Gtk_Main kommer plocka ut >kmm;-specifika argument från kommandoraden. Dessa kommer att tas bort och behandlas. Efter att alla väsentliga >kmm;-objekt är konstruerade och initialiserade (här i rad 7 och 8) så kommer programmets flöde att överlämnas till >kmm; genom anrop av Gtk_Main-objektet eventLoops metod run() (rad 10). Så småningom kommer >kmm; att återlämna kontrollen till main-funktionen, och då returnerar main framgång (rad 11). I detta enkla exempel skapas bara ett synligt >kmm;-objekt, objektet helloWorldWindow av typen Gtk_Window. Efter konstrueringen kommer fönstret inte att förverkligas. För att bygga och göra det synligt måste man anropa medlemsmetoden show(). Detta är sant för alla synliga >kmm;-objekt. I vårt exempel händer detta på rad 8. Pröva programmet med och utan rad 8 så ser du skillnaden. Om du kör programmet så kommer du att se ett fönster med standardstorlek (200x200) och med samma titel som programmets namn på kommandoraden. Standardstorleken används bara om fönstret är tomt (om det inte innehåller några barnobjekt), eftersom ett fönster med storleken 0x0 är svårt att påverka eller ens se. Vidare kommer du se att programmet inte avslutas, ens om det får stängningssignal från din fönsterhanterare. Så är det på grund av att vi inte har tagit med signalhantering ännu, och det kommer vi inte göra än på ett tag. Vänligen avbryt programmet med CtrlC eller förstör fönstret. Vi kan redan ändra några av helloWorldWindows egenskaper, till exempel titelsträngen eller minsta storleken. Följande kropp kommer exempelvis att ändra båda på en gång; Gtk_Window helloWorldWindow; helloWorldWindow.set_title("Hello, world!"); helloWorldWindow.set_usize(200,20); helloWorldWindow.show(); Gtk_Window-klassen tillhandahåller en metod, set_title(char *), för att ändra fönstrets titel. Om du dock ser till huvudfilen eller dokumentationen så kommer du märka att Gtk_Window inte tillhandahåller nån metod set_usize(gint width, gint height), som ställer in widgetens storlek. set_usize tillhandahålls av Gtk_Widget, och Gtk_Window är en klass med Gtk_Widget som ursprung. Du ska alltid hålla i tankarna att du också kan använda medlemsmetoder från föräldraklasser för att ändra dina >kmm;-objekts egenskaper. Sättet som din fönsterinstans hanteras av fönsterhanteraren kan ändras av en variabel av typen GtkWindowType, given till Gtk_Windows konstruktör. Det finns tre möjliga värden: GTK_WINDOW_TOPLEVEL (standard), GTK_WINDOW_DIALOG och GTK_WINDOW_POPUP. För att få reda på vad de gör, ändra rad 7 i exemplet till något likt: Gtk_Window helloWorldWindow(GTK_WINDOW_TOPLEVEL); och byt sedan ut GTK_WINDOW_TOPLEVEL mot någon av de andra två möjligheterna.Du kommer att få se att fönster av typen GTK_WINDOW_TOPLEVEL hanteras helt och hållet av fönsterhanteraren. Vidare kommer du få se att fönster av typen GTK_WINDOW_DIALOG saknar några handtag (till exempel storleks- och stängningsknapparna) och att fönster av typen GTK_WINDOW_POPUP inte hanteras alls av fönsterhanteraren (ingen ram, inga knappar). Låt oss nu gå över till ett annat >kmm;-objekt, widget-klassen Gtk_Label. Konstruktören ber om en const char* som innehåller etikettens namn. Betänk detta exempelprogram: &label-widget; De flesta delarna av det här programmet är redan förklarade, bara raderna 7, 8 och 11 är nya. Om du kompilerar och kör detta exempel så kommer du inte att få se ett fönster som är av standardstorleken 200x200, utan ett fönster som har precis den storlek som behövs för att innehålla texten "Hello, world!". Vanligtvis kommer en widget att ha en standardstorlek för att precis få plats med den barn-widgeten den innehåller. En widget kan läggas till fönstret med medlemsmetoden add(Gtk_Widget*). Då detta kräver att en pekare till widgetten läggs till så ger vi Gtk_Label-widgettens pekare som parameter. Lägg märke till att add() är en medlemsmetod i klassen Gtk_Container, i vilken Gtk_Window har sitt ursprung, inte i Gtk_Window själv. Som du kommer att få se senare så kan de använda detta tillvägagångssätt för att lägga till en widget i alla behållare, inte bara fönster. Som redan nämnts så måste vi göra etiketten synlig med medlemsmetoden show(). Lägg märke till att vi först kan visa etiketten med show() och därefter fönstret. Om du ändrar ordningen så kommer du först att få se det tomma fönstret och sedan se etiketten ritas upp. I de flesta fall så är det att föredra att rita upp widgetten internt för att sedan som sista steg göra fönstret synligt. Klassen Gtk_Label har två medlemsmetoder, set(const gchar* str) och get(gchar** str) så att du kan ändra etiketten och se vad den läser. Vänligen kom ihåg att klassen Gtk_Label har sitt ursprung i andra klasser, och att du kan använda medlemsmetoder från föräldraklasser för att ändra andra egenskaper hos Gtk_Label. Till exempel kan du ändra etikettens minsta storlek med medlemsmetoden set_usize(gint, gint) i klassen Gtk_Widget. Etiketter är ganska tråkiga, eftersom de är passiva. Om du vill interagera med användaren så kommer du säkerligen vilja ha knappar med i din applikation. För detta ändamål finns Gtk_Button som liknar Gtk_Label. Gtk_Button-klassen är dock mer komplex, då den är en behållare (den har sitt ursprung i Gtk_Container-klassen), så du kan lägga till en etikett, lite grafik eller vad du vill. Widgetar läggs till en knapp på samma sätt som till ett fönster, med medlemsmetoden add(Gtk_Widget *). Om du bara vill lägga till en etikett till en Gtk_Button-behållare så kan du ge textsträngen till konstruktören för Gtk_Button. Detta är en bekväm och vanlig förkortning. Det innebär att följande kodbitar är ekvivalenta: Gtk_Label someLabel("Hello, world!"); someLabel.show(); Gtk_Button someButton; someButton.add(&someLabel); someButton.show(); är det svåra sättet att åstadkomma: Gtk_Button someButton("Hello, world!"); someButton.show(); Det finns för tillfället inget sätt att komma åt etiketten skapad av Gtk_Button(const gchar*), så du måste använda den genomförliga formen om du vill arbeta med den, exempelvis om du vill ändra knappens text. Ändra så att "Hello, world!"-exemplet använder en knapp istället för en etikett och försök köra det. Du kommer att få se att knappens färg ändras om du rör muspekaren över den och om du klickar på den, men inget annat händer. Det är möjligt att få något att hända, och detta är meningen med signaler. Signaler sänds ut av >kmm; när något intressant händer, till exempel när ett fönster ändrar storlek eller när en knapp blir nedtryckt. Du kan koppla dessa signaler, vilket innebär att du kan sätta en funktion till kön av funktioner som ska bli kallade när en signal sänd ut. Du kan koppla flera funktioner till en och samma signal, och du kan sätta samma funktion på flera signaler. Hur som helst, funktionens returvärde och argument måste stämma överens med signalens returvärde och argument. Beakta följande program som är en lång variant av övningen i föregående avsnitt: &signal-1; Lägg märke till avsaknaden av show()-anrop för Gtk_Label-, Gtk_Button- och Gtk_Window-elementen. De är ersatta av ett enda anrop av medlemsmetoden show_all() i Gtk_Window-objektet helloWorldWindow. show_all() är en användbar och vanlig förkortning, den anropar show() för widgeten själv och för alla element den innehåller. show() och show_all kommer diskuteras genomförligare senare i denna studiehandledning när vi talar om behållare. Vi vill få något att hända när knappen trycks ned. Vi vill till exempel ändra etikettens text (och detta är anledningen till att vi inte gav texten till knappens konstruktör). För att kunna göra detta måste >kmm; lägga märke till oss nät knappen trycks ned. Detta gör det genom att göra ett funktionsanrop. Tja, det är lite mer invecklat i verkligheten, men för tillfället räcker det med att tänka på signaler som funktionsanrop som görs av >kmm; som reaktion på en händelse. Det finns bara en sak kvar att göra för vårt program, det måste berätta för >kmm; vilken funktion som skall anropas när vilken aktivitet inträffat i vilket element. Detta gör man med connect_to_function. För att prova den, vänligen lägg till följande funktion till ovanstående exempel, och lägg även till anropet connect_to_function till main-funktionen. 2a static void changeLabel(Gtk_Label& theLabel) 2b { 2c static bool flag=true; 2d 2e flag = !flag; 2f flag ? theLabel.set("Bye, bye!") 2g : theLabel.set("Hello, World!"); 2h } 11a connect_to_function(helloWorldButton.clicked, &changeLabel, helloWorldLabel); changeLabel använder en statisk variabel av bool-typ för att lagra etikettens nuvarande status (vi skulle också kunna fråga den med Gtk_Labels medlemsmetod get, men det skulle kräva en strängjämförelse, en meningslöst tillkrånglande i detta lilla exempel) och ändrar etikettens text när den blir anropad. connect_to_function-funktionens anrop kräver en del förklaring. Vanligen tar connect_to_function två argument. Det första är signalen du vill koppla till, och det andra är funktionen du vill koppla till signalen. Ett valfritt tredje argument kommer att skickas vidare till den kopplade funktionen när signalen sänds ut. I vårt exempel så sänds signalen helloWorldButton-clicked ut när knappen blir klickad (med andra ord nedtryckt och uppsläppt) och changeLabel(helloWorldLabel) anropas. Om det tredje av argumenten till connect_to_function utelämnas så skickas inget argument vidare. Du kan koppla så många funktioner som du vill till en signal, de anropas den ena efter den andra. Dessutom kan du inte bara koppla funktionsanrop till en signal, utan också medlemsmetoder av en klass instansen och till och med andra signaler. Signaler kontrollerar flödet i ett interaktivt program. Fram till nu så har varje objekt av klassen Gtk_Container bara haft ett Gtk_Widget-objekt i sig (till exempel ett fönster med en etikett på). Uppenbarligen är inte detta tillräckligt i de flesta fall. Det barnsliga sättet att lägga till en andra etikett skulle förmodligen bli något likt följande: &packaging-1; Vänligen försök kompilera och köra detta exempel. Blir du förvånad? Du kommer att se precis samma utdata som om raderna 9 och 13 inte hade varit där. Att byta plats på raderna 12 och 13 kommer bara att visa den andra texten "Bye, world!", men inte "Hello, world!". Även om detta inte verkar vettigt vid första anblicken så kommer du snart komma på varför det finns starka skäl för detta beteende. Det handlar helt och hållet om placering. Det finns en vettig standard för placering av en ensam widget i en behållare (den är centrerad), det finns ingen uppenbar placering att föredra för mer än en widget. De skulle kunna bli placerade vertikalt eller horisontellt, vänster-, högerjusterade eller centrerade. Placeringen kunde också bli olika för varje widget, till exempel några högst upp i behållaren och andra till höger. Eftersom placering av widgettar är en så komplex uppgift så finns det många olika sätt att göra det. Därför är det förbjudet att placera mer än ett objekt i en behållare, och >k; kommer klaga med ett felmeddelande vid körning. Det lättaste sättet att placera widgettar är att placera dem i en rad (horisontellt) eller i en kolumn (vertikalt). För detta finns det två klasser i >kmm;, klassen Gtk_HBox och Gtk_VBox. Eftersom båda klasserna förser oss med väldigt lika funktionalitet så har de sitt ursprung i en gemensam bas, klassen Gtk_Bok, som aldrig används direkt. För följande förklaring används Gtk_HBox som exempel, men samma saker är sanna även om Gtk_VBox, eftersom gränssnittet tillhandahålls av Gtk_Box, inte av en av underklasserna. Huvudidén är att lägga till en box i behållaren, och sedan lägga till widgettarna i boxen. För detta ändamål har Gtk_Box två metoder, pack_start(Gtk_Widget*) och pack_end(Gtk_Widget*). pack_start lägger till widgetar i början av boxen i riktning emot slutet, medan pack_end börjar i slutet av boxen och går emot början. Därför är ordningen metoderna anropas i viktig. Ett enkelt exempel visar båda sätten att lägga till widgetar i en box. &packaging-2; Om du provar det här exemplet så bör du ändra fönstrets storlek för att tvinga fram en annan placering. Då en Gtk_HBox har en annan standardstorlek för att passa summan av standardstorleken på de widgetar den innehåller, kommer du inte att se den annorlunda placeringen av widgetarna förrän storleken ändrats. Vänligen lägg märke till skillnaden i ordning mellan anropen på rad 14 till 17 i pack_start och pack_end. En Gtk_Bok är en osynlig box, vilket innebär att den inte lägger till något synligt till behållaren den läggs till i. Du måste ändå anropa show() för att göra widgetarna den innehåller synliga. show gör bara en widget synlig för dess direkta förälder. Om den ska visa sig i ett fönster så måste alla widgetar på vägen ner till den vara synliga också. Detta är verkligen ett utmärkt exempel på varför show_all() är en fantastisk bekvämlighet för programmeraren. Du kan nästa flera horisontella och vertikala boxar för att nå en bättre kontroll över placeringen. Du kan också lägga till andra widgetar till en box än etiketter. Du kan justera elementens placeringen i en box, men det är ämnet i en senare del i denna studiehandledning. Såhär långt bör läsaren redan ha blivit ganska bekantade med >kmm;. Det är ett bra tillfälle nu att summera alla >kmm;s finesser som presenterats i de föregående delarna med ett komplexare exempel. Programmet nedan kommer att visa en lista med tre bockknappar, var och en med namnet på en basfärg på (röd, grön och blå (engelska: "red", "green" och "blue")). Användaren kan bocka av av på färgerna med ett klick på bockknappen och programmet kommer räkna ut den resulterande färgen som blir genom att blanda de förbockade färgerna. En bockknapp tillhandahåller en behållare tillsammans med en liten bockruta till vänster. Denna bockruta kan växlas med ett musklick för att indikera om saken skall vara på eller av. En bockknapp tillhandahålls a klassen Gtk_CheckButton. För din bekvämlighet tillhandahålls en standardkontruktör som tar emot en sträng (liknande Gtk_Button). Då Gtk_CheckButton har sitt ursprung i Gtk_Button kan alla signaler och medlemsmetoder du redan kan användas. Dessutom kan du fråga efter dess nuvarande tillstånd med bool get_state() och du kan ställa in det med void set_state(bool state). En signal, toggled, sänds ut närhelst dess nuvarande status ändras. Ett enkelt program visar dig hur denna knapp kan användas. Det innehåller också allting du lärt dig tidigare, så om du har svårt att förstå det, gå tillbaka och läs igen från början av handledningen. En funktion förväntas du dock inte vara bekant med. Det är anropet till connect_to_method, som används för att koppla ihop en medlemsmetod med en signal. För tillfället räcker det att veta att detta anrop används för att köra updateColor() närhelst en bockknapps status ändras. &checkbutton; Du måste ha märkt att programmets design ändrats grundligt från den använd i tidigare exempel. Tidigare hade vi alla objekt i huvudfunktionen, vilket var vettigt eftersom vi hade relativt få widgetar. Med ett ökat antal objekt att hantera behöver vi en mer sofistikerad design. Det är en bra idé att skilja widgetarna åt genom platsen de dyker upp på i programmet. Till exempel kan du skapa separata klasser för varje fönster som används i ditt program. Även boxar och andra saker kan dock ses som separata enheter. Ofta finns det flera möjliga och bra lösningar. I vårt fall har jag valt att göra en klass ColorMix som representerar innehållet i vårt fönster. På detta vis kan vi använda objektet ColorMix på andra platser, till exempel som en del av ett större fönster. En annan mycket viktig designfråga är användningen av arv. Eftersom klassen ColorMix har sitt ursprung i Gtk_HBox så blev det verkligen i sig själv ett >kmm;-objekt! I det exemplet ovan kan man se hur enkelt >kmm; kan utökas med komplexare widgetar. Det är sant att ColorMix är för specialiserad för att vara särskilt användbar i andra sammanhang, men det är lätt att se att detta inte är för nåt begränsande av arvmöjligheterna. Om du använder konstruktörer som tar emot lämpliga parametrar så kan du enkelt skapa dina egna abstrakta widgetar och andra >kmm;-objekt. Menyer är en väsentlig del av varje användarapplikation. De förser oss med snabb tillgång till programmets huvudsakliga egenskaper. Menyer organiseras i undermenyer, vilka koms åt via en menylist, vanligen placerad högst upp i fönstret. Menyföremål kopplas till funktioner med signaler: Om en användare väljer något i en meny så sker en händelse och lämplig signal sänds ut. Du kan koppla ihop en eller flera funktioner med denna signal för att få något att hända genom menyn. Ett vanligt sätt att svara på ett menyval är att öppna ett dialogfönster, men även direkta händelser kan vara lämpliga. Du kan bygga upp menyer direkt av >kmm;-widgetarna, men detta är omständligt då en massa overhead är inblandat i implementeringen av de nödvändiga objekten. För specialfallet menyer tillhandahåller >kmm; ett bättre sätt att skapa den uppsättning widgetar som krävs. Detta system kallas MenuFactory. TOMT &ch-creating-new-widgets-sv; Denna del av studiehandledningen innehåller en komplett klassreferens för >kmm;. Varje klass och dess medlemsmetoder listat här tillsammans med de signaler du kan koppla dem till. Denna referensbok skapas direkt från det nuvarande >kmm;-källkodsträdet och är oöversatt. Program som används för att skapa referensboken. Du kan använda denna referensbok under din gång genom studiehandledningen och medan du programmerar applikationer. Om utdataformatet tillåter det så är klasserna i studiehandledningen länkade till noteringen i denna referens när de uppträder. &referencebook;