Archiv nach Kategorien: Tipps & Tricks

freiesMagazin: Einführung in Python

Da ich mit dem Erscheinen des 12. Teils meiner kleinen Einführung in Python erstmal eine ausgedehnte Pause einlegen werde, hier einmal ein kurzer Überblick der bisher erschienen Teile:

Bei Gelegenheit werde ich nochmal versuchen, die letzten sechs (oder gleich alle 12?) Teile zu bündeln. Außerdem steht noch eine Python3-Aktualisierung an: Zwar ist Python2 noch immer der Standard in der Linux-Welt. Mittels GObject-Integration lässt sich aber inzwischen anständig GTK in Python3 programmieren.

 

Conky und die Fußball EM 2012

Ich bin neulich zufällig auf OpenLigaDB gestoßen, ein Community-Projekt, das zeitnah Sport-Ergebnisse als Webservice zur Verfügung stellen will. Über die SOAP-Schnitstelle lassen sich die Daten unkompliziert und ohne Registrierung abrufen.

Ich habe dazu ein kleines Python-Skript gebaut, das jeweils ausgibt, welche Spiele an einem Tag stattfinden und wie es ggf. gerade steht. Die Ausgabe eignet sich gut für die Einbindung in Conky.

Für das Skript gibt es eine Github-Projektseite. Es sollte genügen, die Datei csi.py im Ordner ~/.conky abzulegen und in der Datei ~/.conkyrc einen Eintrag wie diesen anzufügen:

${font size=11:italic}${color slate grey}Fußball EM 2012 ${hr}${color }${font }
${execi 120 python ~/.conky/csi.py}

Das Skript benötigt das Modul “suds”, das bei vielen Distributionen als “python-suds” oder “python2-suds” zur Verfügung stehen sollte. Unter Umständen (beispielsweise unter Arch) muss der Aufruf python durch python2 ersetzt werden, weil das Skript nur unter Python2 lauffähig ist. Wenn Python2 in eurer Distribution ohnehin noch der Standard ist, funktioniert der Aufruf python ~/.conky/csi.py aber auch.

Wirkliche “Echtzeitergebnisse” sind übrigens mit diesem Skript letztlich nicht möglich: Zum Einen werden die Ergebnisse bei OpenLigaDB händisch eingetragen, so dass es dort schon zu Verzögerungen von etwa einer Minute  kommen kann, zum Anderen empfiehlt es sich auch, Conky das Skript in größeren Intervallen ausführen zu lassen, um OpenLigaDB und den eigenen Rechner nicht unnötig zu belasten.

/edit: SUDS-Abhängigkeit ergänzt

Catacomb Snatch – Ein Spiel entwickelt sich weiter

Im letzten Beitrag zum Thema Catacomb Snatch bin ich kurz auf die Weiterentwicklung des Spiels eingegangen und habe einen Leveleditor vorgestellt. In diesem Teil möchte ich nun genauer das Catacomb Snatch-”Ökosystem” ins Auge fassen.

Forks
Nachdem das Spiel am Sonntag freigegeben wurde, haben sich recht schnell verschiedene Forks gebildet. Besonders häufig wurden dabei die Steuerung (Mauskontrolle), verschiedene Bugs und natürlich die Platzhalter-Sprites ins Auge gefasst. Zu den bekannteren Forks gehören sicherlich:

  • Uber Catacomb Snatch
    Ein Fork, der mittlerweile durch einen Artikel in der englischen Wikipedia geadelt wurde und entsprechend oft verlinkt wird; das meiner Meinung nach aber etwas zu Unrecht: Es gibt anscheinend nur einen Entwickler, der Source scheint nicht verfügbar zu sein. Entsprechend hinkt dieser Fork den übrigen hinterher, wenngleich es ein paar nette Ideen gibt (so können die Droiden beispielsweise die Münzsammler leeren).
  • Catacomb Snatch: Reddit Edition
    Ein Fork, der von der Reddit-Community betrieben wird. Hier gibt es unter anderem zwei neue Level, neue Grafiken für einige Knöpfe und Sichtlinien für die Geschütze.
  • Maescool’s Catacomb Snatch fork
    Derzeit mit 67 Forks auf Github und über 110 Abonnements wohl der aktivste Ableger. Aufgrund der Vielzahl von Änderungen, soll dieser Fork etwas ausführlicher vorgestellt werden.
