Die Wackeligkeit des Facebook-Clients für Android fiel mir erstmalig auf, als ich versuchte, selbigen auf meinen Kindle Fire zu verpflanzen. So schrieb ich am 14.12. noch:

Die Facebook-App läuft aufgrund der fehlenden Profil-Unterstützung nicht [...].

Dies ist, wie ich heute weiß, Unfug. Aber der Reihe nach: Bislang hatte ich unter Android entweder über Seesmic oder Tweetdeck notdürftig an Facebook teilgenommen. Aber jüngst hatte ich auf dem in Ehre ergrauten Nexus One einmal wieder dem aktuellen Facebook-Client eine Chance geben wollen. Und siehe da: Ein Fingertipp auf “Status” – und peng! “Schließen erzwingen” (bzw. fürs SEO: “Force close”). So kannte ich das von meinem “vermeintlich inkompatiblen” Kindle Fire.

Nun aber mal ganz ruhig mit den jungen Pferden: Wenn selbst das erste Google-Referenzhandy nicht in der Lage ist, ordnungsgemäß ein Facebook-Statusupdate einzustellen – was läuft hier eigentlich schief?

Des Rätsels Lösung ergab sich durch erbittertes Nachgooglen auf http://androidforums.com. Der User cheezeboy erklärt plausibel und vollkommen korrekt, was unerwarteterweise das Problem ist:

problem occurs if you are using more than one custom list in the privacy settings, specially for the default posting permissions.

Auf deutsch: Wer eben nicht einfach an “Freunde” postet, sondern wer wie ich eine feingranulare Gruppenzuordnung pflegt, und wer per Default ein vergleichbares Szenario wie ich fährt:

Also jeder, der mehr als eine Gruppe unter “Sichtbar machen für” / “Bestimmte Personen oder Listen” einträgt – für den stürzt der aktuelle Facebook-Client für Android v1.8.4 bei Berührung des “Status”-Buttons mit “Schließen erzwingen” bzw. “Force Close” ab.

… Es gibt meines Wissens derzeit nur zwei Wege, um dies zu umgehen:

• Man verwende, sofern man Backups aufbewahrt hat, einen uralten Facebook-Client. Der alte v1.6.4 läuft etwa auf allen meinen Gerätschaften ohne Abstürze, aber natürlich auch mit deutlich verringertem Funktionsumfang.
• Alternativ kann man von “Benutzerdefiniert” / “Bestimmte Personen oder Listen” einfach auf “Freunde” umstellen. Dann läuft der Client, durchaus auch auf dem Kindle Fire – aber alle Statusupdates sind für alle lesbar.

Share

Der hoch geschätzte und jederzeit gern gelesene Kollege Gerrit van Aaken proklamiert in seinem jüngsten Blogbeitrag auf praegnanz.de, wie schlecht es ab sofort um Webdesign bzw. um bestehende Webseiten bestellt ist. In kurz:

• Eingebettete Fotos – so lala, die könnten natürlich schöner aussehen. Am besten zwei Varianten für Low- bzw. Standard-PPI sowie High-PPI vorhalten und je nach Bedarf via CSS Media Queries zur Schau stellen.
• Grafische oder typografische Bitmap-Inhalte, z.B. Diagramme oder als Grafik hinterlegter Text (etwa Überschriften) – sehen zum Rauslaufen gruselig aus, also unbedingt Webfonts nehmen, alternativ alles unbedingt noch mal in High-PPI generieren und bei Bedarf präsentieren.
• Browsergerenderter Text – naja, OK, schon irgendwie hoch aufgelöst, aber typografisch gesehen suboptimal, weil Arial nun mal für Low-PPI optimiert ist, in High-PPI scheiße aussieht – und überhaupt, jetzt könnten wir doch eigentlich endlich mal was mit Serifen nehmen …

Ehrlich – ich kann das alles echt sehr gut nachvollziehen, und ich habe mit exakt diesen Argumenten auch gestern der wehrlosen Ehefrau das ansonsten friedliche Abendessen verquasselt. Aber nachdem ich nun eine Nacht (schlecht) darüber geschlafen habe, geht es mir schon viel besser. Ich sage: Bitte das Jammern einstellen und erst mal den Ball flach halten.

