Karambaanleitung 2004
Aus dem Jahre 2004, aber ich hoffe, dem Einen oder dem Anderen kann es noch hilfreich sein. Seraphyn
Heute will ich einfach ein Programm vorstellen, welches nicht nur eine Desktopverschönerung zulässt, sondern auch das Bauen eigener Leisten, welche den Kicker ersetzen und die Überwachung des Systemes zulässt. Anbei ist ein HowTo zum Selberprogrammieren von Programmen mit Karamba, welches zwei Beispiele beinhaltet.
Eines ist eine Systemanzeige und das andere ein Ersatz für den Kicker.
Karamba oder auch Superkaramba sind Programme, welche sogenannte Desklets zur Verfügung stellen. Das gleiche gibt es auch nochmal für den Gnome-Desktop, bei jenem nennt sich das Programm aber Gdesklet. Wie dort die Programmierung ist, kann ich leider nicht sagen, da ich jenes noch nicht benutzt habe.
Hier ist ein Beispieldesktop mit solchen Desktlets zu sehen:
Nicht nur, dass diese Desklets cool aussehen, sondern sie haben auch einen sehr informativen Charakter. Hier sind als Beispiel eine Wettervorhersage, Systeminformationen, ein realtime Loggwatcher, eine eigene neue Leiste, welche den Kicker ersetzt usw. zu sehen. Es gibt für Karamba, sowie Superkaramba schon viele Desklets, welche man herunterladen kann.
Man solte einen kleinen Blick auf KDE-Look.org wagen, denn dort gibt es einiges zum Download für die Karambabrüder. Das Coden von eigenen Desklets mag im ersten Moment nicht einfach erscheinen, aber wie bei allem braucht man etwas Übung und ein wenig Zeit. Also nicht gleich bei den ersten nicht sofort eintretenden Erfolgen aufgeben ;)
Um Superkaramba nun selber nutzen zu können schaut man ob es bei der Distribution schon mit dabei ist und installiert es, oder man kompiliert es sich selber. Wer einen Blick auf die Superkaramba-Homepage wirft, findet unter Downloads den SuperKaramba source code, RPMs für RedHat und SuSE, sowie Packages für Debian und Slackware. Wer also eine dieser Distributionen hat, der muss nicht kompilieren und kann den nächsten Punkt überspringen. Für alle anderen geht es nun ins Eingemachte.
1. Die Installation
Nach dem Download des Sourcecodes macht man sich am besten ein Verzeichnis in seinem Homeordner, welches immer zum kompilieren dienen kann. Ich habe meines einfach compile genannt. Nun wird das Paket:
in den Ordner verschoben (1)
entpackt (2)
in den entpackten Ordner gewechselt (3)
Nun wird das ganze mit dem bekannten Dreisatz compiliert und installiert. Um die Software dann zu installieren muss man sich als substitute User (su) anmelden und das root-Passwort wird dazu benötigt. Wer an diesem Punkt noch keinen Compiler installiert hat sollte dies bitte tun.
Falls es schon bei dem ./configure zu Fehlern kommen sollte sind nicht alle Pakete, welche für die Kompilierung benötigt werden installiert. Weil in dem im Moment erhältlichen Quellcode noch ein kleiner Fehler steckt der dazu führt, dass die Desklets andere Fenster überdecken, sollte man folgende Zeile in der Datei the karamba.cpp auskommentieren:
KWin::setType(winId(), NET::Dock);
Setzt vor diese Zeile einfach ein //.
Das sollte dann so aussehen:
So nun ist Superkaramba installiert nur wie kann man es aufrufen bzw. starten?
Entweder macht man sich einen Desktoplink oder man ruft es direkt von der Shell auf:
Man kann sich auch ein Script zur Hilfe nehmen und packt es in den ~/.kde/Autostart/ Ordner, nennt es karamba.sh, macht es ausführbar mit dem Befehl:
Dieses Script sollte diese Zeilen enthalten:
Somit startet Karamba bzw. Superkaramba direkt.
Nun sollte man schon ein Desklet von dem oben genannten Link heruntergeladen haben, damit man es in diesem Fenster nun auswählen kann. Um dies zu tun wählt man einfach die .theme-Datei aus, welche sich in dem Ordner des heruntergeladenen Desklets befindet. Um weitere Desklets auszuwählen wirft man einfach einen Blick auf das Menü, welches bei einem schon geöffneten Desklet erscheint, wenn man mit der rechten Maustaste darauf klickt.
Der Code
Im Grunde sind wir hier schon fertig, aber man will ja vielleicht auch selber etwas erstellen und wenn es nur eine eigene Bar ist, welche den Kicker ersetzen soll, oder ein Monitor für das System. Als Beispiel wird ab hier das micromon-Package, welches die CPU-, Festplatten-, RAM-Auslastung, sowie die Festplattenbelegung anzeigt genommen.
Wenn man sich das Verzeichnis des micromon anschaut sieht man dort ein micromon.theme und ein Verzeichnis für die Bilder, welche mit angezeigt werden. Dies ist der Ordner images. Wenn man sich nun das micomon.theme anschaut sieht man folgenden Code, welchen ich hier schon ein wenig kommentiere und deswegen Zeilennummern vorn angefügt habe um eine bessere Referenz zu bieten. Zu beachten ist, dass jede Zeile, welche mit einem # am Anfang beginnt ein Kommentar ist und nicht von Karamba beachtet wird.
(1)
Hier befinden sich die Angaben über:
Die Postion des Desklets (X und Y)
Die Grösse des Desklets (W und H)
Den Upfreshinterval des Desklets, also die Zeit in welcher das Desklet upgedatet werden soll in Millisekunden (interval) und die Angabe ob das Desklet beweglich sein soll in der Position oder nicht (locked)
(2)
Hier haben wir die Icons für die einzelnen Anzeigen. Wie man nun sieht halten sich die X und Y Angaben an den Rahmen, welcher mit dem Punkt (1) definiert wurde, sprich die Höhen- und Breitenangaben. Die Pfadangabe verhält sich relativ zu dem Pfad unseres Ordners.
(3)
Dies ist nun der erste Einsatzort der eingebauten Sensoren. Auf diese gehe ich später noch genauer ein. Bei dem Format sollte man seine CPU-Leistung eingeben, sprich die 1749MHz gegen den Wert der eigenen CPU austauschen. Auch hier ist der interval wiederzufinden, denn jener kann noch angepasst werden, genauso wie die Schriftgrösse und die Farbe der Schrift.
(4)
Hier sollte als device das richtige angegeben werden, bei den meisten sollte dies eth0 sein.
Innerhalb diese Formattags sieht man zwei Angaben dies sind %in und %out, ich denke sie sind selbsterklärend.
(5)
Hier sollten die richtigen Mountpoints eingepflegt werden. Sprich jene welche in der fstab drin stehen. und unter Format kann man anstelle von hda2 auch /home oder ähnliches eingeben was genau die FSH wiederspiegelt. In meinem Falle wäre dies:
(6)
Hier ist ein wenig Anpassung nötig. Im ganzen sieht die Zeile so aus:
Hier wird das Tool Sensor geladen und damit ein ps -aux, ein Anzeigen aller Prozesse gesetzt. Dies bedeutet man muss auch die Größe des gesamten Desklets dieser Ausgabe anpassen. Also schon ein wenig Umcoden des Desklets. Dies kann mit einem Rechtsklick auf das Desklet gemacht werden und mit dem Kommando Edit, oder mit einem Textprogramm wie kate, vi oder pico.
3. Der Code Advanced
Hier nun einige Erklärungen zu den Sensoren und mehr, wie man z.B. das Startmenü in seine selbstgebaute Bar bekommt und Buttons baut um den Desktop zu wechseln.
Parameterübersicht
KARAMBA
Dies definiert das Karambafenster selbst. Ein großes Fenster braucht natürlich mehr Zeit um gezeichnet zu werden, als ein kleines. Somit sollte nie das Karambafentser größer sein, als benötigt.
X - Horizontal Position des Karambafensters
Default: X=0
Y - Vertical Position des Karambafensters
default: Y=0
W - Die Breite des Karambafensters
default: W=300
H - Die HÖhe des Karambafensters
default: W=300
RIGHT - Wenn RIGHT=true gesetzt ist , dann wird das Karambafenster auf der rechten Seite des Bildschirms angezeigt und der X Paramter ignoriert.
default: RIGHT=false
BOTTOM - Das gleiche wie bei Right, nur dass es der untere Screen ist. Der Y Paramter wird ignoriert.
ONTOP - ONTOP=true zeigt das Karambafenster immer über allen anderen Desktopfenstern.
default: ONTOP=false
TOPBAR - TOPBAR=true zeigt das Fenster am oberen Bildschirmrand an und vergrösserte Fenster überdecken somit das Karambafenster nicht. Somit kann man dann das Karambadesklet wie den Kicker unter KDE einsetzen. Aber Achtung, das Karambafenster kann da nicht bewegt werden.
default: TOPBAR=false
BOTTOMBAR - BOTTOMBAR=true ist das gleich wie TOPBAR=true, nur diesmal betrifft es den unteren Bildschirmrand.
default: BOTTOMBAR=false
INTERVAL - Ist die Rate in welcher das Desklet neu geschrieben werden soll. Die Angaben werden in Millisekunden gerechnet.
default: INTERVAL=5000
LOCKED - A LOCKED=true bedeutet, dass das Karambafenster nicht per Click'n'move bewegt werden kann. Dies kann aber auch per Rechtsclick auf das Desklet nachträglich geändert werden.
default: LOCKED=false
Maßangaben
IMAGE
Zeigt ein Bild an einer fest definierten Position an. Das Bild kann nicht zu einen Sensor verbunden werden, denn die Werte des Sensors würden als Bildpfad interpretiert werden. Bilder mit Transparenz können benuztzt werden.
X - Horizontale Position des Bildes gesehen vom oberen rechten Rand.
Y - Vertikale Position des Bildes gesehen vom oberen linken Rand.
PATH - Der Pfad zu dem Bild und zwar relativ zu dem config.-File
Beispiele:
IMAGE X=10 Y=10 PATH="/tmp/pic.png"
IMAGE X=10 Y=10 PATH="http://your-site.se/image.jpg"
IMAGE X=10 Y=10 SENSOR=PROGRAM PROGRAM="pictures.pl"
TEXT
Zeigt einen Text an einer fest definierten Position an. Man kann die Höhe und Breite angeben und außerhalb dieses Bereiches wird kein Text angzeigt, dieser Punkt ist aber nur Optional. Alle Sensoren können mit einer Textangabe als Maß verbunden werden.
X - Horizontale Position des Textes gesehen vom oberen rechten Rand.
Y - Vertikale Position des Textes gesehen vom oberen linken Rand.
W - Die Breite des Textbereiches, optional
H - Die Höhe des Textbereiches, optional
VALUE - Der Text
ALIGN - Setzt die Anordnung des Textes Möglich sind:
LEFT|CENTER|RIGHT
default: ALIGN=LEFT
FONT - Welche Schrift benutzt werden soll
FONTSIZE - Die Grösse der Schrift
COLOR - Die Textfarbe, COLOR=0..255,0..255,0..255
default: COLOR=0,0,0
BGCOLOR - Schattenfarbe des Textes
default: BGCOLOR=0,0,0
SHADOW - Setzt einen Schatten für den Text und zwar n Pixel vom Text enfernt. Diese Angabe kann auch negativ sein.
default: SHADOW=0
Beispiel: SHADOW=2
FIXEDPITCH - Setzt einen kleinen Zwischenbereich zwischen die einzelnen Buchstaben.
default: FIXEDPITH=false
Beispiele:
TEXT X=0 Y=0 VALUE="Test string"
TEXT X=0 Y=0 SENSOR=CPU COLOR=255,0,0 FONT="arial" SENSOR=CPU
BAR
Zeigt einen Balken an, welcher wie ein Fortschrittsbalken ist. Dieser Balken wird mit Hilfe eines Bildes angezeigt, welches in der Pfadangabe steht. Hier können auch transparente oder semitransparente Bilder genutzt werden. Wenn die Angaben W und H nicht genuztzt werden , dann wird die Größe des Bildes, welches angegeben wurde genutzt. Als Default wird der Balken von Links nach rechts angezeigt, aber auch ein vetrtikaler Balken ist möglich, dazu wird die Option Vertical genutzt.
X - Horizontale Position gesehen vom oberen rechten Rand.
Y - Vertikale Position gesehen vom oberen linken Rand.
W - Die Breite des Balkens, optional
H - Die Höhe des Balkens, optional
PATH - PATH - Der Pfad zu dem Bild des Balkens und zwar relativ zu dem config.-File
VERTICAL - Der Balken wird Vertikal angezeigt
default: VERTICAL=false
VALUE - Wert des Balkens Bsp.: MB GB usw...
default: VALUE=0
MIN - Die minimalste Einheit des Balkens, kann von einem Sensor überschrieben werden.
default: MIN=0
MAX - Die maximalste Einheit für den Balken, kann von einem Sensor überschrieben werden.
default: MAX=100
Beispiele:
BAR X=0 Y=0 W=10 H=200 VERTICAL=true PATH="img.png" SENSOR=CPU
BAR X=0 Y=0 PATH="img.png" MIN=30 MAX=60 SENSOR=CPU
GRAPHEN
Zeigt einen Graphen an, welcher von rechts nach links verläuft.
X - Horizontale Position gesehen vom oberen rechten Rand.
Y - Vertikale Position gesehen vom oberen linken Rand.
W - Die Breite des Graphen, optional
H - Die Höhe des Graphen, optional
POINTS - Anzahl der Punkte in dem Graphen
MIN - Die minimalste Einheit des Graphen, kann von einem Sensor überschrieben werden.
default: MIN=0
MAX - Die maximalste Einheit für den Graphen, kann von einem Sensor überschrieben werden.
default: MAX=100
COLOR - Die Farbe des Graphen, COLOR=0..255,0..255,0..255
default: COLOR=0,0,0
Examples:
GRAPH X=0 Y=0 W=200 H=60 POINTS=100 SENSOR=CPU
SENSOREN
CPU
Dieser Sensor zeigt die momentane CPU-Auslastung an. Es können auch mehrere Prozessoren angezeigt werden. Der INTERVAL-Parameter der ersten CPU gilt auch für alle darauf folgenden CPUs. Es kann aber auch ein anderer Interval durch einen weiteren Sensor für die zweite CPU angegeben werden. INTERVAL - Ist die Rate in welchen Abständen der CPU-Sensor abgetastet werden soll. Die Angabe erfolgt auch hier in Millisekunden.
default: INTERVAL=1000
CPU - Die Nummer der CPU, sehr wichtig , wenn man mehr als eine hat.
CPU=0 - Die erste CPU
CPU=1 - Die zweite CPU
CPU=all - Die Auslastung aller Prozessoren.
default: CPU=all
FORMAT
%v - Die CPU Auslastung
%load - Das gleiche wie %v
%user - Die Auslastung durch den Benutzer
%system - Die Auslastung durch das System
%nice - Die Niceauslastung
%idle - Die Idleauslastung
default: FORMAT="%v"
Beispiel: FORMAT="CPU load: %v"
MEMORY
Dieser Sensor gibt Auskunft über den Speicher und den Swapspeicher. Der INTERVAL-Parameter des ersten Speichersensors, welcher in dem Config-File angeben wird, wird für alle darauf folgenden Speichersensoren genutzt.
INTERVAL - Ist die Rate in der der Speichersensor abgetastet werden soll. Die Angabe erfolgt ebenfalls in Millisekunden.
default: INTERVAL=3000
FORMAT
%fm - Freier Speicher in Megabytes
%fmb - Freier Speicher in Megabytes (cache and buffers excluded)
%um - Benutzter Speicher in Megabytes
%umb - Benutzter Speicher in Megabytes (cache and buffers excluded)
%tm - Kompletter Speicher in Megabytes
%fs - Freier Swap in Megabytes
%us - Benutzter Swap in Megabytes
%ts - Kompletter Swap in Megabytes
default: FORMAT="%um"
Beispiel: FORMAT="Freier Speicher: %fm MB"
DISK
Dieser Sensor gibt Auskunft über die gemounteten HDs. Das Network File System (NFS) kann auch angezeigt werden. Der INTERVAL-Parameter des ersten Disksensors, welcher in dem Config-File angegeben wird, wird für alle darauf folgenden Disksensoren genutzt.
INTERVAL - Ist die Rate in welcher der Disksensor abgetastet werden soll. Auch diese Wertangabe erfolgt in Millisekunden.
default: INTERVAL=5000
FORMAT
%f - Freier Festplattenspeicher in Megabytes
%fp - Prozentangabe des freien Speichers.
%u - Benutzter Destplattenspeicher in Megabytes
%up - Prozentangabe des benuzten Festplattenspeichers.
%t - Gesamte Festplattengröse in Megabytes
default: FORMAT="%u"
Beispiele: FORMAT="Free space: %f MB"
FORMAT="Used space: %up %"
MOUNTPOINT
default: MOUNTPOINT="/"
Beispiel: MOUNTPOINT="/mnt/home"
NETWORK
Dieser Sensor gibt Auskunft über den Netzwerkverkehr. Der INTERVAL-Parameter des ersten Netzwerksensors, welcher in dem Config-File angeben wird, wird für alle darauf folgenden Netzwerksensoren genutzt.
INTERVAL - Ist die Rate in welcher der Netzwerksensor abgetastet werden soll. Auch hier erfolgt die Angabe in Millisekunden.
default: INTERVAL=2000
DEVICE - Ist der Netzwerkanschluss , welcher genutzt werden soll.
default: DEVICE="eth0"
Beispiel: DEVICE="ppp0"
FORMAT
%in - Eingehender NetzwerkTraffic in kilobytes / s
%out - Ausgehender NetzwerkTraffic in kilobytes / s
default: FORMAT="%in"
Beispiel: FORAMT="Eingehender : %in kb/s"
DECIMALS
Dezimalwert für die Netzwerkmessung.
default: DECIMALS=0
TIME
Dieser Sensor ist für die Zeitangabe zuständig. Der INTERVAL-Parameter des ersten Zeitsensors, welcher in dem Config-File angeben wird, wird für alle darauf folgenden Zeitsensoren genutzt.
INTERVAL - Ist die Rate in welchen Zeitabständen der Zeitsensor abgetastet werden soll. Auch hier erfolgt die Angabe in Millisekunden.
default: INTERVAL=60000
FORMAT
d - Der Tag ohne anführende Null (1-31)
dd - Der Tag mit anführender Null (01-31)
ddd - Der abgekürzte lokalisierte Tagesname (Bsp. 'Mon'..'Son')
dddd - Der ausführliche lokalisierte Tagesname (Bsp.'Montag'..'Sonntag')
M - Der Monat ohne anführende Null (1-12)
MM - Der Monat mit anführender Null (01-12)
MMM - Der abgekürzte lokalisierte Monatsname (Bsp. 'Jan'..'Dez').
MMMM - Der ausführliche lokalisierte Monatsname (Bsp. 'Januar'..'Dezember').
yy - Das Jahr zweistellig (00-99)
yyyy - Das Jahr vierstellig (1752-8000)
h - Die Stunde ohne anführende Null (0..23 or 1..12 wenn AM/PM angezeigt wird)
hh - Die Stunde mit anführender Null (00..23 or 01..12 wenn AM/PM angezeigt wird)
m - Die Minuten ohne anführende Null (0..59)
mm - Die Minuten mit anführender Null (00..59)
s - Die Sekunden ohne anführende Null (0..59)
ss - Die Skunden mit anführender Null (00..59)
z - Die Millisekunden ohne anführende Null (0..999)
zzz - Die Millisekunden mit anführender Null (000..999)
AP - Benutzt AM/PM Anzeige. AP wird mit "AM" oder "PM" ausgetauscht.
ap - Benutzt am/pm Anzeige. ap wird mit "am" or "pm" ausgetauscht.
Beispielformate (Hier wird Datum und Zeit mit dem 21ten Mai 2001 14:13:09 genutzt)
FORMAT="dd.MM.yyyy" -> 21.05.2001
FORMAT="ddd MMMM d yy" -> Die Mai 21 01
FORMAT="hh:mm:ss.zzz" -> 14:13:09.042
FORMAT="h:m:s ap" -> 2:13:9 pm
UPTIME
Dieser Sensor zeigt an, wie lange das System seit dem letzten Start läuft. Der INTERVAL-Parameter des ersten Uptimesensors, welcher in dem Config-File angegeben wird, wird auch für alle darauf folgenden Uptimesensoren genutzt.
INTERVAL - Ist die Rate in welchen Zeitabständen der Uptimesensor abgefragt werden soll. Auch hier erfolgt wieder die Angabe in Millisekunden.
default: INTERVAL=60000
FORMAT
%d - Tage
%h - Stunden
%m - Minuten
%s - SeKunden
%H - Stunden mit anführender Null
%M - Minuten mit anführender Null
%S - Seconds mit anführender
default: FORMAT="%dd %h:%M"
SENSOR
Dieser Sensor kann CPU-Temperatur, Lüftergeschwindigkeit, Spannung und noch weiteres mehr anzeigen. Das Programm sensors wird gebraucht, damit dieser Sensor arbeiten kann. Der INTERVAL-Parameter des ersten Sensors, welcher in dem Config-File angeben wird , wird für alle darauf folgenden Sensoren genutzt.
INTERVAL - Ist die Rate in welchem Zeitabstand der Sensor abgetatstet werden soll. Auch hier gilt wieder die Angabe in Millisekunden.
default: INTERVAL=30000
FORMAT
%v - Der Wert des Sensoren
default: FORMAT="%v"
Beispiel: FORMAT="Lüftergeschwindigkeit: %v"
TYPE
default: TYPE="temp2"
Lässt das Sensorprogramm mit den erhältlichen Anzeigen laufen.
Beispiel:
TYPE="fan1"
TEXTFILE
Dieser Sensor liest Textfiles jeglicher Art. Mit diesem Sesnor lassen sich Logfiles in Realzeit anzeigen oder auch ein Newsticker. Der INTERVAL- und ENCODING-Parameter des ersten Textsensors, welcher in dem Config-File angeben wird, wird auch hier wieder für alle darauf folgenden Textsensoren genutzt, welche den gleichen Pfad haben.
INTERVAL - Ist die Rate in welchem Zeitabstand der Textsensor abgetatstet werden soll. Hier gilt ebenfalls, Angaben sind in Millisekunden.
default: INTERVAL=60000
PATH
Der Pfad zu dem Textfile
Beispiel:
PATH="/var/log/messages"
ENCODING
Mit diesem Parameter kann ein anderer Zeichesatz angezeigt werden, wenn dies von Nöten ist. Eine Liste der Codings kann in der QTextCodec Class Reference gefunden werden.
Default: ENCODING="" - Die eigene locale wird genuztzt.
Beispiele:
ENCODING="KOI8-R"
ENCODING="ISO8859-6"
LINE
Mit dem Parameter LINE wird nur eine Zeile angezeigt, welche in dem angwählten Text emthalten ist.
LINE=1 - Die erste Zeile des Textfiles
LINE=2 - Die zweite Zeile des Textfiles
LINE=-1 - Die letzte Zeile des Textfiles
LINE=-2 - Die vorletzte Zeile des Textfiles
RDF
Es muss RDF=true gesetzt werden, wenn des Textfiles ein RDF/RSS-Feed ist
default: RDF=false
NOATUN
Mit diesem Sensor kann eine Anzeige für Noatun und eine Fernsteuerung gestaltet werden. Der INTERVAL-Parameter des ersten Noatunsensors, welcher in dem Config-File angeben wird, wird für alle darauf folgenden Noatunsensoren genutzt.
INTERVAL - Ist die Rate in welchem Zeitabstand der Noatunsensor abgetastet werden soll Auch hier kommen als Zeiteinheit wieder unsere Millisekunden zum Einsatz.
default: INTERVAL=1000
FORMAT
%id - Der noatun dcop Name ist sehr wichtig, wenn man eine Clickarea angibt.
Beispiel:
onclick="dcop %v Noatun play" sensor=noatun format="%id"
%title - Titel des laufenden Songes
%time - Zeit des laufenden Songes
%remain - Verbleibende Zeit des gerade laufenden Songes
%length - Länge des laufenden Songes
%full - Dieser Sensor Gibt den MAX-Wert zurück wenn Noatun gestartet ist, sonst 0.
%full ist sehr nützlich, wenn der Sensor mit einem BAR verbunden ist, somit wird das Bild des Balkens nur angezeigt, wenn Noatun läuft.
default: FORMAT="%title %time / %total"
XMMS
Mit diesem Sensor ist das Gegenstück für XMMS des Noatunsensors.
Der INTERVAL und ENCODING-Parameter des ersten XMMS-Sensors, welcher in dem Config-File angeben wird, wird für alle darauf folgenden XMMS-Sensoren genutzt.
INTERVAL - Ist die Rate in welchem Zeitabstand der XMMS-Sensor abgetastet werden soll. Angabe auch hier wieder in Millisekunden.
default: INTERVAL=1000
ENCODING
Mit diesem Paraneter kann ein anderer Zeichensatz angezeigt werden, wenn dies von Nöten ist. Eine Liste der Codings kann in der QTextCodec Class Reference gefunden werden.
Default: ENCODING="" - Die eigene locale wird genuztzt.
Beispiele:
ENCODING="KOI8-R"
ENCODING="ISO8859-6"
FORMAT
%title - Titel des laufenden Songs
%time - Zeit des laufenden Songs
%remain - Verbleibende Zeit des gerade laufenden Songs
%length - Länge des laufenden Songs
%full - Dieser Sensor Gibt den MAX-Wert zurück wenn XMMS gestartet ist, sonst 0.
%full ist sehr nützlich, wenn der Sensor mit einem BAR verbunden ist. Somit wird das Bild des Balkens nur angezeigt, wenn XMMS läuft.
default: FORMAT="%title %time / %total"
PROGRAM
Dieser Sensor ist dafür da um ein Programm laufen zu lassen und dieses dann auf einem Meter auszugeben. Der INTERVAL und ENCODING-Parameter des ersten Sensors, welcher in dem Config-File angeben wird, wird für alle darauf folgenden Sensoren genutzt, welche den identischen Programmnamen haben, inklusive den Programmparametern
INTERVAL - Ist die Rate in welchem Zeitabstand der Sensor abgetastet werden soll, auch hier wieder in Millisekunden.
default: INTERVAL=3600000
PROGRAM
Das Programm, welches laufen soll
Beispiel:
PROGRAM="ftpwho -v"
ENCODING
Mit diesem Paraneter kann ein anderer Zeichesatz angezeigt werden, wenn dies von Nöten ist. Eine Liste der Codings kann in der QTextCodec Class Reference gefunden werden.
Default: ENCODING="" - Die eigene locale wird genuztzt.
Beispiele:
ENCODING="KOI8-R"
ENCODING="ISO8859-6"
LINE
Mit dem Parameter LINE wird nur eine Zeile angezeigt, welche in dem angwählten Text ist.
LINE=1 - Die erste Zeile des Textfiles
LINE=2 - Die zweite Zeile des Textfiles
LINE=-1 - Die letzte Zeile des Textfiles
LINE=-2 - Die vorletzte Zeile des Textfiles
DEFAULTFONT
Der Nutzen des Defaulfonttags ist , jener dass er für alle Texte geltend gesetzt werden kann. Wenn nun der DEFAULTFONT gesetzt ist kann damit der Texttag verkleinert werden und nur noch als DEAFAULTFONT gesetzt werden. Die Ausnahme ist, wenn der Text-Tag eigene Parameter gesetzt hat. Diese Paramter überschreiben dann den DEFAULTFONT. Sprich der Text muss nicht weiter spezifiziert werden.
Beispiel:
DEFAULTFONT shadow=2 color=255,0,0
text x=0 y=0 value="test"
DEFAULTFONT font="times" fontsize=10 color=255,0,0
text x=0 y=40 value="test" font="arial"
text x=0 y=80 value="test" color=0,0,0
CLICKAREA
Dieser Tag definiert einen klickbaren Bereich. Von diesem Punkt aus, kann dann ein Programm gestartet werden. Ein Doppelklick auf diesen Bereich ist nur nötig wenn das Karambafenster nicht gelocked ist. Der CLICKAREA-Tag wird wie ein Meter benutzt, dies bedeutet es können auch dort Sensoren vorhanden sein.
X - Horizontale Position gesehen vom oberen rechten Rand.
Y - Vertikale Position gesehen vom oberen linken Rand.
W - Die Breite des klickbaren Bereiches
H - Die Höhe des klickbaren Bereiches.
PREVIEW - Wenn PREVIEW mit 'true' gesetzt wurde wird ein Rechteck um den Bereich angezeigt
ONCLICK - Das Programm, welches gestartet werden soll bei einem Klick.
%v wird mit dem Wert des Sensors ersetzt.
Beispiel:
CLICKAREA X=0 Y=0 W=100 H=10 ONCLICK="kdialog --msgbox 'CPU load: %v'" SENSOR=CPU
Dieses Beispiel zeigt eine Dialogbox, welche die momentane CPU-Last zeigt. Man könnte dort auch die Shell unterbingen oder sonst ein anderes Programm, dies ist z.B. sehr wichtig, wenn man sich eine eigene Toolbar baut, dazu aber später mehr.
Der Group-Tag ist ein sehr wichtiger Tag, denn damit lassen sich Elemente in Gruppen zusammenfassen. Dies macht es sehr leicht Elemnte hinzuzufügen und wieder zu entfernen, da man nicht alle x- und y-Werte neu setzen muss. Es können auch Gruppen in Gruppen erstellt werden.
X - Horizontale Position der Gruppe gesehen vom oberen rechten Rand.
Y - Vertikale Position der Gruppe gesehen vom oberen linken Rand.
Beispiel:
X=20 Y=20
TEXT X=0 Y=0 VALUE="test1"
TEXT X=10 Y=10 VALUE="test2"
X=20 Y=20
Wie man in diesem Beispiel sieht fangen die Icons innerhalb der Gruppe immer mit einem neuen X=0 Wert an.
4. Das Nutzen von Scripten
Um nun Karamba noch ein wenig zu erweitern kann man noch Perl- und Pythonscripte mit einbauen, welche verschiedene Dinge ausführen, wie z.B. einen Kalender darstellen, nach Mails sehen, das Wetter anzeigen und auch eine Webcam einbinden. Dort sind auch verbesserte Scripte für den XMMS-Player zu finden. Bei einem Blick auf KDE-Look.org lassen sich dort einige in den vorgefertigten Desklets finden und durch die GPL auch nutzen.Ein Blick auf die Karambahomepage weist schon vier Skripte zum downloaden auf.
5. Das Nutzen von DCOP für einen eigenen Kicker
DCOP setzt auf der X11-Standardbibliothek libICE auf und ist mit seiner BSD-Lizenz frei verfügbar. DCOP wurde auf der KDE II Konferenz im Oktober 1999 als Umstieg auf ein eigenes Protokoll namens DCOP (Desktop COmmunication Protocol) entschieden. DCOP ist eine ressourcensparende Middleware zur Kommunikation von Applikationen, die auf der X11-Standardbibliothek libICE aufsetzt. Vorgestellt wurde DCOP von Matthias Ettrich (KDE-Gründer) und Preston Brown.
Hardcore Interna, kann überlesen werden ;):
Eine typische, standard-konforme X11-Anwendung ist über zwei Bibliotheken an jeweils einen Server-Prozess gebunden, über libX11 an den X-Server und über libSM an den Session-Management-Server. libSM widerum ist nur eine verhältnismäßig kleine Protokollimplementierung auf der Grundlage von libICE, einer allgemeinen Kommunikationsbibliothek, deren Design das Multiplexing verschiedener Protokolle über eine Verbindung ermöglicht.
Applikation
- libX11 <-----------------> XServer
- libSM <----------> SMServer
- libICE
DCOP macht sich nun zu nutze, daß jede Anwendung bereits über libICE verfügt und damit die Bibliothek bereits im Arbeitsspeicher vorhanden ist. Über libDCOP wird ein weiteres Protokol, eben DCOP, auf ICE aufgesetzt. Mit diesem greift die Anwendung auf einen dritten Server, dem DCOP-Server, zu.
Applikation
- libX11 <-----------------> XServer
- libDCOP <--------> DCOPServer
- libSM <----------> SMServer
- libICE
Der DCOP-Server ist ein Prozess der ständig auf dem Desktop läuft. Jeder Client muß sich einmalig bei ihm anmelden und kann dann mit jedem anderen Client auf dem Desktop kommunizieren. Bei der Anmeldung erhält jeder Client einen eineindeutigen Namen, über den er jederzeit identifiziert werden kann. Der DCOP-Server steht wie ein Verkehrspolizist in der Mitte der Kreuzung und regelt die Kommunikation zwischen den Clients. Diese Eigenschaft brachte ihm (neben dem offensichtlichem Grund: Desktop COmmunication Protocol) seinen Namen, er wurde in Anlehnung an den Traffic-COP, als Desktop-COP bezeichnet.
Das Design mit einem DCOP-Server in der Mitte hat 3 entscheidende Vorteile:
1.Man bekommt einen Naming-Service umsonst mit dazu. Es wird einfach, laufende Anwendungen zu lokalisieren.
2.Es werden wenig Verbindungen gebraucht (n Verbindungen für n Anwendungen), für Anfragen müssen nicht extra neue Verbindungen geöffnet werden. Dadurch ergibt sich eine sehr kurze Latenzzeit auch für den jeweils ersten Aufruf.
3.Ermöglicht sehr schnelle Massensendungen (broadcasts).
Es werden 2 Arten der Kommunikation zwischen Clients unterstützt:
Fire and Forget (asynchrones Senden)
Call and Listen (synchroner Aufruf)
Bei Fire and Forget sendet Client A eine Nachricht an Client B. Es handelt sich um eine einseitige Kommunikation, wobei Client B auch mehrere Applikationen seien können (Broadcasts). Client A hat bei dieser Art der Kommunikation keine Möglichkeit zu überprüfen, ob die Nachricht bei allen Clients angekommen ist, es interessiert Client A auch nicht. Call and Listen behebt diesen Nachteil. Hierbei erwartet Client A eine Reaktion von Client B. A ist also im Stande zu überprüfen, ob seine versendete Nachricht alle Empfänger erreicht hat und kann gegebenenfalls auf die Antwort reagieren; es handelt sich um eine zwei-, bzw mehrseitige Kommunikation.
Die synchronen Aufrufe sind dafür leider langsamer als das asynchrone Senden. Der Entwickler hat im konkreten Fall die Entscheidung zu treffen,was ihm wichtiger ist. Ein sicheres Ankommen mit einer Antwortmöglichkeit einerseits, oder das schnellere (nicht abgesicherte) Versenden einer Nachricht andererseits. Beide Methoden haben ihre Berechtigung für die Kommunikation auf dem Desktop.
So nun geht es ein bischen einfacher weiter, und wir wissen was der DCOP macht bzw. wofür DCOP da ist.
Für DCOP gibt es einige Anleitungen im Netz und der Aufruf des DCOP-Browser unter KDE funktioniert mit ALT+F2 und kdcop. Dieser ist aber Bestandteil eines weiteren Turtorials meinerseits, welches noch folgen wird. Hier gebe ich nur ein paar Beispiele, dass man auch seinen Kicker durch eine eigene Leiste ersetzen kann.
Der eigene Kicker
So, da oben einige Desklets angesprochen wurden kommt nun der SelfmadeKicker. Dieser Kicker ist im oberen Bereich des Dekstops und beinhaltet zum Aufzeigen der Funktionen keine Groups. Er hat XMMS Unterstützung, Desktopwechseln, das KDE Startmenü, Uhr, Statusleiste, Netzwerk und vieles mehr. Ich habe den Code nur noch an den Stellen kommentiert, welche definitiv nicht oben schon genannt wurden. Wichtig sind in diesem Punkt die DCOP Aufrufe. Diese Leiste hat dieses Aussehen
Diese Bar ist sehr einfach und es lässt sich noch mehr hinzufügen oder auch weglassen.
6. Die goldenen Regeln
Wenn mal was nicht so funktioniert, wie es soll, sollte man diese Regeln beachten:
1.Ist alles in einer Zeile, was in eine gehört ?
2.Ist alles richtig geschrieben ?
3.Sind die Pfadangaben richtig ?
4.Scripte per chmod u+x XXX.py/pl ausführbar gemacht ?
5.Stimmen die Rechte
6.Sind alle Icons bzw. Bilder vorhanden ?
Ich hoffe ich konnte ein klein wenig Licht in das Dunkel bringen.
Und wünsche viel Spass beim Coden
Gruß
Seraphyn
Heute will ich einfach ein Programm vorstellen, welches nicht nur eine Desktopverschönerung zulässt, sondern auch das Bauen eigener Leisten, welche den Kicker ersetzen und die Überwachung des Systemes zulässt. Anbei ist ein HowTo zum Selberprogrammieren von Programmen mit Karamba, welches zwei Beispiele beinhaltet.
Eines ist eine Systemanzeige und das andere ein Ersatz für den Kicker.
Karamba oder auch Superkaramba sind Programme, welche sogenannte Desklets zur Verfügung stellen. Das gleiche gibt es auch nochmal für den Gnome-Desktop, bei jenem nennt sich das Programm aber Gdesklet. Wie dort die Programmierung ist, kann ich leider nicht sagen, da ich jenes noch nicht benutzt habe.
Hier ist ein Beispieldesktop mit solchen Desktlets zu sehen:
Nicht nur, dass diese Desklets cool aussehen, sondern sie haben auch einen sehr informativen Charakter. Hier sind als Beispiel eine Wettervorhersage, Systeminformationen, ein realtime Loggwatcher, eine eigene neue Leiste, welche den Kicker ersetzt usw. zu sehen. Es gibt für Karamba, sowie Superkaramba schon viele Desklets, welche man herunterladen kann.
Man solte einen kleinen Blick auf KDE-Look.org wagen, denn dort gibt es einiges zum Download für die Karambabrüder. Das Coden von eigenen Desklets mag im ersten Moment nicht einfach erscheinen, aber wie bei allem braucht man etwas Übung und ein wenig Zeit. Also nicht gleich bei den ersten nicht sofort eintretenden Erfolgen aufgeben ;)
Um Superkaramba nun selber nutzen zu können schaut man ob es bei der Distribution schon mit dabei ist und installiert es, oder man kompiliert es sich selber. Wer einen Blick auf die Superkaramba-Homepage wirft, findet unter Downloads den SuperKaramba source code, RPMs für RedHat und SuSE, sowie Packages für Debian und Slackware. Wer also eine dieser Distributionen hat, der muss nicht kompilieren und kann den nächsten Punkt überspringen. Für alle anderen geht es nun ins Eingemachte.
1. Die Installation
Nach dem Download des Sourcecodes macht man sich am besten ein Verzeichnis in seinem Homeordner, welches immer zum kompilieren dienen kann. Ich habe meines einfach compile genannt. Nun wird das Paket:
in den Ordner verschoben (1)
entpackt (2)
in den entpackten Ordner gewechselt (3)
(1) tux@erde:~ cp superkaramba-0.33.tar.gz /home/username/compile
(2) tux@erde:~ tar -xzvf superkaramba-0.33.tar.gz
(3) tux@erde:~ cd superkaramba-0.33 Nun wird das ganze mit dem bekannten Dreisatz compiliert und installiert. Um die Software dann zu installieren muss man sich als substitute User (su) anmelden und das root-Passwort wird dazu benötigt. Wer an diesem Punkt noch keinen Compiler installiert hat sollte dies bitte tun.
tux@erde:~ ./configure
tux@erde:~ make
tux@erde:~ su
Password:
tux@erde:# make install Falls es schon bei dem ./configure zu Fehlern kommen sollte sind nicht alle Pakete, welche für die Kompilierung benötigt werden installiert. Weil in dem im Moment erhältlichen Quellcode noch ein kleiner Fehler steckt der dazu führt, dass die Desklets andere Fenster überdecken, sollte man folgende Zeile in der Datei the karamba.cpp auskommentieren:
KWin::setType(winId(), NET::Dock);
Setzt vor diese Zeile einfach ein //.
Das sollte dann so aussehen:
// KWin::setType(winId(), NET::Dock); So nun ist Superkaramba installiert nur wie kann man es aufrufen bzw. starten?
Entweder macht man sich einen Desktoplink oder man ruft es direkt von der Shell auf:
tux@erde:~ superkaramba & Man kann sich auch ein Script zur Hilfe nehmen und packt es in den ~/.kde/Autostart/ Ordner, nennt es karamba.sh, macht es ausführbar mit dem Befehl:
tux@erde:~ chmod 700 karamba.sh Dieses Script sollte diese Zeilen enthalten:
#!/bin/sh
superkaramba /Pfad/zu/dem/Theme/Themename.theme & Somit startet Karamba bzw. Superkaramba direkt.
Nun sollte man schon ein Desklet von dem oben genannten Link heruntergeladen haben, damit man es in diesem Fenster nun auswählen kann. Um dies zu tun wählt man einfach die .theme-Datei aus, welche sich in dem Ordner des heruntergeladenen Desklets befindet. Um weitere Desklets auszuwählen wirft man einfach einen Blick auf das Menü, welches bei einem schon geöffneten Desklet erscheint, wenn man mit der rechten Maustaste darauf klickt.
Der Code
Im Grunde sind wir hier schon fertig, aber man will ja vielleicht auch selber etwas erstellen und wenn es nur eine eigene Bar ist, welche den Kicker ersetzen soll, oder ein Monitor für das System. Als Beispiel wird ab hier das micromon-Package, welches die CPU-, Festplatten-, RAM-Auslastung, sowie die Festplattenbelegung anzeigt genommen.
Wenn man sich das Verzeichnis des micromon anschaut sieht man dort ein micromon.theme und ein Verzeichnis für die Bilder, welche mit angezeigt werden. Dies ist der Ordner images. Wenn man sich nun das micomon.theme anschaut sieht man folgenden Code, welchen ich hier schon ein wenig kommentiere und deswegen Zeilennummern vorn angefügt habe um eine bessere Referenz zu bieten. Zu beachten ist, dass jede Zeile, welche mit einem # am Anfang beginnt ein Kommentar ist und nicht von Karamba beachtet wird.
# Micromon by Flavio Gargiulo (www.flagar.com) is a simplified version
# of Minimon by Simon Ask Ulsnes (simon@ulsnes.dk), that doesn't make
# use of the lm-sensors section.
# Icons by Chip (author of TMon)
#
# This is a rewrite of TMon I made because I wanted something a bit
# more discrete to monitor my system.
# I have changed the font to Cure from the Artwiz fonts package
# (install guide: http://www.linuxquestions.org/questions/history/61294)
# and made the icons transparent. I have also removed the background,
# the graphs and bars, and the uptime monitor (commented out below).
#
# You will surely want to modify this theme for your own computer,
# especially things like the font and the font colour (white by default)
# Also, since I have only one fan in my case (the CPU fan), there is only
# one fan sensor (a permanent zero looks stupid)
#
# Hope you like it
#
(1) karamba x=824 y=548 w=200 h=220 interval=500 locked=true
#
# Icons
(2) image x=0 y=0 path="images/cpu.png"
image x=4 y=30 path="images/mem.png"
image x=7 y=60 path="images/net.png"
image x=4 y=86 path="images/hdd.png"
#image x=8 y=115 path="images/time.png"
# CPU monitor
(3) text x=30 y=4 sensor=cpu format="cpu: 1794 MHz / %v%" color=255,255,255 fontsize=9 interval=500
# Memory monitor
text x=30 y=28 sensor=memory format="ram: %um / %tmmb" color=255,255,220 fontsize=9
text x=30 y=38 sensor=memory format="swap: %us / %tsmb" color=255,255,220 fontsize=9
# Network monitor
(4) text x=30 y=58 sensor=network device="eth1" format="in: %in kb/s" color=220,255,255 fontsize=9 interval=250
text x=30 y=68 sensor=network device="eth1" format="out: %out kb/s" color=255,220,255 fontsize=9 interval=250
#
# Harddrive monitor
(5) text x=30 y=88 sensor=disk mountpoint="/" format="root: %u mb / %up%" color=255,255,255 fontsize=9 interval=10000
text x=30 y=100 sensor=disk mountpoint="/mnt/hda2" format="hda2: %u mb / %up%" color=255,255,255 fontsize=9 interval=10000
text x=30 y=112 sensor=disk mountpoint="/mnt/hdb5" format="hdb5: %u mb / %up%" color=255,255,255 fontsize=9 interval=10000
text x=30 y=124 sensor=disk mountpoint="/mnt/sda7" format="sda7: %u mb / %up%" color=255,255,255 fontsize=9 interval=10000
text x=30 y=136 sensor=disk mountpoint="/mnt/sdb1" format="sdb1: %u mb / %up%" color=255,255,255 fontsize=9 interval=10000
# Uptime display
#text x=30 y=114 sensor=uptime format="uptime: %dd %H:%M" color=255,255,255 fontsize=9
# External program
(6) #text x=30 y=130 sensor=program program="ps aux" fontsize=9 (1)
Hier befinden sich die Angaben über:
Die Postion des Desklets (X und Y)
Die Grösse des Desklets (W und H)
Den Upfreshinterval des Desklets, also die Zeit in welcher das Desklet upgedatet werden soll in Millisekunden (interval) und die Angabe ob das Desklet beweglich sein soll in der Position oder nicht (locked)
(2)
Hier haben wir die Icons für die einzelnen Anzeigen. Wie man nun sieht halten sich die X und Y Angaben an den Rahmen, welcher mit dem Punkt (1) definiert wurde, sprich die Höhen- und Breitenangaben. Die Pfadangabe verhält sich relativ zu dem Pfad unseres Ordners.
(3)
Dies ist nun der erste Einsatzort der eingebauten Sensoren. Auf diese gehe ich später noch genauer ein. Bei dem Format sollte man seine CPU-Leistung eingeben, sprich die 1749MHz gegen den Wert der eigenen CPU austauschen. Auch hier ist der interval wiederzufinden, denn jener kann noch angepasst werden, genauso wie die Schriftgrösse und die Farbe der Schrift.
(4)
Hier sollte als device das richtige angegeben werden, bei den meisten sollte dies eth0 sein.
Innerhalb diese Formattags sieht man zwei Angaben dies sind %in und %out, ich denke sie sind selbsterklärend.
(5)
Hier sollten die richtigen Mountpoints eingepflegt werden. Sprich jene welche in der fstab drin stehen. und unter Format kann man anstelle von hda2 auch /home oder ähnliches eingeben was genau die FSH wiederspiegelt. In meinem Falle wäre dies:
text x=30 y=100 sensor=disk mountpoint="/mnt/hda5" format="Bunker: %u mb / %up%" color=255,255,255 fontsize=9 interval=10000 (6)
Hier ist ein wenig Anpassung nötig. Im ganzen sieht die Zeile so aus:
# External program text x=30 y=130 sensor=program program="ps aux" fontsize=9 color=255,255,255 fontsize=9 Hier wird das Tool Sensor geladen und damit ein ps -aux, ein Anzeigen aller Prozesse gesetzt. Dies bedeutet man muss auch die Größe des gesamten Desklets dieser Ausgabe anpassen. Also schon ein wenig Umcoden des Desklets. Dies kann mit einem Rechtsklick auf das Desklet gemacht werden und mit dem Kommando Edit, oder mit einem Textprogramm wie kate, vi oder pico.
3. Der Code Advanced
Hier nun einige Erklärungen zu den Sensoren und mehr, wie man z.B. das Startmenü in seine selbstgebaute Bar bekommt und Buttons baut um den Desktop zu wechseln.
Parameterübersicht
KARAMBA
Dies definiert das Karambafenster selbst. Ein großes Fenster braucht natürlich mehr Zeit um gezeichnet zu werden, als ein kleines. Somit sollte nie das Karambafentser größer sein, als benötigt.
X - Horizontal Position des Karambafensters
Default: X=0
Y - Vertical Position des Karambafensters
default: Y=0
W - Die Breite des Karambafensters
default: W=300
H - Die HÖhe des Karambafensters
default: W=300
RIGHT - Wenn RIGHT=true gesetzt ist , dann wird das Karambafenster auf der rechten Seite des Bildschirms angezeigt und der X Paramter ignoriert.
default: RIGHT=false
BOTTOM - Das gleiche wie bei Right, nur dass es der untere Screen ist. Der Y Paramter wird ignoriert.
ONTOP - ONTOP=true zeigt das Karambafenster immer über allen anderen Desktopfenstern.
default: ONTOP=false
TOPBAR - TOPBAR=true zeigt das Fenster am oberen Bildschirmrand an und vergrösserte Fenster überdecken somit das Karambafenster nicht. Somit kann man dann das Karambadesklet wie den Kicker unter KDE einsetzen. Aber Achtung, das Karambafenster kann da nicht bewegt werden.
default: TOPBAR=false
BOTTOMBAR - BOTTOMBAR=true ist das gleich wie TOPBAR=true, nur diesmal betrifft es den unteren Bildschirmrand.
default: BOTTOMBAR=false
INTERVAL - Ist die Rate in welcher das Desklet neu geschrieben werden soll. Die Angaben werden in Millisekunden gerechnet.
default: INTERVAL=5000
LOCKED - A LOCKED=true bedeutet, dass das Karambafenster nicht per Click'n'move bewegt werden kann. Dies kann aber auch per Rechtsclick auf das Desklet nachträglich geändert werden.
default: LOCKED=false
Maßangaben
IMAGE
Zeigt ein Bild an einer fest definierten Position an. Das Bild kann nicht zu einen Sensor verbunden werden, denn die Werte des Sensors würden als Bildpfad interpretiert werden. Bilder mit Transparenz können benuztzt werden.
X - Horizontale Position des Bildes gesehen vom oberen rechten Rand.
Y - Vertikale Position des Bildes gesehen vom oberen linken Rand.
PATH - Der Pfad zu dem Bild und zwar relativ zu dem config.-File
Beispiele:
IMAGE X=10 Y=10 PATH="/tmp/pic.png"
IMAGE X=10 Y=10 PATH="http://your-site.se/image.jpg"
IMAGE X=10 Y=10 SENSOR=PROGRAM PROGRAM="pictures.pl"
TEXT
Zeigt einen Text an einer fest definierten Position an. Man kann die Höhe und Breite angeben und außerhalb dieses Bereiches wird kein Text angzeigt, dieser Punkt ist aber nur Optional. Alle Sensoren können mit einer Textangabe als Maß verbunden werden.
X - Horizontale Position des Textes gesehen vom oberen rechten Rand.
Y - Vertikale Position des Textes gesehen vom oberen linken Rand.
W - Die Breite des Textbereiches, optional
H - Die Höhe des Textbereiches, optional
VALUE - Der Text
ALIGN - Setzt die Anordnung des Textes Möglich sind:
LEFT|CENTER|RIGHT
default: ALIGN=LEFT
FONT - Welche Schrift benutzt werden soll
FONTSIZE - Die Grösse der Schrift
COLOR - Die Textfarbe, COLOR=0..255,0..255,0..255
default: COLOR=0,0,0
BGCOLOR - Schattenfarbe des Textes
default: BGCOLOR=0,0,0
SHADOW - Setzt einen Schatten für den Text und zwar n Pixel vom Text enfernt. Diese Angabe kann auch negativ sein.
default: SHADOW=0
Beispiel: SHADOW=2
FIXEDPITCH - Setzt einen kleinen Zwischenbereich zwischen die einzelnen Buchstaben.
default: FIXEDPITH=false
Beispiele:
TEXT X=0 Y=0 VALUE="Test string"
TEXT X=0 Y=0 SENSOR=CPU COLOR=255,0,0 FONT="arial" SENSOR=CPU
BAR
Zeigt einen Balken an, welcher wie ein Fortschrittsbalken ist. Dieser Balken wird mit Hilfe eines Bildes angezeigt, welches in der Pfadangabe steht. Hier können auch transparente oder semitransparente Bilder genutzt werden. Wenn die Angaben W und H nicht genuztzt werden , dann wird die Größe des Bildes, welches angegeben wurde genutzt. Als Default wird der Balken von Links nach rechts angezeigt, aber auch ein vetrtikaler Balken ist möglich, dazu wird die Option Vertical genutzt.
X - Horizontale Position gesehen vom oberen rechten Rand.
Y - Vertikale Position gesehen vom oberen linken Rand.
W - Die Breite des Balkens, optional
H - Die Höhe des Balkens, optional
PATH - PATH - Der Pfad zu dem Bild des Balkens und zwar relativ zu dem config.-File
VERTICAL - Der Balken wird Vertikal angezeigt
default: VERTICAL=false
VALUE - Wert des Balkens Bsp.: MB GB usw...
default: VALUE=0
MIN - Die minimalste Einheit des Balkens, kann von einem Sensor überschrieben werden.
default: MIN=0
MAX - Die maximalste Einheit für den Balken, kann von einem Sensor überschrieben werden.
default: MAX=100
Beispiele:
BAR X=0 Y=0 W=10 H=200 VERTICAL=true PATH="img.png" SENSOR=CPU
BAR X=0 Y=0 PATH="img.png" MIN=30 MAX=60 SENSOR=CPU
GRAPHEN
Zeigt einen Graphen an, welcher von rechts nach links verläuft.
X - Horizontale Position gesehen vom oberen rechten Rand.
Y - Vertikale Position gesehen vom oberen linken Rand.
W - Die Breite des Graphen, optional
H - Die Höhe des Graphen, optional
POINTS - Anzahl der Punkte in dem Graphen
MIN - Die minimalste Einheit des Graphen, kann von einem Sensor überschrieben werden.
default: MIN=0
MAX - Die maximalste Einheit für den Graphen, kann von einem Sensor überschrieben werden.
default: MAX=100
COLOR - Die Farbe des Graphen, COLOR=0..255,0..255,0..255
default: COLOR=0,0,0
Examples:
GRAPH X=0 Y=0 W=200 H=60 POINTS=100 SENSOR=CPU
SENSOREN
CPU
Dieser Sensor zeigt die momentane CPU-Auslastung an. Es können auch mehrere Prozessoren angezeigt werden. Der INTERVAL-Parameter der ersten CPU gilt auch für alle darauf folgenden CPUs. Es kann aber auch ein anderer Interval durch einen weiteren Sensor für die zweite CPU angegeben werden. INTERVAL - Ist die Rate in welchen Abständen der CPU-Sensor abgetastet werden soll. Die Angabe erfolgt auch hier in Millisekunden.
default: INTERVAL=1000
CPU - Die Nummer der CPU, sehr wichtig , wenn man mehr als eine hat.
CPU=0 - Die erste CPU
CPU=1 - Die zweite CPU
CPU=all - Die Auslastung aller Prozessoren.
default: CPU=all
FORMAT
%v - Die CPU Auslastung
%load - Das gleiche wie %v
%user - Die Auslastung durch den Benutzer
%system - Die Auslastung durch das System
%nice - Die Niceauslastung
%idle - Die Idleauslastung
default: FORMAT="%v"
Beispiel: FORMAT="CPU load: %v"
MEMORY
Dieser Sensor gibt Auskunft über den Speicher und den Swapspeicher. Der INTERVAL-Parameter des ersten Speichersensors, welcher in dem Config-File angeben wird, wird für alle darauf folgenden Speichersensoren genutzt.
INTERVAL - Ist die Rate in der der Speichersensor abgetastet werden soll. Die Angabe erfolgt ebenfalls in Millisekunden.
default: INTERVAL=3000
FORMAT
%fm - Freier Speicher in Megabytes
%fmb - Freier Speicher in Megabytes (cache and buffers excluded)
%um - Benutzter Speicher in Megabytes
%umb - Benutzter Speicher in Megabytes (cache and buffers excluded)
%tm - Kompletter Speicher in Megabytes
%fs - Freier Swap in Megabytes
%us - Benutzter Swap in Megabytes
%ts - Kompletter Swap in Megabytes
default: FORMAT="%um"
Beispiel: FORMAT="Freier Speicher: %fm MB"
DISK
Dieser Sensor gibt Auskunft über die gemounteten HDs. Das Network File System (NFS) kann auch angezeigt werden. Der INTERVAL-Parameter des ersten Disksensors, welcher in dem Config-File angegeben wird, wird für alle darauf folgenden Disksensoren genutzt.
INTERVAL - Ist die Rate in welcher der Disksensor abgetastet werden soll. Auch diese Wertangabe erfolgt in Millisekunden.
default: INTERVAL=5000
FORMAT
%f - Freier Festplattenspeicher in Megabytes
%fp - Prozentangabe des freien Speichers.
%u - Benutzter Destplattenspeicher in Megabytes
%up - Prozentangabe des benuzten Festplattenspeichers.
%t - Gesamte Festplattengröse in Megabytes
default: FORMAT="%u"
Beispiele: FORMAT="Free space: %f MB"
FORMAT="Used space: %up %"
MOUNTPOINT
default: MOUNTPOINT="/"
Beispiel: MOUNTPOINT="/mnt/home"
NETWORK
Dieser Sensor gibt Auskunft über den Netzwerkverkehr. Der INTERVAL-Parameter des ersten Netzwerksensors, welcher in dem Config-File angeben wird, wird für alle darauf folgenden Netzwerksensoren genutzt.
INTERVAL - Ist die Rate in welcher der Netzwerksensor abgetastet werden soll. Auch hier erfolgt die Angabe in Millisekunden.
default: INTERVAL=2000
DEVICE - Ist der Netzwerkanschluss , welcher genutzt werden soll.
default: DEVICE="eth0"
Beispiel: DEVICE="ppp0"
FORMAT
%in - Eingehender NetzwerkTraffic in kilobytes / s
%out - Ausgehender NetzwerkTraffic in kilobytes / s
default: FORMAT="%in"
Beispiel: FORAMT="Eingehender : %in kb/s"
DECIMALS
Dezimalwert für die Netzwerkmessung.
default: DECIMALS=0
TIME
Dieser Sensor ist für die Zeitangabe zuständig. Der INTERVAL-Parameter des ersten Zeitsensors, welcher in dem Config-File angeben wird, wird für alle darauf folgenden Zeitsensoren genutzt.
INTERVAL - Ist die Rate in welchen Zeitabständen der Zeitsensor abgetastet werden soll. Auch hier erfolgt die Angabe in Millisekunden.
default: INTERVAL=60000
FORMAT
d - Der Tag ohne anführende Null (1-31)
dd - Der Tag mit anführender Null (01-31)
ddd - Der abgekürzte lokalisierte Tagesname (Bsp. 'Mon'..'Son')
dddd - Der ausführliche lokalisierte Tagesname (Bsp.'Montag'..'Sonntag')
M - Der Monat ohne anführende Null (1-12)
MM - Der Monat mit anführender Null (01-12)
MMM - Der abgekürzte lokalisierte Monatsname (Bsp. 'Jan'..'Dez').
MMMM - Der ausführliche lokalisierte Monatsname (Bsp. 'Januar'..'Dezember').
yy - Das Jahr zweistellig (00-99)
yyyy - Das Jahr vierstellig (1752-8000)
h - Die Stunde ohne anführende Null (0..23 or 1..12 wenn AM/PM angezeigt wird)
hh - Die Stunde mit anführender Null (00..23 or 01..12 wenn AM/PM angezeigt wird)
m - Die Minuten ohne anführende Null (0..59)
mm - Die Minuten mit anführender Null (00..59)
s - Die Sekunden ohne anführende Null (0..59)
ss - Die Skunden mit anführender Null (00..59)
z - Die Millisekunden ohne anführende Null (0..999)
zzz - Die Millisekunden mit anführender Null (000..999)
AP - Benutzt AM/PM Anzeige. AP wird mit "AM" oder "PM" ausgetauscht.
ap - Benutzt am/pm Anzeige. ap wird mit "am" or "pm" ausgetauscht.
Beispielformate (Hier wird Datum und Zeit mit dem 21ten Mai 2001 14:13:09 genutzt)
FORMAT="dd.MM.yyyy" -> 21.05.2001
FORMAT="ddd MMMM d yy" -> Die Mai 21 01
FORMAT="hh:mm:ss.zzz" -> 14:13:09.042
FORMAT="h:m:s ap" -> 2:13:9 pm
UPTIME
Dieser Sensor zeigt an, wie lange das System seit dem letzten Start läuft. Der INTERVAL-Parameter des ersten Uptimesensors, welcher in dem Config-File angegeben wird, wird auch für alle darauf folgenden Uptimesensoren genutzt.
INTERVAL - Ist die Rate in welchen Zeitabständen der Uptimesensor abgefragt werden soll. Auch hier erfolgt wieder die Angabe in Millisekunden.
default: INTERVAL=60000
FORMAT
%d - Tage
%h - Stunden
%m - Minuten
%s - SeKunden
%H - Stunden mit anführender Null
%M - Minuten mit anführender Null
%S - Seconds mit anführender
default: FORMAT="%dd %h:%M"
SENSOR
Dieser Sensor kann CPU-Temperatur, Lüftergeschwindigkeit, Spannung und noch weiteres mehr anzeigen. Das Programm sensors wird gebraucht, damit dieser Sensor arbeiten kann. Der INTERVAL-Parameter des ersten Sensors, welcher in dem Config-File angeben wird , wird für alle darauf folgenden Sensoren genutzt.
INTERVAL - Ist die Rate in welchem Zeitabstand der Sensor abgetatstet werden soll. Auch hier gilt wieder die Angabe in Millisekunden.
default: INTERVAL=30000
FORMAT
%v - Der Wert des Sensoren
default: FORMAT="%v"
Beispiel: FORMAT="Lüftergeschwindigkeit: %v"
TYPE
default: TYPE="temp2"
Lässt das Sensorprogramm mit den erhältlichen Anzeigen laufen.
Beispiel:
TYPE="fan1"
TEXTFILE
Dieser Sensor liest Textfiles jeglicher Art. Mit diesem Sesnor lassen sich Logfiles in Realzeit anzeigen oder auch ein Newsticker. Der INTERVAL- und ENCODING-Parameter des ersten Textsensors, welcher in dem Config-File angeben wird, wird auch hier wieder für alle darauf folgenden Textsensoren genutzt, welche den gleichen Pfad haben.
INTERVAL - Ist die Rate in welchem Zeitabstand der Textsensor abgetatstet werden soll. Hier gilt ebenfalls, Angaben sind in Millisekunden.
default: INTERVAL=60000
PATH
Der Pfad zu dem Textfile
Beispiel:
PATH="/var/log/messages"
ENCODING
Mit diesem Parameter kann ein anderer Zeichesatz angezeigt werden, wenn dies von Nöten ist. Eine Liste der Codings kann in der QTextCodec Class Reference gefunden werden.
Default: ENCODING="" - Die eigene locale wird genuztzt.
Beispiele:
ENCODING="KOI8-R"
ENCODING="ISO8859-6"
LINE
Mit dem Parameter LINE wird nur eine Zeile angezeigt, welche in dem angwählten Text emthalten ist.
LINE=1 - Die erste Zeile des Textfiles
LINE=2 - Die zweite Zeile des Textfiles
LINE=-1 - Die letzte Zeile des Textfiles
LINE=-2 - Die vorletzte Zeile des Textfiles
RDF
Es muss RDF=true gesetzt werden, wenn des Textfiles ein RDF/RSS-Feed ist
default: RDF=false
NOATUN
Mit diesem Sensor kann eine Anzeige für Noatun und eine Fernsteuerung gestaltet werden. Der INTERVAL-Parameter des ersten Noatunsensors, welcher in dem Config-File angeben wird, wird für alle darauf folgenden Noatunsensoren genutzt.
INTERVAL - Ist die Rate in welchem Zeitabstand der Noatunsensor abgetastet werden soll Auch hier kommen als Zeiteinheit wieder unsere Millisekunden zum Einsatz.
default: INTERVAL=1000
FORMAT
%id - Der noatun dcop Name ist sehr wichtig, wenn man eine Clickarea angibt.
Beispiel:
onclick="dcop %v Noatun play" sensor=noatun format="%id"
%title - Titel des laufenden Songes
%time - Zeit des laufenden Songes
%remain - Verbleibende Zeit des gerade laufenden Songes
%length - Länge des laufenden Songes
%full - Dieser Sensor Gibt den MAX-Wert zurück wenn Noatun gestartet ist, sonst 0.
%full ist sehr nützlich, wenn der Sensor mit einem BAR verbunden ist, somit wird das Bild des Balkens nur angezeigt, wenn Noatun läuft.
default: FORMAT="%title %time / %total"
XMMS
Mit diesem Sensor ist das Gegenstück für XMMS des Noatunsensors.
Der INTERVAL und ENCODING-Parameter des ersten XMMS-Sensors, welcher in dem Config-File angeben wird, wird für alle darauf folgenden XMMS-Sensoren genutzt.
INTERVAL - Ist die Rate in welchem Zeitabstand der XMMS-Sensor abgetastet werden soll. Angabe auch hier wieder in Millisekunden.
default: INTERVAL=1000
ENCODING
Mit diesem Paraneter kann ein anderer Zeichensatz angezeigt werden, wenn dies von Nöten ist. Eine Liste der Codings kann in der QTextCodec Class Reference gefunden werden.
Default: ENCODING="" - Die eigene locale wird genuztzt.
Beispiele:
ENCODING="KOI8-R"
ENCODING="ISO8859-6"
FORMAT
%title - Titel des laufenden Songs
%time - Zeit des laufenden Songs
%remain - Verbleibende Zeit des gerade laufenden Songs
%length - Länge des laufenden Songs
%full - Dieser Sensor Gibt den MAX-Wert zurück wenn XMMS gestartet ist, sonst 0.
%full ist sehr nützlich, wenn der Sensor mit einem BAR verbunden ist. Somit wird das Bild des Balkens nur angezeigt, wenn XMMS läuft.
default: FORMAT="%title %time / %total"
PROGRAM
Dieser Sensor ist dafür da um ein Programm laufen zu lassen und dieses dann auf einem Meter auszugeben. Der INTERVAL und ENCODING-Parameter des ersten Sensors, welcher in dem Config-File angeben wird, wird für alle darauf folgenden Sensoren genutzt, welche den identischen Programmnamen haben, inklusive den Programmparametern
INTERVAL - Ist die Rate in welchem Zeitabstand der Sensor abgetastet werden soll, auch hier wieder in Millisekunden.
default: INTERVAL=3600000
PROGRAM
Das Programm, welches laufen soll
Beispiel:
PROGRAM="ftpwho -v"
ENCODING
Mit diesem Paraneter kann ein anderer Zeichesatz angezeigt werden, wenn dies von Nöten ist. Eine Liste der Codings kann in der QTextCodec Class Reference gefunden werden.
Default: ENCODING="" - Die eigene locale wird genuztzt.
Beispiele:
ENCODING="KOI8-R"
ENCODING="ISO8859-6"
LINE
Mit dem Parameter LINE wird nur eine Zeile angezeigt, welche in dem angwählten Text ist.
LINE=1 - Die erste Zeile des Textfiles
LINE=2 - Die zweite Zeile des Textfiles
LINE=-1 - Die letzte Zeile des Textfiles
LINE=-2 - Die vorletzte Zeile des Textfiles
DEFAULTFONT
Der Nutzen des Defaulfonttags ist , jener dass er für alle Texte geltend gesetzt werden kann. Wenn nun der DEFAULTFONT gesetzt ist kann damit der Texttag verkleinert werden und nur noch als DEAFAULTFONT gesetzt werden. Die Ausnahme ist, wenn der Text-Tag eigene Parameter gesetzt hat. Diese Paramter überschreiben dann den DEFAULTFONT. Sprich der Text muss nicht weiter spezifiziert werden.
Beispiel:
DEFAULTFONT shadow=2 color=255,0,0
text x=0 y=0 value="test"
DEFAULTFONT font="times" fontsize=10 color=255,0,0
text x=0 y=40 value="test" font="arial"
text x=0 y=80 value="test" color=0,0,0
CLICKAREA
Dieser Tag definiert einen klickbaren Bereich. Von diesem Punkt aus, kann dann ein Programm gestartet werden. Ein Doppelklick auf diesen Bereich ist nur nötig wenn das Karambafenster nicht gelocked ist. Der CLICKAREA-Tag wird wie ein Meter benutzt, dies bedeutet es können auch dort Sensoren vorhanden sein.
X - Horizontale Position gesehen vom oberen rechten Rand.
Y - Vertikale Position gesehen vom oberen linken Rand.
W - Die Breite des klickbaren Bereiches
H - Die Höhe des klickbaren Bereiches.
PREVIEW - Wenn PREVIEW mit 'true' gesetzt wurde wird ein Rechteck um den Bereich angezeigt
ONCLICK - Das Programm, welches gestartet werden soll bei einem Klick.
%v wird mit dem Wert des Sensors ersetzt.
Beispiel:
CLICKAREA X=0 Y=0 W=100 H=10 ONCLICK="kdialog --msgbox 'CPU load: %v'" SENSOR=CPU
Dieses Beispiel zeigt eine Dialogbox, welche die momentane CPU-Last zeigt. Man könnte dort auch die Shell unterbingen oder sonst ein anderes Programm, dies ist z.B. sehr wichtig, wenn man sich eine eigene Toolbar baut, dazu aber später mehr.
Der Group-Tag ist ein sehr wichtiger Tag, denn damit lassen sich Elemente in Gruppen zusammenfassen. Dies macht es sehr leicht Elemnte hinzuzufügen und wieder zu entfernen, da man nicht alle x- und y-Werte neu setzen muss. Es können auch Gruppen in Gruppen erstellt werden.
X - Horizontale Position der Gruppe gesehen vom oberen rechten Rand.
Y - Vertikale Position der Gruppe gesehen vom oberen linken Rand.
Beispiel:
TEXT X=0 Y=0 VALUE="test1"
TEXT X=10 Y=10 VALUE="test2"
Wie man in diesem Beispiel sieht fangen die Icons innerhalb der Gruppe immer mit einem neuen X=0 Wert an.
4. Das Nutzen von Scripten
Um nun Karamba noch ein wenig zu erweitern kann man noch Perl- und Pythonscripte mit einbauen, welche verschiedene Dinge ausführen, wie z.B. einen Kalender darstellen, nach Mails sehen, das Wetter anzeigen und auch eine Webcam einbinden. Dort sind auch verbesserte Scripte für den XMMS-Player zu finden. Bei einem Blick auf KDE-Look.org lassen sich dort einige in den vorgefertigten Desklets finden und durch die GPL auch nutzen.Ein Blick auf die Karambahomepage weist schon vier Skripte zum downloaden auf.
5. Das Nutzen von DCOP für einen eigenen Kicker
DCOP setzt auf der X11-Standardbibliothek libICE auf und ist mit seiner BSD-Lizenz frei verfügbar. DCOP wurde auf der KDE II Konferenz im Oktober 1999 als Umstieg auf ein eigenes Protokoll namens DCOP (Desktop COmmunication Protocol) entschieden. DCOP ist eine ressourcensparende Middleware zur Kommunikation von Applikationen, die auf der X11-Standardbibliothek libICE aufsetzt. Vorgestellt wurde DCOP von Matthias Ettrich (KDE-Gründer) und Preston Brown.
Hardcore Interna, kann überlesen werden ;):
Eine typische, standard-konforme X11-Anwendung ist über zwei Bibliotheken an jeweils einen Server-Prozess gebunden, über libX11 an den X-Server und über libSM an den Session-Management-Server. libSM widerum ist nur eine verhältnismäßig kleine Protokollimplementierung auf der Grundlage von libICE, einer allgemeinen Kommunikationsbibliothek, deren Design das Multiplexing verschiedener Protokolle über eine Verbindung ermöglicht.
Applikation
- libX11 <-----------------> XServer
- libSM <----------> SMServer
- libICE
DCOP macht sich nun zu nutze, daß jede Anwendung bereits über libICE verfügt und damit die Bibliothek bereits im Arbeitsspeicher vorhanden ist. Über libDCOP wird ein weiteres Protokol, eben DCOP, auf ICE aufgesetzt. Mit diesem greift die Anwendung auf einen dritten Server, dem DCOP-Server, zu.
Applikation
- libX11 <-----------------> XServer
- libDCOP <--------> DCOPServer
- libSM <----------> SMServer
- libICE
Der DCOP-Server ist ein Prozess der ständig auf dem Desktop läuft. Jeder Client muß sich einmalig bei ihm anmelden und kann dann mit jedem anderen Client auf dem Desktop kommunizieren. Bei der Anmeldung erhält jeder Client einen eineindeutigen Namen, über den er jederzeit identifiziert werden kann. Der DCOP-Server steht wie ein Verkehrspolizist in der Mitte der Kreuzung und regelt die Kommunikation zwischen den Clients. Diese Eigenschaft brachte ihm (neben dem offensichtlichem Grund: Desktop COmmunication Protocol) seinen Namen, er wurde in Anlehnung an den Traffic-COP, als Desktop-COP bezeichnet.
Das Design mit einem DCOP-Server in der Mitte hat 3 entscheidende Vorteile:
1.Man bekommt einen Naming-Service umsonst mit dazu. Es wird einfach, laufende Anwendungen zu lokalisieren.
2.Es werden wenig Verbindungen gebraucht (n Verbindungen für n Anwendungen), für Anfragen müssen nicht extra neue Verbindungen geöffnet werden. Dadurch ergibt sich eine sehr kurze Latenzzeit auch für den jeweils ersten Aufruf.
3.Ermöglicht sehr schnelle Massensendungen (broadcasts).
Es werden 2 Arten der Kommunikation zwischen Clients unterstützt:
Fire and Forget (asynchrones Senden)
Call and Listen (synchroner Aufruf)
Bei Fire and Forget sendet Client A eine Nachricht an Client B. Es handelt sich um eine einseitige Kommunikation, wobei Client B auch mehrere Applikationen seien können (Broadcasts). Client A hat bei dieser Art der Kommunikation keine Möglichkeit zu überprüfen, ob die Nachricht bei allen Clients angekommen ist, es interessiert Client A auch nicht. Call and Listen behebt diesen Nachteil. Hierbei erwartet Client A eine Reaktion von Client B. A ist also im Stande zu überprüfen, ob seine versendete Nachricht alle Empfänger erreicht hat und kann gegebenenfalls auf die Antwort reagieren; es handelt sich um eine zwei-, bzw mehrseitige Kommunikation.
Die synchronen Aufrufe sind dafür leider langsamer als das asynchrone Senden. Der Entwickler hat im konkreten Fall die Entscheidung zu treffen,was ihm wichtiger ist. Ein sicheres Ankommen mit einer Antwortmöglichkeit einerseits, oder das schnellere (nicht abgesicherte) Versenden einer Nachricht andererseits. Beide Methoden haben ihre Berechtigung für die Kommunikation auf dem Desktop.
So nun geht es ein bischen einfacher weiter, und wir wissen was der DCOP macht bzw. wofür DCOP da ist.
Für DCOP gibt es einige Anleitungen im Netz und der Aufruf des DCOP-Browser unter KDE funktioniert mit ALT+F2 und kdcop. Dieser ist aber Bestandteil eines weiteren Turtorials meinerseits, welches noch folgen wird. Hier gebe ich nur ein paar Beispiele, dass man auch seinen Kicker durch eine eigene Leiste ersetzen kann.
Der eigene Kicker
So, da oben einige Desklets angesprochen wurden kommt nun der SelfmadeKicker. Dieser Kicker ist im oberen Bereich des Dekstops und beinhaltet zum Aufzeigen der Funktionen keine Groups. Er hat XMMS Unterstützung, Desktopwechseln, das KDE Startmenü, Uhr, Statusleiste, Netzwerk und vieles mehr. Ich habe den Code nur noch an den Stellen kommentiert, welche definitiv nicht oben schon genannt wurden. Wichtig sind in diesem Punkt die DCOP Aufrufe. Diese Leiste hat dieses Aussehen
# written by Seraphyn
# Icons Umicons made by norbalin www.kde-look.org
# general
KARAMBA X=0 Y=0 W=1280 H=40 interval=1000 locked=true topbar=true ontop=true BGCOLOR=0,0,0
#K Menu
image x=4 y=6 path="pics/aboutkde.png"
CLICKAREA X=4 Y=6 W=32 H=25 ONCLICK="dcop kicker kicker popupKMenu 0"
# Dies ist der Aufruf für das Startmenü, welches normalerweise auf dem Kicker ist.
# Die 0 am Schluss bedeutet, das genau dort das Menü erscheinen soll wo geklickt wird.
# Dies kann auch an einem eigenen Ort gestellt werden, einfach mal mit Zahlen spielen ;)
#Apps
#shell
image x=60 y=6 path="pics/display.png"
CLICKAREA X=60 Y=6 W=32 H=25 ONCLICK="konsole"
#workspaces up and down
image x=650 y=5 path="pics/downarrow.png"
CLICKAREA X=650 Y=5 W=24 H=24 ONCLICK="dcop kwin KWinInterface nextDesktop"
image x=680 y=5 path="pics/uparrow.png"
CLICKAREA X=680 Y=5 W=24 H=24 ONCLICK="dcop kwin KWinInterface previousDesktop"
# Hier ist der nächste DDCOP Aufruf, welcher zum Wechseln des Desktops vorhanden ist
# Ich denke mal er dürfte auch leicht zu verstehen sein, was jener macht ;)
#xmms
image x=740 y=11 path="pics/2leftarrow.png"
image x=760 y=10 path="pics/stop.png"
image x=780 y=10 path="pics/pause.png"
image x=800 y=10 path="pics/1rightarrow.png"
image x=820 y=11 path="pics/2rightarrow.png"
clickarea x=740 y=11 w=18 h=17 onclick="xmms --rew" preview=false
clickarea x=760 y=10 w=19 h=19 onclick="xmms --stop" preview=false
clickarea x=780 y=10 w=19 h=19 onclick="xmms --pause" preview=false
clickarea x=800 y=10 w=19 h=19 onclick="xmms --play" preview=false
clickarea x=820 y=11 w=18 h=17 onclick="xmms --fwd" preview=false
#XMMS hat in dem Sinne keinen DCOP aufruf, aber es gibt noch Zusätze welche
#mehr Anzeigen wie z.B. den Songtitel, einfach mal so einen Quellcode anschauen bei KDE-Look.org
# Disk 1
bar x=950 y=6 w=60 h=5 vertical=false path="pics/hdfuller.png" sensor=disk mountpoint="/home"
text x=1055 y=1 sensor=disk mountpoint="/home" format="%f M" align=right color=0,0,0 fontsize=7 font="verdana"
#text x=1005 y=1 sensor=disk mountpoint="/home" format="%up %" align=right color=0,0,0 fontsize=7 font="verdana"
text x=950 y=1 value="Home" color=0,0,0 align=left fontsize=7 font="verdana"
#
CLICKAREA x=950 y=6 w=24 h=22 ONCLICK="kdf"
# Disk 2
bar x=950 y=18 w=110 h=5 vertical=false path="pics/hdfuller.png" sensor=disk mountpoint="/Bunker"
text x=1055 y=14 sensor=disk mountpoint="/Bunker" format="%f M" align=right color=0,0,0 fontsize=7 font="verdana"
#text x=1005 y=14 sensor=disk mountpoint="/Bunker" format="%up %" align=right color=0,0,0 fontsize=7 font="verdana"
text x=950 y=14 value="Bunker" color=0,0,0 align=left fontsize=7 font="verdana"
# Disk 3
bar x=950 y=31 w=110 h=5 vertical=false path="pics/hdfuller.png" sensor=disk mountpoint="/Bunker2"
text x=1055 y=27 sensor=disk mountpoint="/Bunker2" format="%f M" align=right color=0,0,0 fontsize=7 font="verdana"
text x=950 y=27 value="Bunker2" color=0,0,0 align=left fontsize=7 font="verdana"
# network
image x=1060 y=6 path="pics/connectestablished.png"
# Network (eth0)
# In
text x=1135 y=4 sensor=network device="eth0" format="%in kB/s<" align=right color=0,0,0, fontsize=8 font="verdana" interval=250
#
# Out
text x=1135 y=22 sensor=network device="eth0" format="%out kB/s>" align=right color=0,0,0, fontsize=8 font="verdana" interval=250
#tray apps
# Klipper Button
IMAGE x=1145 y=2 w=16 h=16 SENSOR=PROGRAM PROGRAM="echo pics/mini-`dcop | grep klipper`.png"
CLICKAREA x=1145 y=2 w=16 h=16 ONCLICK="dcop klipper 'qt/main_menu' showNormal"
# Kmix Button
IMAGE x=1145 y=21 w=16 h=16 SENSOR=PROGRAM PROGRAM="echo pics/mini-`dcop | grep kmix`.png"
CLICKAREA x=1145 y=21 w=16 h=16 ONCLICK="dcop kmix kmix-mainwindow#1 restore"
# LogOut
IMAGE x=1165 y=2 w=16 h=16 path="pics/logout.png"
CLICKAREA x=1165 y=2 w=16 h=16 ONCLICK="dcop ksmserver ksmserver logout 1 0 -1"
# Dies sind nun DCOP Aufrufe, welche die wichtigsten Anwendungen in der Systemleiste
# Des ehemaligen Kickers verwenden. Es ist auch möglich,
#z.B. SIM dort unter zu bringen, den
# Vorstellungen sind dort keine Grenzen gesetzt.
x=1200 y=5
text x=38 y=-2 sensor=time format="hh:mm:ss" font="verdana" color=0,0,0 fontsize=13 shadow=0 align=center interval=500
text x=38 y=13 sensor=time format="ddd dd.MM.yy" color=0,0,0 fontsize=10 align=center shadow=0
#click on the time to edit the time/date
CLICKAREA X=10 Y=0 W=60 H=20 ONCLICK="kdesu /sbin/yast2 'timezone'"
# Hier wurde nun zu der Zeit noch ein KDESU, welches als root ein Prgramm ausführt eingesetzt
# In dem Falle wird YAST unter Suse ausgeführt mit dem Aufruf, dass die Zeit geändert werden soll
Diese Bar ist sehr einfach und es lässt sich noch mehr hinzufügen oder auch weglassen.
6. Die goldenen Regeln
Wenn mal was nicht so funktioniert, wie es soll, sollte man diese Regeln beachten:
1.Ist alles in einer Zeile, was in eine gehört ?
2.Ist alles richtig geschrieben ?
3.Sind die Pfadangaben richtig ?
4.Scripte per chmod u+x XXX.py/pl ausführbar gemacht ?
5.Stimmen die Rechte
6.Sind alle Icons bzw. Bilder vorhanden ?
Ich hoffe ich konnte ein klein wenig Licht in das Dunkel bringen.
Und wünsche viel Spass beim Coden
Gruß
Seraphyn
