Mac java aqua look and feel for windows
Very nice :-) It avoids that the window title is temporarily in the light design during startup and I hope the workspace chooser would also be dark during startup. (In reply to Lakshmi Shanmugam from comment #11) redrawing problems in various situations (probably because cocoa doesn't redraw subviews with a layer just because the parent view is marked as dirty) when resizing the editors or views, editor or view contents are scaled rather than redrawn.
#Mac java aqua look and feel for windows Patch
Still this patch is no complete solution, as views are now layer based, which leads various drawing problems: The other issue is that explicitly invoking view.displayIfNeeded() does not work because of this, but we already discussed in bug 526395 that doing synchronous paints is bad for performance and as cocoa invokes displayIfNeeded based on time in when nextEventMatchingMask is called, so not doing anything in Control.update(boolean) works (at least for normal apps which invoke nextEventMatchingMask often enough) which depend on the font, so returning a NSBitmapImageRep based context seems to work. Other invocations are usually need to compute the size of buttons etc. (In reply to Eclipse Genie from comment #6)Įxperimental patch for avoiding NPEs when running with NSRequiresAquaSystemAppearance, because default and window NSGraphicsContext is then only available within drawRect invocations.
I am running into this same issue when attempting to run BiglyBT in 'dark mode' - there are a couple of places I am getting a stack trace:Īt .puteSize(CLabel.java:148)Īt .puteSize(GridData.java:494)Īt .GridLayout.layout(GridLayout.java:224)Īt .puteSize(GridLayout.java:167)Īt .puteSize(Composite.java:229)Īt .puteSize(FormData.java:131)Īt .FormLayout.layout(FormLayout.java:326)Īt .FormLayout.layout(FormLayout.java:292)Īt .Composite.updateLayout(Composite.java:1267)Īt .Composite.layout(Composite.java:742)Īt .tScrollWidth(Tree.java:3172)Īt .ndMeasureItem(Tree.java:2746)Īt .Tree.drawInteriorWithFrame_inView(Tree.java:1067)Īt .Display.windowProc(Display.java:6405)Īt .cocoa.OS.objc_msgSendSuper(Native Method)Īt .Widget.drawRect(Widget.java:769)Īt .Display.windowProc(Display.java:5942)Īt .Display.applicationNextEventMatchingMask(Display.java:5196)Īt .Display.applicationProc(Display.java:5620)Īt .cocoa.OS.objc_msgSend(Native Method)Īt .(NSApplication.java:97)Īt .Display.readAndDispatch(Display.java:3732) (For the eclipse launcher it is the 10.10 sdk - and configuring 1.8 as jvm in the eclipse.ini using -vm doesn't avoid the crash, so this must be the difference) Otool -l /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home/bin/java | fgrep -A3 LC_VERSION_MIN_MACOSX Otool -l /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/bin/java | fgrep -A4 LC_VERSION_MIN_MACOSX I now found out that this was because I was running with jdk1.8.0_162, so the difference is probably because of some api linkage check - it was linked with the 10.8 sdk: At EclipseCon I could not reproduce the crash in a nested eclipse. When I do that, the application crashes when run with Java 9 or later in Contol.internal_new_GCĪt .Control.internal_new_GC(Control.java:2180)Īt .GC.(GC.java:177)Īt .GC.(GC.java:138)Īt .CLabel.getTotalSize(CLabel.java:274) I haven't found documentation for this, but Apple has opensourced the relevent code, see To active this setting in a nested eclipse, the CFProcessPath environment variable has to be set in the launch configuration so it points to a folder which contains a ist with this setting (i.e.
As we won't link on 10.14 for now, this means setting Just summarizing some discussion at EclipseCon Europe: