custom firefox keyboard shortcuts 03. Apr 2010

Während man den Menüeinträgen einer Software unter Mac OS X über die Systemeinstellungen bequem Tastenkürzel zuweisen kann bleibt man für sonstige Kommandos leider außen vor. Für den Firefox kommt in diesem Fall Keyconfig zur Rettung. Dieses Add-on macht genau das, was der Name verspricht und man kann zum Beispiel dem Firefox die Tastenkürzel des Safari beibringen. Es gibt eine kleine Liste mit Beispielen wo unter anderem auch die Befehle zum wechseln in den nächsten bzw. vorherigen Tab enthalten sind.

 

close firefox window with cmd-w 01. Apr 2010

Ich habe keine Ahnung was sich die Firefox-Entwickler dabei gedacht haben einen selbstverständlichen Mac OS X-Standard wie das Schließen des aktuellen Fensters mit ⌘W zu deaktivieren, aber man kann sich Gott seid dank von diesem Unsinn erlösen indem man einfach in die Adresszeile about:config eingibt und dann den Wert browser.tabs.closeWindowWithLastTab auf true setzt. Voilà!

 

federal switching recommendations 13. Feb 2010

Das Bundesamt für Sicherheit in der Informationstechnik reagierte prompt und empfahl den Nutzern des Internet Explorers, vorübergehend auf einen anderen Browser umzusteigen. Das Redmonder Surfprogramm wurde kurz darauf per Update repariert. Doch es dauerte nicht lange, bis das nächste Leck gefunden war. (Quelle: ZDF)

Ich frage mich, was wohl passieren muss, damit das Bundesamt für Sicherheit in der Informationstechnik den Nutzern des Internet Explorers empfiehlt dauerhaft auf einen anderen Browser umzusteigen. Empfehlen die eigentlich auch den Nutzern von Microsoft Windows vorrübergehend auf ein anderes Betriebssystem umzusteigen? Komfortable Möglichkeiten dazu gäbe es ja mittlerweile in Gestalt von Knoppix und anderen Linux-Live-CDs.

 

assembling a usable safari 4 09. Jul 2009

Mein erster Updateversuch auf Safari 4 verlief wenig erfolgreich. Nach der Installation des Updates stürzte Safari noch während des Startvorgangs reproduzierbar ab. Mir war zwar klar, dass dies mit hoher Wahrscheinlichkeit mit den von mir installierten Plugins zu tun haben musste, aber diese Erkenntnis half mir dann auch erstmal nicht weiter, da ich mir nicht vorstellen konnte ohne Sogudi und SafariBlock zu leben. Ich führte also ein Downgrade auf Safari 3 durch und ließ erstmal alles beim Alten.

Dank dem Hinweis von Maurice auf Keywurl habe ich dann Tatendrang für einen neuen Anlauf entwickelt. Ich entfernte also die Plugins unter /Library/InputManagers und installierte das neueste Safari 4-Update sowie die aktuellen Versionen von Keywurl und SafariBlock. Um die Kürzel von Sogudi zu übernehmen habe ich dann noch die Präferenzen von Sogudi nach Keywurl kopiert (Das Format ist kompatibel).

mkdir ~/Library/Application\ Support/Keywurl
cp ~/Library/Application\ Support/SogudiShortcuts.plist \ 
~/Library/Application\ Support/Keywurl/Keywords.plist

Nach dem Kopieren der Präferenzen sind dann alle Kürzel wie gewohnt verfügbar. Lediglich der default-Kürzel wird fehlerhaft importiert. Anstatt complete query muss dort complete location field stehen. Wenn dies angepaßt wird funktioniert der default und zwar sogar nicht nur mit der Leertaste sondern auch ohne alles, sprich Keywurl überschreibt die Safari-Methode zum Aufruf der korrespondierenden Domäne.

Soweit so gut. Updates bedeuten aber leider nicht nur Verbesserungen sondern oft auch Verschlimmbesserungen. In diesem ist die Adressleiste so ein Fall. Nachdem sie schon beim Firefox in Form der Awful Bar verhunzt worden war, legten nun die Safari-Entwickler nach und zerstörten ihrerseits die vorher in ergonomischer Perfektion erstrahlende Schnittstelle.

Vorher:

Safari 4 Beta Adressleiste

Nachher:

Safari 4 Final Adressleiste