Maescool’s Catacomb Snatch fork
Bei mittlerweile mehr als 67 Forks und gut 40 Pulls Request auf Github kann dieser Fork sicher nicht mehr allein dem belgischen Entwickler “Maescool” zugeschrieben werden – dieser Fork hat sich zu einem tatsächlichen Gemeinschaftsprojekt weiter entwickelt. 
Neben dem Github-Projekt gibt es eine offizielle Seite mit Forum, ein automatisches Build-System mit den jeweils aktuellsten Version und ein kleines Wiki. IRC-Nutzer können im Freenode-Kanal #catacomb-snatch die Entwicklung verfolgen.
Einige Neuerungen bei diesem Fork sind:
  • Neue, schickere Grafiken in den Menüs.
  • Neue Levels und eine ansprechende Levelauswahl.
  • Levels werden automatisch aus dem Ordner ~./mojam/levels ausgelesen.
  • Neue Menüs “Optionen” und “How to Play”
  • Verschiedene Schwierigkeitsstufen
  • Zielen, schießen, kaufen und aufheben sind nun mit der Maus möglich
  • Levelsystem mit Erfahrungspunkten
  • Upgradesfür Münzsammler und Geschütze (Taste “F”)
  • Vollbildmodus (F11)
  • Pause-Bildschirm (ESC)
Durch die Änderungen und Verbesserungen ist diese CS-Version meiner Meinung nach derzeit die attraktivste und interessanteste. Auf der Issue-Seite bei Github gewinnt man schnell einen Überblick über die verschiedenen Ideen, die zur Zeit in Angriff genommen werden.
Weitere Ressourcen im Netz
Die Seite “The Crypt” bietet weiteres Material rund um Catacomb Snatch. Neben einem Forum finden sich dort Level zum Herunterladen, eine Übersicht verschiedener Forks und Anleitungen zum Erstellen von Leveln und Einrichten eines eigenen Eclipse-Projektes auf Basis des CS-Source Codes.
Das Entwickler-Team Mojang hat zudem eine kurze Anleitung veröffentlicht, in der geschildert wird, wie der CS-Source Code genutzt werden. Dort werden auch einige Probleme angerissen und mögliche Weiterentwicklungen vorgeschlagen.

Erweiterungen für die Gnome-Shell

Zur Entwicklungspolitik der Gnome-Macher gehört es, einen einheitlichen Desktop auszuliefern, der (euphemistisch formuliert) nicht mit Einstellungsmöglichkeiten überladen ist. Gerade in den frühen Versionen von GNOME3 war dies durchaus Anlass für Kritik, sahen sich doch viele Nutzer bevormundet und nicht in der Lage, die beanstandeten Eigenheiten der Gnome-Shell bequem wegzukonfigurieren. Dafür gibt  es aber eine mächtige Erweiterungs-Schnittstelle, mit der sich alle möglichen Verhaltensweisen und Darstellungen der Gnome-Shell bearbeiten lassen.

Ein lange erwarteter und sicher nicht unwichtiger Schritt zu einem benutzerfreundlicheren Desktop war daher die Seite extensions.gnome.org, über die Erweiterungs-Entwickler und Nutzer zusammenfinden. Die Seite bietet Erweiterungen nicht nur an, sondern ermöglicht es auch, diese direkt dort zu installieren und zu (de)aktivieren.

Eben weil das Installieren und Nutzen von Erweiterungen durch die Seite so komfortabel geworden ist, möchte ich die Erweiterungen vorstellen, die ich nutze, um den Gnome-Desktop meinen Vorstellungen anzupassen.

