Re: [cp-patches] RFC: LightweightPeers reworked
On Tue, 2006-02-21 at 19:11 -0500, Lillian Angel wrote: > +// This should be overridden by default Toolkit (eg. GtkToolkit). > +// If target is an instance of Container, then a > GtkLightweightContainerPeer > +// should be returned. Otherwise, an instance of > LightweightComponentPeer is > +// returned for Components. This is because, all the properties > of a > +// Container should be accessible (bounds, location etc). > +// LightweightComponentPeers really are lightweight, but a > +// GtkLightweightContainerPeer is different because it still > +// has a backing widget that tracks its bounds/location for use > +// by the native side. A GtkLightweightContainerPeer is > lightweight as > +// well because it does not allocate screen resources. This comment should be moved out of Toolkit and into GtkToolkit. GtkLightweightContainerPeer needs to override GtkComponentPeer painting methods to be no-ops: handleEvent and postExposeEvent. GtkLightweightContainerPeer.repaint should be overridden to be LightweightComponentPeer's implementation. Overriding all these methods should eliminate the flicker we were seeing in the Swing demo: Roman pointed out that lightweight peers should never call paint directly or post paint events. With these changes, this patch looks good to me. Tom
Re: [cp-patches] RFC: LightweightPeers reworked
On Tue, 2006-02-21 at 14:52 -0500, Scott Gilbertson wrote: > The ideal situation would probably be to have: > gnu.awt.peer.LightweightContainerPeer > (implementing ContainerPeer) and perhaps subclass GtkContainerPeer from > that. Then the base implementation of java.awt.Toolkit.createComponent > could return either a LightweightComponentPeer ... > > Within the Classpath tree, QtToolkit doesn't override createComponent > either, so it probably has the same issue. > > A related problem with the patch as it stands is that the comment at the top > of the non-peer-specific class LightweightComponentPeer says to use a > peer-specific class (GtkLightweightContainerPeer) for lightweight > Containers. The comment is only reasonable for those using GTK peers. I made these changes to the patch. I changed back Toolkit.createComponent to return an instance of LightweightComponentPeer and I fixed the comment. Below is the updated ChangeLog. Attached is the updated patch. A couple of mauve tests were committed for this (gnu/testlet/java/awt/Container/LightweightContainer). Tom asked me to post the memory usage for the swing demo with and without this patch. There is a negligible difference: With patch: vm size 220.8mb, res 20.7mb, shared 5.4mb Without patch: vm size 220.1mb, res 20.1, shared 5.3mb Feel free to send your feedback, I will not commit this until everyone has had a chance to look it over. 2006-02-21 Lillian Angel <[EMAIL PROTECTED]> * gnu/java/awt/peer/gtk/GtkLightweightContainerPeer.java: New class to handle Container Lightweights. This class implements ContainerPeer. * gnu/java/awt/peer/gtk/GtkToolkit.java: Fixed imports. (createComponent): New method to override Toolkit's createComponent. Returns an instance of GtkLightweightPeer if the target is a container, and a LightweightComponentPeer if the target is a Component. * include/Makefile.am: Added gnu_java_awt_peer_gtk_GtkLightweightContainerPeer.h. * include/gnu_java_awt_peer_gtk_GtkLightweightContainterPeer.h: New header file. * java/awt/Toolkit.java (createComponent): Changed to return an instance of LightweightComponentPeer. This method should be overridden. Added comment explaining why. * native/jni/gtk-peer/Makefile.am: Added gnu_java_awt_peer_gtk_GtkLightweightContainerPeer.c. * native/jni/gtk-peer/gnu_java_awt_peer_gtk_ GtkLightweightContainerPeer.c: New class. * gnu/java/awt/peer/GLightweightPeer.java: Removed class, replaced with LightweightComponentPeer. * gnu/java/awt/peer/LightweightComponentPeer.java: New class. Replaces GLightweightPeer, but only implements ComponentPeer now. Updated comments. (repaint): Incorporate Scott's patch. Sends event to parent. * gnu/java/awt/peer/gtk/GtkComponentPeer.java (setParent): Removed check for LightweightPeer. The parent should be set for all components. (setBounds): Removed code for lightweights. The placement of the lightweight containers is now handled by GtkLightweightContainerPeer. * gnu/java/awt/peer/gtk/GtkContainerPeer.java (endValidate): Removed comment. * java/awt/Graphics.java (hitClip): Incorporates Scott's patch to handle null clip. Index: gnu/java/awt/peer/GLightweightPeer.java === RCS file: gnu/java/awt/peer/GLightweightPeer.java diff -N gnu/java/awt/peer/GLightweightPeer.java --- gnu/java/awt/peer/GLightweightPeer.java 19 Aug 2005 01:29:26 - 1.6 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,339 +0,0 @@ -/* GLightweightPeer.java -- - Copyright (C) 2003, 2004 Free Software Foundation, Inc. - -This file is part of GNU Classpath. - -GNU Classpath is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2, or (at your option) -any later version. - -GNU Classpath is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with GNU Classpath; see the file COPYING. If not, write to the -Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA -02110-1301 USA. - -Linking this library statically or dynamically with other modules is -making a combined work based on this library. Thus, the terms and -conditions of the GNU General Public License cover the whole -combination. - -As a special exception, the copyright holders of this library give you -permission to link this library with independent modules to produce an -executable, regardless of the license te
[cp-patches] [generics] new BigDecimal methods.
Here are some of the missing BigDecimal methods. More are coming but
I'm committing these now so the JAPI results will be more readable.
2006-02-21 Anthony Balkissoon <[EMAIL PROTECTED]>
* java/math/BigDecimal.java:
(mathContext): New field.
(precision): Likewise.
(BigDecimal(int)): New constructor.
(BigDecimal(long)): Likewise.
(BigDecimal(BigInteger)): Added API docs.
(BigDecimal(BigInteger, int)): Removed incorrect NumberFormatException
and added API docs.
(plus): New method.
(round): Likewise.
(precision): Likewise.
(valueOf): Likewise.
(numDigitsInLong): New implementation method.
--Tony
Index: java/math/BigDecimal.java
===
RCS file: /cvsroot/classpath/classpath/java/math/BigDecimal.java,v
retrieving revision 1.17.2.5
diff -u -r1.17.2.5 BigDecimal.java
--- java/math/BigDecimal.java 2 Nov 2005 00:43:34 - 1.17.2.5
+++ java/math/BigDecimal.java 21 Feb 2006 21:07:26 -
@@ -41,6 +41,8 @@
{
private BigInteger intVal;
private int scale;
+ private MathContext mathContext;
+ private int precision = 0;
private static final long serialVersionUID = 6108874887143696463L;
/**
@@ -73,15 +75,47 @@
public static final int ROUND_HALF_EVEN = 6;
public static final int ROUND_UNNECESSARY = 7;
+ /**
+ * Constructs a new BigDecimal whose unscaled value is val and whose
+ * scale is zero.
+ * @param val the value of the new BigDecimal
+ * @since 1.5
+ */
+ public BigDecimal (int val)
+ {
+this.intVal = BigInteger.valueOf(val);
+this.scale = 0;
+ }
+
+ /**
+ * Constructs a new BigDecimal whose unscaled value is val and whose
+ * scale is zero.
+ * @param val the value of the new BigDecimal
+ */
+ public BigDecimal (long val)
+ {
+this.intVal = BigInteger.valueOf(val);
+this.scale = 0;
+ }
+
+ /**
+ * Constructs a BigDecimal whose unscaled value is num and whose
+ * scale is zero.
+ * @param num the value of the new BigDecimal
+ */
public BigDecimal (BigInteger num)
{
this (num, 0);
}
- public BigDecimal (BigInteger num, int scale) throws NumberFormatException
+ /**
+ * Constructs a BigDecimal whose unscaled value is num and whose
+ * scale is scale.
+ * @param num
+ * @param scale
+ */
+ public BigDecimal (BigInteger num, int scale)
{
-if (scale < 0)
- throw new NumberFormatException ("scale of " + scale + " is < 0");
this.intVal = num;
this.scale = scale;
}
@@ -455,7 +489,108 @@
{
return new BigDecimal (intVal.negate (), scale);
}
+
+ /**
+ * Returns this BigDecimal. This is included for symmetry with the
+ * method negate().
+ * @return this
+ * @since 1.5
+ */
+ public BigDecimal plus()
+ {
+return this;
+ }
+
+ /**
+ * Returns a BigDecimal which is this BigDecimal rounded according to the
+ * MathContext rounding settings.
+ * @param mc the MathContext that tells us how to round
+ * @return the rounded BigDecimal
+ */
+ public BigDecimal round(MathContext mc)
+ {
+int mcPrecision = mc.getPrecision();
+int numToChop = precision - mcPrecision;
+// If mc specifies not to chop any digits or if we've already chopped
+// enough digits (say by using a MathContext in the constructor for this
+// BigDecimal) then just return this.
+if (mcPrecision == 0 || numToChop <= 0)
+ return this;
+
+// Make a new BigDecimal which is the correct power of 10 to chop off
+// the required number of digits and then call divide.
+BigDecimal div =
+ new BigDecimal(BigInteger.valueOf((long)Math.pow(10, numToChop)));
+BigDecimal rounded = divide(div, scale, mc.getRoundingMode().ordinal());
+rounded.scale -= numToChop;
+return rounded;
+ }
+
+ /**
+ * Returns the precision of this BigDecimal (the number of digits in the
+ * unscaled value). The precision of a zero value is 1.
+ * @return the number of digits in the unscaled value, or 1 if the value
+ * is zero.
+ */
+ public int precision()
+ {
+if (precision == 0)
+ precision = numDigitsInLong(intVal.longValue());
+return precision;
+ }
+ /**
+ * This method determines the number of digits in the long value l.
+ * @param l the long value
+ * @return the number of digits in l
+ */
+ private static int numDigitsInLong(long l)
+ {
+// We divide up the range in a binary fashion, this first if
+// takes care of numbers with 1 to 9 digits.
+if (l < 10L)
+{
+ // This if is for numbers with 1 to 5 digits.
+ if (l < 10L)
+{
+ if (l < 100L)
+return (l < 10L) ? 1 : 2;
+ if (l < 1L)
+return (l < 1000L) ? 3 : 4;
+ return 5;
+}
+ // Here we handle numbers with 6 to 9 digits.
+ if (l < 1000L)
+return (l < 100L) ?
Re: [cp-patches] RFC: LightweightPeers reworked
> From: "Thomas Fitzsimmons" > OK, a few comments: > > +public class LightweightComponentPeer > + implements LightweightPeer, ContainerPeer > > Does LightweightComponentPeer still need to implement ContainerPeer or > can it just implement ComponentPeer? Just implementing ComponentPeer should be OK, except that it requires every peer Toolkit (in libjava, XToolkit for example) to do what GtkToolkit.createComponent does, namely return either a LightweightContainerPeer or a ContainerPeer subclass. The ideal situation would probably be to have: gnu.awt.peer.LightweightContainerPeer (implementing ContainerPeer) and perhaps subclass GtkContainerPeer from that. Then the base implementation of java.awt.Toolkit.createComponent could return either a LightweightComponentPeer or LightweightContainerPeer, depending on the type of Component. That way I wouldn't have to modify XToolkit, which does not override createComponent, the next time Classpath is merged into GCJ. Within the Classpath tree, QtToolkit doesn't override createComponent either, so it probably has the same issue. A related problem with the patch as it stands is that the comment at the top of the non-peer-specific class LightweightComponentPeer says to use a peer-specific class (GtkLightweightContainerPeer) for lightweight Containers. The comment is only reasonable for those using GTK peers.
Re: [cp-patches] RFC: LightweightPeers reworked
> OK, a few comments: > > +public class LightweightComponentPeer > + implements LightweightPeer, ContainerPeer > > Does LightweightComponentPeer still need to implement ContainerPeer or > can it just implement ComponentPeer? > No, it does not need to implement ContainerPeer. It is enough to just implement ComponentPeer. > - > -// Skip lightweight peers. > + > > Actually we do still need to skip lightweight peers here (and the patch > doesn't change the behaviour) so the comment should stay. Ok, fixed. > +// This should be overridden by default Toolkit (eg. GtkToolkit). > +// If target is an instance of Container, then a GtkLightweightPeer > +// should be returned. Otherwise, an instance of GLightweightPeer > is > +// returned for Components. This is because, all the properties of > a > +// Container should be accessible (bounds, location etc). > +// A lightweight Component should _just_ be drawn on its parent > window, > +// but we should be able to reshape a Container. Therefore, > Component > +// and Container lightweights should be treated differently. > > You need to update the class names in this comment and the comment could > be clearer. The reason for the distinction is that > LightweightComponentPeers really are lightweight but > GtkLightweightContainerPeer is lightweight in that it doesn't allocate > screen resources but it still has a backing widget that tracks its > bounds and location for use by the native side. Oops, yes. Fixed. Attached is a new patch. I will work on committing a couple of mauve tests for these changes. Lillian Index: gnu/java/awt/peer/GLightweightPeer.java === RCS file: gnu/java/awt/peer/GLightweightPeer.java diff -N gnu/java/awt/peer/GLightweightPeer.java --- gnu/java/awt/peer/GLightweightPeer.java 19 Aug 2005 01:29:26 - 1.6 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,339 +0,0 @@ -/* GLightweightPeer.java -- - Copyright (C) 2003, 2004 Free Software Foundation, Inc. - -This file is part of GNU Classpath. - -GNU Classpath is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2, or (at your option) -any later version. - -GNU Classpath is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with GNU Classpath; see the file COPYING. If not, write to the -Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA -02110-1301 USA. - -Linking this library statically or dynamically with other modules is -making a combined work based on this library. Thus, the terms and -conditions of the GNU General Public License cover the whole -combination. - -As a special exception, the copyright holders of this library give you -permission to link this library with independent modules to produce an -executable, regardless of the license terms of these independent -modules, and to copy and distribute the resulting executable under -terms of your choice, provided that you also meet, for each linked -independent module, the terms and conditions of the license of that -module. An independent module is a module which is not derived from -or based on this library. If you modify this library, you may extend -this exception to your version of the library, but you are not -obligated to do so. If you do not wish to do so, delete this -exception statement from your version. */ - - -package gnu.java.awt.peer; - -import java.awt.AWTEvent; -import java.awt.AWTException; -import java.awt.BufferCapabilities; -import java.awt.Color; -import java.awt.Component; -import java.awt.Cursor; -import java.awt.Dimension; -import java.awt.Font; -import java.awt.FontMetrics; -import java.awt.Graphics; -import java.awt.GraphicsConfiguration; -import java.awt.Image; -import java.awt.Insets; -import java.awt.Point; -import java.awt.Rectangle; -import java.awt.Toolkit; -import java.awt.event.PaintEvent; -import java.awt.image.ColorModel; -import java.awt.image.ImageObserver; -import java.awt.image.ImageProducer; -import java.awt.image.VolatileImage; -import java.awt.peer.ContainerPeer; -import java.awt.peer.LightweightPeer; - -/* - * Another possible implementation strategy for lightweight peers is - * to make GLightweightPeer a placeholder class that implements - * LightweightPeer. Then the Component and Container classes could - * identify a peer as lightweight and handle it specially. The - * current approach is probably more clear but less efficient. - */ - -/** - * A stub class that implements the ComponentPeer and ContainerPeer - * interfaces using callbacks into the Component and Container - * class
Re: [cp-patches] RFC: LightweightPeers reworked
Update - my JamVM setup is working now (Thanks Robert Lougher) so I can
confirm that the LightweightRepaintTest program fails with JamVM + Classpath
(recent from cvs) + GTK peers. So it looks like my GLightweightPeer.repaint
changes are indeed required to pass that test. Without the patch, the
repaint method for a lightweight Component doesn't do anything.
Here is the patch with Mark Wielaard's recent observations taken into
account:
Index: libjava/classpath/gnu/java/awt/peer/GLightweightPeer.java
===
--- gnu/java/awt/peer/GLightweightPeer.java (revision 110719)
+++ gnu/java/awt/peer/GLightweightPeer.java (working copy)
@@ -227,7 +227,12 @@ public class GLightweightPeer
public void print(Graphics graphics) {}
- public void repaint(long tm, int x, int y, int width, int height) {}
+ public void repaint(long tm, int x, int y, int width, int height)
+ {
+Component p = comp.getParent ();
+if(p != null)
+ p.repaint(tm,x+comp.getX(),y+comp.getY(),width,height);
+ }
public void requestFocus() {}
Index: java/awt/Graphics.java
===
--- java/awt/Graphics.java (revision 110719)
+++ java/awt/Graphics.java (working copy)
@@ -617,6 +617,9 @@ public abstract class Graphics
*/
public boolean hitClip(int x, int y, int width, int height)
{
+Shape clip = getClip();
+if (clip == null)
+ return true;
return getClip().intersects(x, y, width, height);
}
- Original Message -
From: "Scott Gilbertson"
To: "Lillian Angel"
Sent: Tuesday, February 21, 2006 12:19 PM
Subject: Re: [cp-patches] RFC: LightweightPeers reworked
> I wonder if you could have a look at this change, half of which I claim is
> related:
>
http://developer.classpath.org/pipermail/classpath/2006-February/000157.html
>
> I originally submitted it for GCJ (hence the superfluous "libjava/" on all
> the paths), but it needs to go in Classpath before checking in there, so
> merging doesn't get out of control. I haven't been able to get
> Classpath+JamVM to work, so I've been unable to test it in order to submit
a
> Classpath patch. I'm working with the xlib peers on GCJ (so I'm not
really
> in a position to pass judgement on GTK peer code), but my changes
referenced
> above affect GTK peers as well.
>
> Here's my test program, which fails without my patch using GCJ + Classpath
> 0.20 (as merged into the GCJ tree), with both xlib and gtk peers:
> http://gcc.gnu.org/ml/java/2006-02/msg00048/LightweightRepaintTest.java
>
> Your patch still has createComponent returning a GLightweightPeer when the
> Component is not a Container (as in my test program), and I claim there's
a
> problem with GLightweightPeer, so it wouldn't surprise me much if my test
> program still fails with your patch. I'd be overjoyed if you'd include my
> changes and ultimately check them in, since I could then do the same for
> GCJ.
>
> - Original Message -
> From: "Lillian Angel"
> Sent: Tuesday, February 21, 2006 10:28 AM
> Subject: [cp-patches] RFC: LightweightPeers reworked
>
>
> > Hello,
> >
> > Tom F. and I worked on changing how we handle Container lightweights and
> > Component lightweights. This bug showed up in MegaMek and several test
> > cases. It appeared that Containers should be handled differently.
> >
> > When a Container was placed in a Window, and contained Heavyweight
> > components, the location of the components were always being set at
> > (0,0), relative to the Window. This is because the components were not
> > aware of the bounds of the Container. Now, GtkLightweightPeer is similar
> > to a GtkPanelPeer.
> >
> > GtkLightweightPeer extends GtkContainerPeer. This fixes the problem. We
> > discovered that we could not completely get rid of GLightweightPeer
> > because Components still depended on its constructor.
> >
> > I tested this with the swing demo and MegaMek. The painting seems to
> > work fine still...
> >
> > Feel free to give me feedback before I commit this.
> >
> > 2006-02-21 Lillian Angel <[EMAIL PROTECTED]>
> >
> > * gnu/java/awt/peer/gtk/GtkLightweightPeer.java:
> > New class to handle Container Lightweights.
> > * gnu/java/awt/peer/gtk/GtkPanelPeer.java:
> > Removed unneeded import.
> > * gnu/java/awt/peer/gtk/GtkToolkit.java
> > (createComponent): New method to override Toolkit's
> > createComponent. Returns an instance of GtkLightweightPeer
> > if the target is a container, and a GLightweightPeer if the
> > target is a Component.
> > * include/Makefile.am:
> > Added gnu_java_awt_peer_gtk_GtkLightweightPeer.h.
> > * include/gnu_java_awt_peer_gtk_GtkLightweightPeer.h:
> > New header file.
> > * java/awt/Toolkit.java
> > (createComponent): Changed to return null. This method
> > should be overridden. Added comment explaining why.
Re: [cp-patches] RFC: LightweightPeers reworked
On Tue, 2006-02-21 at 13:09 -0500, Lillian Angel wrote: > > GLightweightPeer should probably be renamed to LightweightComponentPeer > > though, and GtkLightweightPeer should be GtkLightweightContainerPeer. > > > Attached is the updated patch. OK, a few comments: +public class LightweightComponentPeer + implements LightweightPeer, ContainerPeer Does LightweightComponentPeer still need to implement ContainerPeer or can it just implement ComponentPeer? - -// Skip lightweight peers. + Actually we do still need to skip lightweight peers here (and the patch doesn't change the behaviour) so the comment should stay. +// This should be overridden by default Toolkit (eg. GtkToolkit). +// If target is an instance of Container, then a GtkLightweightPeer +// should be returned. Otherwise, an instance of GLightweightPeer is +// returned for Components. This is because, all the properties of a +// Container should be accessible (bounds, location etc). +// A lightweight Component should _just_ be drawn on its parent window, +// but we should be able to reshape a Container. Therefore, Component +// and Container lightweights should be treated differently. You need to update the class names in this comment and the comment could be clearer. The reason for the distinction is that LightweightComponentPeers really are lightweight but GtkLightweightContainerPeer is lightweight in that it doesn't allocate screen resources but it still has a backing widget that tracks its bounds and location for use by the native side. Tom
Re: [cp-patches] RFC: LightweightPeers reworked
On Tue, 2006-02-21 at 12:19 -0500, Scott Gilbertson wrote: > I wonder if you could have a look at this change, half of which I claim is > related: > http://developer.classpath.org/pipermail/classpath/2006-February/000157.html Attached is a newly updated patch to incorporate Scott's patch, Mark approved this on the Classpath mailing list. This patch includes the renaming of the lightweight peer classes that Tom suggested. I, also, fixed up LightweightComponentPeer to only implement ComponentPeer and GtkLightweightContainerPeer to only implement ContainerPeer. Here is an updated ChangeLog entry: 2006-02-21 Lillian Angel <[EMAIL PROTECTED]> * gnu/java/awt/peer/gtk/GtkLightweightContainerPeer.java: New class to handle Container Lightweights. This class implements ContainerPeer. * gnu/java/awt/peer/gtk/GtkToolkit.java: Fixed imports. (createComponent): New method to override Toolkit's createComponent. Returns an instance of GtkLightweightPeer if the target is a container, and a LightweightComponentPeer if the target is a Component. * include/Makefile.am: Added gnu_java_awt_peer_gtk_GtkLightweightContainerPeer.h. * include/gnu_java_awt_peer_gtk_GtkLightweightContainterPeer.h: New header file. * java/awt/Toolkit.java (createComponent): Changed to return null. This method should be overridden. Added comment explaining why. * native/jni/gtk-peer/Makefile.am: Added gnu_java_awt_peer_gtk_GtkLightweightContainerPeer.c. * native/jni/gtk-peer/gnu_java_awt_peer_gtk_ GtkLightweightContainerPeer.c: New class. * gnu/java/awt/peer/GLightweightPeer.java: Removed class, replaced with LightweightComponentPeer. * gnu/java/awt/peer/LightweightComponentPeer.java: New class. Replaces GLightweightPeer, but only implements ComponentPeer now. Updated comments. (repaint): Incorporate Scott's patch. Sends event to parent using tm, not 0. * gnu/java/awt/peer/gtk/GtkComponentPeer.java (setParent): Removed check for LightweightPeer. The parent should be set for all components. (setBounds): Removed code for lightweights. The placement of the lightweight containers is now handled by GtkLightweightContainerPeer. * gnu/java/awt/peer/gtk/GtkContainerPeer.java (endValidate): Removed comment. * java/awt/Graphics.java (hitClip): Incorporates Scott's patch to handle null clip. Index: gnu/java/awt/peer/GLightweightPeer.java === RCS file: gnu/java/awt/peer/GLightweightPeer.java diff -N gnu/java/awt/peer/GLightweightPeer.java --- gnu/java/awt/peer/GLightweightPeer.java 19 Aug 2005 01:29:26 - 1.6 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,339 +0,0 @@ -/* GLightweightPeer.java -- - Copyright (C) 2003, 2004 Free Software Foundation, Inc. - -This file is part of GNU Classpath. - -GNU Classpath is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2, or (at your option) -any later version. - -GNU Classpath is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with GNU Classpath; see the file COPYING. If not, write to the -Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA -02110-1301 USA. - -Linking this library statically or dynamically with other modules is -making a combined work based on this library. Thus, the terms and -conditions of the GNU General Public License cover the whole -combination. - -As a special exception, the copyright holders of this library give you -permission to link this library with independent modules to produce an -executable, regardless of the license terms of these independent -modules, and to copy and distribute the resulting executable under -terms of your choice, provided that you also meet, for each linked -independent module, the terms and conditions of the license of that -module. An independent module is a module which is not derived from -or based on this library. If you modify this library, you may extend -this exception to your version of the library, but you are not -obligated to do so. If you do not wish to do so, delete this -exception statement from your version. */ - - -package gnu.java.awt.peer; - -import java.awt.AWTEvent; -import java.awt.AWTException; -import java.awt.BufferCapabilities; -import java.awt.Color; -import java.awt.Component; -import java.awt.Cursor; -import java.awt.Dimension; -import java.awt.Font; -import java.awt.FontMetrics; -im
Re: [cp-patches] RFC: LightweightPeers reworked
> GLightweightPeer should probably be renamed to LightweightComponentPeer
> though, and GtkLightweightPeer should be GtkLightweightContainerPeer.
Attached is the updated patch.
Thanks,
Lillian
Index: gnu/java/awt/peer/GLightweightPeer.java
===
RCS file: gnu/java/awt/peer/GLightweightPeer.java
diff -N gnu/java/awt/peer/GLightweightPeer.java
--- gnu/java/awt/peer/GLightweightPeer.java 19 Aug 2005 01:29:26 - 1.6
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,339 +0,0 @@
-/* GLightweightPeer.java --
- Copyright (C) 2003, 2004 Free Software Foundation, Inc.
-
-This file is part of GNU Classpath.
-
-GNU Classpath is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2, or (at your option)
-any later version.
-
-GNU Classpath is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with GNU Classpath; see the file COPYING. If not, write to the
-Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
-02110-1301 USA.
-
-Linking this library statically or dynamically with other modules is
-making a combined work based on this library. Thus, the terms and
-conditions of the GNU General Public License cover the whole
-combination.
-
-As a special exception, the copyright holders of this library give you
-permission to link this library with independent modules to produce an
-executable, regardless of the license terms of these independent
-modules, and to copy and distribute the resulting executable under
-terms of your choice, provided that you also meet, for each linked
-independent module, the terms and conditions of the license of that
-module. An independent module is a module which is not derived from
-or based on this library. If you modify this library, you may extend
-this exception to your version of the library, but you are not
-obligated to do so. If you do not wish to do so, delete this
-exception statement from your version. */
-
-
-package gnu.java.awt.peer;
-
-import java.awt.AWTEvent;
-import java.awt.AWTException;
-import java.awt.BufferCapabilities;
-import java.awt.Color;
-import java.awt.Component;
-import java.awt.Cursor;
-import java.awt.Dimension;
-import java.awt.Font;
-import java.awt.FontMetrics;
-import java.awt.Graphics;
-import java.awt.GraphicsConfiguration;
-import java.awt.Image;
-import java.awt.Insets;
-import java.awt.Point;
-import java.awt.Rectangle;
-import java.awt.Toolkit;
-import java.awt.event.PaintEvent;
-import java.awt.image.ColorModel;
-import java.awt.image.ImageObserver;
-import java.awt.image.ImageProducer;
-import java.awt.image.VolatileImage;
-import java.awt.peer.ContainerPeer;
-import java.awt.peer.LightweightPeer;
-
-/*
- * Another possible implementation strategy for lightweight peers is
- * to make GLightweightPeer a placeholder class that implements
- * LightweightPeer. Then the Component and Container classes could
- * identify a peer as lightweight and handle it specially. The
- * current approach is probably more clear but less efficient.
- */
-
-/**
- * A stub class that implements the ComponentPeer and ContainerPeer
- * interfaces using callbacks into the Component and Container
- * classes. GLightweightPeer allows the Component and Container
- * classes to treat lightweight and heavyweight peers in the same way.
- *
- * Lightweight components are painted directly onto their parent
- * containers through an Image object provided by the toolkit.
- */
-public class GLightweightPeer
- implements LightweightPeer, ContainerPeer
-{
- private Component comp;
-
- private Insets containerInsets;
-
- public GLightweightPeer(Component comp)
- {
-this.comp = comp;
- }
-
- // java.awt.peer.ContainerPeer implementation:
-
- public Insets insets()
- {
-return getInsets ();
- }
-
- public Insets getInsets()
- {
-if (containerInsets == null)
- containerInsets = new Insets (0,0,0,0);
-return containerInsets;
- }
-
- public void beginValidate()
- {
- }
-
- public void endValidate()
- {
- }
-
- public void beginLayout()
- {
- }
-
- public void endLayout()
- {
- }
-
- public boolean isPaintPending()
- {
-return false;
- }
-
- // java.awt.peer.ComponentPeer implementation:
-
- public int checkImage(Image img, int width, int height, ImageObserver o)
- {
-return comp.getToolkit().checkImage(img, width, height, o);
- }
-
- public Image createImage(ImageProducer prod)
- {
-return comp.getToolkit().createImage(prod);
- }
-
- /* This method is not called. */
- public Image createImage(int width, int height)
- {
-return null
Re: [cp-patches] RFC: LightweightPeers reworked
On Tue, 2006-02-21 at 10:28 -0500, Lillian Angel wrote: > Hello, > > Tom F. and I worked on changing how we handle Container lightweights and > Component lightweights. This bug showed up in MegaMek and several test > cases. It appeared that Containers should be handled differently. > > When a Container was placed in a Window, and contained Heavyweight > components, the location of the components were always being set at > (0,0), relative to the Window. This is because the components were not > aware of the bounds of the Container. Now, GtkLightweightPeer is similar > to a GtkPanelPeer. > > GtkLightweightPeer extends GtkContainerPeer. This fixes the problem. We > discovered that we could not completely get rid of GLightweightPeer > because Components still depended on its constructor. > > I tested this with the swing demo and MegaMek. The painting seems to > work fine still... > > Feel free to give me feedback before I commit this. I'll provide background as to why this change makes sense. Some AWT applications pack heavyweight components in lightweight containers. MegaMek is one such application but we've seen other examples. For a heavyweight component packed in a lightweight container, the native peers are missing offset information about that heavyweight's peer's location, because the native peers have no knowledge of the lightweight container. For example: (0, 0) - | HW CONTAINER | | | | (40, 10) | | | LW CONTAINER | | | | (20, 15) - | | | || HW BUTTON | | | | |- | | | | - This case isn't handled correctly by our GTK peers currently. The button will be displayed at 20, 15 in the heavyweight container, because GTK has no knowledge of the lightweight container. To address this, Lillian's patch peers the lightweight container to a windowless GtkFixed. Because the GtkFixed is windowless it provides exactly what is needed and nothing more: it gives GTK information about the location and size of the lightweight container, and does not add a new screen resource to every lightweight container. The advantage of this approach is that it eliminates any special casing we need to do in ComponentPeer.setBounds. Previously we were handling this case in the GTK peers by climbing the component hierarchy in GtkComponentPeer.setBounds, accounting for any lightweight ancestors' coordinates but this code was fragile and buggy. Note that GLightweightPeer is still needed for lightweight components that are not containers. Lightweight components truly need no native representation because they cannot contain other heavyweights. GLightweightPeer should probably be renamed to LightweightComponentPeer though, and GtkLightweightPeer should be GtkLightweightContainerPeer. The patch as-posted is not complete. We need to change GtkLightweightContainerPeer so that it is more like LightweightComponentPeer -- for example, it should never call paint on its awtComponent. At this point I'm more concerned that people critique the approach to solving the heavyweight-in-lightweight-container problem rather than the patch-as-posted. Comments? Tom
Re: [cp-patches] RFC: LightweightPeers reworked
I wonder if you could have a look at this change, half of which I claim is related: http://developer.classpath.org/pipermail/classpath/2006-February/000157.html I originally submitted it for GCJ (hence the superfluous "libjava/" on all the paths), but it needs to go in Classpath before checking in there, so merging doesn't get out of control. I haven't been able to get Classpath+JamVM to work, so I've been unable to test it in order to submit a Classpath patch. I'm working with the xlib peers on GCJ (so I'm not really in a position to pass judgement on GTK peer code), but my changes referenced above affect GTK peers as well. Here's my test program, which fails without my patch using GCJ + Classpath 0.20 (as merged into the GCJ tree), with both xlib and gtk peers: http://gcc.gnu.org/ml/java/2006-02/msg00048/LightweightRepaintTest.java Your patch still has createComponent returning a GLightweightPeer when the Component is not a Container (as in my test program), and I claim there's a problem with GLightweightPeer, so it wouldn't surprise me much if my test program still fails with your patch. I'd be overjoyed if you'd include my changes and ultimately check them in, since I could then do the same for GCJ. - Original Message - From: "Lillian Angel" Sent: Tuesday, February 21, 2006 10:28 AM Subject: [cp-patches] RFC: LightweightPeers reworked > Hello, > > Tom F. and I worked on changing how we handle Container lightweights and > Component lightweights. This bug showed up in MegaMek and several test > cases. It appeared that Containers should be handled differently. > > When a Container was placed in a Window, and contained Heavyweight > components, the location of the components were always being set at > (0,0), relative to the Window. This is because the components were not > aware of the bounds of the Container. Now, GtkLightweightPeer is similar > to a GtkPanelPeer. > > GtkLightweightPeer extends GtkContainerPeer. This fixes the problem. We > discovered that we could not completely get rid of GLightweightPeer > because Components still depended on its constructor. > > I tested this with the swing demo and MegaMek. The painting seems to > work fine still... > > Feel free to give me feedback before I commit this. > > 2006-02-21 Lillian Angel <[EMAIL PROTECTED]> > > * gnu/java/awt/peer/gtk/GtkLightweightPeer.java: > New class to handle Container Lightweights. > * gnu/java/awt/peer/gtk/GtkPanelPeer.java: > Removed unneeded import. > * gnu/java/awt/peer/gtk/GtkToolkit.java > (createComponent): New method to override Toolkit's > createComponent. Returns an instance of GtkLightweightPeer > if the target is a container, and a GLightweightPeer if the > target is a Component. > * include/Makefile.am: > Added gnu_java_awt_peer_gtk_GtkLightweightPeer.h. > * include/gnu_java_awt_peer_gtk_GtkLightweightPeer.h: > New header file. > * java/awt/Toolkit.java > (createComponent): Changed to return null. This method > should be overridden. Added comment explaining why. > * native/jni/gtk-peer/Makefile.am: > Added gnu_java_awt_peer_gtk_GtkLightweightPeer.c. > * native/jni/gtk-peer/gnu_java_awt_peer_gtk_ > GtkLightweightPeer.c: New class. > >
Re: [cp-patches] [generics] RFC: new Enum java.math.RoundingMode
On Tue, 2006-02-21 at 10:42 -0500, Anthony Balkissoon wrote:
> This is committed as:
>
> 2006-02-21 Anthony Balkissoon <[EMAIL PROTECTED]>
>
> * java/math/MathContext.java: New class.
> * java/math/RoundingMode: New Enum.
>
> In response to Andrew and Tom:
>
> Andrew: Yes, the only thing restricting this to the generics branch is
> the Enum. But reading Sun's arguments in favour of Enums
> (http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html) , they
> make some reasonable points. So maybe the pity isn't that they use
> Enums here but that we're still not able to handle them on the trunk.
> I'm not sure how far away that is though - from what I understand it's
> because not all the compilers we use support the new language features?
>
Yes, I can see their reasons for using them. It's just a shame that
having that all the new math changes, AFAICS, are dependent on that
enum, which locks it down to the branch.
The problem is that ecj is the only FOSS compiler that can currently
compile this stuff. I think the plan is to now merge this with gcj to
provide this functionality for that. I don't know if anyone is still
even working on this for jikes.
> Tom: Yeah, the header template isn't there, and also the Eclipse builder
> options don't seem to be working properly. Everytime I made any small
> change it would do an entire rebuild, running autogen, configure,
> ClasspathHeaders, BuildNative, etc.
> Andrew Overholt gave it a quick look for me but we didn't see the
> problem so we just worked around it on my local machine.
>
>
> That's all for now, I should have some more java.math stuff ready soon.
>
> --Tony
>
> On Tue, 2006-02-21 at 08:32 +, Andrew John Hughes wrote:
> > On Mon, 2006-02-20 at 17:33 -0500, Anthony Balkissoon wrote:
> > > On Mon, 2006-02-20 at 15:09 -0500, Anthony Balkissoon wrote:
> > > > This is RFC because it's my first commit to the generics branch and I
> > > > just want to make sure there aren't any special procedures I forgot.
> > > >
> > > > 2006-02-20 Anthony Balkissoon <[EMAIL PROTECTED]>
> > > >
> > > > * java/math/RoundingMode: New Enum.
> > > >
> > > > --Tony
> > >
> > >
> > > This is replaced by:
> > > 2006-02-20 Anthony Balkissoon <[EMAIL PROTECTED]>
> > >
> > > * java/math/MathContext.java: New class.
> > > * java/math/RoundingMode: New Enum.
> > >
> > > Also, I forgot to put the GNU Classpath header in RoundingMode, but this
> > > patch includes it. Comments are still appreciated. I'll commit this
> > > tomorrow if no one objects.
> > >
> > > --Tony
> >
> > Looks fine to me -- the header would have been my only comment. Of
> > course, I'm assuming it applies cleanly and compiles... ;)
> >
> > It's a pity this new math stuff uses an enum for RoundingMode, because
> > AFAICS that's the only thing that restricts this to the generics branch.
--
Andrew :-)
Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
If you use Microsoft Office, support movement towards the end of vendor
lock-in:
http://opendocumentfellowship.org/petition/
"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
[cp-patches] FYI: Documentation update for StreamPrintService
Hi,
changelog says all.
2006-02-21 Wolfgang Baer <[EMAIL PROTECTED]>
* javax/print/StreamPrintService.java: Added and enhanced documentation.
Wolfgang
Index: javax/print/StreamPrintService.java
===
RCS file: /cvsroot/classpath/classpath/javax/print/StreamPrintService.java,v
retrieving revision 1.2
diff -u -r1.2 StreamPrintService.java
--- javax/print/StreamPrintService.java 2 Jul 2005 20:32:46 - 1.2
+++ javax/print/StreamPrintService.java 21 Feb 2006 15:34:44 -
@@ -1,5 +1,5 @@
/* StreamPrintService.java --
- Copyright (C) 2004 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -42,6 +42,15 @@
/**
+ * StreamPrintService is a special print service capable of
+ * printing into a supplied output stream.
+ *
+ * Beside providing the same functionality as a print service it additionally
+ * allows to specify the output stream for the print data. A stream print
+ * service is obtained via the [EMAIL PROTECTED] javax.print.StreamPrintServiceFactory}
+ * by looking for services supporting a given output format type.
+ *
+ *
* @author Michael Koch ([EMAIL PROTECTED])
*/
public abstract class StreamPrintService implements PrintService
@@ -68,16 +77,18 @@
}
/**
- * Returns the document format emited by this print service.
+ * Returns the document format emitted by this print service.
+ * The returned string is a MIME type compatible with the
+ * [EMAIL PROTECTED] DocFlavor} class.
*
- * @return the document format
+ * @return The document format of the output.
*/
public abstract String getOutputFormat();
/**
* Returns the OutputStream of this object.
*
- * @return the OutputStream
+ * @return The OutputStream
*/
public OutputStream getOutputStream()
{
[cp-patches] FYI: WrappedPlainView fixlet
One of my last fixes showed up a problem with WrappedPlainView, which is
fixed by this patch.
2006-02-21 Roman Kennke <[EMAIL PROTECTED]>
* javax/swing/text/WrappedPlainView.java
(calculateBreakPosition): Changed to use the view's allocation
instead
of the container's preferredSize.
/Roman
Index: javax/swing/text/WrappedPlainView.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/WrappedPlainView.java,v
retrieving revision 1.9
diff -u -r1.9 WrappedPlainView.java
--- javax/swing/text/WrappedPlainView.java 23 Nov 2005 14:23:14 - 1.9
+++ javax/swing/text/WrappedPlainView.java 21 Feb 2006 15:35:57 -
@@ -270,8 +270,7 @@
protected int calculateBreakPosition(int p0, int p1)
{
Container c = getContainer();
-Rectangle alloc = c.isValid() ? c.getBounds()
- : new Rectangle(c.getPreferredSize());
+Rectangle alloc = new Rectangle(0, 0, getWidth(), getHeight());
updateMetrics();
try
{
[cp-patches] RFC: LightweightPeers reworked
Hello,
Tom F. and I worked on changing how we handle Container lightweights and
Component lightweights. This bug showed up in MegaMek and several test
cases. It appeared that Containers should be handled differently.
When a Container was placed in a Window, and contained Heavyweight
components, the location of the components were always being set at
(0,0), relative to the Window. This is because the components were not
aware of the bounds of the Container. Now, GtkLightweightPeer is similar
to a GtkPanelPeer.
GtkLightweightPeer extends GtkContainerPeer. This fixes the problem. We
discovered that we could not completely get rid of GLightweightPeer
because Components still depended on its constructor.
I tested this with the swing demo and MegaMek. The painting seems to
work fine still...
Feel free to give me feedback before I commit this.
2006-02-21 Lillian Angel <[EMAIL PROTECTED]>
* gnu/java/awt/peer/gtk/GtkLightweightPeer.java:
New class to handle Container Lightweights.
* gnu/java/awt/peer/gtk/GtkPanelPeer.java:
Removed unneeded import.
* gnu/java/awt/peer/gtk/GtkToolkit.java
(createComponent): New method to override Toolkit's
createComponent. Returns an instance of GtkLightweightPeer
if the target is a container, and a GLightweightPeer if the
target is a Component.
* include/Makefile.am:
Added gnu_java_awt_peer_gtk_GtkLightweightPeer.h.
* include/gnu_java_awt_peer_gtk_GtkLightweightPeer.h:
New header file.
* java/awt/Toolkit.java
(createComponent): Changed to return null. This method
should be overridden. Added comment explaining why.
* native/jni/gtk-peer/Makefile.am:
Added gnu_java_awt_peer_gtk_GtkLightweightPeer.c.
* native/jni/gtk-peer/gnu_java_awt_peer_gtk_
GtkLightweightPeer.c: New class.
Index: gnu/java/awt/peer/gtk/GtkComponentPeer.java
===
RCS file: /sources/classpath/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java,v
retrieving revision 1.105
diff -u -r1.105 GtkComponentPeer.java
--- gnu/java/awt/peer/gtk/GtkComponentPeer.java 17 Feb 2006 19:53:06 - 1.105
+++ gnu/java/awt/peer/gtk/GtkComponentPeer.java 21 Feb 2006 15:11:38 -
@@ -166,19 +166,16 @@
setVisibleAndEnabled ();
}
- void setParent ()
+ void setParent()
{
ComponentPeer p;
Component component = awtComponent;
-do
- {
-component = component.getParent ();
-p = component.getPeer ();
- }
-while (p instanceof java.awt.peer.LightweightPeer);
+
+component = component.getParent();
+p = component.getPeer();
if (p != null)
- gtkWidgetSetParent (p);
+ gtkWidgetSetParent(p);
}
void beginNativeRepaint ()
@@ -443,38 +440,11 @@
{
int new_x = x;
int new_y = y;
-
-Component parent = awtComponent.getParent ();
-Component next_parent;
-
-// Heavyweight components that are children of one or more
-// lightweight containers have to be handled specially. Because
-// calls to GLightweightPeer.setBounds do nothing, GTK has no
-// knowledge of the lightweight containers' positions. So we have
-// to add the offsets manually when placing a heavyweight
-// component within a lightweight container. The lightweight
-// container may itself be in a lightweight container and so on,
-// so we need to continue adding offsets until we reach a
-// container whose position GTK knows -- that is, the first
-// non-lightweight.
-boolean lightweightChild = false;
-Insets i;
-while (parent.isLightweight())
- {
-lightweightChild = true;
-
-next_parent = parent.getParent();
-
-i = ((Container) parent).getInsets();
-new_x += parent.getX() + i.left;
-new_y += parent.getY() + i.top;
-
-parent = next_parent;
- }
+Component parent = awtComponent.getParent();
// We only need to convert from Java to GTK coordinates if we're
// placing a heavyweight component in a Window.
-if (parent instanceof Window && !lightweightChild)
+if (parent instanceof Window)
{
GtkWindowPeer peer = (GtkWindowPeer) parent.getPeer ();
// important: we want the window peer's insets here, not the
@@ -490,7 +460,7 @@
new_x = x - insets.left;
new_y = y - insets.top + menuBarHeight;
}
-
+
setNativeBounds (new_x, new_y, width, height);
}
Index: gnu/java/awt/peer/gtk/GtkContainerPeer.java
===
RCS file: /sources/classpath/classpath/gnu/java/awt/peer/gtk/GtkContainerPeer.java,v
retrieving revision 1.33
diff -u -r1.33 GtkContainerPeer.java
--- gnu/java/awt/peer/gtk/GtkContainerPeer.java 19 Feb 2006 22:32:45 - 1.33
+++ gnu/java/awt/peer/gtk/GtkContainerPeer.java 21 Feb 2006 15:11:38 -
@@ -81,8 +81,7
[cp-patches] Re: RFC: LightweightPeers reworked
On Tue, 2006-02-21 at 10:28 -0500, Lillian Angel wrote:
> Hello,
>
> Tom F. and I worked on changing how we handle Container lightweights and
> Component lightweights. This bug showed up in MegaMek and several test
> cases.
Attached is the test case that we used to fix this. Try it without the
patch and resize the Frame to see what happens.
Lillian
import java.awt.*;
public class Grid2 extends Container {
private Canvas canHex;
private Label labElev;
private TextField texElev;
private Button butElevUp;
private Button butElevDown;
private Label labTerrain;
private java.awt.List lisTerrain;
private Button butDelTerrain;
private Panel panTerrainType;
private Choice choTerrainType;
private TextField texTerrainLevel;
private Panel panTerrExits;
private Checkbox cheTerrExitSpecified;
private TextField texTerrExits;
private Button butTerrExits;
private Panel panRoads;
private Checkbox cheRoadsAutoExit;
private Label labTheme;
private TextField texTheme;
private Button butAddTerrain;
private Label blankL;
private Label labBoard;
private Panel panButtons;
private Button butBoardNew, butBoardLoad;
private Button butBoardSave, butBoardSaveAs;
private Button butBoardSaveAsImage;
private Button butMiniMap;
public static void main(String[] args)
{
new Grid2();
}
public Grid2()
{
Frame p = new Frame();
p.setLayout(new BorderLayout());
Panel scrollPane = new Panel();
scrollPane.setLayout (new BorderLayout());
Scrollbar vertical = new Scrollbar (Scrollbar.VERTICAL);
Scrollbar horizontal = new Scrollbar (Scrollbar.HORIZONTAL);
scrollPane.add (new Canvas(), BorderLayout.CENTER);
scrollPane.add (vertical, BorderLayout.EAST);
scrollPane.add (horizontal, BorderLayout.SOUTH);
p.add(scrollPane, BorderLayout.CENTER);
setupEditorPanel();
p.add(this, BorderLayout.EAST);
p.setSize(800, 600);
p.show();
System.out.println(this.getLayout());
doLayout();
}
private void setupEditorPanel() {
canHex = new Canvas();
labElev = new Label("a", Label.RIGHT); //$NON-NLS-1$
texElev = new TextField("0", 1); //$NON-NLS-1$
butElevUp = new Button("BoardEditor.butElevUp"); //$NON-NLS-1$
butElevDown = new Button(("BoardEditor.butElevDown")); //$NON-NLS-1$
labTerrain = new Label(("BoardEditor.labTerrain"), Label.LEFT); //$NON-NLS-1$
lisTerrain = new java.awt.List(6);
butDelTerrain = new Button(("BoardEditor.butDelTerrain")); //$NON-NLS-1$
choTerrainType = new Choice();
texTerrainLevel = new TextField("0", 1); //$NON-NLS-1$
butAddTerrain = new Button(("BoardEditor.butAddTerrain")); //$NON-NLS-1$
butMiniMap = new Button(("BoardEditor.butMiniMap")); //$NON-NLS-1$
panTerrainType = new Panel(new BorderLayout());
panTerrainType.add(choTerrainType, BorderLayout.WEST);
panTerrainType.add(texTerrainLevel, BorderLayout.CENTER);
cheTerrExitSpecified = new Checkbox(("BoardEditor.cheTerrExitSpecified")); //$NON-NLS-1$
butTerrExits = new Button(("BoardEditor.butTerrExits")); //$NON-NLS-1$
texTerrExits = new TextField("0", 1); //$NON-NLS-1$
panTerrExits = new Panel(new FlowLayout());
panTerrExits.add(cheTerrExitSpecified);
panTerrExits.add(butTerrExits);
panTerrExits.add(texTerrExits);
panRoads = new Panel(new FlowLayout());
cheRoadsAutoExit = new Checkbox(("BoardEditor.cheRoadsAutoExit")); //$NON-NLS-1$
panRoads.add(cheRoadsAutoExit);
labTheme = new Label(("BoardEditor.labTheme"), Label.LEFT); //$NON-NLS-1$
texTheme = new TextField("", 15); //$NON-NLS-1$
labBoard = new Label(("BoardEditor.labBoard"), Label.LEFT); //$NON-NLS-1$
butBoardNew = new Button(("BoardEditor.butBoardNew")); //$NON-NLS-1$
butBoardLoad = new Button(("BoardEditor.butBoardLoad")); //$NON-NLS-1$
butBoardSave = new Button(("BoardEditor.butBoardSave")); //$NON-NLS-1$
butBoardSaveAs = new Button(("BoardEditor.butBoardSaveAs")); //$NON-NLS-1$
butBoardSaveAsImage = new Button(("BoardEditor.butBoardSaveAsImage")); //$NON-NLS-1$
panButtons = new Panel(new GridLayout(3, 2, 2, 2));
panButtons.add(labBoard);
panButtons.add(butBoardNew);
panButtons.add(butBoardLoad);
panButtons.add(butBoardSave);
panButtons.add(butBoardSaveAs);
panButtons.add(butBoardSaveAsImage);
blankL = new Label("", Label.CENTER); //$NON-NLS-1$
GridBagLayout gridbag = new GridBagLayout();
GridBagConstraints c = new GridBagConstraints();
setLayout(gridbag);
c.fill = GridBagConstraints.HORIZONTAL;
c.weightx = 0.0;c.weighty = 0.0;
c.insets = new Insets(4
Re: [cp-patches] FYI: Swing text improvements
On Tue, 2006-02-21 at 14:00 +, Roman Kennke wrote: > Hi list, > > I hacked a little on our HTML renderer, it is now possible to render more > complex HTML documents, including line wrapping behaviour. This is of > course not limited to HTML but for styled text in general. Here is a > screenshot of a rendered HTML document: > > http://kennke.org/~roman/html.png > Thanks for this work Roman, HTML is really coming along thanks to you! --Tony
[cp-patches] Re: RFC: Scrollbar fixes for old Events and setting value
On Tue, 2006-02-21 at 14:56 +0100, Mark Wielaard wrote: > Hi Tom, > > On Mon, 2006-02-20 at 18:10 -0500, Thomas Fitzsimmons wrote: > > On Mon, 2006-02-20 at 23:31 +0100, Mark Wielaard wrote: > > > My main question is whether the "loopback" protection is correct. I got > > > the idea from GtkCheckboxPeer. > > > > I think there is a deadlock risk with this patch and with > > GtkCheckboxPeer. postAdjustmentEvent is called with the GDK lock held > > and calls the synchronized method Scrollbar.setValues. > > Scrollbar.setValues calls GtkScrollbarPeer.setValues which acquires the > > GDK lock. So there's the potential for mutual embrace if a thread other > > than the GTK main thread calls Scrollbar.setValues at the right time. > > I see. Good point. gtk signal handlers should do as little as possible. > Only posting events from them seems like a good design. > > > Why not just set the new value upon receiving the posted AdjustmentEvent > > in Scrollbar.processAdjustmentEvent rather than directly in > > GtkScrollbarPeer.postAdjustmentEvent? > > There were 2 problems with doing it that way. processAdjustmentEvent() > isn't called in the 1.0 model (only when there are actual listeners). > And I didn't know how to prevent "loopback" when the scrollbar was moved > by the user and (because the system was a bit slow) the event was > triggering "late" making the scrollbar jump a bit back and forth while > it was being scrolled quickly. > > But I believe I found solutions for both of these. I do the adjusting in > the package private dispatchEventImpl() just before checking whether or > not AdjustmentEvents need to be fired. And in the peer we set > ValueIsAdjusting true to mark the event (and the component) as being > under adjustment of the user. This makes my test application and the vte > happy. > > 2006-02-21 Mark Wielaard <[EMAIL PROTECTED]> > > * java/awt/Component.java (translateEvent): Translate > AdjustmentEvents to 1.0 Events. > * java/awt/Scrollbar.java (dispatchEventImpl): Set valueIsAdjusting. > Call setValue() before processing event. > * gnu/java/awt/peer/gtk/GtkScrollbarPeer.java (setValues): Check > whether we are currently changing and being called back from the > Scrollbar component. > (setBarValues): New native method. > (postAdjustmentEvent): Mark AdjustmentEvent as user generated. > * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkScrollbarPeer.c > (Java_gnu_java_awt_peer_gtk_GtkScrollbarPeer_setValues): Renamed to > Java_gnu_java_awt_peer_gtk_GtkScrollbarPeer_setBarValue > * include/gnu_java_awt_peer_gtk_GtkScrollbarPeer.h: Regenerated. Looks good, thanks. Please commit. > > If you think propagating value changes to awt components through the > event queue and dispatchEventImp() is a good idea then I will change > GtkCheckboxPeer accordingly and audit the other awt gtk-peers. Yes, I've thought about different approaches to this and this seems like the simplest one that doesn't contain race conditions. Tom
Re: [cp-patches] [generics] RFC: new Enum java.math.RoundingMode
This is committed as:
2006-02-21 Anthony Balkissoon <[EMAIL PROTECTED]>
* java/math/MathContext.java: New class.
* java/math/RoundingMode: New Enum.
In response to Andrew and Tom:
Andrew: Yes, the only thing restricting this to the generics branch is
the Enum. But reading Sun's arguments in favour of Enums
(http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html) , they
make some reasonable points. So maybe the pity isn't that they use
Enums here but that we're still not able to handle them on the trunk.
I'm not sure how far away that is though - from what I understand it's
because not all the compilers we use support the new language features?
Tom: Yeah, the header template isn't there, and also the Eclipse builder
options don't seem to be working properly. Everytime I made any small
change it would do an entire rebuild, running autogen, configure,
ClasspathHeaders, BuildNative, etc.
Andrew Overholt gave it a quick look for me but we didn't see the
problem so we just worked around it on my local machine.
That's all for now, I should have some more java.math stuff ready soon.
--Tony
On Tue, 2006-02-21 at 08:32 +, Andrew John Hughes wrote:
> On Mon, 2006-02-20 at 17:33 -0500, Anthony Balkissoon wrote:
> > On Mon, 2006-02-20 at 15:09 -0500, Anthony Balkissoon wrote:
> > > This is RFC because it's my first commit to the generics branch and I
> > > just want to make sure there aren't any special procedures I forgot.
> > >
> > > 2006-02-20 Anthony Balkissoon <[EMAIL PROTECTED]>
> > >
> > > * java/math/RoundingMode: New Enum.
> > >
> > > --Tony
> >
> >
> > This is replaced by:
> > 2006-02-20 Anthony Balkissoon <[EMAIL PROTECTED]>
> >
> > * java/math/MathContext.java: New class.
> > * java/math/RoundingMode: New Enum.
> >
> > Also, I forgot to put the GNU Classpath header in RoundingMode, but this
> > patch includes it. Comments are still appreciated. I'll commit this
> > tomorrow if no one objects.
> >
> > --Tony
>
> Looks fine to me -- the header would have been my only comment. Of
> course, I'm assuming it applies cleanly and compiles... ;)
>
> It's a pity this new math stuff uses an enum for RoundingMode, because
> AFAICS that's the only thing that restricts this to the generics branch.
Index: java/math/MathContext.java
===
RCS file: java/math/MathContext.java
diff -N java/math/MathContext.java
--- /dev/null 1 Jan 1970 00:00:00 -
+++ java/math/MathContext.java 21 Feb 2006 15:32:37 -
@@ -0,0 +1,198 @@
+/* MathContext.java --
+ Copyright (C) 1999, 2000, 2002, 2004, 2005 Free Software Foundation, Inc.
+
+This file is part of GNU Classpath.
+
+GNU Classpath is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Classpath is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Classpath; see the file COPYING. If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library. Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module. An independent module is a module which is not derived from
+or based on this library. If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so. If you do not wish to do so, delete this
+exception statement from your version. */
+
+
+package java.math;
+
+import java.io.Serializable;
+
+/**
+ * Immutable objects describing settings such as rounding mode and digit
+ * precision for numerical operations such as those in the BigDecimal class.
+ * @author Anthony Balkissoon abalkiss at redhat dot com
+ *
+ */
+public final class MathContext implements Serializable
+{
+ /** A MathContext for unlimited precision arithmetic * */
+ public static final MathContext UNLIMITED =
+new MathContext(0, RoundingMode.HALF_UP);
+
+ /**
+ * A MathContext for the IEEE 754R Decimal32 format - 7 digit preicision and
+ * HALF_EVEN rounding.
+ *
[cp-patches] FYI: View fix
View.setParent() should also set the parent of the child views to null.
We have mistakenly set it to this.
2006-02-21 Roman Kennke <[EMAIL PROTECTED]>
* javax/swing/text/View.java
(setParent): Set child parent to null when disconnecting
the view from the View hierarchy.
/Roman
Index: javax/swing/text/View.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/View.java,v
retrieving revision 1.28
diff -u -r1.28 View.java
--- javax/swing/text/View.java 13 Feb 2006 14:15:43 - 1.28
+++ javax/swing/text/View.java 21 Feb 2006 15:38:59 -
@@ -91,7 +91,7 @@
{
int numChildren = getViewCount();
for (int i = 0; i < numChildren; i++)
- getView(i).setParent(this);
+ getView(i).setParent(null);
}
this.parent = parent;
Re: [cp-patches] RFC: Fixlets for java.awt.CardLayout
Wolfgang Baer wrote: > Hi, > > I tested an application here which called CardLayout's show method with a null > parameter triggering a wrong NPE. The changes are backed by the recently > committed mauve tests for this class. > > 2006-02-11 Wolfgang Baer <[EMAIL PROTECTED]> > > * java/awt/CardLayout.java: > (first): Updated api documentation. > (last): Likewise. > (next): Likewise. > (previous): Likewise. > (show): Clarified api docs. Return if name is null. Throw > IllegalArgumentException if layout of container is not this. > (gotoComponent): Updated api documentation. Throw > IllegalArgumentException if layout of container is not this. As no one objected so far, committed with updated changelog date. Wolfgang
Re: [cp-patches] RFC: fixed & implemented highlighting - 2nd try
On Tue, 2006-02-21 at 09:45 -0500, Lillian Angel wrote: > I get this when I run the swing demo. Any idea why? > > [EMAIL PROTECTED] examples]$ jamvm gnu/classpath/examples/swing/Demo > Exception during event dispatch: > java.lang.NullPointerException >at javax.swing.text.WrappedPlainView.updateMetrics > (WrappedPlainView.java:300) >at javax.swing.text.WrappedPlainView.getPreferredSpan > (WrappedPlainView.java:309) >at javax.swing.plaf.basic.BasicTextUI$RootView.getPreferredSpan > (BasicTextUI.java:236) >at javax.swing.plaf.basic.BasicTextUI.getPreferredSize > (BasicTextUI.java:789) >at javax.swing.JComponent.getPreferredSize (JComponent.java:1161) >at javax.swing.JEditorPane.getPreferredSize (JEditorPane.java:689) >at javax.swing.text.WrappedPlainView.calculateBreakPosition > (WrappedPlainView.java:274) >at javax.swing.text.WrappedPlainView$WrappedLine.determineNumLines > (WrappedPlainView.java:471) >at javax.swing.text.WrappedPlainView$WrappedLine. > (WrappedPlainView.java:413) >at javax.swing.text.WrappedPlainView.loadChildren > (WrappedPlainView.java:256) >at javax.swing.text.CompositeView.setParent (CompositeView.java:122) >at javax.swing.plaf.basic.BasicTextUI$RootView.setView > (BasicTextUI.java:182) >at javax.swing.plaf.basic.BasicTextUI.setView (BasicTextUI.java:1219) > ... Sorry, my mistake. This is caused by Roman's small BasicTextUI patch. Lillian
[cp-patches] FYI: new NavigationFilter method
The last missing methods in Swing vs Japi are falling. Here comes
NavigationFilter.getNextVisualPositionFrom(), which was quite trivial.
2006-02-21 Roman Kennke <[EMAIL PROTECTED]>
* javax/swing/text/NavigationFilter.java
(getNextVisualPositionFrom): New method.
/Roman
Index: javax/swing/text/NavigationFilter.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/NavigationFilter.java,v
retrieving revision 1.4
diff -u -r1.4 NavigationFilter.java
--- javax/swing/text/NavigationFilter.java 2 Jul 2005 20:32:51 - 1.4
+++ javax/swing/text/NavigationFilter.java 21 Feb 2006 14:43:16 -
@@ -68,4 +68,31 @@
{
fb.setDot(dot, bias);
}
+
+ /**
+ * Returns the next visual position in the specified direction at which one
+ * would place a caret. The default implementation forwards to the text
+ * component's root view. Subclasses may wish to restrict that more.
+ *
+ * @param c the text component
+ * @param pos the current model position
+ * @param bias the bias of pos
+ * @param dir the direction, one of [EMAIL PROTECTED] javax.swing.SwingConstants#NORTH},
+ *[EMAIL PROTECTED] javax.swing.SwingConstants#SOUTH},
+ *[EMAIL PROTECTED] javax.swing.SwingConstants#WEST} or
+ *[EMAIL PROTECTED] javax.swing.SwingConstants#EAST}
+ * @param retBias the bias of the returned position
+ *
+ * @return the next model location to place the caret
+ *
+ * @throws BadLocationException when pos is not a valid model
+ * position
+ */
+ public int getNextVisualPositionFrom(JTextComponent c, int pos,
+ Position.Bias bias, int dir,
+ Position.Bias[] retBias)
+throws BadLocationException
+ {
+return c.getUI().getNextVisualPositionFrom(c, pos, bias, dir, retBias);
+ }
}
Re: [cp-patches] RFC: fixed & implemented highlighting - 2nd try
On Tue, 2006-02-21 at 11:56 +0100, Robert Schuster wrote: > Committed - Roman reviewed the first version. > > cya > Robert > I get this when I run the swing demo. Any idea why? [EMAIL PROTECTED] examples]$ jamvm gnu/classpath/examples/swing/Demo Exception during event dispatch: java.lang.NullPointerException at javax.swing.text.WrappedPlainView.updateMetrics (WrappedPlainView.java:300) at javax.swing.text.WrappedPlainView.getPreferredSpan (WrappedPlainView.java:309) at javax.swing.plaf.basic.BasicTextUI$RootView.getPreferredSpan (BasicTextUI.java:236) at javax.swing.plaf.basic.BasicTextUI.getPreferredSize (BasicTextUI.java:789) at javax.swing.JComponent.getPreferredSize (JComponent.java:1161) at javax.swing.JEditorPane.getPreferredSize (JEditorPane.java:689) at javax.swing.text.WrappedPlainView.calculateBreakPosition (WrappedPlainView.java:274) at javax.swing.text.WrappedPlainView$WrappedLine.determineNumLines (WrappedPlainView.java:471) at javax.swing.text.WrappedPlainView$WrappedLine. (WrappedPlainView.java:413) at javax.swing.text.WrappedPlainView.loadChildren (WrappedPlainView.java:256) at javax.swing.text.CompositeView.setParent (CompositeView.java:122) at javax.swing.plaf.basic.BasicTextUI$RootView.setView (BasicTextUI.java:182) at javax.swing.plaf.basic.BasicTextUI.setView (BasicTextUI.java:1219) at javax.swing.plaf.basic.BasicTextUI.modelChanged (BasicTextUI.java:1243) at javax.swing.plaf.basic.BasicTextUI $PropertyChangeHandler.propertyChange (BasicTextUI.java:385) at java.beans.PropertyChangeSupport.firePropertyChange (PropertyChangeSupport.java:388) at java.beans.PropertyChangeSupport.firePropertyChange (PropertyChangeSupport.java:332) at java.awt.Component.firePropertyChange (Component.java:4455) at javax.swing.text.JTextComponent.setDocument (JTextComponent.java:1148) at javax.swing.JEditorPane.setEditorKit (JEditorPane.java:833) at javax.swing.JEditorPane. (JEditorPane.java:523) at gnu.classpath.examples.swing.Demo.mkEditorPane (Demo.java:946) at gnu.classpath.examples.swing.Demo.mkMenuBar (Demo.java:237) at gnu.classpath.examples.swing.Demo. (Demo.java:708) at gnu.classpath.examples.swing.Demo$LaterMain.run (Demo.java:727) at java.awt.event.InvocationEvent.dispatch (InvocationEvent.java:200) at java.awt.EventQueue.dispatchEvent (EventQueue.java:465) at java.awt.EventDispatchThread.run (EventDispatchThread.java:75) > Robert Schuster wrote: > > Hi all. > > > > I fixed to small errors in this patch that lead to strange behavior: > > > > > >>+ // Last line, from beginning-of-line to p1. > >>+ r0.width = r1.x + r1.width; > > > > Had to add -1 to the calculation above otherwise there were drawing > > differences > > between single line and multi line selections. > > > > > >>+ paintHighlight(g, r0); > >> } > >>+ > >>+// Prevent useless write & repaint operations. > >>+if (o0 == o1 && o1 == p1) > >>+ return; > >>+ > > > > This expression wanted to be > > > > > >>+if (o0 == p0 && o1 == p1) > > > > > > Apart from that I updated the copyright headers in the affected files. > > > > After fixing that I cannot see any more problems with the highlighting > > mechanism. > > > > > > ChangeLog stays the same: > > > > 2006-02-21 Robert Schuster <[EMAIL PROTECTED]> > > > > * javax/swing/plaf/basic/BasicTextUI.java: > > (paint): Remove unneccessary part of the if-expression. > > (damageRange): Added case where the range spans multiple lines. > > * javax/swing/text/DefaultCaret.java: > > (clearHighlight): New method. > > (handleHighlight): Removed unneccessary part of the if-expression. > > (setDot): Use clearHighlight method. > > * javax/swing/text/DefaultHighlighter.java: Use ArrayList instead > > of Vector. > > (paint): Prevented calling size() on every loop iteration, fixed > > calculation of allocation area bounds. > > (getHighlights): Implemented. > > (removeHighlight): Mark damaged area in textcomponent. > > (addHighlight): Mark damaged area in textcomponent. > > (changeHighlight): Mark damaged area in textcomponent. > > (DefaultHighlighter.HighlightEntry): Made it a real > > Highlighter.Highlight implementation. > > (DefaultHighlighter.DefaultHighlightPainter.paint): Fixed > > calculations. > > > > cya > > Robert > > > > > > > > > > > > Index: javax/swing/text/DefaultCaret.java > > === > > RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultCaret.java,v > > retrieving revision 1.30 > > diff -u -r1.30 DefaultCaret.java > > --- javax/swing/text/DefaultCaret.java 9 Feb 2006 17:15:33 - > > 1.30 > > +++ javax/swing/text/DefaultCaret.java 21
[cp-patches] FYI: BasicTextUI fixlet
A small fix for BasicText which removes one unnecessary call to
setParent(null) on the new root view. This would possible confuse the
view that is set, setParent(null) is usually the last call to a view,
here it would have been one of the first calls.
2006-02-21 Roman Kennke <[EMAIL PROTECTED]>
* javax/swing/plaf/basic/BasicTextUI.java
(RootView.setView): Call setParent() on the view with this as
argument instead of null.
(setView): Don't set root view's parent here.
/Roman
Index: javax/swing/plaf/basic/BasicTextUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTextUI.java,v
retrieving revision 1.70
diff -u -r1.70 BasicTextUI.java
--- javax/swing/plaf/basic/BasicTextUI.java 21 Feb 2006 10:57:43 - 1.70
+++ javax/swing/plaf/basic/BasicTextUI.java 21 Feb 2006 14:01:30 -
@@ -179,7 +179,7 @@
view.setParent(null);
if (v != null)
-v.setParent(null);
+v.setParent(this);
view = v;
}
@@ -964,7 +964,7 @@
// The reference implementation does not throw an exception, too.
p0 = Math.min(p0, t.getDocument().getLength());
p1 = Math.min(p1, t.getDocument().getLength());
-
+
Rectangle l1 = modelToView(t, p0, firstBias);
Rectangle l2 = modelToView(t, p1, secondBias);
if (l1.y == l2.y)
@@ -1217,7 +1217,6 @@
protected final void setView(View view)
{
rootView.setView(view);
-view.setParent(rootView);
textComponent.revalidate();
textComponent.repaint();
}
[cp-patches] Re: RFC: Scrollbar fixes for old Events and setting value
Hi Tom,
On Mon, 2006-02-20 at 18:10 -0500, Thomas Fitzsimmons wrote:
> On Mon, 2006-02-20 at 23:31 +0100, Mark Wielaard wrote:
> > My main question is whether the "loopback" protection is correct. I got
> > the idea from GtkCheckboxPeer.
>
> I think there is a deadlock risk with this patch and with
> GtkCheckboxPeer. postAdjustmentEvent is called with the GDK lock held
> and calls the synchronized method Scrollbar.setValues.
> Scrollbar.setValues calls GtkScrollbarPeer.setValues which acquires the
> GDK lock. So there's the potential for mutual embrace if a thread other
> than the GTK main thread calls Scrollbar.setValues at the right time.
I see. Good point. gtk signal handlers should do as little as possible.
Only posting events from them seems like a good design.
> Why not just set the new value upon receiving the posted AdjustmentEvent
> in Scrollbar.processAdjustmentEvent rather than directly in
> GtkScrollbarPeer.postAdjustmentEvent?
There were 2 problems with doing it that way. processAdjustmentEvent()
isn't called in the 1.0 model (only when there are actual listeners).
And I didn't know how to prevent "loopback" when the scrollbar was moved
by the user and (because the system was a bit slow) the event was
triggering "late" making the scrollbar jump a bit back and forth while
it was being scrolled quickly.
But I believe I found solutions for both of these. I do the adjusting in
the package private dispatchEventImpl() just before checking whether or
not AdjustmentEvents need to be fired. And in the peer we set
ValueIsAdjusting true to mark the event (and the component) as being
under adjustment of the user. This makes my test application and the vte
happy.
2006-02-21 Mark Wielaard <[EMAIL PROTECTED]>
* java/awt/Component.java (translateEvent): Translate
AdjustmentEvents to 1.0 Events.
* java/awt/Scrollbar.java (dispatchEventImpl): Set valueIsAdjusting.
Call setValue() before processing event.
* gnu/java/awt/peer/gtk/GtkScrollbarPeer.java (setValues): Check
whether we are currently changing and being called back from the
Scrollbar component.
(setBarValues): New native method.
(postAdjustmentEvent): Mark AdjustmentEvent as user generated.
* native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkScrollbarPeer.c
(Java_gnu_java_awt_peer_gtk_GtkScrollbarPeer_setValues): Renamed to
Java_gnu_java_awt_peer_gtk_GtkScrollbarPeer_setBarValue
* include/gnu_java_awt_peer_gtk_GtkScrollbarPeer.h: Regenerated.
If you think propagating value changes to awt components through the
event queue and dispatchEventImp() is a good idea then I will change
GtkCheckboxPeer accordingly and audit the other awt gtk-peers.
Cheers,
Mark
Index: java/awt/Component.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/Component.java,v
retrieving revision 1.100
diff -u -r1.100 Component.java
--- java/awt/Component.java 15 Feb 2006 20:55:07 - 1.100
+++ java/awt/Component.java 21 Feb 2006 13:55:42 -
@@ -1,5 +1,6 @@
/* Component.java -- a graphics component
- Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006
+ Free Software Foundation
This file is part of GNU Classpath.
@@ -40,6 +41,7 @@
import java.awt.dnd.DropTarget;
import java.awt.event.ActionEvent;
+import java.awt.event.AdjustmentEvent;
import java.awt.event.ComponentEvent;
import java.awt.event.ComponentListener;
import java.awt.event.FocusEvent;
@@ -4876,6 +4878,25 @@
0, 0, oldKey, oldMods);
}
}
+else if (e instanceof AdjustmentEvent)
+ {
+ AdjustmentEvent ae = (AdjustmentEvent) e;
+ int type = ae.getAdjustmentType();
+ int oldType;
+ if (type == AdjustmentEvent.BLOCK_DECREMENT)
+ oldType = Event.SCROLL_PAGE_UP;
+ else if (type == AdjustmentEvent.BLOCK_INCREMENT)
+ oldType = Event.SCROLL_PAGE_DOWN;
+ else if (type == AdjustmentEvent.TRACK)
+ oldType = Event.SCROLL_ABSOLUTE;
+ else if (type == AdjustmentEvent.UNIT_DECREMENT)
+ oldType = Event.SCROLL_LINE_UP;
+ else if (type == AdjustmentEvent.UNIT_INCREMENT)
+ oldType = Event.SCROLL_LINE_DOWN;
+ else
+ oldType = type;
+ translated = new Event(target, oldType, new Integer(ae.getValue()));
+ }
else if (e instanceof ActionEvent)
translated = new Event (target, Event.ACTION_EVENT,
((ActionEvent) e).getActionCommand ());
Index: java/awt/Scrollbar.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/Scrollbar.java,v
retrieving revision 1.27
diff -u -r1.27 Scrollbar.java
--- java/awt/Scrollbar.java 2 Jul 2005 20:32:25 - 1.27
+++ java/awt/Scrollbar.java 21 Feb 2006 13:55:42 -
@@ -1,5 +1,5 @@
/* Scrollbar.java -- AWT Scrollbar widget
- Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005
+ Copyright (C) 1999,
[cp-patches] FYI: Possible GapContent memory leak
We have a possible memory leak in our GapContent implementation. The
problem is that the GapContent stores all the Position objects it
creates in an ArrayList, but since there is no way (except
WeakReferences) to detect when they are no longer used, they are never
removed from that array. I fixed this by storing the Position objects in
WeakReferences and adjusting the class to handle this. This involved
implementing a special Comparator that compares weakly referenced
objects and a clearing mechanism that clears up the ArrayList before new
Positions are created.
2006-02-21 Roman Kennke <[EMAIL PROTECTED]>
PR classpath/26368
* javax/swing/text/GapContent.java
(GapContentPosition): Made class private.
(InsertUndo): Made class private.
(UndoRemove): Made class private.
(WeakPositionComparator): New inner class.
(positions): Made field private.
(createPosition): Clear up GC'ed positions before creating
a new one. Store position as WeakReference.
(getPositionsInRange): Changed to handle WeakReference
positions.
(setPositionsInRange): Changed to handle WeakReference
positions.
(adjustPositionsInRange): Changed to handle WeakReference
positions.
(dumpPositions): Handle WeakReference positions.
(clearPositionReferences): New method.
/Roman
Index: javax/swing/text/GapContent.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/GapContent.java,v
retrieving revision 1.39
diff -u -r1.39 GapContent.java
--- javax/swing/text/GapContent.java 20 Feb 2006 12:07:31 - 1.39
+++ javax/swing/text/GapContent.java 21 Feb 2006 11:28:49 -
@@ -1,5 +1,5 @@
/* GapContent.java --
- Copyright (C) 2002, 2004, 2005 Free Software Foundation, Inc.
+ Copyright (C) 2002, 2004, 2005, 2006 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -39,8 +39,10 @@
package javax.swing.text;
import java.io.Serializable;
+import java.lang.ref.WeakReference;
import java.util.ArrayList;
import java.util.Collections;
+import java.util.Comparator;
import java.util.Iterator;
import java.util.ListIterator;
import java.util.Vector;
@@ -68,8 +70,8 @@
/**
* A [EMAIL PROTECTED] Position} implementation for GapContent.
*/
- class GapContentPosition
- implements Position, Comparable
+ private class GapContentPosition
+implements Position, Comparable
{
/** The index within the buffer array. */
@@ -130,7 +132,7 @@
}
}
- class InsertUndo extends AbstractUndoableEdit
+ private class InsertUndo extends AbstractUndoableEdit
{
public int where, length;
String text;
@@ -169,7 +171,7 @@
}
- class UndoRemove extends AbstractUndoableEdit
+ private class UndoRemove extends AbstractUndoableEdit
{
public int where;
String text;
@@ -206,7 +208,41 @@
}
}
-
+
+ /**
+ * Compares WeakReference objects in a List by comparing the referenced
+ * objects instead.
+ *
+ * @author Roman Kennke ([EMAIL PROTECTED])
+ */
+ private class WeakPositionComparator
+implements Comparator
+ {
+
+/**
+ * Compares two objects of type WeakReference. The objects are compared
+ * using the referenced objects compareTo() method.
+ */
+public int compare(Object o1, Object o2)
+{
+ // Unwrap references.
+ if (o1 instanceof WeakReference)
+o1 = ((WeakReference) o1).get();
+ if (o2 instanceof WeakReference)
+o2 = ((WeakReference) o2).get();
+
+ GapContentPosition p1 = (GapContentPosition) o1;
+ GapContentPosition p2 = (GapContentPosition) o2;
+
+ int retVal;
+ if (p1 == null || p2 == null)
+retVal = -1;
+ else
+retVal = p1.compareTo(p2);
+ return retVal;
+}
+ }
+
/** The serialization UID (compatible with JDK1.5). */
private static final long serialVersionUID = -6226052713477823730L;
@@ -233,9 +269,10 @@
/**
* The positions generated by this GapContent. They are kept in an ordered
- * fashion, so they can be looked up easily.
+ * fashion, so they can be looked up easily. The value objects will be
+ * WeakReference objects that in turn hold GapContentPosition objects.
*/
- ArrayList positions;
+ private ArrayList positions;
/**
* Creates a new GapContent object.
@@ -446,18 +483,22 @@
throw new BadLocationException("The offset was out of the bounds of this"
+ " buffer", offset);
+clearPositionReferences();
+
// We store the actual array index in the GapContentPosition. The real
// offset is then calculated in the GapContentPosition.
int mark = offset;
if (offset >= gapStart)
mark += gapEnd - gapStart;
GapContentPosition pos = new GapContentPosition(mark);
+WeakReference r = new WeakReference(pos);
// Add this into our list in a sorte
Re: [cp-patches] RFC: fixed & implemented highlighting - 2nd try
Committed - Roman reviewed the first version.
cya
Robert
Robert Schuster wrote:
> Hi all.
>
> I fixed to small errors in this patch that lead to strange behavior:
>
>
>>+ // Last line, from beginning-of-line to p1.
>>+ r0.width = r1.x + r1.width;
>
> Had to add -1 to the calculation above otherwise there were drawing
> differences
> between single line and multi line selections.
>
>
>>+ paintHighlight(g, r0);
>> }
>>+
>>+// Prevent useless write & repaint operations.
>>+if (o0 == o1 && o1 == p1)
>>+ return;
>>+
>
> This expression wanted to be
>
>
>>+if (o0 == p0 && o1 == p1)
>
>
> Apart from that I updated the copyright headers in the affected files.
>
> After fixing that I cannot see any more problems with the highlighting
> mechanism.
>
>
> ChangeLog stays the same:
>
> 2006-02-21 Robert Schuster <[EMAIL PROTECTED]>
>
> * javax/swing/plaf/basic/BasicTextUI.java:
> (paint): Remove unneccessary part of the if-expression.
> (damageRange): Added case where the range spans multiple lines.
> * javax/swing/text/DefaultCaret.java:
> (clearHighlight): New method.
> (handleHighlight): Removed unneccessary part of the if-expression.
> (setDot): Use clearHighlight method.
> * javax/swing/text/DefaultHighlighter.java: Use ArrayList instead
> of Vector.
> (paint): Prevented calling size() on every loop iteration, fixed
> calculation of allocation area bounds.
> (getHighlights): Implemented.
> (removeHighlight): Mark damaged area in textcomponent.
> (addHighlight): Mark damaged area in textcomponent.
> (changeHighlight): Mark damaged area in textcomponent.
> (DefaultHighlighter.HighlightEntry): Made it a real
> Highlighter.Highlight implementation.
> (DefaultHighlighter.DefaultHighlightPainter.paint): Fixed
> calculations.
>
> cya
> Robert
>
>
>
>
>
> Index: javax/swing/text/DefaultCaret.java
> ===
> RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultCaret.java,v
> retrieving revision 1.30
> diff -u -r1.30 DefaultCaret.java
> --- javax/swing/text/DefaultCaret.java9 Feb 2006 17:15:33 -
> 1.30
> +++ javax/swing/text/DefaultCaret.java21 Feb 2006 10:25:59 -
> @@ -577,7 +577,39 @@
>{
> return mark;
>}
> -
> +
> + private void clearHighlight()
> + {
> +Highlighter highlighter = textComponent.getHighlighter();
> +
> +if (highlighter == null)
> + return;
> +
> +if (selectionVisible)
> + {
> +try
> + {
> +if (highlightEntry == null)
> + highlightEntry = highlighter.addHighlight(0, 0,
> getSelectionPainter());
> +else
> + highlighter.changeHighlight(highlightEntry, 0, 0);
> + }
> +catch (BadLocationException e)
> + {
> +// This should never happen.
> +throw new InternalError();
> + }
> + }
> +else
> + {
> +if (highlightEntry != null)
> + {
> +highlighter.removeHighlight(highlightEntry);
> +highlightEntry = null;
> + }
> + }
> + }
> +
>private void handleHighlight()
>{
> Highlighter highlighter = textComponent.getHighlighter();
> @@ -588,7 +620,7 @@
> int p0 = Math.min(dot, mark);
> int p1 = Math.max(dot, mark);
>
> -if (selectionVisible && p0 != p1)
> +if (selectionVisible)
>{
> try
> {
> @@ -818,6 +850,7 @@
> if (doc != null)
>this.dot = Math.min(dot, doc.getLength());
> this.dot = Math.max(this.dot, 0);
> +
> handleHighlight();
> adjustVisibility(this);
> appear();
> @@ -842,7 +875,8 @@
>this.dot = Math.min(dot, doc.getLength());
> this.dot = Math.max(this.dot, 0);
> this.mark = this.dot;
> -handleHighlight();
> +
> +clearHighlight();
> adjustVisibility(this);
> appear();
>}
> Index: javax/swing/text/DefaultHighlighter.java
> ===
> RCS file:
> /cvsroot/classpath/classpath/javax/swing/text/DefaultHighlighter.java,v
> retrieving revision 1.6
> diff -u -r1.6 DefaultHighlighter.java
> --- javax/swing/text/DefaultHighlighter.java 19 Oct 2005 14:57:30 -
> 1.6
> +++ javax/swing/text/DefaultHighlighter.java 21 Feb 2006 10:25:59 -
> @@ -1,5 +1,5 @@
> /* DefaultHighlighter.java --
> - Copyright (C) 2004 Free Software Foundation, Inc.
> + Copyright (C) 2004, 2006 Free Software Foundation, Inc.
>
> This file is part of GNU Classpath.
>
> @@ -40,9 +40,10 @@
>
> import java.awt.Color;
> import java.awt.Graphics;
> +import java.awt.Insets;
> import java.awt.Rectangle;
> imp
Re: [cp-patches] RFC: fixed & implemented highlighting
HI Robert, Am Dienstag, den 21.02.2006, 01:36 +0100 schrieb Robert Schuster: > Hi, > I am surprised myself but I really got this working. :) > > What I fixed here are mainly drawing problems. The underlying representation > of > the highlighted area was mostly correct. There are some small glitches in the > behavior which I am going to fix next. > > Please comment the patch. Very good, please commit. /Roman > > The ChangeLog: > > 2006-02-21 Robert Schuster <[EMAIL PROTECTED]> > > * javax/swing/plaf/basic/BasicTextUI.java: > (paint): Remove unneccessary part of the if-expression. > (damageRange): Added case where the range spans multiple lines. > * javax/swing/text/DefaultCaret.java: > (clearHighlight): New method. > (handleHighlight): Removed unneccessary part of the if-expression. > (setDot): Use clearHighlight method. > * javax/swing/text/DefaultHighlighter.java: Use ArrayList instead > of Vector. > (paint): Prevented calling size() on every loop iteration, fixed > calculation of allocation area bounds. > (getHighlights): Implemented. > (removeHighlight): Mark damaged area in textcomponent. > (addHighlight): Mark damaged area in textcomponent. > (changeHighlight): Mark damaged area in textcomponent. > (DefaultHighlighter.HighlightEntry): Made it a real > Highlighter.Highlight implementation. > (DefaultHighlighter.DefaultHighlightPainter.paint): Fixed > calculations. > > cya > Robert > signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[cp-patches] RFC: fixed & implemented highlighting - 2nd try
Hi all.
I fixed to small errors in this patch that lead to strange behavior:
> + // Last line, from beginning-of-line to p1.
> + r0.width = r1.x + r1.width;
Had to add -1 to the calculation above otherwise there were drawing differences
between single line and multi line selections.
> + paintHighlight(g, r0);
> }
> +
> +// Prevent useless write & repaint operations.
> +if (o0 == o1 && o1 == p1)
> + return;
> +
This expression wanted to be
> +if (o0 == p0 && o1 == p1)
Apart from that I updated the copyright headers in the affected files.
After fixing that I cannot see any more problems with the highlighting
mechanism.
ChangeLog stays the same:
2006-02-21 Robert Schuster <[EMAIL PROTECTED]>
* javax/swing/plaf/basic/BasicTextUI.java:
(paint): Remove unneccessary part of the if-expression.
(damageRange): Added case where the range spans multiple lines.
* javax/swing/text/DefaultCaret.java:
(clearHighlight): New method.
(handleHighlight): Removed unneccessary part of the if-expression.
(setDot): Use clearHighlight method.
* javax/swing/text/DefaultHighlighter.java: Use ArrayList instead
of Vector.
(paint): Prevented calling size() on every loop iteration, fixed
calculation of allocation area bounds.
(getHighlights): Implemented.
(removeHighlight): Mark damaged area in textcomponent.
(addHighlight): Mark damaged area in textcomponent.
(changeHighlight): Mark damaged area in textcomponent.
(DefaultHighlighter.HighlightEntry): Made it a real
Highlighter.Highlight implementation.
(DefaultHighlighter.DefaultHighlightPainter.paint): Fixed
calculations.
cya
Robert
Index: javax/swing/text/DefaultCaret.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultCaret.java,v
retrieving revision 1.30
diff -u -r1.30 DefaultCaret.java
--- javax/swing/text/DefaultCaret.java 9 Feb 2006 17:15:33 - 1.30
+++ javax/swing/text/DefaultCaret.java 21 Feb 2006 10:25:59 -
@@ -577,7 +577,39 @@
{
return mark;
}
-
+
+ private void clearHighlight()
+ {
+Highlighter highlighter = textComponent.getHighlighter();
+
+if (highlighter == null)
+ return;
+
+if (selectionVisible)
+ {
+try
+ {
+if (highlightEntry == null)
+ highlightEntry = highlighter.addHighlight(0, 0, getSelectionPainter());
+else
+ highlighter.changeHighlight(highlightEntry, 0, 0);
+ }
+catch (BadLocationException e)
+ {
+// This should never happen.
+throw new InternalError();
+ }
+ }
+else
+ {
+if (highlightEntry != null)
+ {
+highlighter.removeHighlight(highlightEntry);
+highlightEntry = null;
+ }
+ }
+ }
+
private void handleHighlight()
{
Highlighter highlighter = textComponent.getHighlighter();
@@ -588,7 +620,7 @@
int p0 = Math.min(dot, mark);
int p1 = Math.max(dot, mark);
-if (selectionVisible && p0 != p1)
+if (selectionVisible)
{
try
{
@@ -818,6 +850,7 @@
if (doc != null)
this.dot = Math.min(dot, doc.getLength());
this.dot = Math.max(this.dot, 0);
+
handleHighlight();
adjustVisibility(this);
appear();
@@ -842,7 +875,8 @@
this.dot = Math.min(dot, doc.getLength());
this.dot = Math.max(this.dot, 0);
this.mark = this.dot;
-handleHighlight();
+
+clearHighlight();
adjustVisibility(this);
appear();
}
Index: javax/swing/text/DefaultHighlighter.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultHighlighter.java,v
retrieving revision 1.6
diff -u -r1.6 DefaultHighlighter.java
--- javax/swing/text/DefaultHighlighter.java 19 Oct 2005 14:57:30 - 1.6
+++ javax/swing/text/DefaultHighlighter.java 21 Feb 2006 10:25:59 -
@@ -1,5 +1,5 @@
/* DefaultHighlighter.java --
- Copyright (C) 2004 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2006 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -40,9 +40,10 @@
import java.awt.Color;
import java.awt.Graphics;
+import java.awt.Insets;
import java.awt.Rectangle;
import java.awt.Shape;
-import java.util.Vector;
+import java.util.ArrayList;
public class DefaultHighlighter extends LayeredHighlighter
{
@@ -84,7 +85,7 @@
// This should never occur.
return;
}
-
+
if (r0 == null || r1 == null)
return;
@@ -100,7 +101,7 @@
paintHighlight(g, r0);
return;
}
-
+
// First line, from p0 to end-of-line.
r0.width = rect.x + rect.width - r0.x;
paintHighlight(g, r0);
@@ -109,15 +110,19 @@
// have the same
Re: [cp-patches] [generics] RFC: new Enum java.math.RoundingMode
On Tue, 2006-02-21 at 10:01 +0100, Tom Tromey wrote:
> > "Anthony" == Anthony Balkissoon <[EMAIL PROTECTED]> writes:
> Anthony> + public int hashCode()
> Anthony> + {
> Anthony> +//FIXME: Not sure what to do here.
> Anthony> +return super.hashCode();
> Anthony> + }
>
> Just invent some function that uses the data local to the class.
Since you alrady have a equals() method it makes sense to just xor (the
hashcode) of the values used in that method. that automatically makes
sure that the eaulas()/hashCode() contract (equal objects have the same
hashcode) is obeyed.
precision ^ roundMode.hashCode() seems a good idea in this case.
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
[cp-patches] FYI: ZipConstants patch
Hi,
I committed Stuart's patch.
Regards,
Jeroen
2006-02-20 Stuart Ballard <[EMAIL PROTECTED]>
* java/util/zip/ZipConstants.java
(LOCSIG): Change type to long.
(EXTSIG): Likewise.
(CENSIG): Likewise.
(ENDSIG): Likewise.
* java/util/zip/ZipOutputStream.java
(writeLeInt(long)): New method.
Index: java/util/zip/ZipConstants.java
===
RCS file: /cvsroot/classpath/classpath/java/util/zip/ZipConstants.java,v
retrieving revision 1.6
diff -u -r1.6 ZipConstants.java
--- java/util/zip/ZipConstants.java 2 Jul 2005 20:32:44 - 1.6
+++ java/util/zip/ZipConstants.java 21 Feb 2006 09:06:51 -
@@ -1,5 +1,5 @@
/* java.util.zip.ZipConstants
- Copyright (C) 2001 Free Software Foundation, Inc.
+ Copyright (C) 2001, 2006 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -41,7 +41,7 @@
{
/* The local file header */
int LOCHDR = 30;
- int LOCSIG = 'P'|('K'<<8)|(3<<16)|(4<<24);
+ long LOCSIG = 'P'|('K'<<8)|(3<<16)|(4<<24);
int LOCVER = 4;
int LOCFLG = 6;
@@ -54,7 +54,7 @@
int LOCEXT = 28;
/* The Data descriptor */
- int EXTSIG = 'P'|('K'<<8)|(7<<16)|(8<<24);
+ long EXTSIG = 'P'|('K'<<8)|(7<<16)|(8<<24);
int EXTHDR = 16;
int EXTCRC = 4;
@@ -62,7 +62,7 @@
int EXTLEN = 12;
/* The central directory file header */
- int CENSIG = 'P'|('K'<<8)|(1<<16)|(2<<24);
+ long CENSIG = 'P'|('K'<<8)|(1<<16)|(2<<24);
int CENHDR = 46;
int CENVEM = 4;
@@ -82,7 +82,7 @@
int CENOFF = 42;
/* The entries in the end of central directory */
- int ENDSIG = 'P'|('K'<<8)|(5<<16)|(6<<24);
+ long ENDSIG = 'P'|('K'<<8)|(5<<16)|(6<<24);
int ENDHDR = 22;
/* The following two fields are missing in SUN JDK */
Index: java/util/zip/ZipOutputStream.java
===
RCS file: /cvsroot/classpath/classpath/java/util/zip/ZipOutputStream.java,v
retrieving revision 1.11
diff -u -r1.11 ZipOutputStream.java
--- java/util/zip/ZipOutputStream.java 30 Aug 2005 21:47:44 - 1.11
+++ java/util/zip/ZipOutputStream.java 21 Feb 2006 09:07:26 -
@@ -1,5 +1,5 @@
/* ZipOutputStream.java --
- Copyright (C) 2001, 2004, 2005 Free Software Foundation, Inc.
+ Copyright (C) 2001, 2004, 2005, 2006 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -161,6 +161,16 @@
}
/**
+ * Write a long value as an int. Some of the zip constants
+ * are declared as longs even though they fit perfectly well
+ * into integers.
+ */
+ private void writeLeInt(long value) throws IOException
+ {
+writeLeInt((int) value);
+ }
+
+ /**
* Starts a new Zip entry. It automatically closes the previous
* entry if present. If the compression method is stored, the entry
* must have a valid size and crc, otherwise all elements (except
Re: [cp-patches] [generics] RFC: new Enum java.math.RoundingMode
> "Anthony" == Anthony Balkissoon <[EMAIL PROTECTED]> writes:
Anthony> Also, I forgot to put the GNU Classpath header in
Anthony> RoundingMode, but this patch includes it.
For some reason the generics branch doesn't have this header
template... some merge problem I supposed, but I haven't looked.
Anthony> + public int hashCode()
Anthony> + {
Anthony> +//FIXME: Not sure what to do here.
Anthony> +return super.hashCode();
Anthony> + }
Just invent some function that uses the data local to the class.
Tom
[cp-patches] [Patch] Removed empty file
Hello list, I removed the attached file as its empty, no java class inside. And it confuses GCJ when using current classpath CVS as snapshot when building gcj 4.1 or gcj trunk. Cheers, Michael 2006-02-21 Michael Koch <[EMAIL PROTECTED]> * gnu/javax/net/ssl/provider/PRNG.java: Removed. Index: gnu/javax/net/ssl/provider/PRNG.java === RCS file: gnu/javax/net/ssl/provider/PRNG.java diff -N gnu/javax/net/ssl/provider/PRNG.java --- gnu/javax/net/ssl/provider/PRNG.java26 Jan 2006 02:25:11 - 1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,41 +0,0 @@ -/* PRNG.java -- - Copyright (C) 2006 Free Software Foundation, Inc. - -This file is a part of GNU Classpath. - -GNU Classpath is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or (at -your option) any later version. - -GNU Classpath is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with GNU Classpath; if not, write to the Free Software -Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 -USA - -Linking this library statically or dynamically with other modules is -making a combined work based on this library. Thus, the terms and -conditions of the GNU General Public License cover the whole -combination. - -As a special exception, the copyright holders of this library give you -permission to link this library with independent modules to produce an -executable, regardless of the license terms of these independent -modules, and to copy and distribute the resulting executable under -terms of your choice, provided that you also meet, for each linked -independent module, the terms and conditions of the license of that -module. An independent module is a module which is not derived from -or based on this library. If you modify this library, you may extend -this exception to your version of the library, but you are not -obligated to do so. If you do not wish to do so, delete this -exception statement from your version. */ - - -package gnu.javax.net.ssl.provider; - -import java.security.SecureRandom; \ No newline at end of file
Re: [cp-patches] [generics] RFC: new Enum java.math.RoundingMode
On Mon, 2006-02-20 at 17:33 -0500, Anthony Balkissoon wrote:
> On Mon, 2006-02-20 at 15:09 -0500, Anthony Balkissoon wrote:
> > This is RFC because it's my first commit to the generics branch and I
> > just want to make sure there aren't any special procedures I forgot.
> >
> > 2006-02-20 Anthony Balkissoon <[EMAIL PROTECTED]>
> >
> > * java/math/RoundingMode: New Enum.
> >
> > --Tony
>
>
> This is replaced by:
> 2006-02-20 Anthony Balkissoon <[EMAIL PROTECTED]>
>
> * java/math/MathContext.java: New class.
> * java/math/RoundingMode: New Enum.
>
> Also, I forgot to put the GNU Classpath header in RoundingMode, but this
> patch includes it. Comments are still appreciated. I'll commit this
> tomorrow if no one objects.
>
> --Tony
Looks fine to me -- the header would have been my only comment. Of
course, I'm assuming it applies cleanly and compiles... ;)
It's a pity this new math stuff uses an enum for RoundingMode, because
AFAICS that's the only thing that restricts this to the generics branch.
--
Andrew :-)
Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
If you use Microsoft Office, support movement towards the end of vendor
lock-in:
http://opendocumentfellowship.org/petition/
"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
