| Scalos Filetypes Plugin |

Scalos Filetypes Plugin - Erkennung auf Doppelklick

Am Amiga gibt es mit Scalos ein neues Gefühl des Arbeitens. Die von den NewIcons und DOpus gewohnte Filetype-Erkennung ist auch hier implementiert. Doch leider ist das entsprechende guide-File nicht gerade anleitend. Es hinterläßt doch eine ziemliche Leere.

Um den Mechanismus des automatischen Erkennens des File-Typs zu implementieren, braucht es das filetypes.lha-Archiv aus der Download-Sektion der Scalos-Site.

Das filetypes.plugin, das nötig ist, damit die Erkennung auch wirksam wird, gehört nach Plugins/OOP im Scalos-Verzeichnis, und die entsprechenden Preferences für Scalos legt man wohl sinnvollerweise im Sys:Prefs ab, dort gehört dann auch das FileTypesPrefs hin, das im filetypes.lha-Archiv enthalten ist. Ein entsprechendes Icon muß man sich aber noch basteln. Das ganze Paket ist in einem Beta-Stadium, nichtsdestotrotz verdingt es sich hier schon seit Längerem, ohne Probleme zu machen.

Es wäre nun einfach, zu erwarten, bei einem Doppelklick auf ein Icon tut sich was. Nun, es tut sich schon was, solange man ein echtes Icon vor sich hat und nicht ein DefaultIcon. Die FileType-Erkennung macht ja auch nur dann Sinn, wenn ein File kein Icon dabei hat und eines per default ausgewählt werden soll. Abhängig vom Typ sollte es ausfallen und dementsprechend das DefaultTool im Icon gesetzt werden. Genau dieses macht dieses Plugin.

Extensions sind nicht alles

Eine Möglichkeit, den Typ eines Files zu erkennen, liegt darin, einfach die Extension nach dem Punkt im Filenamen auszuwerten und daraus die benötigten Informationen abzuleiten. Daß dies in einem System, das glücklicherweise ohne die Notwendigkeit nach Extensions auskommt, nicht sinnvoll ist, sollte auf der Hand liegen.

Natürlich kann man auch hier die Erkennung so konfigurieren, daß nach Extensions ausgewählt wird, aber dieses Plugin ist viel fähiger: es scannt nach eingegebenen Kriterien die Files durch, sieht daran, welchen Typ das File hat und wählt dementsprechend das zugehörige DefaultIcon aus ENV:Sys aus. In den ToolTypes dieses Icons steht dann, welches DefaultTool ausgeführt werden soll und welche Optionen dabei zur Anwendung kommen.

Was nemma' denn nun?

Um sich nicht alle DefaultIcons und dazugehörige Parameter selber machen zu müssen, wird in der Anleitung darauf hingewiesen, daß ein DefIcons-Brainfile aus der NewIcon-Distribution eingebunden werden kann. Dieses hat dann auch die grundlegende Funktionalität, um die wichtigsten Typen der Files zu unterscheiden.

Dieses Importieren ist leicht geschehen und damit sieht das Prefs-Program für das Scalos-FileTypes-Plugin schon ordentlich gefüllt aus:

Echte LhA-Erkennung in den Preferences

Hier ist wohl auch schon die wichtigste Anwendung der Dateitypenerkennung neben dem stupiden Betrachten irgendwelcher obszönen Bilderl per Doppelklick, weil nur mehr eine Hand frei ist. Ein LhA-Archiv gilt es aufzulisten, zu testen oder zu entpacken.

In den Preferences nun gibt es auf der linken Seite verschiedene Ebenen, in die die Typen eingeteilt werden. Als oberste Hierarchie: es ist ein File. Ein Project ist der Standardfall für Files ohne Icon. Und schließlich als dritte Haupthierarchie ist die Unterscheidung, ob das File ASCII-Texte enthält (darunter fallen eben alle Text-Dateien, HTML-Code, C-Sourcen, etc.) oder vielleicht irgendwelche nicht entzifferbare Sachen (wie Bilder, Archive, Fonts, Keyfiles, etc.). Jedem dieser Typen ist ein DefaultIcon zugeordnet, wie im unteren Teil zu sehen.

Um durch diese Hierarchie zu einem File zu finden, sind jedem Typ verschiedene Auswahlkriterien zugerodnet. Diese sind rechts in der Tabelle angegeben und hier wird auch die Mächtigkeit dieser Erkennung ersichtlich. Nicht nur, daß nach einzelnen Attributen ausgewählt werden kann, es ist auch eine logische Verknüpfung (ODER und UND) mehrerer Kriterien möglich.

