Stümpern mit Niveau

 Java, Software  Kommentare deaktiviert für Stümpern mit Niveau
Aug 012019
 

Ab und zu – die Frequenz ist uneinheitlich, die Rahmenbedingungen unbekannt – neige ich dazu, irgendein IT-Thema mal genauer zu betrachten und ein paar Experimente durchzuführen. Quasi um immer wieder das “innere Komplexitätsgefühl” neu zu justieren. Ich stelle eine gewisse Häufung beim Thema “Protokolle” fest, vielleicht die masochistische Ader die mich schon zur Implementierung einer CD-/DVD-/BluRay-Brenner-Software gebracht hat. Ziel ist immer, bei einer Sache von Quasi-Null-Wissen auf mindestens 3 zusätzliche Seiten im persönlichen Handbuch des nutzlosen Wissens zu kommen. Quasi qualifiziertes Halbwissen, das jede Fachdiskussion unter einer Stunde locker überlebt.

Diesmal das Thema: IPP, das “Internet Printing Protocol”, das im Rahmen einer Diskussion im Kontext meines Lieblingsbetriebssystems RISC OS eher zufällig aufgekommen ist. Früher dachte ich, IPP sei quasi nur “Druckdatenstrom per HTTP an den Drucker übermitteln”. Sowas wie “JetDirect über HTTP”. Oh Mann, lag ich falsch. Oder besser: es ist eine sehr simplifizierte Beschreibung der Wirklichkeit, und qualifizierte mich damit als “Quasi-Null-Wissenden”.

In Wahrheit hat IPP interessantes Potenzial für die RISC OS-Welt, nämlich “driverless printing”. Man kann per standardisierten Requests den Drucker zu seinen Eigenschaften befragen (Papierzufuhroptionen, Nachbearbeitungsoptionen, Duplex oder nicht und wenn ja wie), zu seinem Status (Tonerstand/Tintenstand, Papierstau etc.) und es gibt ein plattformübergreifendes Rasterformat (“PWG Raster Format” – PWG ist die “Printer Working Group”, die hinter IPP steht), das zum Druck verwendet wird. Zusätzlich vermelden netzwerkverbundene Drucker ihre Anwesenheit über das Bonjour-Protokoll, aber auch direkt verbundene USB-Drucker werden unterstützt. Das Gesamtkunstwerk nennt sich IPP Everywhere. Also die Lösung aller Probleme der Art “klar gibt es da diesen Drucker XYZ, aber für Betriebssystem ABC gibt es leider keine Treiber” – heute behilft man sich da (zumindest im RISC OS-Markt) mit der oberen Preisklasse der PostScript- und PDF-fähigen Drucker, muss aber immer noch tricksen um mit speziellen Druckerfeatures arbeiten zu können.

Die IT wäre nicht die IT, wenn nicht zwei konkurrierende andere Lösungen gleichzeitig um die Gunst des Anwenders (interessiert den das eigentlich?) buhlen würden: AirPrint (von Apples Gnaden) und Wi-Fi Direct Print. So weit, so ärgerlich. Zurück zu IPP. Dessen Charme ist die Verfügbarkeit eines gut dokumentierten Standards, bei den beiden Konkurrenten sieht es da nicht ganz so gut aus, dafür waren diese früher am Markt und sind (deshalb?) deutlich weiter verbreitet – IPP Everywhere wird heute eigentlich nur von einer Reihe von HP-Druckern unterstützt.

Wie auch immer, ich fasste ein Ziel ins Auge: mit meinem IPP-fähigen (aber natürlich nicht IPP Everywhere-kompatiblen, weil Baujahr 2011) Oki C530 ein PDF zu drucken, indem über IPP der PDF-Datenstrom an den Drucker geschickt wird.

Wie anfangen? Der IPP-Guide erzählt von 40 Spezifikationen mit insgesamt fast 2000 Seiten, das schien jetzt etwas ambitioniert. Aber es gibt JIPP, eine Java-Implementierung von IPP von HP, verfügbar auf GitHub. Unter der guten MIT-Lizenz. Da waren Beispiele dabei. Wie schwer kann es also sein?