Es gibt meines Wissens derzeit genau vier Geräte, die ein Retina-Display mit doppelt hoher PPI-Dichte an den Massenmarkt tragen: Das iPhone 4, der iPod touch (4. Generation), das iPhone 4S und nun das iPad 3 – allesamt von Apple. Wie Gerrit korrekt bemerkt: Beim iPhone / iPod touch ist o.a. Problematik weniger relevant, weil man eh permanent scrollt. Das Retina-Display dient dabei eher dazu, schon in der stark verkleinerten Ansicht einen besseren Überblick zu bekommen, wohin sich das Zoomen lohnt.

In der Folge des iPhone 4  hat meines Wissens noch kein anderer Mobiltelefonhersteller ein Retina-Display verbaut. Und auch im Vorfeld des iPad-Relaunchs wurde lange Zeit gemutmaßt, dass ein Retina-Display mit 10 Zoll Bildschirmdiagonale viel zu teuer sei, um es zu einem tolerablen Preis zu verbauen. Machen wir uns nichts vor: Apple kann hier seine Markt-Vorherrschaft ausspielen, um den Herstellern andere Konditionen abzuverlangen. Aber: Ich sehe diesseits des Horizonts noch keinen anderen Hersteller, der ein 10″-Tablet mit High-PPI zu einem bezahlbaren Preis produzieren könnte.

Wie sieht es aber im Notebook- oder gar Desktop-Markt aus? Sicher ähnlich. Wenn es jemand schafft, dann sicher wiederum Apple mit seinen 11 Zoll “kleinen” MacBook Airs – basierend auf der Theorie, dass Mac OS X 10.7 oder 10.8 High-PPI fähig ist (man sah schon derartige Screenshots) – Tim Cook sprach ja auch davon, dass wir für 2012 noch einiges zu erwarten haben. Aber wäre ein Retina-Display für größere Macs mit 13, 15, 17, 21 oder gar 27 Zoll Bildschirmdiagonale bezahlbar? Man darf das vorerst bezweifeln. Und: Ich kann mir erst recht im Windows-Lager momentan kein Feld-Wald-Wiesen-TFT mit 24 oder 27 Zoll mit High-PPI ie. “QuadHD”-Auflösung vorstellen. Zur Erinnerung: Wenn anschließend nicht mehr 1920×1080, sondern 3840×2160 Pixel gefüllt werden wollen, schreit dies nach enorm dicken Grafikkarten und Monitorkabeln.

Man verzeihe mir: Ich sehe High-PPI mittelfristig höchstens im “kleinformatigen”, aber immer noch hochpreisigen Profisegment, während der Massenmarkt noch meilenweit davon entfernt ist.

Auch wenn Tablets tendenziell zunehmen, und wenn in vielen Bereichen “Tablet” mit “iPad” gleichgesetzt wird, so steht auf den Schreibtischen in den Büros und auch in den Wohnhäusern tendenziell eher ein Desktop- oder eventuell Laptop-Computer. Was ich damit sagen will: Das Gros der Endanwender dürfte auf absehbare Zeit noch ohne High-PPI auskommen müssen.

Ergo: Die Schwächen von Standard-PPI-Webseiten auf High-PPI-Displays sind durchaus real, aber bezogen auf den Massenmarkt momentan noch vernachlässigbar. Es mag für Webseiten mit hohem bzw. hochqualitativem Bildgehalt sinnvoll sein, auf High-PPI einzugehen und entsprechenden Aufwand zu betreiben – ob man hier allerdings schon von bildschirmoptimierten auf offsetoptimierte Schriften wechseln sollte, wage ich vorerst stark zu bezweifeln.

Bestehende Webseiten abzustrafen, weil sie auf iPhone 4(S) und iPad 3 suboptimal aussehen, halte ich für deutlich übertrieben. Natürlich ist die Darstellung nicht bestmöglich, aber sicher nicht dermaßen scharöcklich, dass man sich angewidert abwenden möchte.

Denn: Unzweifelhaft sind die 1024×768 des iPad 1 und 2 für ein 10 Zoll-Display heutzutage eher gering. Aber: Sich auf dem 10 Zoll-Display des iPad 3 mit deutlich höherer Auflösung als Full-HD (mit dem man bekanntlich anderenorts Großbildschirme mit 50 Zoll und mehr beschickt) über nicht ganz optimales Grafikrendering zu beschweren, ist in meinen Augen nun wirklich Jammern auf hohem Niveau.

Share

Catan-Kindle - Screenshot

Endlich ist “unser” Spiel “Die Siedler von Catan” für den Kindle portiert worden. Das sieht ein bisschen rudimentär aus – aber es funktioniert überraschend gut. – Siehe Screenshot.

