Skip to main content

Nimbus issues

68 replies [Last post]
swpalmer
Offline
Joined: 2003-06-10

Is there a list of known issues with Nimbus?

I just noticed that comboboxes don't have a rollover effect like nearly every other control. But it seems pretty obvious and I don't want to file tons of duplicate bug reports.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
krheinwald
Offline
Joined: 2004-06-25

Richard,

thanks for looking into this!

> > - the grid for the tables is not drawn, even when
> http://bugs.sun.com/view_bug.do?bug_id=6594663

Additionally, gridlines should default to true to match other L&Fs

> In this way, if you use DefaultXXXRenderer, it will
> automatically pick up all the colors, fonts, sizes,
> opacities, etc that the LAF defaults to.

That would be perfect (for me). If the DefaultRenderer sets the UI correctly for the current cell I can simply set the text and icon as required. Most of the fiddling with UIDefaults was to properly set the UI, I wouldn't mind dropping the stripping, although this might even be easier, if getTableCellRendererComponent() sets all the colors, etc for me. ;-)

It sounds like you are tackling a fix long overdue...

> Ok, while this is true, I'm going to see what I can
> do to support more of these keys.

I think it would definitly help if the most widely used values were available as 'read only'.

Klaus

kjordan2001
Offline
Joined: 2008-12-22

I know this is more than a year old, but I still seem to see this problem with Nimbus but not with any other LAF. Is there a workaround for making the toolbar have components expand to the full size of the toolbar now?

mvillarroel
Offline
Joined: 2005-05-01

I totally agree with kjordan2001, I think the toolbar layout problems in nimbus have to be resolved soon. Nimbus is a wonderful LAF, but the toolbar is almost useless.

krheinwald
Offline
Joined: 2004-06-25

Richard,

you can also show that a disabled Jtable does not look any different from a enabled one by adding

jTable1.setEnabled(false);

after

intiComponents();

in my previous example.

Expected behavior is that a disabled component is display dimmed.

Klaus

kleopatra
Offline
Joined: 2003-06-11

>
> you can also show that a disabled Jtable does not
> look any different from a enabled one by adding
>
> jTable1.setEnabled(false);
>

yeah that's a known issue and the fault of DefaultTableCellRenderer - it sets its state incompleted in ignoring the target's enabled property.

>
> Expected behavior is that a disabled component is
> display dimmed.

I would say even a bit more: a disabled component should not react to user interaction in any way - f.i. manipulating columns (sorting, resizing by mouseEvents on the header) should be disabled. The arguable point is who's responsible for keeping the header's enabled property in synch with the table's enablement ;-)

Jeanette

krheinwald
Offline
Joined: 2004-06-25

> yeah that's a known issue and the fault of
> DefaultTableCellRenderer

That also happens for those cells not having a CellRenderer set.

> I would say even a bit more: a disabled component
> should not react to user interaction in any way

That works correctly for the cells, i.e. they are not selectable/editable, but as you said, not for the header. It still reacts to mouse clicks allows changing the sort order.

It seems this is not a Nimbus specific problem, rather a Swing one introduced whith table sorting.

* I just realized the header is painted (partly) correctly, i.e. the font is plain instead of bold, and the columns are not resizable anymore when the surrounding SrollPane is disabled. Kind of makes sense, as the ScrollPane is responsible for displaying the header.

I didn't realize this as I implemented my own TableSorter long time ago whch properly handles the enabled state ;-)

> The arguable point is who's responsible for keeping the
> header's enabled property in synch with the table's
> enablement ;-)

I'd say the ScrollPane should realize this automatically. But even when you explicitly disable the ScrollPane, it is still a bug that the header reacts to mouse clicks.

Klaus

kleopatra
Offline
Joined: 2003-06-11

Klaus,

I split off a new thread, as our discussion is no longer Nimbus specific:

http://forums.java.net/jive/thread.jspa?threadID=32192

Cheers
Jeanette

kleopatra
Offline
Joined: 2003-06-11

ahh ... now I know how the post-multiplication happens: the server keeps telling that the comment was invalid and I keeps hitting the submit button repeatedly ...

so for now I'll clean out the text - any way to cancel the post at all?

Jeanette

Message was edited by: kleopatra

kleopatra
Offline
Joined: 2003-06-11

[deleted yet another duplicate]

Message was edited by: kleopatra

krheinwald
Offline
Joined: 2004-06-25

Richard,

here is the small example you asked for. The seperators do show up, though...

---

import javax.swing.*;

public class ToolBarTest extends javax.swing.JFrame {

public ToolBarTest() {
try {
// UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");
// UIManager.setLookAndFeel("com.sun.java.swing.plaf.motif.MotifLookAndFeel");
// UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
UIManager.setLookAndFeel("sun.swing.plaf.nimbus.NimbusLookAndFeel");
} catch (Exception e) {
e.printStackTrace();
}

initComponents();
}

//
private void initComponents() {

toolBar = new javax.swing.JToolBar();
jButton1 = new javax.swing.JButton();
jSeparator1 = new javax.swing.JToolBar.Separator();
jButton2 = new javax.swing.JButton();
statusBar = new javax.swing.JToolBar();
nJumpsLabel = new javax.swing.JLabel();
statusLabel = new javax.swing.JLabel();
progressBar = new javax.swing.JProgressBar();

setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);

toolBar.setFloatable(false);
toolBar.setRollover(true);
toolBar.setFocusable(false);
toolBar.setMargin(new java.awt.Insets(2, 0, 2, 0));
toolBar.setMinimumSize(new java.awt.Dimension(300, 50));

jButton1.setText("jButton1");
jButton1.setFocusable(false);
jButton1.setHorizontalTextPosition(javax.swing.SwingConstants.CENTER);
jButton1.setVerticalTextPosition(javax.swing.SwingConstants.BOTTOM);
toolBar.add(jButton1);
toolBar.add(jSeparator1);

jButton2.setText("jButton2");
jButton2.setFocusable(false);
jButton2.setHorizontalTextPosition(javax.swing.SwingConstants.CENTER);
jButton2.setVerticalTextPosition(javax.swing.SwingConstants.BOTTOM);
toolBar.add(jButton2);

getContentPane().add(toolBar, java.awt.BorderLayout.NORTH);

statusBar.setFloatable(false);

nJumpsLabel.setText("n Jumps ");
nJumpsLabel.setMaximumSize(new java.awt.Dimension(150, 19));
nJumpsLabel.setMinimumSize(new java.awt.Dimension(100, 19));
nJumpsLabel.setPreferredSize(new java.awt.Dimension(100, 19));
statusBar.add(nJumpsLabel);

statusLabel.setHorizontalAlignment(javax.swing.SwingConstants.RIGHT);
statusLabel.setText("Status");
statusLabel.setMaximumSize(new java.awt.Dimension(32222, 19));
statusLabel.setMinimumSize(new java.awt.Dimension(50, 19));
statusLabel.setPreferredSize(new java.awt.Dimension(50, 19));
statusBar.add(statusLabel);

progressBar.setValue(50);
progressBar.setMaximumSize(new java.awt.Dimension(100, 19));
progressBar.setPreferredSize(new java.awt.Dimension(100, 19));
statusBar.add(progressBar);

getContentPane().add(statusBar, java.awt.BorderLayout.SOUTH);

pack();
}//