Workspace Indicator
Diese Erweiterung zeigt im Panel die aktuelle Arbeitsfläche an und erlaubt es, diese per Mausklick oder Mausrad zu wechseln. Erspart den Wechsel in den Overlay-Modus.

Desktop Scroller
In eine ähnliche Kerbe schlägt der “Desktop Scroller”. Ist diese Erweiterung aktiviert, kann durch Scrollen am rechten Bildschirmrand ebenfalls die Arbeitsfläche gewechselt werden. Die Erweiterung lässt sich relativ leicht so umbiegen, dass das Scrollen am linken Bildschirmrand den Arbeitsflächenwechsel auslöst.

Auto Move Windows
Gehört sicher zu den bekannteren Erweiterungen. Sie verschiebt beliebige Programme nach dem Start auf vorgegebene Arbeitsflächen. Nützlich, wenn man beispielsweise sein Mail-Programm für gewöhnlich auf Arbeitsfläche 2 starten möchte.

Native Window Placement
Normalerweise ordnet die Gnome-Shell die Fenster im Overlay-Modus symmetrisch an und weist jedem Fenster die selbe Höhe zu. Diese Erweiterung sorgt dafür, dass das Größenverhältnis der Fenster im Overlay-Modus dem realen Größenverhältnis entspricht. Außerdem wird die Anordnung der Fenster so vorgenommen, dass sie der Anordnung der Fenster auf dem Desktop näher kommt. Das erleichtert die Orientierung und das Wiederfinden im Overlay-Modus.

Alternative Status Menu
Ebenfalls sicher eine Standard-Erweiterung. Die Überlegung der Gnome-Macher, den Suspend-Modus in den Vordergrund zu stellen, indem er standardmäßig die einzige Option zum Herunterfahren im Statusmenü ist, stieß von Anfang an bei vielen Nutzern auf Unverständnis – auch weil die Möglichkeit, mit Hilfe der ALT-Taste weitere Optionen zu erhalten, nicht besonders alltagstauglich bzw. intuitiv erschien. Die Erweiterung “Alternative Status Menu” fügt daher weitere Optionen zum Statusmenü hinzu.

PulseAudio-Equalizer
Diese Erweiterung fügt im Sound-Menü eigentlich nur einen Eintrag für den PulseAudio-Equalizer hinzu, der unabhängig davon zusätzlich installiert werden muss. Dennoch finde ich die Erweiterung durchaus praktisch, da der Equalizer so immer griffbereit ist und zum Experimentieren einlädt – nicht nur bei Vuvuzela-Sorgen.

Presentation Mode
Bei Präsentationen oder Flash-Videos greift die Unterdrückung des StandyBy-Modus des Monitors häufig nicht – der StandBy müsste jedes Mal im Vorfeld manuell deaktiviert werden, wenn man nicht grundsätzlich darauf verzichten möchte. Diese Erweiterung fügt einen weiteren Menüpunkt im Statusmenü an, so  dass der StandBy-Modus des Monitors mit einem Klick unterdrückt werden kann.

noa11y
Das Erreichbarkeits-Menü im Gnome-Panel wird von vielen Nutzern nicht benötigt und kann mit dieser Erweiterung entfernt werden.

Bigger MessageTray Corner
Mit dem Update auf GNOME 3.2.2 wurde der Bereich, der die MessageTray hervorbringt, wenn man mit der Maus darüber fährt, auf einen Pixel verkleinert: Der Nutzer muss die Maus nun nur noch in die untere, rechte Ecke schubsen und kann so auf seine Benachrichtigungen zugreifen, ohne die Leiste ständig versehentlich anzuzeigen, wie es in früheren Versionen oft geschah. Wer allerdings einen zweiten Monitor rechts neben dem ersten angeordnet hat, wird unter Umständen Mühe haben, den “magischen Pixel” in der unteren, rechten Ecke des ersten Monitors zu erwischen. Diese kleine Erweiterung habe ich geschrieben, um den Maus-Bereich wieder auf 300 Pixel auszudehnen.

