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