Miranda IM war der Instant Messenger, den ich jahrelang nutzte. Nur mit der Zeit wurde das Projekt Miranda IM immer inaktiver und die fehlenden Updates sorgten auch für ungelöste Probleme im Programm. Ich wollte also einen neuen Instant Messenger finden. Allerdings hatte ich Ansprüche für den Instant Messenger und das implizierte, dass ich eine Evaluation hätte durchführen müssen. In diesem Artikel schreibe ich einerseits davon, wie ich zu Miranda IM gekommen war, warum ich von Miranda IM weg wollte, welche anderen Instant Messenger ich mir genauer anschaute und welche wichtigen Punkte ich dort für mich bewertete und wie ich im Endeffekt von Miranda IM weg ging, aber jetzt immer noch Miranda benutze. Der Artikel setzt an manchen Stellen gewiss IT-Know-how voraus.

Mein Werdegang zu Miranda IM

Bevor ich Miranda IM benutzte, benutzte ich primär den originalen ICQ Client in Version 6. Da dies aus der Sicht eines Informatikers sicherlich peinlich ist, muss ich zu meiner Entschuldigung sagen, dass dieser Zustand Mitte 2008 gegeben war. Daneben benutzte ich auch hin und wieder den Windows Live Messenger und Skype. Das war nicht nur ineffizient in der Benutzung, sondern auch ineffizient im Leistungsverbrauch. Vor allem ICQ sorgte mit seiner tollen Flash-Werbung dafür, dass das ganze richtig träge wurde seit Version 6 (und Version 5 konnte man da bereits nicht mehr nutzen).

Mein Miranda ohne Skins unter Windows XP, Anfang 2009

Mein Miranda ohne Skins unter Windows XP, Anfang 2009

Ich behalf mir nach jedem Update von ICQ 6 mit einem Tool, welches diese Werbung einfach entfernte. So einfach! Bis zu einem gewissen Update im Sommer 2008, nach welchem dieses Tool erst einmal nicht mehr funktionierte. Und damit wurde ICQ 6 für mich erst einmal quasi unbenutzbar, aber ich brauchte es. Und so kam die Erleuchtung! Ich machte mich auf die Suche nach einem Multi-Messenger, der möglichst wenig Leistung braucht. Und somit fand ich Miranda IM. Miranda war echt schnell und fiel im Prozessmanager von Windows kaum auf. Dementsprechend sah Miranda ohne jegliche Modifikation auch aus. Da habe ich sogar einen Screenshot von Anfang 2009 gefunden, wie das bei mir mal aussah. Bereits da verbrachte ich einige Zeit damit, alleine Miranda einzustellen, weil es schon zu dem Zeitpunkt so wahnsinnig viele Einstellungsmöglichkeiten gab! Mit dem Aussehen beschäftigte ich mich allerdings erst, als ich Miranda nach gut einem Jahr Benutzung nochmals komplett neu einrichten musste, da ich vor dem Formatieren von Windows vergaß, die Miranda-Sachen zu sichern.

Mein Miranda mit Skins (Dream), Mitte 2009

Mein Miranda mit Skins (Dream), Mitte 2009

 

Pfoten-Icons

Pfoten-Icons

Natürlich war das noch nicht das Ende. Anfang 2010 kam @KarnBlueEarring auf die Idee, die ICQ-Blume bei sich durch Pfoten zu ersetzen. Pfoten sind ja auch das Zeichen des Furry Fandoms. Er nutzte zu der Zeit noch den originalen ICQ-Client. Ich übernahm die Idee sofort und setzte da testweise eine Pfote um. Er adaptierte dies dann und erstellte sich daraus ein Icon-Set ICQ Paw! mit entsprechenden ICQ-Ornamenten (N/A-Schild usw.). Ich adaptierte seine Icons wiederum, da ich überwiegend weiterhin die Ornamente von Miranda haben wollte, für Offline-Kontakte keine rote, sondern eine graue Pfote und für den Status Unsichtbar keine Pornobrille, sondern einfach Transparenz. Die Icons nutze ich so auch heute noch, auch wenn ich sie gerne mal etwas umgestalten möchte.

Warum ich von Miranda IM weg wollte

Mich brachten ursprünglich drei Thesen dazu, von Miranda wegzuwollen:

  1. Miranda läuft nur auf Windows

    Ich besaß letztes Jahr die Motivation, von Windows wegzuwollen und ganz auf Linux umzusteigen. Primär lag das daran, dass auf Linux gefühlt so vieles einfacher ist, vor allem im Punkt Softwareentwicklung. Auf meinem Arbeitsplatz-Rechner läuft beispielsweise Gentoo Linux (vorher Debian Wheezy, davor Windows 7) und der Umstieg dort hat meine Produktivität definitiv gesteigert.

    Nur hakt der Vergleich mit Zuhause, denn dort mache ich nicht das, was ich überwiegend auf der Arbeit tue. Ich evaluierte meine Tätigkeiten und Workflows. Natürlich gibt es auf Linux für allerlei Dinge Alternativen. Allerdings waren die Resultate nicht so, wie sie sein sollten und das konnte ich nicht gebrauchen! Ich bin ja nicht einfach nur jemand, der nur im Internet surft und mal seine E-Mails abruft. Auf einen Dual-Boot-Kram wollte ich verzichten und auf eine virtuelle Maschine hatte ich auch keinen Bock. Oben drauf kam dann noch, dass ich – auch, wenn es selten ist – auch gerne mal Spiele spiele. Ich habe auch viel in der AppDB vom Windows-Emulator Wine recherchiert, aber die entsprechenden Experimente der User lasen sich wie Gruselgeschichten.

  2. Das Datenbankformat von Miranda

    Miranda speichert alles – Konfiguration und Nachrichtenverlauf – in einem komplett eigenen Datenbankformat mit der unglaublich aussagekräftigen Endung .dat. Und die Dokumentation zur Datenbank-Spezifikation? Tja, die heißt database.h und ist folgerichtig ein C-Header; siehe auch nächster Punkt. Die Datenbank ist quasi das gleiche wie die Windows Registry. Zwar mag es ganz schön sein, wenn man nicht die Festplatte mit tausenden Dateien aus jeder einzelnen Nachrichtensitzung zugemüllt hat, wie das beispielsweise Pidgin macht, aber dann hätte man doch bitte ein brauchbares Datenbankformat nehmen können!

    Allerdings ist mir diese .dat heilig. Sie gehört zu meinen heiligsten drei Dateien, neben meiner Passwortdatenbank und meiner Buchhaltungsdatenbank, um das heilig zu unterstreichen. Denn sie enthält eben meinen ganzen Nachrichtenverlauf und das sind mittlerweile mehr als eine halbe Millionen Nachrichten. Dort steht nicht nur Blabla drin, sondern beispielsweise auch Planungen für Projekte oder allerlei andere Sachen, um getroffene Aussagen beweisen zu können.

    Mit Synchronisierung sieht es da allerdings schlecht aus: Brauche ich meinen IM auf meinen Laptop, weil ich beispielsweise wegfahre, muss ich die Datenbank immer hin- und herkopieren. Sollte ich versehentlich mal die veraltete Datenbank nutzen und mir schreibt jemand, habe ich sofort ein verlorenes Update. Das letzte Mal, als ich versuchte, etwas Zusammenzuführen, ging das schief. Am liebsten würde ich mir also etwas Eigenes schreiben wollen, aber ich habe ehrlich gesagt keine Lust, mich in uralten C-Quellcode einzulesen, mal abgesehen von etwaigen Segfaults und anderen Problemen bei der Entwicklung und Benutzung, was sogleich zum nächsten Punkt führt.

    Allerdings sei noch erwähnt, dass es tatsächlich ein Programm gibt, was über mehrere Instant Messenger Nachrichten synchronisieren kann und als Zwischenbasis eine Datenbank nutzt. Das Programm ist allerdings von Russen entwickelt worden und jegliche Information/Dokumentation ist ebenso auf russisch. Ein lediglicher Export-Test in Miranda erwies sich als nicht zufriedenstellend.

  3. Miranda IM ist total veraltet

    Ich habe bewusst Miranda IM geschrieben, da Miranda NG diese Argumente bzw. Tatsachen teilweise falsifiziert; aber dazu später mehr. Wo es letztes und vorletztes Jahr, vor allem davor, immer wieder Updates gab, stagnierten diese sukzessive und enthielten immer weniger Bugfixes (Features quasi eh nicht mehr). Die Meisten Sachen interessieren mich auch gar nicht, da ich das gar nicht benutzte oder gefixte Problem nie hatte. Es gab seit Sommer ganze vier Updates mit je einem Punkt! Und das waren dann irgendwelche Installer-Probleme, die mich einen Scheiß interessierten, da ich schon immer die Archiv-Version benutzte (portabel, hell yeah!) oder einen Fix, der einfach irgendeine veraltete Kommunikation mit dem Updateserver ersetzt.

    Dabei hatte ich beispielsweise das fundamentale Problem, dass das Jabber/XMPP-Plugin immer wieder abstürzte und auf Jabber kann ich sicherlich nicht verzichten. Zwar stürzte Miranda nicht komplett ab, aber man bemerkte den Absturz des Plugins nur durch ein schönes Fehlerfensterchen; welches allerdings direkt verschwand, wenn man irgendwas drückte; beispielsweise beim Tippen einer Nachricht! Und wenn ich dann auf die tolle Idee kam, dann eine Nachricht in Jabber zu verschicken oder ich bekam eine… Tja, dann war die Nachricht verloren und Miranda fror komplett ein, sodass nur noch das Töten des Prozesses übrig blieb. Und das Problem passierte einfach immer mal wieder sporadisch. It’s not a bug, it’s a feature!

    Und das war der Benutzer-Teil. Jetzt folgt der Informatik-Teil: Die Codebasis von Miranda ist total veraltet und kaum dokumentiert, was nicht gerade förderlich ist. Nein, es ist sogar abschreckend! Mich hat es immer wieder erstaunt, wie auch noch 2013 Plugins für Miranda funktionierten, die seit 2005 nicht mehr geupdatet wurden – bei der Nutzung mit einem entsprechend mulmigen Gefühl. Selbst der Sourcecode der Plugins war, sofern dieser denn verfügbar war, überwiegend grausam. Sicher mag es den Entwicklern ja Freiheit geben, wenn sie ihre Plugins selbst in irgendeiner Art PASCAL schreiben können, aber dann doch auch bitte brauchbar!

    So wollte ich einmal die gesetzten Lesezeichen in meinem Nachrichtenverlauf auslesen. Diese Funktion stellt ein Plugin bereit. Ich gab allerdings nach 2-3 Stunden – ich habe ja anscheinend nichts Besseres zu tun – demotiviert auf, denn der Entwickler kam auf die tolle Idee, alle Lesezeichen serialisiert zu speichern. Serialisierung ist ja nichts Böses, wenn dies denn in standardisierten Datenformaten geschieht. In diesem Fall allerdings wurde ein Array mit Werten eines selbst-definierten Datentyps, bestehend aus mehreren anderen zusammengehangenen Datentypen, einfach aus dem Arbeitsspeicher kopiert und 1:1 in das Datenbankfeld geschrieben. Wow, noch fauler und weniger portabel geht es wohl kaum! Das einzige, was ich ja nun nur tun musste, war, diese serialisierte Zeichenkette an ihren richtigen Bytes zu trennen – was der Compiler des Plugins ja automatisch umsetzt. Dafür schaute ich mir den wunderschönen Quellcode etwas genauer an, denn im Kern waren dies ja wiederum Standardtypen und ich recherchierte dessen Byte-Längen im Arbeitsspeicher. Ich habe alle möglichen entsprechenden Längen mit Pythons unpack ausprobiert, aber intern waren da wohl noch irgendwelche Bits/Bytes, die alles kaputt machten und somit bekam ich immer nur Datenmüll. Und irgendwann hatte ich einfach keine Lust mehr.

