Einleitung

Wer einen MobileMe-Account besitzt oder seine letzten Urlaubsfotos lieber bei Facebook oder Flickr veröffentlichen möchte, der findet in iPhoto entsprechende Funktionen, um Bilder komfortabel hochzuladen. Wer aber Bilder lieber auf seinem eigenen Server hostet, der muss diese zuvor umständlich umkopieren, herunterskalieren und dann noch über einen FTP-Client hochladen. Mit dem Automator kann man sich das Leben etwas einfacher machen. Das Schöne dabei: obwohl der Mac OS X-Finder bis heute nicht auf FTP-Volumes schreiben kann, ist ein Automator-Dienst trotzdem mit Bordmitteln machbar. Wie das geht, möchte ich hier zeigen.

Voraussetzungen

Das Endprodukt, was aus diesem Tutorial hervorgeht, wurde in Automator 2.1 unter Mac OS X 10.6.4 erzeugt. Außerdem liegt Webspace bei einem namhaften Web-Hoster vor und ist über FTP erreichbar. Besondere Automator-Plugins werden nicht verwendet.

Schritte zum Erstellen des Dienstes

Nach dem Start von Automator ist ein neuer Dienst zu erzeugen. Dienste haben die Eigenschaft, sich in das ihnen zugewiesene Programm einzuhängen. Der Dienst ist dann über die Menüleiste erreichbar und fängt sofort an zu arbeiten.

Unser Dienst soll alle in iPhoto markierten Bilder entgegennehmen und in einen temporären Ordner kopieren. Denn: das Original-Material soll natürlich auf keinen Fall angefasst werden.

Nachdem wir einen neuen Dienst begonnen haben, legen wir fest, in welche Anwendung sich dieser einzuklinken hat. Wir möchten, dass der Dienst in iPhoto verfügbar ist. Daher nehmen wir folgende Einstellung vor:



Der Dienst soll einen temporären Ordner auf dem Schreibtisch anlegen. Dies ist durch eine einfache Aktion zu machen:



Anschließend möchten wir die in iPhoto markierten Bilder ermitteln. Dafür müssen diese mittels der folgenden Aktion abgefragt werden:



Als Ergebnis erhalten wir die Bilder, die wir in iPhoto markiert haben. Bilder sind letztlich nichts anderes als "Finder-Objekte", also Dateien. Diese Dateien sollen jetzt in den zuvor angelegten temp-Ordner kopiert werden, was sich mit folgender Aktion bewerkstelligen lässt:



Bei der Auswahl des Ordners gibt es einen kleinen Fallstrick: da das Feld keine freien Texteingaben für Ordner zulässt, muss der Ordner erst im Auswahlfenster angelegt werden. Man klickt also in der Combobox "Nach:" auf "Andere..." legt einen "temp"-Ordner auf dem Schreibtisch an und wählt diesen anschließend aus. Sobald die Combobox dann mit dem "temp"-Ordner beschriftet ist, können wir ihn wieder vom Schreibtisch löschen.

Nachdem die Kopieren-Aktion ausgeführt wurde, erhalten wir als Ergebnis die kopierten Dateien. Mit diesen Kopien können wir nun machen, was wir wollen. In unserem Beispiel möchten wir die Bildgröße ein wenig verkleinern, da das Bereitstellen von Bildern auf Web-Seiten in voller Größe zu enorm langen Ladezeiten führen kann. Wir verwenden also die Aktion "Bilder skalieren":



Hier kann entweder ein Prozentwert oder die Pixelgröße eingestellt werden. Je nachdem, ob das Bild ein hoch- oder querformatiges Bild ist, wird entweder die Höhe oder die Breite automatisch auf den hier eingestellten Wert skaliert.

Jetzt liegen die Bilder in der gewünschten Größe vor und können hochgeladen werden. Wenn der Mac OS X-Finder beschreibbare FTP-Volumes unterstützen würde, hätten wir es einfach. Da das aber nicht funktioniert, nehmen wir einen kleinen Umweg über ein Shell-Script. Wir führen ein Shell-Script aus, welches die eben erzeugten Bilder automatisch hochlädt.

