From Dmitri.Trembovetski at Sun.COM  Fri Jan  4 16:16:27 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Fri, 04 Jan 2008 16:16:27 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
 Exclusive Mode not working with	Xorg server 1.3.0 and above
In-Reply-To: <4769B004.10308@Sun.COM>
References: <1197121416.14405.50.camel@dylan> <4769B004.10308@Sun.COM>
Message-ID: <477ECC5B.6050703@Sun.COM>


   Hi Dan,

   did you receive a confirmation about the SCA?

   Thanks,
     Dmitri


Dmitri Trembovetski wrote:
> 
>   Hi Dan,
> 
>   I know that you sent your SCA (repeatedly =) so
>   I looked at the fix.
> 
>   It looks good.
> 
>   Please see my comments below.
> 
> Dan Munckton wrote:
>> APPROACH
>>
>> The fix is really simple it just checks to make sure RANDR's version is
>> 1.2 or greater if usingXinerama is true, if this is all fine it proceeds
>> to load the libXrandr funcs.
> 
>   Sounds good.
> 
>> For the moment I've completely ignored 6599351, and not touched any of
>> the Xinerama loading code at all. 
> 
>   OK, I think it's a good idea to separate the two fixes.
> 
>> BTW I note that with 6599351 the user has an old style X dual-head
>> config without using Xinerama - I found a note on the Debian Xrandr1.2
>> Howto wiki page [1] explaining that this configuration should crash
>> Xserver 1.3. Does it behave differently in Solaris X?
> 
>   You mean, if randr is present?
>   It could be that it didn't have randr extension.
>   It looks from the comments in the bug report that 1.3 works
>   fine with dual screens w/o xinerama in general.
> 
>> TESTING
>>
>> The equipment I have here will allow me to test single monitor setups
>> with X servers 1.2 and 1.3. Java now behaves as expected in the
>> following cases:
>>
>> 1) Xserver 1.2 + 1 monitor + Xrandr
>>     Expect: isFullScreenSupported: true
>>     Result: PASS
>>
>> 2) Xserver 1.2 + 1 monitor + Xinerama enabled (Xinerama won't actually
>> load but Xrandr and DRI won't load either)
>>     Expect: isFullScreenSupported: false
>>     Result: PASS
>>
>> 3) Xserver 1.3 + 1 monitor + Xrandr + fake Xinerama
>>     Expect: isFullScreenSupported: true
>>     Result: PASS
>>
>> 4) Xserver 1.3 + 1 monitor + Xinerama enabled (Xinerama won't actually
>> load but Xrandr and DRI won't load either)
>>     Expect: isFullScreenSupported: false
>>     Result: PASS
> 
>   I assume this is all on linux, right?
> 
>> TESTING TODO
>>
>> I have an external LCD monitor at work which I can hook up to my laptop
>> next week. This should allow me to test out Xrandr 1.2 multi-monitor
>> setups. I'll post results as soon as complete.
>>
>> However I don't think I can test out Xinerama dual head configs. I tried
>> to set this up once before but failed - I'm still not 100% certain if
>> Xinerama is actually compiled into my X server I will need to check this
>> out properly.
>> If anyone here has a multi monitor setup already and would be prepared
>> to help me test the following scenarios I'd be very grateful.
>>
>> 5) Xserver 1.2 + 2 monitor + Xinerama (Xrandr and DRI won't load)
>>     Expect: isFullScreenSupported: false
>>
>> 6) Xserver 1.3 + 2 monitors + Xinerama
>>     Expect: isFullScreenSupported: false
> 
>   Ugh. That might be a problem - we don't have too many
>   multiscreen solaris or linux systems that we could install
>   new X server on. But we'll see what we can do.
> 
>   We can at least test on the configuration we have.
>   I have a Solaris 10 machine with dual (non-xinerama)
>   screen - the fs mode isn't supported on it.
> 
>> I am also still to run the jtreg tests against this. I will come back
>> with results.
> 
>   I can't think of a good automated regression test for this fix.
>   You can I suppose write a jtreg regression test as script
>   (it is allowed), run xdpyinfo and find out that randr of the
>   correct version is installed and then test if fullscreen
>   is supported but it may not necessarily be a fully correct test -
>   fullscreen may not be enabled for other reasons.
> 
>> Also, do I need to mail both awt-dev and 2d-dev or will just one do in
>> future?
> 
>   This particular fix is 2D only, so we can continue on 2d-dev.
>   The other one - we'll see. I suppose it's not that much of a problem
>   if you cc both lists.
> 
>   Thanks,
>     Dmitri
> 
> 
>>
>> Cheers
>>
>> Dan
>>
>>
>> [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469
>> [1] Section VI.3 of http://wiki.debian.org/XStrikeForce/HowToRandR12
>>

From Dmitri.Trembovetski at Sun.COM  Fri Jan  4 16:26:06 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Fri, 04 Jan 2008 16:26:06 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
 Exclusive Mode not working with	Xorg server 1.3.0 and above
In-Reply-To: <477ECC5B.6050703@Sun.COM>
References: <1197121416.14405.50.camel@dylan> <4769B004.10308@Sun.COM>
	<477ECC5B.6050703@Sun.COM>
Message-ID: <477ECE9E.7020106@Sun.COM>


   OK, Phil actually bothered to check, and now we see
   your name in the list of SCA signatories! Woo-hoo!

   Thanks,
     Dmitri

Dmitri Trembovetski wrote:
> 
>   Hi Dan,
> 
>   did you receive a confirmation about the SCA?
> 
>   Thanks,
>     Dmitri
> 
> 
> Dmitri Trembovetski wrote:
>>
>>   Hi Dan,
>>
>>   I know that you sent your SCA (repeatedly =) so
>>   I looked at the fix.
>>
>>   It looks good.
>>
>>   Please see my comments below.
>>
>> Dan Munckton wrote:
>>> APPROACH
>>>
>>> The fix is really simple it just checks to make sure RANDR's version is
>>> 1.2 or greater if usingXinerama is true, if this is all fine it proceeds
>>> to load the libXrandr funcs.
>>
>>   Sounds good.
>>
>>> For the moment I've completely ignored 6599351, and not touched any of
>>> the Xinerama loading code at all. 
>>
>>   OK, I think it's a good idea to separate the two fixes.
>>
>>> BTW I note that with 6599351 the user has an old style X dual-head
>>> config without using Xinerama - I found a note on the Debian Xrandr1.2
>>> Howto wiki page [1] explaining that this configuration should crash
>>> Xserver 1.3. Does it behave differently in Solaris X?
>>
>>   You mean, if randr is present?
>>   It could be that it didn't have randr extension.
>>   It looks from the comments in the bug report that 1.3 works
>>   fine with dual screens w/o xinerama in general.
>>
>>> TESTING
>>>
>>> The equipment I have here will allow me to test single monitor setups
>>> with X servers 1.2 and 1.3. Java now behaves as expected in the
>>> following cases:
>>>
>>> 1) Xserver 1.2 + 1 monitor + Xrandr
>>>     Expect: isFullScreenSupported: true
>>>     Result: PASS
>>>
>>> 2) Xserver 1.2 + 1 monitor + Xinerama enabled (Xinerama won't actually
>>> load but Xrandr and DRI won't load either)
>>>     Expect: isFullScreenSupported: false
>>>     Result: PASS
>>>
>>> 3) Xserver 1.3 + 1 monitor + Xrandr + fake Xinerama
>>>     Expect: isFullScreenSupported: true
>>>     Result: PASS
>>>
>>> 4) Xserver 1.3 + 1 monitor + Xinerama enabled (Xinerama won't actually
>>> load but Xrandr and DRI won't load either)
>>>     Expect: isFullScreenSupported: false
>>>     Result: PASS
>>
>>   I assume this is all on linux, right?
>>
>>> TESTING TODO
>>>
>>> I have an external LCD monitor at work which I can hook up to my laptop
>>> next week. This should allow me to test out Xrandr 1.2 multi-monitor
>>> setups. I'll post results as soon as complete.
>>>
>>> However I don't think I can test out Xinerama dual head configs. I tried
>>> to set this up once before but failed - I'm still not 100% certain if
>>> Xinerama is actually compiled into my X server I will need to check this
>>> out properly.
>>> If anyone here has a multi monitor setup already and would be prepared
>>> to help me test the following scenarios I'd be very grateful.
>>>
>>> 5) Xserver 1.2 + 2 monitor + Xinerama (Xrandr and DRI won't load)
>>>     Expect: isFullScreenSupported: false
>>>
>>> 6) Xserver 1.3 + 2 monitors + Xinerama
>>>     Expect: isFullScreenSupported: false
>>
>>   Ugh. That might be a problem - we don't have too many
>>   multiscreen solaris or linux systems that we could install
>>   new X server on. But we'll see what we can do.
>>
>>   We can at least test on the configuration we have.
>>   I have a Solaris 10 machine with dual (non-xinerama)
>>   screen - the fs mode isn't supported on it.
>>
>>> I am also still to run the jtreg tests against this. I will come back
>>> with results.
>>
>>   I can't think of a good automated regression test for this fix.
>>   You can I suppose write a jtreg regression test as script
>>   (it is allowed), run xdpyinfo and find out that randr of the
>>   correct version is installed and then test if fullscreen
>>   is supported but it may not necessarily be a fully correct test -
>>   fullscreen may not be enabled for other reasons.
>>
>>> Also, do I need to mail both awt-dev and 2d-dev or will just one do in
>>> future?
>>
>>   This particular fix is 2D only, so we can continue on 2d-dev.
>>   The other one - we'll see. I suppose it's not that much of a problem
>>   if you cc both lists.
>>
>>   Thanks,
>>     Dmitri
>>
>>
>>>
>>> Cheers
>>>
>>> Dan
>>>
>>>
>>> [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469
>>> [1] Section VI.3 of http://wiki.debian.org/XStrikeForce/HowToRandR12
>>>

From werner.randelshofer at bluewin.ch  Tue Jan 15 10:05:17 2008
From: werner.randelshofer at bluewin.ch (Werner Randelshofer)
Date: Tue, 15 Jan 2008 19:05:17 +0100
Subject: <AWT Dev> Request for uniform and contiguous
	resolution-independence in AWT
Message-ID: <7B951DD8-6CEA-4E2E-9EF0-8128B702FCD9@bluewin.ch>

Dear members of the awt-dev group,

I am currently investigating the feasibility of a Swing Aqua Look and  
Fool for the OpenJDK port for Mac OS X "SoyLatte".

Starting with Mac OS X 10.5, the Aqua user interface is resolution  
independent.[1]
This feature effectively decouples the user interface from device  
pixels, allowing to scale the user interface uniformly and  
contiguously. The coordinate system of components is based on a  
floating point coordinate system.

This is different from the resolution-independence concept currently  
implemented in Java AWT, which assumes non-uniform and discrete scaling.

I would love to have an API in AWT for resolution independence, so  
that we could properly implement it in SoyLatte, without use of magic  
tricks, like Apple is currently doing with J2SE5 on Mac OS 10.5.

As far as I know, Mac OS X and Windows Vista support uniform and  
contiguous resolution independence in conceptually the same way. There  
might be even more OpenJDK ports which would benefit from this, like  
OpenJDK for Haiku OS.


Na?vely, I tried to submit a feature request in the Java bug reporter,  
but it tells me, that I can't request features for platforms which are  
not supported by Sun. I made a request at the porters-dev mailing  
list, and they suggested, to start a thread in this mailing list.


-Werner

[1]
http://developer.apple.com/documentation/UserExperience/Conceptual/HiDPIOverview/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080115/8cc3412b/attachment.html 

From lists at munckfish.net  Wed Jan 16 07:37:39 2008
From: lists at munckfish.net (Dan Munckton)
Date: Wed, 16 Jan 2008 15:37:39 +0000
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
	Exclusive	Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <1197369278.7494.8.camel@dylan>
References: <1197121416.14405.50.camel@dylan>  <475AF914.1090309@sun.com>
	<1197369278.7494.8.camel@dylan>
Message-ID: <1200497859.7514.14.camel@dylan>

Hi all

Happy new year.

Although I've been silent for a bit, I'm still working on this. I've
tested more widely now and have managed to configure multi-monitor
setups on both Xorg server's 1.2 and 1.3. I'm also now on the SCA
contributors list.

UPDATED PATCH

Please see the attached updated patch.

I needed to add code to prevent FSEM (Fullscreen Exclusive Mode) on Xorg
1.3 with 2 or more monitors. Although I suspect this is technically
possible now (as it is in Windows) running a full-screen app in a
multi-monitor setup currently disables all Graphics devices except the
default and requires an X restart to bring them back. So I guess it'll
need more work to support that. 

Should I raise an RFE? Is this something worth doing?

FEEDBACK SO FAR

Guys, am I on the right lines?

Yuri, you were going to work on 6599351, does what I've done fit in or
were you planning more radical changes?

ADVICE ON JTREG APPROACH

Also I need some advice on how to approach a jtreg test for this. My
current plan is to use a shell script to query command line tools like
xdpyinfo and xrandr and then run a Java tool to check whether FSEM is or
isn't supported as expected. But I've no idea (yet) how portable this
would be across platforms and across versions of X.

I notice there aren't a great deal FSEM related tests in the source
other than one in jdk/test/java/awt/Fullscreen (which incidentally
appears to be missing a source file 'DisplayModeChanger.java').

I can see the benefit in providing a regression test for this but I'm
concerned that it's very dependent on the environment the tests are
being run on as to whether it'll get spotted at all.

Do you guys think it's a good idea to make a test for this or is it more
likely to be a pest to maintain?

Thanks

Dan Munckton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6636469_v2.diff
Type: text/x-patch
Size: 3709 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080116/ebe7d3f6/attachment.bin 

From lists at munckfish.net  Thu Jan 17 10:10:10 2008
From: lists at munckfish.net (Dan Munckton)
Date: Thu, 17 Jan 2008 18:10:10 +0000
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
	Exclusive	Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <1200497859.7514.14.camel@dylan>
References: <1197121416.14405.50.camel@dylan>  <475AF914.1090309@sun.com>
	<1197369278.7494.8.camel@dylan>  <1200497859.7514.14.camel@dylan>
Message-ID: <1200593410.6546.2.camel@dylan>

Hi

Please disregard all of my previous patches. I've just fixed a logic
error I made when checking the RANDR version. Now fixed, patch v3
attached.

Thanks

Dan Munckton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6636469_v3.diff
Type: text/x-patch
Size: 3738 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080117/503c97cb/attachment.bin 

From Dmitri.Trembovetski at Sun.COM  Thu Jan 17 10:40:00 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Thu, 17 Jan 2008 10:40:00 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH] 6636469: Java
 Fullscreen	Exclusive	Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <1200593410.6546.2.camel@dylan>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
	<1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan>
	<1200593410.6546.2.camel@dylan>
