Products and Services
Downloads
Store
Support
Education
Partners
About
Oracle Technology Network
crollBarUI", packageName + "BSWindowsScrollBarUI"
};
table.putDefaults(uiDefaults);
}
}
protected void initSystemColorDefaults(UIDefaults table) {
}
protected void initComponentDefaults(UIDefaults table) {
if (getClass().getClassLoader() != null) {
Object[] defaults = {
"ClassLoader", getClass().getClassLoader()
};
table.putDefaults(defaults);
}
if (true) {
Color cNoSh = table.getColor("controlShadow");
Color cDkSh = table.getColor("controlDkShadow");
Color cNoHi = table.getColor("controlHighlight");
Color cLtHi = table.getColor("controlLtHighlight");
Border loweredBevelBorder = new BasicBorders.FieldBorder(cNoSh, cDkSh,cNoHi, cLtHi);
Border raisedBevelBorder = new BasicBorders.FieldBorder(cNoHi, cLtHi,cNoSh, cDkSh);
Border raisedCellBevelBorder = new BasicBorders.FieldBorder(cLtHi, cNoHi,cNoSh, cDkSh);
Border pumBorder = new BorderUIResource.CompoundBorderUIResource(raisedBevelBorder, new EmptyBorder(1,1, 1, 1));
Border buttonBorder = new BorderUIResource.CompoundBorderUIResource(table.getBorder("ToggleButton.border"), new EmptyBorder(1, 1, 1, 1));
Object[] defaults = {
"ScrollPane.border" , loweredBevelBorder,
"Table.scrollPaneBorder", loweredBevelBorder,
"TableHeader.cellBorder", raisedCellBevelBorder,
"PopupMenu.border" , pumBorder,
"Button.border" , buttonBorder
};
table.putDefaults(defaults);
}
}
}
-------------------------------------------------------------------------
package bs.swing.plaf.windows;
import java.awt.Graphics;
import java.awt.Rectangle;
import javax.swing.JComponent;
import javax.swing.plaf.ComponentUI;
import javax.swing.plaf.basic.BasicScrollBarUI;
/**
* BSWindowsScrollBarUI.
* <p>
* @version 1.0
* @author <withheld>
* </p>
*/
public class BSWindowsScrollBarUI extends BasicScrollBarUI {
public static ComponentUI createUI(JComponent c) {
return new BSWindowsScrollBarUI();
}
public BSWindowsScrollBarUI() {
super();
}
protected void paintTrack(Graphics g, JComponent c, Rectangle trackBounds) {
g.setColor(trackColor);
g.fillRect(trackBounds.x, trackBounds.y, trackBounds.width,trackBounds.height);
g.setColor(trackColor.brighter());
if (trackBounds.width > trackBounds.height) {
for (int ix = trackBounds.x - trackBounds.height; ix < trackBounds.x +trackBounds.width; ix+=2) {
g.drawLine(ix, trackBounds.y, ix + trackBounds.height, trackBounds.y +trackBounds.height);
}
} else {
for (int iy = trackBounds.y - trackBounds.width; iy < trackBounds.y +trackBounds.height; iy+=2) {
g.drawLine(trackBounds.x, iy, trackBounds.x + trackBounds.width, iy +trackBounds.width);
}
}
if(trackHighlight == DECREASE_HIGHLIGHT) {
paintDecreaseHighlight(g);
}
else if(trackHighlight == INCREASE_HIGHLIGHT) {
paintIncreaseHighlight(g);
}
}
}
-------------------------------------------------------------------------
(Review ID: 99529)
======================================================================
ck.prasad@eng 2001-04-05Selected items:
Problem description from Customer
----------------------------------
This is from JDK 1.4 beta 54 on Windows NT 4.0.
java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b54)
Java HotSpot(TM) Client VM (build B54, mixed mode)
From the above description Item 20 says :
20. Selected items in lists and trees have a yellow focus outline
in the Windows Look And Feel while Windows paints them with
a grey/dark grey dashed/dotted outline.
It complains that the focus indicator for JList and JTree in
the Windows L&F is a yellow outline, rather than a dashed outline
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
as it is for real Windows apps. The same is also true for JTable.
Name: krC82822 Date: 05/31/2001
java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)
The swing dialogs in JDK1.4 BETA still don't use the default
windows font when Windows LNF is used. Since one of the goals
JDK 1.4 is to be indistinguishable from native windows
applications when using windows LNF, this should be fixed.
(Review ID: 125074)
======================================================================
Name: rlT66838 Date: 09/02/99
At the moment, Microsoft Windows is the platform that most end users
use to run desktop GUI applications. As I understand it, the concept
behind Java is to make applications platform-independent; in order to
be able to nevertheless create programs that have the (native) "look
and feel" that most (Windows) users expect, Sun has created the
"Windows Look And Feel".
However, I have found (and others probably have as well) that there
are still many problems in the current implementation of the Windows
LAF that make it difficult to actually write applications that
look and feel like real, native Windows ones (and I'm not even
talking about speed/performance here). In order to help you
improve the situation, I've taken the time to examine and
describe some of the issues. A lot of them may appear to
be minor ones but a) the sheer number turns them into one big
problem and b) even little things that are somehow "wrong"
can quickly make the user think that he or she is dealing
with an "unprofessional" application. As there is no way to
attach images to bug reports, I have not included screenshots
that demonstrate the issues. However, in case you really need
any, I am willing to create and send them by e-mail.
Here are some of the problems that I have noticed
(the list does not claim to be complete); they have
intentionally been submitted as one bug report rather
than many individual ones:
Fonts:
01. By far the most obvious difference between the Swing Windows
Look And Feel and the "real" Windows appearance is the font
that is used almost everywhere where there is text to paint.
This includes components such as labels, text fields, menu
items, tabs, check boxes, radio buttons etc. I'm sure that
you're aware of this difference and the fact that this hasn't
been fixed yet suggests that there might be a technical
problem. However, since Java2 seems to be able to use all
installed fonts, why isn't the Windows system font being
used? According to the display/appearance settings panel,
it is "MS Sans Serif (Western)" size 8. Since this can be
changed by the user, the Windows LAF should probably find
a way to determine the current system font, at least once,
at startup. In any case, Swing's current choice which
seems to be FontUIResource("Dialog", Font.PLAIN, 12),
makes it obvious to any user that they're not dealing
with a real Windows application.
Colours:
02. By default, Swing seems to use white as the background colour
for the interior of controls such as check boxes, radio buttons
and combo boxes. However, in Windows, these are painted using
the (configurable) "window" colour. If a user changes the
"window" system colour from the default white to something
else, Swing check boxes/radio buttons/combo boxes start looking
different from their Windows counterparts.
03. For scrollbar "channels", Windows uses a pattern of
alternating grey and white pixels. Swing, however, uses
a solid grey colour. For users who have changed the "window"
system colour to grey, this can become a problem because in
case the scroll pane contains a component that uses "window"
as the background colour too (such as JTree), there will be
no visual separation between the contained component and
the scrollbar channel. This is both ugly and irritating.
Resizable windows:
04. In Swing, Resizable windows such as the JFileChooser or
(resizable) JInternalFrames do not have the "draggable"
texture in the lower right corners that the original
Windows ones have.
Buttons:
05. The default button size in Windows is 75x23 pixels.
Swing ignores this; for example, the "OK" button in a
JOptionPane is 39x27 pixels big, and in the JFileChooser
dialogue, both the "OK" and the "Cancel" button are
73x27 pixels big.
06. Toolbar buttons (icon buttons) should not have
a painted focus outline.
Text components:
07. In Windows, text components that are not editable have
a blinking caret just as editable ones (although you
cannot type anything). In Swing, there is no caret.
This makes navigation and text selection very difficult.
08. In a text field, there should be a margin of one pixel
between the border and the caret if it's at the first
position, just like in Windows. Otherwise, it's hard
to separate the caret from the border.
09. The marked selection in a text field should not cover the
complete text field interior around the selected text as
it does in Swing. Instead, there should be a margin of
Insets(1, 1, 2, 1) as in Windows.
Check boxes:
10. The disabled look of check boxes is different
from Windows (grey/white outline vs. black/white outline).
Menus:
11. Swing menu bars are two pixels higher than Windows menu bars.
12. The colour of JMenu components does not change to grey when
the window they're in is deactivated.
13. JMenus don't have the Windows 98 rollover effect.
14. Swing paints the white and grey outline of popup menus using
a width of two pixels. Windows only uses one pixel.
15. The width of the space to the left/right of the widest menu
item in the menu is not the same as in Windows. Moreover,
Swing menu items are four pixels higher than the real ones.
There are also differences concerning the space between
a) border/[checkbox|bullet]/name and b) name/mnemonic/border.
16. The bullet (o) and arrow (>) icons/drawings aren't the same
as in Windows either although the average user probably
won't notice.
17. Popup menus should disappear/be closed when the window
they're in is deactivated.
Tabbed panes:
18. Swing tabs in tabbed panes are two pixels higher than Windows tabs.
Moreover, the active tab exceeds the "base line" at the bottom
by one pixel.
Split panes:
19. The arrows on a "one touch expandable" divider are too big.
Selected items:
20. Selected items in lists and trees have a yellow focus outline
in the Windows Look And Feel while Windows paints them with
a grey/dark grey dashed/dotted outline.
Tables:
21. Swing Table headers are four pixels higher than Windows
table headers. There is also an inaccuracy concerning
the outline colours (grey vs. black).
Sliders:
22. The disabled look of the JSlider knob is different
from Windows (grey vs. white/grey).
Scroll bars:
23. The placement of the arrows on Swing scroll bars is
one pixel different from the way it's done in Windows.
This might seem like a rather minor issue but it is
quite noticeable.
Internal frames:
24. The title text of internal frames is placed two pixels
lower than the original Windows title. Also, there is
no colour transition in the title bar like the one
Windows 98 offers... :)
25. The "minimize" icon is not exactly the same as in Windows.
Folder icons:
26. The folder icons used in JTree and JFileChooser look
different from the ones Windows (98) uses (in Explorer,
for example).
File chooser:
27. The Swing file chooser is too big. Its size is 508x327 pixels
which is considerably bigger than the original Windows size
which is just 428x266 pixels.
28. The size of the Swing toolbar buttons (25x25) is different
from the original size (23x22).
29. All files have the same icon. I assume that this is a design
decision rather than a bug because access to the icons that
are registered with each file type is a system-dependent
feature. If it's intentional that only the default icon
(the piece of paper with a Windows logo) is used, it should
at least have the right colour: white - not transparent.
I assume that it is another design decision to make the
icon transparent to simplify painting of the "selected" status.
However, if the "window" system colour is not white, the
file icon is not white anymore either (which it should be).
30. Selected file items should only have the outline painted
around the file name (which is what Windows does), not the
file name AND the icon. There still needs to be some kind
of visual transformation of the icon, though (using the
"selected" colour).
31. In Windows, the "Open" and "Cancel" buttons do not have
tooltips associated with them.
32. There are still a lot of other issues that make the
JFileChooser look and feel different from the original
AWT FileDialog. Some are related to OS specific features
(such as the -missing- help button), some are related to
changes to the Windows GUI (three new toolbar icons were
introduced with the Internet Explorer 5 upgrade) and
others are related to general JFileChooser incapabilities.
These include: a "list view" button that's always disabled,
a missing "table view" (Name, Size, Type, Modified, Attributes)
and missing multi-file selection.
Colour chooser:
33. This component doesn't even attempt to adapt to the
Windows colour chooser look/feel. Whether there is
a real need to, is debatable, of course.
Tooltips:
34. Swing tooltips are six pixels higher than Windows tooltips.
New widgets:
35. ...and finally, there are some new widgets (or new
variations of existing ones) that Microsoft has introduced
during the last few years. A look at Office 2000, for
example, reveals that there are some that Swing doesn't
offer (which makes it a Swing problem rather than a
specific Windows LAF issue; and the productivity gain
of some of MS's new GUI stuff is questionable anyway).
I realize that it's hard to emulate a native look and feel
100% accurately, especially if some of it keeps changing
(Win95->Win98) and if many things rely on system features
that a pure Java package doesn't have access to. Always
using the Java Look And Feel instead might be a better
solution - but as Sun has decided to provide "native"
look and feels too, the Windows LAF has become part
of the Windows release of Java2; and since it's there,
it deserves to be done "right".
Best regards,
Henrik
(Review ID: 94575)
======================================================================
Name: krT82822 Date: 10/07/99
If I set the font for NT, my application's JMenuBar still shows
a san-serif type font, even if I restart it. This goes for text in dialogs etc. The font color isn't used either, seems like
all of this is hardcoded?
---------
(see also 4129288)
(Review ID: 94073)
======================================================================
Name: krT82822 Date: 12/19/99
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)
To see the bugs you have to first change the default colors using
your Windows "Display Properties" dialog. Choose the scheme 'Lilac'.
The first bug is in menus. First go to any native Windows application
and click on a menu. When the menu drops down, observe the colors
of the edge of the menu and also the thickness of the edge. The
edge is very thin (1 pixel?) and the color is light blue. Now start
SwingSet and click on the File menu. The edge of the menu pane is
too think (3 pixels?) and is white in color, not light blue. (In fact
in many places, for example Group Box, the 3D highlight color is white
when it should be light blue.)
Another bug is the colors used for disabled labels. Go to SwingSet
and click on the File menu. The colors of the grayed out menu items
are all wrong.
These bugs make Java based applications the "odd man out" on Windows.
(Review ID: 99200)
======================================================================
Name: krT82822 Date: 01/24/2000
java version "1.2.2"
Classic VM (build JDK-1.2.2-001, native threads, symcjit)
None needed create any bevel border an set the look and feel to windows.
Swing always makes the highlight White. If you set your windows colors
to dark gray then the highlight should be light gray. The buttons work
fine. But, Menu drop downs/Popups/JscrollPane/BevelBorders stay white.
I bet if check what the button's do verse these other objects you will
find an overlook in color setting.
Thanks.....
(Review ID: 100302)
======================================================================
Name: krT82822 Date: 01/24/2000
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-I)
Java HotSpot(TM) Client VM (build 1.3-I, mixed mode)
Windows look and feel has unacceptable look defects
notably the borders of various JComponent subclasses
and the background pattern of JScrollBar.
Below I provide the source code of my custom Windows LAF
(based on Sun's Windows LAF) fixing the most important
look defects. The fixes can be easily migrated into Sun's
Windows LAF and have been tested thorougly.
(I do not provide a single bug report for each look defect
as there are too many).
-------------------------------------------------------------------------
package bs.swing.plaf.windows;
import java.awt.Color;
import javax.swing.LookAndFeel;
import javax.swing.UIDefaults;
import javax.swing.border.Border;
import javax.swing.border.EmptyBorder;
import javax.swing.plaf.BorderUIResource;
import javax.swing.plaf.basic.BasicBorders;
import javax.swing.plaf.basic.BasicLookAndFeel;
/**
* Implements the Windows 95 Look and Feel.
* Is build on top of Sun's implementation of the Windows 95 Look And Feel
* (com.sun.java.swing.plaf.windows.WindowsLookAndFeel).
* <p>
* Fixes cosmetic defects (ScrollBarUI and Borders).
* <p>
* Inheritance is achieved by peering instead of by subclassing.
* (UI classes not implemented specifically for My Windows fixes will
* default to those implemented in Sun's Windows).
* <p>
* @version 1.0
* @author Bruno Stuessi
* </p>
*/
public class BSWindowsLookAndFeel extends BasicLookAndFeel {
private LookAndFeel windowsLAF;
public BSWindowsLookAndFeel() {
super();
try {
String s = "com.sun.java.swing.plaf.windows.WindowsLookAndFeel";
windowsLAF = (LookAndFeel) Class.forName(s).newInstance();
} catch (Exception e) {
throw new RuntimeException(e.toString());
}
}
public String getName() {
return "Windows";
}
public String getDescription() {
return "The Microsoft Windows Look and Feel";
}
public String getID() {
return "Windows";
}
public boolean isNativeLookAndFeel() {
return windowsLAF.isNativeLookAndFeel();
}
public boolean isSupportedLookAndFeel() {
return windowsLAF.isSupportedLookAndFeel();
}
public UIDefaults getDefaults() {
UIDefaults table = windowsLAF.getDefaults();
initClassDefaults(table);
initSystemColorDefaults(table);
initComponentDefaults(table);
return table;
}
protected void initClassDefaults(UIDefaults table) {
if (true) {
String packageName = "bs.swing.plaf.windows.";
Object[] uiDefaults = {
"S
CONVERTED DATA
BugTraq+ Release Management Values
COMMIT TO FIX:
merlin
FIXED IN:
merlin-beta2
INTEGRATED IN:
merlin-beta2
WORK AROUND
Name: krT82822 Date: 01/24/2000
Well, you could get the hightlight color off the buttons and apply to
every object that has the problem. But I have not tried this.
(Review ID: 100302)
======================================================================
PUBLIC COMMENTS
.
EVALUATION
The submitter is absolutely correct, we have not given enough quality time to the windows laf.
scott.violet@eng 1999-09-23
The submitter provides an excellent and very detailed report. We will be using this report to drive the improvements to the Windows LAF for the next major revion of the JDK.
mark.davidson@Eng 2000-04-27
This bug has 208 JDC votes (as of May 11, 2001) so I suppose I should make a comment on how this bug is being addressed.
The good news is that we have taken a fresh look at the Windows LAF for 1.4 and have addressed many of your concerns. The biggest win has been the support for native desktop properties. The Windows LAF will use the system colors and fonts and will recognize and update these properties when the properties in Windows will change.
The second major win is that it will support new features in Windows 2000 like mnemonic hiding and menu animation. We are still trying to resolve some issues related to the transition effects so it may not make it into Beta. The new Win LAF will detect what version of Windows it's running on and enable the visual effects for that platform (if the desktop properties enable them of course).
The third major improvement has been in JFileChooser. The chooser will look at the shell folder and only expose the drives that have valid mappings. It will also show Explorer items like My Computer, Network Neighbourhood and Desktop, etc...
We have also implemented menu rollover effects and rollover toolbar effects and have paid much closer attention to the borders of the components, sizes and widths.
We still have some work to go but when you get ahold of the 1.4-beta (due very soon now) you will see a great improvement of the Windows LAF from 1.3.
For the next beta refresh we plan on taking another pass over this bug report and see if we have addressed all the issues.
For more details see
mark.davidson@Eng 2001-05-11
I'm going to close out this bug as fixed and integrated. My last set of changes on monday seems to have addressed many of the remaining issues. I'm quite satisfied that the Windows LAF has been sufficiently improved in beta 2.
I'm not sure if it's been mentioned anywhere but I'll reiterate it here: The rollover toolbar support is enabled in 1.4.beta. To enable it, set the client property "JToolBar.isRollover" to TRUE on the toolbar that you want the rollover.
For example:
toolbar.putClientProperty("JToolBar.isRollover", Boolean.TRUE);
This should really be implemented as a public method like setRollover(boolean)/isRollover() on JTooBar. It's kind of late for API changes but I'm sure we can squeek this in for FCS.
mark.davidson@Eng 2001-07-11