Die Möglichkeiten, die sich da stellen:

Match - an welcher Stelle im File tritt welche Bytekombination auf?

Search - irgendwo im File steht doch wohl ein bestimmter String?

FileSize - die Größe kann auch ausschlaggebend sein, größer, kleiner, gleich, etc.

FileName - die gewohnten Pattern können hier zur Extension-Erkennung mißbraucht werden.

Protection - die ProtectionBits der AmigaFiles als Einschränkungsmöglichkeit

FileType - File, Verzeichnis, Link oder Partiotion?

Misc - und noch ein wenig mehr...

OR - logische Verknüpfung

Es können auch mehrere Kriterien pro DefaultIcon eingegeben werden, die sind dann UND-verknüpft, setzt man ein ODER zwischen die Zeilen, müssen nicht mehr alle Kriterien erfüllt werden.

Um nun zu unserer LhA-Erkennung zu kommen, ist die Erkennung durch die Hierarchie nötig. Das Archiv ist ein File, also gehört zur Hierarchie namens FILE das Kriterium FILETYPE/FILE. Die nächste Stufe ist das Project. Ist es, also Misc/TRUE auf der rechten Seite. Und wieder eine Hierarchie weiter kommen wir zu den Archiven. Diese haben nun in der Konfiguration, wie das importierte BrainFile aus den NewIcons-Archiven sich gibt, kein Kriterium. Vielmehr aber die untergeordneten Icons, wie lharc. Ein LhA-File zeichnet sich dadurch aus, daß ab Position 2 im File die Zeichenkette "-lh" steht. Danach kommt eine Ziffer, die die Stärke des Packalgorithmus angibt und wieder ein Minuszeichen. Dieses steht dan an sechster Stelle. Daraus ergibt sich dann die entsprechende Mischung aus Kriterien, die zur erfolgreichen Erkennung nötig sind: MATCH/2 -lh und MATCH/6 -. Damit schon weiß Scalos, daß es mit einem LhA-File zu tun hat.

In dieser Unterhierarchie sind auch noch andere Archive zu finde, wie lzx, arj oder zip. Sollte keines davon zutreffen, wird eben das DefaultIcon zu archive angezeigt.

Ein anderes schönes Beispiel für Hierarchien sind die IFF-Files: Es gibt die IFF-Hierarchie, die sich dadurh kennzeichnet, daß die ersten vier Buchstaben "FORM" lauten und das sechzehnte Byte ein Nullbyte ist. Dementsprechend die Kriterien: MATCH/0 FORM und MATCH/ 10 \0. 16 in hexadezimal ist 10 und "\0" ist die Angabe des Bytes in ASCII-Ziffern, eben ein Nullbyte.

Alle Einträge, die unter dieser Hierarchie gemacht werden, haben nun schon mal die Voraussetzung, daß die File alle IFF-Files darstellen. Die Frage ist nur noch, welche. Das steht dann in den Unterhierarchien, wie z.B. für ILBM: MATCH/8 ILBM, oder für 8SVX-Files: MATCH/8 8SVX. Das NewIcons-Brainfile ist zwar relativ vollständig, aber irgendwie ziemlich unaufgeräumt.

Die Einschränkung der Auswahl kann auch negiert werden, daß das entsprechende File nur dann in diese Hierarchie paßt, wenn dieses eine Kriterium nicht zutrifft, weiters ist eine Unterscheidung der Groß- und Kleinschreibung möglich.

In Zeiten von GhostScript sind auch PDF-Dateien für den Amiga kein Hindernis mehr. Sie können ebenso leicht erkannt werden: MATCH/0 %PDF.

Leider hat das Prefs-Programm noch ein paar Bugs; so schließt es sich bei Klick auf Save oder das CloseGadget nicht, sondern erst durch einen beherzten Klick aufs Cancel-Gadget. Die Einstellungen bleiben aber dennoch erhalten, wenn zuvor abgespeichert wurde.

Und was stellen wir nun damit an?

Ist unter Scalos nun die NewIcons.library am Werken, so wird nach einem schönen Reset, der allerdings ärgerlicherweise auch nötig ist, wenn man in den FileTypePrefs was ändert, der Aufbau der icons in einem Fenster etwas verzögert, da sich der gute, brave Amiga erst durch die Kriterien suchen darf und dann erst entscheiden kann, welches Icon er nun für die Files darstellt.

Normalerweise kann man jedem File ein DefaultTool zuweisen, wenn es ein Icon hat. Hier geht es aber um die Files, die kein Icon ihr eigen nennen und deshalb DefaultIcons verpasst bekommen. Von diesen gibt es aber für jeden Typ nur eines (eben in ENV:Sys) und deshalb ist auch für jedes File des gleichen Typs dann das Icon mit allen Tooltypes das Gleiche.

Für diverse Bilder zum Beispiel wird man als DefaultTool wohl ein Anzeigeprogramm einstellen, für verschiedene Archiver, die oft nur als CLI-Pgramm existieren, tut man sich da aber schwer.

Im FileTypes-Archiv gibt es dafür ein schönes Zusatztool namens DoCommand, daß schleunigst ins Tools-Verzeichnis von Scalos gehört. Denn dieses kleine Tool macht dann die Feinheiten aus.

Aus den ToolTypes des DefaultIcons heraus gestartet, erlaubt es die interaktive Beeinflussung und Ausführung von anderen Tools, die wiederum so ihre Sachen mit dem ursprünglichen File anstellen können.

Hier ist es dann möglich, bei einem LhA-File nachzufragen, ob der Benutzer es anschauen, testen oder entpacken möchte. Bei einem Postscript- oder PDF-File könnte die Auswahl zum Beispiel sein, ob es am Monitor betrachtet werden will oder der Drucker ausspucken soll.

DoCommand in Anwendung

Das DefaultTool ist natürlich Scalos:Tools/DoCommand und in die ToolTypes schriebt man hinein, was das Tool mit dem File machen soll. hier gibt es im entsprechenden Requester dann eben vier Buttons mit "Extract", "List", "Test" und das obligatorische "Cancel" für die Verlegenheitsklickerei.

Die Auswahlmöglichkeiten im Detail

Die einzelnen Befehle sind in der Dokumentation zum FileTypes-Archiv sogar erklärt. ASKCOM legt fest, wieviele Gadgets im Requester auftauchen sollen und wie sie beschriftet sind. Dabei gibt es keine Mengenbeschränkung. Mit COMMAND legt man den Befehl zum ersten Gadget fest. Innerhalb des Argumentes zu diesem Tooltype können bestimmte Sondersequenzen verwendet werden, die bewirken, daß an deren Stelle der Filename (%f), das Ergenis eines Auswahlrequester nach einem Verzeichnis (%pd) oder einem File (%pf) und anderes eingesetzt wird. Damit läßt sich im Beispiel des LhA schön das Zielverzeichnis des Entpackvorganges angeben. FILE bedeutet das Gleiche, wie es das auch in anderen ToolTypes tut, es legt die Art der Ausgabe fest.

Für die weiteren Auswahlmöglichkeiten braucht man nur diese beiden ToolTypes entsprechend wiederholt und angepaßt angeben. Zu beachten ist dabei, daß die ToolTypes für das erste Kommando ohne Ziffer am Ende zu sein haben. Alle weiteren werden einfach durchnumeriert.

Was einzig stört an dem Ganzen ist, daß ein Ghostscript, aus den ToolTypes von DoCommand heraus gestartet, gandenlos semmelt. Denn mit 4kB Stack ist er nunmal nicht zufrieden. Es waere nun ein einfaches, in den ToolTypes im entsprechenden Gadget die Größe des Stacks hinaufzusetzen. Scalos aber verhindert das effizient, denn in dem Plugin, das für die Anzeige der iconinformation zuständig ist, kann kein Wert für einen Stack eingestellt werden. Schlecht.

Eine Möglichkeit besteht darin, mit der Original-Workbench zu booten, und in diesem DefaultIcon den Wert für den Stack hinaufzusetzen. Doch leider hilft das auch nicht, denn das ausführende Programm, in diesem Fall der Ghostscript, bekommt trotzdem nur 4kB an Stack zugewiesen und semmelt weiter. Hier also gehört noch einiges "optimiert".

Ansonsten aber ist diese FileTypen-Erkennung eine feine Sache und läßt sich hervorragend im täglichen Gebrauch einsetzen, wenn sie denn einmal konfiguriert ist.

Oliver Gerler

Scalos - Die Homepage der Programmierer

Filetypes Voreinstellungen (GIF; 21K)

Tooltypes Fenster (GIF; 24K)

Requester nach Doppelklick (GIF; 1K)