.





At the moment,  customer  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:

 customer . 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  customer  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) 
======================================================================




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)
======================================================================




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)
======================================================================




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)
======================================================================




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  customer  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
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)
======================================================================

  xxxxx@xxxxx   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.





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)
======================================================================
Posted Date : 2005-07-22 03:26:06.0

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)
======================================================================

The submitter is absolutely correct, we have not given enough quality time to the windows laf.
  xxxxx@xxxxx   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.
  xxxxx@xxxxx   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 http://java.sun.com/products/jfc/tsc/articles/merlin/windows/index.html

  xxxxx@xxxxx   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.
  xxxxx@xxxxx   2001-07-11

See also bugs 4256307, 4146858, and 4133908.

This is a GREAT bug report as it has the kind of detail that a developer loves
to see
when working on fixing a bug (I should know, I'm a GUI developer myself).
I'd like to add that for JMenus the color used for the border outline differs
from
the native Windows menus. Swing uses white for the upper edge of the raised
bevel while Windows uses a shade of the menu color itself (you can see this
really
easily if setting the desktop color scheme to "Desert"). This
difference
would be less noticable if the border width if fixed(ie changes from 2 to 1).

Wow.  Lots of stuff.  I hope Sun gets all this stuff fixed - we're planning on
writing a completely Java application that ALSO has the Windows 2000 logo - and
we've found some problems related to this that would keep us from qualifying
(these are mostly accessibility issues): system scrollbar sizes aren't
regarded; internal windows don't use the caption size system setting; radio
buttons are cut in half in high-contrast mode (because of the shadows), menus
don't have outlines in high-contrast black mode, and disable items of any kind
disappear in high-constrast black.

Great bug report.I would like to add the following:

In the JFileChooser, Windows provides a Popup menu when you 
right click over the center list of files. This is 
conspicuously missing in JFileChooser.

The JFileChooser's center panel is supposed to be 
multicolumn. It also needs to sort in a non case-sensitive 
manner.

When dragging the Print Dialog over the other windows of an 
application, they are not redrawn. I know why this is and 
have a workaround. Email me if you want it!

I think one of the main problems is that Windows L&F keeps 
changing and evolving. Microsoft is obviously doing it to 
have an ever new and exciting L&F, but in the process they 
are thorn to the Java Platform's efforts on pluggable L&F. 
I am sure they are very happy about this!

See also: bugs 4199362 :( and 4302130.

Pretty detailed bug report, esp. down to the pixel level.  
Didn't notice much of this stuff until I read this bug 
report:)  Our users don't seem to notice/mind many of the 
problems noted here, but most don't alter there desktop 
themes...

One of the most noticable deviations is the lack of 
*default* mouseover bevel bordering on JToolbar & JMenu.  
Here's the quick fix for this (parts skimmed from forums):

JMenu (where MenuBar is your JMenu):
// Make menu items pop ala IE/Win98 
Border raisedbevel = BorderFactory.createRaisedBevelBorder
();
for (int i=0; i < MenuBar.getMenuCount(); i++) {
    final JMenu jb = MenuBar.getMenu(i);
    jb.setBorder(raisedbevel);
    jb.addMouseListener(new MouseAdapter() { 
        public void mouseEntered(MouseEvent e) {
            if (jb.isEnabled()) jb.setBorderPainted(true);
        } 
        public void mouseExited(MouseEvent e) { 
            jb.setBorderPainted(false);
        } 
    }); 
}

JToolbar (where ToolBar is your JToolBar):
for (int i=0; i < ToolBar.getComponentCount(); i++) {
    Component c = ToolBar.getComponentAtIndex(i);
    if (c instanceof JButton) {
        final JButton jb = (JButton)c; 
        jb.setBorderPainted(false);
        jb.addMouseListener(new MouseAdapter() { 
            public void mouseEntered(MouseEvent e) { 
                if (jb.isEnabled()) jb.setBorderPainted
(true);
            } 
            public void mouseExited(MouseEvent e) { 
                jb.setBorderPainted(false);
            } 
        }); 
    }
}

Good luck,
Chris

Another Win32 feature missing from Swing's Windows L&F:
in a JFileChooser, the user can't type the first few letters
of a
file to scroll the list to that file/icon.  (Users must
either drag
the scrollbar until they find it, or type the entire name in
the
entry field, neither of which works very well with many
files.)

This is not a bug, it is a feature.
You cannot have Windows look&feel if it is no native 
Windows GUI. Even many VB applications show a "non-Windows" 
look&feel.
You cannot get a Windows look&feel on windows and a Motif 
look&feel on X with the same program. Since the native GUI 
APIs differ this is impossible to achieve.
If I think on all the Windows common controls I can only 
laugh about a Java program trying to behave like a Windows 
program. Forget it - or you will end up with a GUI that 
looks like Windows but drives the users crazy because of 
all the details that don't behave like windows.
"Be as you are": If you use Java then use a Java look&feel.

It is trivially easy to check System.getProperty("os.name") 
and set the LAF accordingly, so that an application can 
look like Windows on Windows, Mac on Mac, and X on Unix. 
*IF* we had a good set of standard LAF classes.

"It is trivially easy to check System.getProperty
("os.name") 
and set the LAF accordingly"

No, it's actually even easier. Just call 
getSystemLookAndFeelClassName() in javax.swing.UIManager 
and it will tell you exactly what class to use to get the 
system look and feel for whatever OS you're on. Pass that 
as the parameter to setLookAndFeel(String className) in the 
same class and you're set.

One recurring theme here is that things are taller than 
what they are supposed to emulate.  My guess is that the 
tendency (to make things taller) came from the X 
window/Motif world, where everything is twice as tall as 
necessary, and you need a 21" monitor to get anything 
done.  Urgly and pathetic.

i am *somehow* not so positive to submitter. Complete W&F
OK. but till when. For example Window tooltip can be what u
want. this is a simple borderless control nothing more. In
Delphi it inherits CustomControl, so.
For me Windows L&F is ok. 

One more thing, the vertical lines in a JTree do not align 
with the little plus signs inside the small retangles used 
to expand/collapse tree nodes.  They are one pixel off to 
the left.

I absolutely and totally agree with this bug and want it 
fixed tho I'd put my VOTES on 4337823 (fillRect has severe 
synchronization bug in Java 2) which is currently IMHO the 
most accute Java VM bug. There are several small issues 
like one-pixel margins or small collor differences that 
stand out but and YES they should be fixed and YES they 
matter a lot in making it really look and feel like Windows 
but more importantly, I think, are the big things.. Things 
like the file pickers which are absolute crap! They look 
nothing like the real thing and they have severe alignment 
and size bugs, wrong icons etc. etc. Also, when you click-
and-a-half on a name to rename a file, for instance, the 
editor is totally different than in the real thing. Other 
things that very clearly stand out are wrong default icons 
in tree views, wrong colors on highlights (the current L&F 
often uses a solid yellow outline) etc.. Some of these 
could be very quickly fixed I think...

