Category: macOS

Mit der Einführung der MacBook Pro’s im Oktober stellt Apple nun konsequent seine Monitore auf sog. Glare-Type Displays mit Glasabdeckung um. Erschreckend neu ist zudem die Tatsache, dass man als Kunde keine Wahlmöglichkeit mehr zwischen den neuen Glare und den bisherigen matten Displays hat.
Der Vorteil des Glare Diplays liegt in der brilianteren Darstellung von Schwarz verbunden mit der Erhöhung des Kontrastes. Allerdings kommen öfters – und wahrscheinlich auch bei Apple – sog. TN Displays zum Einsatz, die selbst mit dem erhöhtem Kontrastumfang den besseren IPS– und VA-Panels in diesem Punkt unterlegen sind.
Der entscheidende Nachteil sind aber die Reflektionen die bei den Glare-Type Displays – oder Glossy wie Apple es nennt – besonders stark bei Lichteinfall von hinten oder Punktlichtquellen zutage treten. Dabei ist der Hinweis, dass man den Arbeitsplatz nach Möglichkeit anpassen sollte ein schlechter Witz. Blanker Hohn ist der oft zitierte Satz, dass Gamer wohl keine Probleme mit dem Gerät haben, da diese in abgedunkelten Räumen ihre Augen sowieso zugrunderichten. Dass die Reflektionsproblematik keine Geschmackssache ist, zeigt die Norm ISO 9241-7 (Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten), die Glare-Type-Displays als ungeeignet für Büroarbeiten klassifiziert.
Da allerdings privates Arbeiten zuhause nicht schlechter gestellt werden sollte und Lichteinfälle ausser Haus bei Laptoparbeiten noch schlechter zu kontrollieren sind bleibt als einzigste Erkenntnis diejeniege, dass die von Apple propagierten Displays nicht alltagstauglich sind. Die Probleme welche Profis mit diesem Typ von Monitor haben (Farbkalibrierung) kamen dabei noch gar nicht zur Sprache.

Die Entscheidung nur noch Glare-Type (Glossy) Displays einzusetzen stellt nach meiner Überzeugung nicht nur einen Rückschritt in der Technologie dar – es manifestiert eher eine gewaltige Fehlentscheidung kombiniert mit wiederkehrendem Größenwahn von Apple.

Zwar stellt Apple immer noch herrausragende Hardware her, als Kunde gibt es dennoch Alternativen. Zudem gibt es glücklicherweise noch Apple Hardware ohne Monitore und nicht zuletzt stirbt die Hoffnung, dass in dieser Sache das letzte Wort noch nicht gesprochen ist.

Seit iTunes 7.7 gibt es bei mehreren Usern allerhand Probleme, bspw. mit Umlauten in Liedern usw.

Ich selber kann mit dem Programm gar nichts mehr anfangen.

•  die bestehende Library bringt iTunes zum hängen
• eine neue Library erkennt nur noch einen Teil der Lieder
• Zeitweise werden auch diese Lieder von iTunes als nichtauffindbar deklariert (liegen auf Netzwerkserver)
• CD’s abspielen klappt nicht immer, wenn die Frage  nach Importieren verneint wird.

Alles in allem ist dieses Update das schlimmste, welches je über die Apple Update  Verwaltung eingespielt wurde, die eingeschobene Version 7.7.1 verbessert den Zustand allerdings – wenn auch nicht 100% zufriedenstellend. Es scheint so als ob das neue iPhone 2.0 Apple’s Softwarequalität momentan nachteilig beeinflusst.

Nachdem ich mein WLAN Netzwerk von WEP auf WPA umstellte und zumindest anfänglich alles klappte, stellte mein AirportExpress nach einer gewissen Zeit den Dienst ein.
Dieses Spiel ging zweimal so – kurioserweise trat der Fehler immer erst nach ein paar Tagen ein. Zufällig staß ich auf folgenden Artikel, bei dem ebenfalls eine Inkompatibilität zwischen Apple Airport Produkten und einem Speedtouch Modem beschrieben wurde.

http://www.qdsl-support.de/archive/index.php?t-13262.html

Die Lösung, die bei mir ebenso zum Erfolg führte war ein Downgrade der Airport Express Firmware auf Version 6.1.1

