Using the unified toolbar with Java 1.6 or within an .app bundle

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use the example unified toolbar code
2a. Run an application using Java 1.6 (commandline / jar or .app)
2b. Run an application using Java 1.6 (within a .app only)

What is the expected output? What do you see instead?
This should produce a unifed toolbar, but you get the problem described here:
http://rchandran.blogspot.com/2009/07/new-netbeans-look-on-os-x-part-ii.html

Someone found a work around by drawing the fade manual in the comments of
this post:
http://explodingpixels.wordpress.com/2008/05/02/sexy-swing-app-the-unified-toolb
ar/#comment-936

What version of the product are you using? On what operating system?
Mac OS X 1.5
Java 1.6
Mac Widgets 0.9.5

Please provide any additional information below.
I have raise an issue with apple, please feel free to comment on it too if
you can give them more information:
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/110/wo/5lsjsFab3uRAr
nLL2N1U70/8.56

Original issue reported on code.google.com by jamesd...@gmail.com on 17 Oct 2009 at 1:42

[GoogleCodeExporter]

Should also have said that it happens when launch a .app bundle that users Mac 
OSX 
JavaApplicationStub java launch. NetBeans found a way round it by using their 
own
launcher, although that would complicated to do, and only solves the problem 
for Java
1.5 within a .app and not for Java 1.6 in general.

Original comment by jamesd...@gmail.com on 17 Oct 2009 at 2:04

[GoogleCodeExporter]

Try running the latest developer build:

http://www.macwidgetsforjava.com/downloads/latest/mac_widgets.jar

I believe this issue is fixed. Let me know if the problem is resolved, and I'll 
close this issue.

Original comment by kenneth....@gmail.com on 20 Oct 2009 at 12:16

• Changed state: Accepted

[GoogleCodeExporter]

Still seems to look funny with that version if I run with java 1.6 or 1.5 
within a .app

Original comment by jamesd...@gmail.com on 20 Oct 2009 at 3:17

Attachments:

• Toolbar.png

[GoogleCodeExporter]

Let me know if there's any other information or testing you want me to help 
with. I
keen to get this working and to help as much as I can.

Original comment by jamesd...@gmail.com on 20 Oct 2009 at 3:39

[GoogleCodeExporter]

Also let me know if the email you have listed is an email that I can use to 
donate on
paypal. cheers, James

Original comment by jamesd...@gmail.com on 21 Oct 2009 at 3:47

[GoogleCodeExporter]

Hi James,

If you'd like to donate, you can use:

kenneth.orr@gmail.com

Thanks!
-Ken

Original comment by kenneth....@gmail.com on 21 Oct 2009 at 4:18

[GoogleCodeExporter]

So if you run the same code, not in a .app, it looks fine? Can you point me to 
the NetBeans workaround?

Original comment by kenneth....@gmail.com on 22 Oct 2009 at 3:43

[GoogleCodeExporter]

Yes if I use the same Jar, but run it in a .app it doesn't look right. When you
bundle into a .app Apple include the JavaApplicationStub native binary that is 
used
to launch your .jar and also bind the windows to that .app's icon on the doc.

What netbeans does it use a shell script (see attached file netbeans) which in 
turn
launches there own native binary (nbexec) to do the same job as the
JavaApplicationStub above, but for some reason it doesn't have the same 
problem. I
could be wrong though, and they may have a work around in their java code that I
haven't found.

Also if I change my Java Preferences and launch just the jar using Java 1.6 it 
has
the same problem as when running the .app in Java 1.5

I guess the other work around would be to be to shade the window in gray 
directly on
Java 1.6 on leopard, and if there was a way to detect the .app do it for that as
well. Maybe it could be an option that an application could enable for the 
toolbar.

Apple responded to the bug I raised with them:
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/110/wo/zxYJMltbrUgD6
5hyLBt8yM/3.79.28.0.13

Saying:
"This is a known issue for 64-bit applications on Leopard. All 64-bit apps have
broken textured windows, and this issue has been resolved in Snow Leopard."

I guess this is because parts of the Java runtime are 64-bit, but it doesn't 
help
those of us still on Leopard.

Original comment by jamesd...@gmail.com on 24 Oct 2009 at 12:05

Attachments:

• netbeans
• nbexec

[GoogleCodeExporter]

I'm already manually painting the textured window background on the Mac for 
Java 6 on Leopard. Sounds like if I 
extend this to include 64 bit JVMs on the Mac, I'll fix your case.

