Liferea: xdg-open, tabs and tips (and a patch of course)

Im IRC kam der Vorschlag, dass Liferea doch xdg-open aus den xdg-utils benutzen könnte; ein Wrapperscript, das jeweils die bevorzugte Anwendung für einen Datei- oder URL-Typ des jeweils aktiven Desktop Environments (via gnome-open [GNOME], exo-open [XFCE], kfmclient [KDE]) benutzt. Die Idee ist sehr gut, denn obwohl manuelle Konfiguration möglich ist, wäre es schön, wenn ich z.B. automatisch Konqueror benutzen könnte, wenn ich es denn wollte… und nicht erst in den Einstellungen rumspielen müsste.

Theorie und Praxis treffen jedoch an irgendeinem Punkt aufeinander und man merkt, dass manche Dinge noch nicht ohne weiteres möglich sind. Im Falle Liferea zeigt sich das ganz banal am Fehlen von nötigen Parametern. Liferea supportet Optionen, welche festlegen wie ein Link geöffnet wird: In einem neuen Fenster, in einem neuen Tab oder in einem bestehenden Fenster. Dort die richtigen Parameter automatisch zu finden – bei der Fülle der möglichen Browser und auf Hinblick dessen, was xdg-open leisten soll: Unmöglich.

Nun jedoch grundsätzlich zu sagen “xdg-open ist minderwertig” wäre etwas verwegen, da – oh Schreck – auch gnome-open als Option in Liferea zu finden ist. Darum: Warum nicht auch xdg-open hinzufügen? Weder gnome-open noch xdg-open verstehen New Tabs, xdg-open versteht jedoch welchen Browser ich gerne hätte.

Argumente wie “du checkst ja garnicht, ob xdg-open überhaupt vorhanden ist” sind hinfällig: Nicht jedes System hat Opera, Netscape… et cetera. Wenn man wirklich mag, könnte man beim ersten Start überprüfen, ob xdg-open vorhanden ist – wenn ja wird es als Standard gesetzt. Klingt wie ein fairer Kompromiss, oder?

Darum: 2 Minuten Copy & Paste und fertig sind wir auch an dieser Front (bis auf das Überprüfen ob vorhanden oder nicht).

Apache2 als Schleuse

Tja, wer kennt das Problem nicht: Die meisten Proxies sind sehr lasch mit Port 80, aber bei Port 81 ist alles immer gesperrt.

Das ist unter normalen Umständen ganz egal, nur leider nicht, wenn der Entwicklungsserver auf den man zugreifen möchte, auf eben diesem Port 81 läuft. Wenn man aber eh schon Apache am laufen hat, kann man auch mit ein paar Zeilen in der httpd.conf den Server von Port 81 als Subdomain auf Port 80 laufen lassen:

<VirtualHost *:80>
ServerName subdomain.server.com
ProxyPass / http://interne.ip:80/
ProxyPassReverse / http://interne.ip:80/
ProxyPreserveHost On

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) http://interne.ip:80/$1 [P]
</VirtualHost>

Ja, das Ganze nutzt mod_proxy und mod_rewrite. Da der Proxyzugriff allerdings nur auf die interne.ip gestattet ist… naja, ist es relativ sicher 😉 .

Wie sagt man so schön? Not macht erfinderisch.

Maus- und Keyboardsharing mit Synergy

Ich arbeite momentan parallel mit einem Windows- und einem Linuxsystem. Es ist dabei unglaublich störend, dass ich zwei Keyboards und Mäuse auf dem Tisch liegen habe (Platzverschwendung, anyone?). Eine sinnvolle Alternative bietet Synergy.

Wer kennt nicht dieses dolle Programm von Stardock, mit dem man seine Maus und sein Keyboard zwischen mehreren Rechnern teilen kann? Leider ist dieses Programm a.) kommerziell und b.) nur für Windows verfügbar, was für mich also schonmal total nutzlos ist, da ich hauptsächlich mit Linux arbeite. Hier greift das OpenSource Programm Synergy ein, welches sowohl für Windows, Linux als auch OSX verfügbar ist.

Nutzer von Debian können sich Synergy mit apt-get install synergy auf die Platte lutschen, Windows- und Macuser machen irgendwas anderes.

Nehmen wir an, ich will meine Eingabegeräte vom Linuxrechner mit der Windowsmaschine nutzen:

Zuerst touched man sich lokal im Homeverzeichnis eine .synergy.conf

Die Datei wird dann mit folgendem Inhalt gefüllt:

 section: screens
undine:
salamander:
end

section: links
undine:
left    = salamander
salamander:
right   = undine
end

section: options
heartbeat       = 5000
switchDelay     = 500
end

Einfach, oder? Unter Screens werden alle Rechner angegeben, die mit einbezogen werden sollen (Server mit Keyboard und Maus natürlich nicht vergessen!). Bei Links wird die Reihenfolge der Screens angegeben. Die Optionen kann man auch weglassen wenn man mag, ich finde sie aber recht nützlich.

synergys -f –config ~/.synergy.conf startet dann den Synergyserver, sobald man Clients (Rechner ohne Eingabegeräte) verbunden hat, kann man die Screens wechseln. Einfach und idiotensicher.

Funktioniert klasse und ich kann es nur jedem empfehlen, der mehrere verschiedene, non-Xserver basierte Systeme bei sich laufen hat.

Spaß mit X – Xdmx

Okay, das ist weniger ein sinnvoller Post als mehr ein Braindump für mehrere kleine Parts, an denen ich mal angesetzt habe.

Xdmx ist ein X Proxy, der mehrere X Server von verschiedenen Rechnern bündelt und z.B. große Wallinstallationen erlaubt (oder halt tausend Monitore nebeneinander 😉 ).

In Ermangelung ständig verfügbarer, mehrerer Monitore darum nur ein kurzer Abriss für KDE Nutzer:

Ich finde es am sinnvollsten eine eigene xsession für Xdmx in /usr/share/xsessions anzulegen:

 [Desktop Entry]
Encoding=UTF-8
Type=XSession
Exec=/usr/bin/startdmxkde
TryExec=/usr/bin/startdmxkde
Name=Xdmx (KDE)

…die das kleine Shellscript aufruft:

 #!/bin/bash

startx `which startkde` –      \
/usr/bin/Xdmx :1      \
-display :0  \
-display 192.168.1.3:0 \
-display 192.168.1.4:0 \
-xinerama \
-ignorebadfontpaths        \

…welches KDE startet, den lokalen X Screen als Hauptscreen ganz links anordnet und dann die zwei anderen Screens der im Netzwerk befindlichen Rechner rechts danebenschaltet. Aus Performancegründen ist die Option für Xinerama negativ (-xinerama) und somit deaktiviert, wer es braucht kann natürlich mit +xinerama arbeiten. Sinnvolle Ergänzung zu diesem Setup wäre irgendwas in Richtung Chromium.

Mal schauen, wann ich wieder genug Monitore zusammen habe für den nächsten Testrun 🙂 .

Spaß mit X – ESD

Letztes Mal gabs die Basisportion X Spielerei. Wobei natürlich einige Punkte wie z.B. ssh -CY bewusst nicht behandelt wurden. Ich entschuldige mich, ja, man kann sich auch per ssh mit den Parametern -CY einloggen und dann einfach ohne weitere Eingaben X Anwendungen starten.

Aber darum geht es dieses Mal nicht. Seit Ewigkeiten hatte ich lokal den Artikel zum Thema ESD – Sound über Netzwerk herumliegen.

Continue reading Spaß mit X – ESD