Howto: Kompilieren und Installieren von NinjaIDE unter MacOS

NinjaIDE ist eine freie Entwicklungsumgebung für Python, die wir hier schon kurz vorgestellt haben. Für Windows und Linux existieren fertige Binärpakete, dort ist NinjaIDE also schnell und einfach eingerichtet. Unter MacOS sieht es leider anders aus. Hier erhält man lediglich die Software-Quellen und muss selbst kompilieren. Da NinjaIDE mit PyQt entwickelt wird, kommen Qt und PyQt als Abhängigkeiten noch dazu. Diese Anleitung beschreibt kurz, wie sich NinjaIDE unter MacOS (hier: Lion; für Mountain Lion sollten die Schritte identisch sein) bauen und installieren lässt.

Abhängigkeiten

Zunächst werden die benötigten Abhängigkeiten heruntergeladen. Kurzer Hinweis: Da die Software durchaus öfter aktualisiert wird, können die Versionsangaben in dieser Anleitung leicht von den aktuellsten Versionen abweichen.

Die benötigten Abhängigkeiten sind:

Qt4 (nicht Version 5!) von der Qt-Projektseite: http://qt-project.org/downloads

Hierbei handelt es sich um einen einfachen Installer, der das eigentliche Qt-Toolkit einrichtet. Das ist entsprechend schnell erledigt.

Bei Riverbank Computing lädt man sich nun die Sourcen für SIP und PyQt herunter:

sip-4.14.7.tar.gz von hier
PyQt-mac-gpl-4.10.2.tar.gz von hier

Beide Dateien werden wie üblich per Doppelklick entpackt. Anschließend muss das Terminal genutzt werden. (Von wegen, Mac-User hätten das nicht nötig!) Zunächst wechseln wir in das SIP-Verzeichnis und kompilieren und installieren es mit Hilfe folgender Befehle:

Das gleiche Spiel erfolgt nun mit PyQt: erst in das entsprechende Verzeichnis wechseln und die Build-Vorgang bzw. die Installation durchführen mit:

Der Vorgang dauert eine ganze Weile, man kann sich also in der Zeit getrost einen Kaffee machen.

NinjaIDE

Auf der Website des Projektes kann das Source-Paket für MacOS heruntergeladen werden. Anschließend wird es entpackt und ähnlich erstellt wie die Abhängikeiten. Wir wechseln also im Terminal in das Source-Verzeichnis und kompilieren die IDE wie folgt:

Launcher erstellen

NinjaIDE kann zunächst nur von der Shell (/usr/local/bin/ninja-ide) aus gestartet werden. Das Installationsscript beinhaltet zwar »py2app«, mit dem ein Launcher erstellt werden können sollte, das scheint aber nicht zu funktionieren (wahrscheinlich würden andernfalls auch fertige Binärpakete für den Mac angeboten werden).

Wir erstellen uns also einen einfachen Launcher mit Hilfe von Platypus, das kostenlos von der zugehörigen Projekt-Website heruntergeladen werden kann. Nach dem Start von Platypus wird das auszuführende Script /usr/local/bin/ninja-ide ausgewählt, der Script Type auf Python gestellt, ein Icon (das findet sich direkt im Source-Ordner von NinjaIDE) ausgesucht sowie wenige weitere Optionen eingestellt. Das Ergebnis sollte etwa wie folgt aussehen, wobei die Angaben zum Identifier und Autor anhand der persönlichen Benutzerkennung vorbelegt werden.

Platypus
Platypus

Mit Klick auf Create kann der gewünschte Launcher erstellt werden und beispielsweise im Application-Verzeichnis abgelegt werden.

Ninja IDE Mac
Das Ergebnis: Ninja IDE auf dem Mac

Wenn’s mal Python sein muss: NinjaIDE

Eine kleine Anwendungs-Empfehlung am Rande: Wer mit Python entwickeln will oder muss, hat es unter Umständen etwas schwer, eine gute Entwicklungsumgebung zu finden. Mit der Open-Source-IDE »NinjaIDE« existiert eine übersichtliche und bequeme Entwicklungsumgebung, die für die Plattformen Windows, MacOS und Linux zur Verfügung steht.