Original comment by kenneth....@gmail.com on 24 Oct 2009 at 1:02

[GoogleCodeExporter]

I'm still a little confused here. I don't see any rendering issue under 1.6 on 
Leopard with the latest version of the 
code. I manually paint the textured window background in that particular case 
(Leopard + 1.6). 

Can you run the DUnifiedToolBar demo and see if that works for you?

Original comment by kenneth....@gmail.com on 24 Oct 2009 at 12:50

[GoogleCodeExporter]

I'm confused too. Now it seems to work fine. I swear I built my project with 
the link
you sent, but I guess I didn't. Thanks anyway, keep up the great work and let 
me know
if there's anyway I can help towards this project. I'm developing an application
template, that aims to create a native experience as possible on different 
platforms
and will be including your library as part of it:
http://code.google.com/p/limegreen/

Original comment by jamesd...@gmail.com on 24 Oct 2009 at 3:58

[GoogleCodeExporter]

OK, glad to hear it's working!

Original comment by kenneth....@gmail.com on 25 Oct 2009 at 12:10

• Changed state: Invalid

[GoogleCodeExporter]

I'm still having problems with this using the unified toolbar on JDK 1.6 on 
Leopard,
with the version of mac_widgets.jar you linked above on 20 October.

I'm launching my app via JLNP from Firefox, if that matters.

Original comment by jonabb...@gmail.com on 28 Oct 2009 at 5:03

Attachments:

• [Picture 2.png](https://storage.googleapis.com/google-code-attachments/macwidgets/issue-133/comment-13/Picture 2.png)
• [Picture 3.png](https://storage.googleapis.com/google-code-attachments/macwidgets/issue-133/comment-13/Picture 3.png)

[GoogleCodeExporter]

So "Comment 11" is incorrect, or were you using a different configuration (e.g. 
Java 5)?

Original comment by kenneth....@gmail.com on 28 Oct 2009 at 5:30

[GoogleCodeExporter]

I can't speak to Comment 11, but I am using Java 6 on Leopard.  The screenshots 
include a dialog showing the 
system properties for Java and Operating System versions.

Original comment by jonabb...@gmail.com on 28 Oct 2009 at 5:32

[GoogleCodeExporter]

Incidentally, I hadn't been setting apple.awt.brushMetalLook before taking 
those screenshots.. after posting 
those shots, I thought perhaps I had just missed a step, but when I went back 
to set 
apple.awt.brushMetalLook to "true", I still got the same behavior.

However, there is something left for me to try.  I attempted to do 
System.setProperty("apple.awt.brushMetalLook", "true") before creating and 
opening my main application 
window, but there is a login window which is displayed first.  Perhaps I need 
to set apple.awt.brushMetalLook 
before creating and displaying *that* window.

I will try that and report back.

Jon

Original comment by jonabb...@gmail.com on 28 Oct 2009 at 5:35

[GoogleCodeExporter]

Hi Jon,

If you're using MacUtils.makeWindowLeopardStyle, then you don't need to set teh 
brushed metal property, as 
that is done for you:

http://code.google.com/p/macwidgets/source/browse/trunk/source/com/explodingpixe
ls/macwidgets/Mac
Utils.java

I got you confused with James, which is why I asked if Comment 11 still applied 
-- disregard!

A couple of things to try:

1) Run without using an app bundle -- do you see the same behavior?
2) Verify that you are in fact running with the latest developer build ( 
http://www.macwidgetsforjava.com/downloads/latest/mac_widgets.jar )
3) Create a simple app (just a JFrame), apply the Mac Widgets for Java and see 
if you see the same behavior.

Let me know how that goes.
-Ken

Original comment by kenneth....@gmail.com on 28 Oct 2009 at 6:10

[GoogleCodeExporter]

Okay, I had needed to do 
getRootPane().putClientProperty("apple.awt.brushMetalLook",
"true") on my main window.

Once I did this, the window's chrome looked right and the unified toolbar 
melded nicely.

Unfortunately, the rest of my interface looked very poor, indeed, including
especially my JDesktopPane with the JInternalFrames.

I attempted to do putClientProperty("apple.awt.brushMetalLook", "false") on 
some of
my interior panels, but it appears that the client property on the root pane of 
the
JFrame rules over all.

I'm going to have to back out of using the unified toolbar, I think, but it's 
not the
fault of the toolbar code, which appears to be working just fine as long as the
putClientProperty() call is made on the JFrame's rootPane.

Original comment by jonabb...@gmail.com on 28 Oct 2009 at 6:11