Evaluation eines neuen Instant Messengers

Wirklich viele Auswahlmöglichkeiten bestanden nicht. Meine Recherche zur Popularität von Instant Messengern – bezogen auf Windows – ergab, dass es nur so wirklich eine Top 3 gab, bestehend aus Trillian, Pidgin und Miranda IM selbst. Zwar gab es ja auch noch andere Messenger, aber die beachtete ich nicht weiter. Das lag an der Plattform, an etwaiger mangelnder Popularität und dementsprechenden Folgen, wie beispielsweise keiner Community, keinen Plugins (wenn überhaupt erweiterbar) und eventuellen Updates, sowie auch einfach aufgrund der Lizenz und Bedenken gegenüber des Datenschutzes.

Trillian

Trillian testete ich 2008 schon einmal. Allerdings kann man den Stand von diesem Trillian nicht mit dem heutigen vergleichen. Trillian war damals geplagt von Abstürzen und allerlei anderen Problemen, die aber mittlerweile alle passé sind. Ich muss allerdings dazu sagen, dass ich in dieser Evaluation Trillian nie eigenständig getestet habe. Stattdessen schaute ich mir Screenshots an und @Aica87, als überzeugte Nutzerin von Trillian, war äußerst kompetent, mir von Trillian Pro Fragen und Vergleiche beantworten zu können, obwohl sie gar keine Informatikerin ist. Ehrlich gesagt machte sie mir Trillian ziemlich schmackhaft und dachte schon, ich hätte meinen zukünftigen Instant Messenger gefunden. Sicherlich kann ich jetzt nicht alles auflisten, was ich gutgeheißen habe, denn die Kommunikation über Trillian mit Aica lief über einige Monate. Dennoch schaute ich mir aber Trillian auch bei den für mich wesentlichen Punkten im Detail an.

  • Die Firma

    Cerulean wirkt mir ganz sympathisch. Trillian wirkt stabil und die Firma pflegt auch ihr Produkt, Enterprise-Produkt. Wenn User Diskussionen auf Trillians Hilfsplattform starten, dann scheuen sich auch Support-Mitarbeiter nicht davor, auch mal technische Details rauszurücken über interne Funktion oder Infrastruktur. Eine Firma hinter einem Produkt hat auch den starken Vorteil, Support erhalten zu können. Ob dieser Support nun gut oder schlecht ist, ist die andere Frage. Aber dieser Punkt soll nur am Rande erwähnt sein.

  • Aussehen

    Trillian gefiel mir vom Aussehen her. Außerdem konnte man da auch manche Sachen anpassen, so wie ich von Aica erfuhr. Zu einer genaueren Untersuchung diesbezüglich kam ich aber nicht.

  • Integration von Skype mit SkypeKit

    Trillian ermöglicht es, Skype direkt zu benutzen, ohne dass der Skype-Client selber dafür laufen müsste. Der Gedanke gefiel mir sehr, denn in Skype habe ich Kontakte, die ich nirgendwo anders habe. Nur ging es mir immer auf den Zeiger, den Skype Client dann laufen lassen zu müssen und somit war ich einfach so gut wie nie online. Darunter litten dann beispielsweise leider auch Internet-Freundschaften. Zwar bot Miranda IM ein Skype-Plugin, aber das nutzte nur die Skype API (der Skype Client musste also im Hintergrund laufen) und es verursachte auch nur mehr Probleme, als dass es half.

  • Plattformen und History-Sync

    Trillian läuft auf Window (und Mac), auf iOS und mittlerweile sogar auf Linux. Dazu bietet Trillian in der Pro-Version sogar an, Nachrichten auf diesen verschiedenen Plattformen synchronisieren zu können. Das mochte für ja ganz schön klingen, da mir meine History heilig ist (siehe Warum ich von Miranda IM weg wollte). Allerdings betitelt Trillian dieses Feature als Cloud history. Alleine beim Wort Cloud sollten schon die Alarmglocken schlagen und das war bei mir auch schon vor der NSA-Affäre der Fall. Die Logs werden zwar verschlüsselt auf dem Server gespeichert, aber es ist doch genauso, wie bei jedem anderen Cloud-Anbieter: Den Schlüssel hat man nicht selbst, sondern der Anbieter. Anscheinend hat Cerulean aber vor, irgendwann einmal Verschlüsselung zu bieten, welche noch lokal stattfindet, bevor der Upload auf ihre Server erfolgt. Das wurde hier geschrieben. Trillian speichert die History nach wie vor in einem XML-Format und damit hätte ich auch etwas Eigenes machen können.

  • Kein OTR und closed-source

    Off-the-Record Messaging – Nachrichten-End-zu-End-Verschlüsselung – ist einfach etwas, das sein muss. Wenn man sich mal die Hilfsplattform von Trillian anschaut, so taucht das Thema OTR immer wieder auf. Als ich selber Ende September hier einen kurzen Kommentar verfasste, sorgte das schon für ein kleines Aufflammen. Als ich mit der Evaluation begann, beschäftigte ich mich mit dem Thema Trillian und OTR nicht, weil ich irgendwann mal gelesen hatte, dass es ein Plugin dafür gäbe. Und natürlich dachte ich, dass das Plugin auch in heutiger Zeit reibungslos funktionieren würde, denn OTR ist ja irgendwie schon etwas Essentielles und bei Miranda und Pidgin wird OTR auch über Plugins bereitgestellt (und funktioniert reibungslos). Als ich aber dann darüber recherchierte, fand ich unter anderem die eben verlinkte Diskussion und Ernüchterung trat ein. Somit brauchte es nur dieses eine Argument und Trillian war für mich erledigt. Aber selbst wenn Cerulean OTR direkt in Trillian implementiert: Woher soll man wissen, dass das Unternehmen nicht irgendwelche Abhörschnittstellen einbauen muss, denn es ist ja closed-source? Daher würde es für mich selbst dann, wenn Trillian (wieder) OTR hat, ein weiteres tödliches Argument geben.

    Anmerkung: Vor ein paar Tagen schrieb @eiszfuchs mir, dass er Trillian erfolgreich mit diesem Plugin nutzen würde.