Message-ID: <478FA100.7070401@Sun.COM>


   Hi Dan,

   the patch looks fine.

   The only thing is that we typically try to avoid
   the use of goto if possible (like in this case since you
   don't win much by using it), so I'd suggest to
   just use
+    dlclose(pLibRandR);
+    return JNI_FALSE;
   instead of
+            goto return_false;

   Disabling fullscreen for multiscreen systems is ok with
   me.

   I agree that it'll be hard to create a robust automated
   test for this bug (and there's plenty of manual tests
   already, adding a new one won't be of much benefit),
   so I suggest we skip on regression test for this one.

   Regarding testing configurations: I have requested
   a sparc system with Nevada (so that it has the new X server),
   and also an x86/64 machine for linux/solaris. Once
   we have those set up we can proceed with the integration.

   Thanks,
     Dmitri

Dan Munckton wrote:
> Hi
> 
> Please disregard all of my previous patches. I've just fixed a logic
> error I made when checking the RANDR version. Now fixed, patch v3
> attached.
> 
> Thanks
> 
> Dan Munckton
> 

From cosine at freesoft.org  Mon Jan 21 12:42:49 2008
From: cosine at freesoft.org (Brent Baccala)
Date: Mon, 21 Jan 2008 15:42:49 -0500 (EST)
Subject: <AWT Dev> delivery of mouse events
Message-ID: <Pine.LNX.4.64.0801211537360.22713@bigsky.freesoft.org>

Hi -

Several years ago, while working with a tablet PC, I developed a patch
to AWT that delivered all mouse events to the application.  This was
for pen applications that wanted to track exactly how the user had
moved the pen, as opposed to the default behavior, which was to
discard extraneous mouse motion events.

I only did this for X Windows, and it wasn't done as an option - I
"selected" this feature according to which version of rt.jar I used.

Anyway, now that this is open source, is this a feature we'd like to
see added to AWT?  (I'm assuming it hasn't been done already)

If so, it should probably be a runtime option.  Any suggestions for
how to turn it on and off?



 					-bwb

 					Brent Baccala
 					cosine at freesoft.org

From Oleg.Sukhodolsky at Sun.COM  Tue Jan 22 01:02:09 2008
From: Oleg.Sukhodolsky at Sun.COM (Oleg Sukhodolsky)
Date: Tue, 22 Jan 2008 12:02:09 +0300
Subject: <AWT Dev> delivery of mouse events
In-Reply-To: <Pine.LNX.4.64.0801211537360.22713@bigsky.freesoft.org>
References: <Pine.LNX.4.64.0801211537360.22713@bigsky.freesoft.org>
Message-ID: <4795B111.6020008@sun.com>

Hi Brent,

could you please provide more accurate description of the feature you 
propose.

Thanks, Oleg.

Brent Baccala wrote:
> Hi -
> 
> Several years ago, while working with a tablet PC, I developed a patch
> to AWT that delivered all mouse events to the application.  This was
> for pen applications that wanted to track exactly how the user had
> moved the pen, as opposed to the default behavior, which was to
> discard extraneous mouse motion events.
> 
> I only did this for X Windows, and it wasn't done as an option - I
> "selected" this feature according to which version of rt.jar I used.
> 
> Anyway, now that this is open source, is this a feature we'd like to
> see added to AWT?  (I'm assuming it hasn't been done already)
> 
> If so, it should probably be a runtime option.  Any suggestions for
> how to turn it on and off?
> 
> 
> 
>                     -bwb
> 
>                     Brent Baccala
>                     cosine at freesoft.org

From cosine at freesoft.org  Tue Jan 22 10:19:58 2008
From: cosine at freesoft.org (Brent Baccala)
Date: Tue, 22 Jan 2008 13:19:58 -0500 (EST)
Subject: <AWT Dev> delivery of mouse events
In-Reply-To: <4795B111.6020008@sun.com>
References: <Pine.LNX.4.64.0801211537360.22713@bigsky.freesoft.org>
	<4795B111.6020008@sun.com>
Message-ID: <Pine.LNX.4.64.0801221318350.8496@bigsky.freesoft.org>

On Tue, 22 Jan 2008, Oleg Sukhodolsky wrote:

> Hi Brent,
>
> could you please provide more accurate description of the feature you 
> propose.
>
> Thanks, Oleg.

See http://www.freesoft.org/software/tablet-java

This page includes a link to the patch file, but like I said, I don't
think it's suitable as is, because it should be a selectable option.


 					-bwb

 					Brent Baccala
 					cosine at freesoft.org

From Oleg.Sukhodolsky at Sun.COM  Tue Jan 22 12:10:34 2008
From: Oleg.Sukhodolsky at Sun.COM (Oleg Sukhodolsky)
Date: Tue, 22 Jan 2008 23:10:34 +0300
Subject: <AWT Dev> delivery of mouse events
In-Reply-To: <Pine.LNX.4.64.0801221318350.8496@bigsky.freesoft.org>
References: <Pine.LNX.4.64.0801211537360.22713@bigsky.freesoft.org>
	<4795B111.6020008@sun.com>
	<Pine.LNX.4.64.0801221318350.8496@bigsky.freesoft.org>
Message-ID: <47964DBA.9070909@sun.com>

Brent Baccala ?????:
> On Tue, 22 Jan 2008, Oleg Sukhodolsky wrote:
> 
>> Hi Brent,
>>
>> could you please provide more accurate description of the feature you 
>> propose.
>>
>> Thanks, Oleg.
> 
> See http://www.freesoft.org/software/tablet-java
> 
> This page includes a link to the patch file, but like I said, I don't
> think it's suitable as is, because it should be a selectable option.

So, if I've got the changes wright, you would like to have an option to 
disable coalescing of mouse events.  Am I right?
IMHO it is a good idea and I would be happy to have this feature in our 
code.

Oleg.

From cosine at freesoft.org  Tue Jan 22 13:19:08 2008
From: cosine at freesoft.org (Brent Baccala)
Date: Tue, 22 Jan 2008 16:19:08 -0500 (EST)
Subject: <AWT Dev> delivery of mouse events
In-Reply-To: <47964DBA.9070909@sun.com>
References: <Pine.LNX.4.64.0801211537360.22713@bigsky.freesoft.org>
	<4795B111.6020008@sun.com>
	<Pine.LNX.4.64.0801221318350.8496@bigsky.freesoft.org>
	<47964DBA.9070909@sun.com>
Message-ID: <Pine.LNX.4.64.0801221607010.4916@bigsky.freesoft.org>

On Tue, 22 Jan 2008, Oleg Sukhodolsky wrote:

> So, if I've got the changes wright, you would like to have an option to 
> disable coalescing of mouse events.  Am I right?
> IMHO it is a good idea and I would be happy to have this feature in our code.

Yes, that's right.

I'm thinking about adding methods to Component, say
enableMouseEventCoalescing() and disableMouseEventCoalescing().

The default would be on, and it would then be up to the app to turn
this off on specific Components.

Not sure about Component nesting - I guess the simplest thing would be
to leave it up to the app to turn this off everywhere in a nested
chain of Components, but maybe that should happen automatically.

I don't know enough about how Java passes events between Components to
really say for sure.



 					-bwb

 					Brent Baccala
 					cosine at freesoft.org

From Oleg.Sukhodolsky at Sun.COM  Wed Jan 30 01:18:11 2008
From: Oleg.Sukhodolsky at Sun.COM (Oleg Sukhodolsky)
Date: Wed, 30 Jan 2008 12:18:11 +0300
Subject: <AWT Dev> delivery of mouse events
In-Reply-To: <Pine.LNX.4.64.0801221607010.4916@bigsky.freesoft.org>
References: <Pine.LNX.4.64.0801211537360.22713@bigsky.freesoft.org>
	<4795B111.6020008@sun.com>
	<Pine.LNX.4.64.0801221318350.8496@bigsky.freesoft.org>
	<47964DBA.9070909@sun.com>
	<Pine.LNX.4.64.0801221607010.4916@bigsky.freesoft.org>
Message-ID: <47A040D3.2080702@sun.com>

Hi Brent,

(sorry for the delay I had a "diving session" with another project)

Brent Baccala wrote:
> On Tue, 22 Jan 2008, Oleg Sukhodolsky wrote:
> 
>> So, if I've got the changes wright, you would like to have an option 
>> to disable coalescing of mouse events.  Am I right?
>> IMHO it is a good idea and I would be happy to have this feature in 
>> our code.
> 
> Yes, that's right.
> 
> I'm thinking about adding methods to Component, say
> enableMouseEventCoalescing() and disableMouseEventCoalescing().

it is interesting thing, but be aware that EventQueue performs some 
coalescing for PaitnEvents and for MouseEvents even if component doesn't 
coalesce them (see EventQueue.coalesceEvent()).
So, it will not be enough to add these methods to Componet.

> The default would be on, and it would then be up to the app to turn
> this off on specific Components.
> 
> Not sure about Component nesting - I guess the simplest thing would be
> to leave it up to the app to turn this off everywhere in a nested
> chain of Components, but maybe that should happen automatically.

I'd also leave this w/o changing, though someone may say that this is 
inconvenient for Swing (or other "strange" AWT-based libraries ;)

Regards, Oleg

> 
> I don't know enough about how Java passes events between Components to
> really say for sure.
> 
> 
> 
>                     -bwb
> 
>                     Brent Baccala
>                     cosine at freesoft.org