From mitulagrawal at ge.com  Mon Feb  1 00:31:48 2010
From: mitulagrawal at ge.com (meteor)
Date: Mon, 1 Feb 2010 00:31:48 -0800 (PST)
Subject: <AWT Dev> AWT event to XEvent
Message-ID: <27401020.post@talk.nabble.com>


Hi all,

Have been working on JAVA for quite some time and have been using the Nabble
forums quite frequently for any JAVA related issues. Although this time
around for the issue I have in hand am not sure if it is possible to solve
or not. Am actually working on an application for which part of its UI is
developed in C++ and uses Motif while part of the UI is developed in JAVA
which uses the standard AWT package. CORBA is used to communicate between
C++ and JAVA. Now in a particular case I am generating an AWT event on the
JAVA UI and need to capture that as an XEvent on the C++ side for some
reason. Both these UI have there individual event handlers i.e.
ActionListeners on the JAVA side and XEventLoop on the C++ side to handle
the events occuring on them individually. But in this particular case I want
to capture an AWT event by the XEventLoop on the C++ side.

Am sure this is a not a very peculiar case and there are instances where an
AWT Event needs to be converted to an native event. Have come across a
couple of ideas for doing the same:

1) Re-Design my XEventLoop to listen/process the AWT events as well and
register the Java application as an observable for the XEventLoop. The
problem with this approach is that am not sure if that is possible (dont
have so much experience in working with XEvents) and even if it is possible
this will require re-designing the entire XEvent mechanism which I hate to
do!

2) Somehow convert the AWT event to the native XEVent since an AWT event is
generated by XEvent so I believe converting it back to an XEvent should be
possible. Again am not sure if this is the right thing to do since I may
loose some information in doing so and am also not aware of any direct way
of doing this.

This task seems to be very challenging and have spent a lot of time on this
but am not able to come up with a concrete solution. Hope to get some help
from you all.

Any help in this regard is appreciated.

Regards
Mitul
-- 
View this message in context: http://old.nabble.com/AWT-event-to-XEvent-tp27401020p27401020.html
Sent from the OpenJDK AWT Development mailing list archive at Nabble.com.



From Artem.Ananiev at Sun.COM  Mon Feb  1 02:16:59 2010
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Mon, 01 Feb 2010 13:16:59 +0300
Subject: <AWT Dev> AWT event to XEvent
In-Reply-To: <27401020.post@talk.nabble.com>
References: <27401020.post@talk.nabble.com>
Message-ID: <4B66AA1B.3030002@sun.com>

Hi, Mitul,

I'm not sure I've got what you're writing about... See particular 
questions below.

On 2/1/2010 11:31 AM, meteor wrote:
>
> Hi all,
>
> Have been working on JAVA for quite some time and have been using the Nabble
> forums quite frequently for any JAVA related issues. Although this time
> around for the issue I have in hand am not sure if it is possible to solve
> or not. Am actually working on an application for which part of its UI is
> developed in C++ and uses Motif while part of the UI is developed in JAVA
> which uses the standard AWT package. CORBA is used to communicate between
> C++ and JAVA. Now in a particular case I am generating an AWT event on the
> JAVA UI and need to capture that as an XEvent on the C++ side for some
> reason. Both these UI have there individual event handlers i.e.
> ActionListeners on the JAVA side and XEventLoop on the C++ side to handle
> the events occuring on them individually. But in this particular case I want
> to capture an AWT event by the XEventLoop on the C++ side.

I hope you don't rely on Motif's implementation of AWT and only use 
Motif in your code. MToolkit (Motif-based AWT toolkit) is almost gone 
these days.

> Am sure this is a not a very peculiar case and there are instances where an
> AWT Event needs to be converted to an native event. Have come across a
> couple of ideas for doing the same:
>
> 1) Re-Design my XEventLoop to listen/process the AWT events as well and
> register the Java application as an observable for the XEventLoop. The
> problem with this approach is that am not sure if that is possible (dont
> have so much experience in working with XEvents) and even if it is possible
> this will require re-designing the entire XEvent mechanism which I hate to
> do!

Do you mean your C++ event loop to process both application XEvents and 
AWT XEvents and then forward the latter ones to AWT? This is currently 
unsupported, and I doubt it will ever be.

> 2) Somehow convert the AWT event to the native XEVent since an AWT event is
> generated by XEvent so I believe converting it back to an XEvent should be
> possible. Again am not sure if this is the right thing to do since I may
> loose some information in doing so and am also not aware of any direct way
> of doing this.

Obviously, most of AWT events are caused by native XEvents. However, you 
must realize that the conversion is very deep AWT internals, and the 
things may change at any moment in the future.

The question is: why do you need to process AWT events (converted back 
to XEvents) in your applications? Could you track the events at Java 
level and forward them to your application (using CORBA)?

Thanks,

Artem

> This task seems to be very challenging and have spent a lot of time on this
> but am not able to come up with a concrete solution. Hope to get some help
> from you all.
>
> Any help in this regard is appreciated.
>
> Regards
> Mitul


From Anthony.Petrov at Sun.COM  Mon Feb  1 07:19:36 2010
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Mon, 01 Feb 2010 18:19:36 +0300
Subject: <AWT Dev> Question about GtkLnF implementation
In-Reply-To: <194f62551001300847p3dc450c1yc1610dead2c94222@mail.gmail.com>
References: <194f62551001300743u40c9b112y1766eed6369a7c2f@mail.gmail.com>
	<9e89675b1001300813j7e993449x23b5231b9c0c0648@mail.gmail.com>
	<194f62551001300847p3dc450c1yc1610dead2c94222@mail.gmail.com>
Message-ID: <4B66F108.6010609@sun.com>

Hi Clemens, Damjan,

[ also copying the swing-dev@ list ]

AFAIK, there currently nobody working on such an enhancement to the 
Swing GTK L&F implementation. This L&F is by far not the fastest one out 
there, so any improvement is very welcome.

If either of you could help with developing a fix, that would be very 
much appreciated.

--
best regards,
Anthony

On 1/30/2010 7:47 PM Clemens Eisserer wrote:
> Hi Damjan,
> 
>> The number of roundtrips isn't such a problem, the number is pixels
>> is. 2 NxM pixmaps have the same number of pixels in total as an Nx2M
>> or 2NxM pixmap, so little time is saved.
> 
> Sure the amount of data stays the same - however for (most modern)
> video drivers which place their pixmaps in vram it does make a
> difference.The whole situation is quite ugly :-/
> 
>> Anyway, when last I heard the solution to this was to subclass GDK
>> drawing functions so they draw with the alpha channel in the first
>> place, instead of the double drawing without alpha and then mixing
>> pixmaps to recover it. Anyone working on this?
> 
> Hmm, I guess the best thing would be to get GTK's broken theme API
> right, to draw on a cairo-context instead of a GdkDrawalbe.
> 
> I submited patches for rfc some time ago, but nobody really looked at
> it. To me it seems GTK is quite dead.
> When I brought that topic up again, it was mentioned that the work is
> obsolete because GTK+3 will have an all new-any-shiny theming API
> which will be perfect in any aspect.
> 
> However they are talking about GTK+3 for about 2,5 years now, with no outcome.
> 
> Hmm, I am starting to get personal again ;)
> 
> - Clemens


From damjan.jov at gmail.com  Mon Feb  1 07:28:13 2010
From: damjan.jov at gmail.com (Damjan Jovanovic)
Date: Mon, 1 Feb 2010 17:28:13 +0200
Subject: <AWT Dev> Question about GtkLnF implementation
In-Reply-To: <4B66F108.6010609@sun.com>
References: <194f62551001300743u40c9b112y1766eed6369a7c2f@mail.gmail.com>
	<9e89675b1001300813j7e993449x23b5231b9c0c0648@mail.gmail.com>
	<194f62551001300847p3dc450c1yc1610dead2c94222@mail.gmail.com>
	<4B66F108.6010609@sun.com>
Message-ID: <9e89675b1002010728p6908b8aak402a7fa997d02916@mail.gmail.com>

Hi Anthony, Clemens, others

There's an interesting comment, quoted below, in the evaluation of
http://bugs.sun.com/view_bug.do?bug_id=6286734

---BEGIN QUOTE---
I have an idea of impoving overall GTK LAF performance by implementing
own gdk backend which would draw gtk widgets directly to
X11SurfaceData backing buffer.
It improves GTK LAF performance dramatically especially on remote
hosts (up to 20 times).
Together with some minor changes it would be a better solution for this "bug"
Uncommit it from Mustang becasue I'm getting late with this feature.
Posted Date : 2006-03-27 13:03:58.0
---END QUOTE---

Who wrote this (I suspect Kirill Kirichenko for some reason) and is
this code still around? It would really help to see it.

Thank you
Damjan


On Mon, Feb 1, 2010 at 5:19 PM, Anthony Petrov <Anthony.Petrov at sun.com> wrote:
> Hi Clemens, Damjan,
>
> [ also copying the swing-dev@ list ]
>
> AFAIK, there currently nobody working on such an enhancement to the Swing
> GTK L&F implementation. This L&F is by far not the fastest one out there, so
> any improvement is very welcome.
>
> If either of you could help with developing a fix, that would be very much
> appreciated.
>
> --
> best regards,
> Anthony
>
> On 1/30/2010 7:47 PM Clemens Eisserer wrote:
>>
>> Hi Damjan,
>>
>>> The number of roundtrips isn't such a problem, the number is pixels
>>> is. 2 NxM pixmaps have the same number of pixels in total as an Nx2M
>>> or 2NxM pixmap, so little time is saved.
>>
>> Sure the amount of data stays the same - however for (most modern)
>> video drivers which place their pixmaps in vram it does make a
>> difference.The whole situation is quite ugly :-/
>>
>>> Anyway, when last I heard the solution to this was to subclass GDK
>>> drawing functions so they draw with the alpha channel in the first
>>> place, instead of the double drawing without alpha and then mixing
>>> pixmaps to recover it. Anyone working on this?
>>
>> Hmm, I guess the best thing would be to get GTK's broken theme API
>> right, to draw on a cairo-context instead of a GdkDrawalbe.
>>
>> I submited patches for rfc some time ago, but nobody really looked at
>> it. To me it seems GTK is quite dead.
>> When I brought that topic up again, it was mentioned that the work is
>> obsolete because GTK+3 will have an all new-any-shiny theming API
>> which will be perfect in any aspect.
>>
>> However they are talking about GTK+3 for about 2,5 years now, with no
>> outcome.
>>
>> Hmm, I am starting to get personal again ;)
>>
>> - Clemens
>


From damjan.jov at gmail.com  Mon Feb  1 07:44:47 2010
From: damjan.jov at gmail.com (Damjan Jovanovic)
Date: Mon, 1 Feb 2010 17:44:47 +0200
Subject: <AWT Dev> Patch feedback?
Message-ID: <9e89675b1002010744y1b0c3053vbb10a1e5392a6180@mail.gmail.com>

Hi

Can I please get some feedback and maybe a sponsor for
https://bugs.openjdk.java.net/show_bug.cgi?id=100124

I've been waiting for the past 6 weeks. I need to at least know
whether it's worth continuing work on this patch.

Thank you
Damjan


From c.cerbo at gmail.com  Mon Feb  1 13:31:12 2010
From: c.cerbo at gmail.com (Costantino Cerbo)
Date: Mon, 1 Feb 2010 22:31:12 +0100
Subject: <AWT Dev> swing-dev Digest, Vol 34, Issue 1
In-Reply-To: <mailman.9.1265054401.3340.swing-dev@openjdk.java.net>
References: <mailman.9.1265054401.3340.swing-dev@openjdk.java.net>
Message-ID: <6fbbec31002011331s6522d783o9aaeabac8977ad17@mail.gmail.com>

> Date: Mon, 01 Feb 2010 18:19:36 +0300
> From: Anthony Petrov <Anthony.Petrov at Sun.COM>
> AFAIK, there currently nobody working on such an enhancement to the
> Swing GTK L&F implementation. This L&F is by far not the fastest one out
> there, so any improvement is very welcome.

If Oracle will invest more money on Java and Solaris, as Larry Ellison
said, they should invest also on the GTK L&F!
Isn't Gnome the default GUI Environment on the (now) Oracle Operating
System! ;-)

By the way, did you have the time to take a look to my last patch (Bug
6913179) and experiment a little bit to solve the problem with the
EDT?
I spent also yesterday some time but without success :-(

Thank you very much,
Costantino


From linuxhippy at gmail.com  Tue Feb  2 03:47:46 2010
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 2 Feb 2010 06:47:46 -0500
Subject: <AWT Dev> Question about GtkLnF implementation
In-Reply-To: <9e89675b1002010728p6908b8aak402a7fa997d02916@mail.gmail.com>
References: <194f62551001300743u40c9b112y1766eed6369a7c2f@mail.gmail.com>
	<9e89675b1001300813j7e993449x23b5231b9c0c0648@mail.gmail.com>
	<194f62551001300847p3dc450c1yc1610dead2c94222@mail.gmail.com>
	<4B66F108.6010609@sun.com>
	<9e89675b1002010728p6908b8aak402a7fa997d02916@mail.gmail.com>
Message-ID: <194f62551002020347l11fa6233vdd8a41dfe3a2bbaf@mail.gmail.com>

Hi all,

> Who wrote this (I suspect Kirill Kirichenko for some reason) and is
> this code still around? It would really help to see it.
Wow, if the code is still arround it would be of course the best solution.
I am curious how all the rendering routines were implemented.

For now I am trying to push some changes into GTK to make their theme
API more friendly for non-gtk consumers (like Java, FireFox).
It would also solve the problem, however it would take time for the
new GTK to spread arround and themes to be adopted.

-  Clemens


From Anthony.Petrov at Sun.COM  Tue Feb  2 07:32:09 2010
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Tue, 02 Feb 2010 18:32:09 +0300
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: first patch
In-Reply-To: <6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<4B583BD5.9080704@sun.com>
	<6fbbec31001211508v780986a7n936a8d20d182a3a9@mail.gmail.com>
	<4B59944C.2020903@sun.com>
	<6fbbec31001241126o62bcccf8u813f76902b6a8cd1@mail.gmail.com>
	<4B5D9CFA.5010502@sun.com>
	<6fbbec31001251417o2a49f02fr1fc2047993787e31@mail.gmail.com>
	<4B5EFD4F.6030104@sun.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
Message-ID: <4B684579.3070105@sun.com>

Hi Costantino,

Thanks for the patch. The current webrev is at:

http://cr.openjdk.java.net/~anthony/7-43-GTKFileDialog-6913179.2/

Peter and I are currently discussing a possible solution for the 
modality issue. When we come up with an idea, we'll let you know.

--
best regards,
Anthony


On 01/29/2010 02:28 AM, Costantino Cerbo wrote:
> Hallo Peter, Hello Anthony,
> 
> in the attached patch I take care of all the last Peter's comment.
> 
> Unfortunately the problem with the EDT is still there.
> 
> 2010/1/28 Anthony Petrov <Anthony.Petrov at sun.com>:
>> What do you mean by "doesn't start"? Doesn't gtk_main() print out any
>> diagnostic output to stderr? Or does it get invoked at all?
> Unfortunately no diagnostic output is printed to stderr... try yourself...
> I've also init the GLib thread system and call gdk_threads_enter() and
> gdk_threads_leave() but the problem remains.
> 
> I've no idea how to solve this problem... I've tried also with
> SwingUtilities#invokeLater and SwingWorker...
> I ask again for your help: It would be very nice if some of you can
> address his mind to the solution of this remaining issue... otherwise
> all the work done until now goes lost.
> 
> Thanks a lot!
> Costantino


From c.cerbo at gmail.com  Tue Feb  2 08:11:44 2010
From: c.cerbo at gmail.com (Costantino Cerbo)
Date: Tue, 2 Feb 2010 17:11:44 +0100
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: first patch
In-Reply-To: <4B684579.3070105@sun.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<4B59944C.2020903@sun.com>
	<6fbbec31001241126o62bcccf8u813f76902b6a8cd1@mail.gmail.com>
	<4B5D9CFA.5010502@sun.com>
	<6fbbec31001251417o2a49f02fr1fc2047993787e31@mail.gmail.com>
	<4B5EFD4F.6030104@sun.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
	<4B684579.3070105@sun.com>
Message-ID: <6fbbec31002020811x73149265he2c5e97534a61ba7@mail.gmail.com>

2010/2/2 Anthony Petrov <Anthony.Petrov at sun.com>:
> Peter and I are currently discussing a possible solution for the modality
> issue. When we come up with an idea, we'll let you know.
Thanks a lot!

Cheers,
Costantino


From Denis.Fokin at Sun.COM  Wed Feb  3 07:22:31 2010
From: Denis.Fokin at Sun.COM (Denis S. Fokin)
Date: Wed, 03 Feb 2010 18:22:31 +0300
Subject: <AWT Dev> Patch feedback?
In-Reply-To: <9e89675b1002010744y1b0c3053vbb10a1e5392a6180@mail.gmail.com>
References: <9e89675b1002010744y1b0c3053vbb10a1e5392a6180@mail.gmail.com>
Message-ID: <4B6994B7.5000501@sun.com>

Hi Damjan,

Could you provide more details...

 > 8. Needs jtreg tests.

It would be great to look at a sample application, that you used to 
write your prototype :-)
Could you attach it?

 > It's been tested with Nautilus and File Roller on Linux,
 > Windows Explorer and Windows Mail on Windows. All work.

Could you give us more details about scenarios that you have used for 
the testing?

Thank you,
      Denis.

Damjan Jovanovic wrote:
> Hi
>
> Can I please get some feedback and maybe a sponsor for
> https://bugs.openjdk.java.net/show_bug.cgi?id=100124
>
> I've been waiting for the past 6 weeks. I need to at least know
> whether it's worth continuing work on this patch.
>
> Thank you
> Damjan



From Denis.Fokin at Sun.COM  Wed Feb  3 07:52:50 2010
From: Denis.Fokin at Sun.COM (Denis S. Fokin)
Date: Wed, 03 Feb 2010 18:52:50 +0300
Subject: <AWT Dev> Patch feedback?
In-Reply-To: <4B6994B7.5000501@sun.com>
References: <9e89675b1002010744y1b0c3053vbb10a1e5392a6180@mail.gmail.com>
	<4B6994B7.5000501@sun.com>
Message-ID: <4B699BD2.9020208@sun.com>

Hi Damjan,

as for the Windows-specific part, as I know, the similar functionality 
has been implemented in the next changeset

http://hg.openjdk.java.net/jdk7/awt/jdk/rev/fd5bf5955e37

The implementation has not been promoted yet.

Thank you,
    Denis.

Denis S. Fokin wrote:
> Hi Damjan,
>
> Could you provide more details...
>
> > 8. Needs jtreg tests.
>
> It would be great to look at a sample application, that you used to 
> write your prototype :-)
> Could you attach it?
>
> > It's been tested with Nautilus and File Roller on Linux,
> > Windows Explorer and Windows Mail on Windows. All work.
>
> Could you give us more details about scenarios that you have used for 
> the testing?
>
> Thank you,
>      Denis.
>
> Damjan Jovanovic wrote:
>> Hi
>>
>> Can I please get some feedback and maybe a sponsor for
>> https://bugs.openjdk.java.net/show_bug.cgi?id=100124
>>
>> I've been waiting for the past 6 weeks. I need to at least know
>> whether it's worth continuing work on this patch.
>>
>> Thank you
>> Damjan
>



From damjan.jov at gmail.com  Wed Feb  3 10:20:58 2010
From: damjan.jov at gmail.com (Damjan Jovanovic)
Date: Wed, 3 Feb 2010 20:20:58 +0200
Subject: <AWT Dev> Patch feedback?
In-Reply-To: <4B6994B7.5000501@sun.com>
References: <9e89675b1002010744y1b0c3053vbb10a1e5392a6180@mail.gmail.com>
	<4B6994B7.5000501@sun.com>
Message-ID: <9e89675b1002031020x7aaa12e5rccf012c29b32db7@mail.gmail.com>

On Wed, Feb 3, 2010 at 5:22 PM, Denis S. Fokin <Denis.Fokin at sun.com> wrote:
> Hi Damjan,

Hi Denis

> Could you provide more details...
>
>> 8. Needs jtreg tests.
>
> It would be great to look at a sample application, that you used to write
> your prototype :-)
> Could you attach it?

Attached. One is to test drops, the other drags. They're quite hacked :-)

>> It's been tested with Nautilus and File Roller on Linux,
>> Windows Explorer and Windows Mail on Windows. All work.
>
> Could you give us more details about scenarios that you have used for the
> testing?

Drag file from Java, drop to Nautilus
Drag file from an archive (eg. ZIP file) opened in File Roller, drop to Java
Drag file from Java, drop to Windows Explorer
Drag email or attachment from Windows Mail, drop to Java
And finally: drag from Java, drop to Java

All tests need the patch applied to compile and run.

> Thank you,
> ? ? Denis.

Thank you
Damjan

> Damjan Jovanovic wrote:
>>
>> Hi
>>
>> Can I please get some feedback and maybe a sponsor for
>> https://bugs.openjdk.java.net/show_bug.cgi?id=100124
>>
>> I've been waiting for the past 6 weeks. I need to at least know
>> whether it's worth continuing work on this patch.
>>
>> Thank you
>> Damjan
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Drop.java
Type: text/x-java
Size: 1597 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20100203/dd48578e/Drop.java 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BasicDnD.java
Type: text/x-java
Size: 13210 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20100203/dd48578e/BasicDnD.java 

From damjan.jov at gmail.com  Wed Feb  3 10:52:00 2010
From: damjan.jov at gmail.com (Damjan Jovanovic)
Date: Wed, 3 Feb 2010 20:52:00 +0200
Subject: <AWT Dev> Patch feedback?
In-Reply-To: <4B699BD2.9020208@sun.com>
References: <9e89675b1002010744y1b0c3053vbb10a1e5392a6180@mail.gmail.com>
	<4B6994B7.5000501@sun.com> <4B699BD2.9020208@sun.com>
Message-ID: <9e89675b1002031052v1babc67eic213bd54125b71c8@mail.gmail.com>

On Wed, Feb 3, 2010 at 5:52 PM, Denis S. Fokin <Denis.Fokin at sun.com> wrote:
> Hi Damjan,

Hi Denis

> as for the Windows-specific part, as I know, the similar functionality has
> been implemented in the next changeset
>
> http://hg.openjdk.java.net/jdk7/awt/jdk/rev/fd5bf5955e37

IMO it's quite dangerous to implicitly convert FILEDESCRIPTOR +
FILECONTENTS to temporary files and present them to the caller. If
someone drags a 100MB file from an FTP server or a directory with
hundreds of files into Java, you will block the EDT for a long time
while the files copy. Also AWT allows you to request file contents
many times before the drop, and you could end up writing many copies
out, taking time and wasting disk space.

The different API used in my patch can be asynchronous relative to the
EDT, and only allows 1 transfer attempt, thus avoiding all those
problems where possible. It also happens to be usable on *nix's X
Direct Save and (I suspect) MacOS's promise data flavors, where the
drop target doesn't get the file contents at all, it just tells the
drag source where to write out the file(s) and the drag source writes
them whenever, however, and whatever it likes - something that cannot
possibly work with javaFileListFlavor.

> The implementation has not been promoted yet.

That patch for dragging with an image looks impressive, nice work!

You might also want to look at a short patch I made to support
changing the drag cursor:
https://bugs.openjdk.java.net/show_bug.cgi?id=100121

> Thank you,
> ? Denis.

Thank you
Damjan

> Denis S. Fokin wrote:
>>
>> Hi Damjan,
>>
>> Could you provide more details...
>>
>> > 8. Needs jtreg tests.
>>
>> It would be great to look at a sample application, that you used to write
>> your prototype :-)
>> Could you attach it?
>>
>> > It's been tested with Nautilus and File Roller on Linux,
>> > Windows Explorer and Windows Mail on Windows. All work.
>>
>> Could you give us more details about scenarios that you have used for the
>> testing?
>>
>> Thank you,
>> ? ? Denis.
>>
>> Damjan Jovanovic wrote:
>>>
>>> Hi
>>>
>>> Can I please get some feedback and maybe a sponsor for
>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100124
>>>
>>> I've been waiting for the past 6 weeks. I need to at least know
>>> whether it's worth continuing work on this patch.
>>>
>>> Thank you
>>> Damjan
>>
>
>


From Artem.Ananiev at Sun.COM  Fri Feb  5 06:36:54 2010
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Fri, 05 Feb 2010 17:36:54 +0300
Subject: <AWT Dev> <Swing Dev> review request for 6899434: Add affine
 transform support to JLayer
In-Reply-To: <7DA864E83CAE4D4D9EBAC77237DEF6B9@DB35TT0J>
References: <7DA864E83CAE4D4D9EBAC77237DEF6B9@DB35TT0J>
Message-ID: <4B6C2D06.7030405@sun.com>

Hi, Piet,

I haven't looked through the entire webrev and inspected mostly an AWT 
part of the fix. A question is whether it's possible to get rid of the 
new "conversionShift" field in Container, to make transformations 
support really stateless?

Another option to consider is to make some of the existing methods (e.g. 
getMouseEventTargetImpl()) public instead of introducing new ones.

Thanks,

Artem

On 1/28/2010 8:21 PM, Piet Blok wrote:
> Hello all,
>
> review request for 6899434: Add affine transform support to JLayer
>
> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>
> The patch covers all the requested functionality. It is concentrated in
> JLayer class, keeping in mind to affect the library as little as possible.
>
> 1) A setter and getter for the transform in JLayer
>
> 2) The paint method in JLayer has been adapted to use the transform
>
> 3) RepaintManager has been adapted to propagate repaint requests from
> the view or any of its children to the top level JLayer and have the
> dirty region transformed.
>
> 4) java.awt.Container and java.awt.LightweightDispatcher (both in the
> same source) have been adapted to redispatch MouseEvents to the intended
> target component. The lookup for the component that provides a custon
> cursor has also been adapted.
>
> 5) To enable Container to do necessary reculculations, a protected
> method has been introduced that will be overridden by JLayer:
> protected Point getConvertedPoint(Point point).
> (If someone can suggest a better name for this method I'm glad to hear)
>
> 6) A package private method in SwingUtilities has been added that helps
> JPopupMenu and ToolTipManager to find the correct popup location.
> JPopupMenu and ToolTipManager have been changed to use this new method
> in their calculations.
>
> 7) Two jtreg tests have been added.
>
> Looking forward for comments.
>
> Thanks,
> Piet
>
>
>


From Denis.Fokin at Sun.COM  Fri Feb  5 08:06:04 2010
From: Denis.Fokin at Sun.COM (Denis S. Fokin)
Date: Fri, 05 Feb 2010 19:06:04 +0300
Subject: <AWT Dev> Patch feedback?
In-Reply-To: <9e89675b1002031052v1babc67eic213bd54125b71c8@mail.gmail.com>
References: <9e89675b1002010744y1b0c3053vbb10a1e5392a6180@mail.gmail.com>
	<4B6994B7.5000501@sun.com> <4B699BD2.9020208@sun.com>
	<9e89675b1002031052v1babc67eic213bd54125b71c8@mail.gmail.com>
Message-ID: <4B6C41EC.1080306@sun.com>

Hi Damjan,

thank you for your comments. I asked Alexey to look at this.

Thank you,
   Denis.

Denis.

Damjan Jovanovic wrote:
> On Wed, Feb 3, 2010 at 5:52 PM, Denis S. Fokin <Denis.Fokin at sun.com> wrote:
>   
>> Hi Damjan,
>>     
>
> Hi Denis
>
>   
>> as for the Windows-specific part, as I know, the similar functionality has
>> been implemented in the next changeset
>>
>> http://hg.openjdk.java.net/jdk7/awt/jdk/rev/fd5bf5955e37
>>     
>
> IMO it's quite dangerous to implicitly convert FILEDESCRIPTOR +
> FILECONTENTS to temporary files and present them to the caller. If
> someone drags a 100MB file from an FTP server or a directory with
> hundreds of files into Java, you will block the EDT for a long time
> while the files copy. Also AWT allows you to request file contents
> many times before the drop, and you could end up writing many copies
> out, taking time and wasting disk space.
>
> The different API used in my patch can be asynchronous relative to the
> EDT, and only allows 1 transfer attempt, thus avoiding all those
> problems where possible. It also happens to be usable on *nix's X
> Direct Save and (I suspect) MacOS's promise data flavors, where the
> drop target doesn't get the file contents at all, it just tells the
> drag source where to write out the file(s) and the drag source writes
> them whenever, however, and whatever it likes - something that cannot
> possibly work with javaFileListFlavor.
>
>   
>> The implementation has not been promoted yet.
>>     
>
> That patch for dragging with an image looks impressive, nice work!
>
> You might also want to look at a short patch I made to support
> changing the drag cursor:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100121
>
>   
>> Thank you,
>>   Denis.
>>     
>
> Thank you
> Damjan
>
>   
>> Denis S. Fokin wrote:
>>     
>>> Hi Damjan,
>>>
>>> Could you provide more details...
>>>
>>>       
>>>> 8. Needs jtreg tests.
>>>>         
>>> It would be great to look at a sample application, that you used to write
>>> your prototype :-)
>>> Could you attach it?
>>>
>>>       
>>>> It's been tested with Nautilus and File Roller on Linux,
>>>> Windows Explorer and Windows Mail on Windows. All work.
>>>>         
>>> Could you give us more details about scenarios that you have used for the
>>> testing?
>>>
>>> Thank you,
>>>     Denis.
>>>
>>> Damjan Jovanovic wrote:
>>>       
>>>> Hi
>>>>
>>>> Can I please get some feedback and maybe a sponsor for
>>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100124
>>>>
>>>> I've been waiting for the past 6 weeks. I need to at least know
>>>> whether it's worth continuing work on this patch.
>>>>
>>>> Thank you
>>>> Damjan
>>>>         
>>     



From Denis.Fokin at Sun.COM  Fri Feb  5 08:08:59 2010
From: Denis.Fokin at Sun.COM (Denis S. Fokin)
Date: Fri, 05 Feb 2010 19:08:59 +0300
Subject: <AWT Dev> Patch feedback?
In-Reply-To: <9e89675b1002031020x7aaa12e5rccf012c29b32db7@mail.gmail.com>
References: <9e89675b1002010744y1b0c3053vbb10a1e5392a6180@mail.gmail.com>
	<4B6994B7.5000501@sun.com>
	<9e89675b1002031020x7aaa12e5rccf012c29b32db7@mail.gmail.com>
Message-ID: <4B6C429B.6080100@sun.com>

Hi Damjan,

thank you, I will look at this till COB Monday.

Denis.

Damjan Jovanovic wrote:
> On Wed, Feb 3, 2010 at 5:22 PM, Denis S. Fokin <Denis.Fokin at sun.com> wrote:
>   
>> Hi Damjan,
>>     
>
> Hi Denis
>
>   
>> Could you provide more details...
>>
>>     
>>> 8. Needs jtreg tests.
>>>       
>> It would be great to look at a sample application, that you used to write
>> your prototype :-)
>> Could you attach it?
>>     
>
> Attached. One is to test drops, the other drags. They're quite hacked :-)
>
>   
>>> It's been tested with Nautilus and File Roller on Linux,
>>> Windows Explorer and Windows Mail on Windows. All work.
>>>       
>> Could you give us more details about scenarios that you have used for the
>> testing?
>>     
>
> Drag file from Java, drop to Nautilus
> Drag file from an archive (eg. ZIP file) opened in File Roller, drop to Java
> Drag file from Java, drop to Windows Explorer
> Drag email or attachment from Windows Mail, drop to Java
> And finally: drag from Java, drop to Java
>
> All tests need the patch applied to compile and run.
>
>   
>> Thank you,
>>     Denis.
>>     
>
> Thank you
> Damjan
>
>   
>> Damjan Jovanovic wrote:
>>     
>>> Hi
>>>
>>> Can I please get some feedback and maybe a sponsor for
>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100124
>>>
>>> I've been waiting for the past 6 weeks. I need to at least know
>>> whether it's worth continuing work on this patch.
>>>
>>> Thank you
>>> Damjan
>>>       
>>     



From pbhome at ziggo.nl  Mon Feb  8 03:27:32 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Mon, 8 Feb 2010 12:27:32 +0100
Subject: <AWT Dev> Fw: <Swing Dev> review request for 6899434: Add affine
	transformsupport to JLayer
Message-ID: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>

Hi Artem,

To demonstrate the implemention via the AWTAccessor pattern, I created a 
version 2 implementation:

http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/

This implementation is much cleaner than the original one.

Looking forward for yout comments,
Piet



> Hi Artem,
>
> The problem with making existing methods public is that it solves only 
> half of the problem at hand:
>
> 1) Locate the correct component (can be solved)
>
> 2) Recalculating the mouse point from rendered space to layout space is 
> not solved because the locating methods only return a component. 
> Recalculation is needed to correctly set a mouse point in the new events, 
> relative to the target component.
>
> In my proposed implementation the shift caused by transformations is 
> stored when looking up the target (for future use: creating new events 
> from the original event). This future is quite an immediate future because 
> creating a new event from an existing event will always be directly 
> preceded by looking up that target event.
>
> An alternative would be to again iterate through the hierarchy and do the 
> transformations. This must be done in LightweightDispatcher in the 
> methods:
>
> 1) retargetMouseEvent (an inverse transform is needed, so the new 
> Container method getConvertedPoint can be used)
>
> 2) eventDispatched. Unfortunately here an ordinary transform is needed, so 
> a second new Container method must be defined that does an ordinary 
> transform.
>
> But.... a completely different approach is also possible. I did this in an 
> earlier version, so I know that it works. With this approach no new public 
> or protected methods need to be introduced and no existing methods need to 
> go public or protected. All remains private or package private.
>
> That approach is as follows:
>
> 1) Define the AffineTransform as a private field in Component.
>
> 2) Use the AWTAccessor pattern to make the transform available in 
> Container and LightweightDispatcher and in swing classes.
>
> 3) In Container and LightweightDispatcher, get the transform and do 
> transformations when needed.
>
> In my opinion, the solution with the AWTAccessor pattern is the cleanest. 
> However, it requires Component and AWTAccessor to be touched.
>
> Please let me know what you think.
>
> Piet
>
>
>
>> Hi, Piet,
>>
>> I haven't looked through the entire webrev and inspected mostly an AWT 
>> part of the fix. A question is whether it's possible to get rid of the 
>> new "conversionShift" field in Container, to make transformations support 
>> really stateless?
>>
>> Another option to consider is to make some of the existing methods (e.g. 
>> getMouseEventTargetImpl()) public instead of introducing new ones.
>>
>> Thanks,
>>
>> Artem
>>
>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>> Hello all,
>>>
>>> review request for 6899434: Add affine transform support to JLayer
>>>
>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>
>>> The patch covers all the requested functionality. It is concentrated in
>>> JLayer class, keeping in mind to affect the library as little as 
>>> possible.
>>>
>>> 1) A setter and getter for the transform in JLayer
>>>
>>> 2) The paint method in JLayer has been adapted to use the transform
>>>
>>> 3) RepaintManager has been adapted to propagate repaint requests from
>>> the view or any of its children to the top level JLayer and have the
>>> dirty region transformed.
>>>
>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both in the
>>> same source) have been adapted to redispatch MouseEvents to the intended
>>> target component. The lookup for the component that provides a custon
>>> cursor has also been adapted.
>>>
>>> 5) To enable Container to do necessary reculculations, a protected
>>> method has been introduced that will be overridden by JLayer:
>>> protected Point getConvertedPoint(Point point).
>>> (If someone can suggest a better name for this method I'm glad to hear)
>>>
>>> 6) A package private method in SwingUtilities has been added that helps
>>> JPopupMenu and ToolTipManager to find the correct popup location.
>>> JPopupMenu and ToolTipManager have been changed to use this new method
>>> in their calculations.
>>>
>>> 7) Two jtreg tests have been added.
>>>
>>> Looking forward for comments.
>>>
>>> Thanks,
>>> Piet
>>>
>>>
>>>
>>
>
>
> 




From yuri.nesterenko at sun.com  Mon Feb  8 06:07:57 2010
From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com)
Date: Mon, 08 Feb 2010 14:07:57 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6882912: Strange behaviours when typing
	@ or '
Message-ID: <20100208140849.2B2D14171F@hg.openjdk.java.net>

Changeset: 66c193082586
Author:    yan
Date:      2010-02-08 17:02 +0300
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/66c193082586

6882912: Strange behaviours when typing @ or '
Summary: Eliminate stray lines without a proper unicode->regularKeyID pair (e.g. as there is no "arrow left" unicode, should be no pair)
Reviewed-by: rupashka

! src/share/classes/sun/awt/ExtendedKeyCodes.java



From Denis.Fokin at Sun.COM  Mon Feb  8 09:38:00 2010
From: Denis.Fokin at Sun.COM (Denis S. Fokin)
Date: Mon, 08 Feb 2010 20:38:00 +0300
Subject: <AWT Dev> Patch feedback?
In-Reply-To: <9e89675b1002031020x7aaa12e5rccf012c29b32db7@mail.gmail.com>
References: <9e89675b1002010744y1b0c3053vbb10a1e5392a6180@mail.gmail.com>
	<4B6994B7.5000501@sun.com>
	<9e89675b1002031020x7aaa12e5rccf012c29b32db7@mail.gmail.com>
Message-ID: <4B704BF8.6010300@sun.com>

Hi Damjan,

Thank you for the samples.

I tried to execute them.

I executed Drop and it did not work for me.

As I understand the class requires an URI as a parameter to store a 
dropped file in the location.

I tired to pass '.' and 'file://....' as parameters but the transfered 
file did not  appear at the specified locations.

Form the other hand, the drop of a file from ubuntu GNOME desktop was 
refused (I am not sure whether it is a nautilus window) and from ubuntu 
GNOME nautilus window the drop was accepted (but as I mentioned above 
the file was not transfered).

More details from you about the expected behavior would be appreciated )

As for the BasicDnD.java I either did not catch the scenario.

What should be dragged from the test? An item from the JTree?

Thank you,
    Denis.


Damjan Jovanovic wrote:
> On Wed, Feb 3, 2010 at 5:22 PM, Denis S. Fokin <Denis.Fokin at sun.com> wrote:
>   
>> Hi Damjan,
>>     
>
> Hi Denis
>
>   
>> Could you provide more details...
>>
>>     
>>> 8. Needs jtreg tests.
>>>       
>> It would be great to look at a sample application, that you used to write
>> your prototype :-)
>> Could you attach it?
>>     
>
> Attached. One is to test drops, the other drags. They're quite hacked :-)
>
>   
>>> It's been tested with Nautilus and File Roller on Linux,
>>> Windows Explorer and Windows Mail on Windows. All work.
>>>       
>> Could you give us more details about scenarios that you have used for the
>> testing?
>>     
>
> Drag file from Java, drop to Nautilus
> Drag file from an archive (eg. ZIP file) opened in File Roller, drop to Java
> Drag file from Java, drop to Windows Explorer
> Drag email or attachment from Windows Mail, drop to Java
> And finally: drag from Java, drop to Java
>
> All tests need the patch applied to compile and run.
>
>   
>> Thank you,
>>     Denis.
>>     
>
> Thank you
> Damjan
>
>   
>> Damjan Jovanovic wrote:
>>     
>>> Hi
>>>
>>> Can I please get some feedback and maybe a sponsor for
>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100124
>>>
>>> I've been waiting for the past 6 weeks. I need to at least know
>>> whether it's worth continuing work on this patch.
>>>
>>> Thank you
>>> Damjan
>>>       
>>     



From damjan.jov at gmail.com  Mon Feb  8 10:34:11 2010
From: damjan.jov at gmail.com (Damjan Jovanovic)
Date: Mon, 8 Feb 2010 20:34:11 +0200
Subject: <AWT Dev> Patch feedback?
In-Reply-To: <4B704BF8.6010300@sun.com>
References: <9e89675b1002010744y1b0c3053vbb10a1e5392a6180@mail.gmail.com>
	<4B6994B7.5000501@sun.com>
	<9e89675b1002031020x7aaa12e5rccf012c29b32db7@mail.gmail.com>
	<4B704BF8.6010300@sun.com>
Message-ID: <9e89675b1002081034k38dab022h4067a0e134c1f23f@mail.gmail.com>

On Mon, Feb 8, 2010 at 7:38 PM, Denis S. Fokin <Denis.Fokin at sun.com> wrote:
> Hi Damjan,

Hi Denis

> Thank you for the samples.
>
> I tried to execute them.
>
> I executed Drop and it did not work for me.
>
> As I understand the class requires an URI as a parameter to store a dropped
> file in the location.
>
> I tired to pass '.' and 'file://....' as parameters but the transfered file
> did not ?appear at the specified locations.
>
> Form the other hand, the drop of a file from ubuntu GNOME desktop was
> refused (I am not sure whether it is a nautilus window) and from ubuntu
> GNOME nautilus window the drop was accepted (but as I mentioned above the
> file was not transfered).
>
> More details from you about the expected behavior would be appreciated )

file:///tmp works for me.

You have to use a drag source which supports XDS, like an archive
opened in Gnome's File Roller, to drop to Drop.java. Nautilus as a
drag source doesn't provide the XDS format, which is why dragging from
it doesn't work and wasn't listed in my test scenarios.

> As for the BasicDnD.java I either did not catch the scenario.
>
> What should be dragged from the test? An item from the JTree?

Check "Turn on Drag and Drop" then drag any item from the JList into
Nautilus. It will make a "hello world file.txt" in the dropped
directory, containing "Hello world" as the text.

> Thank you,
> ? Denis.

Thank you
Damjan

>
> Damjan Jovanovic wrote:
>>
>> On Wed, Feb 3, 2010 at 5:22 PM, Denis S. Fokin <Denis.Fokin at sun.com>
>> wrote:
>>
>>>
>>> Hi Damjan,
>>>
>>
>> Hi Denis
>>
>>
>>>
>>> Could you provide more details...
>>>
>>>
>>>>
>>>> 8. Needs jtreg tests.
>>>>
>>>
>>> It would be great to look at a sample application, that you used to write
>>> your prototype :-)
>>> Could you attach it?
>>>
>>
>> Attached. One is to test drops, the other drags. They're quite hacked :-)
>>
>>
>>>>
>>>> It's been tested with Nautilus and File Roller on Linux,
>>>> Windows Explorer and Windows Mail on Windows. All work.
>>>>
>>>
>>> Could you give us more details about scenarios that you have used for the
>>> testing?
>>>
>>
>> Drag file from Java, drop to Nautilus
>> Drag file from an archive (eg. ZIP file) opened in File Roller, drop to
>> Java
>> Drag file from Java, drop to Windows Explorer
>> Drag email or attachment from Windows Mail, drop to Java
>> And finally: drag from Java, drop to Java
>>
>> All tests need the patch applied to compile and run.
>>
>>
>>>
>>> Thank you,
>>> ? ?Denis.
>>>
>>
>> Thank you
>> Damjan
>>
>>
>>>
>>> Damjan Jovanovic wrote:
>>>
>>>>
>>>> Hi
>>>>
>>>> Can I please get some feedback and maybe a sponsor for
>>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100124
>>>>
>>>> I've been waiting for the past 6 weeks. I need to at least know
>>>> whether it's worth continuing work on this patch.
>>>>
>>>> Thank you
>>>> Damjan
>>>>
>>>
>>>
>
>


From Artem.Ananiev at Sun.COM  Tue Feb  9 03:29:24 2010
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Tue, 09 Feb 2010 14:29:24 +0300
Subject: <AWT Dev> <Swing Dev> Fw: review request for 6899434: Add
	affine	transformsupport to JLayer
In-Reply-To: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
Message-ID: <4B714714.3040108@sun.com>

Hi, Piet,

let's try to find if these two approaches could be combined together. 
What I personally like is:

1. There's no changed in Component (approach 1).

2. AWTAccessor is not changed and not used (approach 1).

3. Small changes in Container (approach 2).

As you correctly noticed, we need some (private or public) API to do 
both forward and reverse transforms - to find a component under mouse 
and to send a translated mouse event. Why couldn't we make the following 
minimal changes then:

a. Introduce a new protected method toLayoutSpace() - or whatever it's 
named - which does nothing by default, but overridden in JLayer to 
respect its transform.

b. Make findComponentAt() protected. It will then be overridden in 
JLayer to respect its inverse transform.

As a side effect, this would give the developers a flexibility to use 
non-affine transforms. They will even be able to use different 
transforms for forward and reverse operations, but I doubt anyone will 
want this (or we could add an explicit warning to JavaDoc about this).

Thanks,

Artem

On 2/8/2010 2:27 PM, Piet Blok wrote:
> Hi Artem,
>
> To demonstrate the implemention via the AWTAccessor pattern, I created a
> version 2 implementation:
>
> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>
> This implementation is much cleaner than the original one.
>
> Looking forward for yout comments,
> Piet
>
>
>
>> Hi Artem,
>>
>> The problem with making existing methods public is that it solves only
>> half of the problem at hand:
>>
>> 1) Locate the correct component (can be solved)
>>
>> 2) Recalculating the mouse point from rendered space to layout space
>> is not solved because the locating methods only return a component.
>> Recalculation is needed to correctly set a mouse point in the new
>> events, relative to the target component.
>>
>> In my proposed implementation the shift caused by transformations is
>> stored when looking up the target (for future use: creating new events
>> from the original event). This future is quite an immediate future
>> because creating a new event from an existing event will always be
>> directly preceded by looking up that target event.
>>
>> An alternative would be to again iterate through the hierarchy and do
>> the transformations. This must be done in LightweightDispatcher in the
>> methods:
>>
>> 1) retargetMouseEvent (an inverse transform is needed, so the new
>> Container method getConvertedPoint can be used)
>>
>> 2) eventDispatched. Unfortunately here an ordinary transform is
>> needed, so a second new Container method must be defined that does an
>> ordinary transform.
>>
>> But.... a completely different approach is also possible. I did this
>> in an earlier version, so I know that it works. With this approach no
>> new public or protected methods need to be introduced and no existing
>> methods need to go public or protected. All remains private or package
>> private.
>>
>> That approach is as follows:
>>
>> 1) Define the AffineTransform as a private field in Component.
>>
>> 2) Use the AWTAccessor pattern to make the transform available in
>> Container and LightweightDispatcher and in swing classes.
>>
>> 3) In Container and LightweightDispatcher, get the transform and do
>> transformations when needed.
>>
>> In my opinion, the solution with the AWTAccessor pattern is the
>> cleanest. However, it requires Component and AWTAccessor to be touched.
>>
>> Please let me know what you think.
>>
>> Piet
>>
>>
>>
>>> Hi, Piet,
>>>
>>> I haven't looked through the entire webrev and inspected mostly an
>>> AWT part of the fix. A question is whether it's possible to get rid
>>> of the new "conversionShift" field in Container, to make
>>> transformations support really stateless?
>>>
>>> Another option to consider is to make some of the existing methods
>>> (e.g. getMouseEventTargetImpl()) public instead of introducing new ones.
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>> Hello all,
>>>>
>>>> review request for 6899434: Add affine transform support to JLayer
>>>>
>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>
>>>> The patch covers all the requested functionality. It is concentrated in
>>>> JLayer class, keeping in mind to affect the library as little as
>>>> possible.
>>>>
>>>> 1) A setter and getter for the transform in JLayer
>>>>
>>>> 2) The paint method in JLayer has been adapted to use the transform
>>>>
>>>> 3) RepaintManager has been adapted to propagate repaint requests from
>>>> the view or any of its children to the top level JLayer and have the
>>>> dirty region transformed.
>>>>
>>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both in the
>>>> same source) have been adapted to redispatch MouseEvents to the
>>>> intended
>>>> target component. The lookup for the component that provides a custon
>>>> cursor has also been adapted.
>>>>
>>>> 5) To enable Container to do necessary reculculations, a protected
>>>> method has been introduced that will be overridden by JLayer:
>>>> protected Point getConvertedPoint(Point point).
>>>> (If someone can suggest a better name for this method I'm glad to hear)
>>>>
>>>> 6) A package private method in SwingUtilities has been added that helps
>>>> JPopupMenu and ToolTipManager to find the correct popup location.
>>>> JPopupMenu and ToolTipManager have been changed to use this new method
>>>> in their calculations.
>>>>
>>>> 7) Two jtreg tests have been added.
>>>>
>>>> Looking forward for comments.
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>


From pbhome at ziggo.nl  Tue Feb  9 05:30:11 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Tue, 9 Feb 2010 14:30:11 +0100
Subject: <AWT Dev> <Swing Dev> Fw: review request for 6899434: Add
	affinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
Message-ID: <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>

Hi Artem,

Thanks for the detailed evaluation.


> Hi, Piet,
>
> let's try to find if these two approaches could be combined together. What 
> I personally like is:
>
> 1. There's no changed in Component (approach 1).
>
> 2. AWTAccessor is not changed and not used (approach 1).
>
> 3. Small changes in Container (approach 2).

Ok, let's try to do it without AWTAccessor and keep the changes in Container 
as small as possible.

>
> As you correctly noticed, we need some (private or public) API to do both 
> forward and reverse transforms - to find a component under mouse and to 
> send a translated mouse event. Why couldn't we make the following minimal 
> changes then:
>
> a. Introduce a new protected method toLayoutSpace() - or whatever it's 
> named - which does nothing by default, but overridden in JLayer to respect 
> its transform.

Ok (like in approach 1). The toLayoutSpace(Point) in Container will become 
protected and will do nothing. JLayer will override it.

>
> b. Make findComponentAt() protected. It will then be overridden in JLayer 
> to respect its inverse transform.

I'm not so sure. First of all, there are two methods in Container that need 
adustment:

- findComponentAt Impl(used for lookup of a component that provides a 
cursor)
- getMouseEventTargetImpl (used for lookup of a target component for a 
MouseEvent)

Both methods use a different lookup approach and follow a chain of method 
invocations. Both are quite complicated and have some parameters that 
influence the lookup. Overriding them in JLayer would make it necessary to 
copy all that code in JLayer and just make one tiny adjustment for the 
transform.

Besides, why did we introduce the toLayoutSpace(Point) method? That method 
is intended to be used to have the Point transformed, like in version 2 
(which you liked) but without the AWTAccessor. That method is introduced 
exactly for that purpose!

>
> As a side effect, this would give the developers a flexibility to use 
> non-affine transforms. They will even be able to use different transforms 
> for forward and reverse operations, but I doubt anyone will want this (or 
> we could add an explicit warning to JavaDoc about this).

Hmm.. I share your doubts, but nevertheless.

You forget one thing to mention: the retargeting in LightweightDispatcher 
also needs adjustment. In version 2 (which you liked) a call is made to a 
private static methods toLayoutSpace(MouseEvent) which uses the AWTAccessor.

This method can be adapted to use the Container.toLayoutSpace(Point) method 
to update the MouseEvent. The AWTAccessor pattern is then obsolete.

So, in summary,

1) The implementation in version 2 will be used but without the AWTAccessor.
:
2) Container.toLayoutSpace(Point) will become protected and the Container 
implementation does nothing.

3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain private and 
static, but will be rewritten to use Container.toLayoutSpace(Point) in a 
hierachy loop.

4) LightweightDispatcher.concatenateHierarchyTransforms() will of course be 
removed.

Please let me know if you agree.

Thanks
Piet

>
> Thanks,
>
> Artem
>
> On 2/8/2010 2:27 PM, Piet Blok wrote:
>> Hi Artem,
>>
>> To demonstrate the implemention via the AWTAccessor pattern, I created a
>> version 2 implementation:
>>
>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>
>> This implementation is much cleaner than the original one.
>>
>> Looking forward for yout comments,
>> Piet
>>
>>
>>
>>> Hi Artem,
>>>
>>> The problem with making existing methods public is that it solves only
>>> half of the problem at hand:
>>>
>>> 1) Locate the correct component (can be solved)
>>>
>>> 2) Recalculating the mouse point from rendered space to layout space
>>> is not solved because the locating methods only return a component.
>>> Recalculation is needed to correctly set a mouse point in the new
>>> events, relative to the target component.
>>>
>>> In my proposed implementation the shift caused by transformations is
>>> stored when looking up the target (for future use: creating new events
>>> from the original event). This future is quite an immediate future
>>> because creating a new event from an existing event will always be
>>> directly preceded by looking up that target event.
>>>
>>> An alternative would be to again iterate through the hierarchy and do
>>> the transformations. This must be done in LightweightDispatcher in the
>>> methods:
>>>
>>> 1) retargetMouseEvent (an inverse transform is needed, so the new
>>> Container method getConvertedPoint can be used)
>>>
>>> 2) eventDispatched. Unfortunately here an ordinary transform is
>>> needed, so a second new Container method must be defined that does an
>>> ordinary transform.
>>>
>>> But.... a completely different approach is also possible. I did this
>>> in an earlier version, so I know that it works. With this approach no
>>> new public or protected methods need to be introduced and no existing
>>> methods need to go public or protected. All remains private or package
>>> private.
>>>
>>> That approach is as follows:
>>>
>>> 1) Define the AffineTransform as a private field in Component.
>>>
>>> 2) Use the AWTAccessor pattern to make the transform available in
>>> Container and LightweightDispatcher and in swing classes.
>>>
>>> 3) In Container and LightweightDispatcher, get the transform and do
>>> transformations when needed.
>>>
>>> In my opinion, the solution with the AWTAccessor pattern is the
>>> cleanest. However, it requires Component and AWTAccessor to be touched.
>>>
>>> Please let me know what you think.
>>>
>>> Piet
>>>
>>>
>>>
>>>> Hi, Piet,
>>>>
>>>> I haven't looked through the entire webrev and inspected mostly an
>>>> AWT part of the fix. A question is whether it's possible to get rid
>>>> of the new "conversionShift" field in Container, to make
>>>> transformations support really stateless?
>>>>
>>>> Another option to consider is to make some of the existing methods
>>>> (e.g. getMouseEventTargetImpl()) public instead of introducing new 
>>>> ones.
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>> Hello all,
>>>>>
>>>>> review request for 6899434: Add affine transform support to JLayer
>>>>>
>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>
>>>>> The patch covers all the requested functionality. It is concentrated 
>>>>> in
>>>>> JLayer class, keeping in mind to affect the library as little as
>>>>> possible.
>>>>>
>>>>> 1) A setter and getter for the transform in JLayer
>>>>>
>>>>> 2) The paint method in JLayer has been adapted to use the transform
>>>>>
>>>>> 3) RepaintManager has been adapted to propagate repaint requests from
>>>>> the view or any of its children to the top level JLayer and have the
>>>>> dirty region transformed.
>>>>>
>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both in the
>>>>> same source) have been adapted to redispatch MouseEvents to the
>>>>> intended
>>>>> target component. The lookup for the component that provides a custon
>>>>> cursor has also been adapted.
>>>>>
>>>>> 5) To enable Container to do necessary reculculations, a protected
>>>>> method has been introduced that will be overridden by JLayer:
>>>>> protected Point getConvertedPoint(Point point).
>>>>> (If someone can suggest a better name for this method I'm glad to 
>>>>> hear)
>>>>>
>>>>> 6) A package private method in SwingUtilities has been added that 
>>>>> helps
>>>>> JPopupMenu and ToolTipManager to find the correct popup location.
>>>>> JPopupMenu and ToolTipManager have been changed to use this new method
>>>>> in their calculations.
>>>>>
>>>>> 7) Two jtreg tests have been added.
>>>>>
>>>>> Looking forward for comments.
>>>>>
>>>>> Thanks,
>>>>> Piet
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
> 




From Alexey.Utkin at Sun.COM  Tue Feb  9 10:20:43 2010
From: Alexey.Utkin at Sun.COM (Alexey Utkin)
Date: Tue, 09 Feb 2010 21:20:43 +0300
Subject: <AWT Dev> Patch feedback?
In-Reply-To: <9e89675b1002031052v1babc67eic213bd54125b71c8@mail.gmail.com>
References: <9e89675b1002010744y1b0c3053vbb10a1e5392a6180@mail.gmail.com>
	<4B6994B7.5000501@sun.com> <4B699BD2.9020208@sun.com>
	<9e89675b1002031052v1babc67eic213bd54125b71c8@mail.gmail.com>
Message-ID: <4B71A77B.30403@sun.com>

On 2/3/2010 21:52, Damjan Jovanovic wrote:
> On Wed, Feb 3, 2010 at 5:52 PM, Denis S. Fokin<Denis.Fokin at sun.com>  wrote:
>    
>> Hi Damjan,
>>      
> Hi Denis
>
>    
>> as for the Windows-specific part, as I know, the similar functionality has
>> been implemented in the next changeset
>>
>> http://hg.openjdk.java.net/jdk7/awt/jdk/rev/fd5bf5955e37
>>      
> IMO it's quite dangerous to implicitly convert FILEDESCRIPTOR +
> FILECONTENTS to temporary files and present them to the caller. If
> someone drags a 100MB file from an FTP server or a directory with
> hundreds of files into Java, you will block the EDT for a long time
> while the files copy. Also AWT allows you to request file contents
> many times before the drop, and you could end up writing many copies
> out, taking time and wasting disk space.
>    
1. The file names are unique. We cannot "writing many copies" of file 
content.
2. If application is written in content-observing mode that means that
author is *really* interested in context that *could* be changed by DnD 
source. And content
update is defensible.
3. Applied approach get the chance for former-designed applications to 
be a drop targets for
attachments (the main use-case that was clearly mentioned in bug 
description). For example,
DnD protocol with temp files are used in a cross platform Thunderbird 
mail client.
4. Temp file approach is in consistence with existent security model.
5. AWT message pumping could be blocked in predictable(limited) time manner.

> The different API used in my patch can be asynchronous relative to the
> EDT, and only allows 1 transfer attempt, thus avoiding all those
> problems where possible. It also happens to be usable on *nix's X
> Direct Save and (I suspect) MacOS's promise data flavors, where the
> drop target doesn't get the file contents at all, it just tells the
> drag source where to write out the file(s) and the drag source writes
> them whenever, however, and whatever it likes - something that cannot
> possibly work with javaFileListFlavor.
>
>    

Ovwr the MS Windows your call stack looks like this:

OLE-DnD callback from OS system
------------------
C++ AwtDragSource::GetData
C++ AwtDataTransferer::ConvertData
C++ AwtDataTransferer::ConvertData
------------------
native-to-Java
------------------
DataTransferer::convertData
DataTransferer::translateTransferable
WDataTransferer::transferAbstractFiles
AbstractFile::open() && abstractFile.getPath()

If  the AbstractFile is an interface, here the user code have a 
privileged access to the system.
The fist and the last that you can do here as a hacker - just block AWT 
thread.
Game over.

The key stone of Java Security: never make a sync-call from AWT thread 
to user code.
This rule was broken in your implementation.
That's why the transferred data have to be prepared in Java *before* DnD 
session.
There is no way to implement asynchronous data provider for the system, 
sorry.
I am agree that it is a good idea to extend Data Flavors list by 
standard URL list,
but it is another hard question.

Regards,
-Alexey Utkin aka uta

>> The implementation has not been promoted yet.
>>      
> That patch for dragging with an image looks impressive, nice work!
>
> You might also want to look at a short patch I made to support
> changing the drag cursor:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100121
>    



From Peter.Zhelezniakov at Sun.COM  Wed Feb 10 06:04:46 2010
From: Peter.Zhelezniakov at Sun.COM (Peter Zhelezniakov)
Date: Wed, 10 Feb 2010 17:04:46 +0300
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: first patch
In-Reply-To: <6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<4B583BD5.9080704@sun.com>
	<6fbbec31001211508v780986a7n936a8d20d182a3a9@mail.gmail.com>
	<4B59944C.2020903@sun.com>
	<6fbbec31001241126o62bcccf8u813f76902b6a8cd1@mail.gmail.com>
	<4B5D9CFA.5010502@sun.com>
	<6fbbec31001251417o2a49f02fr1fc2047993787e31@mail.gmail.com>
	<4B5EFD4F.6030104@sun.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
Message-ID: <4B72BCFE.5050005@Sun.com>

Hi Costantino,

Costantino Cerbo wrote:
>> What do you mean by "doesn't start"? Doesn't gtk_main() print out any
>> diagnostic output to stderr? Or does it get invoked at all?
> Unfortunately no diagnostic output is printed to stderr... try yourself...
> I've also init the GLib thread system and call gdk_threads_enter() and
> gdk_threads_leave() but the problem remains.

It worked for me today - i just added minimal code to start a new 
thread, and added wrapping to Java_sun_awt_X11_GtkFileDialogPeer_run(). 
File dialog was shown, and EDT was not blocked. Makes me think i'm 
missing something.

Anyway, I attach a patch relative to
   http://cr.openjdk.java.net/~anthony/7-43-GTKFileDialog-6913179.1/

Please let me know what you think.
-- 
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtkfd.patch
Type: text/x-patch
Size: 2496 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20100210/129a5a77/gtkfd.patch 

From c.cerbo at gmail.com  Wed Feb 10 10:35:36 2010
From: c.cerbo at gmail.com (Costantino Cerbo)
Date: Wed, 10 Feb 2010 19:35:36 +0100
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: first patch
In-Reply-To: <4B72BCFE.5050005@Sun.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<4B59944C.2020903@sun.com>
	<6fbbec31001241126o62bcccf8u813f76902b6a8cd1@mail.gmail.com>
	<4B5D9CFA.5010502@sun.com>
	<6fbbec31001251417o2a49f02fr1fc2047993787e31@mail.gmail.com>
	<4B5EFD4F.6030104@sun.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
	<4B72BCFE.5050005@Sun.com>
Message-ID: <6fbbec31002101035s51d984c8t9b441272c0128ae5@mail.gmail.com>

Hallo Peter,

2010/2/10 Peter Zhelezniakov <Peter.Zhelezniakov at sun.com>:
> It worked for me today - i just added minimal code to start a new thread,
> and added wrapping to Java_sun_awt_X11_GtkFileDialogPeer_run(). File dialog
> was shown, and EDT was not blocked. Makes me think i'm missing something.
It works correctly, but only if we don't use the GTK L&F.
I didn't realise it and this is a very useful clue: it means that we
do something wrong with the initialization of GTK.

With the GTK L&F, I get these errors:
  Xlib: sequence lost (0x11fae > 0x2233) in reply type 0x1c!

  *** glibc detected ***
/home/c.cerbo/openjdk-awt/jdk/build/linux-i586/bin/java: double free
or corruption (fasttop): 0x912db9d0 ***
  *** glibc detected ***
/home/c.cerbo/openjdk-awt/jdk/build/linux-i586/bin/java: double free
or corruption (out): 0x912d2d10 ***

Regards,
Costantino


From Anthony.Petrov at Sun.COM  Wed Feb 10 23:44:35 2010
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Thu, 11 Feb 2010 10:44:35 +0300
Subject: <AWT Dev> <Swing Dev> Fw: review request for 6899434:
	Add	affinetransformsupport to JLayer
In-Reply-To: <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
Message-ID: <4B73B563.7080002@sun.com>

Hi Piet,

The version #2 looks very good.

On 2/9/2010 4:30 PM Piet Blok wrote:
> 1) The implementation in version 2 will be used but without the 
> AWTAccessor.

So that the Component.transform is moved over to the JLayer class, 
right? That would be great.


> 2) Container.toLayoutSpace(Point) will become protected and the 
> Container implementation does nothing.
> 
> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain private 
> and static, but will be rewritten to use Container.toLayoutSpace(Point) 
> in a hierachy loop.
> 
> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of course 
> be removed.

I like the proposal.

A minor comment regarding the code:

src/share/classes/java/awt/Container.java
> 4875         Component parent = comp.getParent();

I suggest to use the getContainer() method instead. If the comp is a 
window, the getParent() may actually return an owner of the window, 
which we certainly don't want to deal with.

Also, please make sure you format the code according the guidelines: in 
Container.java the code put in the new try{} blocks must be correctly 
indented.

Otherwise looks fine. Thanks!

--
best regards,
Anthony

> 
> Please let me know if you agree.
> 
> Thanks
> Piet
> 
>>
>> Thanks,
>>
>> Artem
>>
>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>> Hi Artem,
>>>
>>> To demonstrate the implemention via the AWTAccessor pattern, I created a
>>> version 2 implementation:
>>>
>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>
>>> This implementation is much cleaner than the original one.
>>>
>>> Looking forward for yout comments,
>>> Piet
>>>
>>>
>>>
>>>> Hi Artem,
>>>>
>>>> The problem with making existing methods public is that it solves only
>>>> half of the problem at hand:
>>>>
>>>> 1) Locate the correct component (can be solved)
>>>>
>>>> 2) Recalculating the mouse point from rendered space to layout space
>>>> is not solved because the locating methods only return a component.
>>>> Recalculation is needed to correctly set a mouse point in the new
>>>> events, relative to the target component.
>>>>
>>>> In my proposed implementation the shift caused by transformations is
>>>> stored when looking up the target (for future use: creating new events
>>>> from the original event). This future is quite an immediate future
>>>> because creating a new event from an existing event will always be
>>>> directly preceded by looking up that target event.
>>>>
>>>> An alternative would be to again iterate through the hierarchy and do
>>>> the transformations. This must be done in LightweightDispatcher in the
>>>> methods:
>>>>
>>>> 1) retargetMouseEvent (an inverse transform is needed, so the new
>>>> Container method getConvertedPoint can be used)
>>>>
>>>> 2) eventDispatched. Unfortunately here an ordinary transform is
>>>> needed, so a second new Container method must be defined that does an
>>>> ordinary transform.
>>>>
>>>> But.... a completely different approach is also possible. I did this
>>>> in an earlier version, so I know that it works. With this approach no
>>>> new public or protected methods need to be introduced and no existing
>>>> methods need to go public or protected. All remains private or package
>>>> private.
>>>>
>>>> That approach is as follows:
>>>>
>>>> 1) Define the AffineTransform as a private field in Component.
>>>>
>>>> 2) Use the AWTAccessor pattern to make the transform available in
>>>> Container and LightweightDispatcher and in swing classes.
>>>>
>>>> 3) In Container and LightweightDispatcher, get the transform and do
>>>> transformations when needed.
>>>>
>>>> In my opinion, the solution with the AWTAccessor pattern is the
>>>> cleanest. However, it requires Component and AWTAccessor to be touched.
>>>>
>>>> Please let me know what you think.
>>>>
>>>> Piet
>>>>
>>>>
>>>>
>>>>> Hi, Piet,
>>>>>
>>>>> I haven't looked through the entire webrev and inspected mostly an
>>>>> AWT part of the fix. A question is whether it's possible to get rid
>>>>> of the new "conversionShift" field in Container, to make
>>>>> transformations support really stateless?
>>>>>
>>>>> Another option to consider is to make some of the existing methods
>>>>> (e.g. getMouseEventTargetImpl()) public instead of introducing new 
>>>>> ones.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> review request for 6899434: Add affine transform support to JLayer
>>>>>>
>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>
>>>>>> The patch covers all the requested functionality. It is 
>>>>>> concentrated in
>>>>>> JLayer class, keeping in mind to affect the library as little as
>>>>>> possible.
>>>>>>
>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>
>>>>>> 2) The paint method in JLayer has been adapted to use the transform
>>>>>>
>>>>>> 3) RepaintManager has been adapted to propagate repaint requests from
>>>>>> the view or any of its children to the top level JLayer and have the
>>>>>> dirty region transformed.
>>>>>>
>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both in the
>>>>>> same source) have been adapted to redispatch MouseEvents to the
>>>>>> intended
>>>>>> target component. The lookup for the component that provides a custon
>>>>>> cursor has also been adapted.
>>>>>>
>>>>>> 5) To enable Container to do necessary reculculations, a protected
>>>>>> method has been introduced that will be overridden by JLayer:
>>>>>> protected Point getConvertedPoint(Point point).
>>>>>> (If someone can suggest a better name for this method I'm glad to 
>>>>>> hear)
>>>>>>
>>>>>> 6) A package private method in SwingUtilities has been added that 
>>>>>> helps
>>>>>> JPopupMenu and ToolTipManager to find the correct popup location.
>>>>>> JPopupMenu and ToolTipManager have been changed to use this new 
>>>>>> method
>>>>>> in their calculations.
>>>>>>
>>>>>> 7) Two jtreg tests have been added.
>>>>>>
>>>>>> Looking forward for comments.
>>>>>>
>>>>>> Thanks,
>>>>>> Piet
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 


From damjan.jov at gmail.com  Thu Feb 11 00:33:07 2010
From: damjan.jov at gmail.com (Damjan Jovanovic)
Date: Thu, 11 Feb 2010 10:33:07 +0200
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: 	first patch
In-Reply-To: <6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<6fbbec31001211508v780986a7n936a8d20d182a3a9@mail.gmail.com>
	<4B59944C.2020903@sun.com>
	<6fbbec31001241126o62bcccf8u813f76902b6a8cd1@mail.gmail.com>
	<4B5D9CFA.5010502@sun.com>
	<6fbbec31001251417o2a49f02fr1fc2047993787e31@mail.gmail.com>
	<4B5EFD4F.6030104@sun.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
Message-ID: <9e89675b1002110033l542b255boc9f87c6a15fcf4da@mail.gmail.com>

On my setup, with your patches, FileDialogTest.java fails to even start:

$ java sun/awt/X11/FileDialogTest
Exception in thread "main" java.lang.InternalError: Unable to load
native GTK libraries
	at com.sun.java.swing.plaf.gtk.GTKLookAndFeel.initialize(GTKLookAndFeel.java:1447)
	at javax.swing.UIManager.setLookAndFeel(UIManager.java:531)
	at javax.swing.UIManager.setLookAndFeel(UIManager.java:576)
	at sun.awt.X11.FileDialogTest.main(FileDialogTest.java:146)

But then jconsole does the same.

Turns out your patches introduce a regression that totally breaks the
GTK LAF for me, since they look for the wrong gthread library name,
causing GTK to fail to load:

+#define GTHREAD_LIB "libgthread-2.0.so"

$ ls /usr/lib/libgthread*
/usr/lib/libgthread-2.0.so.0  /usr/lib/libgthread-2.0.so.0.2200.2

Note the ".0" at the end.

$ strace -f java sun/awt/X11/FileDialogTest
...
[pid   449] open("/lib/tls/i686/cmov/libgthread-2.0.so", O_RDONLY) =
-1 ENOENT (No such file or directory)
[pid   449] open("/lib/tls/i686/libgthread-2.0.so", O_RDONLY) = -1
ENOENT (No such file or directory)
[pid   449] open("/lib/tls/libgthread-2.0.so", O_RDONLY) = -1 ENOENT
(No such file or directory)
[pid   449] open("/lib/i686/cmov/libgthread-2.0.so", O_RDONLY) = -1
ENOENT (No such file or directory)
[pid   449] open("/lib/i686/libgthread-2.0.so", O_RDONLY) = -1 ENOENT
(No such file or directory)
[pid   449] open("/lib/libgthread-2.0.so", O_RDONLY) = -1 ENOENT (No
such file or directory)
[pid   449] open("/usr/lib/tls/libgthread-2.0.so", O_RDONLY) = -1
ENOENT (No such file or directory)
[pid   449] open("/usr/lib/i686/cmov/libgthread-2.0.so", O_RDONLY) =
-1 ENOENT (No such file or directory)
[pid   449] open("/usr/lib/i686/libgthread-2.0.so", O_RDONLY) = -1
ENOENT (No such file or directory)
[pid   449] open("/usr/lib/libgthread-2.0.so", O_RDONLY) = -1 ENOENT
(No such file or directory)
[pid   449] open("/usr/lib/i486-linux-gnu/libgthread-2.0.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
...

This is with the 32 bit Linux Mint 8, but Ubuntu 9.04 has the same problem:

$ ls /usr/lib/libgthread*
libgthread-2.0.so.0         libgthread-2.0.so.0.2000.1

So I don't know where you're testing, that the GTK LAF hasn't regressed.

Otherwise I will test more later.

Thank you for the great work
Damjan Jovanovic


On Fri, Jan 29, 2010 at 1:28 AM, Costantino Cerbo <c.cerbo at gmail.com> wrote:
> Hallo Peter, Hello Anthony,
>
> in the attached patch I take care of all the last Peter's comment.
>
> Unfortunately the problem with the EDT is still there.
>
> 2010/1/28 Anthony Petrov <Anthony.Petrov at sun.com>:
>> What do you mean by "doesn't start"? Doesn't gtk_main() print out any
>> diagnostic output to stderr? Or does it get invoked at all?
> Unfortunately no diagnostic output is printed to stderr... try yourself...
> I've also init the GLib thread system and call gdk_threads_enter() and
> gdk_threads_leave() but the problem remains.
>
> I've no idea how to solve this problem... I've tried also with
> SwingUtilities#invokeLater and SwingWorker...
> I ask again for your help: It would be very nice if some of you can
> address his mind to the solution of this remaining issue... otherwise
> all the work done until now goes lost.
>
> Thanks a lot!
> Costantino
>


From pbhome at ziggo.nl  Thu Feb 11 00:45:44 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Thu, 11 Feb 2010 09:45:44 +0100
Subject: <AWT Dev> <Swing Dev> Fw: review request for 6899434:
	Addaffinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
Message-ID: <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>

Hi Anthony,

> Hi Piet,
>
> The version #2 looks very good.

Looks, yes. Unfortunately, later I detected that it doesn't work. It's 
missing something. Oh yes, I carried out a comprehensive manual test but the 
test setup was wrong: I tested against the version 1! (A jtreg test was 
carried out against version 2 and was succesfull).

I'll try to manually add a remark to that webrev to state that it's invalid 
and should not be used.

>
> On 2/9/2010 4:30 PM Piet Blok wrote:
>> 1) The implementation in version 2 will be used but without the 
>> AWTAccessor.
>
> So that the Component.transform is moved over to the JLayer class, right? 
> That would be great.
>

Yes

>
>> 2) Container.toLayoutSpace(Point) will become protected and the Container 
>> implementation does nothing.
>>
>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain private 
>> and static, but will be rewritten to use Container.toLayoutSpace(Point) 
>> in a hierachy loop.
>>
>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of course 
>> be removed.
>
> I like the proposal.

As said, something was missing: A Container.toRenderedSpace(point) is needed 
as well. This method must return the normal transformed point, as opposed to 
toLayoutSpace() that returns the inverse transformed point.

And yes, like Artem pointed out in an earlier post, this leaves the option 
open for implementers to choose for a transformation  other than 
AffineTransform. Fish eye, some sinus, whatever. (Curious to know how one 
would implement the actual rendering, but that's beside the point).

>
> A minor comment regarding the code:
>
> src/share/classes/java/awt/Container.java
>> 4875         Component parent = comp.getParent();
>
> I suggest to use the getContainer() method instead. If the comp is a 
> window, the getParent() may actually return an owner of the window, which 
> we certainly don't want to deal with.

Aha, wasn't aware of getContainer() (package private). Very good.

>
> Also, please make sure you format the code according the guidelines: in 
> Container.java the code put in the new try{} blocks must be correctly 
> indented.

This I was wondering about: should I or shouldn't I (touch code that is 
otherwise not altered). Now I know, thanks.

>
> Otherwise looks fine. Thanks!
>

Ok, I'm working on version 3. And this time actually testing against this 
same version 3!  I'm still working on some more simple jtreg test cases and 
I'll change to getContainer() and indent correctly.

Thanks,
Piet

> --
> best regards,
> Anthony
>
>>
>> Please let me know if you agree.
>>
>> Thanks
>> Piet
>>
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>>> Hi Artem,
>>>>
>>>> To demonstrate the implemention via the AWTAccessor pattern, I created 
>>>> a
>>>> version 2 implementation:
>>>>
>>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>>
>>>> This implementation is much cleaner than the original one.
>>>>
>>>> Looking forward for yout comments,
>>>> Piet
>>>>
>>>>
>>>>
>>>>> Hi Artem,
>>>>>
>>>>> The problem with making existing methods public is that it solves only
>>>>> half of the problem at hand:
>>>>>
>>>>> 1) Locate the correct component (can be solved)
>>>>>
>>>>> 2) Recalculating the mouse point from rendered space to layout space
>>>>> is not solved because the locating methods only return a component.
>>>>> Recalculation is needed to correctly set a mouse point in the new
>>>>> events, relative to the target component.
>>>>>
>>>>> In my proposed implementation the shift caused by transformations is
>>>>> stored when looking up the target (for future use: creating new events
>>>>> from the original event). This future is quite an immediate future
>>>>> because creating a new event from an existing event will always be
>>>>> directly preceded by looking up that target event.
>>>>>
>>>>> An alternative would be to again iterate through the hierarchy and do
>>>>> the transformations. This must be done in LightweightDispatcher in the
>>>>> methods:
>>>>>
>>>>> 1) retargetMouseEvent (an inverse transform is needed, so the new
>>>>> Container method getConvertedPoint can be used)
>>>>>
>>>>> 2) eventDispatched. Unfortunately here an ordinary transform is
>>>>> needed, so a second new Container method must be defined that does an
>>>>> ordinary transform.
>>>>>
>>>>> But.... a completely different approach is also possible. I did this
>>>>> in an earlier version, so I know that it works. With this approach no
>>>>> new public or protected methods need to be introduced and no existing
>>>>> methods need to go public or protected. All remains private or package
>>>>> private.
>>>>>
>>>>> That approach is as follows:
>>>>>
>>>>> 1) Define the AffineTransform as a private field in Component.
>>>>>
>>>>> 2) Use the AWTAccessor pattern to make the transform available in
>>>>> Container and LightweightDispatcher and in swing classes.
>>>>>
>>>>> 3) In Container and LightweightDispatcher, get the transform and do
>>>>> transformations when needed.
>>>>>
>>>>> In my opinion, the solution with the AWTAccessor pattern is the
>>>>> cleanest. However, it requires Component and AWTAccessor to be 
>>>>> touched.
>>>>>
>>>>> Please let me know what you think.
>>>>>
>>>>> Piet
>>>>>
>>>>>
>>>>>
>>>>>> Hi, Piet,
>>>>>>
>>>>>> I haven't looked through the entire webrev and inspected mostly an
>>>>>> AWT part of the fix. A question is whether it's possible to get rid
>>>>>> of the new "conversionShift" field in Container, to make
>>>>>> transformations support really stateless?
>>>>>>
>>>>>> Another option to consider is to make some of the existing methods
>>>>>> (e.g. getMouseEventTargetImpl()) public instead of introducing new 
>>>>>> ones.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> review request for 6899434: Add affine transform support to JLayer
>>>>>>>
>>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>>
>>>>>>> The patch covers all the requested functionality. It is concentrated 
>>>>>>> in
>>>>>>> JLayer class, keeping in mind to affect the library as little as
>>>>>>> possible.
>>>>>>>
>>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>>
>>>>>>> 2) The paint method in JLayer has been adapted to use the transform
>>>>>>>
>>>>>>> 3) RepaintManager has been adapted to propagate repaint requests 
>>>>>>> from
>>>>>>> the view or any of its children to the top level JLayer and have the
>>>>>>> dirty region transformed.
>>>>>>>
>>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both in 
>>>>>>> the
>>>>>>> same source) have been adapted to redispatch MouseEvents to the
>>>>>>> intended
>>>>>>> target component. The lookup for the component that provides a 
>>>>>>> custon
>>>>>>> cursor has also been adapted.
>>>>>>>
>>>>>>> 5) To enable Container to do necessary reculculations, a protected
>>>>>>> method has been introduced that will be overridden by JLayer:
>>>>>>> protected Point getConvertedPoint(Point point).
>>>>>>> (If someone can suggest a better name for this method I'm glad to 
>>>>>>> hear)
>>>>>>>
>>>>>>> 6) A package private method in SwingUtilities has been added that 
>>>>>>> helps
>>>>>>> JPopupMenu and ToolTipManager to find the correct popup location.
>>>>>>> JPopupMenu and ToolTipManager have been changed to use this new 
>>>>>>> method
>>>>>>> in their calculations.
>>>>>>>
>>>>>>> 7) Two jtreg tests have been added.
>>>>>>>
>>>>>>> Looking forward for comments.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Piet
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 




From c.cerbo at gmail.com  Thu Feb 11 02:01:17 2010
From: c.cerbo at gmail.com (Costantino Cerbo)
Date: Thu, 11 Feb 2010 11:01:17 +0100
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: 	first patch
In-Reply-To: <9e89675b1002110033l542b255boc9f87c6a15fcf4da@mail.gmail.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<4B59944C.2020903@sun.com>
	<6fbbec31001241126o62bcccf8u813f76902b6a8cd1@mail.gmail.com>
	<4B5D9CFA.5010502@sun.com>
	<6fbbec31001251417o2a49f02fr1fc2047993787e31@mail.gmail.com>
	<4B5EFD4F.6030104@sun.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
	<9e89675b1002110033l542b255boc9f87c6a15fcf4da@mail.gmail.com>
Message-ID: <6fbbec31002110201u63518012g9a5451c164db09da@mail.gmail.com>

Hello Damian,

thanks for your interest and collaboration for my patch!

To solve this problem we have to use
  #define GTHREAD_LIB "libgthread-2.0.so.0"
instead of
  #define GTHREAD_LIB "libgthread-2.0.so"

I've seen that also to dynamically load libgtk-x11-2.0 the suffix ".0" is used.

I use Fedora and there both "libgthread-2.0.so.0" and
"libgthread-2.0.so" exist as symbolic link.
In your and other Linux distro is maybe only "libgthread-2.0.so.0" available.

Cheers,
Costantino



2010/2/11 Damjan Jovanovic <damjan.jov at gmail.com>:
> On my setup, with your patches, FileDialogTest.java fails to even start:
>
> $ java sun/awt/X11/FileDialogTest
> Exception in thread "main" java.lang.InternalError: Unable to load
> native GTK libraries
> ? ? ? ?at com.sun.java.swing.plaf.gtk.GTKLookAndFeel.initialize(GTKLookAndFeel.java:1447)
> ? ? ? ?at javax.swing.UIManager.setLookAndFeel(UIManager.java:531)
> ? ? ? ?at javax.swing.UIManager.setLookAndFeel(UIManager.java:576)
> ? ? ? ?at sun.awt.X11.FileDialogTest.main(FileDialogTest.java:146)
>
> But then jconsole does the same.
>
> Turns out your patches introduce a regression that totally breaks the
> GTK LAF for me, since they look for the wrong gthread library name,
> causing GTK to fail to load:
>
> +#define GTHREAD_LIB "libgthread-2.0.so"
>
> $ ls /usr/lib/libgthread*
> /usr/lib/libgthread-2.0.so.0 ?/usr/lib/libgthread-2.0.so.0.2200.2
>
> Note the ".0" at the end.
>
> $ strace -f java sun/awt/X11/FileDialogTest
> ...
> [pid ? 449] open("/lib/tls/i686/cmov/libgthread-2.0.so", O_RDONLY) =
> -1 ENOENT (No such file or directory)
> [pid ? 449] open("/lib/tls/i686/libgthread-2.0.so", O_RDONLY) = -1
> ENOENT (No such file or directory)
> [pid ? 449] open("/lib/tls/libgthread-2.0.so", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> [pid ? 449] open("/lib/i686/cmov/libgthread-2.0.so", O_RDONLY) = -1
> ENOENT (No such file or directory)
> [pid ? 449] open("/lib/i686/libgthread-2.0.so", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> [pid ? 449] open("/lib/libgthread-2.0.so", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> [pid ? 449] open("/usr/lib/tls/libgthread-2.0.so", O_RDONLY) = -1
> ENOENT (No such file or directory)
> [pid ? 449] open("/usr/lib/i686/cmov/libgthread-2.0.so", O_RDONLY) =
> -1 ENOENT (No such file or directory)
> [pid ? 449] open("/usr/lib/i686/libgthread-2.0.so", O_RDONLY) = -1
> ENOENT (No such file or directory)
> [pid ? 449] open("/usr/lib/libgthread-2.0.so", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> [pid ? 449] open("/usr/lib/i486-linux-gnu/libgthread-2.0.so",
> O_RDONLY) = -1 ENOENT (No such file or directory)
> ...
>
> This is with the 32 bit Linux Mint 8, but Ubuntu 9.04 has the same problem:
>
> $ ls /usr/lib/libgthread*
> libgthread-2.0.so.0 ? ? ? ? libgthread-2.0.so.0.2000.1
>
> So I don't know where you're testing, that the GTK LAF hasn't regressed.
>
> Otherwise I will test more later.
>
> Thank you for the great work
> Damjan Jovanovic
>
>
> On Fri, Jan 29, 2010 at 1:28 AM, Costantino Cerbo <c.cerbo at gmail.com> wrote:
>> Hallo Peter, Hello Anthony,
>>
>> in the attached patch I take care of all the last Peter's comment.
>>
>> Unfortunately the problem with the EDT is still there.
>>
>> 2010/1/28 Anthony Petrov <Anthony.Petrov at sun.com>:
>>> What do you mean by "doesn't start"? Doesn't gtk_main() print out any
>>> diagnostic output to stderr? Or does it get invoked at all?
>> Unfortunately no diagnostic output is printed to stderr... try yourself...
>> I've also init the GLib thread system and call gdk_threads_enter() and
>> gdk_threads_leave() but the problem remains.
>>
>> I've no idea how to solve this problem... I've tried also with
>> SwingUtilities#invokeLater and SwingWorker...
>> I ask again for your help: It would be very nice if some of you can
>> address his mind to the solution of this remaining issue... otherwise
>> all the work done until now goes lost.
>>
>> Thanks a lot!
>> Costantino
>>
>


From Peter.Zhelezniakov at Sun.COM  Thu Feb 11 02:26:08 2010
From: Peter.Zhelezniakov at Sun.COM (Peter Zhelezniakov)
Date: Thu, 11 Feb 2010 13:26:08 +0300
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: first patch
In-Reply-To: <6fbbec31002101035s51d984c8t9b441272c0128ae5@mail.gmail.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<4B59944C.2020903@sun.com>
	<6fbbec31001241126o62bcccf8u813f76902b6a8cd1@mail.gmail.com>
	<4B5D9CFA.5010502@sun.com>
	<6fbbec31001251417o2a49f02fr1fc2047993787e31@mail.gmail.com>
	<4B5EFD4F.6030104@sun.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
	<4B72BCFE.5050005@Sun.com>
	<6fbbec31002101035s51d984c8t9b441272c0128ae5@mail.gmail.com>
Message-ID: <4B73DB40.2050804@Sun.com>

Hi Costantino,

Costantino Cerbo wrote:
 > It works correctly, but only if we don't use the GTK L&F.
 > I didn't realise it and this is a very useful clue: it means that we
 > do something wrong with the initialization of GTK.
 >
 > With the GTK L&F, I get these errors:
 >   Xlib: sequence lost (0x11fae > 0x2233) in reply type 0x1c!
 >
 >   *** glibc detected ***
 > /home/c.cerbo/openjdk-awt/jdk/build/linux-i586/bin/java: double free
 > or corruption (fasttop): 0x912db9d0 ***
 >   *** glibc detected ***
 > /home/c.cerbo/openjdk-awt/jdk/build/linux-i586/bin/java: double free
 > or corruption (out): 0x912d2d10 ***

I tried again, this time with your newest patch
   http://cr.openjdk.java.net/~anthony/7-43-GTKFileDialog-6913179.2/

My only change was to start a new thread in GtkFileDialogPeer (see 
gtkfd2.patch, attached). It worked with GTK LAF for me, and i wasn't 
getting any messages. I was running attached GtkFD.java on a Gentoo box 
with gtk+-2.16.6, and was using latest jdk7 sources.

Could you try my patch and test on your machine?

Thanks!
-- 
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GtkFD.java
Type: text/x-java
Size: 1228 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20100211/c45ef0c3/GtkFD.java 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gtkfd2.patch
Url: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20100211/c45ef0c3/gtkfd2.patch 

From Denis.Fokin at Sun.COM  Thu Feb 11 02:47:56 2010
From: Denis.Fokin at Sun.COM (Denis S. Fokin)
Date: Thu, 11 Feb 2010 13:47:56 +0300
Subject: <AWT Dev> Patch feedback?
In-Reply-To: <9e89675b1002081034k38dab022h4067a0e134c1f23f@mail.gmail.com>
References: <9e89675b1002010744y1b0c3053vbb10a1e5392a6180@mail.gmail.com>
	<4B6994B7.5000501@sun.com>
	<9e89675b1002031020x7aaa12e5rccf012c29b32db7@mail.gmail.com>
	<4B704BF8.6010300@sun.com>
	<9e89675b1002081034k38dab022h4067a0e134c1f23f@mail.gmail.com>
Message-ID: <4B73E05C.80908@sun.com>

Hi Damjan,

I thought, that my problems could be concerned with Alexey's patch but 
your test does not work for me even with b81 (

I should look at that deeper.

Thank you,
    Denis.

Damjan Jovanovic wrote:
> On Mon, Feb 8, 2010 at 7:38 PM, Denis S. Fokin <Denis.Fokin at sun.com> wrote:
>   
>> Hi Damjan,
>>     
>
> Hi Denis
>
>   
>> Thank you for the samples.
>>
>> I tried to execute them.
>>
>> I executed Drop and it did not work for me.
>>
>> As I understand the class requires an URI as a parameter to store a dropped
>> file in the location.
>>
>> I tired to pass '.' and 'file://....' as parameters but the transfered file
>> did not  appear at the specified locations.
>>
>> Form the other hand, the drop of a file from ubuntu GNOME desktop was
>> refused (I am not sure whether it is a nautilus window) and from ubuntu
>> GNOME nautilus window the drop was accepted (but as I mentioned above the
>> file was not transfered).
>>
>> More details from you about the expected behavior would be appreciated )
>>     
>
> file:///tmp works for me.
>
> You have to use a drag source which supports XDS, like an archive
> opened in Gnome's File Roller, to drop to Drop.java. Nautilus as a
> drag source doesn't provide the XDS format, which is why dragging from
> it doesn't work and wasn't listed in my test scenarios.
>
>   
>> As for the BasicDnD.java I either did not catch the scenario.
>>
>> What should be dragged from the test? An item from the JTree?
>>     
>
> Check "Turn on Drag and Drop" then drag any item from the JList into
> Nautilus. It will make a "hello world file.txt" in the dropped
> directory, containing "Hello world" as the text.
>
>   
>> Thank you,
>>   Denis.
>>     
>
> Thank you
> Damjan
>
>   
>> Damjan Jovanovic wrote:
>>     
>>> On Wed, Feb 3, 2010 at 5:22 PM, Denis S. Fokin <Denis.Fokin at sun.com>
>>> wrote:
>>>
>>>       
>>>> Hi Damjan,
>>>>
>>>>         
>>> Hi Denis
>>>
>>>
>>>       
>>>> Could you provide more details...
>>>>
>>>>
>>>>         
>>>>> 8. Needs jtreg tests.
>>>>>
>>>>>           
>>>> It would be great to look at a sample application, that you used to write
>>>> your prototype :-)
>>>> Could you attach it?
>>>>
>>>>         
>>> Attached. One is to test drops, the other drags. They're quite hacked :-)
>>>
>>>
>>>       
>>>>> It's been tested with Nautilus and File Roller on Linux,
>>>>> Windows Explorer and Windows Mail on Windows. All work.
>>>>>
>>>>>           
>>>> Could you give us more details about scenarios that you have used for the
>>>> testing?
>>>>
>>>>         
>>> Drag file from Java, drop to Nautilus
>>> Drag file from an archive (eg. ZIP file) opened in File Roller, drop to
>>> Java
>>> Drag file from Java, drop to Windows Explorer
>>> Drag email or attachment from Windows Mail, drop to Java
>>> And finally: drag from Java, drop to Java
>>>
>>> All tests need the patch applied to compile and run.
>>>
>>>
>>>       
>>>> Thank you,
>>>>    Denis.
>>>>
>>>>         
>>> Thank you
>>> Damjan
>>>
>>>
>>>       
>>>> Damjan Jovanovic wrote:
>>>>
>>>>         
>>>>> Hi
>>>>>
>>>>> Can I please get some feedback and maybe a sponsor for
>>>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100124
>>>>>
>>>>> I've been waiting for the past 6 weeks. I need to at least know
>>>>> whether it's worth continuing work on this patch.
>>>>>
>>>>> Thank you
>>>>> Damjan
>>>>>
>>>>>           
>>>>         
>>     



From Peter.Zhelezniakov at Sun.COM  Thu Feb 11 02:49:20 2010
From: Peter.Zhelezniakov at Sun.COM (Peter Zhelezniakov)
Date: Thu, 11 Feb 2010 13:49:20 +0300
Subject: <AWT Dev> Question about GtkLnF implementation
In-Reply-To: <194f62551002020347l11fa6233vdd8a41dfe3a2bbaf@mail.gmail.com>
References: <194f62551001300743u40c9b112y1766eed6369a7c2f@mail.gmail.com>
	<9e89675b1001300813j7e993449x23b5231b9c0c0648@mail.gmail.com>
	<194f62551001300847p3dc450c1yc1610dead2c94222@mail.gmail.com>
	<4B66F108.6010609@sun.com>
	<9e89675b1002010728p6908b8aak402a7fa997d02916@mail.gmail.com>
	<194f62551002020347l11fa6233vdd8a41dfe3a2bbaf@mail.gmail.com>
Message-ID: <4B73E0B0.8060701@Sun.com>

Clemens Eisserer wrote:
>> Who wrote this (I suspect Kirill Kirichenko for some reason) and is
>> this code still around? It would really help to see it.
> Wow, if the code is still arround it would be of course the best solution.
> I am curious how all the rendering routines were implemented.

It seems that code is lost. Its author felt it was a dirty hack and a 
failed experiment. He remembers the patch gave significant speedup with 
vector themes, but nearly regressed on pixmap ones.

I personally agree that the most promising thing is Cairo drawables. 
They should have alpha, and by the time jdk7 ships, Cairo will probably 
be everywhere.

gtk2_interface.c has a large comment describing the situation at the 
time of writing (some five years ago) and possible ways to solve it.

As for drawing to a single pixmap, there's absolutely no reason not to 
try. I wonder if X could put limits on pixmap size, e.g. we could end up 
with a pixmap twice the size of the screen - this can be a problem maybe.

Thanks!
-- 
Peter


From damjan.jov at gmail.com  Thu Feb 11 03:00:07 2010
From: damjan.jov at gmail.com (Damjan Jovanovic)
Date: Thu, 11 Feb 2010 13:00:07 +0200
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: 	first patch
In-Reply-To: <4B73DB40.2050804@Sun.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<4B5D9CFA.5010502@sun.com>
	<6fbbec31001251417o2a49f02fr1fc2047993787e31@mail.gmail.com>
	<4B5EFD4F.6030104@sun.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
	<4B72BCFE.5050005@Sun.com>
	<6fbbec31002101035s51d984c8t9b441272c0128ae5@mail.gmail.com>
	<4B73DB40.2050804@Sun.com>
Message-ID: <9e89675b1002110300j29a0a35ck8b20875066f35aa@mail.gmail.com>

On Thu, Feb 11, 2010 at 12:26 PM, Peter Zhelezniakov
<Peter.Zhelezniakov at sun.com> wrote:
> Hi Costantino,
>
> Costantino Cerbo wrote:
>> It works correctly, but only if we don't use the GTK L&F.
>> I didn't realise it and this is a very useful clue: it means that we
>> do something wrong with the initialization of GTK.
>>
>> With the GTK L&F, I get these errors:
>> ? Xlib: sequence lost (0x11fae > 0x2233) in reply type 0x1c!
>>
>> ? *** glibc detected ***
>> /home/c.cerbo/openjdk-awt/jdk/build/linux-i586/bin/java: double free
>> or corruption (fasttop): 0x912db9d0 ***
>> ? *** glibc detected ***
>> /home/c.cerbo/openjdk-awt/jdk/build/linux-i586/bin/java: double free
>> or corruption (out): 0x912d2d10 ***
>
> I tried again, this time with your newest patch
> ?http://cr.openjdk.java.net/~anthony/7-43-GTKFileDialog-6913179.2/
>
> My only change was to start a new thread in GtkFileDialogPeer (see
> gtkfd2.patch, attached). It worked with GTK LAF for me, and i wasn't getting
> any messages. I was running attached GtkFD.java on a Gentoo box with
> gtk+-2.16.6, and was using latest jdk7 sources.
>
> Could you try my patch and test on your machine?
>
> Thanks!
> --
> Peter
>
> *** src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java.old ?Thu Feb 11
> 13:07:16 2010
> --- src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ? ? ?Thu Feb 11
> 13:07:22 2010
> ***************
> *** 84,93 ****
> ? ? ? ? ?XToolkit.awtLock();
> ? ? ? ? ?try {
> ? ? ? ? ? ? ?if (b) {
> ! ? ? ? ? ? ? ? ? run(fd.getTitle(), fd.getMode(), fd.getDirectory(),
> ! ? ? ? ? ? ? ? ? ? ? ? ? fd.getFile(), fd.getFilenameFilter());
>
> ! ? ? ? ? ? ? ? ? fd.setVisible(false);
> ? ? ? ? ? ? ?} else {
> ? ? ? ? ? ? ? ? ?quit();
> ? ? ? ? ? ? ? ? ?fd.setVisible(false);
> --- 84,98 ----
> ? ? ? ? ?XToolkit.awtLock();
> ? ? ? ? ?try {
> ? ? ? ? ? ? ?if (b) {
> ! ? ? ? ? ? ? ? ? Thread t = new Thread() {
> ! ? ? ? ? ? ? ? ? ? ? public void run() {
> ! ? ? ? ? ? ? ? ? ? ? ? ? GtkFileDialogPeer.this.run(fd.getTitle(),
> fd.getMode(), fd.getDirectory(),
> ! ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? fd.getFile(), fd.getFilenameFilter());
>
> ! ? ? ? ? ? ? ? ? ? ? ? ? fd.setVisible(false);
> ! ? ? ? ? ? ? ? ? ? ? }
> ! ? ? ? ? ? ? ? ? };
> ! ? ? ? ? ? ? ? ? t.start();
> ? ? ? ? ? ? ?} else {
> ? ? ? ? ? ? ? ? ?quit();
> ? ? ? ? ? ? ? ? ?fd.setVisible(false);
>
>

Hi Peter

Your patch causes a native assertion error upon clicking "Save":

$ java sun.awt.X11.FileDialogTest
java: ../../src/xcb_io.c:242: process_responses: Assertion `(((long)
(dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
Aborted

Clicking "Open" either silently exits or indefinitely hangs (no
redraw) both the file dialog and the Java window.

Damjan Jovanovic


From c.cerbo at gmail.com  Thu Feb 11 03:24:35 2010
From: c.cerbo at gmail.com (Costantino Cerbo)
Date: Thu, 11 Feb 2010 12:24:35 +0100
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: 	first patch
In-Reply-To: <9e89675b1002110300j29a0a35ck8b20875066f35aa@mail.gmail.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<6fbbec31001251417o2a49f02fr1fc2047993787e31@mail.gmail.com>
	<4B5EFD4F.6030104@sun.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
	<4B72BCFE.5050005@Sun.com>
	<6fbbec31002101035s51d984c8t9b441272c0128ae5@mail.gmail.com>
	<4B73DB40.2050804@Sun.com>
	<9e89675b1002110300j29a0a35ck8b20875066f35aa@mail.gmail.com>
Message-ID: <6fbbec31002110324v97c55a8v792eb4af2d413d8d@mail.gmail.com>

Hi Peter, Hi Damjan

2010/2/11 Damjan Jovanovic <damjan.jov at gmail.com>:
> Hi Peter
>
> Your patch causes a native assertion error upon clicking "Save":
>
> $ java sun.awt.X11.FileDialogTest
> java: ../../src/xcb_io.c:242: process_responses: Assertion `(((long)
> (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
> Aborted
>
> Clicking "Open" either silently exits or indefinitely hangs (no
> redraw) both the file dialog and the Java window.

Yes, using a new Thread with the GTK L&F causes the same problem also
on my system (Fedora 12).
Without a new Thread it seems to work, but the EDT is of course blocked.

I think we should investigate how we initialise the GTK multithreaded system.

Regards,
Costantino


From pbhome at ziggo.nl  Thu Feb 11 06:25:29 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Thu, 11 Feb 2010 15:25:29 +0100
Subject: <AWT Dev> <Swing Dev> Fw: review request for
	6899434:Addaffinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
	<B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
Message-ID: <0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>

Hi all,

Please find a third version for the webrev here: 
http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/

AWTAccessor removed again

2 protected methods for Container: toLayoutSpace(x,y) and 
toRenderedSpace(x,y), overridden in JLayer.

Use getContainer() in getRenderedSpaceShift(), but getParent() in 
getLayoutSpaceShift(). The latter because it is called from 
retargetMouseEvent which itself uses getParent() when finding the hierarchy 
translation value.

Indented the try block

Added some jtreg test cases, one a manual test.

Please review again

Thanks,
Piet





> Hi Anthony,
>
>> Hi Piet,
>>
>> The version #2 looks very good.
>
> Looks, yes. Unfortunately, later I detected that it doesn't work. It's 
> missing something. Oh yes, I carried out a comprehensive manual test but 
> the test setup was wrong: I tested against the version 1! (A jtreg test 
> was carried out against version 2 and was succesfull).
>
> I'll try to manually add a remark to that webrev to state that it's 
> invalid and should not be used.
>
>>
>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>> 1) The implementation in version 2 will be used but without the 
>>> AWTAccessor.
>>
>> So that the Component.transform is moved over to the JLayer class, right? 
>> That would be great.
>>
>
> Yes
>
>>
>>> 2) Container.toLayoutSpace(Point) will become protected and the 
>>> Container implementation does nothing.
>>>
>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain private 
>>> and static, but will be rewritten to use Container.toLayoutSpace(Point) 
>>> in a hierachy loop.
>>>
>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of course 
>>> be removed.
>>
>> I like the proposal.
>
> As said, something was missing: A Container.toRenderedSpace(point) is 
> needed as well. This method must return the normal transformed point, as 
> opposed to toLayoutSpace() that returns the inverse transformed point.
>
> And yes, like Artem pointed out in an earlier post, this leaves the option 
> open for implementers to choose for a transformation  other than 
> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how one 
> would implement the actual rendering, but that's beside the point).
>
>>
>> A minor comment regarding the code:
>>
>> src/share/classes/java/awt/Container.java
>>> 4875         Component parent = comp.getParent();
>>
>> I suggest to use the getContainer() method instead. If the comp is a 
>> window, the getParent() may actually return an owner of the window, which 
>> we certainly don't want to deal with.
>
> Aha, wasn't aware of getContainer() (package private). Very good.
>
>>
>> Also, please make sure you format the code according the guidelines: in 
>> Container.java the code put in the new try{} blocks must be correctly 
>> indented.
>
> This I was wondering about: should I or shouldn't I (touch code that is 
> otherwise not altered). Now I know, thanks.
>
>>
>> Otherwise looks fine. Thanks!
>>
>
> Ok, I'm working on version 3. And this time actually testing against this 
> same version 3!  I'm still working on some more simple jtreg test cases 
> and I'll change to getContainer() and indent correctly.
>
> Thanks,
> Piet
>
>> --
>> best regards,
>> Anthony
>>
>>>
>>> Please let me know if you agree.
>>>
>>> Thanks
>>> Piet
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>>>> Hi Artem,
>>>>>
>>>>> To demonstrate the implemention via the AWTAccessor pattern, I created 
>>>>> a
>>>>> version 2 implementation:
>>>>>
>>>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>>>
>>>>> This implementation is much cleaner than the original one.
>>>>>
>>>>> Looking forward for yout comments,
>>>>> Piet
>>>>>
>>>>>
>>>>>
>>>>>> Hi Artem,
>>>>>>
>>>>>> The problem with making existing methods public is that it solves 
>>>>>> only
>>>>>> half of the problem at hand:
>>>>>>
>>>>>> 1) Locate the correct component (can be solved)
>>>>>>
>>>>>> 2) Recalculating the mouse point from rendered space to layout space
>>>>>> is not solved because the locating methods only return a component.
>>>>>> Recalculation is needed to correctly set a mouse point in the new
>>>>>> events, relative to the target component.
>>>>>>
>>>>>> In my proposed implementation the shift caused by transformations is
>>>>>> stored when looking up the target (for future use: creating new 
>>>>>> events
>>>>>> from the original event). This future is quite an immediate future
>>>>>> because creating a new event from an existing event will always be
>>>>>> directly preceded by looking up that target event.
>>>>>>
>>>>>> An alternative would be to again iterate through the hierarchy and do
>>>>>> the transformations. This must be done in LightweightDispatcher in 
>>>>>> the
>>>>>> methods:
>>>>>>
>>>>>> 1) retargetMouseEvent (an inverse transform is needed, so the new
>>>>>> Container method getConvertedPoint can be used)
>>>>>>
>>>>>> 2) eventDispatched. Unfortunately here an ordinary transform is
>>>>>> needed, so a second new Container method must be defined that does an
>>>>>> ordinary transform.
>>>>>>
>>>>>> But.... a completely different approach is also possible. I did this
>>>>>> in an earlier version, so I know that it works. With this approach no
>>>>>> new public or protected methods need to be introduced and no existing
>>>>>> methods need to go public or protected. All remains private or 
>>>>>> package
>>>>>> private.
>>>>>>
>>>>>> That approach is as follows:
>>>>>>
>>>>>> 1) Define the AffineTransform as a private field in Component.
>>>>>>
>>>>>> 2) Use the AWTAccessor pattern to make the transform available in
>>>>>> Container and LightweightDispatcher and in swing classes.
>>>>>>
>>>>>> 3) In Container and LightweightDispatcher, get the transform and do
>>>>>> transformations when needed.
>>>>>>
>>>>>> In my opinion, the solution with the AWTAccessor pattern is the
>>>>>> cleanest. However, it requires Component and AWTAccessor to be 
>>>>>> touched.
>>>>>>
>>>>>> Please let me know what you think.
>>>>>>
>>>>>> Piet
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi, Piet,
>>>>>>>
>>>>>>> I haven't looked through the entire webrev and inspected mostly an
>>>>>>> AWT part of the fix. A question is whether it's possible to get rid
>>>>>>> of the new "conversionShift" field in Container, to make
>>>>>>> transformations support really stateless?
>>>>>>>
>>>>>>> Another option to consider is to make some of the existing methods
>>>>>>> (e.g. getMouseEventTargetImpl()) public instead of introducing new 
>>>>>>> ones.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> review request for 6899434: Add affine transform support to JLayer
>>>>>>>>
>>>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>>>
>>>>>>>> The patch covers all the requested functionality. It is 
>>>>>>>> concentrated in
>>>>>>>> JLayer class, keeping in mind to affect the library as little as
>>>>>>>> possible.
>>>>>>>>
>>>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>>>
>>>>>>>> 2) The paint method in JLayer has been adapted to use the transform
>>>>>>>>
>>>>>>>> 3) RepaintManager has been adapted to propagate repaint requests 
>>>>>>>> from
>>>>>>>> the view or any of its children to the top level JLayer and have 
>>>>>>>> the
>>>>>>>> dirty region transformed.
>>>>>>>>
>>>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both in 
>>>>>>>> the
>>>>>>>> same source) have been adapted to redispatch MouseEvents to the
>>>>>>>> intended
>>>>>>>> target component. The lookup for the component that provides a 
>>>>>>>> custon
>>>>>>>> cursor has also been adapted.
>>>>>>>>
>>>>>>>> 5) To enable Container to do necessary reculculations, a protected
>>>>>>>> method has been introduced that will be overridden by JLayer:
>>>>>>>> protected Point getConvertedPoint(Point point).
>>>>>>>> (If someone can suggest a better name for this method I'm glad to 
>>>>>>>> hear)
>>>>>>>>
>>>>>>>> 6) A package private method in SwingUtilities has been added that 
>>>>>>>> helps
>>>>>>>> JPopupMenu and ToolTipManager to find the correct popup location.
>>>>>>>> JPopupMenu and ToolTipManager have been changed to use this new 
>>>>>>>> method
>>>>>>>> in their calculations.
>>>>>>>>
>>>>>>>> 7) Two jtreg tests have been added.
>>>>>>>>
>>>>>>>> Looking forward for comments.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Piet
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
> 




From Artem.Ananiev at Sun.COM  Thu Feb 11 09:48:03 2010
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Thu, 11 Feb 2010 20:48:03 +0300
Subject: <AWT Dev> <Swing Dev> Fw: review request
	for	6899434:Addaffinetransformsupport to JLayer
In-Reply-To: <0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
Message-ID: <4B7442D3.3040709@sun.com>

Hi, Piet,

the 3rd version looks really great! I haven't looked to Swing code much, 
though :)

A small suggestion is to unify getRenderedSpaceShift() and 
getLayoutSpaceShift(), so they both accept a Component and a Point to 
translate. Could they also be static methods? It seems not, as I see a 
reference to "nativeContainer" in getLayoutSpaceShift()...

Thanks,

Artem

On 2/11/2010 5:25 PM, Piet Blok wrote:
> Hi all,
>
> Please find a third version for the webrev here:
> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>
> AWTAccessor removed again
>
> 2 protected methods for Container: toLayoutSpace(x,y) and
> toRenderedSpace(x,y), overridden in JLayer.
>
> Use getContainer() in getRenderedSpaceShift(), but getParent() in
> getLayoutSpaceShift(). The latter because it is called from
> retargetMouseEvent which itself uses getParent() when finding the
> hierarchy translation value.
>
> Indented the try block
>
> Added some jtreg test cases, one a manual test.
>
> Please review again
>
> Thanks,
> Piet
>
>
>
>
>
>> Hi Anthony,
>>
>>> Hi Piet,
>>>
>>> The version #2 looks very good.
>>
>> Looks, yes. Unfortunately, later I detected that it doesn't work. It's
>> missing something. Oh yes, I carried out a comprehensive manual test
>> but the test setup was wrong: I tested against the version 1! (A jtreg
>> test was carried out against version 2 and was succesfull).
>>
>> I'll try to manually add a remark to that webrev to state that it's
>> invalid and should not be used.
>>
>>>
>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>> 1) The implementation in version 2 will be used but without the
>>>> AWTAccessor.
>>>
>>> So that the Component.transform is moved over to the JLayer class,
>>> right? That would be great.
>>>
>>
>> Yes
>>
>>>
>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>> Container implementation does nothing.
>>>>
>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>> private and static, but will be rewritten to use
>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>
>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>> course be removed.
>>>
>>> I like the proposal.
>>
>> As said, something was missing: A Container.toRenderedSpace(point) is
>> needed as well. This method must return the normal transformed point,
>> as opposed to toLayoutSpace() that returns the inverse transformed point.
>>
>> And yes, like Artem pointed out in an earlier post, this leaves the
>> option open for implementers to choose for a transformation other than
>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>> one would implement the actual rendering, but that's beside the point).
>>
>>>
>>> A minor comment regarding the code:
>>>
>>> src/share/classes/java/awt/Container.java
>>>> 4875 Component parent = comp.getParent();
>>>
>>> I suggest to use the getContainer() method instead. If the comp is a
>>> window, the getParent() may actually return an owner of the window,
>>> which we certainly don't want to deal with.
>>
>> Aha, wasn't aware of getContainer() (package private). Very good.
>>
>>>
>>> Also, please make sure you format the code according the guidelines:
>>> in Container.java the code put in the new try{} blocks must be
>>> correctly indented.
>>
>> This I was wondering about: should I or shouldn't I (touch code that
>> is otherwise not altered). Now I know, thanks.
>>
>>>
>>> Otherwise looks fine. Thanks!
>>>
>>
>> Ok, I'm working on version 3. And this time actually testing against
>> this same version 3! I'm still working on some more simple jtreg test
>> cases and I'll change to getContainer() and indent correctly.
>>
>> Thanks,
>> Piet
>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>>>
>>>> Please let me know if you agree.
>>>>
>>>> Thanks
>>>> Piet
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>>>>> Hi Artem,
>>>>>>
>>>>>> To demonstrate the implemention via the AWTAccessor pattern, I
>>>>>> created a
>>>>>> version 2 implementation:
>>>>>>
>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>>>>
>>>>>> This implementation is much cleaner than the original one.
>>>>>>
>>>>>> Looking forward for yout comments,
>>>>>> Piet
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Artem,
>>>>>>>
>>>>>>> The problem with making existing methods public is that it solves
>>>>>>> only
>>>>>>> half of the problem at hand:
>>>>>>>
>>>>>>> 1) Locate the correct component (can be solved)
>>>>>>>
>>>>>>> 2) Recalculating the mouse point from rendered space to layout space
>>>>>>> is not solved because the locating methods only return a component.
>>>>>>> Recalculation is needed to correctly set a mouse point in the new
>>>>>>> events, relative to the target component.
>>>>>>>
>>>>>>> In my proposed implementation the shift caused by transformations is
>>>>>>> stored when looking up the target (for future use: creating new
>>>>>>> events
>>>>>>> from the original event). This future is quite an immediate future
>>>>>>> because creating a new event from an existing event will always be
>>>>>>> directly preceded by looking up that target event.
>>>>>>>
>>>>>>> An alternative would be to again iterate through the hierarchy
>>>>>>> and do
>>>>>>> the transformations. This must be done in LightweightDispatcher
>>>>>>> in the
>>>>>>> methods:
>>>>>>>
>>>>>>> 1) retargetMouseEvent (an inverse transform is needed, so the new
>>>>>>> Container method getConvertedPoint can be used)
>>>>>>>
>>>>>>> 2) eventDispatched. Unfortunately here an ordinary transform is
>>>>>>> needed, so a second new Container method must be defined that
>>>>>>> does an
>>>>>>> ordinary transform.
>>>>>>>
>>>>>>> But.... a completely different approach is also possible. I did this
>>>>>>> in an earlier version, so I know that it works. With this
>>>>>>> approach no
>>>>>>> new public or protected methods need to be introduced and no
>>>>>>> existing
>>>>>>> methods need to go public or protected. All remains private or
>>>>>>> package
>>>>>>> private.
>>>>>>>
>>>>>>> That approach is as follows:
>>>>>>>
>>>>>>> 1) Define the AffineTransform as a private field in Component.
>>>>>>>
>>>>>>> 2) Use the AWTAccessor pattern to make the transform available in
>>>>>>> Container and LightweightDispatcher and in swing classes.
>>>>>>>
>>>>>>> 3) In Container and LightweightDispatcher, get the transform and do
>>>>>>> transformations when needed.
>>>>>>>
>>>>>>> In my opinion, the solution with the AWTAccessor pattern is the
>>>>>>> cleanest. However, it requires Component and AWTAccessor to be
>>>>>>> touched.
>>>>>>>
>>>>>>> Please let me know what you think.
>>>>>>>
>>>>>>> Piet
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi, Piet,
>>>>>>>>
>>>>>>>> I haven't looked through the entire webrev and inspected mostly an
>>>>>>>> AWT part of the fix. A question is whether it's possible to get rid
>>>>>>>> of the new "conversionShift" field in Container, to make
>>>>>>>> transformations support really stateless?
>>>>>>>>
>>>>>>>> Another option to consider is to make some of the existing methods
>>>>>>>> (e.g. getMouseEventTargetImpl()) public instead of introducing
>>>>>>>> new ones.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Artem
>>>>>>>>
>>>>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> review request for 6899434: Add affine transform support to JLayer
>>>>>>>>>
>>>>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>>>>
>>>>>>>>> The patch covers all the requested functionality. It is
>>>>>>>>> concentrated in
>>>>>>>>> JLayer class, keeping in mind to affect the library as little as
>>>>>>>>> possible.
>>>>>>>>>
>>>>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>>>>
>>>>>>>>> 2) The paint method in JLayer has been adapted to use the
>>>>>>>>> transform
>>>>>>>>>
>>>>>>>>> 3) RepaintManager has been adapted to propagate repaint
>>>>>>>>> requests from
>>>>>>>>> the view or any of its children to the top level JLayer and
>>>>>>>>> have the
>>>>>>>>> dirty region transformed.
>>>>>>>>>
>>>>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both
>>>>>>>>> in the
>>>>>>>>> same source) have been adapted to redispatch MouseEvents to the
>>>>>>>>> intended
>>>>>>>>> target component. The lookup for the component that provides a
>>>>>>>>> custon
>>>>>>>>> cursor has also been adapted.
>>>>>>>>>
>>>>>>>>> 5) To enable Container to do necessary reculculations, a protected
>>>>>>>>> method has been introduced that will be overridden by JLayer:
>>>>>>>>> protected Point getConvertedPoint(Point point).
>>>>>>>>> (If someone can suggest a better name for this method I'm glad
>>>>>>>>> to hear)
>>>>>>>>>
>>>>>>>>> 6) A package private method in SwingUtilities has been added
>>>>>>>>> that helps
>>>>>>>>> JPopupMenu and ToolTipManager to find the correct popup location.
>>>>>>>>> JPopupMenu and ToolTipManager have been changed to use this new
>>>>>>>>> method
>>>>>>>>> in their calculations.
>>>>>>>>>
>>>>>>>>> 7) Two jtreg tests have been added.
>>>>>>>>>
>>>>>>>>> Looking forward for comments.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Piet
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>


From c.cerbo at gmail.com  Thu Feb 11 14:35:49 2010
From: c.cerbo at gmail.com (Costantino Cerbo)
Date: Thu, 11 Feb 2010 23:35:49 +0100
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: first patch
In-Reply-To: <4B73DB40.2050804@Sun.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<4B5D9CFA.5010502@sun.com>
	<6fbbec31001251417o2a49f02fr1fc2047993787e31@mail.gmail.com>
	<4B5EFD4F.6030104@sun.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
	<4B72BCFE.5050005@Sun.com>
	<6fbbec31002101035s51d984c8t9b441272c0128ae5@mail.gmail.com>
	<4B73DB40.2050804@Sun.com>
Message-ID: <6fbbec31002111435k1f367312u63b7e4a3522b181e@mail.gmail.com>

Hi Peter, Hi Damjan,

I've observed that the FileChooser with the GTK L&F either silently
exits or indefinitely hangs when the function
  fp_gtk_main()
is called in sun_awt_X11_GtkFileDialogPeer.c

Calling gtk-main() more times shouldn't be a problem.
I've read on http://library.gnome.org/devel/gtk/unstable/gtk-General.html#gtk-main
that is supports nested calls.

How do we can debug the native code to capture further information?

Cheers,
Costantino

P.S.: My OS is Fedora 12 with GTK+ 2.18.6


2010/2/11 Peter Zhelezniakov <Peter.Zhelezniakov at sun.com>:
> Hi Costantino,
>
> Costantino Cerbo wrote:
>> It works correctly, but only if we don't use the GTK L&F.
>> I didn't realise it and this is a very useful clue: it means that we
>> do something wrong with the initialization of GTK.
>>
>> With the GTK L&F, I get these errors:
>> ? Xlib: sequence lost (0x11fae > 0x2233) in reply type 0x1c!
>>
>> ? *** glibc detected ***
>> /home/c.cerbo/openjdk-awt/jdk/build/linux-i586/bin/java: double free
>> or corruption (fasttop): 0x912db9d0 ***
>> ? *** glibc detected ***
>> /home/c.cerbo/openjdk-awt/jdk/build/linux-i586/bin/java: double free
>> or corruption (out): 0x912d2d10 ***
>
> I tried again, this time with your newest patch
> ?http://cr.openjdk.java.net/~anthony/7-43-GTKFileDialog-6913179.2/
>
> My only change was to start a new thread in GtkFileDialogPeer (see
> gtkfd2.patch, attached). It worked with GTK LAF for me, and i wasn't getting
> any messages. I was running attached GtkFD.java on a Gentoo box with
> gtk+-2.16.6, and was using latest jdk7 sources.
>
> Could you try my patch and test on your machine?
>
> Thanks!
> --
> Peter
>
> *** src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java.old ?Thu Feb 11
> 13:07:16 2010
> --- src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ? ? ?Thu Feb 11
> 13:07:22 2010
> ***************
> *** 84,93 ****
> ? ? ? ? ?XToolkit.awtLock();
> ? ? ? ? ?try {
> ? ? ? ? ? ? ?if (b) {
> ! ? ? ? ? ? ? ? ? run(fd.getTitle(), fd.getMode(), fd.getDirectory(),
> ! ? ? ? ? ? ? ? ? ? ? ? ? fd.getFile(), fd.getFilenameFilter());
>
> ! ? ? ? ? ? ? ? ? fd.setVisible(false);
> ? ? ? ? ? ? ?} else {
> ? ? ? ? ? ? ? ? ?quit();
> ? ? ? ? ? ? ? ? ?fd.setVisible(false);
> --- 84,98 ----
> ? ? ? ? ?XToolkit.awtLock();
> ? ? ? ? ?try {
> ? ? ? ? ? ? ?if (b) {
> ! ? ? ? ? ? ? ? ? Thread t = new Thread() {
> ! ? ? ? ? ? ? ? ? ? ? public void run() {
> ! ? ? ? ? ? ? ? ? ? ? ? ? GtkFileDialogPeer.this.run(fd.getTitle(),
> fd.getMode(), fd.getDirectory(),
> ! ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? fd.getFile(), fd.getFilenameFilter());
>
> ! ? ? ? ? ? ? ? ? ? ? ? ? fd.setVisible(false);
> ! ? ? ? ? ? ? ? ? ? ? }
> ! ? ? ? ? ? ? ? ? };
> ! ? ? ? ? ? ? ? ? t.start();
> ? ? ? ? ? ? ?} else {
> ? ? ? ? ? ? ? ? ?quit();
> ? ? ? ? ? ? ? ? ?fd.setVisible(false);
>
>


From pbhome at ziggo.nl  Thu Feb 11 23:53:38 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Fri, 12 Feb 2010 08:53:38 +0100
Subject: <AWT Dev> <Swing Dev> Fw: review request
	for6899434:Addaffinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
	<B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
	<4B7442D3.3040709@sun.com>
Message-ID: <7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>


Hi Artem,

The webrev for version 3.1: 
http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/


> Hi, Piet,
>
> the 3rd version looks really great! I haven't looked to Swing code much, 
> though :)
>
> A small suggestion is to unify getRenderedSpaceShift() and 
> getLayoutSpaceShift(), so they both accept a Component and a Point to 
> translate. Could they also be static methods? It seems not, as I see a 
> reference to "nativeContainer" in getLayoutSpaceShift()...

I unified both methods and made them static after adding nativeContainer as 
a parameter to both. Their signature is now:

private static Point getXXXSpaceShift(Component target, Point dstPoint, 
Container nativeContainer)

(the nativeContainer argument is used in only one of the methods)

For the swing guys: in SwingUtilities and RepaintManager, where iterating 
over the parent hierarchy, I added a check to "parent != null" to also check 
"!(parent instanceof Window)".

Thanks,
Piet

>
> Thanks,
>
> Artem
>
> On 2/11/2010 5:25 PM, Piet Blok wrote:
>> Hi all,
>>
>> Please find a third version for the webrev here:
>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>
>> AWTAccessor removed again
>>
>> 2 protected methods for Container: toLayoutSpace(x,y) and
>> toRenderedSpace(x,y), overridden in JLayer.
>>
>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>> getLayoutSpaceShift(). The latter because it is called from
>> retargetMouseEvent which itself uses getParent() when finding the
>> hierarchy translation value.
>>
>> Indented the try block
>>
>> Added some jtreg test cases, one a manual test.
>>
>> Please review again
>>
>> Thanks,
>> Piet
>>
>>
>>
>>
>>
>>> Hi Anthony,
>>>
>>>> Hi Piet,
>>>>
>>>> The version #2 looks very good.
>>>
>>> Looks, yes. Unfortunately, later I detected that it doesn't work. It's
>>> missing something. Oh yes, I carried out a comprehensive manual test
>>> but the test setup was wrong: I tested against the version 1! (A jtreg
>>> test was carried out against version 2 and was succesfull).
>>>
>>> I'll try to manually add a remark to that webrev to state that it's
>>> invalid and should not be used.
>>>
>>>>
>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>> 1) The implementation in version 2 will be used but without the
>>>>> AWTAccessor.
>>>>
>>>> So that the Component.transform is moved over to the JLayer class,
>>>> right? That would be great.
>>>>
>>>
>>> Yes
>>>
>>>>
>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>> Container implementation does nothing.
>>>>>
>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>> private and static, but will be rewritten to use
>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>
>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>> course be removed.
>>>>
>>>> I like the proposal.
>>>
>>> As said, something was missing: A Container.toRenderedSpace(point) is
>>> needed as well. This method must return the normal transformed point,
>>> as opposed to toLayoutSpace() that returns the inverse transformed 
>>> point.
>>>
>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>> option open for implementers to choose for a transformation other than
>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>>> one would implement the actual rendering, but that's beside the point).
>>>
>>>>
>>>> A minor comment regarding the code:
>>>>
>>>> src/share/classes/java/awt/Container.java
>>>>> 4875 Component parent = comp.getParent();
>>>>
>>>> I suggest to use the getContainer() method instead. If the comp is a
>>>> window, the getParent() may actually return an owner of the window,
>>>> which we certainly don't want to deal with.
>>>
>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>
>>>>
>>>> Also, please make sure you format the code according the guidelines:
>>>> in Container.java the code put in the new try{} blocks must be
>>>> correctly indented.
>>>
>>> This I was wondering about: should I or shouldn't I (touch code that
>>> is otherwise not altered). Now I know, thanks.
>>>
>>>>
>>>> Otherwise looks fine. Thanks!
>>>>
>>>
>>> Ok, I'm working on version 3. And this time actually testing against
>>> this same version 3! I'm still working on some more simple jtreg test
>>> cases and I'll change to getContainer() and indent correctly.
>>>
>>> Thanks,
>>> Piet
>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>>>
>>>>> Please let me know if you agree.
>>>>>
>>>>> Thanks
>>>>> Piet
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>>>>>> Hi Artem,
>>>>>>>
>>>>>>> To demonstrate the implemention via the AWTAccessor pattern, I
>>>>>>> created a
>>>>>>> version 2 implementation:
>>>>>>>
>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>>>>>
>>>>>>> This implementation is much cleaner than the original one.
>>>>>>>
>>>>>>> Looking forward for yout comments,
>>>>>>> Piet
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Artem,
>>>>>>>>
>>>>>>>> The problem with making existing methods public is that it solves
>>>>>>>> only
>>>>>>>> half of the problem at hand:
>>>>>>>>
>>>>>>>> 1) Locate the correct component (can be solved)
>>>>>>>>
>>>>>>>> 2) Recalculating the mouse point from rendered space to layout 
>>>>>>>> space
>>>>>>>> is not solved because the locating methods only return a component.
>>>>>>>> Recalculation is needed to correctly set a mouse point in the new
>>>>>>>> events, relative to the target component.
>>>>>>>>
>>>>>>>> In my proposed implementation the shift caused by transformations 
>>>>>>>> is
>>>>>>>> stored when looking up the target (for future use: creating new
>>>>>>>> events
>>>>>>>> from the original event). This future is quite an immediate future
>>>>>>>> because creating a new event from an existing event will always be
>>>>>>>> directly preceded by looking up that target event.
>>>>>>>>
>>>>>>>> An alternative would be to again iterate through the hierarchy
>>>>>>>> and do
>>>>>>>> the transformations. This must be done in LightweightDispatcher
>>>>>>>> in the
>>>>>>>> methods:
>>>>>>>>
>>>>>>>> 1) retargetMouseEvent (an inverse transform is needed, so the new
>>>>>>>> Container method getConvertedPoint can be used)
>>>>>>>>
>>>>>>>> 2) eventDispatched. Unfortunately here an ordinary transform is
>>>>>>>> needed, so a second new Container method must be defined that
>>>>>>>> does an
>>>>>>>> ordinary transform.
>>>>>>>>
>>>>>>>> But.... a completely different approach is also possible. I did 
>>>>>>>> this
>>>>>>>> in an earlier version, so I know that it works. With this
>>>>>>>> approach no
>>>>>>>> new public or protected methods need to be introduced and no
>>>>>>>> existing
>>>>>>>> methods need to go public or protected. All remains private or
>>>>>>>> package
>>>>>>>> private.
>>>>>>>>
>>>>>>>> That approach is as follows:
>>>>>>>>
>>>>>>>> 1) Define the AffineTransform as a private field in Component.
>>>>>>>>
>>>>>>>> 2) Use the AWTAccessor pattern to make the transform available in
>>>>>>>> Container and LightweightDispatcher and in swing classes.
>>>>>>>>
>>>>>>>> 3) In Container and LightweightDispatcher, get the transform and do
>>>>>>>> transformations when needed.
>>>>>>>>
>>>>>>>> In my opinion, the solution with the AWTAccessor pattern is the
>>>>>>>> cleanest. However, it requires Component and AWTAccessor to be
>>>>>>>> touched.
>>>>>>>>
>>>>>>>> Please let me know what you think.
>>>>>>>>
>>>>>>>> Piet
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi, Piet,
>>>>>>>>>
>>>>>>>>> I haven't looked through the entire webrev and inspected mostly an
>>>>>>>>> AWT part of the fix. A question is whether it's possible to get 
>>>>>>>>> rid
>>>>>>>>> of the new "conversionShift" field in Container, to make
>>>>>>>>> transformations support really stateless?
>>>>>>>>>
>>>>>>>>> Another option to consider is to make some of the existing methods
>>>>>>>>> (e.g. getMouseEventTargetImpl()) public instead of introducing
>>>>>>>>> new ones.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Artem
>>>>>>>>>
>>>>>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>>>>>> Hello all,
>>>>>>>>>>
>>>>>>>>>> review request for 6899434: Add affine transform support to 
>>>>>>>>>> JLayer
>>>>>>>>>>
>>>>>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>>>>>
>>>>>>>>>> The patch covers all the requested functionality. It is
>>>>>>>>>> concentrated in
>>>>>>>>>> JLayer class, keeping in mind to affect the library as little as
>>>>>>>>>> possible.
>>>>>>>>>>
>>>>>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>>>>>
>>>>>>>>>> 2) The paint method in JLayer has been adapted to use the
>>>>>>>>>> transform
>>>>>>>>>>
>>>>>>>>>> 3) RepaintManager has been adapted to propagate repaint
>>>>>>>>>> requests from
>>>>>>>>>> the view or any of its children to the top level JLayer and
>>>>>>>>>> have the
>>>>>>>>>> dirty region transformed.
>>>>>>>>>>
>>>>>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both
>>>>>>>>>> in the
>>>>>>>>>> same source) have been adapted to redispatch MouseEvents to the
>>>>>>>>>> intended
>>>>>>>>>> target component. The lookup for the component that provides a
>>>>>>>>>> custon
>>>>>>>>>> cursor has also been adapted.
>>>>>>>>>>
>>>>>>>>>> 5) To enable Container to do necessary reculculations, a 
>>>>>>>>>> protected
>>>>>>>>>> method has been introduced that will be overridden by JLayer:
>>>>>>>>>> protected Point getConvertedPoint(Point point).
>>>>>>>>>> (If someone can suggest a better name for this method I'm glad
>>>>>>>>>> to hear)
>>>>>>>>>>
>>>>>>>>>> 6) A package private method in SwingUtilities has been added
>>>>>>>>>> that helps
>>>>>>>>>> JPopupMenu and ToolTipManager to find the correct popup location.
>>>>>>>>>> JPopupMenu and ToolTipManager have been changed to use this new
>>>>>>>>>> method
>>>>>>>>>> in their calculations.
>>>>>>>>>>
>>>>>>>>>> 7) Two jtreg tests have been added.
>>>>>>>>>>
>>>>>>>>>> Looking forward for comments.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Piet
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
> 




From damjan.jov at gmail.com  Fri Feb 12 00:36:14 2010
From: damjan.jov at gmail.com (Damjan Jovanovic)
Date: Fri, 12 Feb 2010 10:36:14 +0200
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: 	first patch
In-Reply-To: <6fbbec31002110324v97c55a8v792eb4af2d413d8d@mail.gmail.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<4B5EFD4F.6030104@sun.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
	<4B72BCFE.5050005@Sun.com>
	<6fbbec31002101035s51d984c8t9b441272c0128ae5@mail.gmail.com>
	<4B73DB40.2050804@Sun.com>
	<9e89675b1002110300j29a0a35ck8b20875066f35aa@mail.gmail.com>
	<6fbbec31002110324v97c55a8v792eb4af2d413d8d@mail.gmail.com>
Message-ID: <9e89675b1002120036y798f8b66waa34c6d67a580edd@mail.gmail.com>

On Thu, Feb 11, 2010 at 1:24 PM, Costantino Cerbo <c.cerbo at gmail.com> wrote:
> Hi Peter, Hi Damjan
>
> 2010/2/11 Damjan Jovanovic <damjan.jov at gmail.com>:
>> Hi Peter
>>
>> Your patch causes a native assertion error upon clicking "Save":
>>
>> $ java sun.awt.X11.FileDialogTest
>> java: ../../src/xcb_io.c:242: process_responses: Assertion `(((long)
>> (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
>> Aborted
>>
>> Clicking "Open" either silently exits or indefinitely hangs (no
>> redraw) both the file dialog and the Java window.
>
> Yes, using a new Thread with the GTK L&F causes the same problem also
> on my system (Fedora 12).
> Without a new Thread it seems to work, but the EDT is of course blocked.
>
> I think we should investigate how we initialise the GTK multithreaded system.

While testing without Peter's change I got a JVM crash from
FileDialogTest in "C  [libmC  [libmawt.so+0x3e992]
Java_com_sun_java_swing_plaf_gtk_GTKStyle_nativeGetColorForState+0x32".
This error is reproducible by opening and closing a file dialog twice.

Now with Peter's change, reproducing the hung GUI situation and
sending Java signal 3 gives an all threads stack trace that doesn't
seem particularly useful, since it doesn't trace into native code.

Tracing with gdb is equally doomed, since setting a breakpoint on
"assert" causes the entire X11 server to hang until Java is killed
;-).

But since the assertion error happens in xcb, and Java doesn't link to
libxcb while ldd shows that libgtk-x11 definitely does, it's safe to
conclude the assertion is caused by GTK itself.

strace shows 2 X11 sockets are opened during Java's execution, so
hopefully Java and GTK use different X11 sockets and don't interfere
with each other this way.

That only leaves Java's usage of GTK as a suspect.

The multithreading rule for GTK is "simply" gdk_threads_enter() before
and gdk_threads_leave() after every call to GTK. You've added those
for some (probably not enough) of the file dialog code, but the rest
of Java's GTK code doesn't do it, so when Peter's patch starts calling
into GTK from 2 threads and 1 of them isn't locking, things go very
bad, rapidly. See
http://www.cairographics.org/threaded_animation_with_cairo/ and
http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness.html
for details. There was another example I found earlier that does
exactly what Java does (gtk_init and gtk_main in different threads),
but I can't find it now.

Anyway what happens when gdk_threads_init() and gdk_threads_leave()
are added everywhere?

Firstly Java hangs on startup. Luckily this time gdb's "thread apply
all bt" does work, and shows that the problem is caused by
gdk_threads_enter()/leave() not being reentrant, so
gtk2_init_painting() takes the lock and calls init_containers() which
also tries to take the lock -> deadlock. Unluckily there's a lot of
functions in gtk2_interface.c that call each other; setting up locking
to avoid reentrance would be a pain.

On http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness.html
we read that while GDK locks are not reentrant, they can be safely
replaced by locks that are reentrant, and the java-gnome library
successfully does just that. Unfortunately for us
gdk_threads_set_lock_functions() only exists since GDK 2.4 -> no go.

So, after much hacking, when finally GTK calls are made thread-safe
and avoid gdk lock reentrance AFAICT, the dialog displays, the Java
GUI remains redrawable, and there's no crash. Unfortunately the dialog
won't close (it keeps coming back when you click Cancel) but that's a
different bug ;-).

My patch for all these changes is based on your latest one and include
Peter's (hackish?) patch. It's attached.

Otherwise, your patch lacks error checking (eg. in calls to
GetJavaVM() and NewStringUTF()), has typos in comments, and relies on
C99 features like C++ style comments and variable declarations in the
middle of a code block (do we allow those in Java?). In
sun_awt_X11_GtkFileDialogPeer.c you name the function "quit" and
document it as "hide"; similarly for "show" and "run". I am not
convinced I got all the GTK calls to be thread safe, so please audit
the code very carefully, and my locking could be a bit too fine
grained and impact the GTK LAF drawing performance.

> Regards,
> Costantino
>

Regards
Damjan
-------------- next part --------------
diff -r 66c193082586 make/sun/xawt/FILES_c_unix.gmk
--- a/make/sun/xawt/FILES_c_unix.gmk	Mon Feb 08 17:02:43 2010 +0300
+++ b/make/sun/xawt/FILES_c_unix.gmk	Fri Feb 12 10:30:40 2010 +0200
@@ -79,4 +79,5 @@
 	gtk2_interface.c \
         swing_GTKEngine.c \
         swing_GTKStyle.c \
-        rect.c
+        rect.c \
+	sun_awt_X11_GtkFileDialogPeer.c
diff -r 66c193082586 make/sun/xawt/FILES_export_unix.gmk
--- a/make/sun/xawt/FILES_export_unix.gmk	Mon Feb 08 17:02:43 2010 +0300
+++ b/make/sun/xawt/FILES_export_unix.gmk	Fri Feb 12 10:30:40 2010 +0200
@@ -33,4 +33,5 @@
       sun/awt/X11/XDesktopPeer.java \
       sun/awt/X11/XToolkit.java \
       sun/awt/X11/XComponentPeer.java \
-      sun/awt/X11/XInputMethod.java
+      sun/awt/X11/XInputMethod.java \
+      sun/awt/X11/GtkFileDialogPeer.java
diff -r 66c193082586 make/sun/xawt/mapfile-vers
--- a/make/sun/xawt/mapfile-vers	Mon Feb 08 17:02:43 2010 +0300
+++ b/make/sun/xawt/mapfile-vers	Fri Feb 12 10:30:40 2010 +0200
@@ -172,6 +172,7 @@
         Java_sun_awt_UNIXToolkit_load_1stock_1icon;
         Java_sun_awt_UNIXToolkit_load_1gtk_1icon;
         Java_sun_awt_UNIXToolkit_nativeSync;
+        Java_sun_awt_UNIXToolkit_gtkCheckVersionImpl;
         Java_java_awt_AWTEvent_initIDs;
         Java_java_awt_event_InputEvent_initIDs;
         Java_java_awt_event_KeyEvent_initIDs;
@@ -396,6 +397,9 @@
         Java_com_sun_java_swing_plaf_gtk_GTKStyle_nativeGetClassValue;
         Java_com_sun_java_swing_plaf_gtk_GTKStyle_nativeGetPangoFontName;
 
+	Java_sun_awt_X11_GtkFileDialogPeer_run;
+	Java_sun_awt_X11_GtkFileDialogPeer_quit;
+
 	Java_sun_print_CUPSPrinter_initIDs;
 	Java_sun_print_CUPSPrinter_getCupsServer;
 	Java_sun_print_CUPSPrinter_getCupsPort;
diff -r 66c193082586 src/solaris/classes/sun/awt/UNIXToolkit.java
--- a/src/solaris/classes/sun/awt/UNIXToolkit.java	Mon Feb 08 17:02:43 2010 +0300
+++ b/src/solaris/classes/sun/awt/UNIXToolkit.java	Fri Feb 12 10:30:40 2010 +0200
@@ -314,4 +314,27 @@
         }
         return new RenderingHints(KEY_TEXT_ANTIALIASING, aaHint);
     }
+    
+    private native boolean gtkCheckVersionImpl(int major, int minor, 
+    		int micro);
+    
+	/**
+	 * Returns {@code true} if the GTK+ library is compatible with the given
+	 * version.
+	 * 
+	 * @param major
+	 *            The required major version.
+	 * @param minor
+	 *            The required minor version.
+	 * @param micro
+	 *            The required micro version.
+	 * @return {@code true} if the GTK+ library is compatible with the given
+	 *         version.
+	 */
+	public boolean checkGtkVersion(int major, int minor, int micro) {
+		if(loadGTK()) {
+			return gtkCheckVersionImpl(major, minor, micro);
+		}
+		return false;
+	}
 }
diff -r 66c193082586 src/solaris/classes/sun/awt/X11/XToolkit.java
--- a/src/solaris/classes/sun/awt/X11/XToolkit.java	Mon Feb 08 17:02:43 2010 +0300
+++ b/src/solaris/classes/sun/awt/X11/XToolkit.java	Fri Feb 12 10:30:40 2010 +0200
@@ -1041,7 +1041,9 @@
     }
 
     public FileDialogPeer createFileDialog(FileDialog target) {
-        FileDialogPeer peer = new XFileDialogPeer(target);
+        // The current GtkFileChooser is available from GTK+ 2.4
+        FileDialogPeer peer = checkGtkVersion(2, 4, 0) ? new GtkFileDialogPeer(
+                target) : new XFileDialogPeer(target);
         targetCreatedPeer(target, peer);
         return peer;
     }
diff -r 66c193082586 src/solaris/native/sun/awt/awt_UNIXToolkit.c
--- a/src/solaris/native/sun/awt/awt_UNIXToolkit.c	Mon Feb 08 17:02:43 2010 +0300
+++ b/src/solaris/native/sun/awt/awt_UNIXToolkit.c	Fri Feb 12 10:30:40 2010 +0200
@@ -154,7 +154,9 @@
         return JNI_FALSE;
     }
     (*env)->GetStringUTFRegion(env, filename, 0, len, filename_str);
+    fp_gdk_threads_enter();
     pixbuf = (*fp_gdk_pixbuf_new_from_file)(filename_str, error);
+    fp_gdk_threads_leave();
 
     /* Release the strings we've allocated. */
     free(filename_str);
@@ -208,8 +210,10 @@
         (*env)->GetStringUTFRegion(env, detail, 0, len, detail_str);
     }
 
+    fp_gdk_threads_enter();
     pixbuf = gtk2_get_stock_icon(widget_type, stock_id_str, icon_size,
                                  text_direction, detail_str);
+    fp_gdk_threads_leave();
 
     /* Release the strings we've allocated. */
     free(stock_id_str);
@@ -260,3 +264,21 @@
     }
     dlclose(hSplashLib);
 }
+
+/*
+ * Class:     sun_awt_UNIXToolkit
+ * Method:    gtkCheckVersionImpl
+ * Signature: (III)Ljava/lang/String;
+ */
+JNIEXPORT jboolean JNICALL
+Java_sun_awt_UNIXToolkit_gtkCheckVersionImpl
+  (JNIEnv *env, jobject this, jint major, jint minor, jint micro)
+{
+	char *ret = fp_gtk_check_version(major, minor, micro);
+	if (ret == NULL) {
+		return TRUE;
+	}
+
+	free(ret);
+	return FALSE;
+}
diff -r 66c193082586 src/solaris/native/sun/awt/gtk2_interface.c
--- a/src/solaris/native/sun/awt/gtk2_interface.c	Mon Feb 08 17:02:43 2010 +0300
+++ b/src/solaris/native/sun/awt/gtk2_interface.c	Fri Feb 12 10:30:40 2010 +0200
@@ -32,6 +32,7 @@
 #include "java_awt_Transparency.h"
 
 #define GTK2_LIB "libgtk-x11-2.0.so.0"
+#define GTHREAD_LIB "libgthread-2.0.so"
 
 #define G_TYPE_INVALID                  G_TYPE_MAKE_FUNDAMENTAL (0)
 #define G_TYPE_NONE                     G_TYPE_MAKE_FUNDAMENTAL (1)
@@ -75,6 +76,7 @@
 const gint DEFAULT    = 1 << 10;
 
 static void *gtk2_libhandle = NULL;
+static void *gthread_libhandle = NULL;
 static jmp_buf j;
 
 /* Widgets */
@@ -150,7 +152,6 @@
 /*************************
  * Glib function pointers
  *************************/
-static void     (*fp_g_free)(gpointer mem);
 
 static gboolean (*fp_g_main_context_iteration)(GMainContext *context,
                                              gboolean may_block);
@@ -204,9 +205,6 @@
 /************************
  * Gtk function pointers
  ************************/
-static gchar*   (*fp_gtk_check_version)(guint required_major,
-                                        guint required_minor,
-                                        guint required_micro);
 static gboolean (*fp_gtk_init_check)(int* argc, char** argv);
 
 /* Painting */
@@ -330,7 +328,6 @@
 static void (*fp_gtk_menu_item_set_submenu)(GtkMenuItem *menu_item,
         GtkWidget *submenu);
 static void (*fp_gtk_widget_realize)(GtkWidget *widget);
-static void (*fp_gtk_widget_destroy)(GtkWidget *widget);
 static GdkPixbuf* (*fp_gtk_widget_render_icon)(GtkWidget *widget,
         const gchar *stock_id, GtkIconSize size, const gchar *detail);
 static void (*fp_gtk_widget_set_name)(GtkWidget *widget, const gchar *name);
@@ -388,6 +385,15 @@
     return result;
 }
 
+static void* dl_symbol_gthread(const char* name)
+{
+    void* result = dlsym(gthread_libhandle, name);
+    if (!result)
+        longjmp(j, NO_SYMBOL_EXCEPTION);
+
+    return result;
+}
+
 gboolean gtk2_check_version()
 {
     if (gtk2_libhandle != NULL) {
@@ -414,6 +420,26 @@
     }
 }
 
+/**
+ * Functions for sun_awt_X11_GtkFileDialogPeer.c
+ */
+void gtk2_file_chooser_load()
+{
+	fp_gtk_file_chooser_get_filename = dl_symbol(
+			"gtk_file_chooser_get_filename");
+	fp_gtk_file_chooser_dialog_new = dl_symbol("gtk_file_chooser_dialog_new");
+	fp_gtk_file_chooser_set_current_folder = dl_symbol(
+			"gtk_file_chooser_set_current_folder");
+	fp_gtk_file_chooser_set_filename = dl_symbol(
+			"gtk_file_chooser_set_filename");
+	fp_gtk_file_filter_add_custom = dl_symbol("gtk_file_filter_add_custom");
+	fp_gtk_file_chooser_set_filter = dl_symbol("gtk_file_chooser_set_filter");
+	fp_gtk_file_chooser_get_type = dl_symbol("gtk_file_chooser_get_type");
+	fp_gtk_file_filter_new = dl_symbol("gtk_file_filter_new");
+	fp_gtk_file_chooser_set_do_overwrite_confirmation = dl_symbol(
+			"gtk_file_chooser_set_do_overwrite_confirmation");
+}
+
 gboolean gtk2_load()
 {
     gboolean result;
@@ -423,7 +449,9 @@
     char *gtk_modules_env;
 
     gtk2_libhandle = dlopen(GTK2_LIB, RTLD_LAZY | RTLD_LOCAL);
-    if (gtk2_libhandle == NULL)
+    gthread_libhandle = dlopen(GTHREAD_LIB, RTLD_LAZY | RTLD_LOCAL);
+
+    if (gtk2_libhandle == NULL || gthread_libhandle == NULL)
         return FALSE;
 
     if (setjmp(j) == 0)
@@ -597,6 +625,29 @@
         fp_gtk_range_get_adjustment =
             dl_symbol("gtk_range_get_adjustment");
 
+    	fp_gtk_widget_hide = dl_symbol("gtk_widget_hide");
+    	fp_gtk_main_quit = dl_symbol("gtk_main_quit");
+    	fp_g_signal_connect_data = dl_symbol("g_signal_connect_data");
+    	fp_gtk_widget_show = dl_symbol("gtk_widget_show");
+    	fp_gtk_main = dl_symbol("gtk_main");
+
+    	/**
+    	 * GLib thread system
+    	 */
+    	fp_g_thread_get_initialized = dl_symbol_gthread("g_thread_get_initialized");
+    	fp_g_thread_init = dl_symbol_gthread("g_thread_init");
+    	fp_gdk_threads_init = dl_symbol("gdk_threads_init");
+    	fp_gdk_threads_enter = dl_symbol("gdk_threads_enter");
+    	fp_gdk_threads_leave = dl_symbol("gdk_threads_leave");
+
+        /**
+         * Functions for sun_awt_X11_GtkFileDialogPeer.c
+         */
+    	if (fp_gtk_check_version(2, 4, 0) == NULL) {
+    		// The current GtkFileChooser is available from GTK+ 2.4
+    		gtk2_file_chooser_load();
+    	}
+
         /* Some functions may be missing in pre-2.4 GTK.
            We handle them specially here.
          */
@@ -626,6 +677,10 @@
     {
         dlclose(gtk2_libhandle);
         gtk2_libhandle = NULL;
+
+        dlclose(gthread_libhandle);
+        gthread_libhandle = NULL;
+        
         return FALSE;
     }
 
@@ -678,6 +733,19 @@
     */
     handler = XSetErrorHandler(NULL);
     io_handler = XSetIOErrorHandler(NULL);
+
+    if (fp_gtk_check_version(2, 2, 0) == NULL)
+    {
+    	// Init the thread system to use GLib in a thread-safe mode
+    	if (!fp_g_thread_get_initialized())
+    	{
+    		fp_g_thread_init(NULL);
+
+    		//According the GTK documentation, gdk_threads_init() should be
+    		//called before gtk_init() or gtk_init_check()
+    		fp_gdk_threads_init();
+    	}
+    }
     result = (*fp_gtk_init_check)(NULL, NULL);
 
     XSetErrorHandler(handler);
@@ -722,6 +790,7 @@
 
     dlerror();
     dlclose(gtk2_libhandle);
+    dlclose(gthread_libhandle);
     if ((gtk2_error = dlerror()) != NULL)
     {
         return FALSE;
diff -r 66c193082586 src/solaris/native/sun/awt/gtk2_interface.h
--- a/src/solaris/native/sun/awt/gtk2_interface.h	Mon Feb 08 17:02:43 2010 +0300
+++ b/src/solaris/native/sun/awt/gtk2_interface.h	Fri Feb 12 10:30:40 2010 +0200
@@ -28,6 +28,21 @@
 #include <stdlib.h>
 #include <jni.h>
 
+#define _G_TYPE_CIC(ip, gt, ct)       ((ct*) ip)
+#define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
+#define GTK_TYPE_FILE_CHOOSER             (fp_gtk_file_chooser_get_type ())
+#define GTK_FILE_CHOOSER(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), GTK_TYPE_FILE_CHOOSER, GtkFileChooser))
+#define fp_g_signal_connect(instance, detailed_signal, c_handler, data) \
+    fp_g_signal_connect_data ((instance), (detailed_signal), (c_handler), (data), NULL, (GConnectFlags) 0)
+#define	G_CALLBACK(f) ((GCallback) (f))
+#define	G_TYPE_FUNDAMENTAL_SHIFT	(2)
+#define	G_TYPE_MAKE_FUNDAMENTAL(x)	((GType) ((x) << G_TYPE_FUNDAMENTAL_SHIFT))
+#define G_TYPE_OBJECT G_TYPE_MAKE_FUNDAMENTAL (20)
+#define G_OBJECT(object) (G_TYPE_CHECK_INSTANCE_CAST ((object), G_TYPE_OBJECT, GObject))
+#define GTK_STOCK_CANCEL           "gtk-cancel"
+#define GTK_STOCK_SAVE             "gtk-save"
+#define GTK_STOCK_OPEN             "gtk-open"
+
 typedef enum _WidgetType
 {
     BUTTON,                     /* GtkButton */
@@ -556,6 +571,66 @@
   guint ellipsize : 3;
 };
 
+typedef enum {
+	GTK_RESPONSE_NONE = -1,
+	GTK_RESPONSE_REJECT = -2,
+	GTK_RESPONSE_ACCEPT = -3,
+	GTK_RESPONSE_DELETE_EVENT = -4,
+	GTK_RESPONSE_OK = -5,
+	GTK_RESPONSE_CANCEL = -6,
+	GTK_RESPONSE_CLOSE = -7,
+	GTK_RESPONSE_YES = -8,
+	GTK_RESPONSE_NO = -9,
+	GTK_RESPONSE_APPLY = -10,
+	GTK_RESPONSE_HELP = -11
+} GtkResponseType;
+
+typedef struct _GtkWindow GtkWindow;
+
+typedef struct _GtkFileChooser GtkFileChooser;
+
+typedef enum {
+	GTK_FILE_CHOOSER_ACTION_OPEN,
+	GTK_FILE_CHOOSER_ACTION_SAVE,
+	GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER,
+	GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER
+} GtkFileChooserAction;
+
+typedef struct _GtkFileFilter GtkFileFilter;
+
+typedef enum {
+	GTK_FILE_FILTER_FILENAME = 1 << 0,
+	GTK_FILE_FILTER_URI = 1 << 1,
+	GTK_FILE_FILTER_DISPLAY_NAME = 1 << 2,
+	GTK_FILE_FILTER_MIME_TYPE = 1 << 3
+} GtkFileFilterFlags;
+
+typedef struct {
+	GtkFileFilterFlags contains;
+
+	const gchar *filename;
+	const gchar *uri;
+	const gchar *display_name;
+	const gchar *mime_type;
+} GtkFileFilterInfo;
+
+typedef gboolean (*GtkFileFilterFunc)(const GtkFileFilterInfo *filter_info,
+		gpointer data);
+
+typedef void (*GDestroyNotify)(gpointer data);
+
+typedef void (*GCallback)(void);
+
+typedef struct _GClosure GClosure;
+
+typedef void (*GClosureNotify)(gpointer data, GClosure *closure);
+
+typedef enum {
+	G_CONNECT_AFTER = 1 << 0, G_CONNECT_SWAPPED = 1 << 1
+} GConnectFlags;
+
+typedef struct _GThreadFunctions GThreadFunctions;
+
 /*
  * Converts java.lang.String object to UTF-8 character string.
  */
@@ -569,6 +644,13 @@
  */
 gboolean gtk2_check_version();
 
+/**
+ * Returns :
+ *	NULL if the GTK+ library is compatible with the given version, or a string
+ *	describing the version mismatch.
+ */
+gchar* (*fp_gtk_check_version)(guint required_major, guint required_minor,
+		                       guint required_micro);
 /*
  * Load the gtk2 library.  If the library is already loaded this method has no
  * effect and returns success.
@@ -651,6 +733,7 @@
 void gtk2_set_range_value(WidgetType widget_type, jdouble value,
                           jdouble min, jdouble max, jdouble visible);
 
+void (*fp_g_free)(gpointer mem);
 void (*fp_g_object_unref)(gpointer object);
 int (*fp_gdk_pixbuf_get_bits_per_sample)(const GdkPixbuf *pixbuf);
 guchar *(*fp_gdk_pixbuf_get_pixels)(const GdkPixbuf *pixbuf);
@@ -660,5 +743,41 @@
 int (*fp_gdk_pixbuf_get_rowstride)(const GdkPixbuf *pixbuf);
 int (*fp_gdk_pixbuf_get_width)(const GdkPixbuf *pixbuf);
 GdkPixbuf *(*fp_gdk_pixbuf_new_from_file)(const char *filename, GError **error);
+void (*fp_gtk_widget_destroy)(GtkWidget *widget);
+
+
+/**
+ * Function Pointers for GtkFileChooser
+ */
+gchar* (*fp_gtk_file_chooser_get_filename)(GtkFileChooser *chooser);
+void (*fp_gtk_widget_hide)(GtkWidget *widget);
+void (*fp_gtk_main_quit)(void);
+GtkWidget* (*fp_gtk_file_chooser_dialog_new)(const gchar *title,
+		GtkWindow *parent, GtkFileChooserAction action,
+		const gchar *first_button_text, ...);
+gboolean (*fp_gtk_file_chooser_set_current_folder)(GtkFileChooser *chooser,
+		const gchar *filename);
+gboolean (*fp_gtk_file_chooser_set_filename)(GtkFileChooser *chooser,
+		const char *filename);
+void (*fp_gtk_file_filter_add_custom)(GtkFileFilter *filter,
+		GtkFileFilterFlags needed, GtkFileFilterFunc func, gpointer data,
+		GDestroyNotify notify);
+void (*fp_gtk_file_chooser_set_filter)(GtkFileChooser *chooser,
+		GtkFileFilter *filter);
+GType (*fp_gtk_file_chooser_get_type)(void);
+GtkFileFilter* (*fp_gtk_file_filter_new)(void);
+void (*fp_gtk_file_chooser_set_do_overwrite_confirmation)(
+		GtkFileChooser *chooser, gboolean do_overwrite_confirmation);
+gulong (*fp_g_signal_connect_data)(gpointer instance,
+		const gchar *detailed_signal, GCallback c_handler, gpointer data,
+		GClosureNotify destroy_data, GConnectFlags connect_flags);
+void (*fp_gtk_widget_show)(GtkWidget *widget);
+void (*fp_gtk_main)(void);
+
+gboolean (*fp_g_thread_get_initialized)(void);
+void (*fp_g_thread_init)(GThreadFunctions *vtable);
+void (*fp_gdk_threads_init)(void);
+void (*fp_gdk_threads_enter)(void);
+void (*fp_gdk_threads_leave)(void);
 
 #endif /* !_GTK2_INTERFACE_H */
diff -r 66c193082586 src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c	Fri Feb 12 10:30:40 2010 +0200
@@ -0,0 +1,138 @@
+#include <jni.h>
+#include <stdio.h>
+#include "gtk2_interface.h"
+#include "sun_awt_X11_GtkFileDialogPeer.h"
+
+static JavaVM *jvm;
+static GtkWidget *dialog = NULL;
+
+// In order to Cache some method IDs
+static jmethodID filenameFilterCallbackMethodID = NULL;
+static jmethodID setFileInternalMethodID = NULL;
+
+static gboolean filenameFilterCallback(const GtkFileFilterInfo * filter_info,
+		gpointer obj)
+{
+	JNIEnv *env = (JNIEnv *) JNU_GetEnv(jvm, JNI_VERSION_1_2);
+
+	if (filenameFilterCallbackMethodID == NULL) {
+		jclass cx = (*env)->GetObjectClass(env, (jobject) obj);
+		filenameFilterCallbackMethodID = (*env)->GetMethodID(env, cx,
+				"filenameFilterCallback", "(Ljava/lang/String;)Z");
+	}
+
+	jstring filename = (*env)->NewStringUTF(env, filter_info->filename);
+
+	return (*env)->CallBooleanMethod(env, obj, filenameFilterCallbackMethodID,
+			filename);
+}
+
+/*
+ * Class:     sun_awt_X11_GtkFileDialogPeer
+ * Method:    hide
+ * Signature: ()V
+ */
+JNIEXPORT void JNICALL Java_sun_awt_X11_GtkFileDialogPeer_quit
+(JNIEnv * env, jobject jpeer)
+{
+	if (dialog != NULL)
+	{
+		fp_gtk_widget_hide (dialog);
+		fp_gtk_widget_destroy (dialog);
+
+		fp_gtk_main_quit ();
+		dialog = NULL;
+	}
+}
+
+static void handle_response(GtkWidget * aDialog, gint responseId, gpointer obj)
+{
+	JNIEnv *env = (JNIEnv *) JNU_GetEnv(jvm, JNI_VERSION_1_2);
+
+	char *filename = NULL;
+
+	if (responseId == GTK_RESPONSE_ACCEPT) {
+		filename = fp_gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(aDialog));
+	}
+
+	if (setFileInternalMethodID == NULL) {
+		jclass cx = (*env)->GetObjectClass(env, (jobject) obj);
+		setFileInternalMethodID = (*env)->GetMethodID(env, cx,
+				"setFileInternal", "(Ljava/lang/String;)V");
+	}
+
+	jstring jfilename = (*env)->NewStringUTF(env, filename);
+
+	(*env)->CallVoidMethod(env, obj, setFileInternalMethodID, jfilename);
+	fp_g_free(filename);
+
+	Java_sun_awt_X11_GtkFileDialogPeer_quit(NULL, NULL);
+}
+
+/*
+ * Class:     sun_awt_X11_GtkFileDialogPeer
+ * Method:    show
+ * Signature: (Ljava/lang/String;ILjava/lang/String;Ljava/lang/String;Ljava/io/FilenameFilter;)V
+ */
+JNIEXPORT void JNICALL
+Java_sun_awt_X11_GtkFileDialogPeer_run(JNIEnv * env, jobject jpeer,
+		jstring jtitle, jint mode, jstring jdir, jstring jfile, jobject jfilter)
+{
+	if (jvm == NULL) {
+		(*env)->GetJavaVM(env, &jvm);
+	}
+
+	const char *title = (*env)->GetStringUTFChars(env, jtitle, 0);
+
+	fp_gdk_threads_enter();
+
+	if (mode == 1) {
+		// Save action
+		dialog = fp_gtk_file_chooser_dialog_new(title, NULL,
+				GTK_FILE_CHOOSER_ACTION_SAVE, GTK_STOCK_CANCEL,
+				GTK_RESPONSE_CANCEL, GTK_STOCK_SAVE, GTK_RESPONSE_ACCEPT, NULL);
+	} else {
+		// Default action OPEN
+		dialog = fp_gtk_file_chooser_dialog_new(title, NULL,
+				GTK_FILE_CHOOSER_ACTION_OPEN, GTK_STOCK_CANCEL,
+				GTK_RESPONSE_CANCEL, GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT, NULL);
+	}
+
+	(*env)->ReleaseStringUTFChars(env, jtitle, title);
+
+	// Set the directory
+	if (jdir != NULL) {
+		const char *dir = (*env)->GetStringUTFChars(env, jdir, 0);
+		fp_gtk_file_chooser_set_current_folder(GTK_FILE_CHOOSER(dialog), dir);
+		(*env)->ReleaseStringUTFChars(env, jdir, dir);
+	}
+
+	// Set the filename
+	if (jfile != NULL) {
+		const char *filename = (*env)->GetStringUTFChars(env, jfile, 0);
+		fp_gtk_file_chooser_set_filename(GTK_FILE_CHOOSER(dialog), filename);
+		(*env)->ReleaseStringUTFChars(env, jfile, filename);
+	}
+
+	// Set the file filter
+	if (jfilter != NULL) {
+		GtkFileFilter *filter;
+		filter = fp_gtk_file_filter_new();
+		fp_gtk_file_filter_add_custom(filter, GTK_FILE_FILTER_FILENAME,
+				filenameFilterCallback, jpeer, NULL);
+		fp_gtk_file_chooser_set_filter(GTK_FILE_CHOOSER(dialog), filter);
+	}
+
+	//Other Properties
+	if (fp_gtk_check_version(2, 8, 0) == NULL) {
+		fp_gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(
+				dialog), TRUE);
+	}
+
+	fp_g_signal_connect(G_OBJECT(dialog), "response", G_CALLBACK(
+			handle_response), jpeer);
+	fp_gtk_widget_show(dialog);
+
+	fp_gtk_main();
+	fp_gdk_threads_leave();
+}
diff -r 66c193082586 src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.h	Fri Feb 12 10:30:40 2010 +0200
@@ -0,0 +1,31 @@
+/* DO NOT EDIT THIS FILE - it is machine generated */
+#include <jni.h>
+/* Header for class sun_awt_X11_GtkFileDialogPeer */
+
+#ifndef _Included_sun_awt_X11_GtkFileDialogPeer
+#define _Included_sun_awt_X11_GtkFileDialogPeer
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+
+/*
+ * Class:     sun_awt_X11_GtkFileDialogPeer
+ * Method:    run
+ * Signature: (Ljava/lang/String;ILjava/lang/String;Ljava/lang/String;Ljava/io/FilenameFilter;)V
+ */
+JNIEXPORT void JNICALL Java_sun_awt_X11_GtkFileDialogPeer_run
+  (JNIEnv *, jobject, jstring, jint, jstring, jstring, jobject);
+
+/*
+ * Class:     sun_awt_X11_GtkFileDialogPeer
+ * Method:    quit
+ * Signature: ()V
+ */
+JNIEXPORT void JNICALL Java_sun_awt_X11_GtkFileDialogPeer_quit
+  (JNIEnv *, jobject);
+
+#ifdef __cplusplus
+}
+#endif
+#endif
diff -r 66c193082586 src/solaris/native/sun/awt/swing_GTKEngine.c
--- a/src/solaris/native/sun/awt/swing_GTKEngine.c	Mon Feb 08 17:02:43 2010 +0300
+++ b/src/solaris/native/sun/awt/swing_GTKEngine.c	Fri Feb 12 10:30:40 2010 +0200
@@ -38,8 +38,10 @@
         jint widget_type, jint state, jint shadow_type, jstring detail,
         jint x, jint y, jint w, jint h, jint arrow_type)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_arrow(widget_type, state, shadow_type, getStrFor(env, detail),
             x, y, w, h, arrow_type, TRUE);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -54,8 +56,10 @@
         jint x, jint y, jint w, jint h,
         jint synth_state, jint dir)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_box(widget_type, state, shadow_type, getStrFor(env, detail),
                    x, y, w, h, synth_state, dir);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -70,8 +74,10 @@
         jint x, jint y, jint w, jint h,
         jint gap_side, jint gap_x, jint gap_w)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_box_gap(widget_type, state, shadow_type, getStrFor(env, detail),
             x, y, w, h, gap_side, gap_x, gap_w);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -85,8 +91,10 @@
         jint widget_type, jint synth_state, jstring detail,
         jint x, jint y, jint w, jint h)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_check(widget_type, synth_state, getStrFor(env, detail),
                      x, y, w, h);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -100,8 +108,10 @@
         jint widget_type, jint state, jstring detail,
         jint x, jint y, jint w, jint h, jint expander_style)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_expander(widget_type, state, getStrFor(env, detail),
             x, y, w, h, expander_style);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -115,8 +125,10 @@
         jint widget_type, jint state, jint shadow_type, jstring detail,
         jint x, jint y, jint w, jint h, jint placement)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_extension(widget_type, state, shadow_type,
             getStrFor(env, detail), x, y, w, h, placement);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -130,8 +142,10 @@
         jint widget_type, jint state, jint shadow_type, jstring detail,
         jint x, jint y, jint w, jint h, jboolean has_focus)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_flat_box(widget_type, state, shadow_type,
             getStrFor(env, detail), x, y, w, h, has_focus);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -145,8 +159,10 @@
         jint widget_type, jint state, jstring detail,
         jint x, jint y, jint w, jint h)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_focus(widget_type, state, getStrFor(env, detail),
             x, y, w, h);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -160,8 +176,10 @@
         jint widget_type, jint state, jint shadow_type, jstring detail,
         jint x, jint y, jint w, jint h, jint orientation)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_handle(widget_type, state, shadow_type, getStrFor(env, detail),
             x, y, w, h, orientation);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -175,8 +193,10 @@
         jint widget_type, jint state, jstring detail,
         jint x, jint y, jint w, jint h)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_hline(widget_type, state, getStrFor(env, detail),
             x, y, w, h);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -190,8 +210,10 @@
         jint widget_type, jint synth_state, jstring detail,
         jint x, jint y, jint w, jint h)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_option(widget_type, synth_state, getStrFor(env, detail),
                       x, y, w, h);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -206,8 +228,10 @@
         jint x, jint y, jint w, jint h,
         jint synth_state, jint dir)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_shadow(widget_type, state, shadow_type, getStrFor(env, detail),
                       x, y, w, h, synth_state, dir);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -221,8 +245,10 @@
         jint widget_type, jint state, jint shadow_type, jstring detail,
         jint x, jint y, jint w, jint h, jint orientation)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_slider(widget_type, state, shadow_type, getStrFor(env, detail),
             x, y, w, h, orientation);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -236,8 +262,10 @@
         jint widget_type, jint state, jstring detail,
         jint x, jint y, jint w, jint h)
 {
+    fp_gdk_threads_enter();
     gtk2_paint_vline(widget_type, state, getStrFor(env, detail),
             x, y, w, h);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -250,7 +278,9 @@
         JNIEnv *env, jobject this, jint widget_type, jint state,
         jint x, jint y, jint w, jint h)
 {
+    fp_gdk_threads_enter();
     gtk_paint_background(widget_type, state, x, y, w, h);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -262,7 +292,9 @@
 Java_com_sun_java_swing_plaf_gtk_GTKEngine_nativeStartPainting(
         JNIEnv *env, jobject this, jint w, jint h)
 {
+    fp_gdk_threads_enter();
     gtk2_init_painting(w, h);
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -276,7 +308,9 @@
 {
     jint transparency;
     gint *buffer = (gint*) (*env)->GetPrimitiveArrayCritical(env, dest, 0);
+    fp_gdk_threads_enter();
     transparency = gtk2_copy_image(buffer, width, height);
+    fp_gdk_threads_leave();
     (*env)->ReleasePrimitiveArrayCritical(env, dest, buffer, 0);
     return transparency;
 }
@@ -289,7 +323,9 @@
 JNIEXPORT void JNICALL Java_com_sun_java_swing_plaf_gtk_GTKEngine_native_1switch_1theme(
         JNIEnv *env, jobject this)
 {
+    fp_gdk_threads_enter();
     flush_gtk_event_loop();
+    fp_gdk_threads_leave();
 }
 
 /*
@@ -300,7 +336,11 @@
 JNIEXPORT jobject JNICALL Java_com_sun_java_swing_plaf_gtk_GTKEngine_native_1get_1gtk_1setting(
         JNIEnv *env, jobject this, jint property)
 {
-    return gtk2_get_setting(env, property);
+    jobject obj;
+    fp_gdk_threads_enter();
+    obj = gtk2_get_setting(env, property);
+    fp_gdk_threads_leave();
+    return obj;
 }
 
 /*
@@ -313,5 +353,7 @@
         JNIEnv *env, jobject this, jint widget_type,
         jdouble value, jdouble min, jdouble max, jdouble visible)
 {
+    fp_gdk_threads_enter();
     gtk2_set_range_value(widget_type, value, min, max, visible);
+    fp_gdk_threads_leave();
 }
diff -r 66c193082586 src/solaris/native/sun/awt/swing_GTKStyle.c
--- a/src/solaris/native/sun/awt/swing_GTKStyle.c	Mon Feb 08 17:02:43 2010 +0300
+++ b/src/solaris/native/sun/awt/swing_GTKStyle.c	Fri Feb 12 10:30:40 2010 +0200
@@ -36,7 +36,11 @@
 Java_com_sun_java_swing_plaf_gtk_GTKStyle_nativeGetXThickness(
     JNIEnv *env, jclass klass, jint widget_type)
 {
-    return gtk2_get_xthickness(env, widget_type);
+    jint ret;
+    fp_gdk_threads_enter();
+    ret = gtk2_get_xthickness(env, widget_type);
+    fp_gdk_threads_leave();
+    return ret;
 }
 
 /*
@@ -48,7 +52,11 @@
 Java_com_sun_java_swing_plaf_gtk_GTKStyle_nativeGetYThickness(
     JNIEnv *env, jclass klass, jint widget_type)
 {
-    return gtk2_get_ythickness(env, widget_type);
+    jint ret;
+    fp_gdk_threads_enter();
+    ret = gtk2_get_ythickness(env, widget_type);
+    fp_gdk_threads_leave();
+    return ret;
 }
 
 /*
@@ -61,7 +69,11 @@
     JNIEnv *env, jclass klass, jint widget_type,
     jint state_type, jint type_id)
 {
-    return gtk2_get_color_for_state(env, widget_type, state_type, type_id);
+    jint ret;
+    fp_gdk_threads_enter();
+    ret = gtk2_get_color_for_state(env, widget_type, state_type, type_id);
+    fp_gdk_threads_leave();
+    return ret;
 }
 
 /*
@@ -73,7 +85,11 @@
 Java_com_sun_java_swing_plaf_gtk_GTKStyle_nativeGetClassValue(
     JNIEnv *env, jclass klass, jint widget_type, jstring key)
 {
-    return gtk2_get_class_value(env, widget_type, key);
+    jobject ret;
+    fp_gdk_threads_enter();
+    ret = gtk2_get_class_value(env, widget_type, key);
+    fp_gdk_threads_leave();
+    return ret;
 }
 
 /*
@@ -85,5 +101,9 @@
 Java_com_sun_java_swing_plaf_gtk_GTKStyle_nativeGetPangoFontName(
     JNIEnv *env, jclass klass, jint widget_type)
 {
-    return gtk2_get_pango_font_name(env, widget_type);
+    jstring ret;
+    fp_gdk_threads_enter();
+    ret = gtk2_get_pango_font_name(env, widget_type);
+    fp_gdk_threads_leave();
+    return ret;
 }

From damjan.jov at gmail.com  Fri Feb 12 05:38:06 2010
From: damjan.jov at gmail.com (Damjan Jovanovic)
Date: Fri, 12 Feb 2010 15:38:06 +0200
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: 	first patch
In-Reply-To: <6fbbec31001271452h7aa5fb9fp5bd403569a5c3edd@mail.gmail.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<4B5734F9.5070806@sun.com> <4B583BD5.9080704@sun.com>
	<6fbbec31001211508v780986a7n936a8d20d182a3a9@mail.gmail.com>
	<4B59944C.2020903@sun.com>
	<6fbbec31001241126o62bcccf8u813f76902b6a8cd1@mail.gmail.com>
	<4B5D9CFA.5010502@sun.com>
	<6fbbec31001251417o2a49f02fr1fc2047993787e31@mail.gmail.com>
	<4B5EE991.3080505@Sun.com>
	<6fbbec31001271452h7aa5fb9fp5bd403569a5c3edd@mail.gmail.com>
Message-ID: <9e89675b1002120538o7abe3307gc376cc7f62239027@mail.gmail.com>

On Thu, Jan 28, 2010 at 12:52 AM, Costantino Cerbo <c.cerbo at gmail.com> wrote:
> Hi Peter,
>
> 2010/1/26 Peter Zhelezniakov <Peter.Zhelezniakov at sun.com>:
>> Note that JFileChooser has some bells and whistles like setAccessory() and
>> setFileSystemView(). We're going to have hard time making GTK paint the
>> right thing =) ?I'm not sure it is at all possible.
>
> I know... therefore I start this project to emulate the native GTK in Swing:
> http://code.google.com/p/gtkjfilechooser/
>
> Maybe the Awt and the Swing team may reconsider to adopt this solution
> in the next Java releases.
> As I already stated, I can fully donate the code to the OpenJDK
> project: consider it yours! ;-)

The GtkFileChooser seems fairly customizable: setAccessory() can be
implemented using gtk_file_chooser_set_preview_widget(), and the
filesystem view seems customizable too. You can also slot in custom
widgets (eg. an "Open read-only" checkbox).

Even if GtkFileChooser can't do something, you can embed
GtkFileChooserWidget into a larger window, and add any surrounding
widgets you like.

If you need help, let me know.

> Chreers,
> Costantino
>

Regards
Damjan


From c.cerbo at gmail.com  Fri Feb 12 07:04:13 2010
From: c.cerbo at gmail.com (Costantino Cerbo)
Date: Fri, 12 Feb 2010 16:04:13 +0100
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: 	first patch
In-Reply-To: <9e89675b1002120538o7abe3307gc376cc7f62239027@mail.gmail.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<4B583BD5.9080704@sun.com>
	<6fbbec31001211508v780986a7n936a8d20d182a3a9@mail.gmail.com>
	<4B59944C.2020903@sun.com>
	<6fbbec31001241126o62bcccf8u813f76902b6a8cd1@mail.gmail.com>
	<4B5D9CFA.5010502@sun.com>
	<6fbbec31001251417o2a49f02fr1fc2047993787e31@mail.gmail.com>
	<4B5EE991.3080505@Sun.com>
	<6fbbec31001271452h7aa5fb9fp5bd403569a5c3edd@mail.gmail.com>
	<9e89675b1002120538o7abe3307gc376cc7f62239027@mail.gmail.com>
Message-ID: <6fbbec31002120704n30580e59k386e5a4e555873d1@mail.gmail.com>

Hallo Damjan,

it would be great, if we could update the JFileChooser in the GTK L&F.
When I had more time I've tried to emulate it completly in swing
(without native code), but the awt & swing team didn't like this
approach.
Unfortunately I've now not so much time to start a new task from
scratch but I could support you by testing on Fedora, Suse and
Solaris.
There is already the issue 5090726 in the Sun Bug Database.

Cheers,
Costantino

P.S.: thanks a lot for your patch about the awt FileDialog: I'll test
it on monday.

2010/2/12 Damjan Jovanovic <damjan.jov at gmail.com>:
> On Thu, Jan 28, 2010 at 12:52 AM, Costantino Cerbo <c.cerbo at gmail.com> wrote:
>> Hi Peter,
>>
>> 2010/1/26 Peter Zhelezniakov <Peter.Zhelezniakov at sun.com>:
>>> Note that JFileChooser has some bells and whistles like setAccessory() and
>>> setFileSystemView(). We're going to have hard time making GTK paint the
>>> right thing =) ?I'm not sure it is at all possible.
>>
>> I know... therefore I start this project to emulate the native GTK in Swing:
>> http://code.google.com/p/gtkjfilechooser/
>>
>> Maybe the Awt and the Swing team may reconsider to adopt this solution
>> in the next Java releases.
>> As I already stated, I can fully donate the code to the OpenJDK
>> project: consider it yours! ;-)
>
> The GtkFileChooser seems fairly customizable: setAccessory() can be
> implemented using gtk_file_chooser_set_preview_widget(), and the
> filesystem view seems customizable too. You can also slot in custom
> widgets (eg. an "Open read-only" checkbox).
>
> Even if GtkFileChooser can't do something, you can embed
> GtkFileChooserWidget into a larger window, and add any surrounding
> widgets you like.
>
> If you need help, let me know.
>
>> Chreers,
>> Costantino
>>
>
> Regards
> Damjan
>


From dmitry.cherepanov at sun.com  Fri Feb 12 09:02:28 2010
From: dmitry.cherepanov at sun.com (dmitry.cherepanov at sun.com)
Date: Fri, 12 Feb 2010 17:02:28 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6705345: Enable multiple file selection
	in AWT	FileDialog
Message-ID: <20100212170248.437DE41D22@hg.openjdk.java.net>

Changeset: 2ba381560071
Author:    dcherepanov
Date:      2010-02-12 19:58 +0300
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/2ba381560071

6705345: Enable multiple file selection in AWT FileDialog
Reviewed-by: art, anthony, alexp

! src/share/classes/java/awt/FileDialog.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java
! src/windows/classes/sun/awt/windows/WFileDialogPeer.java
! src/windows/native/sun/windows/awt_FileDialog.cpp
! src/windows/native/sun/windows/awt_FileDialog.h
+ test/java/awt/FileDialog/MultipleMode/MultipleMode.html
+ test/java/awt/FileDialog/MultipleMode/MultipleMode.java



From Anthony.Petrov at Sun.COM  Fri Feb 12 09:06:08 2010
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Fri, 12 Feb 2010 20:06:08 +0300
Subject: <AWT Dev> <Swing Dev> Fw: review
	request	for6899434:Addaffinetransformsupport to JLayer
In-Reply-To: <7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
Message-ID: <4B758A80.3070101@sun.com>

Hi Piet,

The fix looks fine. Thanks.

--
best regards,
Anthony


On 02/12/2010 10:53 AM, Piet Blok wrote:
> 
> Hi Artem,
> 
> The webrev for version 3.1: 
> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
> 
> 
>> Hi, Piet,
>>
>> the 3rd version looks really great! I haven't looked to Swing code 
>> much, though :)
>>
>> A small suggestion is to unify getRenderedSpaceShift() and 
>> getLayoutSpaceShift(), so they both accept a Component and a Point to 
>> translate. Could they also be static methods? It seems not, as I see a 
>> reference to "nativeContainer" in getLayoutSpaceShift()...
> 
> I unified both methods and made them static after adding nativeContainer 
> as a parameter to both. Their signature is now:
> 
> private static Point getXXXSpaceShift(Component target, Point dstPoint, 
> Container nativeContainer)
> 
> (the nativeContainer argument is used in only one of the methods)
> 
> For the swing guys: in SwingUtilities and RepaintManager, where 
> iterating over the parent hierarchy, I added a check to "parent != null" 
> to also check "!(parent instanceof Window)".
> 
> Thanks,
> Piet
> 
>>
>> Thanks,
>>
>> Artem
>>
>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>> Hi all,
>>>
>>> Please find a third version for the webrev here:
>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>
>>> AWTAccessor removed again
>>>
>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>> toRenderedSpace(x,y), overridden in JLayer.
>>>
>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>> getLayoutSpaceShift(). The latter because it is called from
>>> retargetMouseEvent which itself uses getParent() when finding the
>>> hierarchy translation value.
>>>
>>> Indented the try block
>>>
>>> Added some jtreg test cases, one a manual test.
>>>
>>> Please review again
>>>
>>> Thanks,
>>> Piet
>>>
>>>
>>>
>>>
>>>
>>>> Hi Anthony,
>>>>
>>>>> Hi Piet,
>>>>>
>>>>> The version #2 looks very good.
>>>>
>>>> Looks, yes. Unfortunately, later I detected that it doesn't work. It's
>>>> missing something. Oh yes, I carried out a comprehensive manual test
>>>> but the test setup was wrong: I tested against the version 1! (A jtreg
>>>> test was carried out against version 2 and was succesfull).
>>>>
>>>> I'll try to manually add a remark to that webrev to state that it's
>>>> invalid and should not be used.
>>>>
>>>>>
>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>> AWTAccessor.
>>>>>
>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>> right? That would be great.
>>>>>
>>>>
>>>> Yes
>>>>
>>>>>
>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>> Container implementation does nothing.
>>>>>>
>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>> private and static, but will be rewritten to use
>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>
>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>> course be removed.
>>>>>
>>>>> I like the proposal.
>>>>
>>>> As said, something was missing: A Container.toRenderedSpace(point) is
>>>> needed as well. This method must return the normal transformed point,
>>>> as opposed to toLayoutSpace() that returns the inverse transformed 
>>>> point.
>>>>
>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>> option open for implementers to choose for a transformation other than
>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>>>> one would implement the actual rendering, but that's beside the point).
>>>>
>>>>>
>>>>> A minor comment regarding the code:
>>>>>
>>>>> src/share/classes/java/awt/Container.java
>>>>>> 4875 Component parent = comp.getParent();
>>>>>
>>>>> I suggest to use the getContainer() method instead. If the comp is a
>>>>> window, the getParent() may actually return an owner of the window,
>>>>> which we certainly don't want to deal with.
>>>>
>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>
>>>>>
>>>>> Also, please make sure you format the code according the guidelines:
>>>>> in Container.java the code put in the new try{} blocks must be
>>>>> correctly indented.
>>>>
>>>> This I was wondering about: should I or shouldn't I (touch code that
>>>> is otherwise not altered). Now I know, thanks.
>>>>
>>>>>
>>>>> Otherwise looks fine. Thanks!
>>>>>
>>>>
>>>> Ok, I'm working on version 3. And this time actually testing against
>>>> this same version 3! I'm still working on some more simple jtreg test
>>>> cases and I'll change to getContainer() and indent correctly.
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>>>
>>>>>> Please let me know if you agree.
>>>>>>
>>>>>> Thanks
>>>>>> Piet
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>>>>>>> Hi Artem,
>>>>>>>>
>>>>>>>> To demonstrate the implemention via the AWTAccessor pattern, I
>>>>>>>> created a
>>>>>>>> version 2 implementation:
>>>>>>>>
>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>>>>>>
>>>>>>>> This implementation is much cleaner than the original one.
>>>>>>>>
>>>>>>>> Looking forward for yout comments,
>>>>>>>> Piet
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Artem,
>>>>>>>>>
>>>>>>>>> The problem with making existing methods public is that it solves
>>>>>>>>> only
>>>>>>>>> half of the problem at hand:
>>>>>>>>>
>>>>>>>>> 1) Locate the correct component (can be solved)
>>>>>>>>>
>>>>>>>>> 2) Recalculating the mouse point from rendered space to layout 
>>>>>>>>> space
>>>>>>>>> is not solved because the locating methods only return a 
>>>>>>>>> component.
>>>>>>>>> Recalculation is needed to correctly set a mouse point in the new
>>>>>>>>> events, relative to the target component.
>>>>>>>>>
>>>>>>>>> In my proposed implementation the shift caused by 
>>>>>>>>> transformations is
>>>>>>>>> stored when looking up the target (for future use: creating new
>>>>>>>>> events
>>>>>>>>> from the original event). This future is quite an immediate future
>>>>>>>>> because creating a new event from an existing event will always be
>>>>>>>>> directly preceded by looking up that target event.
>>>>>>>>>
>>>>>>>>> An alternative would be to again iterate through the hierarchy
>>>>>>>>> and do
>>>>>>>>> the transformations. This must be done in LightweightDispatcher
>>>>>>>>> in the
>>>>>>>>> methods:
>>>>>>>>>
>>>>>>>>> 1) retargetMouseEvent (an inverse transform is needed, so the new
>>>>>>>>> Container method getConvertedPoint can be used)
>>>>>>>>>
>>>>>>>>> 2) eventDispatched. Unfortunately here an ordinary transform is
>>>>>>>>> needed, so a second new Container method must be defined that
>>>>>>>>> does an
>>>>>>>>> ordinary transform.
>>>>>>>>>
>>>>>>>>> But.... a completely different approach is also possible. I did 
>>>>>>>>> this
>>>>>>>>> in an earlier version, so I know that it works. With this
>>>>>>>>> approach no
>>>>>>>>> new public or protected methods need to be introduced and no
>>>>>>>>> existing
>>>>>>>>> methods need to go public or protected. All remains private or
>>>>>>>>> package
>>>>>>>>> private.
>>>>>>>>>
>>>>>>>>> That approach is as follows:
>>>>>>>>>
>>>>>>>>> 1) Define the AffineTransform as a private field in Component.
>>>>>>>>>
>>>>>>>>> 2) Use the AWTAccessor pattern to make the transform available in
>>>>>>>>> Container and LightweightDispatcher and in swing classes.
>>>>>>>>>
>>>>>>>>> 3) In Container and LightweightDispatcher, get the transform 
>>>>>>>>> and do
>>>>>>>>> transformations when needed.
>>>>>>>>>
>>>>>>>>> In my opinion, the solution with the AWTAccessor pattern is the
>>>>>>>>> cleanest. However, it requires Component and AWTAccessor to be
>>>>>>>>> touched.
>>>>>>>>>
>>>>>>>>> Please let me know what you think.
>>>>>>>>>
>>>>>>>>> Piet
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi, Piet,
>>>>>>>>>>
>>>>>>>>>> I haven't looked through the entire webrev and inspected 
>>>>>>>>>> mostly an
>>>>>>>>>> AWT part of the fix. A question is whether it's possible to 
>>>>>>>>>> get rid
>>>>>>>>>> of the new "conversionShift" field in Container, to make
>>>>>>>>>> transformations support really stateless?
>>>>>>>>>>
>>>>>>>>>> Another option to consider is to make some of the existing 
>>>>>>>>>> methods
>>>>>>>>>> (e.g. getMouseEventTargetImpl()) public instead of introducing
>>>>>>>>>> new ones.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Artem
>>>>>>>>>>
>>>>>>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>>>>>>> Hello all,
>>>>>>>>>>>
>>>>>>>>>>> review request for 6899434: Add affine transform support to 
>>>>>>>>>>> JLayer
>>>>>>>>>>>
>>>>>>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>>>>>>
>>>>>>>>>>> The patch covers all the requested functionality. It is
>>>>>>>>>>> concentrated in
>>>>>>>>>>> JLayer class, keeping in mind to affect the library as little as
>>>>>>>>>>> possible.
>>>>>>>>>>>
>>>>>>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>>>>>>
>>>>>>>>>>> 2) The paint method in JLayer has been adapted to use the
>>>>>>>>>>> transform
>>>>>>>>>>>
>>>>>>>>>>> 3) RepaintManager has been adapted to propagate repaint
>>>>>>>>>>> requests from
>>>>>>>>>>> the view or any of its children to the top level JLayer and
>>>>>>>>>>> have the
>>>>>>>>>>> dirty region transformed.
>>>>>>>>>>>
>>>>>>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both
>>>>>>>>>>> in the
>>>>>>>>>>> same source) have been adapted to redispatch MouseEvents to the
>>>>>>>>>>> intended
>>>>>>>>>>> target component. The lookup for the component that provides a
>>>>>>>>>>> custon
>>>>>>>>>>> cursor has also been adapted.
>>>>>>>>>>>
>>>>>>>>>>> 5) To enable Container to do necessary reculculations, a 
>>>>>>>>>>> protected
>>>>>>>>>>> method has been introduced that will be overridden by JLayer:
>>>>>>>>>>> protected Point getConvertedPoint(Point point).
>>>>>>>>>>> (If someone can suggest a better name for this method I'm glad
>>>>>>>>>>> to hear)
>>>>>>>>>>>
>>>>>>>>>>> 6) A package private method in SwingUtilities has been added
>>>>>>>>>>> that helps
>>>>>>>>>>> JPopupMenu and ToolTipManager to find the correct popup 
>>>>>>>>>>> location.
>>>>>>>>>>> JPopupMenu and ToolTipManager have been changed to use this new
>>>>>>>>>>> method
>>>>>>>>>>> in their calculations.
>>>>>>>>>>>
>>>>>>>>>>> 7) Two jtreg tests have been added.
>>>>>>>>>>>
>>>>>>>>>>> Looking forward for comments.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Piet
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 


From linuxhippy at gmail.com  Mon Feb 15 08:53:42 2010
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Mon, 15 Feb 2010 11:53:42 -0500
Subject: <AWT Dev> Question about GtkLnF implementation
In-Reply-To: <4B73E0B0.8060701@Sun.com>
References: <194f62551001300743u40c9b112y1766eed6369a7c2f@mail.gmail.com>
	<9e89675b1001300813j7e993449x23b5231b9c0c0648@mail.gmail.com>
	<194f62551001300847p3dc450c1yc1610dead2c94222@mail.gmail.com>
	<4B66F108.6010609@sun.com>
	<9e89675b1002010728p6908b8aak402a7fa997d02916@mail.gmail.com>
	<194f62551002020347l11fa6233vdd8a41dfe3a2bbaf@mail.gmail.com>
	<4B73E0B0.8060701@Sun.com>
Message-ID: <194f62551002150853n4b988673o79987370713b7aa@mail.gmail.com>

Hi Peter,

> It seems that code is lost. Its author felt it was a dirty hack and a failed
> experiment. He remembers the patch gave significant speedup with vector
> themes, but nearly regressed on pixmap ones.
Thanks a lot for clarification.

> I personally agree that the most promising thing is Cairo drawables. They
> should have alpha, and by the time jdk7 ships, Cairo will probably be
> everywhere.
The problem is GTK+ devs are unwilling to change there theme API to
allow cairo drawables, it still requires a GdkDrawable.
I worked on a solution 2 years ago, but it was rejected because GTK3
will have an all-new theme engine solving all problems.
Now 2 years later, nothing has changed and my patches are still rejected.
No wonder Nokia bought Trolltech, because GTK is almost stalled.

> As for drawing to a single pixmap, there's absolutely no reason not to try.
> I wonder if X could put limits on pixmap size, e.g. we could end up with a
> pixmap twice the size of the screen - this can be a problem maybe.
I did some experiements and did not find any significant speedup :/

I have another idea in mind, detecting vector-only themes but still
passing a GdkDrawable.
That could give a speedup when using strictly vector-only themes.

- Clemens


From c.cerbo at gmail.com  Mon Feb 15 11:05:01 2010
From: c.cerbo at gmail.com (Costantino Cerbo)
Date: Mon, 15 Feb 2010 20:05:01 +0100
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: 	first patch
In-Reply-To: <9e89675b1002120036y798f8b66waa34c6d67a580edd@mail.gmail.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
	<4B72BCFE.5050005@Sun.com>
	<6fbbec31002101035s51d984c8t9b441272c0128ae5@mail.gmail.com>
	<4B73DB40.2050804@Sun.com>
	<9e89675b1002110300j29a0a35ck8b20875066f35aa@mail.gmail.com>
	<6fbbec31002110324v97c55a8v792eb4af2d413d8d@mail.gmail.com>
	<9e89675b1002120036y798f8b66waa34c6d67a580edd@mail.gmail.com>
Message-ID: <6fbbec31002151105gf91654bu6b60966017c8e7f7@mail.gmail.com>

Hi Damjan,

2010/2/12 Damjan Jovanovic <damjan.jov at gmail.com>:
> My patch for all these changes is based on your latest one and include
> Peter's (hackish?) patch. It's attached.

Thanks for the great job! The FileDialog works now also with the GTK
L&F and without blocking the EDT.
As you said, the key was the invocation of fp_gdk_threads_enter() and
fp_gdk_threads_leave()

> Otherwise, your patch lacks error checking (eg. in calls to
> GetJavaVM() and NewStringUTF()), has typos in comments, and relies on
> C99 features like C++ style comments and variable declarations in the
> middle of a code block (do we allow those in Java?). In
> sun_awt_X11_GtkFileDialogPeer.c you name the function "quit" and
> document it as "hide"; similarly for "show" and "run". I am not
> convinced I got all the GTK calls to be thread safe, so please audit
> the code very carefully, and my locking could be a bit too fine
> grained and impact the GTK LAF drawing performance.
About these points I think that Peter and Anthony may direct take care
of them, without that I release a new patch.
I've checked swing_GTKEngine.c and swing_GTKStyle.c and the calls to
fp_gdk_threads_enter() and fp_gdk_threads_leave() are overall.


Cheers,
Costantino


From c.cerbo at gmail.com  Mon Feb 15 11:15:24 2010
From: c.cerbo at gmail.com (Costantino Cerbo)
Date: Mon, 15 Feb 2010 20:15:24 +0100
Subject: <AWT Dev> Bug 6913179,
	FileDialog uses native GTK under Linux: 	first patch
In-Reply-To: <9e89675b1002120036y798f8b66waa34c6d67a580edd@mail.gmail.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
	<4B72BCFE.5050005@Sun.com>
	<6fbbec31002101035s51d984c8t9b441272c0128ae5@mail.gmail.com>
	<4B73DB40.2050804@Sun.com>
	<9e89675b1002110300j29a0a35ck8b20875066f35aa@mail.gmail.com>
	<6fbbec31002110324v97c55a8v792eb4af2d413d8d@mail.gmail.com>
	<9e89675b1002120036y798f8b66waa34c6d67a580edd@mail.gmail.com>
Message-ID: <6fbbec31002151115o45a119d0i2f615f7e57671e75@mail.gmail.com>

Hallo Damjan,

2010/2/12 Damjan Jovanovic <damjan.jov at gmail.com>:
> Unfortunately the dialog won't close (it keeps coming back
> when you click Cancel) but that's a different bug ;-).
I haven't this problem with your patch.
I can close the FileDialog in every circumstance: by clicking "Cancel"
or the X on the top or simply by invoking FileDialog#setVisible(false)
in an other thread.

Regards,
Costantino


From Artem.Ananiev at Sun.COM  Tue Feb 16 04:49:46 2010
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Tue, 16 Feb 2010 15:49:46 +0300
Subject: <AWT Dev> <Swing Dev> Fw: review
	request	for6899434:Addaffinetransformsupport to JLayer
In-Reply-To: <7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
Message-ID: <4B7A946A.6000503@sun.com>

Hi, Piet,

the fix looks pretty good in general. Some small comments:

1. As we're about to introduce 2 new public methods into Container, we 
need to provide a description of "layout space" and "render space". I 
hope you or Alex will take care of this.

2. Could toRenderedSpace() throw NoninvertibleTransformException as well?

3. getRenderedSpaceShift() - should we traverse containers up to null or 
up to the nativeContainer?

Thanks,

Artem

On 2/12/2010 10:53 AM, Piet Blok wrote:
>
> Hi Artem,
>
> The webrev for version 3.1:
> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>
>
>> Hi, Piet,
>>
>> the 3rd version looks really great! I haven't looked to Swing code
>> much, though :)
>>
>> A small suggestion is to unify getRenderedSpaceShift() and
>> getLayoutSpaceShift(), so they both accept a Component and a Point to
>> translate. Could they also be static methods? It seems not, as I see a
>> reference to "nativeContainer" in getLayoutSpaceShift()...
>
> I unified both methods and made them static after adding nativeContainer
> as a parameter to both. Their signature is now:
>
> private static Point getXXXSpaceShift(Component target, Point dstPoint,
> Container nativeContainer)
>
> (the nativeContainer argument is used in only one of the methods)
>
> For the swing guys: in SwingUtilities and RepaintManager, where
> iterating over the parent hierarchy, I added a check to "parent != null"
> to also check "!(parent instanceof Window)".
>
> Thanks,
> Piet
>
>>
>> Thanks,
>>
>> Artem
>>
>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>> Hi all,
>>>
>>> Please find a third version for the webrev here:
>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>
>>> AWTAccessor removed again
>>>
>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>> toRenderedSpace(x,y), overridden in JLayer.
>>>
>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>> getLayoutSpaceShift(). The latter because it is called from
>>> retargetMouseEvent which itself uses getParent() when finding the
>>> hierarchy translation value.
>>>
>>> Indented the try block
>>>
>>> Added some jtreg test cases, one a manual test.
>>>
>>> Please review again
>>>
>>> Thanks,
>>> Piet
>>>
>>>
>>>
>>>
>>>
>>>> Hi Anthony,
>>>>
>>>>> Hi Piet,
>>>>>
>>>>> The version #2 looks very good.
>>>>
>>>> Looks, yes. Unfortunately, later I detected that it doesn't work. It's
>>>> missing something. Oh yes, I carried out a comprehensive manual test
>>>> but the test setup was wrong: I tested against the version 1! (A jtreg
>>>> test was carried out against version 2 and was succesfull).
>>>>
>>>> I'll try to manually add a remark to that webrev to state that it's
>>>> invalid and should not be used.
>>>>
>>>>>
>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>> AWTAccessor.
>>>>>
>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>> right? That would be great.
>>>>>
>>>>
>>>> Yes
>>>>
>>>>>
>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>> Container implementation does nothing.
>>>>>>
>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>> private and static, but will be rewritten to use
>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>
>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>> course be removed.
>>>>>
>>>>> I like the proposal.
>>>>
>>>> As said, something was missing: A Container.toRenderedSpace(point) is
>>>> needed as well. This method must return the normal transformed point,
>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>> point.
>>>>
>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>> option open for implementers to choose for a transformation other than
>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>>>> one would implement the actual rendering, but that's beside the point).
>>>>
>>>>>
>>>>> A minor comment regarding the code:
>>>>>
>>>>> src/share/classes/java/awt/Container.java
>>>>>> 4875 Component parent = comp.getParent();
>>>>>
>>>>> I suggest to use the getContainer() method instead. If the comp is a
>>>>> window, the getParent() may actually return an owner of the window,
>>>>> which we certainly don't want to deal with.
>>>>
>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>
>>>>>
>>>>> Also, please make sure you format the code according the guidelines:
>>>>> in Container.java the code put in the new try{} blocks must be
>>>>> correctly indented.
>>>>
>>>> This I was wondering about: should I or shouldn't I (touch code that
>>>> is otherwise not altered). Now I know, thanks.
>>>>
>>>>>
>>>>> Otherwise looks fine. Thanks!
>>>>>
>>>>
>>>> Ok, I'm working on version 3. And this time actually testing against
>>>> this same version 3! I'm still working on some more simple jtreg test
>>>> cases and I'll change to getContainer() and indent correctly.
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>>>
>>>>>> Please let me know if you agree.
>>>>>>
>>>>>> Thanks
>>>>>> Piet
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>>>>>>> Hi Artem,
>>>>>>>>
>>>>>>>> To demonstrate the implemention via the AWTAccessor pattern, I
>>>>>>>> created a
>>>>>>>> version 2 implementation:
>>>>>>>>
>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>>>>>>
>>>>>>>> This implementation is much cleaner than the original one.
>>>>>>>>
>>>>>>>> Looking forward for yout comments,
>>>>>>>> Piet
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Artem,
>>>>>>>>>
>>>>>>>>> The problem with making existing methods public is that it solves
>>>>>>>>> only
>>>>>>>>> half of the problem at hand:
>>>>>>>>>
>>>>>>>>> 1) Locate the correct component (can be solved)
>>>>>>>>>
>>>>>>>>> 2) Recalculating the mouse point from rendered space to layout
>>>>>>>>> space
>>>>>>>>> is not solved because the locating methods only return a
>>>>>>>>> component.
>>>>>>>>> Recalculation is needed to correctly set a mouse point in the new
>>>>>>>>> events, relative to the target component.
>>>>>>>>>
>>>>>>>>> In my proposed implementation the shift caused by
>>>>>>>>> transformations is
>>>>>>>>> stored when looking up the target (for future use: creating new
>>>>>>>>> events
>>>>>>>>> from the original event). This future is quite an immediate future
>>>>>>>>> because creating a new event from an existing event will always be
>>>>>>>>> directly preceded by looking up that target event.
>>>>>>>>>
>>>>>>>>> An alternative would be to again iterate through the hierarchy
>>>>>>>>> and do
>>>>>>>>> the transformations. This must be done in LightweightDispatcher
>>>>>>>>> in the
>>>>>>>>> methods:
>>>>>>>>>
>>>>>>>>> 1) retargetMouseEvent (an inverse transform is needed, so the new
>>>>>>>>> Container method getConvertedPoint can be used)
>>>>>>>>>
>>>>>>>>> 2) eventDispatched. Unfortunately here an ordinary transform is
>>>>>>>>> needed, so a second new Container method must be defined that
>>>>>>>>> does an
>>>>>>>>> ordinary transform.
>>>>>>>>>
>>>>>>>>> But.... a completely different approach is also possible. I did
>>>>>>>>> this
>>>>>>>>> in an earlier version, so I know that it works. With this
>>>>>>>>> approach no
>>>>>>>>> new public or protected methods need to be introduced and no
>>>>>>>>> existing
>>>>>>>>> methods need to go public or protected. All remains private or
>>>>>>>>> package
>>>>>>>>> private.
>>>>>>>>>
>>>>>>>>> That approach is as follows:
>>>>>>>>>
>>>>>>>>> 1) Define the AffineTransform as a private field in Component.
>>>>>>>>>
>>>>>>>>> 2) Use the AWTAccessor pattern to make the transform available in
>>>>>>>>> Container and LightweightDispatcher and in swing classes.
>>>>>>>>>
>>>>>>>>> 3) In Container and LightweightDispatcher, get the transform
>>>>>>>>> and do
>>>>>>>>> transformations when needed.
>>>>>>>>>
>>>>>>>>> In my opinion, the solution with the AWTAccessor pattern is the
>>>>>>>>> cleanest. However, it requires Component and AWTAccessor to be
>>>>>>>>> touched.
>>>>>>>>>
>>>>>>>>> Please let me know what you think.
>>>>>>>>>
>>>>>>>>> Piet
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi, Piet,
>>>>>>>>>>
>>>>>>>>>> I haven't looked through the entire webrev and inspected
>>>>>>>>>> mostly an
>>>>>>>>>> AWT part of the fix. A question is whether it's possible to
>>>>>>>>>> get rid
>>>>>>>>>> of the new "conversionShift" field in Container, to make
>>>>>>>>>> transformations support really stateless?
>>>>>>>>>>
>>>>>>>>>> Another option to consider is to make some of the existing
>>>>>>>>>> methods
>>>>>>>>>> (e.g. getMouseEventTargetImpl()) public instead of introducing
>>>>>>>>>> new ones.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Artem
>>>>>>>>>>
>>>>>>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>>>>>>> Hello all,
>>>>>>>>>>>
>>>>>>>>>>> review request for 6899434: Add affine transform support to
>>>>>>>>>>> JLayer
>>>>>>>>>>>
>>>>>>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>>>>>>
>>>>>>>>>>> The patch covers all the requested functionality. It is
>>>>>>>>>>> concentrated in
>>>>>>>>>>> JLayer class, keeping in mind to affect the library as little as
>>>>>>>>>>> possible.
>>>>>>>>>>>
>>>>>>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>>>>>>
>>>>>>>>>>> 2) The paint method in JLayer has been adapted to use the
>>>>>>>>>>> transform
>>>>>>>>>>>
>>>>>>>>>>> 3) RepaintManager has been adapted to propagate repaint
>>>>>>>>>>> requests from
>>>>>>>>>>> the view or any of its children to the top level JLayer and
>>>>>>>>>>> have the
>>>>>>>>>>> dirty region transformed.
>>>>>>>>>>>
>>>>>>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both
>>>>>>>>>>> in the
>>>>>>>>>>> same source) have been adapted to redispatch MouseEvents to the
>>>>>>>>>>> intended
>>>>>>>>>>> target component. The lookup for the component that provides a
>>>>>>>>>>> custon
>>>>>>>>>>> cursor has also been adapted.
>>>>>>>>>>>
>>>>>>>>>>> 5) To enable Container to do necessary reculculations, a
>>>>>>>>>>> protected
>>>>>>>>>>> method has been introduced that will be overridden by JLayer:
>>>>>>>>>>> protected Point getConvertedPoint(Point point).
>>>>>>>>>>> (If someone can suggest a better name for this method I'm glad
>>>>>>>>>>> to hear)
>>>>>>>>>>>
>>>>>>>>>>> 6) A package private method in SwingUtilities has been added
>>>>>>>>>>> that helps
>>>>>>>>>>> JPopupMenu and ToolTipManager to find the correct popup
>>>>>>>>>>> location.
>>>>>>>>>>> JPopupMenu and ToolTipManager have been changed to use this new
>>>>>>>>>>> method
>>>>>>>>>>> in their calculations.
>>>>>>>>>>>
>>>>>>>>>>> 7) Two jtreg tests have been added.
>>>>>>>>>>>
>>>>>>>>>>> Looking forward for comments.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Piet
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>


From c.cerbo at gmail.com  Tue Feb 16 05:04:29 2010
From: c.cerbo at gmail.com (Costantino Cerbo)
Date: Tue, 16 Feb 2010 14:04:29 +0100
Subject: <AWT Dev> 6705345: Enable multiple file selection in AWT
	FileDialog: also for the new GtkFileDialogPeer.
Message-ID: <6fbbec31002160504i105315ceo80c6b16febc2cfd6@mail.gmail.com>

Hallo!

I've just seen this bug fix:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6705345

After the patch for the GtkFileDialogPeer is committed I can also
extend its functionalities to handle multiple file selection.
What about directory-only selection in FileDialog? Also in this case,
I can provide already a patch for the GtkFileDialogPeer (but not for
the other OSs).

Cheers,
Costantino


From pbhome at ziggo.nl  Tue Feb 16 07:12:13 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Tue, 16 Feb 2010 16:12:13 +0100
Subject: <AWT Dev> <Swing Dev> Fw: review
	requestfor6899434:Addaffinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
	<B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
	<4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
	<4B7A946A.6000503@sun.com>
Message-ID: <1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J>

Hi Artem

> Hi, Piet,
>
> the fix looks pretty good in general. Some small comments:
>
> 1. As we're about to introduce 2 new public methods into Container, we 
> need to provide a description of "layout space" and "render space". I hope 
> you or Alex will take care of this.

What about the following descriptions?

Layout space refers to user space (coordinates in the layout system).
Rendered space refers to device space (coordinates on the screen).
Please see (link to) AffineTransform.

>
> 2. Could toRenderedSpace() throw NoninvertibleTransformException as well?

No. toRenderedSpace() is a direct transformation with any of 
AffineTransform's transform() methods.
This in contrast to inverse operations as used in toLayoutSpace(), like 
AffineTransform's createInverse() and inverseTransform() methods that may 
throw this exception.

>
> 3. getRenderedSpaceShift() - should we traverse containers up to null or 
> up to the nativeContainer?

Good point. For testing I added a test "not nativeContainer" to the null 
test and everything still works (in my own test suite that is far more 
complex than the provided jtreg test cases).

getRenderedSpaceShift() is invoked from eventDispatched. It should do a 
traversal that is analogous to the traversal there.

In general, I'm not sure about the role of "nativeContainer" and how it is 
used. For example, I don't know if (one or more)  native containers can be 
present in the hierachy between a Window and the lowest child component. Or 
is the top Window always the native container? If this is not the case, 
could you depict some hierarchy example where a native container is a child 
somewhere in the hierarchy of a JLayer's view? Then I can do a more 
comprehensive test.

Please let me know, so I can prepare a version 3.2  if needed (and add the 
descriptions at the same time)

Thanks,
Piet.

>
> Thanks,
>
> Artem
>
> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>
>> Hi Artem,
>>
>> The webrev for version 3.1:
>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>
>>
>>> Hi, Piet,
>>>
>>> the 3rd version looks really great! I haven't looked to Swing code
>>> much, though :)
>>>
>>> A small suggestion is to unify getRenderedSpaceShift() and
>>> getLayoutSpaceShift(), so they both accept a Component and a Point to
>>> translate. Could they also be static methods? It seems not, as I see a
>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>
>> I unified both methods and made them static after adding nativeContainer
>> as a parameter to both. Their signature is now:
>>
>> private static Point getXXXSpaceShift(Component target, Point dstPoint,
>> Container nativeContainer)
>>
>> (the nativeContainer argument is used in only one of the methods)
>>
>> For the swing guys: in SwingUtilities and RepaintManager, where
>> iterating over the parent hierarchy, I added a check to "parent != null"
>> to also check "!(parent instanceof Window)".
>>
>> Thanks,
>> Piet
>>
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>> Hi all,
>>>>
>>>> Please find a third version for the webrev here:
>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>
>>>> AWTAccessor removed again
>>>>
>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>
>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>> getLayoutSpaceShift(). The latter because it is called from
>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>> hierarchy translation value.
>>>>
>>>> Indented the try block
>>>>
>>>> Added some jtreg test cases, one a manual test.
>>>>
>>>> Please review again
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Hi Anthony,
>>>>>
>>>>>> Hi Piet,
>>>>>>
>>>>>> The version #2 looks very good.
>>>>>
>>>>> Looks, yes. Unfortunately, later I detected that it doesn't work. It's
>>>>> missing something. Oh yes, I carried out a comprehensive manual test
>>>>> but the test setup was wrong: I tested against the version 1! (A jtreg
>>>>> test was carried out against version 2 and was succesfull).
>>>>>
>>>>> I'll try to manually add a remark to that webrev to state that it's
>>>>> invalid and should not be used.
>>>>>
>>>>>>
>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>>> AWTAccessor.
>>>>>>
>>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>>> right? That would be great.
>>>>>>
>>>>>
>>>>> Yes
>>>>>
>>>>>>
>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>>> Container implementation does nothing.
>>>>>>>
>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>> private and static, but will be rewritten to use
>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>
>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>>> course be removed.
>>>>>>
>>>>>> I like the proposal.
>>>>>
>>>>> As said, something was missing: A Container.toRenderedSpace(point) is
>>>>> needed as well. This method must return the normal transformed point,
>>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>>> point.
>>>>>
>>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>>> option open for implementers to choose for a transformation other than
>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>>>>> one would implement the actual rendering, but that's beside the 
>>>>> point).
>>>>>
>>>>>>
>>>>>> A minor comment regarding the code:
>>>>>>
>>>>>> src/share/classes/java/awt/Container.java
>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>
>>>>>> I suggest to use the getContainer() method instead. If the comp is a
>>>>>> window, the getParent() may actually return an owner of the window,
>>>>>> which we certainly don't want to deal with.
>>>>>
>>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>>
>>>>>>
>>>>>> Also, please make sure you format the code according the guidelines:
>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>> correctly indented.
>>>>>
>>>>> This I was wondering about: should I or shouldn't I (touch code that
>>>>> is otherwise not altered). Now I know, thanks.
>>>>>
>>>>>>
>>>>>> Otherwise looks fine. Thanks!
>>>>>>
>>>>>
>>>>> Ok, I'm working on version 3. And this time actually testing against
>>>>> this same version 3! I'm still working on some more simple jtreg test
>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>
>>>>> Thanks,
>>>>> Piet
>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>>>
>>>>>>> Please let me know if you agree.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Piet
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Artem
>>>>>>>>
>>>>>>>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>>>>>>>> Hi Artem,
>>>>>>>>>
>>>>>>>>> To demonstrate the implemention via the AWTAccessor pattern, I
>>>>>>>>> created a
>>>>>>>>> version 2 implementation:
>>>>>>>>>
>>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>>>>>>>
>>>>>>>>> This implementation is much cleaner than the original one.
>>>>>>>>>
>>>>>>>>> Looking forward for yout comments,
>>>>>>>>> Piet
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Artem,
>>>>>>>>>>
>>>>>>>>>> The problem with making existing methods public is that it solves
>>>>>>>>>> only
>>>>>>>>>> half of the problem at hand:
>>>>>>>>>>
>>>>>>>>>> 1) Locate the correct component (can be solved)
>>>>>>>>>>
>>>>>>>>>> 2) Recalculating the mouse point from rendered space to layout
>>>>>>>>>> space
>>>>>>>>>> is not solved because the locating methods only return a
>>>>>>>>>> component.
>>>>>>>>>> Recalculation is needed to correctly set a mouse point in the new
>>>>>>>>>> events, relative to the target component.
>>>>>>>>>>
>>>>>>>>>> In my proposed implementation the shift caused by
>>>>>>>>>> transformations is
>>>>>>>>>> stored when looking up the target (for future use: creating new
>>>>>>>>>> events
>>>>>>>>>> from the original event). This future is quite an immediate 
>>>>>>>>>> future
>>>>>>>>>> because creating a new event from an existing event will always 
>>>>>>>>>> be
>>>>>>>>>> directly preceded by looking up that target event.
>>>>>>>>>>
>>>>>>>>>> An alternative would be to again iterate through the hierarchy
>>>>>>>>>> and do
>>>>>>>>>> the transformations. This must be done in LightweightDispatcher
>>>>>>>>>> in the
>>>>>>>>>> methods:
>>>>>>>>>>
>>>>>>>>>> 1) retargetMouseEvent (an inverse transform is needed, so the new
>>>>>>>>>> Container method getConvertedPoint can be used)
>>>>>>>>>>
>>>>>>>>>> 2) eventDispatched. Unfortunately here an ordinary transform is
>>>>>>>>>> needed, so a second new Container method must be defined that
>>>>>>>>>> does an
>>>>>>>>>> ordinary transform.
>>>>>>>>>>
>>>>>>>>>> But.... a completely different approach is also possible. I did
>>>>>>>>>> this
>>>>>>>>>> in an earlier version, so I know that it works. With this
>>>>>>>>>> approach no
>>>>>>>>>> new public or protected methods need to be introduced and no
>>>>>>>>>> existing
>>>>>>>>>> methods need to go public or protected. All remains private or
>>>>>>>>>> package
>>>>>>>>>> private.
>>>>>>>>>>
>>>>>>>>>> That approach is as follows:
>>>>>>>>>>
>>>>>>>>>> 1) Define the AffineTransform as a private field in Component.
>>>>>>>>>>
>>>>>>>>>> 2) Use the AWTAccessor pattern to make the transform available in
>>>>>>>>>> Container and LightweightDispatcher and in swing classes.
>>>>>>>>>>
>>>>>>>>>> 3) In Container and LightweightDispatcher, get the transform
>>>>>>>>>> and do
>>>>>>>>>> transformations when needed.
>>>>>>>>>>
>>>>>>>>>> In my opinion, the solution with the AWTAccessor pattern is the
>>>>>>>>>> cleanest. However, it requires Component and AWTAccessor to be
>>>>>>>>>> touched.
>>>>>>>>>>
>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>
>>>>>>>>>> Piet
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi, Piet,
>>>>>>>>>>>
>>>>>>>>>>> I haven't looked through the entire webrev and inspected
>>>>>>>>>>> mostly an
>>>>>>>>>>> AWT part of the fix. A question is whether it's possible to
>>>>>>>>>>> get rid
>>>>>>>>>>> of the new "conversionShift" field in Container, to make
>>>>>>>>>>> transformations support really stateless?
>>>>>>>>>>>
>>>>>>>>>>> Another option to consider is to make some of the existing
>>>>>>>>>>> methods
>>>>>>>>>>> (e.g. getMouseEventTargetImpl()) public instead of introducing
>>>>>>>>>>> new ones.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Artem
>>>>>>>>>>>
>>>>>>>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>>>>>>>> Hello all,
>>>>>>>>>>>>
>>>>>>>>>>>> review request for 6899434: Add affine transform support to
>>>>>>>>>>>> JLayer
>>>>>>>>>>>>
>>>>>>>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>>>>>>>
>>>>>>>>>>>> The patch covers all the requested functionality. It is
>>>>>>>>>>>> concentrated in
>>>>>>>>>>>> JLayer class, keeping in mind to affect the library as little 
>>>>>>>>>>>> as
>>>>>>>>>>>> possible.
>>>>>>>>>>>>
>>>>>>>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>>>>>>>
>>>>>>>>>>>> 2) The paint method in JLayer has been adapted to use the
>>>>>>>>>>>> transform
>>>>>>>>>>>>
>>>>>>>>>>>> 3) RepaintManager has been adapted to propagate repaint
>>>>>>>>>>>> requests from
>>>>>>>>>>>> the view or any of its children to the top level JLayer and
>>>>>>>>>>>> have the
>>>>>>>>>>>> dirty region transformed.
>>>>>>>>>>>>
>>>>>>>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both
>>>>>>>>>>>> in the
>>>>>>>>>>>> same source) have been adapted to redispatch MouseEvents to the
>>>>>>>>>>>> intended
>>>>>>>>>>>> target component. The lookup for the component that provides a
>>>>>>>>>>>> custon
>>>>>>>>>>>> cursor has also been adapted.
>>>>>>>>>>>>
>>>>>>>>>>>> 5) To enable Container to do necessary reculculations, a
>>>>>>>>>>>> protected
>>>>>>>>>>>> method has been introduced that will be overridden by JLayer:
>>>>>>>>>>>> protected Point getConvertedPoint(Point point).
>>>>>>>>>>>> (If someone can suggest a better name for this method I'm glad
>>>>>>>>>>>> to hear)
>>>>>>>>>>>>
>>>>>>>>>>>> 6) A package private method in SwingUtilities has been added
>>>>>>>>>>>> that helps
>>>>>>>>>>>> JPopupMenu and ToolTipManager to find the correct popup
>>>>>>>>>>>> location.
>>>>>>>>>>>> JPopupMenu and ToolTipManager have been changed to use this new
>>>>>>>>>>>> method
>>>>>>>>>>>> in their calculations.
>>>>>>>>>>>>
>>>>>>>>>>>> 7) Two jtreg tests have been added.
>>>>>>>>>>>>
>>>>>>>>>>>> Looking forward for comments.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Piet
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 




From Artem.Ananiev at Sun.COM  Tue Feb 16 07:54:21 2010
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Tue, 16 Feb 2010 18:54:21 +0300
Subject: <AWT Dev> <Swing Dev> Fw:
	review	requestfor6899434:Addaffinetransformsupport to JLayer
In-Reply-To: <1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J> <4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J>
Message-ID: <4B7ABFAD.8060403@sun.com>


On 2/16/2010 6:12 PM, Piet Blok wrote:
> Hi Artem
>
>> Hi, Piet,
>>
>> the fix looks pretty good in general. Some small comments:
>>
>> 1. As we're about to introduce 2 new public methods into Container, we
>> need to provide a description of "layout space" and "render space". I
>> hope you or Alex will take care of this.
>
> What about the following descriptions?
>
> Layout space refers to user space (coordinates in the layout system).
> Rendered space refers to device space (coordinates on the screen).
> Please see (link to) AffineTransform.

Probably, we should mention that layout coordinates are the ones used by 
LayoutManager and other Container stuff. For example, 
Component.getBounds() always returns layout rectangle, not rendered one.

>> 2. Could toRenderedSpace() throw NoninvertibleTransformException as well?
>
> No. toRenderedSpace() is a direct transformation with any of
> AffineTransform's transform() methods.
> This in contrast to inverse operations as used in toLayoutSpace(), like
> AffineTransform's createInverse() and inverseTransform() methods that
> may throw this exception.

It depends on what we consider a forward transform and a reverse 
transform :) And don't forget there may be non-affine transforms...

>> 3. getRenderedSpaceShift() - should we traverse containers up to null
>> or up to the nativeContainer?
>
> Good point. For testing I added a test "not nativeContainer" to the null
> test and everything still works (in my own test suite that is far more
> complex than the provided jtreg test cases).
>
> getRenderedSpaceShift() is invoked from eventDispatched. It should do a
> traversal that is analogous to the traversal there.
>
> In general, I'm not sure about the role of "nativeContainer" and how it
> is used. For example, I don't know if (one or more) native containers
> can be present in the hierachy between a Window and the lowest child
> component. Or is the top Window always the native container? If this is
> not the case, could you depict some hierarchy example where a native
> container is a child somewhere in the hierarchy of a JLayer's view? Then
> I can do a more comprehensive test.

nativeContainer is a basic part of LightweightDispatcher machinery: it 
is the container, always heavyweight, which is served by the dispatcher. 
An obvious example is how all the mouse events are dispatched: we (AWT) 
receive events for heavyweight components only as the underlying OS 
isn't aware of our lightweight Swing components. When the event is 
dispatched to a heavyweight container, it's lightweight dispatcher 
retargets it to a proper lightweight child.

Given that we won't support transformations for heavyweight components 
(BTW, it should also be reflected in JavaDoc), it's enough to care about 
nativeContainer children only.

> Please let me know, so I can prepare a version 3.2 if needed (and add
> the descriptions at the same time)

3.2 is only required if you make any significant changes based on the 
current discussion.

Thanks,

Artem

> Thanks,
> Piet.
>
>>
>> Thanks,
>>
>> Artem
>>
>> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>>
>>> Hi Artem,
>>>
>>> The webrev for version 3.1:
>>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>>
>>>
>>>> Hi, Piet,
>>>>
>>>> the 3rd version looks really great! I haven't looked to Swing code
>>>> much, though :)
>>>>
>>>> A small suggestion is to unify getRenderedSpaceShift() and
>>>> getLayoutSpaceShift(), so they both accept a Component and a Point to
>>>> translate. Could they also be static methods? It seems not, as I see a
>>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>>
>>> I unified both methods and made them static after adding nativeContainer
>>> as a parameter to both. Their signature is now:
>>>
>>> private static Point getXXXSpaceShift(Component target, Point dstPoint,
>>> Container nativeContainer)
>>>
>>> (the nativeContainer argument is used in only one of the methods)
>>>
>>> For the swing guys: in SwingUtilities and RepaintManager, where
>>> iterating over the parent hierarchy, I added a check to "parent != null"
>>> to also check "!(parent instanceof Window)".
>>>
>>> Thanks,
>>> Piet
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>>> Hi all,
>>>>>
>>>>> Please find a third version for the webrev here:
>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>>
>>>>> AWTAccessor removed again
>>>>>
>>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>>
>>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>>> getLayoutSpaceShift(). The latter because it is called from
>>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>>> hierarchy translation value.
>>>>>
>>>>> Indented the try block
>>>>>
>>>>> Added some jtreg test cases, one a manual test.
>>>>>
>>>>> Please review again
>>>>>
>>>>> Thanks,
>>>>> Piet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi Anthony,
>>>>>>
>>>>>>> Hi Piet,
>>>>>>>
>>>>>>> The version #2 looks very good.
>>>>>>
>>>>>> Looks, yes. Unfortunately, later I detected that it doesn't work.
>>>>>> It's
>>>>>> missing something. Oh yes, I carried out a comprehensive manual test
>>>>>> but the test setup was wrong: I tested against the version 1! (A
>>>>>> jtreg
>>>>>> test was carried out against version 2 and was succesfull).
>>>>>>
>>>>>> I'll try to manually add a remark to that webrev to state that it's
>>>>>> invalid and should not be used.
>>>>>>
>>>>>>>
>>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>>>> AWTAccessor.
>>>>>>>
>>>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>>>> right? That would be great.
>>>>>>>
>>>>>>
>>>>>> Yes
>>>>>>
>>>>>>>
>>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>>>> Container implementation does nothing.
>>>>>>>>
>>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>>> private and static, but will be rewritten to use
>>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>>
>>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>>>> course be removed.
>>>>>>>
>>>>>>> I like the proposal.
>>>>>>
>>>>>> As said, something was missing: A Container.toRenderedSpace(point) is
>>>>>> needed as well. This method must return the normal transformed point,
>>>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>>>> point.
>>>>>>
>>>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>>>> option open for implementers to choose for a transformation other
>>>>>> than
>>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>>>>>> one would implement the actual rendering, but that's beside the
>>>>>> point).
>>>>>>
>>>>>>>
>>>>>>> A minor comment regarding the code:
>>>>>>>
>>>>>>> src/share/classes/java/awt/Container.java
>>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>>
>>>>>>> I suggest to use the getContainer() method instead. If the comp is a
>>>>>>> window, the getParent() may actually return an owner of the window,
>>>>>>> which we certainly don't want to deal with.
>>>>>>
>>>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>>>
>>>>>>>
>>>>>>> Also, please make sure you format the code according the guidelines:
>>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>>> correctly indented.
>>>>>>
>>>>>> This I was wondering about: should I or shouldn't I (touch code that
>>>>>> is otherwise not altered). Now I know, thanks.
>>>>>>
>>>>>>>
>>>>>>> Otherwise looks fine. Thanks!
>>>>>>>
>>>>>>
>>>>>> Ok, I'm working on version 3. And this time actually testing against
>>>>>> this same version 3! I'm still working on some more simple jtreg test
>>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>>
>>>>>> Thanks,
>>>>>> Piet
>>>>>>
>>>>>>> --
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>>>
>>>>>>>> Please let me know if you agree.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Piet
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Artem
>>>>>>>>>
>>>>>>>>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>>>>>>>>> Hi Artem,
>>>>>>>>>>
>>>>>>>>>> To demonstrate the implemention via the AWTAccessor pattern, I
>>>>>>>>>> created a
>>>>>>>>>> version 2 implementation:
>>>>>>>>>>
>>>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>>>>>>>>
>>>>>>>>>> This implementation is much cleaner than the original one.
>>>>>>>>>>
>>>>>>>>>> Looking forward for yout comments,
>>>>>>>>>> Piet
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Artem,
>>>>>>>>>>>
>>>>>>>>>>> The problem with making existing methods public is that it
>>>>>>>>>>> solves
>>>>>>>>>>> only
>>>>>>>>>>> half of the problem at hand:
>>>>>>>>>>>
>>>>>>>>>>> 1) Locate the correct component (can be solved)
>>>>>>>>>>>
>>>>>>>>>>> 2) Recalculating the mouse point from rendered space to layout
>>>>>>>>>>> space
>>>>>>>>>>> is not solved because the locating methods only return a
>>>>>>>>>>> component.
>>>>>>>>>>> Recalculation is needed to correctly set a mouse point in the
>>>>>>>>>>> new
>>>>>>>>>>> events, relative to the target component.
>>>>>>>>>>>
>>>>>>>>>>> In my proposed implementation the shift caused by
>>>>>>>>>>> transformations is
>>>>>>>>>>> stored when looking up the target (for future use: creating new
>>>>>>>>>>> events
>>>>>>>>>>> from the original event). This future is quite an immediate
>>>>>>>>>>> future
>>>>>>>>>>> because creating a new event from an existing event will
>>>>>>>>>>> always be
>>>>>>>>>>> directly preceded by looking up that target event.
>>>>>>>>>>>
>>>>>>>>>>> An alternative would be to again iterate through the hierarchy
>>>>>>>>>>> and do
>>>>>>>>>>> the transformations. This must be done in LightweightDispatcher
>>>>>>>>>>> in the
>>>>>>>>>>> methods:
>>>>>>>>>>>
>>>>>>>>>>> 1) retargetMouseEvent (an inverse transform is needed, so the
>>>>>>>>>>> new
>>>>>>>>>>> Container method getConvertedPoint can be used)
>>>>>>>>>>>
>>>>>>>>>>> 2) eventDispatched. Unfortunately here an ordinary transform is
>>>>>>>>>>> needed, so a second new Container method must be defined that
>>>>>>>>>>> does an
>>>>>>>>>>> ordinary transform.
>>>>>>>>>>>
>>>>>>>>>>> But.... a completely different approach is also possible. I did
>>>>>>>>>>> this
>>>>>>>>>>> in an earlier version, so I know that it works. With this
>>>>>>>>>>> approach no
>>>>>>>>>>> new public or protected methods need to be introduced and no
>>>>>>>>>>> existing
>>>>>>>>>>> methods need to go public or protected. All remains private or
>>>>>>>>>>> package
>>>>>>>>>>> private.
>>>>>>>>>>>
>>>>>>>>>>> That approach is as follows:
>>>>>>>>>>>
>>>>>>>>>>> 1) Define the AffineTransform as a private field in Component.
>>>>>>>>>>>
>>>>>>>>>>> 2) Use the AWTAccessor pattern to make the transform
>>>>>>>>>>> available in
>>>>>>>>>>> Container and LightweightDispatcher and in swing classes.
>>>>>>>>>>>
>>>>>>>>>>> 3) In Container and LightweightDispatcher, get the transform
>>>>>>>>>>> and do
>>>>>>>>>>> transformations when needed.
>>>>>>>>>>>
>>>>>>>>>>> In my opinion, the solution with the AWTAccessor pattern is the
>>>>>>>>>>> cleanest. However, it requires Component and AWTAccessor to be
>>>>>>>>>>> touched.
>>>>>>>>>>>
>>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>>
>>>>>>>>>>> Piet
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi, Piet,
>>>>>>>>>>>>
>>>>>>>>>>>> I haven't looked through the entire webrev and inspected
>>>>>>>>>>>> mostly an
>>>>>>>>>>>> AWT part of the fix. A question is whether it's possible to
>>>>>>>>>>>> get rid
>>>>>>>>>>>> of the new "conversionShift" field in Container, to make
>>>>>>>>>>>> transformations support really stateless?
>>>>>>>>>>>>
>>>>>>>>>>>> Another option to consider is to make some of the existing
>>>>>>>>>>>> methods
>>>>>>>>>>>> (e.g. getMouseEventTargetImpl()) public instead of introducing
>>>>>>>>>>>> new ones.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Artem
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>>>>>>>>> Hello all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> review request for 6899434: Add affine transform support to
>>>>>>>>>>>>> JLayer
>>>>>>>>>>>>>
>>>>>>>>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>>>>>>>>
>>>>>>>>>>>>> The patch covers all the requested functionality. It is
>>>>>>>>>>>>> concentrated in
>>>>>>>>>>>>> JLayer class, keeping in mind to affect the library as
>>>>>>>>>>>>> little as
>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2) The paint method in JLayer has been adapted to use the
>>>>>>>>>>>>> transform
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3) RepaintManager has been adapted to propagate repaint
>>>>>>>>>>>>> requests from
>>>>>>>>>>>>> the view or any of its children to the top level JLayer and
>>>>>>>>>>>>> have the
>>>>>>>>>>>>> dirty region transformed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both
>>>>>>>>>>>>> in the
>>>>>>>>>>>>> same source) have been adapted to redispatch MouseEvents to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> intended
>>>>>>>>>>>>> target component. The lookup for the component that provides a
>>>>>>>>>>>>> custon
>>>>>>>>>>>>> cursor has also been adapted.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 5) To enable Container to do necessary reculculations, a
>>>>>>>>>>>>> protected
>>>>>>>>>>>>> method has been introduced that will be overridden by JLayer:
>>>>>>>>>>>>> protected Point getConvertedPoint(Point point).
>>>>>>>>>>>>> (If someone can suggest a better name for this method I'm glad
>>>>>>>>>>>>> to hear)
>>>>>>>>>>>>>
>>>>>>>>>>>>> 6) A package private method in SwingUtilities has been added
>>>>>>>>>>>>> that helps
>>>>>>>>>>>>> JPopupMenu and ToolTipManager to find the correct popup
>>>>>>>>>>>>> location.
>>>>>>>>>>>>> JPopupMenu and ToolTipManager have been changed to use this
>>>>>>>>>>>>> new
>>>>>>>>>>>>> method
>>>>>>>>>>>>> in their calculations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 7) Two jtreg tests have been added.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking forward for comments.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From pbhome at ziggo.nl  Tue Feb 16 08:34:35 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Tue, 16 Feb 2010 17:34:35 +0100
Subject: <AWT Dev> <Swing Dev> Fw:
	reviewrequestfor6899434:Addaffinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
	<B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
	<4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
	<4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J>
	<4B7ABFAD.8060403@sun.com>
Message-ID: <53918E681BAF475E99134FF75A4BB5E7@DB35TT0J>


Hi Artem


>
> On 2/16/2010 6:12 PM, Piet Blok wrote:
>> Hi Artem
>>
>>> Hi, Piet,
>>>
>>> the fix looks pretty good in general. Some small comments:
>>>
>>> 1. As we're about to introduce 2 new public methods into Container, we
>>> need to provide a description of "layout space" and "render space". I
>>> hope you or Alex will take care of this.
>>
>> What about the following descriptions?
>>
>> Layout space refers to user space (coordinates in the layout system).
>> Rendered space refers to device space (coordinates on the screen).
>> Please see (link to) AffineTransform.
>
> Probably, we should mention that layout coordinates are the ones used by 
> LayoutManager and other Container stuff. For example, 
> Component.getBounds() always returns layout rectangle, not rendered one.

Ok, good addition. I'll add that clarification.

>
>>> 2. Could toRenderedSpace() throw NoninvertibleTransformException as 
>>> well?
>>
>> No. toRenderedSpace() is a direct transformation with any of
>> AffineTransform's transform() methods.
>> This in contrast to inverse operations as used in toLayoutSpace(), like
>> AffineTransform's createInverse() and inverseTransform() methods that
>> may throw this exception.
>
> It depends on what we consider a forward transform and a reverse transform 
> :) And don't forget there may be non-affine transforms...

Any transform, be it affine or non-affine is able by definition to 
transform, otherwise it's not a transform :-)

Only inverse transform can be problematic. That is, when two different 
points, after transformation, result in the same point. Valid during 
transform. But impossible to do an inverse. Analogous to multiplying by zero 
is valid, but the operation can't be inversed.

>
>>> 3. getRenderedSpaceShift() - should we traverse containers up to null
>>> or up to the nativeContainer?
>>
>> Good point. For testing I added a test "not nativeContainer" to the null
>> test and everything still works (in my own test suite that is far more
>> complex than the provided jtreg test cases).
>>
>> getRenderedSpaceShift() is invoked from eventDispatched. It should do a
>> traversal that is analogous to the traversal there.
>>
>> In general, I'm not sure about the role of "nativeContainer" and how it
>> is used. For example, I don't know if (one or more) native containers
>> can be present in the hierachy between a Window and the lowest child
>> component. Or is the top Window always the native container? If this is
>> not the case, could you depict some hierarchy example where a native
>> container is a child somewhere in the hierarchy of a JLayer's view? Then
>> I can do a more comprehensive test.
>
> nativeContainer is a basic part of LightweightDispatcher machinery: it is 
> the container, always heavyweight, which is served by the dispatcher. An 
> obvious example is how all the mouse events are dispatched: we (AWT) 
> receive events for heavyweight components only as the underlying OS isn't 
> aware of our lightweight Swing components. When the event is dispatched to 
> a heavyweight container, it's lightweight dispatcher retargets it to a 
> proper lightweight child.
>
> Given that we won't support transformations for heavyweight components 
> (BTW, it should also be reflected in JavaDoc), it's enough to care about 
> nativeContainer children only.


1) I'll add a remark to the new public methods that they only apply to 
lightweight components.
2) I'll study your remarks and decide if I'll add a check on 
nativeContainer.

I'll let you know if and when a version 3.2 is available.

Thanks,
Piet

>
>> Please let me know, so I can prepare a version 3.2 if needed (and add
>> the descriptions at the same time)
>
> 3.2 is only required if you make any significant changes based on the 
> current discussion.
>
> Thanks,
>
> Artem
>
>> Thanks,
>> Piet.
>>
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>>>
>>>> Hi Artem,
>>>>
>>>> The webrev for version 3.1:
>>>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>>>
>>>>
>>>>> Hi, Piet,
>>>>>
>>>>> the 3rd version looks really great! I haven't looked to Swing code
>>>>> much, though :)
>>>>>
>>>>> A small suggestion is to unify getRenderedSpaceShift() and
>>>>> getLayoutSpaceShift(), so they both accept a Component and a Point to
>>>>> translate. Could they also be static methods? It seems not, as I see a
>>>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>>>
>>>> I unified both methods and made them static after adding 
>>>> nativeContainer
>>>> as a parameter to both. Their signature is now:
>>>>
>>>> private static Point getXXXSpaceShift(Component target, Point dstPoint,
>>>> Container nativeContainer)
>>>>
>>>> (the nativeContainer argument is used in only one of the methods)
>>>>
>>>> For the swing guys: in SwingUtilities and RepaintManager, where
>>>> iterating over the parent hierarchy, I added a check to "parent != 
>>>> null"
>>>> to also check "!(parent instanceof Window)".
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Please find a third version for the webrev here:
>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>>>
>>>>>> AWTAccessor removed again
>>>>>>
>>>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>>>
>>>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>>>> getLayoutSpaceShift(). The latter because it is called from
>>>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>>>> hierarchy translation value.
>>>>>>
>>>>>> Indented the try block
>>>>>>
>>>>>> Added some jtreg test cases, one a manual test.
>>>>>>
>>>>>> Please review again
>>>>>>
>>>>>> Thanks,
>>>>>> Piet
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Anthony,
>>>>>>>
>>>>>>>> Hi Piet,
>>>>>>>>
>>>>>>>> The version #2 looks very good.
>>>>>>>
>>>>>>> Looks, yes. Unfortunately, later I detected that it doesn't work.
>>>>>>> It's
>>>>>>> missing something. Oh yes, I carried out a comprehensive manual test
>>>>>>> but the test setup was wrong: I tested against the version 1! (A
>>>>>>> jtreg
>>>>>>> test was carried out against version 2 and was succesfull).
>>>>>>>
>>>>>>> I'll try to manually add a remark to that webrev to state that it's
>>>>>>> invalid and should not be used.
>>>>>>>
>>>>>>>>
>>>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>>>>> AWTAccessor.
>>>>>>>>
>>>>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>>>>> right? That would be great.
>>>>>>>>
>>>>>>>
>>>>>>> Yes
>>>>>>>
>>>>>>>>
>>>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>>>>> Container implementation does nothing.
>>>>>>>>>
>>>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>>>> private and static, but will be rewritten to use
>>>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>>>
>>>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>>>>> course be removed.
>>>>>>>>
>>>>>>>> I like the proposal.
>>>>>>>
>>>>>>> As said, something was missing: A Container.toRenderedSpace(point) 
>>>>>>> is
>>>>>>> needed as well. This method must return the normal transformed 
>>>>>>> point,
>>>>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>>>>> point.
>>>>>>>
>>>>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>>>>> option open for implementers to choose for a transformation other
>>>>>>> than
>>>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know 
>>>>>>> how
>>>>>>> one would implement the actual rendering, but that's beside the
>>>>>>> point).
>>>>>>>
>>>>>>>>
>>>>>>>> A minor comment regarding the code:
>>>>>>>>
>>>>>>>> src/share/classes/java/awt/Container.java
>>>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>>>
>>>>>>>> I suggest to use the getContainer() method instead. If the comp is 
>>>>>>>> a
>>>>>>>> window, the getParent() may actually return an owner of the window,
>>>>>>>> which we certainly don't want to deal with.
>>>>>>>
>>>>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>>>>
>>>>>>>>
>>>>>>>> Also, please make sure you format the code according the 
>>>>>>>> guidelines:
>>>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>>>> correctly indented.
>>>>>>>
>>>>>>> This I was wondering about: should I or shouldn't I (touch code that
>>>>>>> is otherwise not altered). Now I know, thanks.
>>>>>>>
>>>>>>>>
>>>>>>>> Otherwise looks fine. Thanks!
>>>>>>>>
>>>>>>>
>>>>>>> Ok, I'm working on version 3. And this time actually testing against
>>>>>>> this same version 3! I'm still working on some more simple jtreg 
>>>>>>> test
>>>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Piet
>>>>>>>
>>>>>>>> --
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please let me know if you agree.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Piet
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Artem
>>>>>>>>>>
>>>>>>>>>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>>>>>>>>>> Hi Artem,
>>>>>>>>>>>
>>>>>>>>>>> To demonstrate the implemention via the AWTAccessor pattern, I
>>>>>>>>>>> created a
>>>>>>>>>>> version 2 implementation:
>>>>>>>>>>>
>>>>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>>>>>>>>>
>>>>>>>>>>> This implementation is much cleaner than the original one.
>>>>>>>>>>>
>>>>>>>>>>> Looking forward for yout comments,
>>>>>>>>>>> Piet
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi Artem,
>>>>>>>>>>>>
>>>>>>>>>>>> The problem with making existing methods public is that it
>>>>>>>>>>>> solves
>>>>>>>>>>>> only
>>>>>>>>>>>> half of the problem at hand:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) Locate the correct component (can be solved)
>>>>>>>>>>>>
>>>>>>>>>>>> 2) Recalculating the mouse point from rendered space to layout
>>>>>>>>>>>> space
>>>>>>>>>>>> is not solved because the locating methods only return a
>>>>>>>>>>>> component.
>>>>>>>>>>>> Recalculation is needed to correctly set a mouse point in the
>>>>>>>>>>>> new
>>>>>>>>>>>> events, relative to the target component.
>>>>>>>>>>>>
>>>>>>>>>>>> In my proposed implementation the shift caused by
>>>>>>>>>>>> transformations is
>>>>>>>>>>>> stored when looking up the target (for future use: creating new
>>>>>>>>>>>> events
>>>>>>>>>>>> from the original event). This future is quite an immediate
>>>>>>>>>>>> future
>>>>>>>>>>>> because creating a new event from an existing event will
>>>>>>>>>>>> always be
>>>>>>>>>>>> directly preceded by looking up that target event.
>>>>>>>>>>>>
>>>>>>>>>>>> An alternative would be to again iterate through the hierarchy
>>>>>>>>>>>> and do
>>>>>>>>>>>> the transformations. This must be done in LightweightDispatcher
>>>>>>>>>>>> in the
>>>>>>>>>>>> methods:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) retargetMouseEvent (an inverse transform is needed, so the
>>>>>>>>>>>> new
>>>>>>>>>>>> Container method getConvertedPoint can be used)
>>>>>>>>>>>>
>>>>>>>>>>>> 2) eventDispatched. Unfortunately here an ordinary transform is
>>>>>>>>>>>> needed, so a second new Container method must be defined that
>>>>>>>>>>>> does an
>>>>>>>>>>>> ordinary transform.
>>>>>>>>>>>>
>>>>>>>>>>>> But.... a completely different approach is also possible. I did
>>>>>>>>>>>> this
>>>>>>>>>>>> in an earlier version, so I know that it works. With this
>>>>>>>>>>>> approach no
>>>>>>>>>>>> new public or protected methods need to be introduced and no
>>>>>>>>>>>> existing
>>>>>>>>>>>> methods need to go public or protected. All remains private or
>>>>>>>>>>>> package
>>>>>>>>>>>> private.
>>>>>>>>>>>>
>>>>>>>>>>>> That approach is as follows:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) Define the AffineTransform as a private field in Component.
>>>>>>>>>>>>
>>>>>>>>>>>> 2) Use the AWTAccessor pattern to make the transform
>>>>>>>>>>>> available in
>>>>>>>>>>>> Container and LightweightDispatcher and in swing classes.
>>>>>>>>>>>>
>>>>>>>>>>>> 3) In Container and LightweightDispatcher, get the transform
>>>>>>>>>>>> and do
>>>>>>>>>>>> transformations when needed.
>>>>>>>>>>>>
>>>>>>>>>>>> In my opinion, the solution with the AWTAccessor pattern is the
>>>>>>>>>>>> cleanest. However, it requires Component and AWTAccessor to be
>>>>>>>>>>>> touched.
>>>>>>>>>>>>
>>>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>>>
>>>>>>>>>>>> Piet
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi, Piet,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I haven't looked through the entire webrev and inspected
>>>>>>>>>>>>> mostly an
>>>>>>>>>>>>> AWT part of the fix. A question is whether it's possible to
>>>>>>>>>>>>> get rid
>>>>>>>>>>>>> of the new "conversionShift" field in Container, to make
>>>>>>>>>>>>> transformations support really stateless?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another option to consider is to make some of the existing
>>>>>>>>>>>>> methods
>>>>>>>>>>>>> (e.g. getMouseEventTargetImpl()) public instead of introducing
>>>>>>>>>>>>> new ones.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Artem
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>>>>>>>>>> Hello all,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> review request for 6899434: Add affine transform support to
>>>>>>>>>>>>>> JLayer
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The patch covers all the requested functionality. It is
>>>>>>>>>>>>>> concentrated in
>>>>>>>>>>>>>> JLayer class, keeping in mind to affect the library as
>>>>>>>>>>>>>> little as
>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2) The paint method in JLayer has been adapted to use the
>>>>>>>>>>>>>> transform
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3) RepaintManager has been adapted to propagate repaint
>>>>>>>>>>>>>> requests from
>>>>>>>>>>>>>> the view or any of its children to the top level JLayer and
>>>>>>>>>>>>>> have the
>>>>>>>>>>>>>> dirty region transformed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher 
>>>>>>>>>>>>>> (both
>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>> same source) have been adapted to redispatch MouseEvents to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> intended
>>>>>>>>>>>>>> target component. The lookup for the component that provides 
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> custon
>>>>>>>>>>>>>> cursor has also been adapted.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 5) To enable Container to do necessary reculculations, a
>>>>>>>>>>>>>> protected
>>>>>>>>>>>>>> method has been introduced that will be overridden by JLayer:
>>>>>>>>>>>>>> protected Point getConvertedPoint(Point point).
>>>>>>>>>>>>>> (If someone can suggest a better name for this method I'm 
>>>>>>>>>>>>>> glad
>>>>>>>>>>>>>> to hear)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 6) A package private method in SwingUtilities has been added
>>>>>>>>>>>>>> that helps
>>>>>>>>>>>>>> JPopupMenu and ToolTipManager to find the correct popup
>>>>>>>>>>>>>> location.
>>>>>>>>>>>>>> JPopupMenu and ToolTipManager have been changed to use this
>>>>>>>>>>>>>> new
>>>>>>>>>>>>>> method
>>>>>>>>>>>>>> in their calculations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 7) Two jtreg tests have been added.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looking forward for comments.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 




From Peter.Zhelezniakov at Sun.COM  Wed Feb 17 06:09:33 2010
From: Peter.Zhelezniakov at Sun.COM (Peter Zhelezniakov)
Date: Wed, 17 Feb 2010 17:09:33 +0300
Subject: <AWT Dev> Bug 6913179,
 FileDialog uses native GTK under Linux: first patch
In-Reply-To: <9e89675b1002120036y798f8b66waa34c6d67a580edd@mail.gmail.com>
References: <6fbbec31001171414p20990a38q51c25895565f69aa@mail.gmail.com>
	<4B5EFD4F.6030104@sun.com>
	<6fbbec31001271522r662fce01ha92c74ce57a2ee9@mail.gmail.com>
	<4B61C67F.2070109@sun.com>
	<6fbbec31001281528sd735079o949c9ad2afb4bc00@mail.gmail.com>
	<4B72BCFE.5050005@Sun.com>
	<6fbbec31002101035s51d984c8t9b441272c0128ae5@mail.gmail.com>
	<4B73DB40.2050804@Sun.com>
	<9e89675b1002110300j29a0a35ck8b20875066f35aa@mail.gmail.com>
	<6fbbec31002110324v97c55a8v792eb4af2d413d8d@mail.gmail.com>
	<9e89675b1002120036y798f8b66waa34c6d67a580edd@mail.gmail.com>
Message-ID: <4B7BF89D.6000501@Sun.com>

Hi Damian,

Damjan Jovanovic wrote:
> That only leaves Java's usage of GTK as a suspect.

I agree. GTK LAF was meant to be used from a single thread (EDT), so no 
measures were taken to ensure thread safety.


> On http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness.html
> we read that while GDK locks are not reentrant, they can be safely
> replaced by locks that are reentrant, and the java-gnome library
> successfully does just that. Unfortunately for us
> gdk_threads_set_lock_functions() only exists since GDK 2.4 -> no go.

I'd not say no go; GTK 2.2 is already aged, and by the time JDK7 ships 
it would be extinct. So i'd drop support for it completely (we have some 
2.2-specific code now, both Java and C).

OTOH i don't see how set_lock_functions() is going to help. On the 
filedialog thread we run the smart gtk_main() function that releases the 
lock when it's not needed. But on EDT we don't run it, so we ourselves 
must define points where to grab and release the lock. It seems 
reasonable to grab the lock once we're in the native code, and release 
it just before going back to Java. This seems to be the approach you're 
taking with your patch.

Thanks!
-- 
Peter              |  x33066  |  location: SPB04  |  timezone: GMT+03


From Anthony.Petrov at Sun.COM  Thu Feb 18 03:54:00 2010
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Thu, 18 Feb 2010 14:54:00 +0300
Subject: <AWT Dev> 6705345: Enable multiple file selection in
	AWT	FileDialog: also for the new GtkFileDialogPeer.
In-Reply-To: <6fbbec31002160504i105315ceo80c6b16febc2cfd6@mail.gmail.com>
References: <6fbbec31002160504i105315ceo80c6b16febc2cfd6@mail.gmail.com>
Message-ID: <4B7D2A58.2030701@sun.com>

Hi Costantino,

On 2/16/2010 4:04 PM Costantino Cerbo wrote:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6705345
> 
> After the patch for the GtkFileDialogPeer is committed I can also
> extend its functionalities to handle multiple file selection.

Since the fix has just been pushed to the awt repository, I think that 
makes sense to incorporate the required changes right into your current 
patch that introduces the GtkFileDialogPeer. Also, please apply the 
suggestions outlined by Damjan in [1].


> What about directory-only selection in FileDialog? Also in this case,
> I can provide already a patch for the GtkFileDialogPeer (but not for
> the other OSs).

I don't think we're ready for that fix yet. We would really want this 
implemented on all supported platforms at once.

[1] http://mail.openjdk.java.net/pipermail/awt-dev/2010-February/001163.html

--
best regards,
Anthony


From c.cerbo at gmail.com  Thu Feb 18 15:04:31 2010
From: c.cerbo at gmail.com (Costantino Cerbo)
Date: Fri, 19 Feb 2010 00:04:31 +0100
Subject: <AWT Dev> 6705345: Enable multiple file selection in AWT
	FileDialog: also for the new GtkFileDialogPeer.
In-Reply-To: <4B7D2A58.2030701@sun.com>
References: <6fbbec31002160504i105315ceo80c6b16febc2cfd6@mail.gmail.com>
	<4B7D2A58.2030701@sun.com>
Message-ID: <6fbbec31002181504m66b1b5a9k1febc9b6abfb3d70@mail.gmail.com>

Hi Anthony,

here is the new patch for the bug 6913179 (FileDialog should use
native GTK file chooser on linux distros).

There are the most relevant changes:
  1. Dynamic link to libgthread-2.0.so.0 instead of libgthread-2.0.so
  2. GTK multithread support (gdk_threads_enter() and
gdk_threads_leave() as outlined by Damjan)
  3. New Thread to don't block the EDT
  4. Support for multiple file selection (bugs 6705345)

I'm looking forward to hearing your feedback!


2010/2/18 Anthony Petrov <Anthony.Petrov at sun.com>:
>> What about directory-only selection in FileDialog? Also in this case,
>> I can provide already a patch for the GtkFileDialogPeer (but not for
>> the other OSs).
>
> I don't think we're ready for that fix yet. We would really want this
> implemented on all supported platforms at once.
Okay, but meanwhile we can open an issue for this feature in the Sun
bug database, what do you think about?


Best regards,
Costantino from Stuttgart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b6913179.patch
Type: application/octet-stream
Size: 35369 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20100219/a042f43a/b6913179.patch 

From Anthony.Petrov at Sun.COM  Fri Feb 19 07:01:30 2010
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Fri, 19 Feb 2010 18:01:30 +0300
Subject: <AWT Dev> Review request: 6913179 (The java.awt.FileDialog should
 use native GTK file chooser on linux distros)
Message-ID: <4B7EA7CA.8060701@sun.com>

Hi Costantino,

Here's the latest version of your fix:

http://cr.openjdk.java.net/~anthony/7-43-GTKFileDialog-6913179.3/

Thanks!


> Okay, but meanwhile we can open an issue for this feature in the Sun
> bug database, what do you think about?

Just filed the following:

6927978 : Directory Selection standard dialog support

(should become visible on the bugs.sun.com in a day or two).

--
best regards,
Anthony


From lana.steuck at sun.com  Fri Feb 19 17:34:58 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Sat, 20 Feb 2010 01:34:58 +0000
Subject: <AWT Dev> hg: jdk7/awt: 4 new changesets
Message-ID: <20100220013458.B4D8C428CC@hg.openjdk.java.net>

Changeset: e1176f86805f
Author:    mikejwre
Date:      2010-01-28 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/rev/e1176f86805f

Added tag jdk7-b81 for changeset 8403096d1fe7

! .hgtags

Changeset: 6880a3af9add
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/rev/6880a3af9add

Added tag jdk7-b82 for changeset e1176f86805f

! .hgtags

Changeset: 2f3ea057d1ad
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/rev/2f3ea057d1ad

Added tag jdk7-b83 for changeset 6880a3af9add

! .hgtags

Changeset: cf26288a114b
Author:    mikejwre
Date:      2010-02-18 13:31 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/rev/cf26288a114b

Added tag jdk7-b84 for changeset 2f3ea057d1ad

! .hgtags



From lana.steuck at sun.com  Fri Feb 19 17:35:05 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Sat, 20 Feb 2010 01:35:05 +0000
Subject: <AWT Dev> hg: jdk7/awt/corba: 4 new changesets
Message-ID: <20100220013511.F3A60428CD@hg.openjdk.java.net>

Changeset: 1e8c1bfad1ab
Author:    mikejwre
Date:      2010-01-28 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/corba/rev/1e8c1bfad1ab

Added tag jdk7-b81 for changeset e08a42a2a94d

! .hgtags

Changeset: fde0df7a2384
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/corba/rev/fde0df7a2384

Added tag jdk7-b82 for changeset 1e8c1bfad1ab

! .hgtags

Changeset: 68c8961a82e4
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/corba/rev/68c8961a82e4

Added tag jdk7-b83 for changeset fde0df7a2384

! .hgtags

Changeset: c67a9df7bc0c
Author:    mikejwre
Date:      2010-02-18 13:31 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/corba/rev/c67a9df7bc0c

Added tag jdk7-b84 for changeset 68c8961a82e4

! .hgtags



From lana.steuck at sun.com  Fri Feb 19 17:38:24 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Sat, 20 Feb 2010 01:38:24 +0000
Subject: <AWT Dev> hg: jdk7/awt/hotspot: 62 new changesets
Message-ID: <20100220014141.2B19C428D0@hg.openjdk.java.net>

Changeset: 1999f5b12482
Author:    mikejwre
Date:      2010-01-28 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/1999f5b12482

Added tag jdk7-b81 for changeset 1f9b07674480

! .hgtags

Changeset: 26ecc6fa29e6
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/26ecc6fa29e6

Added tag jdk7-b82 for changeset 1999f5b12482

! .hgtags

Changeset: 7fbf850d87b7
Author:    dcubed
Date:      2010-01-13 09:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/7fbf850d87b7

6580131: 3/4 CompiledMethodLoad events don't produce the expected extra notifications to describe inlining
Summary: Add support for additional implementation specific info to the JVM/TI CompiledMethodLoad event via the compile_info parameter.
Reviewed-by: never, ohair, tbell, tdeneau
Contributed-by: Vasanth Venkatachalam <vasanth.venkatachalam at amd.com>

! make/Makefile
! make/defs.make
+ src/share/vm/code/jvmticmlr.h
! src/share/vm/includeDB_core
! src/share/vm/prims/jvmtiExport.cpp

Changeset: 3908ad124838
Author:    dcubed
Date:      2010-01-20 11:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/3908ad124838

Merge

! make/Makefile
! make/defs.make
! src/share/vm/includeDB_core
! src/share/vm/prims/jvmtiExport.cpp

Changeset: 2718ec34c699
Author:    coleenp
Date:      2010-01-22 15:06 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/2718ec34c699

Merge

- src/share/vm/gc_implementation/g1/ptrQueue.inline.hpp

Changeset: cf0685d550f1
Author:    never
Date:      2010-01-20 22:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/cf0685d550f1

6911204: generated adapters with large signatures can fill up the code cache
Reviewed-by: kvn, jrose

! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/share/vm/includeDB_core
! src/share/vm/oops/methodOop.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp

Changeset: 99af867dfa05
Author:    kvn
Date:      2010-01-26 08:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/99af867dfa05

6919886: Sweep CodeCache more aggressively to reduce its usage for CompileTheWorld
Summary: Add safepoint after CompileTheWorldSafepointInterval (100) compilations and do full sweep of CodeCache each time.
Reviewed-by: never
Contributed-by: eric.caspole at amd.com

! src/share/vm/classfile/classLoader.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 89ca5ab4fa60
Author:    iveresov
Date:      2010-01-27 14:06 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/89ca5ab4fa60

Merge

! src/share/vm/includeDB_core

Changeset: 4788266644c1
Author:    jmasa
Date:      2010-01-21 11:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/4788266644c1

6895236: CMS: cmsOopClosures.inline.hpp:43 assert(..., "Should remember klasses in this context")
Summary: Adjust assertion checking for ExplicitGCInvokesConcurrentAndUnloadsClasses as a reason for class unloading
Reviewed-by: ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/iterator.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/referenceProcessor.hpp

Changeset: fed17682aea5
Author:    ysr
Date:      2010-01-21 14:47 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/fed17682aea5

Merge


Changeset: 776fb94f33cc
Author:    apetrusenko
Date:      2010-01-21 18:51 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/776fb94f33cc

6918006: G1: spill space must be reserved on the stack for barrier calls on Windows x64
Summary: Stub code generated to call G1 barriers does not allocate spill space on the stack as required by Windows x64 ABI. The fix is to use more ABI-friendly call_VM_leaf().
Reviewed-by: iveresov, never, kvn

! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp

Changeset: c81fa70144aa
Author:    tonyp
Date:      2010-01-25 18:03 -0500
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/c81fa70144aa

6919980: G1: remove +UseG1GC from under experimental options (second attempt)
Summary: Trying this again, as the original change was lost.
Reviewed-by: ysr, jmasa

! src/share/vm/runtime/globals.hpp

Changeset: 34fb2662f6c2
Author:    ysr
Date:      2010-01-26 16:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/34fb2662f6c2

6920090: G1: Disable ReduceInitialCardMarks at least until 6920109 is fixed
Summary: G1 now answers "no" to the query can_elide_initializing_store_barrier() in the product build. A debug flag allows alternate behaviour in debug builds.
Reviewed-by: iveresov, tonyp

! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_interface/collectedHeap.cpp

Changeset: 291c9b3b64fc
Author:    ysr
Date:      2010-01-26 23:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/291c9b3b64fc

Merge


Changeset: f3345b7b01b4
Author:    ysr
Date:      2010-01-27 22:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/f3345b7b01b4

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 9e1637a04678
Author:    twisti
Date:      2010-01-28 08:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/9e1637a04678

6920970: Zero build fixes after 6849984 and 6911204
Summary: Two recent commits broke the build on Zero.
Reviewed-by: twisti
Contributed-by: Gary Benson <gbenson at redhat.com>

! src/cpu/zero/vm/interpreter_zero.cpp
! src/cpu/zero/vm/sharedRuntime_zero.cpp

Changeset: 8d9bfe6a446b
Author:    never
Date:      2010-01-28 16:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/8d9bfe6a446b

6920346: G1: "must avoid base_memory and AliasIdxTop"
Reviewed-by: kvn

! src/share/vm/opto/memnode.hpp

Changeset: 0e14bd797dad
Author:    never
Date:      2010-01-28 20:41 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/0e14bd797dad

6792161: assert("No dead instructions after post-alloc")
Reviewed-by: kvn

! src/share/vm/opto/ifg.cpp
+ test/compiler/6792161/Test6792161.java

Changeset: ba263cfb7611
Author:    twisti
Date:      2010-01-29 12:13 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/ba263cfb7611

6917766: JSR 292 needs its own deopt handler
Summary: We need to introduce a new MH deopt handler so we can easily determine if the deopt happened at a MH call site or not.
Reviewed-by: never, jrose

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 24128c2ffa87
Author:    twisti
Date:      2010-01-29 08:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/24128c2ffa87

6921339: backout 6917766
Reviewed-by: mr

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 5f24d0319e54
Author:    kvn
Date:      2010-01-29 09:27 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/5f24d0319e54

4360113: Evict nmethods when code cache gets full
Summary: Speculatively unload the oldest nmethods when code cache gets full.
Reviewed-by: never, kvn
Contributed-by: eric.caspole at amd.com

! src/share/vm/ci/ciEnv.cpp
! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/includeDB_compiler2
! src/share/vm/includeDB_core
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp

Changeset: 844a9d73ec22
Author:    never
Date:      2010-01-29 22:51 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/844a9d73ec22

6916644: C2 compiler crash on x86
Reviewed-by: kvn, twisti

! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp
! src/share/vm/opto/machnode.hpp
! src/share/vm/opto/matcher.cpp
+ test/compiler/6916644/Test6916644.java

Changeset: 18a389214829
Author:    twisti
Date:      2010-02-01 19:29 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/18a389214829

6921352: JSR 292 needs its own deopt handler
Summary: We need to introduce a new MH deopt handler so we can easily determine if the deopt happened at a MH call site or not.
Reviewed-by: never, jrose

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.hpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 5fcfaa1ad96f
Author:    twisti
Date:      2010-02-01 23:18 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/5fcfaa1ad96f

6921799: JSR 292 call sites should not be fixed-up
Summary: MethodHandle invoke call sites should not be fixed-up by SharedRuntime::fixup_callers_callsite as c2i/i2c adapters are used to implement MethodHandle actions.
Reviewed-by: kvn, never

! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 87684f1a88b5
Author:    kvn
Date:      2010-02-01 16:49 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/87684f1a88b5

6614597: Performance variability in jvm2008 xml.validation
Summary: Fix incorrect marking of methods as not compilable.
Reviewed-by: never

! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/oops/methodDataOop.hpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/deoptimization.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 74c848d437ab
Author:    never
Date:      2010-02-03 12:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/74c848d437ab

6921922: fix for 6911204 breaks tagged stack interpreter
Reviewed-by: kvn

! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp

Changeset: cef333a48af6
Author:    kvn
Date:      2010-02-03 15:03 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/cef333a48af6

6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly
Summary: Print "made not compilable" line  only for deoptimizations.
Reviewed-by: never

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp

Changeset: e8443c7be117
Author:    never
Date:      2010-02-03 15:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/e8443c7be117

6921969: optimize 64 long multiply for case with high bits zero
Reviewed-by: never, twisti, kvn, rasbold
Contributed-by: Hiroshi Yamauchi <yamauchi at google.com>

! src/cpu/x86/vm/x86_32.ad
+ test/compiler/6921969/TestMultiplyLongHiZero.java

Changeset: 0fce83e8dc0e
Author:    never
Date:      2010-02-03 18:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/0fce83e8dc0e

Merge


Changeset: c1f1137b3575
Author:    twisti
Date:      2010-02-04 03:34 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/c1f1137b3575

Merge

! src/share/vm/runtime/globals.hpp

Changeset: c028504fdaa6
Author:    never
Date:      2010-02-04 11:16 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/c028504fdaa6

6921992: failure in verify scheduling after 6792161
Reviewed-by: kvn

! src/share/vm/opto/ifg.cpp

Changeset: 6deeaebad47a
Author:    dcubed
Date:      2010-02-01 17:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/6deeaebad47a

6902182: 4/4 Starting with jdwp agent should not incur performance penalty
Summary: Rename can_post_exceptions support to can_post_on_exceptions. Add support for should_post_on_exceptions flag to permit per JavaThread optimizations.
Reviewed-by: never, kvn, dcubed
Contributed-by: tom.deneau at amd.com

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/prims/jvmtiEventController.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiExport.hpp
! src/share/vm/prims/jvmtiManageCapabilities.cpp
! src/share/vm/prims/jvmtiThreadState.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp

Changeset: 0fc941df6fb7
Author:    dcubed
Date:      2010-02-02 10:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/0fc941df6fb7

6918421: 1/1 in-process JVM now ignores preset Windows unhandled exception filter
Summary: Add support for chaining Windows UnhandledExceptionFilter handlers
Reviewed-by: kamg, dholmes, never, acorn, ikrylov

! src/os/windows/vm/os_windows.cpp

Changeset: f19bf22685cc
Author:    dcubed
Date:      2010-02-02 11:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/f19bf22685cc

Merge

! src/os/windows/vm/os_windows.cpp

Changeset: 7f8790caccb0
Author:    apangin
Date:      2010-02-04 15:50 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/7f8790caccb0

Merge

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: dba18cabafec
Author:    trims
Date:      2010-02-05 12:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/dba18cabafec

Merge


Changeset: ff3232b68fbb
Author:    trims
Date:      2010-02-05 12:27 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/ff3232b68fbb

6921473: Bump the HS17 build number to 09
Summary: Update the HS17 build number to 09
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1e3c5d0474d4
Author:    trims
Date:      2010-02-05 16:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/1e3c5d0474d4

Merge


Changeset: 39e0a32bc49b
Author:    trims
Date:      2010-02-11 19:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/39e0a32bc49b

Added tag hs17-b01 for changeset a94714c55065

! .hgtags

Changeset: bd1260aafd87
Author:    trims
Date:      2010-02-11 19:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/bd1260aafd87

Added tag hs17-b02 for changeset faf94d94786b

! .hgtags

Changeset: d9c445aa7bb1
Author:    trims
Date:      2010-02-11 19:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/d9c445aa7bb1

Added tag hs17-b03 for changeset f4b900403d6e

! .hgtags

Changeset: 3940517a1f13
Author:    trims
Date:      2010-02-11 19:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/3940517a1f13

Added tag hs17-b04 for changeset d8dd291a362a

! .hgtags

Changeset: 4458e32d9125
Author:    trims
Date:      2010-02-11 19:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/4458e32d9125

Added tag hs17-b05 for changeset 9174bb32e934

! .hgtags

Changeset: 36a78dac746f
Author:    trims
Date:      2010-02-11 19:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/36a78dac746f

Added tag hs17-b06 for changeset a5a6adfca6ec

! .hgtags

Changeset: bfa6d67a7a29
Author:    trims
Date:      2010-02-11 19:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/bfa6d67a7a29

Added tag hs17-b07 for changeset 3003ddd1d433

! .hgtags

Changeset: 73047d0b13cf
Author:    trims
Date:      2010-02-11 19:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/73047d0b13cf

Added tag hs17-b08 for changeset 1f9b07674480

! .hgtags

Changeset: 12076a98a540
Author:    trims
Date:      2010-02-11 19:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/12076a98a540

Added tag hs17-b09 for changeset ff3232b68fbb

! .hgtags

Changeset: 704a172a0918
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/704a172a0918

Added tag hs16-b01 for changeset 981375ca07b7

! .hgtags

Changeset: e114a6374471
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/e114a6374471

Added tag hs16-b02 for changeset f4cbf78110c7

! .hgtags

Changeset: 3469eafe9bf4
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/3469eafe9bf4

Added tag hs16-b03 for changeset 07c1c01e0315

! .hgtags

Changeset: 26dba59fc9ec
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/26dba59fc9ec

Added tag hs16-b04 for changeset 08f86fa55a31

! .hgtags

Changeset: 8b0989046c93
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/8b0989046c93

Added tag hs16-b05 for changeset 32c83fb84370

! .hgtags

Changeset: 5fe06b3f6753
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/5fe06b3f6753

Added tag hs16-b06 for changeset ba313800759b

! .hgtags

Changeset: 36ae83035b8e
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/36ae83035b8e

Added tag hs16-b07 for changeset 3c0f72981560

! .hgtags

Changeset: 89ef87b378cd
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/89ef87b378cd

Added tag hs16-b08 for changeset ac59d4e6dae5

! .hgtags

Changeset: cd89ef31a9c8
Author:    trims
Date:      2010-02-11 20:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/cd89ef31a9c8

Added tag hs15-b01 for changeset 3f844a28c5f4

! .hgtags

Changeset: 2099657b92a1
Author:    trims
Date:      2010-02-11 20:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/2099657b92a1

Added tag hs15-b02 for changeset 1605bb4eb5a7

! .hgtags

Changeset: 9dcad51c5c70
Author:    trims
Date:      2010-02-11 20:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/9dcad51c5c70

Added tag hs15-b03 for changeset 2581d90c6c9b

! .hgtags

Changeset: 07118aaebf50
Author:    trims
Date:      2010-02-11 20:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/07118aaebf50

Added tag hs15-b04 for changeset 9ab385cb0c42

! .hgtags

Changeset: 3f370a32906e
Author:    trims
Date:      2010-02-11 20:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/3f370a32906e

Added tag hs15-b05 for changeset fafab5d5349c

! .hgtags

Changeset: ffc8d176b84b
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/ffc8d176b84b

Added tag jdk7-b83 for changeset 3f370a32906e

! .hgtags

Changeset: 125eb6a9fccf
Author:    mikejwre
Date:      2010-02-18 13:31 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/hotspot/rev/125eb6a9fccf

Added tag jdk7-b84 for changeset ffc8d176b84b

! .hgtags



From lana.steuck at sun.com  Fri Feb 19 17:51:10 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Sat, 20 Feb 2010 01:51:10 +0000
Subject: <AWT Dev> hg: jdk7/awt/jaxp: 7 new changesets
Message-ID: <20100220015110.AB5CB428D3@hg.openjdk.java.net>

Changeset: c876ad22e4bf
Author:    mikejwre
Date:      2010-01-28 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxp/rev/c876ad22e4bf

Added tag jdk7-b81 for changeset 204e59d488cd

! .hgtags

Changeset: 309a0a7fc6ce
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxp/rev/309a0a7fc6ce

Added tag jdk7-b82 for changeset c876ad22e4bf

! .hgtags

Changeset: c664aff74b41
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxp/rev/c664aff74b41

Added tag jdk7-b83 for changeset 309a0a7fc6ce

! .hgtags

Changeset: df2e196a5f01
Author:    ohair
Date:      2010-02-03 16:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxp/rev/df2e196a5f01

6923146: Upgrade to JAXP 1.4.3
Reviewed-by: darcy

! jaxp.properties

Changeset: bf7c7f2825ef
Author:    lana
Date:      2010-02-08 23:58 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxp/rev/bf7c7f2825ef

Merge


Changeset: 32c0cf01d555
Author:    lana
Date:      2010-02-14 23:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxp/rev/32c0cf01d555

Merge


Changeset: 6c0ccabb430d
Author:    mikejwre
Date:      2010-02-18 13:31 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxp/rev/6c0ccabb430d

Added tag jdk7-b84 for changeset 32c0cf01d555

! .hgtags



From lana.steuck at sun.com  Fri Feb 19 17:51:17 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Sat, 20 Feb 2010 01:51:17 +0000
Subject: <AWT Dev> hg: jdk7/awt/jaxws: 4 new changesets
Message-ID: <20100220015117.71E2E428D4@hg.openjdk.java.net>

Changeset: 31573ae8eed1
Author:    mikejwre
Date:      2010-01-28 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxws/rev/31573ae8eed1

Added tag jdk7-b81 for changeset f051045fe94a

! .hgtags

Changeset: 371e3ded591d
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxws/rev/371e3ded591d

Added tag jdk7-b82 for changeset 31573ae8eed1

! .hgtags

Changeset: 8bc02839eee4
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxws/rev/8bc02839eee4

Added tag jdk7-b83 for changeset 371e3ded591d

! .hgtags

Changeset: 8424512588ff
Author:    mikejwre
Date:      2010-02-18 13:31 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jaxws/rev/8424512588ff

Added tag jdk7-b84 for changeset 8bc02839eee4

! .hgtags



From lana.steuck at sun.com  Fri Feb 19 17:53:34 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Sat, 20 Feb 2010 01:53:34 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 45 new changesets
Message-ID: <20100220020825.441D5428DA@hg.openjdk.java.net>

Changeset: 31ed4132f345
Author:    mikejwre
Date:      2010-01-28 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/31ed4132f345

Added tag jdk7-b81 for changeset 10b993d417fc

! .hgtags

Changeset: b250e6c5a9e5
Author:    andrew
Date:      2010-01-28 21:01 +0000
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/b250e6c5a9e5

6921068: Remove javadoc builds warnings from specdefault tag
Summary: Ignore specdefault tag to avoid javadoc warnings
Reviewed-by: darcy, ohair

! make/docs/Makefile

Changeset: b3b10d45778a
Author:    andrew
Date:      2010-01-29 02:38 +0000
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/b3b10d45778a

6917466: Should set bootclasspath for javadoc in jdk build
Summary: javadoc needs to reference the newly built classes so as not to hit APIs which differ between the boot JDK and the source files of the JDK being built.
Reviewed-by: ohair

! make/common/shared/Defs-java.gmk
! make/javax/swing/beaninfo/SwingBeans.gmk

Changeset: 69ef657320ad
Author:    ohair
Date:      2010-01-29 09:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/69ef657320ad

Merge


Changeset: 9027c6b9d7e2
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/9027c6b9d7e2

Added tag jdk7-b82 for changeset 69ef657320ad

! .hgtags

Changeset: 9b82fa0505bc
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/9b82fa0505bc

Added tag jdk7-b83 for changeset 9027c6b9d7e2

! .hgtags

Changeset: dca3a251a001
Author:    xuelei
Date:      2010-01-20 21:38 +0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/dca3a251a001

6862064: incorrect implementation of PKIXParameters.clone()
Reviewed-by: weijun, mullan

! src/share/classes/java/security/cert/PKIXParameters.java

Changeset: b19cd193245e
Author:    dcubed
Date:      2010-01-20 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/b19cd193245e

6580131: 3/4 CompiledMethodLoad events don't produce the expected extra notifications to describe inlining
Summary: Add support for additional implementation specific info to the JVM/TI CompiledMethodLoad event via the compile_info parameter.
Reviewed-by: never, ohair, tbell, tdeneau
Contributed-by: Vasanth Venkatachalam <vasanth.venkatachalam at amd.com>

! make/common/shared/Sanity.gmk
! make/java/jvm/Makefile
! make/mkdemo/jvmti/Makefile
! make/mkdemo/jvmti/README.txt
+ make/mkdemo/jvmti/compiledMethodLoad/Makefile
+ src/share/demo/jvmti/compiledMethodLoad/README.txt
+ src/share/demo/jvmti/compiledMethodLoad/compiledMethodLoad.c
+ src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt
! src/share/demo/jvmti/index.html
+ src/share/javavm/export/jvmticmlr.h
+ test/demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java
! test/demo/jvmti/heapTracker/HeapTrackerTest.java
! test/demo/jvmti/hprof/CpuTimesDefineClassTest.java
! test/demo/jvmti/hprof/CpuTimesTest.java
! test/demo/jvmti/minst/MinstTest.java
! test/demo/jvmti/mtrace/TraceJFrame.java

Changeset: 117b245b5bb9
Author:    vinnie
Date:      2010-01-21 23:59 +0000
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/117b245b5bb9

6763530: Cannot decode PublicKey (Proider SunPKCS11, curve prime256v1)
Reviewed-by: andrew

! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java
! src/share/classes/sun/security/pkcs11/P11Key.java

Changeset: c94ac5522d01
Author:    vinnie
Date:      2010-01-22 00:02 +0000
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/c94ac5522d01

Merge


Changeset: e67bf9abc6a5
Author:    chegar
Date:      2010-01-25 15:41 +0000
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/e67bf9abc6a5

6707289: InterfaceAddress.getNetworkPrefixLength() does not conform to Javadoc
Reviewed-by: michaelm

! src/windows/native/java/net/NetworkInterface_winXP.c
+ test/java/net/InterfaceAddress/NetworkPrefixLength.java

Changeset: 558f2a424bfa
Author:    weijun
Date:      2010-01-26 17:03 +0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/558f2a424bfa

6919610: KeyTabInputStream uses static field for per-instance value
Reviewed-by: mullan

! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java
+ test/sun/security/krb5/ktab/KeyTabIndex.java

Changeset: f544825d0976
Author:    jccollet
Date:      2010-01-26 11:39 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/f544825d0976

6919185: test/closed/sun/net/ftp/FtpTests fails to compile
Summary: Fixed a couple of regressions in FtpClient and updated the test.
Reviewed-by: chegar

! src/share/classes/sun/net/ftp/impl/FtpClient.java

Changeset: 8df0ffac7f4d
Author:    chegar
Date:      2010-01-27 16:11 +0000
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/8df0ffac7f4d

6905552: libnet/nio portability issues
Reviewed-by: alanb

! src/share/native/java/net/net_util.c
! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/solaris/native/java/net/NetworkInterface.c
! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/net_util_md.c
! src/solaris/native/java/net/net_util_md.h
! src/solaris/native/sun/net/spi/SdpProvider.c
! src/solaris/native/sun/nio/ch/Net.c
! src/solaris/native/sun/nio/ch/SctpNet.c

Changeset: 4192f6edbbf4
Author:    ptisnovs
Date:      2010-01-27 17:47 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/4192f6edbbf4

6920143: test/java/awt/TestArea/UsingWithMouse.java needs realSync()
Summary: Added small delay to make sure that TextArea animation have finished
Reviewed-by: anthony

! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.java

Changeset: 0126effcc249
Author:    lana
Date:      2010-01-27 14:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/0126effcc249

Merge


Changeset: 946b30073247
Author:    sherman
Date:      2010-01-27 19:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/946b30073247

6920732: opensource test/java/nio/charset
Summary: move the test cases to openjdk
Reviewed-by: martin

+ test/java/nio/charset/Charset/AvailableCharsetNames.java
+ test/java/nio/charset/Charset/CharsetContainmentTest.java
+ test/java/nio/charset/Charset/Contains.java
+ test/java/nio/charset/Charset/Default.java
+ test/java/nio/charset/Charset/EmptyCharsetName.java
+ test/java/nio/charset/Charset/EncDec.java
+ test/java/nio/charset/Charset/IllegalCharsetName.java
+ test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java
+ test/java/nio/charset/Charset/NullCharsetName.java
+ test/java/nio/charset/Charset/RegisteredCharsets.java
+ test/java/nio/charset/Charset/default.sh
+ test/java/nio/charset/CharsetDecoder/AverageMax.java
+ test/java/nio/charset/CharsetDecoder/EmptyInput.java
+ test/java/nio/charset/CharsetEncoder/CanEncode.java
+ test/java/nio/charset/CharsetEncoder/Flush.java
+ test/java/nio/charset/RemovingSunIO/SunioAlias.java
+ test/java/nio/charset/RemovingSunIO/TestCOMP.java
+ test/java/nio/charset/RemovingSunIO/TestUnmappableForLength.java
+ test/java/nio/charset/coders/BashCache.java
+ test/java/nio/charset/coders/BashStreams.java
+ test/java/nio/charset/coders/Check.java
+ test/java/nio/charset/coders/CheckSJISMappingProp.sh
+ test/java/nio/charset/coders/Errors.java
+ test/java/nio/charset/coders/FullRead.java
+ test/java/nio/charset/coders/IOCoders.java
+ test/java/nio/charset/coders/IsLegalReplacement.java
+ test/java/nio/charset/coders/ResetISO2022JP.java
+ test/java/nio/charset/coders/SJISPropTest.java
+ test/java/nio/charset/coders/StreamTimeout.java
+ test/java/nio/charset/coders/Surrogate.java
+ test/java/nio/charset/coders/Surrogates.java
+ test/java/nio/charset/coders/Util.java
+ test/java/nio/charset/coders/ref.shift_jis
+ test/java/nio/charset/coders/ref.windows-31j
+ test/java/nio/charset/spi/FooCharset.java
+ test/java/nio/charset/spi/FooProvider.java
+ test/java/nio/charset/spi/Test.java
+ test/java/nio/charset/spi/basic.sh
+ test/java/nio/charset/spi/charsetProvider.sp
+ test/java/nio/charset/spi/default-pol

Changeset: 7dadd2951a8b
Author:    andrew
Date:      2010-02-02 10:55 +0000
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/7dadd2951a8b

6921740: Eliminate warnings from sun.io converters and allow compiling with JAVAC_MAX_WARNINGS=true
Summary: Fix sun.io converters unchecked and cast warnings produced by -Xlint:all
Reviewed-by: alanb, sherman

! make/java/sun_nio/Makefile
! src/share/classes/sun/io/ByteToCharUTF8.java
! src/share/classes/sun/io/CharToByteUnicode.java
! src/share/classes/sun/io/CharacterEncoding.java
! src/share/classes/sun/io/Converters.java
! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java

Changeset: e6ab5fabaf7e
Author:    weijun
Date:      2010-02-03 17:04 +0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/e6ab5fabaf7e

6922482: keytool's help on -file always shows 'output file'
Reviewed-by: wetmore

! src/share/classes/sun/security/tools/KeyTool.java
+ test/sun/security/tools/keytool/file-in-help.sh

Changeset: a39e899aa5dc
Author:    sherman
Date:      2010-02-05 00:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/a39e899aa5dc

6919132: Regex \P{Lu} selects half of a surrogate pari
Summary: To use StartS for complement category/block class
Reviewed-by: martin, okutsu

! src/share/classes/java/util/regex/Pattern.java
! test/java/util/regex/RegExTest.java

Changeset: 7136683a33d2
Author:    wetmore
Date:      2010-02-05 17:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/7136683a33d2

6923976: TestProviderLeak.java is using too small of an initial heap under newer Hotspot (b79+)
Reviewed-by: ohair

! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java

Changeset: 445b9928fb70
Author:    sherman
Date:      2010-02-06 09:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/445b9928fb70

6923692: java/classes_util TEST_BUG:ReadZip.java fails when
Summary: to create the test file at test.dir
Reviewed-by: alanb

! test/java/util/zip/ZipFile/ReadZip.java

Changeset: e79d95ea2e81
Author:    lana
Date:      2010-02-08 23:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/e79d95ea2e81

Merge


Changeset: 7e8c77ae401a
Author:    rkennke
Date:      2010-02-02 16:38 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/7e8c77ae401a

6888734: PIT: regression test fails when java.security.manager is enabled
Summary: Load FontManager instance in privileged block to avoid AccessControlException
Reviewed-by: igor, tdv

! src/share/classes/sun/font/FontManagerFactory.java
+ test/java/awt/PrintJob/Security/SecurityDialogTest.java
+ test/java/awt/PrintJob/Security/policy

Changeset: cedd0cdd5b9a
Author:    rkennke
Date:      2010-02-03 10:02 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/cedd0cdd5b9a

6896335: GraphicsEnvironment.getDefaultScreenDevice() throws UnsatisfiedLinkError in headless mode
Summary: Use local ge variable instead of localEnv field in GE.
Reviewed-by: igor, prr

! src/share/classes/java/awt/GraphicsEnvironment.java
+ test/java/awt/GraphicsEnvironment/TestGetDefScreenDevice.java

Changeset: 58d014485a29
Author:    rkennke
Date:      2010-02-07 11:07 +0100
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/58d014485a29

6904882: java.awt.Font.createFont() causes AccessControlException if executed with "-Djava.security.manager"
Summary: Perform FontUtilities initialization in privileged block
Reviewed-by: igor, prr

! src/share/classes/sun/font/FontUtilities.java
+ test/java/awt/FontClass/FontPrivilege.java

Changeset: 89b0235188b5
Author:    lana
Date:      2010-02-09 00:00 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/89b0235188b5

Merge


Changeset: b51982678191
Author:    lana
Date:      2010-02-09 00:02 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/b51982678191

Merge


Changeset: de7807599a9b
Author:    peytoia
Date:      2009-12-15 14:50 +0900
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/de7807599a9b

5047314: [Col] Collator.compare() runs indefinitely for a certain set of Thai strings
Reviewed-by: okutsu

! src/share/classes/java/text/CollationElementIterator.java
+ test/java/text/Collator/Bug5047314.java

Changeset: 3efbbc00ac5f
Author:    lana
Date:      2009-12-16 16:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3efbbc00ac5f

Merge

- make/tools/CharsetMapping/DoubleByte-X.java
- make/tools/CharsetMapping/SingleByte-X.java
- src/share/classes/sun/awt/ComponentAccessor.java
- src/share/classes/sun/awt/WindowAccessor.java
- src/share/classes/sun/security/provider/IdentityDatabase.java
- src/share/classes/sun/security/provider/SystemIdentity.java
- src/share/classes/sun/security/provider/SystemSigner.java
- src/share/classes/sun/security/x509/X500Signer.java
- src/share/classes/sun/security/x509/X509Cert.java
- src/share/classes/sun/tools/jar/JarVerifierStream.java
- src/share/classes/sun/util/CoreResourceBundleControl-XLocales.java
- src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java
- test/java/util/Formatter/Basic-X.java
- test/sun/tools/native2ascii/test2
- test/tools/launcher/SolarisDataModel.sh
- test/tools/launcher/SolarisRunpath.sh
- test/tools/launcher/libraryCaller.c
- test/tools/launcher/libraryCaller.h
- test/tools/launcher/libraryCaller.java

Changeset: e2f7e92c30f1
Author:    peterz
Date:      2009-12-21 19:26 +0300
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/e2f7e92c30f1

6860433: [Nimbus] Code to set a single slider's thumb background doesn't work as specified
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/nimbus/Defaults.template
! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
+ test/javax/swing/plaf/nimbus/ColorCustomizationTest.java

Changeset: fffd21bc5657
Author:    peterz
Date:      2009-12-25 17:47 +0300
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/fffd21bc5657

6860438: [Nimbus] Code to globally set slider's thumb background doesn't work as specified
Reviewed-by: rupashka

! src/share/classes/javax/swing/MultiUIDefaults.java
+ test/javax/swing/MultiUIDefaults/4300666/bug4300666.html
+ test/javax/swing/MultiUIDefaults/4300666/bug4300666.java
+ test/javax/swing/MultiUIDefaults/4331767/bug4331767.java
+ test/javax/swing/MultiUIDefaults/Test6860438.java

Changeset: e9ccd1dd6923
Author:    andrew
Date:      2010-01-08 12:51 +0000
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/e9ccd1dd6923

6584033: (tz) wrong buffer length in TimeZone_md.c
Summary: Add testcase for this bug
Reviewed-by: darcy, okutsu

+ test/java/util/TimeZone/TimeZoneDatePermissionCheck.java
+ test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh

Changeset: b129d0f7be40
Author:    peytoia
Date:      2010-01-13 15:40 +0900
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/b129d0f7be40

6868503: RuleBasedBreakIterator is inefficient
Reviewed-by: okutsu

! src/share/classes/java/text/RuleBasedBreakIterator.java

Changeset: 9c5a24050392
Author:    malenkov
Date:      2010-01-21 21:45 +0300
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/9c5a24050392

4922835: DOC: Statement javadoc should indicate that target and methodName cannot be null
Reviewed-by: peterz

! src/share/classes/java/beans/Expression.java
! src/share/classes/java/beans/Statement.java

Changeset: eba0ff97a252
Author:    malenkov
Date:      2010-01-21 21:53 +0300
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/eba0ff97a252

4968536: DOC: Javadoc for java.beans.Encoder.getPersistenceDelegate is incomplete
Reviewed-by: peterz

! src/share/classes/java/beans/Encoder.java

Changeset: 3c61edecf44f
Author:    okutsu
Date:      2010-01-26 15:42 +0900
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3c61edecf44f

6912866: (date) java.util.Date.before / after may be expensive
Reviewed-by: peytoia

! src/share/classes/java/util/Date.java

Changeset: e7127f3fa2f4
Author:    peterz
Date:      2010-01-28 17:06 +0300
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/e7127f3fa2f4

6912118: Incosistency in several SynthUI classes between inherited specs ofupdate() and paint() methods
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java
! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java
! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java
! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java
! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java
! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java
! src/share/classes/javax/swing/plaf/synth/SynthListUI.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java
! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java
! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java
! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java
! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java
! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java

Changeset: 4eb3a8c95c24
Author:    malenkov
Date:      2010-01-28 20:49 +0300
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/4eb3a8c95c24

6412286: DOC: LTP: Unspecified NPE in java.beans.DefaultPersistenceDelegate.instantiate method
Reviewed-by: peterz

! src/share/classes/java/beans/DefaultPersistenceDelegate.java
! src/share/classes/java/beans/PersistenceDelegate.java

Changeset: 3283bb8c1bcb
Author:    lana
Date:      2010-01-28 16:12 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3283bb8c1bcb

Merge

- make/java/redist/FILES.gmk
- make/sun/nio/FILES_java.gmk
- src/share/classes/sun/dyn/util/BytecodeSignature.java
- src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java

Changeset: 3913691b3021
Author:    malenkov
Date:      2010-02-05 10:36 +0300
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3913691b3021

6921057: REGRESSION: persistence delegate issue on Windows and Linux against 5.u23b03/6u17b11
Reviewed-by: peterz, art

! src/share/classes/java/beans/Introspector.java
! test/java/beans/Introspector/6380849/TestBeanInfo.java
! test/java/beans/Introspector/Test5102804.java
! test/java/beans/XMLEncoder/Test4646747.java

Changeset: 5c0c2882eed2
Author:    lana
Date:      2010-02-09 00:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/5c0c2882eed2

Merge


Changeset: 7cb9388bb1a1
Author:    lana
Date:      2010-02-14 23:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/7cb9388bb1a1

Merge


Changeset: a9b4fde406d4
Author:    mikejwre
Date:      2010-02-18 13:31 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/a9b4fde406d4

Added tag jdk7-b84 for changeset 7cb9388bb1a1

! .hgtags

Changeset: d6d2de6ee2d1
Author:    lana
Date:      2010-02-19 15:13 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/d6d2de6ee2d1

Merge




From lana.steuck at sun.com  Fri Feb 19 18:22:18 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Sat, 20 Feb 2010 02:22:18 +0000
Subject: <AWT Dev> hg: jdk7/awt/langtools: 19 new changesets
Message-ID: <20100220022313.AEEA0428DE@hg.openjdk.java.net>

Changeset: 47003a3622f6
Author:    mikejwre
Date:      2010-01-28 11:27 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/47003a3622f6

Added tag jdk7-b81 for changeset cfabfcf9f110

! .hgtags

Changeset: c9f4ae1f1480
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/c9f4ae1f1480

Added tag jdk7-b82 for changeset 47003a3622f6

! .hgtags

Changeset: 2edcb5dc642d
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/2edcb5dc642d

Added tag jdk7-b83 for changeset c9f4ae1f1480

! .hgtags

Changeset: f23b985beb78
Author:    jjg
Date:      2010-01-19 14:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/f23b985beb78

6917067: refactor type annotations code from TransTypes into new TypeAnnotations class
Reviewed-by: jjg, darcy
Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu

+ src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java

Changeset: 0eaf89e08564
Author:    jjg
Date:      2010-01-20 16:12 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/0eaf89e08564

6918127: improve handling of TypeAnnotationPosition fields
Reviewed-by: jjg, darcy
Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu

! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java

Changeset: da0e3e2dd3ef
Author:    jjg
Date:      2010-01-26 11:15 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/da0e3e2dd3ef

6919944: incorrect position given for duplicate annotation value error
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out
! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java
! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out

Changeset: 59167312ed4e
Author:    jjg
Date:      2010-01-26 11:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/59167312ed4e

6917130: should test that annotations that have been optimized away are not emitted to classfile
Reviewed-by: jjg, darcy
Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu

+ test/tools/javac/typeAnnotations/classfile/DeadCode.java

Changeset: ff7a01f9eff3
Author:    lana
Date:      2010-01-27 14:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/ff7a01f9eff3

Merge


Changeset: 699ecefbdd4e
Author:    jjg
Date:      2010-01-29 16:06 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/699ecefbdd4e

6919889: assorted position errors in compiler syntax trees
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
+ test/tools/javac/T6654037.java
! test/tools/javac/generics/diamond/neg/Neg01.out
! test/tools/javac/generics/diamond/neg/Neg02.out
! test/tools/javac/generics/diamond/neg/Neg03.out
! test/tools/javac/generics/diamond/neg/Neg04.out
+ test/tools/javac/treepostests/TreePosTest.java

Changeset: 8e638442522a
Author:    jjg
Date:      2010-01-29 16:54 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/8e638442522a

6499119: Created package-info class file modeled improperly
6920317: package-info.java file has to be specified on the javac cmdline, else it will not be avail.
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
+ test/tools/javac/processing/6499119/ClassProcessor.java
+ test/tools/javac/processing/6499119/package-info.java
+ test/tools/javac/processing/T6920317.java

Changeset: 732510cc3538
Author:    jjg
Date:      2010-02-01 17:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/732510cc3538

6919986: [308] change size of type_index (of CLASS_EXTENDS and THROWS) from byte to short
Reviewed-by: darcy, jjg
Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu

! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java

Changeset: b0a68258360a
Author:    jjg
Date:      2010-02-02 10:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/b0a68258360a

6918625: handle annotations on array class literals
Reviewed-by: jjg, darcy
Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu

! src/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java
! src/share/classes/com/sun/tools/javap/AnnotationWriter.java
+ test/tools/javap/typeAnnotations/ArrayClassLiterals2.java

Changeset: 41ed86f86585
Author:    jjg
Date:      2010-02-03 11:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/41ed86f86585

6922429: extend tree position test waiver
Reviewed-by: darcy

! test/tools/javac/treepostests/TreePosTest.java

Changeset: f65d652cb6af
Author:    jjg
Date:      2010-02-03 11:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/f65d652cb6af

6922300: [308] populate the reference_info for type annotations targeting primitive class literals
Reviewed-by: darcy, jjg
Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu

! src/share/classes/com/sun/tools/javac/jvm/Gen.java

Changeset: 4c844e609d81
Author:    jjg
Date:      2010-02-03 16:58 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/4c844e609d81

6921979: add test program to verify annotations are attached to nodes as expected
Reviewed-by: darcy

+ test/tools/javac/treeannotests/AnnoTreeTests.java
+ test/tools/javac/treeannotests/DA.java
+ test/tools/javac/treeannotests/TA.java
+ test/tools/javac/treeannotests/Test.java
+ test/tools/javac/treeannotests/TestProcessor.java

Changeset: 4b4e282a3146
Author:    jjg
Date:      2010-02-04 10:14 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/4b4e282a3146

6923080: TreeScanner.visitNewClass should scan tree.typeargs
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
+ test/tools/javac/tree/T6923080.java
+ test/tools/javac/tree/TreeScannerTest.java

Changeset: 56a46d079264
Author:    lana
Date:      2010-02-08 23:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/56a46d079264

Merge


Changeset: d9cd5b8286e4
Author:    lana
Date:      2010-02-14 23:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/d9cd5b8286e4

Merge


Changeset: 75d5bd12eb86
Author:    mikejwre
Date:      2010-02-18 13:31 -0800
URL:       http://hg.openjdk.java.net/jdk7/awt/langtools/rev/75d5bd12eb86

Added tag jdk7-b84 for changeset d9cd5b8286e4

! .hgtags



From Alexander.Potochkin at Sun.COM  Wed Feb 24 05:44:18 2010
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Wed, 24 Feb 2010 16:44:18 +0300
Subject: <AWT Dev> <Swing Dev>
	Fw:	reviewrequestfor6899434:Addaffinetransformsupport to JLayer
In-Reply-To: <53918E681BAF475E99134FF75A4BB5E7@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J> <4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J> <4B7ABFAD.8060403@sun.com>
	<53918E681BAF475E99134FF75A4BB5E7@DB35TT0J>
Message-ID: <4B852D32.4050808@sun.com>

Hello Piet and the team

While the AWT part of the fix is clear and almost done
there are some alternatives
how we should make the best out of it on the Swing side

To make the best decision and get the early feedback from the community
I propose to split the generic support of mouse events
from adding getTransform()/setTransform() on the Swing side.

This is one of the fix which is better to be done step by step.

I filed a new RFE #6929295:
Generic support of mouse event transformation for AWT/Swing

Fixing it will enable the users to easily use
affine transforms for custom Swing components,
which is a fine addition itself.

The next steps will be certainly discussed
shortly after that

Piet, could you please make a new webrev for 6929295?

It should be basically the same fix as for 6899434
but with no changes in JLayer

It would be really great if we manage to do only with
toLayoutSpace()/toRenderedSpace() methods
without using JComponent.inverseTransformVisibleRectangle()

I hope you can emulate it by transforming the corner points of the 
rectangle with toLayoutSpace() method and using its bounds
inside the JComponent.computeVisibleRect() method.

For the default case (no transforms, rectangles only) it will be cheap
and will simplify the usage of the new feature for the Swing developers.

Thanks
alexp

>
> Hi Artem
>
>
>>
>> On 2/16/2010 6:12 PM, Piet Blok wrote:
>>> Hi Artem
>>>
>>>> Hi, Piet,
>>>>
>>>> the fix looks pretty good in general. Some small comments:
>>>>
>>>> 1. As we're about to introduce 2 new public methods into Container, we
>>>> need to provide a description of "layout space" and "render space". I
>>>> hope you or Alex will take care of this.
>>>
>>> What about the following descriptions?
>>>
>>> Layout space refers to user space (coordinates in the layout system).
>>> Rendered space refers to device space (coordinates on the screen).
>>> Please see (link to) AffineTransform.
>>
>> Probably, we should mention that layout coordinates are the ones used
>> by LayoutManager and other Container stuff. For example,
>> Component.getBounds() always returns layout rectangle, not rendered one.
>
> Ok, good addition. I'll add that clarification.
>
>>
>>>> 2. Could toRenderedSpace() throw NoninvertibleTransformException as
>>>> well?
>>>
>>> No. toRenderedSpace() is a direct transformation with any of
>>> AffineTransform's transform() methods.
>>> This in contrast to inverse operations as used in toLayoutSpace(), like
>>> AffineTransform's createInverse() and inverseTransform() methods that
>>> may throw this exception.
>>
>> It depends on what we consider a forward transform and a reverse
>> transform :) And don't forget there may be non-affine transforms...
>
> Any transform, be it affine or non-affine is able by definition to
> transform, otherwise it's not a transform :-)
>
> Only inverse transform can be problematic. That is, when two different
> points, after transformation, result in the same point. Valid during
> transform. But impossible to do an inverse. Analogous to multiplying by
> zero is valid, but the operation can't be inversed.
>
>>
>>>> 3. getRenderedSpaceShift() - should we traverse containers up to null
>>>> or up to the nativeContainer?
>>>
>>> Good point. For testing I added a test "not nativeContainer" to the null
>>> test and everything still works (in my own test suite that is far more
>>> complex than the provided jtreg test cases).
>>>
>>> getRenderedSpaceShift() is invoked from eventDispatched. It should do a
>>> traversal that is analogous to the traversal there.
>>>
>>> In general, I'm not sure about the role of "nativeContainer" and how it
>>> is used. For example, I don't know if (one or more) native containers
>>> can be present in the hierachy between a Window and the lowest child
>>> component. Or is the top Window always the native container? If this is
>>> not the case, could you depict some hierarchy example where a native
>>> container is a child somewhere in the hierarchy of a JLayer's view? Then
>>> I can do a more comprehensive test.
>>
>> nativeContainer is a basic part of LightweightDispatcher machinery: it
>> is the container, always heavyweight, which is served by the
>> dispatcher. An obvious example is how all the mouse events are
>> dispatched: we (AWT) receive events for heavyweight components only as
>> the underlying OS isn't aware of our lightweight Swing components.
>> When the event is dispatched to a heavyweight container, it's
>> lightweight dispatcher retargets it to a proper lightweight child.
>>
>> Given that we won't support transformations for heavyweight components
>> (BTW, it should also be reflected in JavaDoc), it's enough to care
>> about nativeContainer children only.
>
>
> 1) I'll add a remark to the new public methods that they only apply to
> lightweight components.
> 2) I'll study your remarks and decide if I'll add a check on
> nativeContainer.
>
> I'll let you know if and when a version 3.2 is available.
>
> Thanks,
> Piet
>
>>
>>> Please let me know, so I can prepare a version 3.2 if needed (and add
>>> the descriptions at the same time)
>>
>> 3.2 is only required if you make any significant changes based on the
>> current discussion.
>>
>> Thanks,
>>
>> Artem
>>
>>> Thanks,
>>> Piet.
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>>>>
>>>>> Hi Artem,
>>>>>
>>>>> The webrev for version 3.1:
>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>>>>
>>>>>
>>>>>> Hi, Piet,
>>>>>>
>>>>>> the 3rd version looks really great! I haven't looked to Swing code
>>>>>> much, though :)
>>>>>>
>>>>>> A small suggestion is to unify getRenderedSpaceShift() and
>>>>>> getLayoutSpaceShift(), so they both accept a Component and a Point to
>>>>>> translate. Could they also be static methods? It seems not, as I
>>>>>> see a
>>>>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>>>>
>>>>> I unified both methods and made them static after adding
>>>>> nativeContainer
>>>>> as a parameter to both. Their signature is now:
>>>>>
>>>>> private static Point getXXXSpaceShift(Component target, Point
>>>>> dstPoint,
>>>>> Container nativeContainer)
>>>>>
>>>>> (the nativeContainer argument is used in only one of the methods)
>>>>>
>>>>> For the swing guys: in SwingUtilities and RepaintManager, where
>>>>> iterating over the parent hierarchy, I added a check to "parent !=
>>>>> null"
>>>>> to also check "!(parent instanceof Window)".
>>>>>
>>>>> Thanks,
>>>>> Piet
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Please find a third version for the webrev here:
>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>>>>
>>>>>>> AWTAccessor removed again
>>>>>>>
>>>>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>>>>
>>>>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>>>>> getLayoutSpaceShift(). The latter because it is called from
>>>>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>>>>> hierarchy translation value.
>>>>>>>
>>>>>>> Indented the try block
>>>>>>>
>>>>>>> Added some jtreg test cases, one a manual test.
>>>>>>>
>>>>>>> Please review again
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Piet
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Anthony,
>>>>>>>>
>>>>>>>>> Hi Piet,
>>>>>>>>>
>>>>>>>>> The version #2 looks very good.
>>>>>>>>
>>>>>>>> Looks, yes. Unfortunately, later I detected that it doesn't work.
>>>>>>>> It's
>>>>>>>> missing something. Oh yes, I carried out a comprehensive manual
>>>>>>>> test
>>>>>>>> but the test setup was wrong: I tested against the version 1! (A
>>>>>>>> jtreg
>>>>>>>> test was carried out against version 2 and was succesfull).
>>>>>>>>
>>>>>>>> I'll try to manually add a remark to that webrev to state that it's
>>>>>>>> invalid and should not be used.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>>>>>> AWTAccessor.
>>>>>>>>>
>>>>>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>>>>>> right? That would be great.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>>>>>> Container implementation does nothing.
>>>>>>>>>>
>>>>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>>>>> private and static, but will be rewritten to use
>>>>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>>>>
>>>>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>>>>>> course be removed.
>>>>>>>>>
>>>>>>>>> I like the proposal.
>>>>>>>>
>>>>>>>> As said, something was missing: A
>>>>>>>> Container.toRenderedSpace(point) is
>>>>>>>> needed as well. This method must return the normal transformed
>>>>>>>> point,
>>>>>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>>>>>> point.
>>>>>>>>
>>>>>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>>>>>> option open for implementers to choose for a transformation other
>>>>>>>> than
>>>>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to
>>>>>>>> know how
>>>>>>>> one would implement the actual rendering, but that's beside the
>>>>>>>> point).
>>>>>>>>
>>>>>>>>>
>>>>>>>>> A minor comment regarding the code:
>>>>>>>>>
>>>>>>>>> src/share/classes/java/awt/Container.java
>>>>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>>>>
>>>>>>>>> I suggest to use the getContainer() method instead. If the comp
>>>>>>>>> is a
>>>>>>>>> window, the getParent() may actually return an owner of the
>>>>>>>>> window,
>>>>>>>>> which we certainly don't want to deal with.
>>>>>>>>
>>>>>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also, please make sure you format the code according the
>>>>>>>>> guidelines:
>>>>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>>>>> correctly indented.
>>>>>>>>
>>>>>>>> This I was wondering about: should I or shouldn't I (touch code
>>>>>>>> that
>>>>>>>> is otherwise not altered). Now I know, thanks.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Otherwise looks fine. Thanks!
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, I'm working on version 3. And this time actually testing
>>>>>>>> against
>>>>>>>> this same version 3! I'm still working on some more simple jtreg
>>>>>>>> test
>>>>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Piet
>>>>>>>>
>>>>>>>>> --
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Please let me know if you agree.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Piet
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Artem
>>>>>>>>>>>
>>>>>>>>>>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>>>>>>>>>>> Hi Artem,
>>>>>>>>>>>>
>>>>>>>>>>>> To demonstrate the implemention via the AWTAccessor pattern, I
>>>>>>>>>>>> created a
>>>>>>>>>>>> version 2 implementation:
>>>>>>>>>>>>
>>>>>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>>>>>>>>>>
>>>>>>>>>>>> This implementation is much cleaner than the original one.
>>>>>>>>>>>>
>>>>>>>>>>>> Looking forward for yout comments,
>>>>>>>>>>>> Piet
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Artem,
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem with making existing methods public is that it
>>>>>>>>>>>>> solves
>>>>>>>>>>>>> only
>>>>>>>>>>>>> half of the problem at hand:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) Locate the correct component (can be solved)
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2) Recalculating the mouse point from rendered space to layout
>>>>>>>>>>>>> space
>>>>>>>>>>>>> is not solved because the locating methods only return a
>>>>>>>>>>>>> component.
>>>>>>>>>>>>> Recalculation is needed to correctly set a mouse point in the
>>>>>>>>>>>>> new
>>>>>>>>>>>>> events, relative to the target component.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In my proposed implementation the shift caused by
>>>>>>>>>>>>> transformations is
>>>>>>>>>>>>> stored when looking up the target (for future use: creating
>>>>>>>>>>>>> new
>>>>>>>>>>>>> events
>>>>>>>>>>>>> from the original event). This future is quite an immediate
>>>>>>>>>>>>> future
>>>>>>>>>>>>> because creating a new event from an existing event will
>>>>>>>>>>>>> always be
>>>>>>>>>>>>> directly preceded by looking up that target event.
>>>>>>>>>>>>>
>>>>>>>>>>>>> An alternative would be to again iterate through the hierarchy
>>>>>>>>>>>>> and do
>>>>>>>>>>>>> the transformations. This must be done in
>>>>>>>>>>>>> LightweightDispatcher
>>>>>>>>>>>>> in the
>>>>>>>>>>>>> methods:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) retargetMouseEvent (an inverse transform is needed, so the
>>>>>>>>>>>>> new
>>>>>>>>>>>>> Container method getConvertedPoint can be used)
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2) eventDispatched. Unfortunately here an ordinary
>>>>>>>>>>>>> transform is
>>>>>>>>>>>>> needed, so a second new Container method must be defined that
>>>>>>>>>>>>> does an
>>>>>>>>>>>>> ordinary transform.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But.... a completely different approach is also possible. I
>>>>>>>>>>>>> did
>>>>>>>>>>>>> this
>>>>>>>>>>>>> in an earlier version, so I know that it works. With this
>>>>>>>>>>>>> approach no
>>>>>>>>>>>>> new public or protected methods need to be introduced and no
>>>>>>>>>>>>> existing
>>>>>>>>>>>>> methods need to go public or protected. All remains private or
>>>>>>>>>>>>> package
>>>>>>>>>>>>> private.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That approach is as follows:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) Define the AffineTransform as a private field in Component.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2) Use the AWTAccessor pattern to make the transform
>>>>>>>>>>>>> available in
>>>>>>>>>>>>> Container and LightweightDispatcher and in swing classes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3) In Container and LightweightDispatcher, get the transform
>>>>>>>>>>>>> and do
>>>>>>>>>>>>> transformations when needed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In my opinion, the solution with the AWTAccessor pattern is
>>>>>>>>>>>>> the
>>>>>>>>>>>>> cleanest. However, it requires Component and AWTAccessor to be
>>>>>>>>>>>>> touched.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi, Piet,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I haven't looked through the entire webrev and inspected
>>>>>>>>>>>>>> mostly an
>>>>>>>>>>>>>> AWT part of the fix. A question is whether it's possible to
>>>>>>>>>>>>>> get rid
>>>>>>>>>>>>>> of the new "conversionShift" field in Container, to make
>>>>>>>>>>>>>> transformations support really stateless?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Another option to consider is to make some of the existing
>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>> (e.g. getMouseEventTargetImpl()) public instead of
>>>>>>>>>>>>>> introducing
>>>>>>>>>>>>>> new ones.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Artem
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>>>>>>>>>>> Hello all,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> review request for 6899434: Add affine transform support to
>>>>>>>>>>>>>>> JLayer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The patch covers all the requested functionality. It is
>>>>>>>>>>>>>>> concentrated in
>>>>>>>>>>>>>>> JLayer class, keeping in mind to affect the library as
>>>>>>>>>>>>>>> little as
>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2) The paint method in JLayer has been adapted to use the
>>>>>>>>>>>>>>> transform
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 3) RepaintManager has been adapted to propagate repaint
>>>>>>>>>>>>>>> requests from
>>>>>>>>>>>>>>> the view or any of its children to the top level JLayer and
>>>>>>>>>>>>>>> have the
>>>>>>>>>>>>>>> dirty region transformed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher
>>>>>>>>>>>>>>> (both
>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>> same source) have been adapted to redispatch MouseEvents to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> intended
>>>>>>>>>>>>>>> target component. The lookup for the component that
>>>>>>>>>>>>>>> provides a
>>>>>>>>>>>>>>> custon
>>>>>>>>>>>>>>> cursor has also been adapted.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 5) To enable Container to do necessary reculculations, a
>>>>>>>>>>>>>>> protected
>>>>>>>>>>>>>>> method has been introduced that will be overridden by
>>>>>>>>>>>>>>> JLayer:
>>>>>>>>>>>>>>> protected Point getConvertedPoint(Point point).
>>>>>>>>>>>>>>> (If someone can suggest a better name for this method I'm
>>>>>>>>>>>>>>> glad
>>>>>>>>>>>>>>> to hear)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 6) A package private method in SwingUtilities has been added
>>>>>>>>>>>>>>> that helps
>>>>>>>>>>>>>>> JPopupMenu and ToolTipManager to find the correct popup
>>>>>>>>>>>>>>> location.
>>>>>>>>>>>>>>> JPopupMenu and ToolTipManager have been changed to use this
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>> in their calculations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 7) Two jtreg tests have been added.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Looking forward for comments.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From pbhome at ziggo.nl  Wed Feb 24 06:26:40 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Wed, 24 Feb 2010 15:26:40 +0100
Subject: <AWT Dev> Fw: <Swing Dev>
	Fw:reviewrequestfor6899434:Addaffinetransformsupport to JLayer
Message-ID: <87AB7BF2634E4DFB9A7FFA774A4A2DCB@DB35TT0J>


Forgot to send it to the awt list.
Piet


> Hi All,
>
>
>
>> Hello Piet and the team
>>
>> While the AWT part of the fix is clear and almost done
>> there are some alternatives
>> how we should make the best out of it on the Swing side
>>
>> To make the best decision and get the early feedback from the community
>> I propose to split the generic support of mouse events
>> from adding getTransform()/setTransform() on the Swing side.
>>
>> This is one of the fix which is better to be done step by step.
>>
>> I filed a new RFE #6929295:
>> Generic support of mouse event transformation for AWT/Swing
>>
>> Fixing it will enable the users to easily use
>> affine transforms for custom Swing components,
>> which is a fine addition itself.
>>
>> The next steps will be certainly discussed
>> shortly after that
>>
>> Piet, could you please make a new webrev for 6929295?
>>
>> It should be basically the same fix as for 6899434
>> but with no changes in JLayer
>
> Done. Please see here http://www.pbjar.org/OpenJDK/6929295/webrev/
>
> (It is created from the same respository, hence the misleading name 
> insiade the webrev)
>
> I couldn't find rfe 6929295 in the bug database. Perhaps it's not yet 
> publicly available?
>
> Changes versus the last version v3.2:
>
> 1) Added a check on nativeContainer (I don't think it is necessary, but it 
> doesn't hurt)
> 2) Edited the API doc for the two new methods
>
>>
>> It would be really great if we manage to do only with
>> toLayoutSpace()/toRenderedSpace() methods
>> without using JComponent.inverseTransformVisibleRectangle()
>>
>> I hope you can emulate it by transforming the corner points of the 
>> rectangle with toLayoutSpace() method and using its bounds
>> inside the JComponent.computeVisibleRect() method.
>
> Technically such a computation is possible. However, the 
> JLayer.inverseTransformVisibleRectangle() does something more:
> it intersect the resulting rectangle with the transformed view bounds. But 
> let's discuss that later.
>
>>
>> For the default case (no transforms, rectangles only) it will be cheap
>> and will simplify the usage of the new feature for the Swing developers.
>>
>> Thanks
>> alexp
>>
>>>
>>> Hi Artem
>>>
>>>
>>>>
>>>> On 2/16/2010 6:12 PM, Piet Blok wrote:
>>>>> Hi Artem
>>>>>
>>>>>> Hi, Piet,
>>>>>>
>>>>>> the fix looks pretty good in general. Some small comments:
>>>>>>
>>>>>> 1. As we're about to introduce 2 new public methods into Container, 
>>>>>> we
>>>>>> need to provide a description of "layout space" and "render space". I
>>>>>> hope you or Alex will take care of this.
>>>>>
>>>>> What about the following descriptions?
>>>>>
>>>>> Layout space refers to user space (coordinates in the layout system).
>>>>> Rendered space refers to device space (coordinates on the screen).
>>>>> Please see (link to) AffineTransform.
>>>>
>>>> Probably, we should mention that layout coordinates are the ones used
>>>> by LayoutManager and other Container stuff. For example,
>>>> Component.getBounds() always returns layout rectangle, not rendered 
>>>> one.
>>>
>>> Ok, good addition. I'll add that clarification.
>>>
>>>>
>>>>>> 2. Could toRenderedSpace() throw NoninvertibleTransformException as
>>>>>> well?
>>>>>
>>>>> No. toRenderedSpace() is a direct transformation with any of
>>>>> AffineTransform's transform() methods.
>>>>> This in contrast to inverse operations as used in toLayoutSpace(), 
>>>>> like
>>>>> AffineTransform's createInverse() and inverseTransform() methods that
>>>>> may throw this exception.
>>>>
>>>> It depends on what we consider a forward transform and a reverse
>>>> transform :) And don't forget there may be non-affine transforms...
>>>
>>> Any transform, be it affine or non-affine is able by definition to
>>> transform, otherwise it's not a transform :-)
>>>
>>> Only inverse transform can be problematic. That is, when two different
>>> points, after transformation, result in the same point. Valid during
>>> transform. But impossible to do an inverse. Analogous to multiplying by
>>> zero is valid, but the operation can't be inversed.
>>>
>>>>
>>>>>> 3. getRenderedSpaceShift() - should we traverse containers up to null
>>>>>> or up to the nativeContainer?
>>>>>
>>>>> Good point. For testing I added a test "not nativeContainer" to the 
>>>>> null
>>>>> test and everything still works (in my own test suite that is far more
>>>>> complex than the provided jtreg test cases).
>>>>>
>>>>> getRenderedSpaceShift() is invoked from eventDispatched. It should do 
>>>>> a
>>>>> traversal that is analogous to the traversal there.
>>>>>
>>>>> In general, I'm not sure about the role of "nativeContainer" and how 
>>>>> it
>>>>> is used. For example, I don't know if (one or more) native containers
>>>>> can be present in the hierachy between a Window and the lowest child
>>>>> component. Or is the top Window always the native container? If this 
>>>>> is
>>>>> not the case, could you depict some hierarchy example where a native
>>>>> container is a child somewhere in the hierarchy of a JLayer's view? 
>>>>> Then
>>>>> I can do a more comprehensive test.
>>>>
>>>> nativeContainer is a basic part of LightweightDispatcher machinery: it
>>>> is the container, always heavyweight, which is served by the
>>>> dispatcher. An obvious example is how all the mouse events are
>>>> dispatched: we (AWT) receive events for heavyweight components only as
>>>> the underlying OS isn't aware of our lightweight Swing components.
>>>> When the event is dispatched to a heavyweight container, it's
>>>> lightweight dispatcher retargets it to a proper lightweight child.
>>>>
>>>> Given that we won't support transformations for heavyweight components
>>>> (BTW, it should also be reflected in JavaDoc), it's enough to care
>>>> about nativeContainer children only.
>>>
>>>
>>> 1) I'll add a remark to the new public methods that they only apply to
>>> lightweight components.
>>> 2) I'll study your remarks and decide if I'll add a check on
>>> nativeContainer.
>>>
>>> I'll let you know if and when a version 3.2 is available.
>>>
>>> Thanks,
>>> Piet
>>>
>>>>
>>>>> Please let me know, so I can prepare a version 3.2 if needed (and add
>>>>> the descriptions at the same time)
>>>>
>>>> 3.2 is only required if you make any significant changes based on the
>>>> current discussion.
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>>> Thanks,
>>>>> Piet.
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>>>>>>
>>>>>>> Hi Artem,
>>>>>>>
>>>>>>> The webrev for version 3.1:
>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>>>>>>
>>>>>>>
>>>>>>>> Hi, Piet,
>>>>>>>>
>>>>>>>> the 3rd version looks really great! I haven't looked to Swing code
>>>>>>>> much, though :)
>>>>>>>>
>>>>>>>> A small suggestion is to unify getRenderedSpaceShift() and
>>>>>>>> getLayoutSpaceShift(), so they both accept a Component and a Point 
>>>>>>>> to
>>>>>>>> translate. Could they also be static methods? It seems not, as I
>>>>>>>> see a
>>>>>>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>>>>>>
>>>>>>> I unified both methods and made them static after adding
>>>>>>> nativeContainer
>>>>>>> as a parameter to both. Their signature is now:
>>>>>>>
>>>>>>> private static Point getXXXSpaceShift(Component target, Point
>>>>>>> dstPoint,
>>>>>>> Container nativeContainer)
>>>>>>>
>>>>>>> (the nativeContainer argument is used in only one of the methods)
>>>>>>>
>>>>>>> For the swing guys: in SwingUtilities and RepaintManager, where
>>>>>>> iterating over the parent hierarchy, I added a check to "parent !=
>>>>>>> null"
>>>>>>> to also check "!(parent instanceof Window)".
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Piet
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Artem
>>>>>>>>
>>>>>>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Please find a third version for the webrev here:
>>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>>>>>>
>>>>>>>>> AWTAccessor removed again
>>>>>>>>>
>>>>>>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>>>>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>>>>>>
>>>>>>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>>>>>>> getLayoutSpaceShift(). The latter because it is called from
>>>>>>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>>>>>>> hierarchy translation value.
>>>>>>>>>
>>>>>>>>> Indented the try block
>>>>>>>>>
>>>>>>>>> Added some jtreg test cases, one a manual test.
>>>>>>>>>
>>>>>>>>> Please review again
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Piet
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Anthony,
>>>>>>>>>>
>>>>>>>>>>> Hi Piet,
>>>>>>>>>>>
>>>>>>>>>>> The version #2 looks very good.
>>>>>>>>>>
>>>>>>>>>> Looks, yes. Unfortunately, later I detected that it doesn't work.
>>>>>>>>>> It's
>>>>>>>>>> missing something. Oh yes, I carried out a comprehensive manual
>>>>>>>>>> test
>>>>>>>>>> but the test setup was wrong: I tested against the version 1! (A
>>>>>>>>>> jtreg
>>>>>>>>>> test was carried out against version 2 and was succesfull).
>>>>>>>>>>
>>>>>>>>>> I'll try to manually add a remark to that webrev to state that 
>>>>>>>>>> it's
>>>>>>>>>> invalid and should not be used.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>>>>>>>> AWTAccessor.
>>>>>>>>>>>
>>>>>>>>>>> So that the Component.transform is moved over to the JLayer 
>>>>>>>>>>> class,
>>>>>>>>>>> right? That would be great.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>>>>>>>> Container implementation does nothing.
>>>>>>>>>>>>
>>>>>>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>>>>>>> private and static, but will be rewritten to use
>>>>>>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>>>>>>
>>>>>>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will 
>>>>>>>>>>>> of
>>>>>>>>>>>> course be removed.
>>>>>>>>>>>
>>>>>>>>>>> I like the proposal.
>>>>>>>>>>
>>>>>>>>>> As said, something was missing: A
>>>>>>>>>> Container.toRenderedSpace(point) is
>>>>>>>>>> needed as well. This method must return the normal transformed
>>>>>>>>>> point,
>>>>>>>>>> as opposed to toLayoutSpace() that returns the inverse 
>>>>>>>>>> transformed
>>>>>>>>>> point.
>>>>>>>>>>
>>>>>>>>>> And yes, like Artem pointed out in an earlier post, this leaves 
>>>>>>>>>> the
>>>>>>>>>> option open for implementers to choose for a transformation other
>>>>>>>>>> than
>>>>>>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to
>>>>>>>>>> know how
>>>>>>>>>> one would implement the actual rendering, but that's beside the
>>>>>>>>>> point).
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> A minor comment regarding the code:
>>>>>>>>>>>
>>>>>>>>>>> src/share/classes/java/awt/Container.java
>>>>>>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>>>>>>
>>>>>>>>>>> I suggest to use the getContainer() method instead. If the comp
>>>>>>>>>>> is a
>>>>>>>>>>> window, the getParent() may actually return an owner of the
>>>>>>>>>>> window,
>>>>>>>>>>> which we certainly don't want to deal with.
>>>>>>>>>>
>>>>>>>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Also, please make sure you format the code according the
>>>>>>>>>>> guidelines:
>>>>>>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>>>>>>> correctly indented.
>>>>>>>>>>
>>>>>>>>>> This I was wondering about: should I or shouldn't I (touch code
>>>>>>>>>> that
>>>>>>>>>> is otherwise not altered). Now I know, thanks.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Otherwise looks fine. Thanks!
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ok, I'm working on version 3. And this time actually testing
>>>>>>>>>> against
>>>>>>>>>> this same version 3! I'm still working on some more simple jtreg
>>>>>>>>>> test
>>>>>>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Piet
>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> best regards,
>>>>>>>>>>> Anthony
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Please let me know if you agree.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Piet
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Artem
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>>>>>>>>>>>>> Hi Artem,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To demonstrate the implemention via the AWTAccessor pattern, 
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> created a
>>>>>>>>>>>>>> version 2 implementation:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This implementation is much cleaner than the original one.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looking forward for yout comments,
>>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Artem,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The problem with making existing methods public is that it
>>>>>>>>>>>>>>> solves
>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>> half of the problem at hand:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) Locate the correct component (can be solved)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2) Recalculating the mouse point from rendered space to 
>>>>>>>>>>>>>>> layout
>>>>>>>>>>>>>>> space
>>>>>>>>>>>>>>> is not solved because the locating methods only return a
>>>>>>>>>>>>>>> component.
>>>>>>>>>>>>>>> Recalculation is needed to correctly set a mouse point in 
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> events, relative to the target component.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In my proposed implementation the shift caused by
>>>>>>>>>>>>>>> transformations is
>>>>>>>>>>>>>>> stored when looking up the target (for future use: creating
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> events
>>>>>>>>>>>>>>> from the original event). This future is quite an immediate
>>>>>>>>>>>>>>> future
>>>>>>>>>>>>>>> because creating a new event from an existing event will
>>>>>>>>>>>>>>> always be
>>>>>>>>>>>>>>> directly preceded by looking up that target event.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> An alternative would be to again iterate through the 
>>>>>>>>>>>>>>> hierarchy
>>>>>>>>>>>>>>> and do
>>>>>>>>>>>>>>> the transformations. This must be done in
>>>>>>>>>>>>>>> LightweightDispatcher
>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>> methods:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) retargetMouseEvent (an inverse transform is needed, so 
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> Container method getConvertedPoint can be used)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2) eventDispatched. Unfortunately here an ordinary
>>>>>>>>>>>>>>> transform is
>>>>>>>>>>>>>>> needed, so a second new Container method must be defined 
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> does an
>>>>>>>>>>>>>>> ordinary transform.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But.... a completely different approach is also possible. I
>>>>>>>>>>>>>>> did
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> in an earlier version, so I know that it works. With this
>>>>>>>>>>>>>>> approach no
>>>>>>>>>>>>>>> new public or protected methods need to be introduced and no
>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>> methods need to go public or protected. All remains private 
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>> package
>>>>>>>>>>>>>>> private.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That approach is as follows:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) Define the AffineTransform as a private field in 
>>>>>>>>>>>>>>> Component.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2) Use the AWTAccessor pattern to make the transform
>>>>>>>>>>>>>>> available in
>>>>>>>>>>>>>>> Container and LightweightDispatcher and in swing classes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 3) In Container and LightweightDispatcher, get the transform
>>>>>>>>>>>>>>> and do
>>>>>>>>>>>>>>> transformations when needed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In my opinion, the solution with the AWTAccessor pattern is
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> cleanest. However, it requires Component and AWTAccessor to 
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> touched.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi, Piet,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I haven't looked through the entire webrev and inspected
>>>>>>>>>>>>>>>> mostly an
>>>>>>>>>>>>>>>> AWT part of the fix. A question is whether it's possible to
>>>>>>>>>>>>>>>> get rid
>>>>>>>>>>>>>>>> of the new "conversionShift" field in Container, to make
>>>>>>>>>>>>>>>> transformations support really stateless?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Another option to consider is to make some of the existing
>>>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>> (e.g. getMouseEventTargetImpl()) public instead of
>>>>>>>>>>>>>>>> introducing
>>>>>>>>>>>>>>>> new ones.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Artem
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>>>>>>>>>>>>> Hello all,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> review request for 6899434: Add affine transform support 
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> JLayer
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The patch covers all the requested functionality. It is
>>>>>>>>>>>>>>>>> concentrated in
>>>>>>>>>>>>>>>>> JLayer class, keeping in mind to affect the library as
>>>>>>>>>>>>>>>>> little as
>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2) The paint method in JLayer has been adapted to use the
>>>>>>>>>>>>>>>>> transform
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 3) RepaintManager has been adapted to propagate repaint
>>>>>>>>>>>>>>>>> requests from
>>>>>>>>>>>>>>>>> the view or any of its children to the top level JLayer 
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> have the
>>>>>>>>>>>>>>>>> dirty region transformed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher
>>>>>>>>>>>>>>>>> (both
>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>> same source) have been adapted to redispatch MouseEvents 
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> intended
>>>>>>>>>>>>>>>>> target component. The lookup for the component that
>>>>>>>>>>>>>>>>> provides a
>>>>>>>>>>>>>>>>> custon
>>>>>>>>>>>>>>>>> cursor has also been adapted.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 5) To enable Container to do necessary reculculations, a
>>>>>>>>>>>>>>>>> protected
>>>>>>>>>>>>>>>>> method has been introduced that will be overridden by
>>>>>>>>>>>>>>>>> JLayer:
>>>>>>>>>>>>>>>>> protected Point getConvertedPoint(Point point).
>>>>>>>>>>>>>>>>> (If someone can suggest a better name for this method I'm
>>>>>>>>>>>>>>>>> glad
>>>>>>>>>>>>>>>>> to hear)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 6) A package private method in SwingUtilities has been 
>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>> that helps
>>>>>>>>>>>>>>>>> JPopupMenu and ToolTipManager to find the correct popup
>>>>>>>>>>>>>>>>> location.
>>>>>>>>>>>>>>>>> JPopupMenu and ToolTipManager have been changed to use 
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>> in their calculations.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 7) Two jtreg tests have been added.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Looking forward for comments.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
> 




From Anthony.Petrov at Sun.COM  Wed Feb 24 06:49:38 2010
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 24 Feb 2010 17:49:38 +0300
Subject: <AWT Dev> <Swing Dev>
	<AWT	Dev>	Fw:reviewrequestfor6899434:Addaffinetransformsupport
	to JLayer
In-Reply-To: <C2D517ADDBD9400D88C328D1889596B2@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J> <4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J> <4B7ABFAD.8060403@sun.com>
	<53918E681BAF475E99134FF75A4BB5E7@DB35TT0J> <4B852C71.1090402@sun.com>
	<C2D517ADDBD9400D88C328D1889596B2@DB35TT0J>
Message-ID: <4B853C82.4010309@sun.com>

Hi Piet, Alex,

On 02/24/2010 05:24 PM, Piet Blok wrote:
>> To make the best decision and get the early feedback from the community
>> I propose to split the generic support of mouse events
>> from adding getTransform()/setTransform() on the Swing side.
>>
>> This is one of the fix which is better to be done step by step.
>>
>> Fixing it will enable the users to easily use
>> affine transforms for custom Swing components,
>> which is a fine addition itself.

Strongly agree!


>> Piet, could you please make a new webrev for 6929295?
>>
> Done. Please see here http://www.pbjar.org/OpenJDK/6929295/webrev/

The fix looks fine. Just been wondering what testing has been performed 
with that fix? Did you try running swing and awt applications with some 
components in their windows, and see if all clicks get correctly 
delivered to lw and hw components?

--
best regards,
Anthony


From pbhome at ziggo.nl  Wed Feb 24 07:29:17 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Wed, 24 Feb 2010 16:29:17 +0100
Subject: <AWT Dev> <Swing
	Dev>	<AWT	Dev>Fw:reviewrequestfor6899434:Addaffinetransformsupport	to
	JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
	<B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
	<4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
	<4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J>
	<4B7ABFAD.8060403@sun.com>
	<53918E681BAF475E99134FF75A4BB5E7@DB35TT0J>
	<4B852C71.1090402@sun.com>
	<C2D517ADDBD9400D88C328D1889596B2@DB35TT0J>
	<4B853B36.6010303@sun.com>
Message-ID: <3CF1C66CF4E44910A24EAF4BF7C34A94@DB35TT0J>

Hi Alex, Anthony and others,

Aha, I misinterpreted the request to only an awt change.

I'll start working on an uptaed implementation on the swing side 
(RepaintManager, JPopupMenu, ToolTipManager and JComponent), only using 
toLayoutSpace and toRendereredSpace in Container.
Then I'll also be able to create a simple test with some custom transforming 
component.

This will take some more time :-)

Thanks Piet


> Hello Piet
>
>>> Piet, could you please make a new webrev for 6929295?
>>>
>>> It should be basically the same fix as for 6899434
>>> but with no changes in JLayer
>>
>> Done. Please see here http://www.pbjar.org/OpenJDK/6929295/webrev/
>
> The main idea is to enable users to easily use transforms in custom Swing 
> components, so we need all the stuff for the RM, ToolTipManager etc..
>
> just JLayer is to be excluded
>
>>
>> (It is created from the same respository, hence the misleading name
>> insiade the webrev)
>>
>> I couldn't find rfe 6929295 in the bug database. Perhaps it's not yet
>> publicly available?
>
> It usually takes a couple of days to show up in the database
>
>>
>> Changes versus the last version v3.2:
>>
>> 1) Added a check on nativeContainer (I don't think it is necessary, but
>> it doesn't hurt)
>> 2) Edited the API doc for the two new methods
>
>
>
>>>
>>> It would be really great if we manage to do only with
>>> toLayoutSpace()/toRenderedSpace() methods
>>> without using JComponent.inverseTransformVisibleRectangle()
>>>
>>> I hope you can emulate it by transforming the corner points of the
>>> rectangle with toLayoutSpace() method and using its bounds
>>> inside the JComponent.computeVisibleRect() method.
>>
>> Technically such a computation is possible. However, the
>> JLayer.inverseTransformVisibleRectangle() does something more:
>> it intersect the resulting rectangle with the transformed view bounds.
>> But let's discuss that later.
>
> Is it possible to implement this computation right now?
>
> I am afraid we also need at least one simple test
> with a custom Swing component with overridden 
> toLayoutSpace()/toRenderedSpace()
>
> Thanks much and sorry for the confusion!
>
> alexp
>
>>
>>>
>>> For the default case (no transforms, rectangles only) it will be cheap
>>> and will simplify the usage of the new feature for the Swing developers.
>>>
>>> Thanks
>>> alexp
>>>
>>>>
>>>> Hi Artem
>>>>
>>>>
>>>>>
>>>>> On 2/16/2010 6:12 PM, Piet Blok wrote:
>>>>>> Hi Artem
>>>>>>
>>>>>>> Hi, Piet,
>>>>>>>
>>>>>>> the fix looks pretty good in general. Some small comments:
>>>>>>>
>>>>>>> 1. As we're about to introduce 2 new public methods into
>>>>>>> Container, we
>>>>>>> need to provide a description of "layout space" and "render space". 
>>>>>>> I
>>>>>>> hope you or Alex will take care of this.
>>>>>>
>>>>>> What about the following descriptions?
>>>>>>
>>>>>> Layout space refers to user space (coordinates in the layout system).
>>>>>> Rendered space refers to device space (coordinates on the screen).
>>>>>> Please see (link to) AffineTransform.
>>>>>
>>>>> Probably, we should mention that layout coordinates are the ones used
>>>>> by LayoutManager and other Container stuff. For example,
>>>>> Component.getBounds() always returns layout rectangle, not rendered
>>>>> one.
>>>>
>>>> Ok, good addition. I'll add that clarification.
>>>>
>>>>>
>>>>>>> 2. Could toRenderedSpace() throw NoninvertibleTransformException as
>>>>>>> well?
>>>>>>
>>>>>> No. toRenderedSpace() is a direct transformation with any of
>>>>>> AffineTransform's transform() methods.
>>>>>> This in contrast to inverse operations as used in toLayoutSpace(),
>>>>>> like
>>>>>> AffineTransform's createInverse() and inverseTransform() methods that
>>>>>> may throw this exception.
>>>>>
>>>>> It depends on what we consider a forward transform and a reverse
>>>>> transform :) And don't forget there may be non-affine transforms...
>>>>
>>>> Any transform, be it affine or non-affine is able by definition to
>>>> transform, otherwise it's not a transform :-)
>>>>
>>>> Only inverse transform can be problematic. That is, when two different
>>>> points, after transformation, result in the same point. Valid during
>>>> transform. But impossible to do an inverse. Analogous to multiplying by
>>>> zero is valid, but the operation can't be inversed.
>>>>
>>>>>
>>>>>>> 3. getRenderedSpaceShift() - should we traverse containers up to 
>>>>>>> null
>>>>>>> or up to the nativeContainer?
>>>>>>
>>>>>> Good point. For testing I added a test "not nativeContainer" to the
>>>>>> null
>>>>>> test and everything still works (in my own test suite that is far 
>>>>>> more
>>>>>> complex than the provided jtreg test cases).
>>>>>>
>>>>>> getRenderedSpaceShift() is invoked from eventDispatched. It should
>>>>>> do a
>>>>>> traversal that is analogous to the traversal there.
>>>>>>
>>>>>> In general, I'm not sure about the role of "nativeContainer" and
>>>>>> how it
>>>>>> is used. For example, I don't know if (one or more) native containers
>>>>>> can be present in the hierachy between a Window and the lowest child
>>>>>> component. Or is the top Window always the native container? If
>>>>>> this is
>>>>>> not the case, could you depict some hierarchy example where a native
>>>>>> container is a child somewhere in the hierarchy of a JLayer's view?
>>>>>> Then
>>>>>> I can do a more comprehensive test.
>>>>>
>>>>> nativeContainer is a basic part of LightweightDispatcher machinery: it
>>>>> is the container, always heavyweight, which is served by the
>>>>> dispatcher. An obvious example is how all the mouse events are
>>>>> dispatched: we (AWT) receive events for heavyweight components only as
>>>>> the underlying OS isn't aware of our lightweight Swing components.
>>>>> When the event is dispatched to a heavyweight container, it's
>>>>> lightweight dispatcher retargets it to a proper lightweight child.
>>>>>
>>>>> Given that we won't support transformations for heavyweight components
>>>>> (BTW, it should also be reflected in JavaDoc), it's enough to care
>>>>> about nativeContainer children only.
>>>>
>>>>
>>>> 1) I'll add a remark to the new public methods that they only apply to
>>>> lightweight components.
>>>> 2) I'll study your remarks and decide if I'll add a check on
>>>> nativeContainer.
>>>>
>>>> I'll let you know if and when a version 3.2 is available.
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>>
>>>>>> Please let me know, so I can prepare a version 3.2 if needed (and add
>>>>>> the descriptions at the same time)
>>>>>
>>>>> 3.2 is only required if you make any significant changes based on the
>>>>> current discussion.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>>> Thanks,
>>>>>> Piet.
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>>>>>>>
>>>>>>>> Hi Artem,
>>>>>>>>
>>>>>>>> The webrev for version 3.1:
>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi, Piet,
>>>>>>>>>
>>>>>>>>> the 3rd version looks really great! I haven't looked to Swing code
>>>>>>>>> much, though :)
>>>>>>>>>
>>>>>>>>> A small suggestion is to unify getRenderedSpaceShift() and
>>>>>>>>> getLayoutSpaceShift(), so they both accept a Component and a
>>>>>>>>> Point to
>>>>>>>>> translate. Could they also be static methods? It seems not, as I
>>>>>>>>> see a
>>>>>>>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>>>>>>>
>>>>>>>> I unified both methods and made them static after adding
>>>>>>>> nativeContainer
>>>>>>>> as a parameter to both. Their signature is now:
>>>>>>>>
>>>>>>>> private static Point getXXXSpaceShift(Component target, Point
>>>>>>>> dstPoint,
>>>>>>>> Container nativeContainer)
>>>>>>>>
>>>>>>>> (the nativeContainer argument is used in only one of the methods)
>>>>>>>>
>>>>>>>> For the swing guys: in SwingUtilities and RepaintManager, where
>>>>>>>> iterating over the parent hierarchy, I added a check to "parent !=
>>>>>>>> null"
>>>>>>>> to also check "!(parent instanceof Window)".
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Piet
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Artem
>>>>>>>>>
>>>>>>>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Please find a third version for the webrev here:
>>>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>>>>>>>
>>>>>>>>>> AWTAccessor removed again
>>>>>>>>>>
>>>>>>>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>>>>>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>>>>>>>
>>>>>>>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>>>>>>>> getLayoutSpaceShift(). The latter because it is called from
>>>>>>>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>>>>>>>> hierarchy translation value.
>>>>>>>>>>
>>>>>>>>>> Indented the try block
>>>>>>>>>>
>>>>>>>>>> Added some jtreg test cases, one a manual test.
>>>>>>>>>>
>>>>>>>>>> Please review again
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Piet
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>
>>>>>>>>>>>> Hi Piet,
>>>>>>>>>>>>
>>>>>>>>>>>> The version #2 looks very good.
>>>>>>>>>>>
>>>>>>>>>>> Looks, yes. Unfortunately, later I detected that it doesn't 
>>>>>>>>>>> work.
>>>>>>>>>>> It's
>>>>>>>>>>> missing something. Oh yes, I carried out a comprehensive manual
>>>>>>>>>>> test
>>>>>>>>>>> but the test setup was wrong: I tested against the version 1! (A
>>>>>>>>>>> jtreg
>>>>>>>>>>> test was carried out against version 2 and was succesfull).
>>>>>>>>>>>
>>>>>>>>>>> I'll try to manually add a remark to that webrev to state that
>>>>>>>>>>> it's
>>>>>>>>>>> invalid and should not be used.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>>>>>>>> 1) The implementation in version 2 will be used but without 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> AWTAccessor.
>>>>>>>>>>>>
>>>>>>>>>>>> So that the Component.transform is moved over to the JLayer
>>>>>>>>>>>> class,
>>>>>>>>>>>> right? That would be great.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> Container implementation does nothing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>>>>>>>> private and static, but will be rewritten to use
>>>>>>>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms()
>>>>>>>>>>>>> will of
>>>>>>>>>>>>> course be removed.
>>>>>>>>>>>>
>>>>>>>>>>>> I like the proposal.
>>>>>>>>>>>
>>>>>>>>>>> As said, something was missing: A
>>>>>>>>>>> Container.toRenderedSpace(point) is
>>>>>>>>>>> needed as well. This method must return the normal transformed
>>>>>>>>>>> point,
>>>>>>>>>>> as opposed to toLayoutSpace() that returns the inverse
>>>>>>>>>>> transformed
>>>>>>>>>>> point.
>>>>>>>>>>>
>>>>>>>>>>> And yes, like Artem pointed out in an earlier post, this
>>>>>>>>>>> leaves the
>>>>>>>>>>> option open for implementers to choose for a transformation 
>>>>>>>>>>> other
>>>>>>>>>>> than
>>>>>>>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to
>>>>>>>>>>> know how
>>>>>>>>>>> one would implement the actual rendering, but that's beside the
>>>>>>>>>>> point).
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> A minor comment regarding the code:
>>>>>>>>>>>>
>>>>>>>>>>>> src/share/classes/java/awt/Container.java
>>>>>>>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>>>>>>>
>>>>>>>>>>>> I suggest to use the getContainer() method instead. If the comp
>>>>>>>>>>>> is a
>>>>>>>>>>>> window, the getParent() may actually return an owner of the
>>>>>>>>>>>> window,
>>>>>>>>>>>> which we certainly don't want to deal with.
>>>>>>>>>>>
>>>>>>>>>>> Aha, wasn't aware of getContainer() (package private). Very 
>>>>>>>>>>> good.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Also, please make sure you format the code according the
>>>>>>>>>>>> guidelines:
>>>>>>>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>>>>>>>> correctly indented.
>>>>>>>>>>>
>>>>>>>>>>> This I was wondering about: should I or shouldn't I (touch code
>>>>>>>>>>> that
>>>>>>>>>>> is otherwise not altered). Now I know, thanks.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Otherwise looks fine. Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ok, I'm working on version 3. And this time actually testing
>>>>>>>>>>> against
>>>>>>>>>>> this same version 3! I'm still working on some more simple jtreg
>>>>>>>>>>> test
>>>>>>>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Piet
>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> best regards,
>>>>>>>>>>>> Anthony
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please let me know if you agree.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Artem
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>>>>>>>>>>>>>> Hi Artem,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To demonstrate the implemention via the AWTAccessor
>>>>>>>>>>>>>>> pattern, I
>>>>>>>>>>>>>>> created a
>>>>>>>>>>>>>>> version 2 implementation:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This implementation is much cleaner than the original one.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Looking forward for yout comments,
>>>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Artem,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The problem with making existing methods public is that it
>>>>>>>>>>>>>>>> solves
>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>> half of the problem at hand:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1) Locate the correct component (can be solved)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2) Recalculating the mouse point from rendered space to
>>>>>>>>>>>>>>>> layout
>>>>>>>>>>>>>>>> space
>>>>>>>>>>>>>>>> is not solved because the locating methods only return a
>>>>>>>>>>>>>>>> component.
>>>>>>>>>>>>>>>> Recalculation is needed to correctly set a mouse point in
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> events, relative to the target component.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In my proposed implementation the shift caused by
>>>>>>>>>>>>>>>> transformations is
>>>>>>>>>>>>>>>> stored when looking up the target (for future use: creating
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> events
>>>>>>>>>>>>>>>> from the original event). This future is quite an immediate
>>>>>>>>>>>>>>>> future
>>>>>>>>>>>>>>>> because creating a new event from an existing event will
>>>>>>>>>>>>>>>> always be
>>>>>>>>>>>>>>>> directly preceded by looking up that target event.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> An alternative would be to again iterate through the
>>>>>>>>>>>>>>>> hierarchy
>>>>>>>>>>>>>>>> and do
>>>>>>>>>>>>>>>> the transformations. This must be done in
>>>>>>>>>>>>>>>> LightweightDispatcher
>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>> methods:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1) retargetMouseEvent (an inverse transform is needed, so
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> Container method getConvertedPoint can be used)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2) eventDispatched. Unfortunately here an ordinary
>>>>>>>>>>>>>>>> transform is
>>>>>>>>>>>>>>>> needed, so a second new Container method must be defined
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> does an
>>>>>>>>>>>>>>>> ordinary transform.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But.... a completely different approach is also possible. I
>>>>>>>>>>>>>>>> did
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> in an earlier version, so I know that it works. With this
>>>>>>>>>>>>>>>> approach no
>>>>>>>>>>>>>>>> new public or protected methods need to be introduced and 
>>>>>>>>>>>>>>>> no
>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>> methods need to go public or protected. All remains
>>>>>>>>>>>>>>>> private or
>>>>>>>>>>>>>>>> package
>>>>>>>>>>>>>>>> private.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That approach is as follows:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1) Define the AffineTransform as a private field in
>>>>>>>>>>>>>>>> Component.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2) Use the AWTAccessor pattern to make the transform
>>>>>>>>>>>>>>>> available in
>>>>>>>>>>>>>>>> Container and LightweightDispatcher and in swing classes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3) In Container and LightweightDispatcher, get the 
>>>>>>>>>>>>>>>> transform
>>>>>>>>>>>>>>>> and do
>>>>>>>>>>>>>>>> transformations when needed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In my opinion, the solution with the AWTAccessor pattern is
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> cleanest. However, it requires Component and AWTAccessor
>>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>>> touched.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please let me know what you think.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi, Piet,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I haven't looked through the entire webrev and inspected
>>>>>>>>>>>>>>>>> mostly an
>>>>>>>>>>>>>>>>> AWT part of the fix. A question is whether it's possible 
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> get rid
>>>>>>>>>>>>>>>>> of the new "conversionShift" field in Container, to make
>>>>>>>>>>>>>>>>> transformations support really stateless?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Another option to consider is to make some of the existing
>>>>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>>> (e.g. getMouseEventTargetImpl()) public instead of
>>>>>>>>>>>>>>>>> introducing
>>>>>>>>>>>>>>>>> new ones.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Artem
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>>>>>>>>>>>>>> Hello all,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> review request for 6899434: Add affine transform
>>>>>>>>>>>>>>>>>> support to
>>>>>>>>>>>>>>>>>> JLayer
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The patch covers all the requested functionality. It is
>>>>>>>>>>>>>>>>>> concentrated in
>>>>>>>>>>>>>>>>>> JLayer class, keeping in mind to affect the library as
>>>>>>>>>>>>>>>>>> little as
>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2) The paint method in JLayer has been adapted to use the
>>>>>>>>>>>>>>>>>> transform
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 3) RepaintManager has been adapted to propagate repaint
>>>>>>>>>>>>>>>>>> requests from
>>>>>>>>>>>>>>>>>> the view or any of its children to the top level JLayer
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> have the
>>>>>>>>>>>>>>>>>> dirty region transformed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher
>>>>>>>>>>>>>>>>>> (both
>>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>> same source) have been adapted to redispatch
>>>>>>>>>>>>>>>>>> MouseEvents to
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> intended
>>>>>>>>>>>>>>>>>> target component. The lookup for the component that
>>>>>>>>>>>>>>>>>> provides a
>>>>>>>>>>>>>>>>>> custon
>>>>>>>>>>>>>>>>>> cursor has also been adapted.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 5) To enable Container to do necessary reculculations, a
>>>>>>>>>>>>>>>>>> protected
>>>>>>>>>>>>>>>>>> method has been introduced that will be overridden by
>>>>>>>>>>>>>>>>>> JLayer:
>>>>>>>>>>>>>>>>>> protected Point getConvertedPoint(Point point).
>>>>>>>>>>>>>>>>>> (If someone can suggest a better name for this method I'm
>>>>>>>>>>>>>>>>>> glad
>>>>>>>>>>>>>>>>>> to hear)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 6) A package private method in SwingUtilities has been
>>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>>> that helps
>>>>>>>>>>>>>>>>>> JPopupMenu and ToolTipManager to find the correct popup
>>>>>>>>>>>>>>>>>> location.
>>>>>>>>>>>>>>>>>> JPopupMenu and ToolTipManager have been changed to use
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>>> in their calculations.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 7) Two jtreg tests have been added.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Looking forward for comments.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>