Pidgin

Pidgin gilt als der freie Nonplusultra-Client. Durch die Kern-Bibliothek libpurple und der Verwendung des GIMP-Toolkits (GTK+) für die Oberfläche läuft Pidgin problemlos unter Linux (wo es auch herkommt), Windows und mit Eigeninitiative auch anderswo; Mac sei hier ausgeschlossen, da es dort mit Adium quasi den nativen Bruder von Pidgin mit gleicher Kern-Bibliothek gibt. Pidgin ist dementsprechend sehr populär, wird aktiv gepflegt und bietet eine große Community und viele Plugins. Da Trillian ausgeschieden war, blieb mir demnach nur noch Pidgin.

  • Datensicherheit

    Schon im Voraus hatte ich gelesen, dass Pidgin gespeicherte Passwörter im Klartext speichert. Mir ist bewusst, dass Sicherheit durch Verschleierung nicht funktioniert, aber muss man es echt so einfach machen, dass man einfach an einem festen Pfad eine XML-Datei auslesen muss? Miranda speichert zwar seine Passwörter im Prinzip nicht anders, allerdings sind die irgendwie verschleiert und stehen in der Struktur eines eigenen Datenbankformats, dessen Spezifikation und Dokumentation lediglich eine C-Header-Datei ist; siehe Das Datenbankformat von Miranda.

  • Portabilität auf Windows

    Da mir das mit Pidgin und Evaluation gleich zu vage war, war der dementsprechend erste Schritt, es runterzuladen. Ich hasse das Tätigen von Installation auf Windows und bevorzuge portable Software, die sich nicht irgendwo in versteckte Ordner, einer absolut nicht portablen Konfigurationsdatenbank oder weiß der Geier wo noch, einnistet. Miranda benutze ich seit Anfang auch portabel und Miranda stellt da einfach ein Archiv bereit. Und bei Pidgin? Also direkt gibt es da nichts, was wohl an GTK+ liegen dürfte. Es gibt eine Anleitung, wie man sich Pidgin selber portabel macht, aber das nach jedem Update machen zu müssen, wäre ein ziemlich großer Aufwand. Es gibt eine Version von PortableApps, aber auf Fremdquellen möchte ich gerne verzichten. Es gibt auch noch die Fremdquelle portable-pidgin.de und diese nutzte ich zwar dann auch, aber so toll fand ich den Punkt Fremdquelle trotzdem nicht, da man bei einem Update auch wieder hätte rumkrebsen müssen.

  • Log-Format der History

    Pidgin legt für jeden Kontakt für jede neue Nachrichtensitzung eine Textdatei an. Mir ist sicherlich bewusst, dass es Unix-Philosophie sein mag, Daten in viele Dateien auszulagern. Nur da frage ich mich: Wie viele Dateien werden das denn dann, wenn man Pidgin ein paar Jahre benutzt und da ein paar hunderttausend Nachrichten zusammenkommen, wie es bei meiner Miranda-History mittlerweile der Fall ist? Wohlgemerkt besteht eine neue Nachrichtensitzung bereits dann, wenn man zwischenzeitlich das Nachrichtenfenster schließt. Pidgin läuft sicherlich nicht auf einem Server, sondern eher auf einem Desktop-Rechner, der höchst selten Server-Konfiguration (entsprechende Festplatten und RAID > 0) haben sollte. Sicherlich könnte man die Dateien auf lange Sicht in einem Archiv archivieren und komprimieren. Aber das verfehlt meiner Meinung nach die Möglichkeit, sich die Verläufe einfach wieder anschauen zu können. Da haben sich anscheinend schon einige Benutzer in diversen Tickets gewünscht, dass Pidgin so etwas Simples wie eine SQLite-Datenbank (von der Textdatenbank zum Datenbanksystem – REVOLUTION!) benutzt, aber Pläne der Entwickler scheint es dafür nicht zu geben. Es wird immer nur auf Ticket #943 verwiesen, welches mittlerweile sechs Jahre alt ist (mittlerweile hat der Ticketzähler fast 16000 erreicht) und in dem seit vier Jahren nichts mehr passiert ist. Das Log-Format ist auch nicht gerade rosig: Text oder HTML. Semantischer Aufbau? Vielleicht bei den Textdateien ohne jegliche Semantik, aber beim Format der HTML-Dateien sieht es chaotisch aus.

  • Anpassbarkeit und Plugin-Chaos

    Ich möchte nicht bestreiten, dass Pidgin nicht anpassbar ist. Nur wenn ich die Möglichkeiten mit Miranda vergleiche, dann ist Pidgin stark beschränkt. Natürlich ruft dieser Gedanke ja nun Plugins auf den Plan, aber… Welche Plugins denn überhaupt? Das portable Pidgin von portable-pidgin.de hatte direkt einige Plugins mit an Bord, wo aber die meisten glücklicherweise deaktiviert waren. Irgendwie scheint es Gang und Gebe zu sein, dass Plugins von Pidgins in der Regel winzig sind und so redundant, dass sie sich gegenseitig blockieren und man durch die Masse an Plugins erschlagen wird, ohne wirklich das zu bekommen, was man haben möchte.

    Primär versuchte ich das Nachrichtenfenster anzupassen, wo ganze drei Plugins, und Pidgin selber, mitwirkten. Das ganze erinnerte mich an logische Rätsel in Computerspielen, beispielsweise aus Tomb Raider: Dreht man eine Figur, drehen sich die anderen Figuren in die andere Richtung. So war es mit den Optionen der Plugins: Aktivierte man das eine, funktionierte das andere nicht. Und dann gab es in den Pidgin-Einstellungen auch noch Optionen, die Wirkungen von Plugins wiederum veränderten, wo man anhand des Labels nie drauf gekommen wäre und plötzlich funktionierte doch fast alles. Oder auch nicht, weil man andere Sachen wieder deaktivierte. Wenn ich ein logisches Spiel spielen möchte, dann möchte ich das auch bewusst tun. So etwas habe ich bei Miranda nie erlebt und dort habe ich definitiv sehr viel mehr ausprobiert und konfiguriert als in Pidgin und eben das bekommen, was ich auch haben wollte.

  • Anpassbarkeit des Aussehens

    In erster Linie klingt dieser Punkt schwach, aber es geht eher um die praktische Natur und der daraus folgenden Effizienz als um die ästhetische Natur. Wenn man von Miranda kommt, dann wirkt Pidgin aufgrund seiner mangelnden Einstellungsmöglichkeiten wie ein Kulturschock. Ich bin kein Freund von überdesignten Oberflächen und mag auch schlichte Oberflächen, was Pidgin ja bietet. Die gewaltig hervorstechenden Toolbar-Buttons im Nachrichtenfenster waren ja auch noch steuerbar durch Plugins. Aber die Formatierungen der Nachrichten im Nachrichtenfenster empfand ich – und empfinde ich immer noch – als absoluten Graus. Hier ging es mir einfach darum, dass in einem Nachrichtenfenster, was schon an sich größer ist als die Nachrichtenfenster von meinem Miranda, viel weniger Text reinpasst, was vor allem bei sehr langen Nachrichten mehr als nervig ist.

    Jetzt kann man natürlich dazu übergehen, das Nachrichtenfenster seinen Wünschen anzupassen. Genau das versuchte ich auch, wie im vorherigen Punkt erkennbar sein sollte. Nur war das Resultat nicht optimal: Wenn man einfach die Schrift änderte und kleiner machte, wurde das Ganze immer mehr unleserlich, weil die Höhe der Textzeilen proportional immer noch zu hoch war, aber vermutlich konnte man das über den GTK-Stil einstellen. Wenn man die Schriftart und Schriftgröße allerdings änderte, dann änderte sich jegliche Schrift im gesamten Fenster – für einzelne Elemente (Name, Datum, Nachrichtentext) war dies im Fenster nicht möglich. Aber genau so etwas stellte ich mir in Miranda ein, weil ich viel Text auf wenig Platz schnell lesen kann! Genauso erwies sich das Einstellen von Farben als nicht sehr umfänglich, denn der visuelle Reiz spielt auch nochmal eine Rolle bei so kleiner Schrift, wie ich sie effizient nutze. Schlussendlich kam noch der Name bei jeder Nachricht dazu. Ich weiß nicht, ob man das doch ausstellen kann, aber Miranda gruppiert mir durch irgendeine Einstellung die Nachrichten und schreibt den Namen dann nur als quasi Kopfzeile, was auch eine Menge Platz spart.

    Adium, der native Bruder von Pidgin auf Mac (und leider nur Mac), beherrscht etwas, das nennt sich Message Styles. Man kann damit eigene Styles für das Anzeigen der Nachricht festlegen, beispielsweise so etwas, wie man das auch von Smartphones kennt. Als Renderer für diese Styles wird Webkit verwendet, was – wie man weiß, als Basis von Blink, also Google Chrome – sehr viel kann, im Gegensatz zu irgendeinem HTML-Modul von GTK, wie es in Pidgin für die Anzeige der Nachrichten verwendet wird. Zwar wurde versucht, auch ein Webkit-Renderer-Plugin für Pidgin zu entwickeln, was auch diese Message Styles unterstützte, aber das wurde irgendwann aufgegeben – wie man das so kennt.

    Selbst wenn ich mich mehr in GTK2-Stile eingelesen hätte, so hätte ich die Ansicht, wie ich sie in etwa haben wollte, damit wohl nicht umsetzen können. Ein eigenes Render-Plugin dafür zu entwickeln, für Pidgin, das wäre sicherlich Wahnsinn gewesen, aber vermutlich wäre ich diesen Schritt sogar gegangen, wenn es nicht möglicherweise eine einfachere Möglichkeit gegeben hätte.