public static void main(String args[]) {
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
new ToolBarTest().setVisible(true);
}
});
}

// Variables declaration - do not modify
private javax.swing.JButton jButton1;
private javax.swing.JButton jButton2;
private javax.swing.JToolBar.Separator jSeparator1;
private javax.swing.JLabel nJumpsLabel;
private javax.swing.JProgressBar progressBar;
private javax.swing.JToolBar statusBar;
private javax.swing.JLabel statusLabel;
private javax.swing.JToolBar toolBar;
// End of variables declaration

}

Message was edited by: krheinwald

krheinwald
Offline
Joined: 2004-06-25

Ok, reason for the separators not showing up in my example was a too small size (2) being specified.

krheinwald
Offline
Joined: 2004-06-25

> Ok. I'm fixing an issue in Nimbus with cell renderers
> at the moment,
> such that custom cell renderers that extend
> DefaultTableCellRenderer
> (at least) will get the built in row striping from
> Nimbus, selection,
> etc. Will that help in this case?

So you are actually fixing DefaultTableCellRenderer to have the proper UI elements set?
That would definitely help!

> I wouldn't expect this to work in Nimbus. There are a
> couple ways to achieve this (and a heck of a lot more)
> customization though.
...
> Unlike other LAFs, we show the focused component by
> painting the
> focus in the other 2 pixels of the component. This
> means, we have
> built in 2 pixels of space around the component.
> Which means
> JTextArea could/should be non-opaque, but we still
> need to paint the
> rest of the text background.

I wouldn't mind the border being painted, as long as the center stays transparent.

Thanks for your tips, I appreciate it. I will look into them.

Klaus

krheinwald
Offline
Joined: 2004-06-25

> Ok. I'm fixing an issue in Nimbus with cell renderers
> at the moment,
> such that custom cell renderers that extend
> DefaultTableCellRenderer
> (at least) will get the built in row striping from
> Nimbus, selection,
> etc. Will that help in this case?

So you are actually fixing DefaultTableCellRenderer to have the proper UI elements set?
That would definitely help!

> I wouldn't expect this to work in Nimbus. There are a
> couple ways to achieve this (and a heck of a lot more)
> customization though.
...
> Unlike other LAFs, we show the focused component by
> painting the
> focus in the other 2 pixels of the component. This
> means, we have
> built in 2 pixels of space around the component.
> Which means
> JTextArea could/should be non-opaque, but we still
> need to paint the
> rest of the text background.

I wouldn't mind the border being painted, as long as the center stays transparent.

Thanks for your tips, I appreciate it. I will look into them.

Klaus

krheinwald
Offline
Joined: 2004-06-25

Richard,

> Which means
> JTextArea could/should be non-opaque, but we still
> need to paint the
> rest of the text background.

I could fix this be changing the Z-order of two components.

Thanks,
Klaus

krheinwald
Offline
Joined: 2004-06-25

> Ok. I'm fixing an issue in Nimbus with cell renderers
> at the moment,
> such that custom cell renderers that extend
> DefaultTableCellRenderer
> (at least) will get the built in row striping from
> Nimbus, selection,
> etc. Will that help in this case?

So you are actually fixing DefaultTableCellRenderer to have the proper UI elements set?
That would definitely help!

> I wouldn't expect this to work in Nimbus. There are a
> couple ways to achieve this (and a heck of a lot more)
> customization though.
...
> Unlike other LAFs, we show the focused component by
> painting the
> focus in the other 2 pixels of the component. This
> means, we have
> built in 2 pixels of space around the component.
> Which means
> JTextArea could/should be non-opaque, but we still
> need to paint the
> rest of the text background.

I wouldn't mind the border being painted, as long as the center stays transparent.

Thanks for your tips, I appreciate it. I will look into them.

Klaus

krheinwald
Offline
Joined: 2004-06-25

> Ok. I'm fixing an issue in Nimbus with cell renderers
> at the moment,
> such that custom cell renderers that extend
> DefaultTableCellRenderer
> (at least) will get the built in row striping from
> Nimbus, selection,
> etc. Will that help in this case?

So you are actually fixing DefaultTableCellRenderer to have the proper UI elements set?
That would definitely help!

> I wouldn't expect this to work in Nimbus. There are a
> couple ways to achieve this (and a heck of a lot more)
> customization though.
...
> Unlike other LAFs, we show the focused component by
> painting the
> focus in the other 2 pixels of the component. This
> means, we have
> built in 2 pixels of space around the component.
> Which means
> JTextArea could/should be non-opaque, but we still
> need to paint the
> rest of the text background.

I wouldn't mind the border being painted, as long as the center stays transparent.

Thanks for your tips, I appreciate it. I will look into them.

Klaus

krheinwald
Offline
Joined: 2004-06-25

> Ok. I'm fixing an issue in Nimbus with cell renderers
> at the moment,
> such that custom cell renderers that extend
> DefaultTableCellRenderer
> (at least) will get the built in row striping from
> Nimbus, selection,
> etc. Will that help in this case?

