Heute im Programm: Mit der Tastaturkombination ⌃⇧⏏ (Ctrl+Shift+Eject) schaltet man das Display eines Mac-Rechners (also vor allem sinnvoll bei einem iMac) aus.. alternativ natürlich über eine magische Ecke.
Zufällig(!) gefunden via apfeltalk.de
Archiv der Kategorie Apple
Wir hatten dieses Thema bereits indirekt durch den ApplicationBundler im Beitrag vorletzter Woche besprochen.. aber hier nochmal zum eigentlichen Problem und dessen Lösung.
Der Fehler verursacht die aktuell ausgewählte Java-Version (und das ist bei den meisten Leuten der Standard Java 1.5.0). Wenn jedoch die Jar mit Java 1.6 kompiliert wurde, kann der 1.5-Loader damit nichts anfangen bzw. schützt aus naheliegenden Gründen vor der Ausführung. Zwar ist auf Mac OS X System der Version 10.5 auch Java 1.6 installiert, dieses ist jedoch kein Standard.
Es gibt dafür nun drei Möglichkeiten:
- Der Benutzer startet die JAR nicht mit Doppelklick bzw. dem Kommando “java -jar JarFile.jar” sondern mit der direkten Angabe im Frameworkverzeichnis.. diese Lösung ist inakzeptabel.
- Der Benutzer stellt seine Default-JVM auf 1.6 um.. das machen die Entwickler eh, aber der Benutzer wird auch damit überfordert sein. Auch keine akzeptable Lösung.
- Man erstellt eine Mac-Application mit entsprechenden Application-Bootloader und einer Art Manifest, wo eingestellt wird, welche Java-Version verwendet werden muss. Damit findet sich Java 1.6 sogar dann, wenn man als Default 1.4 eingestellt hat. Außerdem hat es den positiven Nebeneffekt, dass die “technische” Jar vor dem Benutzer durch ein Anwendungsymbol kaschiert wird.
Update: It seems that MacWidgets causes this problem. In the applications main frame I added the line
MacUtils.makeWindowLeopardStyle(getRootPane());
If I disable (comment out) this line there will no exceptions. What a..
The structure of components: One Mainframe with BorderLayout (Toolbar, Sidebar and MainContent). The MainContent contains eventually the graph, the corresponding satellite component is in the sidebar.
Original post:
I had already posted about it last week. But now it seems that is was not a reasonable solution.
I have a java swing application which uses standard java swing elements and the jung2 graph framework visualizing graphs. The application is developed under java 1.6 and mac os x 10.5.6.
The actual problem is that since yesterday the AWT-Eventthread crashed, for example like this:
Thu May 7 15:04:28 X.localdomain java[2002] : CGSResolveShmemReference : reference offset (65232) exceeds bounds (32768) on shmem obj 0x257e Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Non-Java exception raised, not handled! (Original problem: Error (1000) creating CGSWindow) at apple.awt.CRenderer.doRect(Native Method) at apple.awt.OSXSurfaceData.doRect(OSXSurfaceData.java:1247) at apple.awt.CRenderer.fillRect(CRenderer.java:157) at apple.awt.CRenderer.fillRect(CRenderer.java:145) at sun.java2d.pipe.ValidatePipe.fillRect(ValidatePipe.java:58) at sun.java2d.SunGraphics2D.fillRect(SunGraphics2D.java:2501) at edu.uci.ics.jung.visualization.BasicVisualizationServer.renderGraph(BasicVisualizationServer.java:341) at edu.uci.ics.jung.visualization.BasicVisualizationServer.paintComponent(BasicVisualizationServer.java:321) at javax.swing.JComponent.paint(JComponent.java:1027) at javax.swing.JComponent.paintChildren(JComponent.java:864) at javax.swing.JComponent.paint(JComponent.java:1036) at javax.swing.JComponent._paintImmediately(JComponent.java:5096) at javax.swing.JComponent.paintImmediately(JComponent.java:4880) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:749) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:679) at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:659) at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:300) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:210) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:200) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:195) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:187) at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
This happens in the event thread, so the application is “still” useable. Well, of course, the graph painting is a mess.
After googling, I found some solutions:
- Execute the file access rights (permissions)-fix via disk utilities & reboot the maschine. Yes, this will fix the problem for some starts, but then.. what a dejavu.
- Assure that the paint-process is not outside of the awt-thread.. yes it is. See trace. (Link developer.apple.com)
- Exclude the SWT jar.. well, I do not use this and I have not include it. (Link publicobject.com)
- Use not the apple ui manager.. well, i replace the manager for the components of jung, i disabled my own selfwritten graph vertex renderer.. no changes. No less exceptions, nothing.
Perhaps this could be an issue by jung, but..
- why only on this mac – but no error/exception on others systems like windows and linux? Also I have a 2 years older macbookpro.. no problem there.
- why, or some time, is there no problem after fixing the file access rights (permissions) and rebooting the machine?
Currently, I have no solution.. the exeptions raises while painting the graph (which uses many paint()/Graphs objects ofc) moving/zooming it. I was able to catch some of the strange exceptions overriding the default visualizerviewer (by jung) and put in a small try-catch-wrapper of the corresponding method (here renderGraph). But other exceptions raised within javax.swing.Component and so on…
And.. how strange: the line
Thu May 7 15:04:28 X.localdomain java[2002] <Warning>: CGSResolveShmemReference : reference offset (65232) exceeds bounds (32768) on shmem obj 0x257e
is not an output by the java exception but from the failed native method. The numbers: 32768 (=2^15) and 65232 (2^16 -4). 64bit-problem?
I’m very appreciate if someone has an idea or solution.
Wie bereits berichtet, ist es von Vorteil, der Buildprozess mit einem Ant-Script zu automatisieren. Um eine Mac-Application zu erstellen, muss man nur wissen, wie eine solche Application aufgebaut ist.. der Rest ist ein Klacks.
Eine Mac-Application ist ein Verzeichnis mit der Erweiterung .app. Die Struktur einer Application (wir nennen sie im Folgenden Application) sieht wie folgt aus:
- Application.app
- Contents
- Info.plist — Properties-Datei für die Anwendung und Java
- MacOS — Verzeichnis
- JavaApplicationStub — Bootloader für Javaprogramme
- PkgInfo — Datei mit Entwicklerinfo
- Resources — Verzeichnis mit dem eigentlichen Javaprogramm
- Java
- Die Jars und so.
- Contents
Den Bootloader befindet sich auf einem Mac in dem Ordner /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub.
Prinzipiell kann man sich diese Struktur komplett selber erstellen; es ist aber zu Empfehlen, den initialen Prozess durch das Programm /Developer/Applications/Utilities/Jar Bundler zu machen. Mit Hilfe dieses Programmes lässt sich für eine bereits fertige JAR die Application erstellen.
Anschließend kopiert man das erstellte Resultat – quasi als Vorlage – in ein Verzeichnis für die Builds. In meinem Fall in dem build_data Verzeichnis. Ein Ant-Task erstellt darauf hin im Verzeichnis deploy eine Application. Die Vorlage ist idealerweise auch im SVN und auch später noch veränderbar – beispielsweise durch das Ändern des Applicationicon, -titel oder anderen Einstellungen.
Wichtig 1: Bei Verwendung von FatJar muss man als Package für die Main den Bootloader von FatJar (com.simontuffs.onejar.Boot) verwenden. Dies erkennt das Programm Jar Bundler aber auch automatisch.
Wichtig 2: Beim Kopieren der Dateien kann es passieren, dass die Rechte an der JavaApplicationStub verloren gehen. Diese muss als ausführbar markiert sein. Ein entsprechender Ant-Befehl stellt das sicher.
<target name="makeMac" depends="makeNormal">
<copy todir="deploy/Application.app">
<fileset dir="build_data/Application.app"/>
</copy>
<!-- chmod the application stub file executable -->
<chmod file="deploy/Application.app/Contents/MacOS/JavaApplicationStub" perm="755"/>
<copy file="deploy/Application.jar" tofile="deploy/Application.app/Contents/Resources/Java/Application.jar" />
</target>
Um den Index neu aufzubauen (beispielsweise aus Gründen der Performance, wenn er kaputt ist, nach einem Plattenwechsel) kann man sich Tools wie Onxy bedienen, die das auf Knopfdruck erledigen. Leider hat das bei mir nicht ganz geklappt, evtl. lag das daran, dass das Volume sich selber auf der Exclusionliste hatte (das hatte ich gemacht, damit ein Fremdsystem nicht den Index kaputt macht, die Idee ist nach hinten losgegangen 
).
Wie dem auch sei, wenn man so in Google danach sucht, wird einem überall der Befehl sudo mdutil -E / vorgeschlagen. Tatsächlich löscht und deaktiviert dieser Befehl den Index aber nur.. warum schreibt das keiner dahin?
Mac:/ knalli$ sudo mdutil -E / /: Indexing and searching disabled.
Etwas schwieriger war es, herauszufinden, wie man den Index wieder aktiviert. Aber, geht natürlich auch, nur anderer Parameter: sudo mdutil -i on /
Mac:/ knalli$ sudo mdutil -i on / /: Indexing enabled.
Die alternativen Möglichkeiten haben mir nichts gebracht, es war wirkungslos:
- Volume in Ausnahmeliste aufnehmen und wieder entfernen (Apple-Lösung)
- Onxy-Spotlight-Index-Reset (Reset ja, Neuaufbau nein).
Definitiv in der Kategorie: “Was ich schon immer mal wissen wollte..”
Wenn man mit Java Swing ein JFileChooser verwendet, so sieht der unter MacOS X alles andere als schön aus – und nativ ist er sowieso nicht. Was ich nicht wusste: Apple hat das AWT-Pendant FileDialog nativ implementiert (oder nachgebaut?). Gewusst wie – darauf gekommen bin ich auch nur, weil ich einfach mal gesucht habe.
Edit: Wie es aussieht, sieht der FileDialog auch unter Windows besser als sein Swing-Pendant aus. Wie sieht das mit den anderen System aus?
Ich hatte das Problem, dass jeder Öffnen und Speichern-Dialog neuerdings mehrere Sekunden brauchte, bis man etwas “machen” konnte. Zudem war die Liste der “Orte” (englisch: Places) überfüllt mit Hunderten Einträgen. Meine definierte Liste war etwa 15-20 Items lang, aber diese Liste wurde ein paar Mal wiederholt – strange.
Löscht man die Datei ~/Library/Preferences/com.apple.sidebarlists.plist, loggt sich aus und wieder neu ein, so ist die Sidebar wieder aufgeräumt. Man muss allerdings die Places wieder neu einstellen und ggf. Tweaks wie das Ausblenden der iDisk reaktivieren.
The Unexpected: Battery Life in OS X vs. Windows Vista
via anandtech.com
Wie immer, sehr netter Artikel bei Ars:
Nun, bei der Keynote gestern gab es Notebooks, das wissen wir jetzt alle 
Nahezu alles, was man die 2 Tage vorher so an Gerüchten hörte, hat sich als Wahrheit herausgestellt.
Ein interessantes Bild – naja, sicherlich konnte man zum Unterstreichen kein besseres finde – ist das, wo jeder Student ein MacBook hat.