Allein: Wie bekommt man dieses (oder ein anderes Spiel) auf seinen Kindle, wenn man nicht in den USA lebt? Denn der Artikel-Link auf www.amazon.com verheißt nichts Gutes: Man bekommt noch nicht einmal gesagt, dass das Spiel US$ 4.99 kosten soll, geschweige denn ist das Spiel außerhalb der USA lieferbar.

Good news everyone: Diese Beschränkung lässt sich mit wenigen Schritten aushebeln:

Internationale Anmeldedaten

Vorab ist wichtig zu wissen: Die Amazon.de-Anmeldedaten funktionieren unverändert auch auf Amazon.com. Und, nebenbei bemerkt, auch auf amazon.co.uk und wo nicht sonst noch alles. Allein: Um eines der internationalen Amazon-Portale nutzen zu können, bedarf es einer Kreditkarte.

Dabei tut es problemlos eine Karte eines deutschen Kreditinstituts mit einer deutschen Rechnungsanschrift. Aber die braucht es auf jeden Fall – die kurze Warnung an alle Kreditkarten-Verweigerer: Ohne weltweit akzeptiertes Plastikgeld geht es hier nicht weiter.

Kindle Bibliothek nach Amazon.com übertragen

Im Auslieferungszustand wurde meine Kindle-Bibliothek, neudeutsch: meine in der Amazon-Cloud gespeicherten E-Book-Käufe, nicht von Amazon.de, sondern von Amazon.com verwaltet. Das hatte die primäre Auswirkung, dass man in US$ bezahlt – sonst aber eigentlich nichts. Das Angebot der erhältlichen E-Books variiert mitunter ein wenig, ebenso die Preise, basierend auf dem Dollar- bzw. EUR-Tageskurs.

Mir wurde daraufhin empfohlen, meine Kindle-Bibliothek zu Amazon.de zu übertragen, um fortan Bücher in EUR bezahlen zu können. Auf meine vorherigen Käufe hatte dieser Wechsel keinerlei Auswirkungen, lediglich auf US-E-Zeitschriftenabos, die danach nicht weiter geführt werden könnten. Da ich solch ein Abo nicht nutzte, war dies auch keine Beschränkung.

Freundlicherweise kann man diesen Wechsel jederzeit rückgängig machen – bzw. auf Wunsch sogar je nach Lust und Laune hin und her wechseln. Ich nutze diese Möglichkeit hier und da, wenn ein E-Book nur in den USA erhältlich ist, wechsele dann aber anschließend meist unverzüglich zurück.

… Also: Flugs gewechselt – das geht mit wenigen Mausklicks. Und schon liefert die Produktseite den Preis. Aber leider auch die Information, dass dieser Artikel für mich als Europäer nicht lieferbar ist.

Das war also erst die halbe Miete.

Eine amerikanische Adresse “erfinden” und eintragen

Die meisten von uns haben durch das Web 2.0 sicherlich Freunde in Übersee. Wer es so ehrlich wie nur möglich machen will, der “leiht” sich dessen Postanschrift – bezieht also quasi virtuell ein Zimmer zur Untermiete.

Alternativ tut es wie in meinem Fall auch die Anschrift von MyUS.com in Sarasota FL, deren Dienstleistungen ich mitunter verwende, wenn ein Händler nun gar nicht in die Alte Welt liefern mag. … Amazon.com mit seinem Kindle Fire und nun auch mit seinen digitalen Verkäufen ist hier ein unrühmlich treffendes Beispiel.

Als dritte Möglichkeit kann man natürlich auch die Adresse eines noblen Hotels auswählen, in dem man schon immer einmal ein paar Nächte verbringen wollte.

Lange Rede, kurzer Sinn: Die reale oder plausibel erfundene US-Postanschrift wird als alternative Lieferadresse im Amazon.com-Account eingetragen.

“Umzug” in die USA

Wiederum im Bereich “My Kindle” bietet Amazon nun an, nach einem Umzug die korrekte Postanschrift zu wählen. Dies ist, logischerweise, die soeben eingegebene USA-Postanschrift.

… Sehr schön ist dabei, dass man trotzdem mit der deutschen Kreditkarte problemlos weiter bezahlen kann.

Kaufen, kaufen, kaufen!

Derart als US-Bürger verkleidet gelingt der Kauf der gewünschten Kindle-App selbstredend sofort. Sie wird kurz darauf wie jedes normale E-Book in Windeseile per Whispernet auf den Handheld übertragen.