http://www.apple.com/support/downloads/airportexpressfirmware611formacosx.html

Auf der Downloadseite der aktuellen Firmware (6.3) steht, dass WPA2 einen Macintosh Computer mit Aiport Extreme benötigt. Da sich in meiner Konfiguration der AirportExpress Client in einem bestehenden Netz einklinkt ist nicht die Kompatibilität zum Apple Rechner sondern in erster Linie zum primären AccessPoint (funkwerk bintec R232bw) wichtig. Dort ist zur Absicherung aber folgendes eingestellt.

Während die AiportExtreme Karte des Macintosh kein Problem hat, scheint diese Einstellung das AiportExpress Gerät aus dem Konzept zu bringen.

Im Fehlerfalle meldete das Syslog des AccessPoint immer wiederkehrende disconnects – failed authentifications – und wieder connects. Ein „reboot“ (Aus- und Einstecken des AirportExpress) brachte nix – nach einem hartem Reset ging’s wieder ein paar Tage gut, bis diesem Problem erneut auftrat.

Eine dauerhafte Lösung ist bisher nur das Downgrade der Firmware – vielleicht kommt ja noch ne bessere Lösung…

Natürlich ist es kein Problem auch Qt Programme als UB’s (Universal Binaries) zu erstellen. Allerdings ist es unter Qt 4.x wesentlich einfacher als unter Qt 3.x, weswegen ich die Vorgehensweise kurz getrennt darstelle

UB’s mit Qt 3.3

Rein theoretisch kann man auch hier beide Zielplattformen (ppc und i386) auf einer Maschine erstellen, was aber zusätzlichen Aufwand erfordert. Einfacher ist es binaries für die beiden Plattformen auf einer passenden Maschine zu erstellen und später zusammenzufügen. die 64bit Targets (ppc64 bzw. x86_64) spielen hier übrigens keine Rolle, da Mac OS X 10.4 sowieso keine 64bit GUI Programme unterstützt.

Das Hauptproblem bei Qt 3.3 ist, dass die Qt Library selber nicht als UB vorliegt oder out-of-the-box erstellt wreden kann. Daher muss man auf jeder Zielplattform diese Library erstellen.

Danach erstellt man sein Programm und/oder seine Libraries/Frameworks auf jeder Maschine. Am Schluss legt man auf jeder Maschine ein Build-Verzeichnis i386 und ppc an, kopiert die Binaries rein und führt Sie mit dem lipo Befehl zusammen, bspw:

lipo -create  build/i386/test build/ppc/test -output test.app/Contents/MacOS/test

mit dem file Kommando sieht man, dass das neue test Binary nun 2 Plattformen unterstützt:

file  test.app/Contents/MacOS/test

test.app/Contents/MacOS/test: Mach-O universal binary with 2 architectures

test.app/Contents/MacOS/test (for architecture i386): Mach-O executable i386
test.app/Contents/MacOS/test (for architecture ppc): Mach-O executable ppc

UB’s mit Qt 4.x

Hier ist das Sache wesentlich einfacher. Wenn man das Toolkit mit dem -universal Flag übersetzt hat man ein UB fähiges Qt Framework. In seinem .pro File muss man dann nur noch

QMAKE_MAC_SDK=/path/to/MacOSX10.4u.sdk
CONFIG+=x86 ppc

angeben um ein fertiges Binary zu erzeugen. Im Hintergrund schleusst Qt einfach die -arch Flags an den g++ Compiler weiter.

weitere Hinweise:

gfortran unterstützt in der eigentlichen Fassung diese -arch Flags noch nicht. Hier gibt es allerdings einen weiteren experimentellen Fork der das schon kann:

http://r.research.att.com/tools/

Um die Qt Bibliothek mit dem eigenen Programm auszuliefern muss der install_name (Linux: soname) geändert werden, dies ist hier am Bsp. von Qt 3.3 dargestellt:

..für die Qt Library selber

 install_name_tool id @executable_path/../Frameworks/libqt.3.dylib 
demo.app/Contents/Frameworks/libqt.3.dylib

und für das Programm:

install_name_tool -change libqt.3.dylib 
@executable_path/../Frameworks/libqt.3.dylib 
test.app/Contents/MacOS/test