Das alles heißt allerdings nicht, dass mir Pidgin komplett missfallen hat. Ich habe mich bei Pidgin auch an Kleinigkeit erfreut, wie beispielsweise (mit einem Plugin) eine bessere Integration mit Windows Aero oder dass bei Nachrichtenfenstern in der Taskleiste der Avatar des Benutzers angezeigt wird. Metakontakt-Funktionalität, was momentan für mich auch ein wichtiger Punkt ist, wirkt in Pidgin auch sehr stabil umgesetzt, während das in Miranda über ein eigenes Proktoll als Plugin passiert und mir ohne bisherige genaue Untersuchung nicht geheuer ist. Ich habe die Evaluation von Pidgin nicht durch die negativen Punkte, die ich hier aufgelistet habe, beendet, sondern weil ich zeitgleich herausgefunden hatte, dass es einen Fork von Miranda IM gab und beschäftigte mich dann direkt mit diesem.

Die Abspaltung Miranda NG

Während ich noch mit dem Nachrichtenfenster von Pidgin kämpfte Pidgin evaluierte, kam ich irgendwie auf die Idee, nach Miranda zu googeln. Mich interessierte, wie es updatemäßig und entwicklungstechnisch ausschaut, denn ich merkte schon, dass mir Pidgin nicht gefiel. Und da stieß ich plötzlich auf Miranda Next Generation, welches ich mir eifrig runterlud.

Migration

Ich machte also ein Backup von Miranda IM. Dieses hatte dann eine größe von 2 Gigabyte, die sich zur Hälfte in Backups der Miranda-Datenbank und den empfangenen Dateien aufteilte. Die Datenbank an sich war mittlerweile größer als 45 Megabyte, aber eben mit dutzenden Backups. Ich lud mir das Plugin IM Updater runter, dessen einziger Sinn es war, Miranda IM zu Miranda NG automatisch zu migrieren. Nach dem Extrahieren von Miranda NG direkt in den Miranda IM Ordner erschien nach dem Start sogleich ein Updater für Plugins, der die Plugins automatisch aktualisierte – so etwas gab es in Miranda IM nie! Aber eigentlich war das auch nicht nötig, da etliche Plugins eh seit Jahren nicht mehr geupdatet wurden (siehe oben).

Allerdings war der Skin meiner Kontaktliste zerschossen (Dream, siehe Screenshots oben). Ich schaltete diesen also um und hatte dann gar keinen Button mehr, um ins Hauptmenü zu kommen, da alles deaktiviert war. Und ich wusste auch nicht, ob es dafür eine Tastenkombination gab. Also nutzte ich das Backup und versuchte es später nochmals. Zwar funktionierte Dream mit einem anderen Kontaktlistenplugin noch, aber ich dachte mir, dass ich ja mal kurz nach einem neuen dunklen Skin schauten könnte.