… Parallel dazu informiert Amazon.com noch, dass Datentraffic via 3G für USA-Bürger außerhalb der USA schmerzhaft teuer wird. Wissenswert – aber letztlich uninteressant.

Und dann: Rolle rückwärts

Direkt nach Abschluss des Kaufs und Abholung der App kann man obigen Tweak getrost rückgängig machen. Also:

• Umzug zurück von der US-Postadresse auf die althergebrachte Adresse in Deutschland.
• Rücktransfer der Kindle-Bibliothek von Amazon.com nach Amazon.de.

Spannend ist, dass alle in den USA getätigten Käufe grundsätzlich unter Amazon.com verbleiben. Löscht man die App also und will sie später erneut an denselben oder einen anderen Kindle senden, muss man dazu auf jeden Fall Amazon.com bemühen.

Viel Spaß mit der somit erworbenen Kindle App!

Share

Ein bisschen weiter ausgeholt: Ja, ich bin ein Grenzgänger, der am Mac zwar mit dem Finder und erst recht mit TotalFinder recht effizient unterwegs ist. Aber wenn es hart auf hart kommt, bevorzuge ich den echten Total Commander. Das fällt am Mac schwer – aber wiederum nicht so schwer: Die aktuelle Version läuft wunderbar unter Wine, der OpenSource-Windows-API-Implementation. Mit ein paar Kniffen hinsichtlich der Tastaturbelegung und etwas Handarbeit zum Aufruf der passenden Mac-Anwendung beim Doppelklick auf eine Datei im Total Commander läuft das Ding “fast-nativ” wirklich wunderbar am Mac. (Ich habe seit Jahr und Tag einen halbfertigen Blog-Beitrag dazu in der Pipeline.)

Wo ist also das Problem? Ganz einfach: Löscht man von einer Wine-Applikation Dateien, landen diese nicht im Mac-Mülleimer. Bislang nahm ich an, dass das Wine-API schlichtweg keinen Papierkorb unterstützt, dass also Dateien immer sofort gelöscht werden – damit kann ich umgehen, kein Problem.

Das ist aber doch nicht der Fall: Nach den Blu-ray-Brenn- und -Probelese-Experimenten des Wochenendes prognostizierte das Time Machine Controlpanel beim anschließend manuell angestoßenen Backup ein Backup-Volumen von knapp 50 GB. Erstaunlich – entsprach das doch mindestens zwei gefüllten einlagigen BD-Rohlingen, die ich allesamt testweise auf die Platte kopiert, CRC-gecheckt und anschließend wohlweislich gelöscht hatte.

Aber: Die 50 GB waren weg – sowohl auf der Macintosh HD als auch auf dem Time Machine Backupvolume. Himmel, seit Festplatten 2 TB groß sind, verliert man wirklich den Überblick über derart fiepsig kleine Datenmengen. Sie lagen nicht mehr im Finder-Papierkorb. Aber warum sicherte Time Machine trotzdem 50 GB? Wo waren die Dateien?

Wie schön wäre es, wenn man nachsehen könnte, welche Dateien Time Machine in einem bestimmten Backup-Lauf tatsächlich gesichert hat. Das klingt allerdings simpler, als es in der Realität ist: Denn jedes Backup-Verzeichnis bildet aufgrund der verwendeten Hardlink-Struktur jederzeit ein vollständiges Volume – man sieht nicht ohne weiteres, was von Backup zu Backup dazu gekommen ist.

In die Bresche springt hier ein wundervolles Tool namens “TimeTracker” von CharlesSoft (bestens bekannt vom Installer-Tool “Pacifist”). TimeTracker ist als Pre-Beta-Version gekennzeichnet, erfüllt aber seinen Zweck: Es zeigt sehr detailliert, welche Verzeichnisse im Backup vorkamen, und wie viel Platz sie beanspruchen.

So kam ich dem Übeltäter auf die Schliche: Die 50 GB lagen unter ~/.local/share/trash/files. Erstaunlich: Google kennt diesen Ordner für Macintosh Computer nicht – die Fundstellen liegen im Bereich Linux. ~/.local/share/trash bildet demnach den Ort, an dem z.B. Ubuntu seine gelöschten Dateien lagert, die sich noch im Papierkorb befinden. … Der Mac verwendet dafür bekanntlich ~/.Trash.