So you are actually fixing DefaultTableCellRenderer to have the proper UI elements set?
That would definitely help!

> I wouldn't expect this to work in Nimbus. There are a
> couple ways to achieve this (and a heck of a lot more)
> customization though.
...
> Unlike other LAFs, we show the focused component by
> painting the
> focus in the other 2 pixels of the component. This
> means, we have
> built in 2 pixels of space around the component.
> Which means
> JTextArea could/should be non-opaque, but we still
> need to paint the
> rest of the text background.

I wouldn't mind the border being painted, as long as the center stays transparent.

Thanks for your tips, I appreciate it. I will look into them.

Klaus

krheinwald
Offline
Joined: 2004-06-25

> Ok. I'm fixing an issue in Nimbus with cell renderers
> at the moment,
> such that custom cell renderers that extend
> DefaultTableCellRenderer
> (at least) will get the built in row striping from
> Nimbus, selection,
> etc. Will that help in this case?

So you are actually fixing DefaultTableCellRenderer to have the proper UI elements set?
That would definitely help!

> I wouldn't expect this to work in Nimbus. There are a
> couple ways to achieve this (and a heck of a lot more)
> customization though.
...
> Unlike other LAFs, we show the focused component by
> painting the
> focus in the other 2 pixels of the component. This
> means, we have
> built in 2 pixels of space around the component.
> Which means
> JTextArea could/should be non-opaque, but we still
> need to paint the
> rest of the text background.

I wouldn't mind the border being painted, as long as the center stays transparent.

Thanks for your tips, I appreciate it. I will look into them.

Klaus

krheinwald
Offline
Joined: 2004-06-25

> Ok. I'm fixing an issue in Nimbus with cell renderers
> at the moment,
> such that custom cell renderers that extend
> DefaultTableCellRenderer
> (at least) will get the built in row striping from
> Nimbus, selection,
> etc. Will that help in this case?

So you are actually fixing DefaultTableCellRenderer to have the proper UI elements set?
That would definitely help!

> I wouldn't expect this to work in Nimbus. There are a
> couple ways to achieve this (and a heck of a lot more)
> customization though.
...
> Unlike other LAFs, we show the focused component by
> painting the
> focus in the other 2 pixels of the component. This
> means, we have
> built in 2 pixels of space around the component.
> Which means
> JTextArea could/should be non-opaque, but we still
> need to paint the
> rest of the text background.

I wouldn't mind the border being painted, as long as the center stays transparent.

Thanks for your tips, I appreciate it. I will look into them.

Klaus

Richard Bair

> When laying out a toolbar, it seems Nimbus uses the preferred size
> of a label, while other L&Fs expand components up to their maximum
> size to fill the whole toolbar.
>
> These two images show the difference: www.paralog.net/files/
> ToolbarNimbus.jpg and www.paralog.net/files/ToolbarWindows.jpg .
> The label showing 'Exporting...' is defined with a large maximum
> width.

Huh, this is very interesting. We aren't doing anything special in
Nimbus per se, I wonder if Synth is using a different layout manager
for JToolBar? I wouldn't expect so, but then I've been surprised before.

Can you post a *small* runnable test that I can use to verify this?

Thanks!
Richard

Richard Bair

Hey Klaus,

You probably aren't going to like this! But here goes:

You cannot safely assume that one LAF will have the same UIDefault
entries as another LAF. Nimbus (and Synth) work in a fundamentally
different way from other LAFs. For example, what should this mean:

UIManager.getColor("Table.selectionForeground");

Should this mean, the selectionForeground color when in the "enabled"
and "editable" state? Or the selectionForeground when "enabled" and
not "editable"? Or should it be the selectionForeground when the
mouse is over?

What does "TableHeader.cellBorder" mean when using Synth and painting
with images? In that case, the visual "border" is most likely just
part of the image being used to paint, and the Swing border is
probably an empty border with some insets. If any at all.

What about "TableHeader.background"? The background of the table
header could be one of many different colors, depending on the state
of the header. For example, is this the background with "enabled",
"disabled", or "mouse over"?

Currently there are no plans for Nimbus to support these keys (or
many of the other keys used by other LAFs) because it really doesn't
make much sense, based on the way Synth/Nimbus work. If we supported
these keys, that would imply that we would honor them as well, but
that doesn't always make sense either. For example, what if the
header background isn't really a solid color, but a 5-6 stop
gradient? In this case, how would we honor the color if specified? By
interpolating the other colors for the remaining 4-5 stops?

In particular:

> [i]UIManager.getColor("TableHeader.background")

I'm not sure this key will make sense with nimbus

> UIManager.getColor("Table.foreground")

In Nimbus. we have a dozen or so "top level" defaults. One of these
is "foreground". When a component doesn't specify an exact foreground
color, it will "inherit" the default. For example, suppose I had this
only:

foreground = BLACK;

In this case, when Nimbus loads the foreground for buttons, tables,
etc, it will use BLACK. If UIDefault had this:

foreground = BLACK;
Table.foreground = BLUE;

Then all foreground colors in the table would be "BLUE", regardless
of the state of the component, but all other components would be
BLACK in every state. If I had this:

foreground = BLACK;
Table.foreground = BLUE;
Table.Disabled.Foreground = GRAY;

Then the table would have BLUE as the foreground for all states other
than Disabled. In the disabled state it would be GRAY. In this way,
using a minimum number of keys, we can define the colors for all
components and states.

I would also like to know why you are relying on these keys. My guess
would be that you are styling other components and what to reuse
colors from the LAF.

It is an unfortunately position we are in. We want it to be easy for
folks to use Nimbus, but at the same time not be shackled down to
past implementation details :(

> JTextArea.setOpaque(false)
>
> seems to be ignored.

That depends on what you think it should do :-). Swing,
unfortunately, has assigned two different meanings to "Opaque".
Officially, it means "does this component paint every pixel within
its bounds?". A component can be opaque = false and still paint every
pixel within its bounds, but it cannot be opaque = true and fail to
do so.

