UNIXwork

Gnome 3 hat das nette Feature, dass ein GTK-Theme eine light und eine darkVariante hat, und einzelne GTK-Anwendungen können sich aussuchen, welche Theme-Variante sie nutzen wollen. Nutzt eine Anwendung jedoch nicht GTK, so gibt es trotzdem eine Möglichkeit zumindestens einen dunklen Fenster-Rahmen zu erhalten.

Welche Farbe ein Fenster hat, hängt nur von einer X-Property ab. Starten wir einfach mal xprop und klicken auf ein dark-theme-Fenster, dann gibt das Programm alle Properties aus. Darunter findet sich dann auch diese Zeile:

_GTK_THEME_VARIANT(UTF8_STRING) = "dark"

Man kann mit xprop auch Properties setzen:

xprop -f _GTK_THEME_VARIANT 8u -set _GTK_THEME_VARIANT "dark" 

Klickt man dann auf ein Fenster, müsste seine Titelleiste das dark theme nutzen.

Um das gleiche in C mit der xlib zu machen, reicht folgender Code:

void set_dark_theme(Display *dp, Window window) {
	Atom atom = XInternAtom(dp, "_GTK_THEME_VARIANT", False);
	Atom type = XInternAtom(dp, "UTF8_STRING", False);
	XChangeProperty(
	        dp, 
	        window, 
	        atom,
	        type,
	        8,
	        PropModeReplace,
	        (const unsigned char*)"dark",
	        4);
}

Die üblichen Schritte beim Kompilieren von Open-Source-Software sind:

./configure --prefix=/usr
make
make install

Damit kompiliert man die Software und installiert sie unter /usr. Es kann vorkommen, dass man die Dateien woanders hin installieren möchte, als bei configure angegeben (z.B. beim Erstellen von Packages). Nach dem Kompilieren nochmal ./configure aufrufen wäre falsch. Die richtige Methode ist bei make install den DESTDIR-Parameter mit anzugeben.

make install DESTDIR=/path

Damit wird beispielsweise eine Datei nicht nach $PREFIX/bin installiert, sondern nach $DESTDIR$PREFIX/bin.

Wer keine GNU autotools nutzt, sondern Makefiles per Hand schreibt, sollte bei seinem install-Target daher vor jedem Installationsort ein $(DESTDIR) einfügen, damit Paketbauer nicht die Dateien von Hand zusammen sammeln müssen.

• xattr(1) Mac OS X Manual Page
• CommonExtendedAttributes
• Extended attributes: the good, the not so good, the bad.

Wer hätte gedacht, dass man beim Kauf eines USB-Serial-Adapter etwas falsch machen kann. Ich hab kürzlich ein QinHeng Electronics HL-340 USB-Serial Adapter gekauft und das Teil kann man echt nicht empfehlen. Linux hat zwar den ch341-Treiber dafür, der funktioniert jedoch nicht gut. Nach dem Anschließen taucht ein Device /dev/ttyUSB0 auf, der Versuch davon zu lesen liefert aber nur Datenmüll (ja, die Baud-Rate und andere Settings waren korrekt eingestellt).

Eine Recherche im Internet hat ergeben, dass genügend andere Leute das gleiche Problem haben, oder ganz andere Probleme, auch unter Windows. Manche haben es hingekriegt, indem sie am Treiber rumgehackt haben. Ich kaufe mir lieber was ordentliches. Empfehlenswert sollen wohl Produkte mit Prolific-Chip sein.

Programmiertechnisch sind Extended Attributes unter Solaris nur Dateien, daher gibt es keine speziellen Syscalls für den Zugriff darauf.

Eine Attribut-Datei öffnen kann man mit openat. Hierfür benötigt man nur einen File-Descriptor der Datei, von der man ein Attribut öffnen will. Es muss dann nur noch das O_XATTR-Flag zusätzlich angegeben werden. Man erhält einen gewöhnlichen File-Descriptor, aus dem wie gewohnt gelesen und geschrieben werden kann.

Hier ist ein kleines Beispielprogramm, dass ein Attribut ausliest und auf der Konsole ausgibt.

Die Liste aller Attribute erhält man, in dem man das Attribut-Verzeichnis ließt. Der Trick ist hier, dass man das "."-Verzeichnis relativ zur Datei mit dem O_XATTR-Flag öffnet.

int attrdir = openat(file, ".", O_RDONLY|O_XATTR);

Hier ist ein Beispiel dafür.

Für andere Dateisystemoperationen wie z.B. unlink oder chown gibt es ebenfalls *at-Funktionen, die man in Kombination mit einem File-Desriptor des Attribut-Verzeichnis benutzen kann. Siehe unlinkat, fstatat, fchownat.

Anstatt zuerst eine Datei mit open und danach mit openat das Attribut zu öffnen, kann man auch attropen benutzen, die das ganze in einer Funktion zusammenfasst.