Nach kurzem Spekulieren und anschließendem Experimentieren stand fest: Wird eine Datei im Wine-Total Commander gelöscht, landet sich unter ~/.local/share/trash – und zwar zum einen die eigentliche Datei unter ./files, zum anderen eine .tashinfo-Datei unter ./info. Flugs zur Demonstration der Löschvorgang einer Datei namens “test.zip” im Wine-Total Commander dokumentiert – vorher, nachher:

In meinem Fall war das ~/.local/share/trash-Verzeichnis auf ca. 12.000 Dateien sowie, durch die BD-Test-Dateien, auf beinahe 56 GB angeschwollen.

Die Lösung ist dreischrittig:

1. Wir gehen davon aus, dass dieser unsichtbare Papierkorb nicht mehr benötigte Dateien enthält. … Logisch, schließlich war ich mir zuvor gar nicht bewusst, dass er überhaupt existierte. Ergo kann der Inhalt von ~/.local/share/trash gestrost gelöscht werden.
• Soll dies vom Finder aus passieren (man erreicht das versteckte Verzeichnis ~/.local mit Hilfe von “Gehe zu” / “Gehe zu Ordner” bzw. Umsch-Cmd-G), rutschen die Dateien ggf. von dort aus in den Mac-Papierkorb.
  Es sei denn, man hält beim Löschen die Umsch-Taste gedrückt, damit der Mac die Dateien direkt und unter Umgehung des Papierkorbes löscht.
• Soll die Löschung wiederum von Wine i.e. wieder vom Total Commander aus passieren, gilt haargenau dasselbe: Statt einfach die Entf-Taste zu drücken, drückt man Umsch-Entf, damit Wine nicht versucht, Dateien vom Papierkorb in den Papierkorb zu verschieben.
2. Exakt das kann man sich anschließend angewöhnen: Schon unter echtem Windows bzw. VMware-Windows bin ich kein Freund des Papierkorbes, dort lösche ich Dateien in den meisten Fällen direkt mit Umsch-Entf.
3. Um das Time Machine-Backup wieder zu verschlanken, wechselt man zunächst mit Umsch-Cmd-G nach ~/.local/share/Trash und startet dann die Time Machine. Hier kann man sich dann die beiden Ordner ./info und ./files schnappen und mit der rechten Maustaste bestimmen, dass diese vollständig aus dem Time Machine-Backup entfernt werden sollen. … Nach Eingabe des Administrator-Passworts kann dies einem gut gefüllten Wine-Papierkorb schon mal etwas länger dauern – Geduld!

Ich bin mir nicht sicher, ob Wine sich ggf. konfigurieren lässt, Dateien direkt zu löschen. Oder, ob eine modernere als die von mir verwendete Wine-Version gelöschte Dateien evtl. sogar in den echten Mac-Papierkorb verschiebt – das wäre natürlich in Zukunft die sauberste Lösung.

… Sie lasen einen weiteren Beitrag aus der Reihe “Erinnerungshilfen für mich selbst und Dokumentationen für andere Betroffene” – damit geben wir zurück in die angeschlossenen Funkhäuser.

Update:

Wer mit Kanonen auf Spatzen schießen will, der kann nach dem manuellen Leeren des Wine-Papierkorbs selbigen wirksam deaktivieren mit Hilfe von

chmod 000 ~/.local/share/Trash/

Share

Dass ich mit dem Problem nicht alleine stehe, zeigt das seitenlange Suchergebnis, wenn man nach eben den Begriffen “fla export png” googlet. Es gibt dabei verschiedene Ansätze:

Der pragmatische: Ein Bild nach dem anderen einzeln exportieren

Flash bietet die Möglichkeit, ein Standbild eines Projekts als Alpha-Kanal-PNG zu exportieren. Man erstelle also eine leeres Dokument mit einer leeren Bühne, platziere dort oben links das zu exportierende Bild, exportiere das Bild …

… beschneide die exportierte Fassung in Photoshop auf die Original-Größe, sofern man nicht vorher daran gedacht hat, gleich die korrekte Bühnengröße zu wählen – und dann dasselbe mit dem zweiten Bild, dann dasselbe mit dem dritten Bild, und es verging Abend und Nacht des ersten Tages.

Das funktioniert zwar, aber ist extrem arbeitsaufwendig und insbesondere bei vielen Einzelgrafiken sehr fehleranfällig – um nicht zu sagen: nicht wirklich gangbar.