For this reason, it also has a second effect for components: if
opaque = true, then ComponentUI (in most LAFs, SynthStyle in Synth/
Nimbus) ensures that the background color of the component is used to
paint every pixel first, and then the component paints as normal.

So setting opaque to false *may not* result in any visual difference.

But, since it could also be a bug :-), what are you seeing, and what
were you expecting?

Cheers!
Richard

Richard Bair

Hey Klaus,

> You cannot safely assume that one LAF will have the same UIDefault
> entries as another LAF. Nimbus (and Synth) work in a fundamentally
> different way from other LAFs. For example, what should this mean:

Ok, while this is true, I'm going to see what I can do to support
more of these keys. I cannot guarantee that all the keys supported by
other LAFs will be supported in Nimbus, but I'll see how far I can
get. I've got another bug filed from NB where NB won't start with
Nimbus because they too are relying on some of these keys. I'm slowly
being beaten into submission :-)

I'll start with Fonts. In Nimbus we have "defaultFont" which is the
fallback font used by everything if they don't override it. What I'll
do is this:

"TextField.font" = new ReferenceValue("defaultFont")

where ReferenceValue extends UIDefaults.ActiveValue and simply looks
up "defaultFont" and returns it when queried. I *won't* set reference
values for items beneath states (ie, I won't:
"TextField.Enabled.font" = new ReferenceValue), since nobody is
relying on those keys right now and I'd like to not get the
UIDefaults table too big.

I'll also try to do the same for background and foreground colors. In
particular:

"TextField.foreground" = ReferenceValue("foreground");
"TextField.background" = ReferenceValue("background");

But be warned that this color is not related to the state of the
component. The "Enabled" foreground/background might be different
from the default foreground/background. But, at least you won't get
NPE's, and the returned values are probably sensible, but I cannot
guarantee it. I might go the extra step of letting
"TextField.background" = "TextField.Enabled.background" if it is
specified, that way the "XXX.background" and "XXX.foreground" keys
are always true with regards to the values associated with the
enabled state. But again, be warned, this may not always tell the
truth, since the "background" color may be ignored. I know Button
ignores it. The "background" color is the same as the panel
background, whereas the colors used in the button are different. Text
field probably also ignores it.

At the moment, the "foreground" colors are honest.

Richard

kirillcool
Offline
Joined: 2004-11-17

> Ok, while this is true, I'm going to see what I can
> do to support
> more of these keys. I cannot guarantee that all the
> keys supported by
> other LAFs will be supported in Nimbus, but I'll see
> how far I can
> get. I've got another bug filed from NB where NB
> won't start with
> Nimbus because they too are relying on some of these
> keys. I'm slowly
> being beaten into submission :-)

Welcome to the world of LAF development :) In Substance, i'm slowly migrating away from *using* the UIManager keys, while still *setting* them so that the applications can use some "sensible" values. The reason that i'm not using the keys are mostly for state-specific color schemes for most of the skins, as you mention for Nimbus. You can have one color for default background, another color for rollover background, yet another color for rollover selected background and so on.

What i think (at least now) is that i don't want to add yet more UIManager entries that are specific to the specific LAF (especially since the color entries do not faithfully represent multi-stop gradients). Instead, i'm publishing a set of Substance-specific painters that allow people to provide much better integration with Substance, at the expense of tying the application to the specific LAF. It's their choice, of course.

Kirill

swpalmer
Offline
Joined: 2003-06-10

Ah, so it's the same issue that I was having with my tree cell renderer. Richard has already mentioned above that he considers the Combobox height thing a bug. I didn't file a report for it though, and I don't know if Richard did. Have you?

Richard Bair

> Ah, so it's the same issue that I was having with my tree cell
> renderer. Richard has already mentioned above that he considers
> the Combobox height thing a bug. I didn't file a report for it
> though, and I don't know if Richard did. Have you?

Cool, I like it when multiple bugs have one root cause :-). I haven't
filed this bug, if you'd like to do the grunt-work, I'd be most
obliged! :-)

roger_rf
Offline
Joined: 2007-10-04

