Skip to main content

Nimbus issues

68 replies [Last post]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
nimbusdeveloper
Offline
Joined: 2009-06-09
Points: 0

Hi Klaus/Richard,

Just wanted to know how to change the BG color of table headers. Nimbus correctly changes the foreground color of the headers but the background color change does not seem to work.
Thanks in advance.

krheinwald
Offline
Joined: 2004-06-25
Points: 0

> 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
Points: 0

Richard,

My post was edited, the screenshot is now at www.paralog.net/files/Toolbars.jpg .

WRT your other post gone AWOL:

[i]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.[/i]

Korrekt. I am using these keys to paint a striped table based on the table colors as well as my own selection as I am using my own cell renderers. Otherwise I have a nice mixture of UI rendered colors and none.

The cell border is necessary to be set in my tableheadercellrenderer, otherwise no border is drawn (in all UIs).

[i]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 :([/i]

I understand this position very well. The question is, how much effort people are willing to invest to make their application Nimbus-ready

[i]> JTextArea.setOpaque(false) seems to be ignored.

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

In other UIs, the TextArea background is not drawn, i.e. transparent and this is what I rely on.

Thanks,
Klaus

Now the messages are there, Strange...

Message was edited by: krheinwald

Message was edited by: krheinwald

Richard Bair

> [i]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.[/i]
>
> Korrekt. I am using these keys to paint a striped table based on
> the table colors as well as my own selection as I am using my own
> cell renderers. Otherwise I have a nice mixture of UI rendered
> colors and none.

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?

> The cell border is necessary to be set in my
> tableheadercellrenderer, otherwise no border is drawn (in all UIs).

Can you provide another screenshot? PNG or some other lossless format
preferred :-).

> [i]> JTextArea.setOpaque(false) seems to be ignored.
>
> But, since it could also be a bug :-), what are you seeing, and
> what were you expecting?[/i]
>
> In other UIs, the TextArea background is not drawn, i.e.
> transparent and this is what I rely on.

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. One
approach would be to register your own Painter implementation which
simply checks whether to paint the component specially or not. It
would delegate to the existing Painter if it should, otherwise it
just paints the background Color. Like:

public final class MyHackedPainter implements Painter {
private Painter delegate;
public MyHackedPainter(Painter delegate) {
this.delegate = delegate;
}

public void paint(Graphics2D g, JTextArea t, int w, int h) {
if ("noBackground".equals(t.getName())) {
g.setColor(t.getBackground());
g.fillRect(0, 0, w, h);
} else {
delegate.paint(g, t, w, h);
}
}

Painter p = (Painter)UIManager.get
("TextArea.Enabled.backgroundPainter");
UIManager.put("TextArea.Enabled.backgroundPainter", new
MyHackedPainter(p));

JTextArea ta = new JTextArea();
ta.setName("noBackground");

Another approach would be to put a bunch of entries into UIManager
for a named component:

UIManager.put("\"noBackground\".backgroundPainter", new SimplePainter
());

where SimplePainter just does the setColor/fillrect part of the
MyHackedPainter.

I'm actually really surprised that JTextArea doesn't paint it's
background when non-opaque (can't say that I've tried that before).
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.

Thanks
Richard

krheinwald
Offline
Joined: 2004-06-25
Points: 0

1. 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.

2. Separators on Toolbars are not shown.

This image shows the difference: www.paralog.net/files/Toolbars.jpg .

(The label showing 'Exporting...' is defined with a large maximum width)

Klaus

Message was edited by: krheinwald

Richard Bair

Hey Klaus,

I can't seem to see the images. Is there someplace else you could
post them?

Thanks!
Richard

On Oct 14, 2007, at 2:56 PM, swing@javadesktop.org wrote:

> 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.
>
> Klaus
> [Message sent by forum member 'krheinwald' (krheinwald)]
>
> http://forums.java.net/jive/thread.jspa?messageID=240023

krheinwald
Offline
Joined: 2004-06-25
Points: 0

[i]UIManager.getColor("TableHeader.background")
UIManager.getColor("Table.foreground")
UIManager.getColor("Table.selectionForeground")
UIManager.getColor("Table.selectionBackground")
UIManager.getBorder("TableHeader.cellBorder")
UIManager.getBorder("Table.cellBorder")[/i]

all return NULL with Nimbus while returning proper values on all the other L&Fs I have seen yet (Metal and Windows on my PC, Aqua on Mac,GTK on Ubuntu, Substance, Synthetica, etc...

Interestingly,

[i]UIManager.getColor("Table.background")[/i]

properly returns white.

Further, setting

[i]UIManager.put("AuditoryCues.playList", UIManager.get("AuditoryCues.defaultCueList"));[/i]

makes most of the L&Fs to play a auditory cue when showing a JOptionPane whioch Nuimbus doesn't and

JTextArea.setOpaque(false)

seems to be ignored.

HTH,
Klaus

kirillcool
Offline
Joined: 2004-11-17
Points: 0

UIManager.put("AuditoryCues.playList", UIManager.get("AuditoryCues.defaultCueList")); works only under LAFs that extend either Metal or Windows. LAFs that extend Basic do not have the second entry.

krheinwald
Offline
Joined: 2004-06-25
Points: 0

If it's not a bug(?), let me rephrase it as a RFE, the sound files are in resources.jar\javax\swing\plaf\metal\sounds.

Klaus

roger_rf
Offline
Joined: 2007-10-04
Points: 0

Hi Richard,

Here are a few issues I found under Nimbus (sorry in advance for my poor English skills):

- Toolbar buttons don't get rendered when the toolbar's orientation is vertical. (Horizontal orientation works fine);
- 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;
- 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. 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;
- 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;
- 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;
- When you use FlowLayout, two components directly beside each other have a quite wide gap between them, it could be narrower;
- 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;
- Component tooltips have a thin gray outline on the top and right sections, but there's no outline in the bottom and left sections;
- 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?

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,

Roger

Richard Bair

Hi Roger!

> Here are a few issues I found under Nimbus (sorry in advance for my
> poor English skills):

Thank you very much for taking the time to report them.

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

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

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

> 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!

> - 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?

> - 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?

> - 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?

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

> - 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".

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

> 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

swpalmer
Offline
Joined: 2003-06-10
Points: 0

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

Richard Bair

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

Also fixed in b06. Although this one is really a symptom of a much
larger bug that needs to be resolved in the general case. Synth uses
it's own SynthComboBoxRenderer which extends JLabel. All the styling
and such done to the combo box renderer is done to that renderer. If
you set your own DefaultListCellRenderer, then you lose the magic in
SynthComboBoxRenderer. In particular, DefaultListCellRenderer is
opaque, which is why you see that white block.

In FileChooser I get around this by wrapping the
SynthComboBoxRenderer and delegating to it rather than replacing it
with a DefaultListCellRenderer. Works fine here, but doesn't fix the
general problem: using DefaultListCellRenderer with Nimbus on
ComboBox's won't work as expected. This one should be fixed by b06 or
b07.

Richard

Richard Bair

> Is there a list of known issues with Nimbus?

Good question. All our bugs are in the bug database, but I can't seem
to see them on the web via bugs.sun.com. I'll see what's up with that.

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

Yep, this one is fixed and will be available in build 06.

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".

OOops, just kidding :-). Wrong bug. Here it is: http://bugs.sun.com/
bugdatabase/view_bug.do?bug_id=6601200

I actually still have this one in a local workspace, merging it back
into a shared workspace today. But it is fixed.

Richard

swpalmer
Offline
Joined: 2003-06-10
Points: 0

> In FileChooser I get around this by wrapping the
> SynthComboBoxRenderer and delegating to it rather
> than replacing it
> with a DefaultListCellRenderer. Works fine here, but
> doesn't fix the
> general problem: using DefaultListCellRenderer with
> Nimbus on
> ComboBox's won't work as expected. This one should be
> fixed by b06 or b07.

It sounds from your description that this fix will be confined to the case of DefaultListCellRenderer with JComboBox on Nimbus and not the more general case of using DefaultListCellRenderer with Synth. Is that correct? If so, this would be a great thing for somebody to write a tech article or blog about so that others that want to use Synth won't have to struggle so much with these issues.

Richard Bair

>> In FileChooser I get around this by wrapping the
>> SynthComboBoxRenderer and delegating to it rather
>> than replacing it
>> with a DefaultListCellRenderer. Works fine here, but
>> doesn't fix the
>> general problem: using DefaultListCellRenderer with
>> Nimbus on
>> ComboBox's won't work as expected. This one should be
>> fixed by b06 or b07.
>
> It sounds from your description that this fix will be confined to
> the case of DefaultListCellRenderer with JComboBox on Nimbus and
> not the more general case of using DefaultListCellRenderer with
> Synth. Is that correct? If so, this would be a great thing for
> somebody to write a tech article or blog about so that others that
> want to use Synth won't have to struggle so much with these issues.

Yes, that's correct, the fix was just for file chooser right now.

However, I have a more general fix in mind, so hopefully people will
be able to use combo box with existing code without having to change
anything.

Richard

Richard Bair

On Oct 2, 2007, at 8:02 AM, Richard Bair wrote:

>> Is there a list of known issues with Nimbus?
>
> Good question. All our bugs are in the bug database, but I can't
> seem to see them on the web via bugs.sun.com. I'll see what's up
> with that.

My bad, they are there. I thought I was searching classes_swing, but
had classes_text instead :-)

http://bugs.sun.com/bugdatabase/search.do?
process=1&category=java&bugStatus=&subcategory=classes_swing&type=&keywo
rd=Nimbus

We've been filing all bugs with the prefix Nimbus L&F: . Sometimes
Nimbus LAF was used.

Thanks
Richard