Mein Miranda mit Dark-Skins

Mein Miranda mit Dark-Skins

Und wie ich fündig wurde! Ich fand dann ein Pack namens Miranda Dark Aero von einer russischen Seite. Ich lud es mir dann lediglich runter, um zu schauen, welche Skins es benutzt, denn das Aussehen gefiel mir. Denn im Endeffekt waren dies drei Skins, die vom gleichen Designer stammen: Kontaktliste Dark MI, Nachrichtenfenster (Rahmen) Dark TS und Pop-ups Dark MI. Eigentlich noch ein vierter für IEView Cult – Style für das Inhalt des Nachrichtenfensters direkt –, aber da wollte ich erst einmal das weiße Fenster behalten. Außerdem gab es jetzt Avatare mitten in der Kontaktliste, Evolution! Allerdings weiß ich nicht, ob das schon vorher möglich war – jedenfalls hatte ich es vorher nicht und hatte es dann ohne weitere Einstellung. 

Ein Test mit den Testkontakten in Pidgin und ein wenig Rumklickerei ergab, dass das Update reibungslos verlief. Allerdings fehlte mir etwas: Ein Button zum Minimieren der Kontaktliste. Zwar gab es einen Toolbar-Button dafür, aber das war eben nicht das gleiche, wie in der »Fensterleiste«. Ich ging also hin, extrahierte die Grafik vom Nachrichtenfenster und baute mir einfach selber in den Skin ein Button zum Mininieren ein. Das war schon etwas nervig, da es nirgends eine Dokumentation gab über das komische Format für Skins dieses Kontaktlisten-Plugins. Außerdem funktionierten wieder Sachen, die ich gar nicht mehr kannte, beispielsweise Pop-up-Benachrichtigungen von Statusänderungen.

Der Fork

Wie in Warum ich von Miranda IM weg wollte beschrieben, passierte updatemäßig so gut wie nichts mehr bei Miranda IM. So, wie ich gelesen hatte, lag dies an der restriktiven Entwicklung, denn der Hauptentwickler schien zuletzt quasi autoritär zu herrschen. Es war für nicht-Entwickler auch nicht möglich, etwaige Patches einfach bereitzustellen, da es so etwas wie einen Pull Request nicht gab. Es dauerte ewig, bis Entwicklungen im Kern von Miranda auch in Plugins landeten, wenn denn überhaupt. Nach einem Disput zwischen den beiden zu dieser Zeit aktivsten Entwicklern verließ einer der beiden auch das Projekt und erstellte im April 2012 den Fork Miranda NG, was dem Projekt wohl das Leben rettete. Bis zum ersten Release vergingen vier Monate, denn es wurde der Source-Code diverser Plugins zusammengesucht (falls dieser überhaupt verfügbar war), es wurden tausende Stellen Code überarbeitet und auch alle Plugins. Der Fork hat sogar wieder inaktive Miranda-Entwickler reaktiviert für das Projekt. Link: Miranda NG: About

  • Verschlüsselte Datenbank ohne Plugin. Aus eigener Erinnerung weiß ich noch, dass das schon vor Jahren gewünscht wurde, aber nie in Miranda IM umgesetzt wurde. Ich weiß nicht, ob andere Clients so etwas überhaupt bieten – Pidgin jedenfalls nicht.
  • Es gibt nun einen Plugin-Updater. So etwas gab es zu Zeiten Miranda IMs nicht. Natürlich nicht, denn die Plugins lagen ja überall verstreut. 
  • Die verfügbaren Plugins sind zumindest teilweise neu geschrieben. Wie oben geschrieben, hatte ich schon Angst, ein Plugin zu nutzen, welches das letzte Mal im Jahr 2005 aktualisiert wurde und viele Jahre später immer noch funktionierte.
  • Planung, native Metakontakte umzusetzen. Was andere Instant Messenger nativ können, kann Miranda nur durch ein Plugin. Dieses Plugin allerdings implementiert ein eigenes Protokoll und delegiert alle Nachrichten über die Plugins hin- und her, genauso wie es den Nachrichtenverlauf synchronisiert und was noch alles. Kurz: Das Plugin war nie geheuer, auch wenn ich gerne eine Metakontakt-Funktionalität hätte. Aber diese soll in Miranda NG direkt im Kern umgesetzt werden, nachdem das Datenbank-Format umgestellt – revolutioniert – wurde.
  • Die Entwicklung findet nun offen statt. Jeder kann Patches einsenden und Feedback geben. Das ganze nennt man auch Social Coding, was Miranda IM nicht kannte.
  • Der Code wird aufgeräumt. Wie oben schon geschrieben, war der ganze Miranda IM Code und auch von den Plugin, einfach grausig. Da das Miranda NG Team sich von vielen Altlasten verabschiedet, entschlackt dies das Projekt schon um viel alten Code. Dazu haben sie die Ambition, dem Code generell ein großes Refactoring zu unterziehen, mit dem sie bereits direkt nach dem Forken begannen. 
  • Dynamisches Nachladen von Plugins. Bei Miranda IM musste man für jede Plugin-Änderung Miranda IM neustarten. Bei Miranda NG braucht man das – solange es sich nicht um sehr zentrale Plugin, wie Protokolle, handelt – nun nicht mehr.
  • Keine ANSI-Versionen mehr. Es gab von Miranda IM von jeder Version immer ANSI- und Unicode-Versionen. Solche uralten DOS-Betriebssysteme, wie Windows 98, können kein Unicode. Durch die Berücksichtigung von zwei Zeichenkodierungen überall im Code war dieser natürlich ziemlich wartungsunfreundlich und eine enorme Altlast. Kurzum wird so etwas wie Windows 98 nicht mehr unterstützt, aber wer nutzt so etwas noch? Bei den Miranda-Downloads gab es jedenfalls witzigerweise immer noch Downloads dieser Version. 
  • Dritt-Anbieter-Bibliotheken wurden aktualisiert. In Miranda IM waren die benutzten Version uralt. Vermutlich hatte niemand einfach die Lust dort, eine neuere Version auszuprobieren und dann alle etwaigen Bugs zu fixen. Oder überhaupt wieder zum Laufen zu bringen.
  • Und viel mehr