Erste Hürde: das Github-Projekt hostet nur Source-Releases. Kein Problem, man kann ja selber bauen. Stellt sich raus: ist Kotlin-Code, gebaut mit Gradle. Hm. Bin ich jetzt für beide Dinge nicht so der Experte, vielleicht ein Experiment für ein anderes Mal. Google führt mich zu einer sinnvollen Paketierung des Codes inklusive aller seiner Abhängigkeiten (wie der Kotlin-Runtime – auch nicht gerade schmal das Dingens). Also schnell ein IDE-Projekt aufgesetzt und los geht’s. Ich arbeite mit Version 0.6.16 – nur falls jemand ein paar Jahre später über diesen Artikel stolpert und bis hierher durchgehalten hat.

Das jprint-Beispiel (inzwischen übrigens – ohne meinen Input und erst vor wenigen Stunden! – signifikant verbessert, an einigen der Stolperfallen) erst mal als Basis genommen. Ein PDF an die bekannte IPP-URL des Druckers geschickt. Eine dubiose Exception war das Ergebnis (aus dem HTTP-OutputStream: java.io.IOException: Error writing request body to server) – wies darauf hin, das irgendwas mit der URL nicht stimmte. OK. Ein paar Varianten durchprobiert (offenbar gibt es typische Implementierungen der Form ipp://irgendneip/ipp und ipp://irgendneip/ipp/lp und http://irgendeineip/ipp und http://irgendeineip:631/ipp – an dieser Stelle die Nebenerkenntnis, dass IPP schlicht HTTP-mit-631-als-Default-Port ist). Manchmal den gleichen Fehler, manchmal einen anderen Fehler (java.net.SocketException: Software caused connection abort: recv failed). Dubios. Weiter rumprobiert. Stellt sich raus: auch bei derselben URL kommt manchmal die eine Exception, manchmal die andere. Aha. Dann doch kein Connection-/URL-Problem? Mal den Code genauer anschauen. Als Transportmechanismus wird eine Klasse namens “IppPacket” verwendet. Da gibt es einen alternativen Konstruktor, der auch eine “ippVersion” (ein int wie es sich gehört) entgegen nimmt. Könnte es sein, dass mein Drucker (aus der Zeit von IPP v1.1) mit dem Default von JIPP (IPP v2.x) einfach nicht klarkommt? Mehrfaches Ausführen des Codes mit stets derselben URL führt tatsächlich manchmal zu einer Exception-losen Verarbeitung des Kommandos mit der Fehler-Rückmeldung “server-error-version-not-supported”, was den Verdacht erhärtet.

Etwas später ist klar: dummerweise erlaubt der Konstruktor von IppPacket, der eine explizite Versionsangabe erlaubt, nicht dieselben Typen an Restparametern, insbesondere nicht den “Operation”-Enum, sondern auch nur einen int. OK, ein paar RFCs zum IPP gelesen und herausgefunden, dass das Kommando getPrinterAttributes 0x0B ist und printJob 0x02. Minuten später sehe ich, dass der Enum innen drin die ints eh auch definiert hat. Grmpf. Ist bestimmt so ein Kotlin-Automatismus. Bleibt die Frage: wie spezifiziert man jetzt in einem int eigentlich “1.1” als Version? Na per 8+8 Bit natürlich. Also 0x0101 für meine Zwecke. Prima. Erstmal getPrinterAttributes probieren statt gleich das PDF zu schicken. Das Kommando wird jetzt zuverlässig verschickt, aber JIPP kann das Resultat nicht unfallfrei parsen – ob das eine Schwäche von JIPP ist oder eine Abweichung von der Spezifikation seitens meines Druckers ist noch ungeklärt, aber Gott sei Dank hat der JIPP-Programmierer bei solchen Parse-Fehlern daran gedacht, die Rohdaten des Replys, der nicht parsebar waren, herauszudumpen. Also konnte ich einfach inspizieren, was mein Drucker so als Fähigkeiten zurückmeldet.

Nachdem das Kommando-Schicken nun völlig problemlos funktionierte, machte ich mich an die eigentliche Aufgabe, den Druck eines PDFs – der Oki unterstützt sowohl direktes Drucken per PostScript als auch per PDF, und PDFs finden sich auf der Platte entschieden leichter. Ein einseitiges Dokument identifiziert und per offiziellem PDF-MIME-Type “application/pdf” zum Drucker geschickt. Kommt zurück: “client-error-attributes-or-values-not-supported”. Eine sprechende Fehlermeldung! Sehr schön. Inspektion der bei getPrinterAttributes zurückgemeldeten Fähigkeiten zeigt: “application/pdf” wird auch gar nicht akzeptiert, nur “application/octet-stream”, “application/vnd.hp-PCL” oder “application/postscript”. Einfach mal “application/octet-stream” geraten, und siehe da: es wird gedruckt.

Na das war ja einfach.

Zu klärende offene Fragen: 1. Nützt mir das jetzt was für IPP unter RISC OS? 2. Wie erzeuge ich möglichst einfach das PWG-Raster-Format aus einem beliebigen Quellformat? 3. Warum drucke ich nicht einfach PDF über einen CUPS-Druckerserver, der ja auch IPP out-of-the-box kann?

Antworten: 1. Noch nicht. 2. Sieht nicht so schwierig aus, auch keine ultrakomplexe Kompression, sondern simples PackedBits-Format und anständig dokumentiert. 2a. Aber auch JPEG wird als Format im Standard zwingend vorausgesetzt – noch einfacher! 3. Weil das ja jeder kann.

Interessanter Beifang: AppImage als Paketiervariante für Linux-Anwendungen. Spannend, kannte ich noch nicht.

Bits frickeln mit Java

 Java, OS, Software  Kommentare deaktiviert für Bits frickeln mit Java
Aug 072018
 

Gerade bin ich dabei – zum besseren Kennenlernen von Filecore-basierten Dateisystemen (man muss den Feind kennen) – in Java ein kleines Tool zu entwickeln, das Disc-Images im Filecore-Format versteht und Dateien und Verzeichnisse daraus extrahieren kann. Nur lesend, um weitere Komplexitäten erst mal zu vermeiden.

Etwas Hintergrund: Filecore ist das native Dateisystem unter RISC OS. Oft wird es auch als “ADFS” bezeichnet, weil das “Advanced Disc Filing System” quasi die erste Implementierung von Filecore war (damals, Floppy-Zeit, zur Archimedes-Ära 800 KiB auf einer 3,5″-DD-Diskette), bevor es abstrahiert und generalisiert als Basis für Disketten- und Festplattenformate in RISC OS Einzug hielt. Es gab über die Jahre reichlich Varianten, um die diversen Einschränkungen und Limits in den besser nutzbaren Bereich zu schieben – das E-Format ist das Übliche für DD-Disketten (800 KiB) und man findet es heute in den Weiten des Internets als .adf-Disc-Images der klassischen Archimedes-Software. Später kam das F-Format für die HD-Floppies (1600 KiB). Schließlich wurde mit RISC OS 4 das E+/F+-Format eingeführt (“Big Map”), um die lächerlich niedrige Grenze solcher Dinge wie “maximale Anzahl von Einträgen in einem Verzeichnis” auf ein halbwegs erträgliches Niveau zu heben.

Wie auch immer – beim Hantieren mit Emulatoren und natürlich dem MIST(er) hat man häufig mit diesen .adf- (Floppy-Images) und .hdf- (Harddisc-Images) Dateien zu tun. Oftmals will man “nur kurz” einen Blick reinwerfen und dazu nicht gleich den Emulator hochfahren. Zumal die Emulatoren auch nicht alle so richtig nutzerfreundlich sind was das “Mounten” des Images angeht.

Also: ein Tool muss her. Systemunabhängig und natürlich mit anständigem UI. Also Java. Das Problem: Filecore wurde von echten Bitfuchsern entwickelt. Da wimmelt es nur so von Bitleisten, unsigned values mit allem zwischen 8 und 64 bit und sonstigem, was unter Java nicht so richtig “nativ” unterstützt wird. Übrigens gibt es Spezialisten, die es auch noch gut finden, dass Java keine “unsigned types” hat – für mich ist dieser Artikel ein Beispiel dafür, wie eine limitierte Erfahrung auf nur wenige Programmiersprachen den Blick aufs wesentliche vernebeln kann, denn die allermeisten der genannten Probleme sind nur inhärent im Java- und C-Typsystem, aber in vernünftigen Sprachen wie Ada elegant gelöst. Dumm, dass die Java-Erfinder vermutlich einen genauso eingeschränkten Blickwinkel hatten – C, C++, Smalltalk, Ende der Geschichte. Aber ich schweife ab.

Jedenfalls habe ich nach Bibliotheken gesucht, die unter Java die Bitfrickelei und unsigned types im Handling etwas angenehmer machen. Leider bin ich bis auf Lukas Eders jOOU-Bibliothek auf nix gescheites gestoßen. Klar, im Apache-Commons-Universum gibt es ein paar Dinge, in Guava ebenso, und sogar Oracle hat das Licht gesehen und ein paar nützliche Dinge in Java 8 nachgerüstet. Also: selbst ist der Mann. “Not invented here” ist schließlich eine der grundsätzlichen Triebfedern der IT.

Es sei denn, jemand hat einen Hinweis auf eine vernünftige, umfassende Bibliothek um meine Bedürfnisse zu erfüllen. Unter ebenso vernünftiger Open-Source-Lizenz natürlich. UAwg! Nebenbei: die eigentliche Implementierung ist nun nicht das große Problem, das Finden geeigneter Doku und fehlerarme Interpretation derselben nebst Erkennen gewünschter und unerwünschter Abweichungen davon in der Praxis hingegen schon. Hat man das Problem erst mal in einer Sprache geknackt, sollte eine Portierung in andere Sprachen kein großes Problem sein. Es wäre eine interessante Fallstudie, den Ada-Code neben dem Java-Code zu sehen.

Und falls jemand ein anständiges (nicht jedoch komplexes!) Dateisystem kennt mit einer simplen Implementierung in einer freien Lizenz – mail me. Filecore hat einen Nachfolger schon seit etwa 30 Jahren verdient.

Wo sind die guten E-Mail-Clients?

 Software  Kommentare deaktiviert für Wo sind die guten E-Mail-Clients?
Nov 132016
 

Im Moment bin ich auf der Suche nach einem anständigen E-Mail-Client unter Windows. Ich bin mit Thunderbird noch nie warm geworden und halte ihn für überladen, instabil, unintuitiv und unzuverlässig. Outlook 2013 kostet mich gerade den letzten Nerv beim Support eines weitgehend unerfahrenen Computernutzers. Quasi unbedienbar, dazu ein Ressourcenfresser sondergleichen. Wenn man eine Einstellung sucht, vergeht mal gern eine Stunde. Die Suchfunktion kann sich nicht entscheiden, ob sie was findet oder nicht – und diese Entscheidung dauert lang.

Und dann stößt man beim googeln auf Beiträge wie diesen – erster Satz: “Microsofts Outlook gilt als das beste E-Mail-Programm.” Äh – bei wem? Bei denen, die nur Lotus Notes (heißt jetzt IBM Notes, sieht aber kein Stück besser aus) als Alternative kennen? Und dann werden dort doch tatsächlich Windows Live Mail und Windows Mail als Alternative genannt. Und natürlich Thunderbird. Ansonsten: nix. Wenn man schon keinen Bock auf Recherche hat, sollte man sich doch solche Artikel gleich sparen.

Jetzt könnte man sagen – tja, was liest Du auch IT-Artikel in der WELT? Ich Dummerchen. Mal bei den Experten von CHIP stattdessen nachlesen. Großartig, diese Top 5. Wenigstens bei heise Downloads gibt es in der E-Mail-Rubrik ein paar Kandidaten.

Aber was sind denn nun die Alternativen? Pegasus Mail, das ich schon unter Windows 3.11 nicht leiden mochte? Opera Mail? Foxmail? Mailbird? eM Client, der in der freien Variante ganze zwei E-Mail-Accounts verwalten kann? Columba – immerhin in Java programmiert und Open Source, d.h. ich könnte realistischerweise eigene Anpassungen vornehmen – dessen letztes Release aus 2007 stammt? Ich ertappe mich kurz beim Gedanken, mutt oder elm unter Cygwin zu installieren. Wenn schon Retro, dann richtig.

Oder was anderes Radikales – mein aus RISC OS-Zeiten liebgewonnenes Messenger Pro in der Windows-Variante kaufen? Hatte ich schon mal in 2002, als Mark Sawle intellegit gründete und Gemini als Messenger Pro-Portierung auf Windows veröffentlichte. Bin ich unter Windows nie mit warm geworden, warum weiß ich eigentlich nicht. Inzwischen ist R-Comp auch der Vertrieb für die Windows-Version, und damit ist es traditionell fast unmöglich, Näheres über die Software herauszufinden, ohne direkt Kontakt aufzunehmen oder die Software einfach zu kaufen. Einfach kaufen? Tja, die R-Comp-Shopseite ist legendär…man kommt über den “Order now!”-Knopf auf eine selten hässliche Zwischenseite, wo einem erklärt wird, dass man doch besser die !Shop-Applikation verwenden soll. Gilt natürlich nur für RISC OS, und der arme Windows-Nutzer clickt vor lauter Verwirrung auf den “secure ordering site”-Link. Ist man clever genug, findet man hier raus, dass es offenbar eine “basic”-Version und eine “full”-Version gibt. Was mag wohl der Unterschied zwischen beiden sein? Auch konsequent: Preise nur in UKP.

Immerhin: für drei Screenshots und ein paar warme Worte hat es gereicht. Liebe Freunde von der Insel: das wird dieser Software (höchstwahrscheinlich) nicht gerecht. Der arme Mark. Nur wer die Original-Intellegit-Seite kennt, kann das Handbuch studieren oder eine etwas ausführlichere Featurebeschreibung lesen. Man kann auch eine Trial-Version herunterl…nein, man kann nur seine E-Mail-Adresse in ein Formularfeld eingeben und eine Trial-Version anfordern. Die 90er feiern ihr Revival.

Wer den ultimativen E-Mail-Client für Windows kennt, immer her mit den Infos. Am besten per E-Mail.

Beknackte Oberflächen – heute: WinZip

 Software, UI  Kommentare deaktiviert für Beknackte Oberflächen – heute: WinZip
Mrz 202016
 

Nein, es soll nicht darum gehen, dass der einzig wahre Weg, Archive zu behandeln, die Idee des “Image Filing System” unter RISC OS ist, und nach wie vor SparkFS von David Pilling die ultimative Implementierung dieser Idee ist. Warum unter Windows bis heute nichts annähernd vergleichbares existiert, ist eines der großen Mysterien der Weltgeschichte. Naja, dort hält man ja teilweise auch den Explorer noch für eine gute Idee.

Also, was nervt mich heute darüber hinaus an WinZip? Das unglaublich schlechte Fehlerhandling. Ich archiviere ein Verzeichnis mit ein paar tausend Dateien. Am Ende des Vorgangs informiert mich WinZip mit folgender alarmierender Meldung: “Es sind Fehler aufgetreten. Möchten Sie die WinZip-Protokolldatei aufrufen?” Fehler? Natürlich will man wissen, was schiefgegangen ist. Also die Protokolldatei öffnen (keine Ahnung, welcher Schwachspieler hier “aufrufen” übersetzt hat). Aber was bekommt man zu sehen? Nicht etwa eine Liste der aufgetretenen Fehler. Nein, eine Liste aller Vorgänge. Wie das Hinzufügen einer Datei zum Archiv. Und wie findet man jetzt die Fehler? Leider gibt es überhaupt keinen Hinweis, durch welchen Text so ein Fehler benannt werden könnte. Doch es kommt noch besser: oft sind gar keine Fehler im Protokoll zu finden, sondern lediglich Warnungen.

Fassen wir zusammen: Irreführende Fehlermeldung, gut versteckte Informationen – ein würdiger Kandidat für den Preis der “Beknackten Oberfläche”. Ergonomiewertung: 0%.

In meinem Falle ist der Grund für Warnungen übrigens meistens, das Dateien mit Datestamps früher als dem 1.1.1980 (das früheste Datum, das im ZIP-Format darstellbar ist) archiviert werden. Da fragt man sich doch direkt, was sich Phil Katz damals gedacht hat. Leider können wir ihn nicht mehr fragen.

Artikelserie vom MiST-Meister in der c’t

 Hardware, Software  Kommentare deaktiviert für Artikelserie vom MiST-Meister in der c’t
Sep 202015
 

Das MiST-Mastermind Till Harbaum hat in der aktuellen, morgen am Kiosk erscheinenden c’t (Ausgabe 21/2015) den ersten Teil einer bisher auf (mindestens?) drei Teile geplanten Artikelserie publiziert. Darin geht es um die Basics rund um die FPGA-Programmierung, und natürlich dient das MiST-Board als Basis für diese Experimente.

Wer schon immer wissen wollte, wie das mit der “Magic” der MiST-Cores so funktioniert, könnte dümmeres tun, als sich die neueste c’t zu holen. Auch wenn das einzige Ergebnis des ersten Teils ist, die gelbe LED des MiST-Boards blinken zu lassen.

Für den zweiten Teil der Serie ist ein Pong-Klon angekündigt, sprich man erfährt wie die Videoausgabe funktioniert und wie man auf Eingaben des Benutzers reagiert. Im dritten Teil geht es dann ans Eingemachte: eine Z80-Implementierung nebst Speicher und Videocontroller kommen zum Einsatz – als alter Z80-Hase freue ich mich darauf besonders.

Neben der bloßen Verwendung vorgefertigter Cores wird dem MiST-Projekt also eine weitere, interessante Facette hinzugefügt.

Beknackte Oberflächen – heute: Outlook 2010 EMail-Export

 Software, UI  Kommentare deaktiviert für Beknackte Oberflächen – heute: Outlook 2010 EMail-Export
Jul 112015
 

Ich fürchte, die heute begonnene Serie “Beknackte Oberflächen” könnte ein Dauerbrenner werden. Es gibt weniges, was mich so nervt wie beknackte, unintuitive Benutzungsoberflächen. Es nervt deutlich mehr als hässliche, aber wenigstens funktionale Oberflächen.

Microsoft musste ja viel Kritik einstecken für die Einführung des “Ribbon”-Konzepts. Und das völlig zu Recht. Heute noch frage ich mich, was denn der große Vorteil dieses Konzepts sein soll, und warum es nicht wenigstens möglich war, beide Konzepte parallel zu integrieren – denn letztlich wird ja auch jede Ribbon-Aktion entweder direkt ausgeführt (so wie bei der guten alten Toolbar) oder öffnet irgendwann denselben schäbigen Dialog wie früher.

Es geht ja das Gerücht, dass Microsoft Legionen an UI-Experten beschäftigt und ständig Versuchspersonen befragt zur Benutzbarkeit ihrer Oberflächen. Keine Ahnung, wo diese Experten waren, als ein Programmierer die Aufgabe bekam, in Outlook 2010 die Funktionalität “EMail exportieren” einzubauen.

Die Ausgangssituation: ich hatte diverse zu exportierende EMails in einer Folder-Struktur gesammelt und wollte nun diesen Folder exportieren und war schon gespannt, welche Formate mir wohl Outlook anbieten würde – Microsoft ist ja auch bekannt dafür, Industriestandards – wenn sie nicht von Microsoft selbst erfunden wurden – entweder nicht oder unvollständig oder fehlerhaft zu unterstützen.

Es stellte sich aber heraus, dass das Export-Format gar nicht das Problem ist, denn die Frage war zunächst: wie funktioniert der Export denn überhaupt? Intuitiv wäre gewesen, den Export über das Kontextmenü erreichbar zu machen – aber da geht nur, über “Eigenschaften” über den Reiter “AutoArchivierung” zu archivieren – aber ich wollte ja jetzt exportieren und nicht irgendwann archivieren. Vielleicht direktes Drag&Drop des Folders ins Dateisystem? Nein, da empfängt mich das Verbotsschild. Also mal im “Datei”-Ribbon nachgeschaut, ob es da “Export” oder “Speichern” oder sowas gibt. Gibt es nicht. Jetzt war ich doch einigermaßen ratlos und bin die anderen Ribbons durchgegangen. Nix zu sehen. Die Symbolleiste für den Schnellzugriff inspiziert. Geschaut, ob es dort in den “Weiteren Befehlen” vielleicht irgendeine Export-Aktion gibt. Wieder nix.

OK, dann mal in den “Optionen” nachschauen, ob man dort irgendwo was aktivieren kann. Dann die Überraschung: Unter “Erweitert” gibt es tatsächlich einen Bereich “Exportieren” nebst zugehörigem Button. Drückt man diesen, gibt es noch eine Überraschung: ein Dialog öffnet sich, der eine Auswahl von 9 Aktionen anbietet. 9 Export-Aktionen? Nein, natürlich nicht. 7 davon sind Import-Aktionen. Ah ja. Immerhin: die anderen Dinge unter “Optionen -> Erweitert” scheinen wirklich Optionen zu sein und keine gut versteckte Funktionalität. Es ist also noch nicht alles verloren.

XYplorer – ein Dateimanager für Windows

 Software, UI  Kommentare deaktiviert für XYplorer – ein Dateimanager für Windows
Nov 292014
 

Die meiste Zeit benutze ich Rechner, die unter Windows laufen. Momentan Windows 7 in der Mehrzahl der Fälle. Ganz freiwillig ist das nicht. Am liebsten würde ich RISC OS nutzen, aber das hat inzwischen nur noch wenig Software verfügbar, die ich für die tägliche Arbeit brauche – Java, eine IDE, ein Browser, alles Mangelware unter RISC OS. Linux nutze ich nur für Spezialaufgaben (aktuell ps3mediaserver, CVS-Server, git-Server, NFS-Server).

Egal welches Betriebssystem man nutzt – eine zentrale Aufgabe ist immer die Navigation im und die Organisation des Dateisystems. Erstaunlich, dass Windows dort seit Version 3.0 mit ziemlich schlechter Software ausgerüstet ist. Der Dateimanager machte den Anfang, später dann der Explorer. Bis heute nicht gerade die Spitze was Leistungsfähigkeit und Ergonomie angeht. Die Änderungen zwischen XP und 7 sind auch eher Verschlimmbesserungen.

Ich habe diverse “Commander-ähnliche” Dateimanager ausprobiert, vom TotalCommander bis zum muCommander. Ich konnte mich nie daran gewöhnen. Eventuell ist das meiner RISC OS-Vergangenheit geschuldet – den RISC OS-Filer halte ich bis heute für das ergonomischste Werkzeug für Dateisystemoperationen. Der Filer ist von derartig eleganter Schlichtheit, dass man den Erfindern täglich auf Knien huldigen will. Unter Linux gibt es den ROX-Filer, entwickelt von einem ehemaligen RISC OS-Benutzer – trotzdem fühlt er sich nicht wie das Original an. Komisch, soll aber nicht das Thema sein.

Letztlich habe ich unter Windows immer mit dem normalen Explorer gearbeitet, in Ermangelung an (mir bekannten) Alternativen. Die Wende kam heute: ich las mal wieder einen der berühmten “die x wichtigsten Freeware-Tools”-Artikel, diesmal in der Geschmacksrichtung “The Register”. Wie so oft waren die Kommentare interessanter als der Artikel, und einer der Kommentatoren nannte ein Tool namens XYplorer als unverzichtbares Werkzeug. Heruntergeladen, auf die Platte extrahiert (ja, es gibt eine “mobile”-Version, die nicht installiert werden muss), gestartet – und sofort gesehen, dass dieses Tool genau das richtige für mich ist.

Highlight-Features aus meiner Sicht – neben der Basisidee der multiplen Tabs – sind der Mini Tree und die “Mouse Down Blow Up”-Funktion. Das lässt sich mit Worten ganz schwer beschreiben, das muss man selbst ausprobieren, oder hier nachlesen. Auch die Such- und Filterfunktionen sehen sehr vielversprechend aus.

Schwächen? Die Internationalisierung scheint nicht vollständig, die deutschen Texte sind immer mal wieder von englischen Einsprengseln unterbrochen, vor allem in den Menüs.

Also: die kostenlose Version herunterladen und ausgiebig testen. Bin gespannt, wie lange meine Euphorie anhält.