Der schmutzige: SWF kompilieren und anschließend dekompilieren

Hier startet der Arbeitsaufwand nicht mit der .fla-Projektdatei, sondern mit dem .swf-Kompilat. Diese Datei schleust man durch einen Decompiler – das kann z.B. Flaex sein.

Der Nachteil ist: Die exportierten Grafiken entsprechen allzu häufig nicht den gewünschten hochqualitativen Original-PNGs. Vielmehr exportiert der Decompiler die Grafiken so, wie sie Flash zuvor in die .swf-Datei eingebettet hat – d.h. in der Regel stark verlustbehaftet. … Freundlicherweise bleibt immerhin der Alpha-Kanal erhalten.

Dieses Problem lässt sich immerhin notdürftig lösen:

1. .fla-Datei in Flash öffnen.
2. In der Objektbibliothek nach “png” suchen.
3. Alle gefundenen .pngs markieren.
4. Rechte Maustaste, Eigenschaften.
5. “Komprimierung” – “verlustfrei”.
   
6. Auf diese Weise eine neue, hochqualitative .swf-Datei kompilieren.
7. Und dann, ganz am Ende, den Decompiler anwerfen und diese .swf-Datei auswerten lassen.

Das funktioniert, hat aber immer noch zwei Nachteile:

• Ins .fla-Projekt eingebettete JPG-Bilder (z.B. großformatige Hintergrundbilder), die man auf dem Weg ebenfalls als “verlustfrei” exportiert, werden dadurch natürlich nicht besser. Vielmehr speichert man die schon im Originalprojekt verlustbehaftet eingebettete Datei in einem verlustfreie Container – das ist ein bisschen so, als ob man aus Hackfleisch wieder ein Steak modelliert. … Es wäre deutlich schöner, wenn man die Original .jpg-Dateien bekäme und fertig.
• Der Export-Vorgang aus der .swf-Datei durch den Decompiler generiert meist numerisch aufsteigend benannte Dateien. Man wird also wiederum lange suchen und umbenennen müssen, bis man die Datei wieder gefunden hat, die man sucht. … Es wäre deutlich angenehmer, wenn die Grafiken noch dieselben Namen hätten, die sie in der Objektbibliothek in der .fla-Projektdatei hatten.

Der einzig wahre: Ein JSFL-Kommando

Danke, Google, dass Du mich zu Darren Osadchuk geführt hast, der auf http://cookbooks.adobe.com exakt dieses Problem gelöst hat. JSFL, oder “JavaScript Flash”, ist eine Möglichkeit, die Flash-Oberfläche mit geskripteten Funktionen zu erweitern. – In “lingua microsoft” würde man so etwas wohl als “VisualBasic” bezeichnet haben. … “Kleiner” Pferdefuß: JSFL gibt es nur in den “Professional”-Editionen von Flash (bei mir: CS4, bei Darren: CS5).

Via JavaScript hat man dabei im DOM Zugriff auf die Objekte, die im aktuell geöffneten .fla-Objekt eingebettet sind. Und es ist um so erfreulicher, dass es hier eine Funktion gibt, deren Name wohl selbsterklärend ist:

var success = libItem.exportToFile(imageFileURL);

Auf deutsch: Hier wird ein Bibliotheks-Item in eine Datei exportiert. … Das Rest ist eine Fingerübung und einschließlich Kommentaren gerade einmal 25 Zeilen lang: Man iteriere durch die komplette Objektbibliothek und exportiere alles, was nach Bild oder Ton aussieht, unter dem bekannten Objektnamen auf die Festplatte.

Einen direkten Download hat Darren nicht vorgesehen, aber man kann den Skript-Code sehr einfach per Copy & Paste übernehmen. Hier noch einmal der Link:

http://cookbooks.adobe.com/post_Extract_bitmaps_and_audio_from_a_FLA_file-18144.html

Das Ganze speichert man mit einem selbst erklärenden Namen von Flash aus in eine .jsfl-Datei (einfach eine UTF-8-ASCII-Datei) ins passende Verzeichnis – bei mir ist das

~/Library/Application Support/Adobe/Flash CS4/de/Configuration/Bilder und Sounds exportieren.jsfl

Nachdem Flash dann neu gestartet ist, findet sich im “Befehle”-Menü ein Eintrag namens “Bilder und Sounds exportieren”.