See also bug 4357012. In the "Save As" dialog, clicking on a folder shouldn't replace the typed name with 
the folder name, but it does.

I totally agree to that bug report. If Java wants to look 
like Windows, it has to be 100% and not 99.9%. It's really 
a problem to sell a software to Windows fanatics, if it is 
not 100% like Windows. In addition, Swing is damned slow, 
even in 1.3.1. So what I think is: Is there anyone that is 
willing to use that Swing Windows PLAF, that is not running 
Windows? I mean, I cannot think of Solaris users that like 
to have an application running looking like Windows. So, if 
I think over it, wouldn't it be better to change the 
implementation of PLAF in a way that if Solaris is running 
and a user wants to have Windows PLAF, the current 
implementation is used, and if Windows IS running, the 
native elements are used? I think this would be possible 
and would help both problems, 100% correct LAF, and better 
performance, too.

Why doesn't the Windows VM internaly call Windows APIs 
(e.g. Microsoft CommonDialogs APIs) instead of trying to 
emulate these calls. As I understand it, WIndowsLookAndFeel 
is only implemented on Windows anyway, so why not make it 
do some funny things internally and call the WIn32 API 
where necessary.

I'm not suggesting Visual J++ here, but why re-implemnt a 
file-selector excatly like one supplied with the operating 
system? This would also side-step the problem of Microsoft 
constantly changing the Windows look and feel.

Least work to be done is to remove a lot of the hardcoding 
of font sizes and colors and add more options to the plaf.
At least resize the menus and allow choices of color for 
the tick marks on a JSlider  

Perhaps the entire "emulate" idea is not so great.
I would like my FileChooser to BE a FileChooser, not be a 
more or less complete replica of whatever OS was the target 
when the java runtime shipped. If I install extensions to 
my OS, I would like them to show up in all applications - 
if Java doesn't not support the user's gadgets & extensions 
(the mouse wheel springs to mind) the user is likely to 
prefer non-java programs...