Damit das klappt, muss zuvor eine Textdatei erstellt werden, welche die Befehle für die ftp-Kommandozeile beinhaltet. Diese Textdatei wird durch die folgenden Aktionen erstellt:



Das Basisverzeichnis ist bei Shell-Scripts aus Automator heraus immer das aktuelle User-Verzeichnis. Mittels lcd wird also zunächst das temp-Verzeichnis festgelegt, in dem sich die Bilder befinden.
Das anschließende "prompt" schaltet die Abfragen aus, die wir beim nächsten Befehl "mput" sonst erhalten würden.
mput ermöglicht das Hochladen mehrerer Dateien gleichzeitig. Achtung, hier ist zu beachten, dass bei der Dateiendung Groß-/Kleinschreibung unterschieden wird! "*.jpg" ist also nicht gleich "*.JPG". Meistens sind Bilder in iPhoto - gerade wenn sie von einer Digitalkamera kommen - aber mit Dateiendung in Großschrift versehen.

Nun haben wir den Text für die ftp-Kommandos, die Datei muss aber noch geschrieben werden. Dies erledigt schließlich die folgende Aktion:



Ins temp-Verzeichnis wird nun eine Textdatei namens ftp.input geschrieben. Diese kann nun, zusammen mit folgender Aktion verwendet werden:



"Benutzername", "Passwort" und "www.meineadresse.de" sind natürlich durch die eigenen Angaben zu ersetzen. Ebenso ist das Unterverzeichnis "test/" an die eigenen Bedürfnisse anzupassen. Wichtig ist jedoch, dass hinter dem Verzeichnis immer ein abschließendes Slash (/) folgt, sonst erkennt ftp die Angabe nicht als Verzeichnis.

Dieser Befehl verbindet sich sofort mit einem ftp-Server und führt anschließend die in der ftp.input-Datei enthaltenen Befehle aus. Dadurch, dass "quit" als letztes in der Datei steht, trennt sich das Script wieder sauber vom Server.

Jetzt wäre eigentlich alles in Ordnung, wir wollen aber noch eben unseren Müll beseitigen - nämlich unseren temp-Ordner. Wir fragen ihn also mit der folgenden Aktion nochmal explizit ab:



...und schmeißen ihn daraufhin bedenkenlos weg:



Und schon ist unser Dienst fertig und bereit zum Ausprobieren.

Zunächst speichern wir ihn mittels Menü "Ablage" > "Sichern".



Jetzt können wir iPhoto starten. Wir wählen ein beliebiges Album, markieren ein paar Bilder und schauen dann mal ins Menü "iPhoto" > "Dienste". Wir finden daraufhin folgenden Eintrag:



Ein Klick und wenige Sekunden (oder Minuten, je nach Umfang) später sind die Bilder hochgeladen. Bei diesen Diensten ist es wichtig, dass man abwartet, bis das Zahnrädchen oben rechts in der Menüleiste verschwindet. Während dieses sich dort dreht, läuft der Dienst.

Ausblick

Dieses Tutorial ist nur die Spitze des Eisbergs und soll zeigen, wie man mit einfachen Mitteln künftig Routineaufgaben schneller und bequemer ausführen kann und dabei auch die Schwächen des Finders sinnvoll umschifft. Natürlich lässt sich so ein Dienst universell einsetzen. Man kann alles mögliche damit hochladen, man kann auch das Zielverzeichnis des Servers abfragen lassen, man kann die Dateiendungen zuvor einheitlich umbenennen etc. Wer ein wenig damit spielt und so etwas ggf. für eigene Zwecke einsetzen kann, wird sicher noch die eine oder andere Idee haben. (Schlicki2808)

Vorwort