Hi Richard,
Sorry for disappearing :( I've filed four bugs for the Nimbus issues I found, with the following ID's:

1095663
1095669
1095673
1095680

The last bug is something new that we haven't discussed here: under Nimbus, JCheckBoxes don't honor the background color you set for them. Also, I sent you an-email with the screenshot you asked in order to see the problem of internal frames with custom icons. Cheers,

Roger

kirillcool
Offline
Joined: 2004-11-17

Override the getDefaultSize() and use your own Nimbus default renderer instead of the basic one. Had to do it in Substance as well.

Richard Bair

I see.

Actually, I have another approach I think would work. Currently,
DefaultListCellRender and DefaultTableCellRenderer are not well
behaved with respect to LAFs. That is, there is no way for the LAF to
customize the way the default renderers render. In the case of Synth/
Nimbus, this causes quite some problems, where we end up using custom
renderers instead of the DefaultXXX renderers. The problems become
apparent when developers then set custom renderers based on
DefaultXXX variants, which then don't look like they belong.

For example, with JTable, in Nimbus we have automatic row striping.
Well, that works until somebody uses a custom renderer. Even if they
use a custom DefaultTableCellRenderer and ONLY override the text
portion of the renderer, they still lose the row striping. This is bad.

The solution I'm thinking of would be to have the DefaultXXX
renderers delegate to a UI delegate, exactly the same as all other
swing components. I'd factor out the getXXXCellRendererComponent()
methods such that they defer to the UI. Basic would have an
implementation (which sadly would have to be package private for the
time being, thanks to JCP rules with regards to public API in update
releases), and thus all LAFs extended from Basic would work fine.
Synth would then extend the UI with it's own variant, doing whatever
it does.

In this way, if you use DefaultXXXRenderer, it will automatically
pick up all the colors, fonts, sizes, opacities, etc that the LAF
defaults to.

What do you think?

Thanks
Richard

On Oct 13, 2007, at 3:51 PM, swing@javadesktop.org wrote:

> Override the getDefaultSize() and use your own Nimbus default
> renderer instead of the basic one. Had to do it in Substance as well.
> [Message sent by forum member 'kirillcool' (kirillcool)]
>
> http://forums.java.net/jive/thread.jspa?messageID=239976

kleopatra
Offline
Joined: 2003-06-11

Hi Richard,

didn't yet have a chance to look into Nimbus - but XXRenderers always get my attention, and more often than not the default core implementations send me into ranting mode :-)

> The solution I'm thinking of would be to have the DefaultXXX
renderers delegate to a UI delegate

That's a good idea and basically what SwingX renderer support is doing:

http://wiki.java.net/bin/view/Javadesktop/SwingLabsRenderer

in SwingX speak a renderer is a ComponentProvider and independent of the target it is rendering in, that is re-usable across table, tree, list, whatever. It delegates its state dependent default visual configuration to DefaultVisuals (yeah, names aren't my strength ;). The delegate is responsible to _completely_ configure the attributes it advertises to configure (which the DefaultXXCellRenderers don't for a variety of properties, aren't even doc'ed to do ... ).

Obviously, the SwingX DefaultVisuals is not a UI-Delegate - but could be, I think (or maybe the underlying CellContext which is the the actual place where the lf-specifics are looked up). Quite exciting prospect!

Cheers
Jeanette

roger_rf
Offline
Joined: 2007-10-04

Hi Richard,

Just to let you know I didn't disappear, I've been a bit swamped with work in the last two days, and probably will be for a couple more. However, I'm still working on a little test app to show the points I brought up, and I think I found the reason to the JDialog size problem. Please try the following in NetBeans 6.0-b1:

- Create a non-resizable JDialog and drop a few components on it: JLabels, JTextFields, JButtons and the like. Just don't forget to drop a few JComboBoxes, and make sure they have empty models (i.e. no items);
- Make sure the dialog occupies the minimum possible size while having all components show up completely, i.e. snap all components to their default sizes, and then resize the dialog to enclose all components exactly;
- In the dialog construtor, after the call to [initComponents()], insert a few items in the ComboBox'es. When the dialog gets shown, you will notice that the lower section of the dialog gets a bit clipped.

Why does that happen? Because, under Nimbus, an empty JComboBox has a different height than a JComboBox that has at least one item. When you insert a few items, the JComboBox expands its height in order to have space to show the current item, but the dialog doesn't expand along with it. IMHO, the fix for this would be having empty JComboBox'es have the same height as those with at least one item. Cheers,

Roger

Richard Bair

> - Create a non-resizable JDialog and drop a few components on it:
> JLabels, JTextFields, JButtons and the like. Just don't forget to
> drop a few JComboBoxes, and make sure they have empty models (i.e.
> no items);
> - Make sure the dialog occupies the minimum possible size while
> having all components show up completely, i.e. snap all components
> to their default sizes, and then resize the dialog to enclose all
> components exactly;
> - In the dialog construtor, after the call to [initComponents()],
> insert a few items in the ComboBox'es. When the dialog gets shown,
> you will notice that the lower section of the dialog gets a bit
> clipped.
>
> Why does that happen? Because, under Nimbus, an empty JComboBox has
> a different height than a JComboBox that has at least one item.
> When you insert a few items, the JComboBox expands its height in
> order to have space to show the current item, but the dialog
> doesn't expand along with it. IMHO, the fix for this would be
> having empty JComboBox'es have the same height as those with at
> least one item. Cheers,

Ah brilliant. I'll be sure it gets fixed. Darn those combos. :-)

Richard

roger_rf
Offline
Joined: 2007-10-04

> Thank you very much for taking the time to report
> them.
>
No problem :) I'm really excited to see Java improving on the desktop front, and helping a little bit with it.

> > - Toolbar buttons don't get rendered when the
> toolbar's orientation
> > is vertical. (Horizontal orientation works fine);
>
> Is the same bug you are seeing?
> http://bugs.sun.com/bugdatabase/
> view_bug.do?bug_id=6594754
>
Yeah, that's it.

> > - The titles of internal frames don't blend well
> with the frame's
> > background. The internal frame is comprised of two
> gray "squares":
> > an "outer" square in a darker tone, and an "inner"
> square in a
> > lighter tone. For the most part, the window title
> is backed by the
> > dark outer square, and since the title is black, it
> can get a bit
> > difficult to read. Also, the frame title gets
> slightly "stroked" by
> > the region where the outer and inner squares meet -
> IMHO, that's
> > not very aesthetically pleasant;
>
> Do you have a screenshot? It may be a bug, or it may
> be the design :-)
>
I can send you a screen shot, just give me your e-mail - mine is roger dot rf at gmail dot com. Upon closer investigation, I found this issue only shows up if you set an icon for the internal frame [internalFrame.setFrameIcon(icon)]. If you leave the default icon untouched, the title is neatly contained in the darker outer square.

> > - When you iconify an internal frame inside a
> JDesktopPane, the
> > iconified frame's title bar gets transparent, and
> the frame title
> > is rendered over whatever is being displayed in the
> underlying
> > JDesktopPane - it becomes difficult to read.
>
> I think it is this bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?
> bug_id=6594098
> It has been fixed, but is not available in a build
> yet. Should be
> available in build 06.
>
Yeah, that's it.

> > Also, there should be a different icon for the
> "Restore" button of
> > iconified internal frames - currenty, it's the same
> icon as the
> > "Minimize" button, which can confuse users;
>
> Yes, I see that too. If you file a bug, let me know!
>
Would you like me to file a bug on this?

> > - In fixed-size JDialogs using the GroupLayout
> layout manager, the
> > size of the dialog isn't calculated correctly upon
> calling
> > [dialog.setVisible(true)], and some visual
> components can get
> > clipped, or not even get shown at all, in the
> lower-right portion
> > of the dialog;
>
> Very interesting. Can you post a small runnable demo
> we can use to
> see the bug?
>
Hmm, I just wrote a little test app but I can't seem to reproduce the bug, it seems to happen very rarely, although it's not random. I've spotted it in a dialog box of a project I'm working on, but I can't post it publicly without my employer's permission. If it's OK with you, I can send you the code privately, after stripping all references that my employer could complain about.