Und der tut exakt das, was der Name verspricht: Das JSFL.-Skript generiert nach Rückfrage eine Ordnerstruktur, die der Hierarchie der Objektbibliothek entspricht, und speichert exakt im jeweiligen Verzeichnis die .png- und .jpg-Grafiken – als wäre es das Normalste der Welt.

Wun-der-bar! Problem ein für allemal gelöst.

Share

Es ist, wie es ist: Wer ein Ticketsystem betreibt, bei dem er die User auffordert, ihnen Screenshots oder Logdateien als Attachment zu schicken, und wenn das Ticketsystem selbige Attachments dann als BLOBs in der MySQL-Datenbank ablegt, der wird alsbald eine riesengroße Datenbank bekommen – was die (mindestens) tägliche Sicherung immer unbequemer und unhandlicher werden lässt.

Wie schön wäre es doch, wenn man die Datenbank ihrem Namen entsprechend nur zum Speichern der Daten verwenden könnte, sowie die Speicherung der Dateien wiederum dem Namen entsprechend dem Dateisystem anvertrauen könnte. Derartige Datei-Halden kann man viel einfacher inkrementell oder differentiell sichern – und ggf. veraltete überflüssige Riesen-Attachments händisch herauslöschen.

Lange Bauchschmerzen und langes Googlen brachte mich hierher: Umstellung ArticleStorageDB auf ArticleStorageFS. Der User “Dennis” berichtet hier im Jahr 2007 von der Umstellung einer OTRS-Datenbank von datenbankbasierende auf eine dateisystembasierender Attachment-Speicherung mit Hilfe eines Perl-Skriptes von Stefan Bedorf aus dem Jahre 2005. Wichtig: Das ist nicht mehr aktuell!

Was ich jetzt nachfolgend schreibe aber sehr wohl:

Erster Schritt: Backup machen.

’nuff said.

Zweiter Schritt: Voreinstellung ändern

Im Backend das “Ticket::StorageModule” von “ArticleStorageDB” auf “ArticleStorageFS” umstellen. Einfach in der SysConfig nach “StorageModule” suchen …

… und umstellen.

Wie User “Dennis” richtig bemerkt, gilt dies natürlich nur für alle zukünftigen Tickets. Alle bestehenden Tickets, die mit ihren fetten Attachments die Datenbank zusauen, zeigen sich davon unbeeindruckt.

Dritter Schritt: Bestehende Tickets konvertieren

User “Dennis” berichtet, dass er das nachträgliche Herausspeichern der Attachments früherer Tickets mit Hilfe eines Perl-Skriptes von Stefan Bedorf erledigt hat. Das funktionierte, soweit ich das verstehe, unter OTRS1 – aber heute unter OTRS3 nicht mehr. (Googlet man weiter, findet man irgendwo eine angepasste Version, die auch unter OTRS2 arbeitet – aber auch die tut es auf heutigen Systemen nicht mehr).

Aber: Unter obigem Weblink liefert im Oktober 2008 der Admin “monotek” den rettenden Hinweis: Es gibt mittlerweile ein im Lieferumfang von OTRS befindliches Tool, das das Kunststück mit Bordmitteln vollbringt. Es findet sich unter $OTRSHOME/bin/otrs.ArticleStorageSwitch.pl – in meinem Fall unter /opt/otrs/bin/otrs.ArticleStorageSwitch.pl.

Wie wirft man es also an? Im Grunde genommen ganz einfach:

 /opt/otrs/bin/otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS

Merke: “S” wie “Source” – “-s ArticleStorageDB”, und “D” wie “Destination” – “-d ArticleStorageFS”. Der Vorgang zieht sich dann etwas:

[root@centos ~]# /opt/otrs/bin/otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS
NOTICE: 1/9295
NOTICE: 2/9295
NOTICE: 3/9295
NOTICE: 4/9295
NOTICE: 5/9295
:
:
:
NOTICE: 9295/9295
NOTICE: done.
[root@centos ~]#

Ich habe das Skript im Kontext des Root-Users ausgeführt, der die Verzeichnisse und Dateien aber anschließend dem User “root:apache” mit “drwxrwsr-x”-Rechten aushändigte. Das genügt, damit die OTRS-Benutzer weiterhin an ihrer Attachments heran kommen, und dass Apache bei neuen Tickets neue Ordner und Dateien anlagen kann.

Selbige lagern anschließend unter $OTRSHOME/var/article/:

[root@centos ~]# ls -la /opt/otrs/var/article/
insgesamt 28
drwxrwsr-x  5 otrs apache 4096  2. Mär 13:51 .
drwxrwxr-x 14 otrs apache 4096 30. Nov 14:19 ..
drwxrwsr-x  5 root apache 4096  2. Mär 13:46 2010
drwxrwsr-x 14 root apache 4096  2. Mär 13:48 2011
drwxrwsr-x  5 root apache 4096  2. Mär 13:49 2012
[root@centos ~]#

Fertig – abputzen! Die MySQL-Datenbank ist wieder rank und schlank – richtig ist, dass man die beiden Tabellen article_attachment und article_plain noch optimieren sollte, um deren Tabellen-Overhead nun abzuräumen. Wie das geht, hat im Original-Link User “dennis” gut beschrieben.

Share

Das Problem existiert seit geraumer Zeit: Irgendwann funktionierte das OTRS-Login mit Firefox via Passwort-Manager noch, aber seit irgendwann später eben nicht mehr. Das Problem kam mit irgend einem OTRS 3.0.x-Update oder mir irgendeinem Firefox 4/5/6/7/8/9-Update … retrospektiv weiß ich das nicht mehr, aber es macht die Sache ja nicht eben besser.

Des Pudels Kern ist, dass OTRS das Passwortfeld der Anmeldemaske auf Read-Only setzt und erst beim Eintritt des Cursors (“onFocus”) editierbar macht. Zweifelsohne handelt es sich dabei um eine sinnvolle Sicherheitserwägung, aber dieser Kniff führt effizient dazu, dass der Firefox-Passwortmanager sich bockig zeigt: Er speichert das Passwort zwar beim ersten Login auf Anfrage, trägt selbiges aber beim nächsten Login nicht mehr automatisch ein – weil das dösige Passwort-Feld in dem Moment halt nicht beschreibbar ist.

Exakt diese Information entnahm ich dem OTRS-Bugtracker, mitsamt einem Core-Patch, der der Login.dtl-Datei ein Stückchen JavaScript hinzufügt. Core-Patches an OTRS sind allerdings nervig, weil man immer damit rechnen muss, dass sie entweder mit dem nächsten Update überschrieben werden, oder (schlimmer noch) dass Sie eben dieses nächste Update der gepatchten Datei be- oder gar verhindern.

Da es sich um ein Stück JavaScript, genauer gesagt: einen Zweizeiler handelt, der aufgerufen werden soll, wenn die Login-Maske erscheint, lag es nahe, diese Funktionalität in ein Userscript (deutsch: Benutzerskript) zu stecken. Das sieht in etwa so aus – der funktionelle Kern ist ein Zweizeiler:

// ==UserScript==
// @name          OTRS Login Helper
// @namespace     https://mein.ticketsystem.tld/otrs/
// @description      Enables support for Firefox password manager
// @include       https://mein.ticketsystem.tld/otrs/index.pl*
// ==/UserScript==
// Notes:
//   based on http://bugs.otrs.org/show_bug.cgi?id=7719

document.getElementById(‘User’).readOnly = false;
document.getElementById(‘Password’).readOnly = false;

Um es tauglich für den eigenen Anwendungszweck zu machen, muss man natürlich “mein.ticketsystem.tld/otrs” durch den Pfad zum eigenen OTRS v3 ersetzen. Anschließend speichert man die Datei unter einem beliebigen Namen, der mit “.user.js” endet, also z.B. “otrsfix.user.js”.

Wie bringt man das Userscript zur Ausführung? Ganz einfach: Mit Greasemonkey.

Also:

1. Greasemonkey installieren.
2. Firefox neu starten.
3. Leeres Fenster (oder Tab) öffnen.
4. Die Datei “otrsfix.user.js” aus dem Finder oder Explorer in das geöffnete Firefox-Fenster ziehen.
5. Userscript-Installation bestätigen.
   
6. Firefox-Fenster mit OTRS-Anmeldemaske öffnen bzw. neu laden.
7. Genießen.

Share

Update: Mein Screencast zeigt Opera unter Mac OS X 10.6.8, aber das Problem ist auch unter Windows 7 und unter Ubuntu Linux 11.10 zu beobachten.

Update 2: Mit Opera 11.61 scheint das Problem (vorerst) behoben zu sein.

Share

I just noticed that I had totally forgotten to post my latest vlog on my blog – so here goes: My two resolutions for the new year 2012 – spending time and effort on making new videos, while at the same time spending time and effort on my new “hobby”.

Share

… and a happy new year!

Share