Man kann über Microsoft sagen, was man will, aber eines muss ich ihnen schon lassen: mit Produkten wie SQL-Server, Visual Studio und .NET ist ihnen ein großer Wurf gelungen, mit denen im Bereich der Softwareentwicklung sinnvolle Standards in Bezug auf objektorientiertes Programmieren gesetzt wurden. Eine Trennung zwischen Benutzeroberfläche und Programmlogik war mit den Win32-IDEs (z.B. Visual Basic 6) zwar möglich, aber verhältnismäßig kryptisch und recht umständlich gelöst. In .NET wird man fast schon gezwungen, sich einen sauberen Programmierstil anzueignen. Nun gibt es endlich für die unterschiedlichsten Projekttypen einheitliche Vorgehensweisen. Der kleine Haken dabei ist jedoch, dass das .NET-Framework ausschließlich auf Windows-Plattformen betrieben wird, trotz der gelobten Plattformunabhängigkeit seitens Microsoft.
Wie gut, dass es Entwickler gibt, die sich diesen Umstand zu Herzen genommen und das mono-Projekt ins Leben gerufen haben. mono ist ein Nachbau des .NET-Frameworks und läuft neben Windows auch auf Linux und Mac OS X. Ich wollte wissen, wie gut das funktioniert, ob man wirklich, wie es versprochen wird, seine Visual Studio-Anwendungen ohne Abstriche auf Mac portieren kann und was es zu beachten gibt.

Umgebung

In meinem Fall betreibe ich mono unter Mac OS X 10.6.4. Das .NET-Projekt wurde in Visual Studio 2005 geschrieben. Dabei handelt es sich um eine einfache Windows Forms-Anwendung, die ein SQL-Frontend für Microsoft SQL Server darstellt, sprich: man gibt eine SQL-Abfrage ein und bekommt das Ergebnis in einem DataGrid angezeigt. Soweit nichts Spektakuläres.

Vorbereitung

Zunächst einmal wird das mono-Framework benötigt. Dieses kann man sich frei unter herunterladen. Das mono-Framework ist übrigens OpenSources, weswegen Interessierte auch gleich die Quelltexte laden können.
Gut, die Installation des Frameworks ist dank eines automatischen Installers keine Raketentechnik und geht in der Regel problemlos vonstatten. Was wir nun aber noch benötigen, ist eine Entwicklungsumgebung. Das Pendant zu Visual Studio nennt sich MonoDevelop und ist, je nach Plattform, in einem unterschiedlichen Entwicklungsstadium. Die Mac OS X-Version hat beispielsweise keinen GUI Designer, da Drap & Drop noch nicht implementiert werden konnte. So bleibt nur das Codieren der Positionen, das Pixelzählen und immer wieder Ausprobieren. MonoDevelop ist unter der oben genannten Seite verfügbar. Auch hier ist die Installation einfach und nach wenigen Sekunden hat man ein Disk Image, wo man nur das MonoDevelop-Icon in die Programme ziehen muss.

Start

Nach dem Start von MonoDevelop erhält man eine Startseite, die stark an Visual Studio erinnert. Hier werden die zuletzt benutzten Projekte sowie Neuigkeiten und Links zu verwandten Seiten angezeigt.


MonoDevelop Startseite

Die MonoDevelop-Oberfläche ist alles andere als nativ. Sie verhält sich nicht mac-like und sieht auch nicht so aus.
In MonoDevelop wird nach Projekten und Projektmappen gegliedert, was es für Ein- und Umsteiger leichter macht, seine Projekte wiederzufinden. Ich lade also mein SQLer-Projekt (sln-Datei, bekannt aus Visual Studio) in die IDE. Alle bekannten Dateitypen werden in der nicht-nativen Auswahlbox aufgeführt.
Nach dem Öffnen der Projektmappe befindet man sich im SourceCode. Wie schon anfangs erwähnt, findet man keinen GUI Designer, mit dem man die Oberfläche bearbeiten könnte. Stattdessen ist der Zugriff auf die Designer-Datei möglich, die immer neben einer normalen vb-Datei existiert und die Generierung sämtlicher Steuerelemente beinhaltet.
Bevor wir das Projekt ausführen können, müssen wir die .NET-Verweise für das Projekt definieren. Diese Möglichkeit finden wir unter "Projekt" und "Verweise bearbeiten…". Hier wählen wir dann die nachfolgend ersichtlichen Verweise:


mono bringt das .NET-Framework gleich mit.

Standardmäßig arbeitet mono mit den gtk-Verweisen, eigene Klassenbibliotheken für die Steuerung von Fenstern, Steuerelementen, Datenbankoperationen und einiges mehr. Da wir es hier mit einer waschechten Windows-Forms-Anwendung zu tun haben und unter denselben Rahmenbedingungen arbeiten möchten, verwenden wir hier knallhart die normalen Microsoft .NET-Bibliotheken. Mit diesen vorbereitenden Maßnahmen können wir das Projekt nun einmal kompilieren und ausführen.

