Nicolas Goutte goutte@kde.org In &kde; kunnen de configuratiebestanden eenvoudig met een tekst-editor, zoals &kate;, bewerkt worden, omdat het gewone tekstbestanden zijn. Een voorbeeld van een configuratiebestand: [General] AutoSave=1 LastFile=/var/tmp/test.txt De gebruikersspecifieke configuratiebestanden worden opgeslagen in .kde/share/config (vervang .kde door uw $TDEHOME instelling) en de globale configuratiebestanden bevinden zich in de submap share/config van het installatiepad van &kde;. (U kunt dit pad vinden door het commando tde-config --prefix uit te voeren.) De bestandsnamen eindigen op rc (zonder een punt ervoor), bijvoorbeeld kopeterc. De stabiliteit van uw &kde;-installatie kan gevaar lopen wanneer u de bestanden handmatig bewerkt. Toepassingen controleren de de gegevens in de configuratiebestanden niet. Dit betekent dat er storingen kunnen optreden en dat toepassingen kunnen crashen. De eerste regel is dus: maak een reservekopie van het bestand voordat u het gaat bewerken. Deze reservekopie kunt u beter niet in één van de submappen van .kde (of de map die overeenkomt met $TDEHOME) opslaan. Het is in het algemeen een goed idee om reservekopieën te maken voor het geval er iets fout gaat met &kde; waardoor u uw belangrijke configuratiebestanden kwijtraakt (bijvoorbeeld de instellingen voor &kmail; in het bestand kmailrc). Zo'n grote storing zou niet voor moeten komen, maar het kán een keer gebeuren. Maar waarom zou u eigenlijk iets aan de configuratiebestanden willen doen? Als u de KIOSK-modus wilt doorvoeren, zult u het wel moeten. Misschien heeft een ontwikkelaar u gevraagd om een item toe te voegen dat hem kan helpen een probleem met de toepassing op te lossen. Misschien wilt u na een storing de bestanden herstellen zonder de complete map .kde te hoeven verwijderen. Misschien wilt u wel iets meer te weten komen over de verborgen mogelijkheden van &kde;. De reden doet er niet toe, u wilt handmatig een configuratiebestand wijzigen. Wanneer u zo'n bestand wilt bewerken, zorg dat eerst dat de toepassing dat dat bestand gebruikt niet draait. In het geval dat het één van de basisconfiguratiebestanden is, kunt u er het beste voor zorgen dat &kde; helemaal niet draait. Klaar? Maak een reservekopie van het bestand (Had ik dat al gezegd?), start uw favoriete editor (laten we aannemen dat dit &kate; is) en open het bestand. Zorg ervoor dat het bestand als UTF-8 geladen wordt, &kate; laat dit zien als uft8 Nu hebt u een bestand als: [Group] Key1=Value1 Key2=Value2 Key3=Value3 U kunt het bestand nu wijzigen (pas op voor typfouten!) en opslaan. (Zorg ervoor dat het weer als UTF-8 opgeslagen wordt.) Nu kunt u de toepassing testen. Als deze niet goed meer werkt, sluit de toepassing dan af en zet de reservekopie van het configuratiebestand weer terug. bevat meer informatie over de mapstructuur van &kde;, dit kan u helpen om het bestand te kunnen vinden dat u moet bewerken. &kde; biedt een krachtig communicatiesysteem, dat tussen processen werkt: &DCOP;, het Desktop COmmunication Protocol. Met &DCOP; hebt u controle over een groot aantal functies in &kde;, vanaf de commandoregel of met een script in u favoriete scripttaal. U kunt ook informatie vanuit &kde;-toepassingen krijgen, verscheidene mediaspelers beschikken bijvoorbeeld over methoden om informatie op te vragen over het bestand dat momenteel afgespeeld wordt. Ruwweg gezegd heeft elke &kde;-toepassing één of meer &DCOP;-interfaces, die op hun beurt methoden (of functies) bieden die door een andere toepassing aangeroepen kunnen worden. De eerste stap om &DCOP; te gebruiken is het vinden van de juiste methode voor de taak. De gemakkelijkste manier om dit te doen is door middel van de kdcop-frontend voor de beschikbare &DCOP;-methoden. Start kdcop vanuit een &konsole; of vanuit de mini-CLI (het dialoogvenster dat na het indrukken van &Alt;F2 verschijnt). Het venster van kdcop laat de actieve toepassingen die &DCOP;-interfaces bieden in een boomstructuur zien. In het algemeen zult u in de boomstructuur moeten zoeken om de juiste methode te vinden. Het is nuttig om te weten dat de interface waar (default) bij staat gewoonlijk de meestgebruikte functies bevat. Dubbelklik op het item SetColor om te testen of de functie doet wat we verwachten. Om de kleur c in te stellen, klikt u op de selectieknop en kiest u een kleur. Bepaal of de kleur al dan niet A moet zijn met het keuzevakje. Klik op OK, de achtergrondkleur is ingesteld Om de toegang te krijgen tot de &DCOP;-methode vanuit uw favoriete scripttaal gebruikt u &DCOP;-"bindings", als deze beschikbaar zijn in de module "tdebindings", of u gebruikt de commandoregel en roept de toepassing dcop aan. De commandoregeltoepassing dcop voldoet voor eenvoudige functies. Om een &DCOP;-methode op de commandoregel aan te roepen moeten we de toepassing en de interface voor de methode, de methode zelf en de argumenten specificeren in een vorm die geaccepteerd wordt door de shell. We specificeren de toepassing, interface en methode in deze volgorde, gevolgd door de argumenten in dezelfde volgorde zoals ze in kdcop staan. dcop heeft een groot aantal opties: de uitvoer van dcop --help laat een lijst van opties zien. Genoeg theorie, tijd voor een voorbeeld: Met behulp van de toepassing dcop en een beetje Perl gaan we een eenvoudig script maken dat de achtergrondkleur van het bureaublad langzaam door het spectrum roteert. Eerst zoeken we in kdcop naar de juiste methode. Voor dit voorbeeld gaan we rechtstreeks naar kdesktop KBackgroundIface setColor. De argumenten en het teruggegeven type van de functie worden in de stijl van C++ gegeven. Voor setColor zijn de argumenten een kleur, c, die de nieuwe achtergrondkleur specificeert, en een logische waarde (true of false), isColorA, die specificeert of het de eerster of tweede kleur is (dit wordt gebruikt om kleurverlopen in te stellen). Om de methode setColor op de commandoregel te gebruiken moeten we het volgende typen: % dcop kdesktop KBackgroundIface setColor '#ffffff' false Om de kleur te specificeren gebruiken we de hexadecimale RGB-waarde, net als in &HTML;. Opmerking: de waarde staat binnen enkele aanhalingstekens zodat # niet door de shell geïnterpreteerd zal worden. De hexadecimale RGB-waarde kunt u in elke &kde;-toepassing in het dialoogvenster "Kleur selecteren" vinden (bijvoorbeeld in &kcontrolcenter;, Uiterlijk & thema's Kleuren), selecteer de gewenste kleur en gebruik de waarde die in het tekstvak HTML staat. Meer hebben we niet nodig van &DCOP;, nu hoeven we alleen het script te schrijven. Hier is een (zeer!) ruwe implementatie: = $min) and ($colour[$which] <= $max)); } } ]]> Voer het script zonder argumenten uit en het zal de achtergrondkleur door een spectrum van gedempte kleuren roteren tot het beëindigd (gekilld) wordt. Voilà! Uiteraard is Perl niet de enige taal die u voor het schrijven van scripts met &DCOP; kunt gebruiken — als u liever een shell-script schrijft, kan dat ook: Het volgende script haalt de intro-afbeelding van de strip User Friendly op en stelt die in als achtergrond voor het bureaublad met behulp van algemeen beschikbare hulpmiddelen en een beetje &DCOP;. .*,,"` TMPFILE=`mktemp /tmp/$0.XXXXXX` || exit 1 wget -q -O $TMPFILE $COMICURL dcop kdesktop KBackgroundIface setWallpaper $TMPFILE 1 ]]> De eerste regel na #!/bin/sh gebruikt wget en een reguliere expressie-kunstje om de locatie van de afbeelding uit de broncode van de indexpagina te extraheren. De tweede en derde regel downloaden de afbeelding, en tot slot stelt dcop de afbeelding in als achtergrond. Veel moderne toetsenborden bevatten toetsen die niet standaard aan een actie zijn toegewezen. Multimedia-toetsen genereren vaak een signaal en kunnen eenvoudig, net als elke andere toets, als sneltoets in een toepassing gekozen worden. Sommige toetsen worden echter niet gedetecteerd en in het dialoogvenster Sneltoetsen instellen heeft het indrukken ervan geen effect. Sommige IBM-laptops hebben bijvoorbeeld extra toetsen bij de pijltoetsen naar links en rechts die eruitzien als pagina links en pagina rechts. U kunt het commando xev gebruiken om de code van de toetsen te vinden. In dit geval is dat 233 en 234. Kies toetssymbolen. Er worden er veel niet standaard gebruikt, deze zijn dus vrij te gebruiken. U kunt de lijst in het bestand /usr/X11R6/include/X11/keysymdef.h vinden (of in het equivalent op uw systeem). Creëer een bestand met de naam .Xmodmap in uw persoonlijke map en typ het volgende erin: keycode 233 = Next_Virtual_Screen keycode 234 = Prev_Virtual_Screen Voer het commando xmodmap ~/.Xmodmap uit. Als u nu het commando xev nog een keer uitvoert, zult u zien dat de toetsen nu de "keysym" (toetssymbool) genereren die u eraan toegewezen hebt. U kunt ze nu aan elke actie toewijzen. De xev-man-pagina. Deze kunt u zien door man:/xev in &konqueror; in de locatiebalk te typen of door man xev in een terminal te typen. Aan de meeste acties op het bureaublad of in toepassingen kunnen gemakkelijk sneltoetsen toegewezen worden. Als de actie waaraan u een sneltoets wilt toewijzen een zelfgeschreven programma is, kunt u net zo gemakkelijk sneltoetsen toewijzen. Misschien wilt u een ongebruikte toets aan een script of aan een dcop-commando toewijzen. In dit voorbeeld gaan we de twee toetsen, die we in toegevoegd hebben, gebruiken om naar het vorige of volgende virtuele bureaublad te gaan; twee functies waarvoor u DCOP nodig hebt (zoals besproken in ). Met de volgende methode is dit gemakkelijk te doen: Open &kcontrol;, kies in het gedeelte Regio & toegankelijkheid Invoeractie Klik op de knop Nieuwe actie Geef de nieuwe actie een naam, ⪚ Volgende virtuele scherm Selecteer Sneltoets -> Command/URL (eenvoudig) bij het Actietype: Op het tabblad sneltoets klikt u op de knop die u aan het commando wilt koppelen. In dit voorbeeld zou dat de knop met het pictogram Volgende pagina zijn. Er verschijnt nu Next_Virtual_Screen op de afbeelding. Op het tabblad Command/URL Settings typt u het commando dat uitgevoerd moet worden in: dcop twin default nextDesktop Herhaal dit voor Prev_Virtual_Screen en dcop twin default previousDesktop. Wanneer u nu op de toets Prev_Virtual_Screen of Next_Virtual_Screen drukt, schakelt u over naar respectievelijk het vorige of het volgende virtuele bureaublad. Zoals blijkt, kunt u elke vrije toets aan elke actie toewijzen. U kunt de documentatie van KHotKeys bekijken door het in &khelpcenter; te selecteren of door help:/khotkeys in &konqueror; in de locatiebalk te typen. Adriaan de Groot groot@kde.org &kdebugdialog; staat niet standaard in het &kmenu;. U moet het in een shell of vanuit de mini-CLI met het commando kdebugdialog opstarten. kdebugdialog; opent een venster met een lange lijst debug-gebieden. Elk gebied heeft een keuzevakje dat u kunt gebruiken om de debug-uitvoer voor dat gedeelte van &kde; in of uit te schakelen. De lijst is op nummer gesorteerd en niet op alfabet, tdeio (127) staat dus voor artskde (400). De nummers lopen op tot zo'n 200.000, maar er zijn in werkelijkheid slechts 400 gebieden. U hoeft niet door de hele lijst heen te zoeken, bovenin het dialoogvenster is een tekstinvoerveld waarin u een gedeelte van de naam kunt invoeren. De lijst wordt gefilterd en alleen de items die de tekst bevatten die u ingetypt hebt worden getoond. ⪚ k filtert niet zo veel uit, maar kont laat alleen de &kontact; debug-gebieden zien. Om nog sneller de debug-uitvoer in of uit te schakelen kunt u op één van de knoppen Alles selecteren of Alles deselecteren klikken, waardoor &kde; een berg aan debug-uitvoer of heel erg weinig uitvoer produceert. In "full"-modus, die u krijgt door kdebugdialog met het commando kdebugdialog --fullmode op te starten, is dezelfde lijst met debug-gebieden beschikbaar als in de gewone modus, maar nu kunt u slechts één item tegelijk uit een keuzelijst selecteren. U kunt dan de uitvoer voor de verschillende soorten meldingen (informatie, waarschuwing, fout en fatale fout) onafhankelijk van elkaar instellen. Voor elk van deze typen kunt u kiezen waarnaartoe de meldingen gestuurd worden. U kunt kiezen uit: Bestand, in dit geval kunt u een bestandsnaam intypen. Dit bestand wordt naar uw $HOME-map geschreven. Dialoogvenster. Elke debug-melding wordt in een dialoogvenster getoond. U moet elke keer op OK klikken om de toepassing verder te laten gaan. Shell, de standaard. Meldingen worden naar "stderr" (standaard foutuitvoer) afgedrukt en zullen naar het shell-venster waar de toepassing opgestart werd of in .xsession-errors geschreven worden. Syslog. Elke debug-melding wordt naar de syslog-voorziening van het systeem gestuurd, waarna het verder behandeld wordt. Geen. Dit onderdrukt de uitvoer van dit type melding. Voor meldingen die door fatale fouten gegenereerd worden is het in het algemeen een slecht idee om Geen of Syslog te kiezen, omdat u in beide gevallen de melding waarschijnlijk niet zult zien en de toepassing die een fatale fout tegenkomt zal verdwijnen zonder dat duidelijk wordt waarom. Of een toepassing al dan niet verdwijnt bij een fatale fout kan ingesteld worden met het keuzevakje Afsluiten bij fatale fouten, dat standaard geselecteerd is — maar het kan gebeuren dat een toepassing toch crasht na een fatale fout.