On windows, a text field has a popup menu with <UNDO, CUT, COPY, PASTE,
DELETE, SELECTALL> functions.  This is not implemented by the JTextArea or JTextField

The windows MenuBar is implemented to perform like a horizontal FlowLayout.
When the window is resized below the width of the menubar, it wraps.

In addition, the system menu is in the navigation path when navigating through
 the menubar via the arrow keys.  This will probably be impossible to duplicate
unless JMenuBar goes back to native menubar instead of just painting one.

Also, is there any particular reason why UIManager can't listen to desktop LAF
changes so that when a user changes the desktop lookand feel, a java application
can choose to response dynamically to this rather than only at startup?

It might be good to point out that TCL/TK and its 
replication of actual windows look and feel is 
extraordinarily precise.  Scriptics has even made it a 
point to call windows components (like FileChooser) when 
necessary.  TCL/TK offers an alternative to Java if you are 
interested in a more windows-like GUI.

I am absolutely delighted by these bug reports. I cannot stand using the Windows L&F in Windows 98 (I 
use 
Metal) because of these stupid differences which frankly just confuse me, and double the time it takes to 
get anything done. If you open a file-chooser, you expect it to behave EXACTLY like a windows 
filechooser. 
Like so exactly you can't tell the difference. I can live with no icon support, but I really can't stand being 
able to see hidden files by default all the time. I keep finding myself using the AWT to get what I want. I 
know this wasn't the original plan for pluggable look and feel, but I think it would be much better if only 
two 
were provided for a given JVM: Metal (which works well for the most part), and the Native L&F. The Native 
L&F should be implemented using Native calls where possible, (rather like the AWT) so that when you ask 
for 
a file open dialog box, you get the system's normal version etc.

May I add to the bug report that when you have a menu open, you should be able to close it by clicking 
ANYWHERE in the window. This is a seriously annoying flaw.

Again, this is acceptable in Metal (beacuse it generally behaves in its own way), but NOT in the Windows 
L&F.

JInternalFrame when maximized do not look like real Windows 
apps. When maximized, the JInternalFrame's title should 
merge with JFrame's title, etc. 

I agree with the comments by mnd999 above that we should
simply call native windows APIs for native windows. It would
probably save a lot of time and effort and eliminate a lot
of bugs, plus the applications built using the WinLAF will
PERFORM much better. Alternatively (but this won't save
development time and effort), provide an emulated
WinLAF and a native WinLAF. I know which one I'd use.

I think itīs not necessary to implement the windows look 
and feel with the Win32 API. Why not to use the java AWT 
instead?

Because the Java AWT *IS* native Win32. :) It's not at all 
impossible to imitate the Windows Look and Feel - lots of 
applications do that. For some reason the Java Windows L&F 
imitation is just a little half assed.

in a jinternalframe between the top right icons to minimize
and maximize the window there isn't any space. instead the
icon to close the window is separated from the first two.

some bugs about jfilechooser lnf in jdk 1.4 beta.

1) the "files of type" jcomboxbox should have the arrow big
as the one in the scrollbars. i've verified that the
scrollbars resizes themselves according to user prefs. so
why comboboxes does not.

2) tooltips for the various buttons are missing

3) the big icons on the left: the documents dir of the user
should be called "my documents" and not "documents and
settings". and the icon should be similar to a folder, not
the same as "my computer"

4) in the native windows file chooser i can delete a file
pressing "delete" button

5) i click a filename to rename it, then i can type the name
i want: in this situation the icon should not be selected.
also, if the filename is long, i should see the start of the
filename and not the end.

6) the native windows file chooser has a "last folder
visited" icon near the up arrow (parent directory)

i can detach a jtoolbar from the window which contains it.
the native windows toolbars, when detached, have a border
(caption?) that is different from the one in normal windows.
its smaller, and has only the button to close it (the top
right x). it hasn't minimize/maximize icons.
instead swing uses the same caption for normal windows and 
floating toolbars.

the dottet line in a button which has the focus is a little
different form the real windows one. 

The Win LAF in 1.4 is indeed much better.  But of course, 
Microsoft is going to release a new GUI with WinXP, and we 
will be stuck with non-native look&feel again.  Even on 
Win2K there are some subtle details that Swing fails to 
emulate perfectly, (e.g. the degrade effect in the title 
bar is blocky in internal frames).

