[kepler-dev] [Bug 3801] - open dialog, common places pane has white box instead of text

Thu Mar 12 18:00:27 PDT 2009

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3801

cxh at eecs.berkeley.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

------- Comment #4 from cxh at eecs.berkeley.edu  2009-03-12 18:00 -------
I believe I;ve fixed this.

For some reason, my previous comment to this bug was not emailed to the
kepler-dev list, I think because I attached an attachment.

In that comment, I determined that the problem was because Windows specific
code was setting the text of the buttons using html.  
See "How to Use HTML in Swing Components" at
http://java.sun.com/docs/books/tutorial/uiswing/components/html.html

I tried adjusting ptII/doc/default.css to set the body color to black:
BODY {
   color: #000000;

but that did not work.  I think the problem is that the text of the
button is not inside a body:
http://sun.calstatela.edu/~cysun/documentation/java/1.5.0-source/j2se/src/share/classes/sun/swing/WindowsPlacesBar.java

has it as:
buttons[i].setText("<html><center>"+folderName+"</center></html>");

One possibility would be to remove the background setting for body
in default.css.  The downside of this is that pages that had different
body background colors would render with those different background
colors.  This is not a huge problem, but we set the background in default.css
for a reason, so we should not unset it.

Another alternative is to get rid of the Windows Places Bar on the left.

http://java.sun.com/j2se/1.5.0/docs/guide/swing/1.5/ suggests:

> 4723745: Metal & Windows FileChooserUI classes cannot be used without
> ShellFolder
> Description:
>
> Since 1.4, the JFileChooser code has too strong a dependence on the native
> layer. An attempt was made to bypass this class for programs that use a
> customized "virtual" filesystem, but the algorithm is not 100% reliable. 
> To toggle this behavior, use the client property FileChooser.useShellFolder,
> for example, to turn off use of the native set this to false:
>
>    jFileChooser.putClientProperty("FileChooser.useShellFolder",
>                 Boolean.FALSE);

My solution was to add an _open() method to HTMLViewer that saves the
previous background color, sets the background to the value of a property,
"ToolBar.shadow", and then restores the original background color.
This might work, so I've checked in.  Worst case, we could make
this conditional for Windows.

I'll submit the test case to Sun as a bug.