Bei all den Plänen, die sie haben und anstreben, kann man sagen, dass Miranda bald nicht mehr wirken wird, als sei es total veraltet. Es gibt jeden Monat eine neue Version vom Hauptprogramm und Updates der Plugins. Zwar zielen die Updates momentan primär auf Stabilität und Refactoring ab, allerdings sind mir auch viele neue Features bisher aufgefallen. Oder eben auch Funktionalitäten, die einst funktionierten, dann ewig lange nicht mehr und jetzt plötzlich wieder funktionieren.

Aber was ist denn nun mit meiner Kritik am Datenbankformat von Miranda und der Synchronisierung, wie oben geschrieben? Tja, da wird mir, bis auf das manuelle Synchronisieren der Datenbank, erst einmal nichts übrig bleiben. Mittlerweile habe ich aber die Motivation, mir ein entsprechenden C-Plugin für Miranda selber zu schreiben und mit meinem Projekt MsgPort zu verknüpfen. Die Umsetzung scheint ja dann auch einfacher zu werden, da der Code sukzessive verbessert wird. MsgPort soll so ein Programm werden, was eben Nachrichten aus diversen Sachen synchronisieren sollen kann. Das bisherige MsgPort ist in Python 3 geschrieben und kann nur Miranda-Nachrichtenverläufe exportieren und hat schon eine generelle Grundstruktur für Bedienung und Datenbank. Aber da muss ich mal schauen, wie ich damit weitermache. 

Fazit

Ehrlich gesagt bin ich ziemlich froh darüber, dass ich bei Miranda bleiben konnte und anderseits auch betrübt, dass ich erst so spät etwas von Miranda NG gehört hatte. Miranda NG ist wohl das Beste, was dem Projekt in der Neuzeit passieren konnte! Es ist jetzt falsch, noch zu sagen, dass Miranda veraltet wäre – dieser Umstand wird nun sukzessive korrigiert, sofern man eben nicht noch Miranda IM benutzt. Wenn man allerdings Google befragt, erscheint beim Suchwort Miranda natürlich nach wie vor Miranda IM und viele Seite zielen auch darauf ab. Es bleibt daher nur zu hoffen, dass Miranda NG viel bekannter wird und das Projekt vielleicht auch etwas daran tut, dass es auf manchen nicht so abschreckend wird, wenn man es nach dem ersten Start betrachtet.

Danksagungen

Da sich diese Evaluation über mehrere Monate hinweg zog, hatte ich das Thema auch mit anderen Leuten, die mir auch so manchen Input gaben. Danke besonders an an @Aica87, mit deren Hilfe ich viel über Trillians Bedienung und Umsetzung erfahren konnte. Dann sei noch @tweetkiba genannt, der mir einigen Input über Instant Messenger auf Linux geben konnte. Zuletzt gab mir auch noch @eiszfuchs Input über Trillian.

Danke außerdem noch an die Teams von Miranda IM, Miranda NG und alle weiteren Mitwirkenden, die Miranda zu dem gemacht haben, was es ist!