Bug #3801
closedopen dialog, common places pane has white box instead of text
0%
Description
XP Pro x64 SP2, Java 1.6.0_11, Kepler 1.0.0 from kepler-project.org.
When I go to File->Open File..., the common places pane on the left has five icons and five white boxes where the icon labels are supposed to be.
Image at the URL.
Files
| HTMLCSSWindowsFileChooserBug.zip (1.6 KB) HTMLCSSWindowsFileChooserBug.zip | |||
| FileBrowserWhiteBoxes.png (22.6 KB) FileBrowserWhiteBoxes.png |
Related issues
Updated by Christopher Brooks almost 16 years ago
I can reproduce this but in the Ptolemy II devel tree, so it is not Kepler
specific. Running $PTII/bin/vergil will do it under Windows 2000 Server with
both Java 1.5.0_17 and 1.6.0_05.
Running java -classpath . ptolemy.vergil.VergilApplication
and then "File -> Open" will do it.
Interestingly, the plotter does not have this bug, even though both
the Plotter and Vergil use ptolemy.gui.Top and JFileChooser.
There is this Sun bug, which is close, but not totally the problem:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6548613
"Windows JFileChooser missing "My Recent Documents" in dropdown"
Updated by Christopher Brooks almost 16 years ago
The whiteboxes in the Windows file browser dialog only occur in
the HTML Viewer.
This command does not have the bug under Java 1.5.0_17 with
Ptolemy II 5.0.1, but does have it with Java 1.5.0_17 with
Ptolemy II 6.0.2, 7.0.1 and the svn head:
java -classpath "." ptolemy.vergil.VergilApplication doc/help.htm
The problem goes away if I comment out the stylesheet code in
ptolemy.actor.gui.HTMLViewer._init():
if (_styleSheetURL != null) {
// If _styleSheetURL is non-null, we set the style sheet
// once and only once. If try to do this in a static initializer,
// then the styles are wrong.
HTMLDocument doc = (HTMLDocument) pane.getDocument();
StyleSheet styleSheet = doc.getStyleSheet();
styleSheet.importStyleSheet(_styleSheetURL);
new HTMLEditorKit().setStyleSheet(styleSheet);
_styleSheetURL = null;
}The problem is that ptII/doc/default.css sets the body to white:
BODY {
background: #ffffff;
which gives us the white boxes. Changing the background changes
the color of the white boxes.
The fix would be to come up with a css file does not set the background
for the JFileBrowser widget.
Updated by Christopher Brooks almost 16 years ago
A class that demonstrates the bug where setting the background of an HTML widget
also affects the background of the text in the Windows Places Bar in the Windows
native file chooser (WindowsFileChooserUI). The Places Bar is the area on the
left that has text for "My Recent Documents", "Desktop", "My Documents",
"My Computer" etc. When we set the BODY style, this affects the background
of the text. It looks like this is a bug in the WindowsPlacesBar code,
if (isXPPlatform) {
buttons[i].setIconTextGap(2);
buttons[i].setMargin(new Insets(2, 2, 2, 2));
buttons[i].setText("<html><center>"+folderName+"</center></html>");
}So, the problem is that the text in the Windows Places Bar is html and setting
the body background color affects it.
I don't have a good solution for this, other than temporarily overridding the
stylesheet in HTMLViewer() when we call _open(). Note that file chooser in
ptolemy.gui.Query might also have this problem.
Updated by Christopher Brooks almost 16 years ago
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.
Updated by Christopher Brooks almost 16 years ago
FWIW, Sun has acknowledged that this is a bug, see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6817933
Updated by Christopher Brooks over 15 years ago
- Windows Server 2003 via Windows Remote Desktop. Java 1.6.0_04 and 1.6.0_14
$PTII/bin/vergil, then File -> Open, then Cancel: HTML window scrambled,
the links on the right of the welcome window are superimposed on the image
on the left.
- Mac OS X, Java 1.5.0_16
$PTII/bin/vergil, then File -> Open.
Move the File Dialog and see that the links on the right are super imposed
on the image on the left.
It appears that calling styleSheet.addRule("body {background: #939393;}");
is what is causing the problem. The reality is that adding any rule
causes the problem on the mac
http://www.gamedev.net/community/forums/topic.asp?topic_id=325758
Brian Hudson writes:
This happens for me as well, even when I actually open a model.
I also get the following exceptions:
Problem setting background color
java.lang.NullPointerException
at ptolemy.actor.gui.HTMLViewer._open(HTMLViewer.java:474)
at ptolemy.gui.Top$FileMenuListener.actionPerformed(Top.java:1139)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown
Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
java.lang.NullPointerException
Problem restoring background color.
at ptolemy.actor.gui.HTMLViewer._open(HTMLViewer.java:488)
at ptolemy.gui.Top$FileMenuListener.actionPerformed(Top.java:1139)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown
Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Charles Shelton writes:
Shelton Charles (CR/RTC3-NA) wrote:
Hi Eveyone,
I'm getting some weird behavior with the Ptolemy Intro Window. When I
launch Ptolemy from Eclipse, the Ptolemy Intro Window appears with the
Ptolemy Logo on the left and some useful links on the right, as normal.But when I click File -> Open to open a model, sometimes after I open a
model, or if I just click Cancel from the file dialog, the Ptolemy Intro
Window redraws itself so that the text with the links is now overlayed
on top of the the Ptolemy logo, and is virtually unreadable. The right
side of the window where the text is supposed to be is empty. This
appears to happened sporadically and is not always repeatable, but I
have been able to reproduce this reliably by launching Ptolemy with no
command line arguments, clicking File -> Open, then clicking Canel in
the file dialog. After the file dialog disappears, the Ptolemy intro
window is redrawn incorectly. This has started happening fairly
recently, so I think this bug is relatively new. Sorry I don't have
more information to go on.By the way, I'm running the latest JDK 1.6.0_14 and using an older
vesion of Eclipse 3.4.0
Updated by Christopher Brooks over 15 years ago
This is fixed in the Ptolemy tree.
I added ptolemy.actor.JFileChooserBugFix and modified ptolemy.gui.Top.
ptolemy.gui.Query and ptolemy.actor.gui.TableauFrame to use it.
Basically, what we do is get the background and save it, set the background
to a value that will work properly, create the JFileChooser and then
in a finally clause restore the original background. This is a hack to
workaround a known Sun bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6817933
I checked that the following work properly with no white boxes and no corruption
of the html widget:
File -> Open
File -> SaveAs
The FileParameter Browse button.
Unfortunately, in Kepler the "Open Archive (KAR)" menu choice still has
white boxes. To fix this, see the comment at the top of JFileChooserBugFix.
Unfortunately, the fixes to File->Open and File->SaveAs will not be visible
in Kepler because Kepler contains a duplicate copy of Top in
ptII/src/ptolemy/gui/Top.java
(Bug 4282 at http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4282)
To see this fix and workaround bug #4282:
cd build-area
ant update-ptolemy -Drev=head
rm ../ptII/src/ptolemy/gui/Top.java
rm ../ptII/target/classes/ptolemy/gui/Top*.class
ant run
rm ../ptII/src/ptolemy/gui/
I'm upgrading the severity of this bug because it makes Kepler look wrong
under Windows when the user opens a file.
Updated by Chad Berkley over 15 years ago
moving to 2.x.y because fixing 4282 will handle most of the problems. fix the gui problems after the 2.0 release.
Updated by Christopher Brooks about 15 years ago
Fixing Bug 4282 fixed most of these problems. The remaining issue is:
the "Open Archive (KAR)" menu choice still has
white boxes. To fix this, see the comment at the top of JFileChooserBugFix.
Updated by Christopher Brooks over 14 years ago
I'm reviewing old bugs.
This bug is still present in the devel tree.
The problems is that under Windows 2003, anything that uses JFileBrowser
will have white boxes in the left hand side. The fix is to use
ptolemy.gui.JFileChooserBugFix
However, this class:
./data-handling/src/org/ecoinformatics/seek/querybuilder/QBApp.java
is in a package that does not import any ptolemy packages, so I'm hesitant
to add the import. If QBApp is fixed or shown to not have the bug then
I believe this bug can be closed.
The following files should be merged from the head to the Kepler release branch.
trunk/modules/gui/src/org/kepler/gui/kar/DeleteArchiveAction.java
trunk/modules/gui/src/org/kepler/gui/kar/ExportArchiveAction.java
trunk/modules/gui/src/org/kepler/gui/kar/OpenArchiveAction.java
trunk/modules/gui/src/org/kepler/gui/kar/RefreshFolderAction.java
trunk/modules/gui/src/org/kepler/gui/kar/ViewManifestAction.java
trunk/modules/module-manager-gui/src/org/kepler/modulemanager/gui/CurrentSuitePanel.java
trunk/modules/gui/src/org/kepler/gui/ComponentLibraryPreferencesTab.java
trunk/modules/actors/src/org/cipres/kepler/NexusFileReader.java
Updated by Derik Barseghian over 14 years ago
It looks like the files in comment#12 still need to be merged into 2.0. I'll do this later this afternoon.
Updated by Derik Barseghian over 14 years ago
merged the 8 files in comment#12 into 2.0, so moving this bug back to 2.X.Y target.
The first part of comment#12 re: QBApp still needs to be addressed.
Updated by Christopher Brooks over 12 years ago
Fixed.
data-handling/src/org/ecoinformatics/seek/querybuilder/QBApp.java was updated:
919 | crawl | 2012-06-11 17:46:03 -0700 (Mon, 11 Jun 2012) | 1 line
use PtFileChooser for OSX dialog boxes (bug 4112)
The way to check this:
cd kepler
find . -name "*.java" > ~/tmp/kj
cat ~/tmp/kj | xargs grep JFileChooser | grep import
Then look for files that import JFileChooser, but do not import JFileChooserBugFix