Re: [cp-patches] Patch: view in JScrollPane
Can I get approval to commit this patch? Thank you! On Fri, 2005-06-17 at 11:17 -0400, Lillian Angel wrote: I fixed the Patch in this attachment to not include the ChangeLog. Sorry about that. 2005-06-17 Lillian Angel [EMAIL PROTECTED] * javax/swing/JScrollPane.java (JScrollPane): Viewport was not being set when the view was null. Whenever a view would be added to container it would not appear. This was changed to use setViewportView. - Lillian. ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: view in JScrollPane
Lillian Angel wrote: Can I get approval to commit this patch? Please do. Sorry, I forgot this. /Roman ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: Reformatted Swing classes
I reformatted a bunch of classes in javax.swing. 2005-06-20 Roman Kennke [EMAIL PROTECTED] * javax/swing/AbstractButton.java: * javax/swing/AbstractCellEditor.java: * javax/swing/Action.java: * javax/swing/BorderFactory.java: * javax/swing/ButtonGroup.java: * javax/swing/CellRendererPane.java: * javax/swing/DebugGraphics.java: * javax/swing/DefaultBoundedRangeModel.java: * javax/swing/DefaultButtonModel.java: * javax/swing/DefaultCellEditor.java: * javax/swing/DefaultComboBoxModel.java: * javax/swing/DefaultDesktopManager.java: * javax/swing/DefaultFocusManager.java: * javax/swing/DefaultListCellRenderer.java: * javax/swing/DefaultListModel.java: * javax/swing/DefaultListSelectionModel.java: * javax/swing/FocusManager.java: * javax/swing/GrayFilter.java: * javax/swing/ImageIcon.java: * javax/swing/JButton.java: * javax/swing/JCheckBoxMenuItem.java: * javax/swing/JColorChooser.java: * javax/swing/JComboBox.java: * javax/swing/JComponent.java: * javax/swing/JDesktopPane.java: Reformatted these sourcefiles to better match our coding style. /Roman 03_Reformatting.diff.gz Description: GNU Zip compressed data ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: preferredSize in JComponent
We already had two fixes in the last weeks about this issue. The problem
was that preferredSize must not be less than minimumSize. The solution
so far has been to adjust preferredSize when minimumSize is set. This
has the sideeffect that getPreferredSize() is called too early or (after
Marks fix) that the preferredSize of the ComponentUI is not recognized.
This new fix solves the problem at the other end: when calling
getPreferredSize (not on setMinimumSize) we check if it is less than
minimumSize and adjust if necessary.
2005-06-20 Roman Kennke [EMAIL PROTECTED]
* javax/swing/JComponent.java
(getPreferredSize): Make sure that preferredSize is greater than
minimumSize.
(setMinimumSize): Removed hack to adjust preferredSize. This is moved
into the method getPreferredSize().
/Roman
Index: javax/swing/JComponent.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/JComponent.java,v
retrieving revision 1.44
diff -u -r1.44 JComponent.java
--- javax/swing/JComponent.java 20 Jun 2005 13:27:59 - 1.44
+++ javax/swing/JComponent.java 20 Jun 2005 13:54:09 -
@@ -1024,17 +1024,25 @@
*/
public Dimension getPreferredSize()
{
+Dimension prefSize = null;
if (preferredSize != null)
- return preferredSize;
+ prefSize = preferredSize;
if (ui != null)
{
Dimension s = ui.getPreferredSize(this);
if (s != null)
- return s;
+ prefSize = s;
}
-Dimension p = super.getPreferredSize();
-return p;
+if (prefSize == null)
+ prefSize = super.getPreferredSize();
+// make sure that prefSize is not smaller than minSize
+if (minimumSize != null prefSize != null
+ (minimumSize.width prefSize.width
+|| minimumSize.height prefSize.height))
+prefSize = new Dimension(Math.max(minimumSize.width, prefSize.width),
+ Math.max(minimumSize.height,
prefSize.height));
+return prefSize;
}
/**
@@ -2063,22 +2071,6 @@
firePropertyChange(minimumSize, oldMinimumSize, minimumSize);
revalidate();
repaint();
-
-// adjust preferred and maximum size accordingly
-if (preferredSize != null)
- {
- Dimension prefSize = getPreferredSize();
- prefSize.width = Math.max(prefSize.width, minimumSize.width);
- prefSize.height = Math.max(prefSize.height, minimumSize.height);
- setPreferredSize(prefSize);
- }
-if (maximumSize != null)
- {
- Dimension maxSize = getMaximumSize();
- maxSize.width = Math.max(maxSize.width, minimumSize.width);
- maxSize.height = Math.max(maxSize.height, minimumSize.height);
- setMaximumSize(maxSize);
- }
}
/**
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch: Bug #13420 JInternalFrame default close operation
Permission to commit the following patch? Or will a maintainer please
commit?
This patches fixes bug #13420, allows invalid close operations to be
specified for JInternalFrame and JFrame without throwing an Error. If
the specified close operation is invalid, the components default close
operation is used instead.
2005-06-20 Anthony Balkissoon [EMAIL PROTECTED]
* javax/swing/JFrame.java,
javax/swing/JInternalFrame.java:
(setDefaultCloseOperation): Added check for invalid close
operation. If invalid, use default behaviour.
Index: javax/swing/JFrame.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/JFrame.java,v
retrieving revision 1.23
diff -u -r1.23 JFrame.java
--- javax/swing/JFrame.java 17 Jun 2005 11:53:50 - 1.23
+++ javax/swing/JFrame.java 20 Jun 2005 15:26:53 -
@@ -331,8 +331,7 @@
* When codeEXIT_ON_CLOSE/code is specified this method calls
* codeSecurityManager.checkExit(0)/code which might throw a
* codeSecurityException/code. When the specified operation is
- * not one of the above a codeIllegalArgumentException/code is
- * thrown.
+ * not one of the above use default HIDE_ON_CLOSE.
*/
public void setDefaultCloseOperation(int operation)
{
@@ -342,8 +341,8 @@
if (operation != EXIT_ON_CLOSE operation != DISPOSE_ON_CLOSE
operation != HIDE_ON_CLOSE operation != DO_NOTHING_ON_CLOSE)
- throw new IllegalArgumentException(operation = + operation);
-
-close_action = operation;
+ close_action = HIDE_ON_CLOSE;
+else
+ close_action = operation;
}
}
Index: javax/swing/JInternalFrame.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/JInternalFrame.java,v
retrieving revision 1.17
diff -u -r1.17 JInternalFrame.java
--- javax/swing/JInternalFrame.java 17 Jun 2005 11:53:50 - 1.17
+++ javax/swing/JInternalFrame.java 20 Jun 2005 15:26:53 -
@@ -1297,19 +1297,20 @@
/**
* This method sets the action taken when this JInternalFrame is closed.
+ * Defaults to DISPOSE_ON_CLOSE if operation is not a legal value.
*
* @param operation One of DO_NOTHING_ON_CLOSE, HIDE_ON_CLOSE or
*DISPOSE_ON_CLOSE.
*
- * @throws Error If the given operation is not one of the allowed modes.
*/
public void setDefaultCloseOperation(int operation)
{
if (operation != DO_NOTHING_ON_CLOSE
operation != HIDE_ON_CLOSE
operation != DISPOSE_ON_CLOSE)
- throw new Error(Close operation must be one of DO_NOTHING_ON_CLOSE, HIDE_ON_CLOSE, or DISPOSE_ON_CLOSE);
-defaultCloseOperation = operation;
+ defaultCloseOperation = DISPOSE_ON_CLOSE;
+else
+ defaultCloseOperation = operation;
}
/**
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: removing 'a.diff'
I'm deleting the mistakenly added 'a.diff'. I'm not writing a ChangeLog entry for this since it is just a mistake and has no bearing on the real history of the sources. But, I thought I'd send email here in case somebody sees the commit and is curious. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [RFA/JDWP] IdManager
On Mon, 2005-06-20 at 10:22 -0500, Archie Cobbs wrote: Keith Seitz wrote: + /* Mapping of class (Class) to IDs (ReferenceTypeId) for reference + types. Unlike other types, reference id types are NEVER released. */ + private Hashtable _classTable; Another question born from my own ignorance... :-) What if a class(loader)s are garbage collected? Would this hash table then become a memory leak?gets Yes, but unfortunately, JDWP specifically says that reference type IDs are never reused, even if the classes are gc'd or unloaded. The same ID is valid for any reference type for the entirety of the debugging session. Or at least that's how I interpret this explanation of referenceTypeId: Uniquely identifies a reference type in the target VM. It should not be assumed that for a particular class, the classObjectID and the referenceTypeID are the same. A particular reference type will be identified by exactly one ID in JDWP commands and replies throughout its lifetime A referenceTypeID is not reused to identify a different reference type, regardless of whether the referenced class has been unloaded. ? Keith ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: #13419 JOptionPane.showInputDialog multi-line
Tony == Anthony Balkissoon [EMAIL PROTECTED] writes:
Tony 2005-06-17 Anthony Balkissoon [EMAIL PROTECTED]
Tony * javax/swing/SwingUtilities.java:
Tony (layoutCompoundLabel): Added check for multi-line text.
Just a minor nit...
Tony +fromIndex=text.indexOf('\n', fromIndex)+1;
Operators need spaces around them:
+fromIndex = text.indexOf('\n', fromIndex) + 1;
Tom
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [RFA/JDWP] IdManager
Keith Seitz wrote: + /* Mapping of class (Class) to IDs (ReferenceTypeId) for reference + types. Unlike other types, reference id types are NEVER released. */ + private Hashtable _classTable; What if a class(loader)s are garbage collected? Would this hash table then become a memory leak?gets Yes, but unfortunately, JDWP specifically says that reference type IDs are never reused, even if the classes are gc'd or unloaded. The same ID is valid for any reference type for the entirety of the debugging session. Or at least that's how I interpret this explanation of referenceTypeId: Uniquely identifies a reference type in the target VM. It should not be assumed that for a particular class, the classObjectID and the referenceTypeID are the same. A particular reference type will be identified by exactly one ID in JDWP commands and replies throughout its lifetime A referenceTypeID is not reused to identify a different reference type, regardless of whether the referenced class has been unloaded. This seems to only imply that whoever is creating ReferenceTypeID's must create a new and unique one every time, not that you need to cache them after the associated class has been unloaded... ? In any case, how is a class ever going to be unloaded if your Hashtable is referencing it? :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Bug #13420 JInternalFrame default close operation
Am Montag, den 20.06.2005, 11:35 -0400 schrieb Anthony Balkissoon: Permission to commit the following patch? Or will a maintainer please commit? This patches fixes bug #13420, allows invalid close operations to be specified for JInternalFrame and JFrame without throwing an Error. If the specified close operation is invalid, the components default close operation is used instead. Please check what the correct close operation is for the invalid case. If I remember correctly, the JDK does DO_NOTHING_ON_CLOSE or what this was called. Ideally you would implement a Mauve testcase for that. /Roman ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: adding to top-level containers
Am Montag, den 20.06.2005, 12:06 -0600 schrieb Tom Tromey: Roman == Roman Kennke [EMAIL PROTECTED] writes: Roman this is cool, thank you. Generally I would prefer to go for 1.4 Roman compatibility and completeness first, and add 1.5 stuff later Any particular reason? I think it makes sense to channel the efforts a little bit. Especially in Swing there is lots of basic stuff not working, so it would be nice to have this first. This whole stuff is a mess and has to be sorted out somehow. It seems to me that a fair amount of 1.5 stuff has already gone into cvs head. And, we know we're going to need it sometime anyway. So if somebody writes it, we might as well just put it in. Yeah sure, if somebody writes it, why not take it. But the limited human resource would be better spend with fixing the basic stuff that does not yet work, hence my suggestion. But you are right, if something 1.5 is done, it would be stupid to reject it (at least if it doesn't break serious stuff). /Roman ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Null check after dereference ingnu.xml.aelfred2.XmlParser
Impressive! - Original Message - From: Lillian Angel [EMAIL PROTECTED] To: classpath-patches@gnu.org Sent: Monday, June 20, 2005 10:24 PM Subject: [cp-patches] Patch: Null check after dereference ingnu.xml.aelfred2.XmlParser fixes bug #13458 2005-06-20 Lillian Angel [EMAIL PROTECTED] * gnu/xml/aelfred2/XmlParser (parseAttribute): if (type.equals(CDATA) || type == null) this would always throw a NullPointerException if type is null. I can commit this if someone approves of it first. Thanks! Lillian. ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: Null check after dereference in javax.swing.DefaultDesktopManager
ChangeLog explains it all. Avoids NullPointerException 2005-06-20 Lillian Angel [EMAIL PROTECTED] * javax/swing/DefaultDesktopManager (getBoundsForIconOf): No reason to check if desktopPane is null after dereferencing desktopPane in code. Fixes bug #13461. Committed! Lillian. Index: javax/swing/DefaultDesktopManager.java === RCS file: /cvsroot/classpath/classpath/javax/swing/DefaultDesktopManager.java,v retrieving revision 1.10 diff -u -r1.10 DefaultDesktopManager.java --- javax/swing/DefaultDesktopManager.java 20 Jun 2005 14:35:53 - 1.10 +++ javax/swing/DefaultDesktopManager.java 20 Jun 2005 20:02:02 - @@ -516,14 +516,15 @@ // the bottom left corner) // The icon also must not be placed where another icon is placed // (regardless whether that frame is an icon currently or not) -JDesktopPane desktopPane = frame.getDesktopPane(); + + if (desktopPane == null) + return frame.getDesktopIcon().getBounds(); + + JDesktopPane desktopPane = frame.getDesktopPane(); Rectangle paneBounds = desktopPane.getBounds(); Insets insets = desktopPane.getInsets(); Dimension pref = frame.getDesktopIcon().getPreferredSize(); -if (desktopPane == null) - return frame.getDesktopIcon().getBounds(); - Component[] frames = desktopPane.getComponents(); int count = 0; ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Null check after dereference ingnu.xml.aelfred2.XmlParser
took me all day ;) just kidding! On Mon, 2005-06-20 at 22:56 +0200, Meskauskas Audrius wrote: Impressive! - Original Message - From: Lillian Angel [EMAIL PROTECTED] To: classpath-patches@gnu.org Sent: Monday, June 20, 2005 10:24 PM Subject: [cp-patches] Patch: Null check after dereference ingnu.xml.aelfred2.XmlParser fixes bug #13458 2005-06-20 Lillian Angel [EMAIL PROTECTED] * gnu/xml/aelfred2/XmlParser (parseAttribute): if (type.equals(CDATA) || type == null) this would always throw a NullPointerException if type is null. I can commit this if someone approves of it first. Thanks! Lillian. ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: Adding public parameterless constructor form HTML.Tag.
Adding public parameterless constructor form HTML.Tag. This constructor appeared since 1.3. It may be very strange to see toString() method returning null, but the Suns implementation does exactly the same. 2005-06-07 Audrius Meskauskas [EMAIL PROTECTED] * javax/swing/text/html/HTML.java (Tag): Added public parameterless constructor. HTML.java.patch Description: Binary data ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch for logging
Hi Chris, On Sat, 2005-06-18 at 13:31 +0100, Chris Burdess wrote: This patch sets the root logger's level to INFO. The root logger's behaviour is inherited by all loggers by default, so this specifies the default level. This means that by default, loggers will actually log something. 2005-06-18 Chris Burdess [EMAIL PROTECTED] * java/util/logging/LogManager.java: Set default level of root logger to INFO. Please commit this if it works for you. It makes sense since it is the same things that is done for the rootLogger in reset(). Please add a line of documentation about this to the constructor or class doc and don't forget to update the copyright year at the top. Thanks, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