Maybe the new AWT Native Interface could allow you to use 
native rendering for many components, so you are not forced 
to a new massive update every time Windows changes?  And 
this is also true for the Motif UI, because not all Motifs 
are identical...

The JDK 1.4 beta Windows L&F toolbar rollovers look nice, 
but they don't work with JToggleButton -- the JToggleButton 
doesn't display a toggled state, as does a non-rollover 
toolbar.

I am glad Sun is fixing this in Swing.  i prefer Sun to 
make the various L&F's available on many plaftorms.  AWT is 
available (for now at least) if you really need to use the 
native components for some reason, but I REALLY prefer 
having it implemented in pure Java as far as possible in 
Swing.  I think that keeping up with the L&F as things 
change is just part of the cost of doing business.  I (and 
may other it appears) would love to help out as new things 
come up or as bugs are reported.  Please continue to refine 
the JFileChooser Dialog (rename and tooltips).  Also, 
please consider changing JOption Pane so the multiple 
custom choice dialog uses buttons instead of a drop down 
list.  Also, if cancel is not available please get rid of 
the X in the JOption Pane.  Thanks, and hey Guys, really 
good job fixing most of these things.  Please keep up the 
good work, it's appreciated.  And Henrik, good bug report.

I would like SUN to re-evalute the Java GUI strategy:

1) Create an AWT and Swing version of the same application 
and test it on a focus group.
2) Concentrate on the GUI toolkit that the users prefer.

Jjesper: you don't get it. The reason Swing exists is that 
AWT is the least common denominator and as such, not 
enough. You can't create a tabbed pane, a table or a tree 
with AWT because AWT only contains widgets that exist on 
all platforms. This is the very reason why Swing was 
created - to provide rich widgets on all platforms. In 
order to get that, they had to be lightweight drawn by 
Java, not native widgets. Swing is there to provide what 
AWT can't provide. Swing builds on top of AWT - just check 
the inheritance tree, event handlers etc. It's not a matter 
of picking one over the other.

I'm running Window XP and I suspect it has a pluggable L&F 
although it is not completely enabled. I feel that 
Microsoft will bury you if you try match their L&F simply 
because they have so much more money to spend and they 
change their L&F frequently (With a plugable L&F they will 
change it more frequently). I think there are smarter ways 
to use Sun's limited resources than to ask it to match the 
MS L&F. I think keeping up with the MS L&F could be a trap 
to drain resource. An arms race that you will never win 
against MS. I think the solution is to create a xml 
interface between applications and GUIs (like xul only 
better) that allows people who want the MS L&F to use the 
MS client api that understands the same xml instructions. I 
think a new kind of browser could be built that used xml 
that could eventually replace the html browser. Maybe this 
is the xform effort, I'm not sure. I think Sun should spend 
more time creating a clean (ie xml based) layer between the 
GUI and the rest of the application; the way an html 
browser is separate from the html server. (I'm sorry to go 
off topic. Please reply to me directly so as not to clutter 
this discussion.)

To macpeep:
Java clearly needs some GUI components that are not 
implemented as native widgets on every OS. The tree 
component is one example.
Conventional GUI design wisdom says that consistency is 
very important: The question I am asking is whether it is 
possible to create successful software with "lightweight" 
non-standard or slighty off-standard GUI elements. Is it?

Fixing JFileChooser should be easy. JNI allows Java code to 
call native code, which on Windows assumes the form of 
DLLs. Guess what COMDLG32.DLL does?

I second the comment by doogie1036. When I open a file dialog, I want to be able to type part of the name 
and have it jump to the file icon, just like it does in Windows. This is a very powerful and convenient 
feature, and I really miss it in a Java application. This behavior shows up in many Windows combo boxes, 
selectable lists, and non-editable tables as well. Perhaps this should be a common property of those classes 
that users can enable. 

I got a message from jdc-webmaster@java.sun.com saying that 
this bug had been closed, but when I look here it is still 
shown as "In progress". It looks like all they did was 
clear all the votes.

Nice to hear this is fixed.  I haven't looked at the pre-
release yet, but if all is as asveritsed the we should b e 
ok.  Now the Swing team needs to start working on 
supporting WindowsXP themes :) :)

Related bug: 4420843

JFailChooser focus is not painted when use the Windows Look and Fell in J2SKD1.4.02