Für Windows und Linux existieren fertige Binärpakete (unter Ubuntu lässt es sich direkt aus dem Software-Center installieren), lediglich unter MacOS müssen die Quellen sowie einige Abhängigkeiten selbst kompiliert und installiert werden. Außerdem fügt sich »NinjaIDE« unter MacOS nicht ganz so gut in das Look and Feel des Systems ein wie unter Windows und Linux. Dennoch: klare Empfehlung für Python-Entwickler!

Ninja IDE unter Ubuntu
Ninja IDE unter Ubuntu

Eine neue IDE für die Android-Entwicklung

Wer einmal die Werkzeuge, die Google für die Android-Entwicklung bereitstellt, mit den Tools für konkurrierende Plattformen – in erster Linie ist das XCode für die iOS-Entwicklung – vergleicht, wird feststellen: Google ist hier klar im Nachteil. Die aktuelle Lösung besteht aus einem SDK mit CLI-Werkzeugen, einer Sammlung von Plugins für Eclipse sowie einem auf einer virtuellen Maschine basierenden Device-Emulator. Zwar ist ein Entwickeln damit möglich, zwischen dieser Lösung und dem angesprochenen XCode liegen in Sachen Komfort und Geschwindigkeit, kurz: dem Wohlfühl-Faktor, jedoch echte Welten. Zu langsam, zu inkonsistent, zu unübersichtlich ist die Android-Entwicklungsumgebung.

Auf seiner letzten Entwicklerkonferenz im Mai hat Google mit dem »Android Studio« nun endlich eine neue Entwicklungsumgebung angekündigt. Diese basiert auf dem bekannten IntelliJ IDEA (das bereits etwas Unterstützung für Android-Projekte enthielt), ist plattformübergreifend (Windows, Mac, Linux) verfügbar und ist vor allem: noch sehr unfertig. Aktuell befindet es sich offiziell in der Version 0.2.

Dennoch: Die Entscheidung für eine neue Basis ist richtig. Das beginnt schon damit, endlich alle benötigten Werkzeuge in einen einzigen Download zu packen und somit die Ersteinrichtung zu erleichtern.

Allerdings sieht man auch hier sofort, dass die unterschiedlichen Teile unterschiedliche Ursprünge haben. Während die eigentliche Entwicklungsumgebung etwa auf dem Swing-Framework beruht, verwenden »Android Virtual Device Manager« und »Android Device Monitor« das SWT-Toolkit. Und an der größten Schwachstelle kann auch eine aufgeräumtere IDE nichts ändern. Das ist und bleibt der ultra-langsame und fehlerträchtige Emulator.

Bis das »Android Studio« für den Entwickler-Alltag taugt und die Einzelkomponenten vernünftig integriert sind, vergeht wahrscheinlich noch mindestens ein Jahr, eher noch mehr Zeit. Bis dahin überarbeitet Google vielleicht auch den Emulator noch einmal bzw. ersetzt ihn durch ein vollständig andere Lösung. Es ist an der Zeit, den Rückstand zu XCode (und auch den Alternativen wie »Xamarin Studio«) aufzuholen.

Android Studio unter MacOS
Android Studio unter MacOS

Coding Fonts

Kaum ein anderes Werkzeug ist für einen Software-Entwickler von so zentraler Bedeutung und gleichzeitig häufig so vernachlässigt wie der verwendete Coding Font. Oft genug wird einfach der voreingestellte Font verwendet, bessere Alternativen werden nicht geprüft. Dabei ist die Auswahl an guten Coding Fonts groß genug.

Die Klassiker: Courier (New) und Monaco

Courier hat seine Ursprünge bereits in den Fünfzigerjahren und findet sich spätestens seit den Achtzigern in der einen oder anderen Variante praktisch auf jedem Computer-System, anfangs als Bitmap-Font, später als bildschirmoptimierter Outline. Bei dieser Verbreitung ist es kein Wunder, dass man auch heute noch sehr häufig auf Courier stößt, obwohl – wie es Gerrit van Aaken ausdrückt – es rein ästhetisch betrachtet kaum Gründe gibt, die für den Einsatz der Courier sprechen.

Courier New
Courier New

Mac-User hatten neben der Courier schon seit ewigen Zeiten eine (bessere) Alternative: die Monaco. Das etwas eigenwillige Schriftbild ist durchaus »typisch« für den Mac und war dort für lange Zeit der Coding Font schlechthin.

Monaco
Monaco

Die neuen Standards: Consolas und Menlo

