Hi,
as mentioned in PR 26157[0] I observed that the JDK's JTextArea adjusts its size
automatically when the characters leave the allocation area of the component.
Our JTextArea did not have this functionality until now.
It took me a while to find out where to place the code that could do the
necce
Am Mittwoch, den 22.02.2006, 09:08 +0100 schrieb Robert Schuster:
> Hi,
> as mentioned in PR 26157[0] I observed that the JDK's JTextArea adjusts its
> size
> automatically when the characters leave the allocation area of the component.
> Our JTextArea did not have this functionality until now.
>
Hi,
Small compile fix for gcj 4.0 as pointed out by the autobuilder.
2006-02-22 Mark Wielaard <[EMAIL PROTECTED]>
* javax/swing/text/html/HTMLDocument.java (createDefaultRoot): Fully
qualify AbstractDocument.AttributeContext.
(blockOpen): Likewise.
Committed,
Mark
Index: javax/s
Hi.
Roman Kennke wrote:
> Am Mittwoch, den 22.02.2006, 09:08 +0100 schrieb Robert Schuster:
>
>>Hi,
>>as mentioned in PR 26157[0] I observed that the JDK's JTextArea adjusts its
>>size
>>automatically when the characters leave the allocation area of the component.
>>Our JTextArea did not have th
In RepaintManager.addInvalidComponent we should really also consider the
component itself and ask if it is a validateRoot. Up to now we started
with the component's parent.
2006-02-22 Roman Kennke <[EMAIL PROTECTED]>
* javax/swing/RepaintManager.java
(addInvalidComponent): Also
I fixed 3 methods in JEditorPane which make this component behave more
nicely in scolling containers. Took me quite a while to determine the
correct behaviour (using BeanShell) and then found that this is even
specified.. duh
2006-02-22 Roman Kennke <[EMAIL PROTECTED]>
* javax/swing/JEd
This adds the isValidateRoot() method to JTextField, which is a nice
little optimization, because otherwise each key press would cause
revalidation of the whole tree.
2006-02-22 Roman Kennke <[EMAIL PROTECTED]>
* javax/swing/JTextField.java
(isValidateRoot): New method.
/Roman
Hi,
the magic caret position can be null when the cursor has not moved yet. I havent
considered this when writing the up/down movement & selection actions. This
patch fixes that.
The ChangeLog:
2006-02-22 Robert Schuster <[EMAIL PROTECTED]>
* javax/swing/text/DefaultEditorKit.java: Add
Hi Robert,
looks good, please commit this (if you haven't already).
/Roman
Am Mittwoch, den 22.02.2006, 10:51 +0100 schrieb Robert Schuster:
> Hi.
>
> Roman Kennke wrote:
> > Am Mittwoch, den 22.02.2006, 09:08 +0100 schrieb Robert Schuster:
> >
> >>Hi,
> >>as mentioned in PR 26157[0] I observe
Hi,
it is really interesting how much influence a simple comparison operator can
have.
This patch fixes the problem[0] I had with up & down movement in jtextareas by
prefering the first value in the comparison by using <= instead of <.
The ChangeLog:
2006-02-22 Robert Schuster <[EMAIL PROTECT
Hi.
Roman Kennke wrote:
> Hi Robert,
>
> looks good, please commit this (if you haven't already).
Cool. Thanks for the review.
I committed the version attached. It the same like the old one but corrects the
copyright header. :)
ChangeLog stays the same:
2006-02-22 Robert Schuster <[EMAIL PR
On 20 Feb, Andrew Haley wrote:
> Andrew Pinski writes:
> > >
> > > In libjava/classpath there are two .cvsignore files which haven't been
> > > deleted yet:
> > >
> > > native/jni/midi-alsa/.cvsignore
> > > native/jni/midi-dssi/.cvsignore
> > >
> > > Should they go, too?
> > > They
Hi,
the title says it all. I saw[0] that painting of the highlight slowed down as
the selected text got longer.
By using pen & paper I found a nice way to minimize the damaged area. Hopefully
that algorithm isnt patented somewhere. :P
the ChangeLog:
2006-02-22 Robert Schuster <[EMAIL PROTECTED
Hi,
On Tue, 2006-02-21 at 10:50 -0500, Thomas Fitzsimmons wrote:
> > 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 thoug
> This comment should be moved out of Toolkit and into GtkToolkit.
Sure.
> GtkLightweightContainerPeer needs to override GtkComponentPeer painting
> methods to be no-ops: handleEvent and postExposeEvent.
> GtkLightweightContainerPeer.repaint should be overridden to be
> LightweightComponentPeer'
On Wed, 2006-02-22 at 12:34 +0100, Robert Schuster wrote:
> 2006-02-22 Robert Schuster <[EMAIL PROTECTED]>
>
> * javax/swing/text/PlainDocument.java:
> (getPreferredSpan): Added missing 'break'.
> statement which corrects an unwanted fall through.
> (updateDamage
> 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.create
On Wed, 2006-02-22 at 11:39 -0500, Scott Gilbertson wrote:
> Looking back, I see the ambiguity in my previous email.
> The structure I had in mind was:
>
> class LightweightComponentPeer
> implements LightweightPeer, ComponentPeer
> {
> // (as now, including the repaint implementation)
> }
ok
> > // New class:
> > class GtkLightweightContainerPeer
> > extends LightweightComponentPeer
> > implements ContainerPeer
> > {
> > // ContainerPeer-specific methods that used
> > // to be in GLightweightPeer
> > }
>
Are you saying you don't think we need class
gnu.java.awt.peer.LightweightC
On Wed, 2006-02-22 at 12:51 -0500, Scott Gilbertson wrote:
> > > // New class:
> > > class GtkLightweightContainerPeer
> > > extends LightweightComponentPeer
> > > implements ContainerPeer
> > > {
> > > // ContainerPeer-specific methods that used
> > > // to be in GLightweightPeer
> > > }
> >
On Wed, 2006-02-22 at 11:39 -0500, Scott Gilbertson wrote:
> Looking back, I see the ambiguity in my previous email.
> The structure I had in mind was:
>
> class LightweightComponentPeer
> implements LightweightPeer, ComponentPeer
> {
> // (as now, including the repaint implementation)
> }
>
> I agree with Scott that we need to add a LightweightContainerPeer class.
> I fixed up Toolkit, as well.
> I also added the painting methods to GtkLightweightContainerPeer (those
> that override ComponentPeer).
>
> This is the updated ChangeLog. The newest patch is attached.
>
> 2006-02-22 Lilli
I added some of the missing constructors in BigDecimal and fixed a small
problem with one of the old ones.
The BigDecimal(char[], int, int) constructor is the meat of this patch,
which I adapted from the BigDecimal(String) constructor but fixed some
problems and commented thoroughly.
More BigDe
23 matches
Mail list logo