Media Player Indicator
Ubuntu-Nutzer kennen bereits die Möglichkeit, ihre Media-Player über das Sound-Menü im Panel zu steuern. Diese Erweiterung bietet diese Möglichkeit auch für Gnome-Shell-Nutzer – vorausgesetzt, die von ihnen eingesetzten Medien-Spieler nutzen die MPRIS-Schnittstelle.

gTile / KeyTiling
Ich habe ja schon’mal erwähnt, dass es gerade auf großen Monitoren attraktiv ist, seine Fenster überlappungsfrei anzuordnen. Nicht ohne Grund bieten viele Systeme und Oberflächen die Möglichkeit, Fenster beispielsweise über den halben Bildschirm zu spannen, wenn man sie an den entsprechenden Bildschirm-Rand zieht. Ich nutze zur Zeit gTile und meine Eigenkreation KeyTiling parallel, um ein wenig Tiling-Gefühl auf den Desktop zu bringen.

Für Hinweise auf weitere interessante Erweiterungen bedanke ich mich schonmal im Voraus :) .

TurboPrint und systemd

Wer systemd verwendet und auf TurboPrint angewiesen ist, wird vielleicht festgestellt haben, dass der TurboPrint-Daemon “tprintdaemon” nicht automatisch gestartet wird. Wie der Änderungs-Übersicht zu entnehmen ist, wurde dieses Problem erst mit TurboPrint 2.24 behoben. Wer ältere Versionen einsetzt, profitiert also nicht davon.

Da es unter systemd sehr leicht ist, neue Services zu definieren, kann leicht Abhilfe geschafft werden:

[Unit]
Description=TurboPrintDaemon

[Service]
Type=forking
ExecStart=/usr/bin/tprintdaemon
Restart=on-abort

[Install]
WantedBy=multi-user.target

Dieser Code wird schlicht in der neu zu erstellenden Datei /etc/systemd/system/tprintdaemon.service
abgelegt.

Nun kann der Service mit
sudo systemctl enable tprintdaemon.service
installiert und mit
sudo systemctl start tprintdaemon.service
direkt gestartet werden.

Kleiner Ersatz für nautilus-open-terminal

Da die Erweiterung nautilus-open-terminal schon seit einiger Zeit für Probleme sorgt und Nautilus abstürzen lässt (Fehlermeldung,Bericht bei Chris) und ich mir ohnehin mal die Python-Schnittstelle von Nautilus ansehen wollte, habe ich eine kleine Erweiterung geschrieben, die nautilus-open-terminal ersetzen soll, bis das Original wieder einwandfrei arbeitet.

Die von Chris angesprochenen Probleme mit “Nautilus-Python” scheinen insgesamt darauf zurückzuführen zu sein, dass für Nautilus-Erweiterungen die GTK3-Anbindung jetzt zwingend erforderlich sind. Durch die Ableitung von GObject ließen sich in meinem Fall also die Probleme beseitigen.

Wer sich meine “open-terminal”-Variante einmal ansehen möchte, kann dies bei GitHub tun. Abgelegt wird das Skript im Verzeichnis ~/.local/share/nautilus-python/extensions/, wobei ich das Verzeichnis in meinem Fall erst noch erstellen musste.

Nvidia, Twinview und das Youtube-Vollbild

Bei der Verwendung des proprietären Nvidia-Treibers in Kombination mit Twinview kommt es bei einigen Flash-Video-Seiten zu einem hässlichen Fehler: Videos werden im Vollbild nicht korrekt dargestellt, das Bild füllt nur einen kleinen Teil des Bildschirms aus.

Ich hatte bisher noch keine zufriedenstellende Lösung gefunden. Einige Nutzer lassen durch zusätzliche Skripte den Flashplayer auf Youtube durch VLC ersetzen. Andere Nutzer lassen durch diesen Trick das Flash-Video das gesamte Browser-Fenster einnehmen und versetzen dann den Browser in den Vollbild-Modus. Wirklich befriedigend ist das alles nicht.