Wie man an diesem Beispiel schön erkennen kann führen viele Websites in ihrer Titelzeile nicht ihren Namen sondern Suchmaschinenspam, der einem dann statt der URL von Safari 4 an prominenter Position serviert wird, während die URL ein abgelegenes Schattendasein in hellgrauer Schrift fristen muss. Der Versuch dieses “Feature” wieder abzustellen verlief leider erfolglos. Lediglich in der Betaversion gibt es versteckte Präferenzen mit denen die klassische Adressleiste wiederhergestellt werden kann.

Also musste die Betaversion her. Natürlich war diese nicht mehr auf der Apple-Website verfügbar, also musste ich erstmal in den Tiefen des Netzes graben um sie ausfindig zu machen. Als ich diese dann versuchte zu installieren, hat sich diese dann natürlich wie bei Apple-Applikationen üblich geweigert, weil ja schon eine neuere Version der Applikation installiert war. Anstatt sie jetzt davon zu überzeugen sich trotzdem zu installieren habe ich einen anderen Weg eingeschlagen.

Zuerst habe ich mithilfe von Pacifist den Safari.app-Ordner aus der PKG-Datei im Diskimage extrahiert. Um an den Safari.app heranzukommen muss man erstmal mit Pacifist die Datei Payload extrahieren und diese dann wieder mit Pacifist öffnen. Darin befindet sich dann im Applications-Ordner der Ordner Safari.app. Diesen Ordner dann extrahieren und einfach in den Programme-Ordner über die Finalversion drüberkopieren

Das hat zwei Vorteile. Erstens funktioniert es im Gegensatz zu automatischen Installationsroutine auf Anhieb und zweitens behält man so zumindest einen Teil der aktuelleren Dateien der Finalversion.

Nach erfolgreicher Installation dann erstmal die Ernüchterung. Keywurl meldet, dass es mit dieser Version nicht zusammenarbeiten möchte. Ich habe dann versucht es durch einen kleinen Eingriff in die Konfigurationsdatei dazu zu bringen zu laden, aber leider war die initiale Weigerung des Plugins nicht unberechtigt, es funktionierte mit der Betaversion einfach nicht.

Auf der Keywurl-Website waren leider auch keine alten Versionen verlinkt, also probierte ich die URL zu verändern um versteckte Versionen aufzudecken und siehe da es fand sich eine ältere Version welche sich nicht nur auf Anhieb laden ließ sondern auch tadellos funktionierte. Die installierte Version von SafariBlock verrichtete wie gewohnt seine Dienste, also galt es nur noch dem Adresszeilen-Spuk den Garaus zu machen.

defaults write com.apple.Safari \
DebugSafari4IncludeFancyURLCompletionList -bool NO

Und wenn man gerade dabei ist, kann man eigentlich auch gleich noch den blauen Fortschrittsindikator wiederherstellen

defaults write com.apple.Safari \
DebugSafari4IncludeToolbarRedesign -bool NO
defaults write com.apple.Safari \
DebugSafari4LoadProgressStyle -bool NO

und dem albernen Topsites den Saft abdrehen.

defaults write com.apple.Safari \
DebugSafari4IncludeTopSites -bool NO

Das ganze läßt sich im übrigen auch via GUI mit Safari Buddy vornehmen.

Nun ist dies sicherlich keine schöne Lösung, da ich so immer nur von einem Teil der Sicherheitsupdates profitiere, aber ich habe erstmal meine Seelenruhe und vielleicht finde sich ja mit der Zeit noch eine bessere Lösung.

 

bad request to google cache 19. Jun 2009

Bad Request

Those who use Safari 3 on Mac OX 10.5 Leopard might have experienced problems when using the cache functionality of the Google search. After some weeks of Safari usage suddenly all Google cache pages lead to the following error message.

Bad Request - Your client has issued a malformed or illegal request.

Clearing Safaris cache doesn’t help. Searching for google in the cookie list and deleting all hits doesn’t help. What does help is deleting all cookies. This of course is a very cumbersome solution since now you have to login again on all your websites and you lose all your preferences. To avoid this you can simply delete all cookie list entries corresponding to the ip adress displayed in the address bar when looking at the google cache error page. Be careful to press Remove and not Remove all since the latter wipes out all cookies even those that are not marked. So in my case I’d simply search for 209.85.129.132 and delete all hits.

Google Cache Cookies

Booyah, this solves the problem!

 

1 2