> > - Text components occupy a little too much space.
> The font size is
> > OK, but the margins could be smaller. I found this
> especially
> > noticeable in JTextField and JTextArea;
>
> Can you send a screenshot?
>
Sure I can send one, but don't get me wrong, it's not that much of a problem, just a matter of taste on aesthetics. I prefer working with small visual gaps, so I can pack more data in less screen space.

> > - When you use FlowLayout, two components directly
> beside each
> > other have a quite wide gap between them, it could
> be narrower;
>
> There should be at least 4 pixels between them -- we
> use this extra
> space for painting focus. How may pixels of space are
> you seeing?
>
Hmm, you're correct, it's just enough space for the painting focus. Sorry about that.

> > - In a JTable, if you provide your own CellRenderer
> for a column
> > and inherit it from DefaultTableCellRenderer, the
> font of your
> > CellRenderer will be drawn with a different color
> than that of the
> > CellRenderer's you don't override;
>
> This is a known bug, and quite a tricky one. But I
> will be addressing
> it in the next 2 weeks.
>
Something else about this one: the text baseline between overridden and non-overridden CellRenderer's is also a bit off. In overridden CellRenderer's, the text's upper margin is greater than the lower margin. In non-overridden Cenderer's, the margins seem to be identical.

> > - Component tooltips have a thin gray outline on
> the top and right
> > sections, but there's no outline in the bottom and
> left sections;
>
> Ok, I don't think we have a bug on this one yet. Let
> me know if you
> file one on bug parade. A suitable title for the bug
> would be:
> "Nimbus L&F: Tooltips outline is only partly
> visible".
>
Would you like me to file a bug on this too?

> > - In JOptionPane.showConfirmDialog() under WinXP,
> if you use
> > JOptionPane.YES_NO_OPTION, the "No" button gets
> rendered to the
> > left of the "Yes" button, when then Windows default
> is the
> > opposite, "Yes" rendered to the left of "No". Maybe
> Nimbus could
> > follow the button placement of the host OS?
>
> I'm not sure if there is a bug filed on this one yet,
> but we've had
> that reported to us from the Testing group as well.
> We followed the
> mac conventions (since that is what the nimbus design
> does) but agree
> that the order of buttons should follow what happens
> on the native
> platform.
>
I personally believe that following the native platform is the better alternative, I've clicked the wrong button several times already ;)

> > These gripes aside, I very much enjoy Nimbus, and I
> surely plan to
> > use it in my projects - gotta love that standard
> background image
> > in JDesktopPane ;) Cheers & keep up the good work,
>
> Thank you very much!
>
> Richard
>
Thanks for the prompt response :) Cheers,

Roger

Richard Bair

Hi Roger,

> I can send you a screen shot, just give me your e-mail - mine is
> roger dot rf at gmail dot com. Upon closer investigation, I found
> this issue only shows up if you set an icon for the internal frame
> [internalFrame.setFrameIcon(icon)]. If you leave the default icon
> untouched, the title is neatly contained in the darker outer square.

Ok. The issue with the title bar painting incorrectly with a custom
icon set is known. Even so, a screenshot would be nice.
richard.bair@sun.com

>>> Also, there should be a different icon for the
>> "Restore" button of
>>> iconified internal frames - currenty, it's the same
>> icon as the
>>> "Minimize" button, which can confuse users;
>>
>> Yes, I see that too. If you file a bug, let me know!
>>
> Would you like me to file a bug on this?

Yes please, that would be great.

>>> - In fixed-size JDialogs using the GroupLayout
>> layout manager, the
>>> size of the dialog isn't calculated correctly upon
>> calling
>>> [dialog.setVisible(true)], and some visual
>> components can get
>>> clipped, or not even get shown at all, in the
>> lower-right portion
>>> of the dialog;
>>
>> Very interesting. Can you post a small runnable demo
>> we can use to
>> see the bug?
>>
> Hmm, I just wrote a little test app but I can't seem to reproduce
> the bug, it seems to happen very rarely, although it's not random.
> I've spotted it in a dialog box of a project I'm working on, but I
> can't post it publicly without my employer's permission. If it's OK
> with you, I can send you the code privately, after stripping all
> references that my employer could complain about.

Sure, you bet. The smaller and simpler the test case, the more likely
it is to be fixed quickly :-)

>>> - Text components occupy a little too much space.
>> The font size is
>>> OK, but the margins could be smaller. I found this
>> especially
>>> noticeable in JTextField and JTextArea;
>>
>> Can you send a screenshot?
>>
> Sure I can send one, but don't get me wrong, it's not that much of
> a problem, just a matter of taste on aesthetics. I prefer working
> with small visual gaps, so I can pack more data in less screen space.

That's ok. A couple other folks have already caught us red-handed
with UI mistakes in Nimbus. We really appreciate the aesthetic
feedback too. At the very least it gives us another perspective to
consider.

>>> - In a JTable, if you provide your own CellRenderer
>> for a column
>>> and inherit it from DefaultTableCellRenderer, the
>> font of your
>>> CellRenderer will be drawn with a different color
>> than that of the
>>> CellRenderer's you don't override;
>>
>> This is a known bug, and quite a tricky one. But I
>> will be addressing
>> it in the next 2 weeks.
>>
> Something else about this one: the text baseline between overridden
> and non-overridden CellRenderer's is also a bit off. In overridden
> CellRenderer's, the text's upper margin is greater than the lower
> margin. In non-overridden Cenderer's, the margins seem to be
> identical.

Ok. I'll look into this.

>>> - Component tooltips have a thin gray outline on
>> the top and right
>>> sections, but there's no outline in the bottom and
>> left sections;
>>
>> Ok, I don't think we have a bug on this one yet. Let
>> me know if you
>> file one on bug parade. A suitable title for the bug
>> would be:
>> "Nimbus L&F: Tooltips outline is only partly
>> visible".
>>
> Would you like me to file a bug on this too?

Yes please!

Cheers
Richard

swpalmer
Offline
Joined: 2003-06-10

If a JTabbedPane is too narrow to show all the tabs there is no widget to allow access to the tabs that aren't drawn. (e.g. Windows LnF draws left-right arrows beside the last rendered tab so you can scroll the tabs left and right to access those not shown.)