Alistair Buxton hat sich auf seiner Homepage einmal näher mit dem Problem beschäftigt und rausgefunden, warum der Flashplayer auf Youtube so skaliert, wie er skaliert. Letztendlich ermittelt das Flash-Plugin durch einen bestimmten API-Aufruf (XGetGeometry) die Größe der Anzeigefläche. Diese wird an den Flash-Player weitergereicht, der daraus seine Schlüsse zieht. Der Youtube-Player scheint zunächst das Flash-Video auf den gesamten Anzeigebereich zu skalieren, um dieses Bild dann (inklusive schwarzer Balken) wieder auf die Größe der primären Anzeige runterzuskalieren oder entsprechend zu beschneiden. Auf der Seite von Alistair Buxton ist das anhand verschiedener Bilder gut nachzuvollziehen.

Alistair hat nun einen kleinen Hack veröffentlicht, der den Aufruf der Methode “XGetGeometry” durch dynamisches Linken mittels LD_PRELOAD überschreibt. Wenn das Flash-Plugin nun nach der Anzeigegröße fragt, werden ihm Breite und Höhe des primären Bildschirms zurückgegeben. Der kleine Hack findet sich hier und ist leicht zu verwenden, in der Readme-Datei finden sich alle wichtigen Informationen.

Einen Nachteil hat auch diese Methode natürlich: Bei jedem Aufruf des Browsers muss die Umgebungsvariable LD_PRELOAD explizit gesetzt werden, damit die modifizierte XGetGeometry-Funktion zum Tragen kommt. Es empfiehlt sich daher, die .desktop-Datei des Lieblingsbrowsers entsprechend anzupassen. Alternativ könnte auch ein kleines Skript erstellt werden, das statt des Browsers aufgerufen wird:

#!/bin/bash
LD_PRELOAD=/usr/lib/libfullscreenhack.so chromium-browser $@

Letztlich ist natürlich auch diese Lösung keine Dauerlösung. Durch den kleinen Trick von Alistair kann man das Problem aber erstmal umschiffen. Endlich.

 

Thema der GnomeShell ändern

Mit der “user theme” Erweiterung für die GnomeShell lassen sich Themen sehr einfach wechseln. Prinzipiell muss dafür nur mit “dconf” der Schlüssel “/org/gnome/shell/extensions/user-theme/name” geändert werden. Damit die Erweiterung die Themen auch findet, müssen diese zuvor im Ordner “~/.themes” abgelegt worden sein.

Um nun das Thema zu ändern, genügt es, folgenden Befehl in der Konsole abzusetzen:

dconf write /org/gnome/shell/extensions/user-theme/name "'DarkGlass'"

Ebenso könnte mit dem Werkzeug “dconf-editor” der entsprechende Schlüssel angepasst werden.

Weil dieses Vorgehen doch eher umständlich ist, gibt es die Erweiterung “themeselector“, die die Möglichkeit, das Thema zu ändern, direkt in die GnomeShell integriert.

Leider scheint diese Erweiterung noch nicht mit der aktuellen Version der GnomeShell lauffähig zu sein und da es nicht mit einer einfachen Anpassung der Versionsnummer in der Datei “metadata.json” getan war, habe ich ein kleines Python-Skript geschrieben, das ebenfalls in der Lage ist, die GnomeShell-Themen auf die Schnelle zu ändern.

Das Skript findet sich hier auf GitHub und sollte mit Python2 und Python3 lauffähig sein. Voraussetzung ist natürlich die Installation der oben erwähnten und verlinkten Erweiterung “user theme”. Außerdem müssen die Bibliotheken für die Anbindung von Python an die GObject-Introspektion installiert sein, unter Ubuntu oder Arch sind diese beispielsweise im Paket “python-gobject” bzw. “python-gobject2″ zu finden.

Wer schnell mal ein paar Shell-Themen ausprobieren möchte, kann ja einen Blick darauf werden.