Erste Schritte mit dem Projekt

Nach der Kompilierung stellen wir erstaunt fest, dass das Programm tatsächlich startet und nichts - außer der Titelleiste - darauf hindeutet, dass es sich hier um ein Programm handelt, was auf dem Mac läuft. Dadurch, dass sämtliche Steuerelemente direkt aus der Windows.Forms kommen, werden sie natürlich auch genauso dargestellt und nicht plattformspezifisch gerendert. Nach ein wenig Herumprobieren und Klicken fallen jedoch schon die ersten Macken auf. So ist der Bildschirmaufbau zäh, langsam, mitunter fehlerhaft und oft führen Aktionen jeglicher Art zum Crash des gesamten Programms - ohne, dass ich dabei selbst Mist gebaut hätte.


Ein Windows-Fenster unter Mac OS X. Die Umlaute stehen zwar richtig im Quelltext, werden aber in der kompilierten Anwendung nicht dargestellt.


Eine Windows-MessageBox unter Mac OS X! Die Fenstericons werden scheinbar nicht ausgewertet, denn egal, ob man vbInformationen, vbQuestion oder vbExclamation benutzt - es erscheint immer das Lämpchen.


Während der Ausführung sammeln sich in der Debug-Ausgabe Fehlermeldungen. Schlagwörter wie "DeviceSynchronize" lassen darauf schließen, dass das Framework oft nicht in der erforderlichen Geschwindigkeit hinterherkommt und sich Threads gegenseitig überholen.


So kann es aussehen, wenn man mehrmals hintereinander das gleiche Fenster öffnet.

Soviel zum Thema Windows.Forms. Wenden wir uns mal von der Oberfläche ab und schauen wir uns die Anwendungslogik an. Hier gehts um Klassen, Schleifen, Konstruktoren uvm. In Klassen werden üblicherweise Properties (Eigenschaften) benutzt, um Werte, die von außen nicht greifbar sein sollen (= private), kontrolliert zurückzugeben und/oder auch zu setzen. Properties sind handlich und können, im Gegensatz zu Funktionen, beide Aufgaben gleichzeitig erfüllen. Natürlich soll erwähnt werden, dass Funktionen für größere Taten bestimmt sind Visual Studio ist in dieser Hinsicht recht flexibel. Properties können, müssen aber keinen definierten Datentyp zurückgeben. Sie können sowohl nur-lesend als auch lesend/schreibend ausgeführt werden. Die folgende Property gibt keinen definierten Datentypen zurück und wird daher als "Object" angenommen - eigentlich:



mono sieht das aber ganz anders - naja fast. Das, was eigentlich eine Warnung sein sollte, ist hier noch ein Fehler:



ReadOnly-Properties werden hingegen gar nicht unterstützt … zumindest nicht "abgefangen":


Resultat:



Das disqualifiziert mono leider im jetzigen Stadium noch für eigene, wiederverwendbare Klassen(bibliotheken) (zumindest komplexere). Hier müsste man dann wieder auf Funktionen ausweichen, die zwar letztlich dasselbe tun, für unseren Zweck aber lediglich eine Vermeidungsstrategie darstellen. Übrigens: der Fehler VBNC99999 signalisiert, dass der Compiler gegen die Wand gefahren ist. Auch wenn der Eindruck entsteht, man habe versehentlich ein Objekt nicht erzeugt, so liegt der Fehler keineswegs im Quelltext - in Visual Studio ist der Quelltext problemlos ausführbar.

Wie geht es weiter?

Mein kleiner Versuch hat gezeigt, dass mono noch in den Kinderschuhen steckt und für das produktive Arbeiten nicht geeignet ist. Nein, man kann definitiv nicht alle Projekte anstandslos in mono ausführen. mono zeigt aber schon sehr gute Ansätze, was das plattformübergreifende Entwickeln anbelangt. Sicher bedarf mono noch viel Entwicklungsarbeit und Fehlerbehebung, es zeigt aber, dass sich einige Menschen Gedanken gemacht haben, wie man das Potential von .NET auf andere Plattformen bringen kann. (Schlicki2808)