Name: keR10081			Date: 08/27/2003


In current implementation of the PropertyChangeListener that handles
change of CHOOSER_PANELS_PROPERTY we do things wrong. Namely, we delete
all old panels, then add all new panels and call installChooserPanel on
each of the new panels. This leads us to calling this method several
times on the panels which are present both in old and new panels. This
call in turn calls buildChooser which adds contents of the panel to it
once again. This is not noticeable in metal/motif/windows LaFs, since it
adds the contents to the BorderLayout.CEnTER, so there is no visual
appearance of the bug, only memory leak, but is well noticeable with GTK
LaF, where we have FlowLayout and thus see ugly chooser panel. This
could be seen running test case, which simply adds a custom panel to a
GTK color chooser, causing it to look ugly.

Test case:
import javax.swing.*;
import java.awt.event.*;

import javax.swing.colorchooser.AbstractColorChooserPanel;
public class ColorChooserBug {
	public static void main(String[] args) {

try{UIManager.setLookAndFeel("com.sun.java.swing.plaf.gtk.GTKLookAndFeel");} 

catch(Exception ex){ex.printStackTrace();}
		final JFrame frame = new JFrame("Test");
		JColorChooser cc = new JColorChooser();
		cc.addChooserPanel(new AbstractColorChooserPanel() {
			public void updateChooser() {}
			protected void buildChooser() {
                         removeAll();
				add(new JLabel("This is an added panel"));
			}
			public String getDisplayName() {
				return "Added Tab";
			}
			public Icon getSmallDisplayIcon() { return null;}
			public Icon getLargeDisplayIcon() { return null;}
		});
		frame.getContentPane().add(cc);
		frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
		frame.pack();
		frame.show();
	}
}

======================================================================
###@###.### 10/25/04 12:39 GMT