//edit: Wie Christoph in den Kommentaren erwähnt, steht diese Funktion auch über das “gnome-tweak-tool” zur Verfügung; da das die meisten Shell-Nutzer wohl installiert haben dürften, besteht natürlich kaum Bedarf für ein zusätzliches Skript :) .

Gnome 3.2 – messageTray auf den primären Monitor verschieben

Ich habe gestern einen Blick auf die Beta von Gnome 3.2 gewagt und bin soweit eigentlich zufrieden: Die GDM-Anmeldebox passt nun besser zum Standard-Thema der Gnome-Shell und die messageTray wird jetzt anscheinend nicht mehr ganz so schlimm mit Benachrichtigungen zugepflastert. Auch der neue Manager für Wechselmedien springt sofort ins Auge.

Etwas frustrierend war für mich aber der Umstand, dass die messageTray bei mir nicht mehr auf dem primären Bildschirm, sondern dem meist abgeschalteten Zweitbildschirm dargestellt wurde. Mit ein paar Handgriffen lässt sich die messageTray aber wieder auf den “richtigen” Bildschirm befördern.

Schritt 1: messageTray.js

Im ersten Schritt wird die Datei /usr/share/gnome-shell/js/ui/messageTray.js mit Root-Rechten bearbeitet. Dabei wird in der Funktion _setSizePosition die Zeile

let monitor = Main.layoutManager.bottomMonitor

durch folgende Zeile ersetzt:

let monitor = Main.layoutManager.primaryMonitor

Schritt 2: layout.js

Auch die Datei /usr/share/gnome-shell/js/ui/layout.js wird mit Root-Rechten bearbeitet. In der Funktion _updateTrayBarrier wird die Zeile

let monitor = this.bottomMonitory

durch folgende Zeile ersetzt:

let monitor = this.primaryMonitor

In der Funktion _updateBoxed wird parallel verfahren: Jedes Vorkommen von “bottomMonitor” im Zusammenhang mit der messageTray wird durch “primaryMonitor” ersetzt. So wird aus:

this.trayBox.set_position(this.bottomMonitor.x, this.bottomMonitor.y + this.bottomMonitor.height); 
this.trayBox.set_size(this.bottomMonitor.width, -1);

this.trayBox.set_clip(0, -this.bottomMonitor.height, this.bottomMonitor.width, this.bottomMonitor.height);

dieses hier:

this.trayBox.set_position(this.primaryMonitor.x, this.primaryMonitor.y + this.primaryMonitor.height);
this.trayBox.set_size(this.primaryMonitor.width, -1);

this.trayBox.set_clip(0, -this.primaryMonitor.height, this.primaryMonitor.width, this.primaryMonitor.height);

Schritt 3: Shell neu starten

Um die Änderungen wirksam zu machen, wird die Shell neu gestartet. Dazu genügt es im Ausführen-Dialog von Gnome3 (ALT+F2) das Kürzel “r” abzusetzen.

 

Kurztipp: Login-Maske auf dem falschen Bildschirm

Im Multi-Monitor-Betrieb zeigt GDM die Login-Maske für gewöhnlich auf dem Monitor, auf dem der Mauszeiger sich aktuell befindet. In meinem Fall ist das leider öfter mal der Zweitbildschirm.

Damit dieser zusätzliche Stromverbraucher nicht unnötig an- und ausgeschaltet werden muss, kann man GDM durch einen kleinen Kniff dazu zwingen, den Mauszeiger auf dem “richtigen” Monitor zu platzieren.

Dazu wird lediglich das Programm xdotool benötigt. Durch folgende Zeile am Ende (jedoch vor dem “exit 0″) der Datei  /etc/gdm/Init/Default wird der Mauszeiger beim Start von GDM an die gewünschte Stelle gebeamt:

xdotool mousemove 500 500

Die beiden letzten Ziffern geben dabei die Koordinaten des Mauszeigers an (gemessen von der linken, oberen Bildschirmecke).

//update:
Es ist natürlich die linke, obere Ecke. Fixed.