Weil sich in Sachen Font-Rendering und Display-Qualität und -Auflösung in den letzten zehn Jahren sehr viel getan hat, sind sowohl Microsoft als auch Apple mit der Zeit gegangen und statten ihre Systeme seit einigen Versionen u. a. auch mit neuen Monospace-Fonts aus, die ihre Vorgänger als Standardfonts ablösen sollen.

Unter Windows ist das Consolas, der an einigen Stellen etwas kantig wirkt; unter MacOS ist es der deutlich rundere Menlo, der auf dem weiter unten besprochenen Vera Sans Mono basiert, mit Ausnahme weniger Glyphen fast identisch ist und von Apple etwa in Xcode als neuer Default gesetzt ist.

Consolas
Consolas

Underrated Underdogs: Vera Sans Mono / DéjaVu Sans Mono

Seitdem die freie Schriftfamilie Bitstream Vera vor etwa zehn Jahren veröffentlicht worden ist, ist die nichtproportionale Variante mein absoluter Favorit, auch wenn ich den Eindruck habe, dass sie noch immer nicht sonderlich bekannt ist. Vera Sans Mono bietet ein klares und ruhiges Erscheinungsbild und ist auf die Bildschirmdarstellung optimiert. Das Derivat DéjaVu besitzt das gleiche Erscheinungsbild, aber einen größeren Zeichenvorrat. Der neue Apple-Standard-Font Menlo ist ebenfalls aus Vera Sans Mono entstanden.

DéjaVu Sans Mono
DéjaVu Sans Mono

Kostenloses vom Profi: Adobe Source Code Pro

Der Schriften-Profi Adobe bietet seit September des letzten Jahres mit Source Code Pro ebenfalls einen sehr ordentlichen und dazu kostenlosen Font an, der sich hervorragend für die Quellcode-Bearbeitung eignet.

Source Code Pro Medium
Source Code Pro Medium

Noch mehr Auswahl: Ubuntu Mono, Droid Sans Mono

Neben diesen Schriften gibt es noch einige Alternativen, von denen zumindest Ubuntu Mono und Droid Sans Mono genannt werden sollten. Die erstgenannte gehört zu denjenigen, die Canonical für sein eigenes Betriebssystem Ubuntu entwickelt hat. Der Font erinnert ebenfalls an Vera, besitzt jedoch einige Feinheiten, die sich davon abheben.

Ubuntu Mono
Ubuntu Mono

Droid Sans Mono wurde von Google für Android entworfen und ist frei verfügbar. Er bietet ebenfalls eine hervorragende Lesbarkeit am Bildschirm.

Droid Sans Mono
Droid Sans Mono

Anmerkung: Alle Abbildungen sind unter Ubuntu erstellt worden. Die Font-Darstellung kann je nach verwendetem Betriebssystem und den gesetzten Einstellungen variieren.

Chrome hängt alle ab

Googles Web-Browser Chrome hängt die Konkurrenz ab: Nach aktuellen Zahlen von Stat Counter liegt der weltweite Marktanteil bei mittlerweile 43%, während der Trend beim Internet Explorer, trotz massiver Werbemaßnahmen und unbestrittener Fortschritte weiter nach unten zeigt. Langsam abwärts geht es auch beim Firefox, der ja seinerzeit erst einen »Generationenwechsel« möglich gemacht hat. Gemäß Stat Counter liegen die drei größten Browser weltweit bei Marktanteilen von knapp 43% (Google Chrome), 25% (Internet Explorer) bzw. 20% (Firefox). Dahinter folgt der Safari mit etwa 8% Marktanteil. Für einen Web-Developer bedeutet das in der Praxis, dass bei Neu-Entwicklungen auch mindestens diese vier Browser unterstützt werden sollten. Noch geht die Tendenz in die Richtung, dass die drei Browser Firefox, Chrome und Safari relativ leicht auf einen gemeinsamen Nenner zu bringen sind, und der Internet Explorer aufgrund eines immer noch vorhandenen technischen Rückstandes die meiste »Extra-Arbeit« verursacht. Die vergleichsweise unterschiedliche Umsetzung von neuen HTML5-Funktionen in allen Programmen dürfte die Situation jedoch in Zukunft eher unübersichtlicher machen.

Aktuelle Browser-Marktanteile weltweit. Quelle: statcounter.com
Aktuelle Browser-Marktanteile weltweit. Quelle: statcounter.com