Richard Bair

> If a JTabbedPane is too narrow to show all the tabs there is no
> widget to allow access to the tabs that aren't drawn. (e.g.
> Windows LnF draws left-right arrows beside the last rendered tab so
> you can scroll the tabs left and right to access those not shown.)

I think this is http://bugs.sun.com/bugdatabase/view_bug.do?
bug_id=6595240.

Richard

swpalmer
Offline
Joined: 2003-06-10

> JTree doesn't seem to respect the row height
> setting:
>
> [code]myTree.setRowHeight(new
> JComboBox().getPreferredSize().height+1);[/code]
>
> doesn't give me the result I was hoping for. My tree
> cell editor (and renderer actually) uses a combobox
> and I want the row height to always accommodate it.

Ok, after further investigation I see that the issue here is that:
[code]new JComboBox().getPreferredSize().height = 18;[/code]
where as:
[code]new JComboBox(new Object[]{"X"}).getPreferredSize().height = 26;[/code]

So it was my own assumptions that were in error.

Richard Bair

> Ok, after further investigation I see that the issue here is that:
> [code]new JComboBox().getPreferredSize().height = 18;[/code]
> where as:
> [code]new JComboBox(new Object[]{"X"}).getPreferredSize().height =
> 26;[/code]
>
> So it was my own assumptions that were in error.

Actually, I do remember having seen this over the weekend, and I
think it is a bug worth fixing. A ComboBox with no items should be
the same size as a ComboBox with one item. In your test, try using "
" instead of "X". It should still give the same size.

Richard

swpalmer
Offline
Joined: 2003-06-10

In detailed view the JFileChooser draws with what should be alternating background colours for each row.. but the background doesn't draw all the way across the column width, so this looks really bad.

Richard Bair

> In detailed view the JFileChooser draws with what should be
> alternating background colours for each row.. but the background
> doesn't draw all the way across the column width, so this looks
> really bad.

I think you are seeing this guy: http://bugs.sun.com/bugdatabase/
view_bug.do?bug_id=6594818

The problem here is looks again to be custom renderers. Similar
situation to the JComboBox. Easy to fix in this case, harder in the
general case. If there even is a general solution. Hmmm.

Richard

swpalmer
Offline
Joined: 2003-06-10

JTree doesn't seem to respect the row height setting:

[code]myTree.setRowHeight(new JComboBox().getPreferredSize().height+1);[/code]

doesn't give me the result I was hoping for. My tree cell editor (and renderer actually) uses a combobox and I want the row height to always accommodate it.

Richard Bair

Ok, I don't think we have seen this one. Please file a bug and let me
know.

Thanks!
Richard

On Oct 2, 2007, at 7:33 AM, swing@javadesktop.org wrote:

> JTree doesn't seem to respect the row height setting:
>
> [code]myTree.setRowHeight(new JComboBox().getPreferredSize().height
> +1);[/code]
>
> doesn't give me the result I was hoping for. My tree cell editor
> (and renderer actually) uses a combobox and I want the row height
> to always accommodate it.
> [Message sent by forum member 'swpalmer' (swpalmer)]
>
> http://forums.java.net/jive/thread.jspa?messageID=238029

swpalmer
Offline
Joined: 2003-06-10

JTabbedPane draws the tabs wrong when they are placed on the left side of the pane.

Richard Bair

> JTabbedPane draws the tabs wrong when they are placed on the left
> side of the pane.

This is really part of this bug: http://bugs.sun.com/bugdatabase/
view_bug.do?bug_id=6594797

I think right now this is a P3 (P1 being highest priority, P3 being
medium priority). If this is a huge deal for your app, let me know
and I'll bump it up.

Thanks
Richard

swpalmer
Offline
Joined: 2003-06-10

I use this code to get the icon for a "folder":

folderIcon = UIManager.getIcon("FileView.directoryIcon");

but it does not work on Nimbus. It works on Metal and Windows LnF on my PC and Aqua on my Mac, and the system look and feel on Ubuntu Linux.

Richard Bair

> I use this code to get the icon for a "folder":
>
> folderIcon = UIManager.getIcon("FileView.directoryIcon");
>
> but it does not work on Nimbus. It works on Metal and Windows LnF
> on my PC and Aqua on my Mac, and the system look and feel on Ubuntu
> Linux.

Hmmm, ok. This would also be good to file a bug on.

Thanks
Richard

swpalmer
Offline
Joined: 2003-06-10

The "Look in:" drop-down in JFileChooser should have icons beside the items (e.g. a harddrive icon beside "Local Disk (C:)", folder icons beside non-root components, etc.)

Richard Bair

> The "Look in:" drop-down in JFileChooser should have icons beside
> the items (e.g. a harddrive icon beside "Local Disk (C:)", folder
> icons beside non-root components, etc.)

We have a bug on this, but it hasn't been fixed yet.

Thanks
Richard

Richard Bair

> The "Look in:" and "Files of Type:" fields in the JFileChooser look
> bad. They appear to be missing needed borders.

Looks like this bug: http://bugs.sun.com/bugdatabase/view_bug.do?
bug_id=6595179. Although I noticed from the bug description it
doesn't mention "Files of Type".

Richard

krheinwald
Offline
Joined: 2004-06-25

Richard,

the attached example shows:

- the border for a TitleBorder is not drawn, only the title is
- the grid for the tables is not drawn, even when explicitly set (on by default for other L&Fs)
- when setting a DefaultTableCellRenderer on the table columns, display of the columns and selction becomes screwed up

These seem to be not specific to Nimbus:
- when setting a DefaultTableCellRenderer on the header, the header cells loose their background and bold font attribute
- The default cell editor for Float and Double does not respect the locale (DE in my case)
- when setting a DefaultTableCellRenderer for Double or Float colums, the locale is not respected anymore in rendering

I hope the forum DB does not choke on me again...

Klaus

---

import javax.swing.*;
import javax.swing.table.*;
import java.awt.*;

public class TableAndBorderTest extends javax.swing.JFrame {

public TableAndBorderTest() {
try {
// UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");
// UIManager.setLookAndFeel("com.sun.java.swing.plaf.motif.MotifLookAndFeel");
// UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
UIManager.setLookAndFeel("sun.swing.plaf.nimbus.NimbusLookAndFeel");
} catch (Exception e) {
e.printStackTrace();
}

initComponents();

Table1.getTableHeader().setFont(jTable1.getFont().deriveFont(Font.BOLD));

jTable1.setShowHorizontalLines(true);
jTable1.setShowVerticalLines(true);

jTable1.getColumnModel().getColumn(2).setHeaderRenderer(new DefaultTableCellRenderer());
jTable1.getColumnModel().getColumn(4).setHeaderRenderer(new DefaultTableCellRenderer());

jTable1.setDefaultRenderer(Integer.class, new DefaultTableCellRenderer());
jTable1.setDefaultRenderer(Double.class, new DefaultTableCellRenderer());
}

//
private void initComponents() {

jScrollPane1 = new javax.swing.JScrollPane();
jTable1 = new javax.swing.JTable();

setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);

jScrollPane1.setBorder(javax.swing.BorderFactory.createTitledBorder("Table"));

jTable1.setModel(new javax.swing.table.DefaultTableModel(
new Object [][] {
{"", "abc", new Integer(123), new Float(123.4), new Double(123.4)},
{null, null, null, null, null},
{null, null, null, null, null},
{null, null, null, null, null}
},
new String [] {
"Title 1", "Title 2", "Title 3", "Title 4", "Title 5"
}
) {
Class[] types = new Class [] {
java.lang.Object.class, java.lang.String.class, java.lang.Integer.class, java.lang.Float.class, java.lang.Double.class
};

public Class getColumnClass(int columnIndex) {
return types [columnIndex];
}
});
jScrollPane1.setViewportView(jTable1);

getContentPane().add(jScrollPane1, java.awt.BorderLayout.CENTER);

pack();
}//

public static void main(String args[]) {
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
new TableAndBorderTest().setVisible(true);
}
});
}

// Variables declaration - do not modify
private javax.swing.JScrollPane jScrollPane1;
private javax.swing.JTable jTable1;
// End of variables declaration

}

Added example to show loosing bold header

Message was edited by: krheinwald

Message was edited by: krheinwald

Richard Bair

Hi Klaus,

> the attached example shows:

Thanks!

> - the border for a TitleBorder is not drawn, only the title is

Ok, this is a known issue, though I can't find a bug on it...

> - the grid for the tables is not drawn, even when explicitly set
> (on by default for other L&Fs)

http://bugs.sun.com/view_bug.do?bug_id=6594663

> - when setting a DefaultTableCellRenderer on the header, the header
> cells loose their background
> - when setting a DefaultTableCellRenderer on the table columns,
> display of the columns and selction becomes screwed up

These are both new bugs, I'll look into them.

> These two seem to be not specific to Nimbus:
> - The default cell editor for Float and Double does not respect the
> locale (DE in my case)
> - when setting a DefaultTableCellRenderer for Double or Float
> colums, the locale is not respected anymore in rendering

K, let me check these out as well.

Thanks
Richard

>
> I hope the forum DB does not choke on me again...
>
> Klaus
>
> ---
>
> import javax.swing.*;
> import javax.swing.table.*;
> import java.awt.*;
>
> public class TableAndBorderTest extends javax.swing.JFrame {
>
> public TableAndBorderTest() {
> try {
> // UIManager.setLookAndFeel
> ("javax.swing.plaf.metal.MetalLookAndFeel");
> // UIManager.setLookAndFeel
> ("com.sun.java.swing.plaf.motif.MotifLookAndFeel");
> // UIManager.setLookAndFeel
> ("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
> UIManager.setLookAndFeel
> ("sun.swing.plaf.nimbus.NimbusLookAndFeel");
> } catch (Exception e) {
> e.printStackTrace();
> }
>
> initComponents();
>
> jTable1.setShowHorizontalLines(true);
> jTable1.setShowVerticalLines(true);
>
> jTable1.getColumnModel().getColumn(2).setHeaderRenderer(new
> DefaultTableCellRenderer());
> jTable1.getColumnModel().getColumn(4).setHeaderRenderer(new
> DefaultTableCellRenderer());
>
> jTable1.setDefaultRenderer(Integer.class, new
> DefaultTableCellRenderer());
> jTable1.setDefaultRenderer(Double.class, new
> DefaultTableCellRenderer());
> }
>
>
>
> //
> private void initComponents() {
>
> jScrollPane1 = new javax.swing.JScrollPane();
> jTable1 = new javax.swing.JTable();
>
> setDefaultCloseOperation
> (javax.swing.WindowConstants.EXIT_ON_CLOSE);
>
> jScrollPane1.setBorder
> (javax.swing.BorderFactory.createTitledBorder("Table"));
>
> jTable1.setModel(new javax.swing.table.DefaultTableModel(
> new Object [][] {
> {"", "abc", new Integer(123), new Float(123.4), new
> Double(123.4)},
> {null, null, null, null, null},
> {null, null, null, null, null},
> {null, null, null, null, null}
> },
> new String [] {
> "Title 1", "Title 2", "Title 3", "Title 4", "Title 5"
> }
> ) {
> Class[] types = new Class [] {
> java.lang.Object.class, java.lang.String.class,
> java.lang.Integer.class, java.lang.Float.class, java.lang.Double.class
> };
>
> public Class getColumnClass(int columnIndex) {
> return types [columnIndex];
> }
> });
> jScrollPane1.setViewportView(jTable1);
>
> getContentPane().add(jScrollPane1,
> java.awt.BorderLayout.CENTER);
>
> pack();
> }//

>
>
> public static void main(String args[]) {
> java.awt.EventQueue.invokeLater(new Runnable() {
> public void run() {
> new TableAndBorderTest().setVisible(true);
> }
> });
> }
>
> // Variables declaration - do not modify
> private javax.swing.JScrollPane jScrollPane1;
> private javax.swing.JTable jTable1;
> // End of variables declaration
>
> }
> [Message sent by forum member 'krheinwald' (krheinwald)]
>
> http://forums.java.net/jive/thread.jspa?messageID=240416