From artem.ananiev at sun.com  Mon Sep  1 06:45:29 2008
From: artem.ananiev at sun.com (artem.ananiev at sun.com)
Date: Mon, 01 Sep 2008 13:45:29 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6707023: Chenese Characters in
	JTextPane Cause Pane	to Hang
Message-ID: <20080901134541.33250D00E@hg.openjdk.java.net>

Changeset: 39c8e06919a9
Author:    art
Date:      2008-09-01 17:41 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/39c8e06919a9

6707023: Chenese Characters in JTextPane Cause Pane to Hang
Summary: input method events are dispatched to correct AppContext
Reviewed-by: naoto, yan

! src/windows/classes/sun/awt/windows/WInputMethod.java



From Artem.Ananiev at Sun.COM  Mon Sep  1 07:02:15 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Mon, 01 Sep 2008 18:02:15 +0400
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: <1ccfd1c10808291046v193d7045vbd13cde154b7095@mail.gmail.com>
References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com>
	<48B28679.20900@sun.com>
	<1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com>
	<48B54D04.1000508@sun.com>
	<1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com>
	<48B679C7.8060605@sun.com>
	<1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com>
	<48B7D17E.1090103@sun.com>
	<1ccfd1c10808291046v193d7045vbd13cde154b7095@mail.gmail.com>
Message-ID: <48BBF5E7.2070301@sun.com>


Martin Buchholz wrote:
> On Fri, Aug 29, 2008 at 3:37 AM, Anthony Petrov <Anthony.Petrov at sun.com> wrote:
>> On 08/28/2008 08:33 PM Martin Buchholz wrote:
>>> I'm thinking:
>>> - the MMX support is in pnggccrd.c,
>>> - but that file is never compiled in OpenJDK

Quick grep for PNG_MMX_CODE_SUPPORTED shows two .h files and six .c 
files in src/share/native/sun/awt/libpng directory, pnggccrd.c is only 
one of them, but what about others?

Thanks,

Artem

>> Why? There's the following line in the make/sun/splashscreen/Makefile:
>>
>> vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/libpng
>>
>> that effectively includes all *.c files in the libpng sources directory
>> (src/share/native/sun/awt/libpng/) in the compilation process.
> 
> Anthony,
> 
> I believe this is a small misunderstanding of how vpath works.
> vpath changes the _search path_ for files, but does not affect which
> files are actually compiled.   That is defined in
> make/sun/splashscreen/FILES_c.gmk
> and pnggccrd.c is notably absent from that file.
> If you actually try a clean build, on any platform,
> you will see no references to pnggccrd (or pngvcrd)
> in the logs (prove me wrong!).
> 
> Martin


From martinrb at google.com  Tue Sep  2 01:11:51 2008
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 2 Sep 2008 01:11:51 -0700
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: <48BBF5E7.2070301@sun.com>
References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com>
	<48B28679.20900@sun.com>
	<1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com>
	<48B54D04.1000508@sun.com>
	<1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com>
	<48B679C7.8060605@sun.com>
	<1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com>
	<48B7D17E.1090103@sun.com>
	<1ccfd1c10808291046v193d7045vbd13cde154b7095@mail.gmail.com>
	<48BBF5E7.2070301@sun.com>
Message-ID: <1ccfd1c10809020111g5530737bs78dfe509aaae31c2@mail.gmail.com>

Hi Artem and Anthony,

To understand this problem, please examine the snippet in pngconf.h

#  if !defined(PNG_MMX_CODE_SUPPORTED) && !defined(PNG_NO_MMX_CODE) && \
     defined(__MMX__)
#    define PNG_MMX_CODE_SUPPORTED
#  endif

The macro __MMX__ is defined if the gcc is configured to have mmx
support on by default.  You can reproduce the problem probably
most easily by modifying the makefiles to add the flag
"-mmmx" to the C compiler flags.

I believe this issue has existed for a while,
dependent on the way that gcc was configured.

Another way to examine the problem is to
look at the link error, failure to find png_combine_row,
and trace where this function is defined and how
it might be called.  The version of this function in
pngrutil.c is only defined if there is _no_ mmx support.

Martin

On Mon, Sep 1, 2008 at 07:02, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>
> Martin Buchholz wrote:
>>
>> On Fri, Aug 29, 2008 at 3:37 AM, Anthony Petrov <Anthony.Petrov at sun.com>
>> wrote:
>>>
>>> On 08/28/2008 08:33 PM Martin Buchholz wrote:
>>>>
>>>> I'm thinking:
>>>> - the MMX support is in pnggccrd.c,
>>>> - but that file is never compiled in OpenJDK
>
> Quick grep for PNG_MMX_CODE_SUPPORTED shows two .h files and six .c files in
> src/share/native/sun/awt/libpng directory, pnggccrd.c is only one of them,
> but what about others?
>
> Thanks,
>
> Artem
>
>>> Why? There's the following line in the make/sun/splashscreen/Makefile:
>>>
>>> vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/libpng
>>>
>>> that effectively includes all *.c files in the libpng sources directory
>>> (src/share/native/sun/awt/libpng/) in the compilation process.
>>
>> Anthony,
>>
>> I believe this is a small misunderstanding of how vpath works.
>> vpath changes the _search path_ for files, but does not affect which
>> files are actually compiled.   That is defined in
>> make/sun/splashscreen/FILES_c.gmk
>> and pnggccrd.c is notably absent from that file.
>> If you actually try a clean build, on any platform,
>> you will see no references to pnggccrd (or pngvcrd)
>> in the logs (prove me wrong!).
>>
>> Martin
>


From roman at kennke.org  Tue Sep  2 04:09:34 2008
From: roman at kennke.org (Roman Kennke)
Date: Tue, 02 Sep 2008 13:09:34 +0200
Subject: <AWT Dev> Ideas about improved architecture of the generic
	Swing peers
In-Reply-To: <1218794992.6783.44.camel@moonlight>
References: <1218794992.6783.44.camel@moonlight>
Message-ID: <1220353774.8444.16.camel@moonlight>

Hi folks,

I'm CCing awt-dev now, I think this could be interesting. Please scroll
down and read the original mail so that you know what I'm talking about.
Basically, I'm trying to implement AWT peers that are based on Swing
(for the widgets) and require minimum effort for porting to new
platforms. Basically, the only thing that is required to be implemented
on a new platform is the windowing functionality, abstracted out nicely
by the PlatformWindow interface.

Today I pushed a first prototype of the new Swing based AWT peers. It
follows the basic architecture described in the original email (all
components have their own native window, which is abstracted behind an
interface, components are backed by their Swing counterparts for drawing
and state handling). So far, this only serves as proof-of-concept. It is
possible to open a Frame and put Canvas inside it. The code is based on
the patches of the Caciocavallo project (which should probably be merged
in mainline at some point). You can find the code here:

http://hg.openjdk.java.net/caciocavallo/ng/

The basic framework is located in the package sun.awt.peer.cacio, an
example implementation based on Escher [1] can be found in
gnu.java.awt.peer.x (start looking at EscherToolkit maybe).

and the patched OpenJDK forest here:

http://hg.openjdk.java.net/caciocavallo/jdk7/


Questions, suggestions, comments and code are heartily welcome :-)

Cheers, Roman

[1] http://escher.sf.net

Am Freitag, den 15.08.2008, 12:09 +0200 schrieb Roman Kennke:
> Hello people,
> 
> I'd like to outline my ideas about an improved architecture of the
> generic Swing based peers. But let me first describe the current state
> and the problem(s) we need to address:
> 
> Currently, the Swing peers implement most of the peers in
> java.awt.peer.* (well ok, minus a couple of complex ones, like
> ScrollPane, Choice, etc). They are not supposed to work standalone, but
> need some support by a real backend. Most notably, this would be an
> implementation of java.awt.Toolkit and the top-level window peers
> (WindowPeer, DialogPeer and FramePeer). Based on these toplevel windows,
> the Swing peers handle all the widgets in a semi-lightweight fashion:
> all the drawing is done using Graphics contexts from the toplevel
> windows. However, the actual Swing components are not connected to the
> component hierarchy in any way, they are only 'hooked in' in a way, so
> that from the perspective of the Swing component it appears as if it
> were in the component hierarchy, but infact it isn't (from the
> perspective of the hierarchy).
> 
> This architecture, requiring the real backend to implement the toplevel
> windows, and do everything else in a quasi-lightweight fashion has some
> disadvantages, or at least, one big disadvantage. It is really hard to
> get the special behaviour of AWT heavyweight components correct. For
> example, suppose you have a Frame, inside this frame you have a Swing
> component, and a Panel. The panel would always be on top of the Swing
> component, regardless of the stacking order in the window. To make it
> even more complex, if you had a Swing component in the Panel, it would
> be drawn on the Panel, not on the Window (an thus, it would appear to be
> always on top of the other Swing component). To get this right in the
> Swing peers, we had to implement a bunch of hacks, that involve double
> buffers for all components and other ugly stuff, and it never worked
> really well.
> 
> The answer, for me, was found in the implementation of the XWindow peers
> in OpenJDK. All AWT components are 'simply' given their own X Windows.
> I, coming from a Swing background, first had to get over this concept a
> little, but then it seemed all logical, and I think most toolkits (at
> least in the X world) are implemented like that. And even though not
> specified exactly, Java AWT applications expect such behavior from AWT
> components.
> 
> What I would like to propose is a kind of blend between the architecture
> of the XAWT peers in OpenJDK and the Swing peers: Let all AWT components
> be drawn in their own window, but let Swing do the drawing and handling
> of logic and events. This way, we would get a maximum portable AWT peer
> implementation, that requires only minimal effort to port to any new
> platform. The interesting part is to implement this idea:
> 
> The first thing to think about is that all components should have their
> own window. To me, this means, that the common superclass of all the
> peers, the SwingComponentPeer, must implement all the necessary
> windowing behaviour. This is done similarily in the XAWT peers, but in a
> very X specific way. All other peers, including the toplevel peers and
> the widgets, derive from this class (an exception would probably be the
> menu related peers). Since SwingComponentPeer already implements all the
> necessary windowing functionality, the toplevel peers don't have much to
> do on their own, except delegating to super here and there. The widget
> peers now don't search for a parent graphics for drawing, but can do
> everything in their own window.
> 
> The tricky part here is, when the SwingComponentPeer is at the top of
> the hierarchy, how can we 'plug in' platform specific code there?
> Subclassing surely isn't it. My idea is to have a kind of PlatformWindow
> interface, which is used by the SwingComponentPeer to delegate all the
> real window implementation stuff to. We should be careful to create a
> nice clean interface there. Porting the AWT would then be as simple as
> implementing this one interface (plus J2D pipeline), and boing! have all
> the AWT widgets and toplevel windows available.
> 
> And we need to consider that not only SwingComponentPeer calls into the
> PlatformWindow impl, but the PlatformWindow impl also needs to call back
> to the SwingComponentPeer for handling events. In the XAWT
> implementation this is done by passing back X events. Of course, we
> don't want platform specific events in the Swing peers. So the
> PlatformWindow implementation needs to take care and transform all
> platform specific events to Java AWT events before passing them back to
> the SwingComponentPeer. It might be necessary to introduce a couple of
> internal peer events for handling stuff that is not covered by the
> 'official' AWT events.
> 
> Summary of the architecture outline (this would be a good point to slip
> in an UML diagram, but I really don't like diagrams ;-) ):
> 
> SwingComponentPeer is the all-mighty master superclass here. It provides
> all the necessary windowing functionality. But it doesn't implement this
> itself, but instead delegates to a PlatformWindow implementation.
> PlatformWindow would be an interface that specifies all the windowing
> functionality that we need from the underlying platform. The
> PlatformWindow implementation is also expected to pass all the events
> from the window to the SwingComponentPeer, in the form of AWT event
> objects (it must already translate the native event types to the
> corresponding AWT events). Subclasses of SwingComponentPeer implement
> both the widgets as well as the toplevel windows. Drawing the widgets
> and handling the state logic of the component is done by Swing.
> 
> Please tell me what you think.
> 
> Cheers, Roman
> 
-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080902/6dce7239/attachment.bin 

From Andrei.Dmitriev at Sun.COM  Wed Sep  3 10:23:30 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Wed, 03 Sep 2008 21:23:30 +0400
Subject: <AWT Dev> Ideas about improved architecture of the
 generic	Swing peers
In-Reply-To: <1220353774.8444.16.camel@moonlight>
References: <1218794992.6783.44.camel@moonlight>
	<1220353774.8444.16.camel@moonlight>
Message-ID: <48BEC812.9080301@sun.com>

Hi Roman,

tried this version and in contrast to previous one this looks much more 
functional. :)
I decided that it's only reasonable to check pure-AWT scenarios so just 
picked a simple "Button-in-a-Frame" thing up and seem it does work.
Haven't looked on how it deals with events... this is an issue for some 
near future. I spent some time walking around the new code and found 
this pretty much similar to a prototype which existed by this moment for 
a - week or something. :)
You did inherited from the SunToolkit class and left Runnable aside. 
Perhaps this could save some more lines of code.

As a matter of fact I also tried some more complicated AWT test which I 
believe covers all components and failed on TextArea peer 
initialization. The good thing is we actually have semi-lightweight peer 
for text components in X11 code so we probably may be kept from part of 
this work. Just in case you haven't realized that yet. :)

Thanks,
   Andrei

Roman Kennke wrote:
> Hi folks,
> 
> I'm CCing awt-dev now, I think this could be interesting. Please scroll
> down and read the original mail so that you know what I'm talking about.
> Basically, I'm trying to implement AWT peers that are based on Swing
> (for the widgets) and require minimum effort for porting to new
> platforms. Basically, the only thing that is required to be implemented
> on a new platform is the windowing functionality, abstracted out nicely
> by the PlatformWindow interface.
> 
> Today I pushed a first prototype of the new Swing based AWT peers. It
> follows the basic architecture described in the original email (all
> components have their own native window, which is abstracted behind an
> interface, components are backed by their Swing counterparts for drawing
> and state handling). So far, this only serves as proof-of-concept. It is
> possible to open a Frame and put Canvas inside it. The code is based on
> the patches of the Caciocavallo project (which should probably be merged
> in mainline at some point). You can find the code here:
> 
> http://hg.openjdk.java.net/caciocavallo/ng/
> 
> The basic framework is located in the package sun.awt.peer.cacio, an
> example implementation based on Escher [1] can be found in
> gnu.java.awt.peer.x (start looking at EscherToolkit maybe).
> 
> and the patched OpenJDK forest here:
> 
> http://hg.openjdk.java.net/caciocavallo/jdk7/
> 
> 
> Questions, suggestions, comments and code are heartily welcome :-)
> 
> Cheers, Roman
> 
> [1] http://escher.sf.net
> 
> Am Freitag, den 15.08.2008, 12:09 +0200 schrieb Roman Kennke:
>> Hello people,
>>
>> I'd like to outline my ideas about an improved architecture of the
>> generic Swing based peers. But let me first describe the current state
>> and the problem(s) we need to address:
>>
>> Currently, the Swing peers implement most of the peers in
>> java.awt.peer.* (well ok, minus a couple of complex ones, like
>> ScrollPane, Choice, etc). They are not supposed to work standalone, but
>> need some support by a real backend. Most notably, this would be an
>> implementation of java.awt.Toolkit and the top-level window peers
>> (WindowPeer, DialogPeer and FramePeer). Based on these toplevel windows,
>> the Swing peers handle all the widgets in a semi-lightweight fashion:
>> all the drawing is done using Graphics contexts from the toplevel
>> windows. However, the actual Swing components are not connected to the
>> component hierarchy in any way, they are only 'hooked in' in a way, so
>> that from the perspective of the Swing component it appears as if it
>> were in the component hierarchy, but infact it isn't (from the
>> perspective of the hierarchy).
>>
>> This architecture, requiring the real backend to implement the toplevel
>> windows, and do everything else in a quasi-lightweight fashion has some
>> disadvantages, or at least, one big disadvantage. It is really hard to
>> get the special behaviour of AWT heavyweight components correct. For
>> example, suppose you have a Frame, inside this frame you have a Swing
>> component, and a Panel. The panel would always be on top of the Swing
>> component, regardless of the stacking order in the window. To make it
>> even more complex, if you had a Swing component in the Panel, it would
>> be drawn on the Panel, not on the Window (an thus, it would appear to be
>> always on top of the other Swing component). To get this right in the
>> Swing peers, we had to implement a bunch of hacks, that involve double
>> buffers for all components and other ugly stuff, and it never worked
>> really well.
>>
>> The answer, for me, was found in the implementation of the XWindow peers
>> in OpenJDK. All AWT components are 'simply' given their own X Windows.
>> I, coming from a Swing background, first had to get over this concept a
>> little, but then it seemed all logical, and I think most toolkits (at
>> least in the X world) are implemented like that. And even though not
>> specified exactly, Java AWT applications expect such behavior from AWT
>> components.
>>
>> What I would like to propose is a kind of blend between the architecture
>> of the XAWT peers in OpenJDK and the Swing peers: Let all AWT components
>> be drawn in their own window, but let Swing do the drawing and handling
>> of logic and events. This way, we would get a maximum portable AWT peer
>> implementation, that requires only minimal effort to port to any new
>> platform. The interesting part is to implement this idea:
>>
>> The first thing to think about is that all components should have their
>> own window. To me, this means, that the common superclass of all the
>> peers, the SwingComponentPeer, must implement all the necessary
>> windowing behaviour. This is done similarily in the XAWT peers, but in a
>> very X specific way. All other peers, including the toplevel peers and
>> the widgets, derive from this class (an exception would probably be the
>> menu related peers). Since SwingComponentPeer already implements all the
>> necessary windowing functionality, the toplevel peers don't have much to
>> do on their own, except delegating to super here and there. The widget
>> peers now don't search for a parent graphics for drawing, but can do
>> everything in their own window.
>>
>> The tricky part here is, when the SwingComponentPeer is at the top of
>> the hierarchy, how can we 'plug in' platform specific code there?
>> Subclassing surely isn't it. My idea is to have a kind of PlatformWindow
>> interface, which is used by the SwingComponentPeer to delegate all the
>> real window implementation stuff to. We should be careful to create a
>> nice clean interface there. Porting the AWT would then be as simple as
>> implementing this one interface (plus J2D pipeline), and boing! have all
>> the AWT widgets and toplevel windows available.
>>
>> And we need to consider that not only SwingComponentPeer calls into the
>> PlatformWindow impl, but the PlatformWindow impl also needs to call back
>> to the SwingComponentPeer for handling events. In the XAWT
>> implementation this is done by passing back X events. Of course, we
>> don't want platform specific events in the Swing peers. So the
>> PlatformWindow implementation needs to take care and transform all
>> platform specific events to Java AWT events before passing them back to
>> the SwingComponentPeer. It might be necessary to introduce a couple of
>> internal peer events for handling stuff that is not covered by the
>> 'official' AWT events.
>>
>> Summary of the architecture outline (this would be a good point to slip
>> in an UML diagram, but I really don't like diagrams ;-) ):
>>
>> SwingComponentPeer is the all-mighty master superclass here. It provides
>> all the necessary windowing functionality. But it doesn't implement this
>> itself, but instead delegates to a PlatformWindow implementation.
>> PlatformWindow would be an interface that specifies all the windowing
>> functionality that we need from the underlying platform. The
>> PlatformWindow implementation is also expected to pass all the events
>> from the window to the SwingComponentPeer, in the form of AWT event
>> objects (it must already translate the native event types to the
>> corresponding AWT events). Subclasses of SwingComponentPeer implement
>> both the widgets as well as the toplevel windows. Drawing the widgets
>> and handling the state logic of the component is done by Swing.
>>
>> Please tell me what you think.
>>
>> Cheers, Roman
>>


From roman at kennke.org  Wed Sep  3 12:40:26 2008
From: roman at kennke.org (Roman Kennke)
Date: Wed, 03 Sep 2008 21:40:26 +0200
Subject: <AWT Dev> Ideas about improved architecture of
	the	generic	Swing peers
In-Reply-To: <48BEC812.9080301@sun.com>
References: <1218794992.6783.44.camel@moonlight>
	<1220353774.8444.16.camel@moonlight>  <48BEC812.9080301@sun.com>
Message-ID: <1220470826.3600.9.camel@moonlight>

Hi Andrei,

> tried this version and in contrast to previous one this looks much more 
> functional. :)
> I decided that it's only reasonable to check pure-AWT scenarios so just 
> picked a simple "Button-in-a-Frame" thing up and seem it does work.

Yeah, I implemented Buttons and Labels yesterday :-)

> Haven't looked on how it deals with events... this is an issue for some 
> near future.

MouseEvents and some other things like PaintEvent, ComponentEvent should
work, at least good enough for getting basic painting and mouse
handling, resizing, etc to work. Today I looked a little in
KeyboardEvent and FocusEvent handling, this is a little weird, because
the KeyboardFocusManager must not expose the backing Swing components as
focus owner, but yet the Swing component should 'think' it is focused.
But I already have some ideas that I try this evening.

>  I spent some time walking around the new code and found 
> this pretty much similar to a prototype which existed by this moment for 
> a - week or something. :)

Cool. So maybe it's a good idea to decide for one of the two prototypes,
either you push out your stuff in the open and we work together on that,
or we continue together on the Cacio peers. What do you think? It
doesn't seem to make sense to develop two implementations in parallel...

> You did inherited from the SunToolkit class and left Runnable aside. 
> Perhaps this could save some more lines of code.

Surely. I'm not sure yet what SunToolkit has to do with Runnable, but I
guess I'll study the code and learn :-)


> As a matter of fact I also tried some more complicated AWT test which I 
> believe covers all components and failed on TextArea peer 
> initialization.

Yeha! I only implemented Window, Frame, Canvas, Button and Label so far.
The other toplevels and Panel seem to be some more low hanging fruits.
The text components shouldn't be so bad - I already had these working to
some degree in the old Swing peers of GNU Classpath. What I'm really
scared about are the compound components like Scrollpane and Choice and
the Menu related stuff.

>  The good thing is we actually have semi-lightweight peer 
> for text components in X11 code so we probably may be kept from part of 
> this work. Just in case you haven't realized that yet. :)

Yeah, I've seen that. Very cool. Infact, my inspiration for all this is
both the XAWT peers of OpenJDK and my old work on GNU Classpath, and to
me, this new code is a merge of ideas from both.

> Thanks,
>    Andrei

Thank you!

/Roman

-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080903/96d5a498/attachment.bin 

From Artem.Ananiev at Sun.COM  Thu Sep  4 01:24:26 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Thu, 04 Sep 2008 12:24:26 +0400
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: <1ccfd1c10808291056g42f92780n7ca1cedc0530b01b@mail.gmail.com>
References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com>
	<48B28679.20900@sun.com>
	<1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com>
	<48B54D04.1000508@sun.com>
	<1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com>
	<48B679C7.8060605@sun.com>
	<1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com>
	<1ccfd1c10808281458t4ce2543difcb2f3442826e095@mail.gmail.com>
	<48B7CFB6.3020006@sun.com>
	<1ccfd1c10808291056g42f92780n7ca1cedc0530b01b@mail.gmail.com>
Message-ID: <48BF9B3A.6070701@sun.com>

Hi, Martin,

I have just filed a new bug

6744609: Disable MMX support when building libpng library

which will be visible via bugs.sun.com in a few hours/days. Next, a 
couple of words about the proposed fix:

1. It seems that on windows platform __MMX__ symbol is never defined, so 
libpng is compiled without MMX support there. That's why defining 
PNG_NO_MMX_CODE unconditionally on all the platforms looks reasonable.

2. A question is about adding pnggccrd.c to the list of files in 
make/sun/splashscreen/FILES_c.gmk - I see some code unrelated to MMX there.

As for pushing the fix to the workspace, I don't know if you have access 
there. BTW, I don't see you in the list of people signed SCA, which is 
required when contributing any code to OpenJDK.

Thanks,

Artem

Martin Buchholz wrote:
> Hi Anthony and Artem,
> 
> My current patch looks like below.
> Except for one remaining minor technical disagreement,I
> the only thing "wrong" is the need for a new bug id
> (I am reusing the old one, already in Fix Delivered state)
> 
> Again, I am proposing to push this to jdk7/awt-gate/jdk
> 
> Thanks,
> 
> Martin
> 
> # HG changeset patch
> # User martin
> # Date 1220032048 25200
> # Node ID abbc627dfd7e7d1e2c613287d5dddb83df3aee93
> # Parent  1267605489211c6c162bb246f653759e933bd06e
> 6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 (64bit)
> Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux
> Reviewed-by: anthony, art
> 
> diff --git a/make/sun/splashscreen/Makefile b/make/sun/splashscreen/Makefile
> --- a/make/sun/splashscreen/Makefile
> +++ b/make/sun/splashscreen/Makefile
> @@ -85,13 +85,6 @@
>  CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen
> -I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen
>  CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg
> -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3
> 
> -ifeq ($(PLATFORM), linux)
> -  ifeq ($(ARCH_DATA_MODEL), 64)
> -    # 64-bit gcc has problems compiling MMX instructions.
> -    # Google it for more details. Possibly the newer versions of
> -    # the PNG-library and/or the new compiler will not need this
> -    # option in the future.
> -    CPPFLAGS += -DPNG_NO_MMX_CODE
> -  endif
> -endif
> -
> +# Shun the less than portable MMX assembly code in pnggccrd.c,
> +# and use alternative implementations in C.
> +CPPFLAGS += -DPNG_NO_MMX_CODE


From martinrb at google.com  Thu Sep  4 02:05:39 2008
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 4 Sep 2008 02:05:39 -0700
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: <48BF9B3A.6070701@sun.com>
References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com>
	<1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com>
	<48B54D04.1000508@sun.com>
	<1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com>
	<48B679C7.8060605@sun.com>
	<1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com>
	<1ccfd1c10808281458t4ce2543difcb2f3442826e095@mail.gmail.com>
	<48B7CFB6.3020006@sun.com>
	<1ccfd1c10808291056g42f92780n7ca1cedc0530b01b@mail.gmail.com>
	<48BF9B3A.6070701@sun.com>
Message-ID: <1ccfd1c10809040205r40b2cf53r99feb0620dea7e8c@mail.gmail.com>

Hi Artem,

On Thu, Sep 4, 2008 at 01:24, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
> Hi, Martin,
>
> I have just filed a new bug
>
> 6744609: Disable MMX support when building libpng library
>
> which will be visible via bugs.sun.com in a few hours/days. Next, a couple
> of words about the proposed fix:
>
> 1. It seems that on windows platform __MMX__ symbol is never defined, so
> libpng is compiled without MMX support there. That's why defining
> PNG_NO_MMX_CODE unconditionally on all the platforms looks reasonable.

Agreed.

> 2. A question is about adding pnggccrd.c to the list of files in
> make/sun/splashscreen/FILES_c.gmk - I see some code unrelated to MMX there.

I no longer suggest adding pngccrd.c to FILES_c.gmk.
The current proposed change should be very safe.

> As for pushing the fix to the workspace, I don't know if you have access
> there. BTW, I don't see you in the list of people signed SCA, which is
> required when contributing any code to OpenJDK.

I have already done commits to OpenJDK since leaving Sun.
Google has signed a corporate special SCA with Sun;
all Google employees can contribute to OpenJDK without
signing an additional SCA.

But I've never done a push to awt.  I plan to push
to the jdk7/awt-gate/jdk repository.
Let me know if that's not the right thing to do.

Martin

> Thanks,
>
> Artem
>
> Martin Buchholz wrote:
>>
>> Hi Anthony and Artem,
>>
>> My current patch looks like below.
>> Except for one remaining minor technical disagreement,I
>> the only thing "wrong" is the need for a new bug id
>> (I am reusing the old one, already in Fix Delivered state)
>>
>> Again, I am proposing to push this to jdk7/awt-gate/jdk
>>
>> Thanks,
>>
>> Martin
>>
>> # HG changeset patch
>> # User martin
>> # Date 1220032048 25200
>> # Node ID abbc627dfd7e7d1e2c613287d5dddb83df3aee93
>> # Parent  1267605489211c6c162bb246f653759e933bd06e
>> 6613927: Compilation of splashscreen png library failed on Ubuntu 7.04
>> (64bit)
>> Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit
>> Linux
>> Reviewed-by: anthony, art
>>
>> diff --git a/make/sun/splashscreen/Makefile
>> b/make/sun/splashscreen/Makefile
>> --- a/make/sun/splashscreen/Makefile
>> +++ b/make/sun/splashscreen/Makefile
>> @@ -85,13 +85,6 @@
>>  CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen
>> -I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen
>>  CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg
>> -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3
>>
>> -ifeq ($(PLATFORM), linux)
>> -  ifeq ($(ARCH_DATA_MODEL), 64)
>> -    # 64-bit gcc has problems compiling MMX instructions.
>> -    # Google it for more details. Possibly the newer versions of
>> -    # the PNG-library and/or the new compiler will not need this
>> -    # option in the future.
>> -    CPPFLAGS += -DPNG_NO_MMX_CODE
>> -  endif
>> -endif
>> -
>> +# Shun the less than portable MMX assembly code in pnggccrd.c,
>> +# and use alternative implementations in C.
>> +CPPFLAGS += -DPNG_NO_MMX_CODE
>


From Artem.Ananiev at Sun.COM  Thu Sep  4 06:12:32 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Thu, 04 Sep 2008 17:12:32 +0400
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: <1ccfd1c10809040205r40b2cf53r99feb0620dea7e8c@mail.gmail.com>
References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com>
	<1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com>
	<48B54D04.1000508@sun.com>
	<1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com>
	<48B679C7.8060605@sun.com>
	<1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com>
	<1ccfd1c10808281458t4ce2543difcb2f3442826e095@mail.gmail.com>
	<48B7CFB6.3020006@sun.com>
	<1ccfd1c10808291056g42f92780n7ca1cedc0530b01b@mail.gmail.com>
	<48BF9B3A.6070701@sun.com>
	<1ccfd1c10809040205r40b2cf53r99feb0620dea7e8c@mail.gmail.com>
Message-ID: <48BFDEC0.1070902@sun.com>

Hi, Martin,

Martin Buchholz wrote:

>> As for pushing the fix to the workspace, I don't know if you have access
>> there. BTW, I don't see you in the list of people signed SCA, which is
>> required when contributing any code to OpenJDK.
> 
> I have already done commits to OpenJDK since leaving Sun.
> Google has signed a corporate special SCA with Sun;
> all Google employees can contribute to OpenJDK without
> signing an additional SCA.
> 
> But I've never done a push to awt.  I plan to push
> to the jdk7/awt-gate/jdk repository.
> Let me know if that's not the right thing to do.

only group members may push any changes to workspace, and each group has 
its own list of trusted contributors, right? I understand you may have 
pushed many patches into different OpenJDK areas, but I don't remember 
any for AWT group.

Your current fix looks safe, and I can push it to the workspace, if you 
agree. In any case, thank you for the work,

Artem


From andrei.dmitriev at sun.com  Thu Sep  4 06:29:33 2008
From: andrei.dmitriev at sun.com (andrei.dmitriev at sun.com)
Date: Thu, 04 Sep 2008 13:29:33 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 2 new changesets
Message-ID: <20080904133006.A6061D22C@hg.openjdk.java.net>

Changeset: b942efbc1c72
Author:    dav
Date:      2008-09-04 17:20 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/b942efbc1c72

6738181: api/java_awt/Toolkit/index.html#GetAWTEventListeners Fails with:empty array returned unexpectedly
Summary: redirect getAWTEventListeners(long l) from Headless to underlying toolkit.
Reviewed-by: art

! src/share/classes/sun/awt/HeadlessToolkit.java
+ test/java/awt/Toolkit/Headless/AWTEventListener/AWTListener.java

Changeset: f0ce5b54bd90
Author:    dav
Date:      2008-09-04 17:24 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/f0ce5b54bd90

Merge

- src/windows/native/sun/windows/UnicowsLoader.cpp
- src/windows/native/sun/windows/UnicowsLoader.h
- src/windows/native/sun/windows/awt_MMStub.cpp
- src/windows/native/sun/windows/awt_MMStub.h
- src/windows/native/sun/windows/awt_Multimon.h
- src/windows/native/sun/windows/awt_Unicode.cpp
- src/windows/native/sun/windows/awt_Unicode.h
- src/windows/native/sun/windows/awt_dlls.cpp
- src/windows/native/sun/windows/awt_dlls.h



From Artem.Ananiev at Sun.COM  Thu Sep  4 06:51:35 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Thu, 04 Sep 2008 17:51:35 +0400
Subject: <AWT Dev> Ideas about improved architecture of the
 generic	Swing peers
In-Reply-To: <1220353774.8444.16.camel@moonlight>
References: <1218794992.6783.44.camel@moonlight>
	<1220353774.8444.16.camel@moonlight>
Message-ID: <48BFE7E7.8090405@sun.com>

Hi, Roman,

I haven't had a chance to look at Caciocavallo project, so some of my 
questions may look pretty naive, but still:

1. Do I understand correctly, that you're using XToolkit approach: each 
component has its own native (heavyweight) window, but all the drawing 
is performed in a lightweight manner?

2. A small note about original email. Most of the problems described in 
the email are related to a known AWT limitation about using both heavy- 
and lightweight components inside a single container. As of JDK7 this 
limitation is eliminated, and hw/lw mixing works pretty well and fast.

3. What is PlatformWindow interface? Does it correspond to a top-level 
window or any heavyweight component?

4. Do you suggest an approach when a lightweight (Swing) component is 
inserted into an AWT widget (aggregation) or just reuse some painting 
and other Swing stuff (draw Swing components onto AWT components)?

5. You write your current implementation works on X11 with EscherToolkit 
on top of it. Do you think it would be hard to use existing AWT 
toolkits: XToolkit & WToolkit - for an underlying layer?

Thanks,

Artem

Roman Kennke wrote:
> Hi folks,
> 
> I'm CCing awt-dev now, I think this could be interesting. Please scroll
> down and read the original mail so that you know what I'm talking about.
> Basically, I'm trying to implement AWT peers that are based on Swing
> (for the widgets) and require minimum effort for porting to new
> platforms. Basically, the only thing that is required to be implemented
> on a new platform is the windowing functionality, abstracted out nicely
> by the PlatformWindow interface.
> 
> Today I pushed a first prototype of the new Swing based AWT peers. It
> follows the basic architecture described in the original email (all
> components have their own native window, which is abstracted behind an
> interface, components are backed by their Swing counterparts for drawing
> and state handling). So far, this only serves as proof-of-concept. It is
> possible to open a Frame and put Canvas inside it. The code is based on
> the patches of the Caciocavallo project (which should probably be merged
> in mainline at some point). You can find the code here:
> 
> http://hg.openjdk.java.net/caciocavallo/ng/
> 
> The basic framework is located in the package sun.awt.peer.cacio, an
> example implementation based on Escher [1] can be found in
> gnu.java.awt.peer.x (start looking at EscherToolkit maybe).
> 
> and the patched OpenJDK forest here:
> 
> http://hg.openjdk.java.net/caciocavallo/jdk7/
> 
> 
> Questions, suggestions, comments and code are heartily welcome :-)
> 
> Cheers, Roman
> 
> [1] http://escher.sf.net
> 
> Am Freitag, den 15.08.2008, 12:09 +0200 schrieb Roman Kennke:
>> Hello people,
>>
>> I'd like to outline my ideas about an improved architecture of the
>> generic Swing based peers. But let me first describe the current state
>> and the problem(s) we need to address:
>>
>> Currently, the Swing peers implement most of the peers in
>> java.awt.peer.* (well ok, minus a couple of complex ones, like
>> ScrollPane, Choice, etc). They are not supposed to work standalone, but
>> need some support by a real backend. Most notably, this would be an
>> implementation of java.awt.Toolkit and the top-level window peers
>> (WindowPeer, DialogPeer and FramePeer). Based on these toplevel windows,
>> the Swing peers handle all the widgets in a semi-lightweight fashion:
>> all the drawing is done using Graphics contexts from the toplevel
>> windows. However, the actual Swing components are not connected to the
>> component hierarchy in any way, they are only 'hooked in' in a way, so
>> that from the perspective of the Swing component it appears as if it
>> were in the component hierarchy, but infact it isn't (from the
>> perspective of the hierarchy).
>>
>> This architecture, requiring the real backend to implement the toplevel
>> windows, and do everything else in a quasi-lightweight fashion has some
>> disadvantages, or at least, one big disadvantage. It is really hard to
>> get the special behaviour of AWT heavyweight components correct. For
>> example, suppose you have a Frame, inside this frame you have a Swing
>> component, and a Panel. The panel would always be on top of the Swing
>> component, regardless of the stacking order in the window. To make it
>> even more complex, if you had a Swing component in the Panel, it would
>> be drawn on the Panel, not on the Window (an thus, it would appear to be
>> always on top of the other Swing component). To get this right in the
>> Swing peers, we had to implement a bunch of hacks, that involve double
>> buffers for all components and other ugly stuff, and it never worked
>> really well.
>>
>> The answer, for me, was found in the implementation of the XWindow peers
>> in OpenJDK. All AWT components are 'simply' given their own X Windows.
>> I, coming from a Swing background, first had to get over this concept a
>> little, but then it seemed all logical, and I think most toolkits (at
>> least in the X world) are implemented like that. And even though not
>> specified exactly, Java AWT applications expect such behavior from AWT
>> components.
>>
>> What I would like to propose is a kind of blend between the architecture
>> of the XAWT peers in OpenJDK and the Swing peers: Let all AWT components
>> be drawn in their own window, but let Swing do the drawing and handling
>> of logic and events. This way, we would get a maximum portable AWT peer
>> implementation, that requires only minimal effort to port to any new
>> platform. The interesting part is to implement this idea:
>>
>> The first thing to think about is that all components should have their
>> own window. To me, this means, that the common superclass of all the
>> peers, the SwingComponentPeer, must implement all the necessary
>> windowing behaviour. This is done similarily in the XAWT peers, but in a
>> very X specific way. All other peers, including the toplevel peers and
>> the widgets, derive from this class (an exception would probably be the
>> menu related peers). Since SwingComponentPeer already implements all the
>> necessary windowing functionality, the toplevel peers don't have much to
>> do on their own, except delegating to super here and there. The widget
>> peers now don't search for a parent graphics for drawing, but can do
>> everything in their own window.
>>
>> The tricky part here is, when the SwingComponentPeer is at the top of
>> the hierarchy, how can we 'plug in' platform specific code there?
>> Subclassing surely isn't it. My idea is to have a kind of PlatformWindow
>> interface, which is used by the SwingComponentPeer to delegate all the
>> real window implementation stuff to. We should be careful to create a
>> nice clean interface there. Porting the AWT would then be as simple as
>> implementing this one interface (plus J2D pipeline), and boing! have all
>> the AWT widgets and toplevel windows available.
>>
>> And we need to consider that not only SwingComponentPeer calls into the
>> PlatformWindow impl, but the PlatformWindow impl also needs to call back
>> to the SwingComponentPeer for handling events. In the XAWT
>> implementation this is done by passing back X events. Of course, we
>> don't want platform specific events in the Swing peers. So the
>> PlatformWindow implementation needs to take care and transform all
>> platform specific events to Java AWT events before passing them back to
>> the SwingComponentPeer. It might be necessary to introduce a couple of
>> internal peer events for handling stuff that is not covered by the
>> 'official' AWT events.
>>
>> Summary of the architecture outline (this would be a good point to slip
>> in an UML diagram, but I really don't like diagrams ;-) ):
>>
>> SwingComponentPeer is the all-mighty master superclass here. It provides
>> all the necessary windowing functionality. But it doesn't implement this
>> itself, but instead delegates to a PlatformWindow implementation.
>> PlatformWindow would be an interface that specifies all the windowing
>> functionality that we need from the underlying platform. The
>> PlatformWindow implementation is also expected to pass all the events
>> from the window to the SwingComponentPeer, in the form of AWT event
>> objects (it must already translate the native event types to the
>> corresponding AWT events). Subclasses of SwingComponentPeer implement
>> both the widgets as well as the toplevel windows. Drawing the widgets
>> and handling the state logic of the component is done by Swing.
>>
>> Please tell me what you think.
>>
>> Cheers, Roman
>>


From roman at kennke.org  Thu Sep  4 07:21:24 2008
From: roman at kennke.org (Roman Kennke)
Date: Thu, 04 Sep 2008 16:21:24 +0200
Subject: <AWT Dev> Ideas about improved architecture of
	the	generic	Swing peers
In-Reply-To: <48BFE7E7.8090405@sun.com>
References: <1218794992.6783.44.camel@moonlight>
	<1220353774.8444.16.camel@moonlight>  <48BFE7E7.8090405@sun.com>
Message-ID: <1220538084.6422.10.camel@moonlight>

Hi Artem,

> I haven't had a chance to look at Caciocavallo project, so some of my 
> questions may look pretty naive, but still:
> 
> 1. Do I understand correctly, that you're using XToolkit approach: each 
> component has its own native (heavyweight) window, but all the drawing 
> is performed in a lightweight manner?

Yes.

> 2. A small note about original email. Most of the problems described in 
> the email are related to a known AWT limitation about using both heavy- 
> and lightweight components inside a single container. As of JDK7 this 
> limitation is eliminated, and hw/lw mixing works pretty well and fast.

Cool. But we don't really mix LW and HW.

> 3. What is PlatformWindow interface? Does it correspond to a top-level 
> window or any heavyweight component?

This corresponds to each HW component, because all components use a
native window. The interface is similar to WindowPeer plus
ComponentPeer, but with some quirks. For example, in the XToolkit, you
have the XComponentPeer which is a subclass of XWindow. XWindow
implements all (most?) of the actual window functionality. What we are
doing is similar, but IMO more portable: CacioComponentPeer implements
all the window functionality, but by delegating the platform dependent
parts to an implementation of the PlatformWindow interface. The
PlatformWindow implementation is responsible for handling the window
(e.g. setVisible()) and for passing back events from the window system
to the CacioComponentPeer (which in turn passen the events on to the
EQ).

> 4. Do you suggest an approach when a lightweight (Swing) component is 
> inserted into an AWT widget (aggregation) or just reuse some painting 
> and other Swing stuff (draw Swing components onto AWT components)?

I don't insert Swing into AWT. From the POV of the application, it
should never see the Swing components used. The peer instantiates the
Swing components, but does not add it to the AWT hierarchy. But it does
some tricks, so that the Swing components 'thinks' it has a valid
parent, to allow painting and some other stuff.

> 5. You write your current implementation works on X11 with EscherToolkit 
> on top of it. Do you think it would be hard to use existing AWT 
> toolkits: XToolkit & WToolkit - for an underlying layer?

I'm not sure what you mean by that. I think it should be possible to use
X11 or Win32 for underlying layer (Escher == X11/Xlib in 100% Java). If
you want to use the Swing peers in XToolkit or WToolkit, you'd have to
implement the PlatformWindow interface in these toolkits and subclass
from CacioToolkit, instead of SunToolkit.

/Roman

> 
> Thanks,
> 
> Artem
> 
> Roman Kennke wrote:
> > Hi folks,
> > 
> > I'm CCing awt-dev now, I think this could be interesting. Please scroll
> > down and read the original mail so that you know what I'm talking about.
> > Basically, I'm trying to implement AWT peers that are based on Swing
> > (for the widgets) and require minimum effort for porting to new
> > platforms. Basically, the only thing that is required to be implemented
> > on a new platform is the windowing functionality, abstracted out nicely
> > by the PlatformWindow interface.
> > 
> > Today I pushed a first prototype of the new Swing based AWT peers. It
> > follows the basic architecture described in the original email (all
> > components have their own native window, which is abstracted behind an
> > interface, components are backed by their Swing counterparts for drawing
> > and state handling). So far, this only serves as proof-of-concept. It is
> > possible to open a Frame and put Canvas inside it. The code is based on
> > the patches of the Caciocavallo project (which should probably be merged
> > in mainline at some point). You can find the code here:
> > 
> > http://hg.openjdk.java.net/caciocavallo/ng/
> > 
> > The basic framework is located in the package sun.awt.peer.cacio, an
> > example implementation based on Escher [1] can be found in
> > gnu.java.awt.peer.x (start looking at EscherToolkit maybe).
> > 
> > and the patched OpenJDK forest here:
> > 
> > http://hg.openjdk.java.net/caciocavallo/jdk7/
> > 
> > 
> > Questions, suggestions, comments and code are heartily welcome :-)
> > 
> > Cheers, Roman
> > 
> > [1] http://escher.sf.net
> > 
> > Am Freitag, den 15.08.2008, 12:09 +0200 schrieb Roman Kennke:
> >> Hello people,
> >>
> >> I'd like to outline my ideas about an improved architecture of the
> >> generic Swing based peers. But let me first describe the current state
> >> and the problem(s) we need to address:
> >>
> >> Currently, the Swing peers implement most of the peers in
> >> java.awt.peer.* (well ok, minus a couple of complex ones, like
> >> ScrollPane, Choice, etc). They are not supposed to work standalone, but
> >> need some support by a real backend. Most notably, this would be an
> >> implementation of java.awt.Toolkit and the top-level window peers
> >> (WindowPeer, DialogPeer and FramePeer). Based on these toplevel windows,
> >> the Swing peers handle all the widgets in a semi-lightweight fashion:
> >> all the drawing is done using Graphics contexts from the toplevel
> >> windows. However, the actual Swing components are not connected to the
> >> component hierarchy in any way, they are only 'hooked in' in a way, so
> >> that from the perspective of the Swing component it appears as if it
> >> were in the component hierarchy, but infact it isn't (from the
> >> perspective of the hierarchy).
> >>
> >> This architecture, requiring the real backend to implement the toplevel
> >> windows, and do everything else in a quasi-lightweight fashion has some
> >> disadvantages, or at least, one big disadvantage. It is really hard to
> >> get the special behaviour of AWT heavyweight components correct. For
> >> example, suppose you have a Frame, inside this frame you have a Swing
> >> component, and a Panel. The panel would always be on top of the Swing
> >> component, regardless of the stacking order in the window. To make it
> >> even more complex, if you had a Swing component in the Panel, it would
> >> be drawn on the Panel, not on the Window (an thus, it would appear to be
> >> always on top of the other Swing component). To get this right in the
> >> Swing peers, we had to implement a bunch of hacks, that involve double
> >> buffers for all components and other ugly stuff, and it never worked
> >> really well.
> >>
> >> The answer, for me, was found in the implementation of the XWindow peers
> >> in OpenJDK. All AWT components are 'simply' given their own X Windows.
> >> I, coming from a Swing background, first had to get over this concept a
> >> little, but then it seemed all logical, and I think most toolkits (at
> >> least in the X world) are implemented like that. And even though not
> >> specified exactly, Java AWT applications expect such behavior from AWT
> >> components.
> >>
> >> What I would like to propose is a kind of blend between the architecture
> >> of the XAWT peers in OpenJDK and the Swing peers: Let all AWT components
> >> be drawn in their own window, but let Swing do the drawing and handling
> >> of logic and events. This way, we would get a maximum portable AWT peer
> >> implementation, that requires only minimal effort to port to any new
> >> platform. The interesting part is to implement this idea:
> >>
> >> The first thing to think about is that all components should have their
> >> own window. To me, this means, that the common superclass of all the
> >> peers, the SwingComponentPeer, must implement all the necessary
> >> windowing behaviour. This is done similarily in the XAWT peers, but in a
> >> very X specific way. All other peers, including the toplevel peers and
> >> the widgets, derive from this class (an exception would probably be the
> >> menu related peers). Since SwingComponentPeer already implements all the
> >> necessary windowing functionality, the toplevel peers don't have much to
> >> do on their own, except delegating to super here and there. The widget
> >> peers now don't search for a parent graphics for drawing, but can do
> >> everything in their own window.
> >>
> >> The tricky part here is, when the SwingComponentPeer is at the top of
> >> the hierarchy, how can we 'plug in' platform specific code there?
> >> Subclassing surely isn't it. My idea is to have a kind of PlatformWindow
> >> interface, which is used by the SwingComponentPeer to delegate all the
> >> real window implementation stuff to. We should be careful to create a
> >> nice clean interface there. Porting the AWT would then be as simple as
> >> implementing this one interface (plus J2D pipeline), and boing! have all
> >> the AWT widgets and toplevel windows available.
> >>
> >> And we need to consider that not only SwingComponentPeer calls into the
> >> PlatformWindow impl, but the PlatformWindow impl also needs to call back
> >> to the SwingComponentPeer for handling events. In the XAWT
> >> implementation this is done by passing back X events. Of course, we
> >> don't want platform specific events in the Swing peers. So the
> >> PlatformWindow implementation needs to take care and transform all
> >> platform specific events to Java AWT events before passing them back to
> >> the SwingComponentPeer. It might be necessary to introduce a couple of
> >> internal peer events for handling stuff that is not covered by the
> >> 'official' AWT events.
> >>
> >> Summary of the architecture outline (this would be a good point to slip
> >> in an UML diagram, but I really don't like diagrams ;-) ):
> >>
> >> SwingComponentPeer is the all-mighty master superclass here. It provides
> >> all the necessary windowing functionality. But it doesn't implement this
> >> itself, but instead delegates to a PlatformWindow implementation.
> >> PlatformWindow would be an interface that specifies all the windowing
> >> functionality that we need from the underlying platform. The
> >> PlatformWindow implementation is also expected to pass all the events
> >> from the window to the SwingComponentPeer, in the form of AWT event
> >> objects (it must already translate the native event types to the
> >> corresponding AWT events). Subclasses of SwingComponentPeer implement
> >> both the widgets as well as the toplevel windows. Drawing the widgets
> >> and handling the state logic of the component is done by Swing.
> >>
> >> Please tell me what you think.
> >>
> >> Cheers, Roman
> >>
-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080904/cfde8264/attachment.bin 

From martinrb at google.com  Thu Sep  4 13:41:31 2008
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 4 Sep 2008 13:41:31 -0700
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: <48BFDEC0.1070902@sun.com>
References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com>
	<1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com>
	<48B679C7.8060605@sun.com>
	<1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com>
	<1ccfd1c10808281458t4ce2543difcb2f3442826e095@mail.gmail.com>
	<48B7CFB6.3020006@sun.com>
	<1ccfd1c10808291056g42f92780n7ca1cedc0530b01b@mail.gmail.com>
	<48BF9B3A.6070701@sun.com>
	<1ccfd1c10809040205r40b2cf53r99feb0620dea7e8c@mail.gmail.com>
	<48BFDEC0.1070902@sun.com>
Message-ID: <1ccfd1c10809041341k22db2a66ua36dc809ebe5e821@mail.gmail.com>

On Thu, Sep 4, 2008 at 06:12, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>> But I've never done a push to awt.  I plan to push
>> to the jdk7/awt-gate/jdk repository.
>> Let me know if that's not the right thing to do.
>
> only group members may push any changes to workspace,

I don't believe that is true - a member of any group can
do pushes to any group forest.  Of course, before doing so,
one gets permission from reviewers who are group members.
I have done pushes to multiple forests already.
I believe the rules for Sun-internal engineers are equally open.

> and each group has its
> own list of trusted contributors, right? I understand you may have pushed
> many patches into different OpenJDK areas, but I don't remember any for AWT
> group.

I have not made many contributions to awt, but IIRC there are some.
You can check for teamware changes by "mb29450".

I'm trying to help Sun do community building.  It helps to empower
external contributors to do as much as possible without involving
a Sun sponsor.  So again, I would like to do the hg push myself.

Thanks,

Martin

> Your current fix looks safe, and I can push it to the workspace, if you
> agree. In any case, thank you for the work,
>
> Artem


From mr at sun.com  Thu Sep  4 20:34:18 2008
From: mr at sun.com (Mark Reinhold)
Date: Thu, 04 Sep 2008 20:34:18 -0700
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: martinrb@google.com; Thu, 04 Sep 2008 13:41:31 PDT;
	<1ccfd1c10809041341k22db2a66ua36dc809ebe5e821@mail.gmail.com> 
Message-ID: <20080905033418.460ED2C2DC@callebaut.niobe.net>

> Date: Thu, 04 Sep 2008 13:41:31 -0700
> From: Martin Buchholz <martinrb at google.com>

> On Thu, Sep 4, 2008 at 06:12, artem.ananiev at sun.com wrote:
>>> But I've never done a push to awt.  I plan to push
>>> to the jdk7/awt-gate/jdk repository.
>>> Let me know if that's not the right thing to do.
>> 
>> only group members may push any changes to workspace,
> 
> I don't believe that is true - a member of any group can
> do pushes to any group forest.

Yes, that's correct.

>				  Of course, before doing so,
> one gets permission from reviewers who are group members.
> I have done pushes to multiple forests already.
> I believe the rules for Sun-internal engineers are equally open.

Right.

>> and each group has its
>> own list of trusted contributors, right? I understand you may have pushed
>> many patches into different OpenJDK areas, but I don't remember any for AWT
>> group.
> 
> I have not made many contributions to awt, but IIRC there are some.
> You can check for teamware changes by "mb29450".
> 
> I'm trying to help Sun do community building.  It helps to empower
> external contributors to do as much as possible without involving
> a Sun sponsor.  So again, I would like to do the hg push myself.

I think Martin's request is entirely reasonable.

- Mark


From mark at klomp.org  Fri Sep  5 02:42:24 2008
From: mark at klomp.org (Mark Wielaard)
Date: Fri, 05 Sep 2008 11:42:24 +0200
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: <1ccfd1c10809041341k22db2a66ua36dc809ebe5e821@mail.gmail.com>
References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com>
	<1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com>
	<48B679C7.8060605@sun.com>
	<1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com>
	<1ccfd1c10808281458t4ce2543difcb2f3442826e095@mail.gmail.com>
	<48B7CFB6.3020006@sun.com>
	<1ccfd1c10808291056g42f92780n7ca1cedc0530b01b@mail.gmail.com>
	<48BF9B3A.6070701@sun.com>
	<1ccfd1c10809040205r40b2cf53r99feb0620dea7e8c@mail.gmail.com>
	<48BFDEC0.1070902@sun.com>
	<1ccfd1c10809041341k22db2a66ua36dc809ebe5e821@mail.gmail.com>
Message-ID: <1220607744.22789.2.camel@dijkstra.wildebeest.org>

Hi Martin,

On Thu, 2008-09-04 at 13:41 -0700, Martin Buchholz wrote:
> I'm trying to help Sun do community building.  It helps to empower
> external contributors to do as much as possible without involving
> a Sun sponsor.

Thanks for being so consistent about pushing for a clear and open
community process to get changes through.

Cheers,

Mark



From Andrei.Dmitriev at Sun.COM  Fri Sep  5 07:13:08 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Fri, 05 Sep 2008 18:13:08 +0400
Subject: <AWT Dev> Ideas about improved architecture
 of	the	generic	Swing peers
In-Reply-To: <1220470826.3600.9.camel@moonlight>
References: <1218794992.6783.44.camel@moonlight>
	<1220353774.8444.16.camel@moonlight> <48BEC812.9080301@sun.com>
	<1220470826.3600.9.camel@moonlight>
Message-ID: <48C13E74.9040000@sun.com>

Hi Roman,

Roman Kennke wrote:
>>  I spent some time walking around the new code and found 
>> this pretty much similar to a prototype which existed by this moment for 
>> a - week or something. :)
> 
> Cool. So maybe it's a good idea to decide for one of the two prototypes,
> either you push out your stuff in the open and we work together on that,
> or we continue together on the Cacio peers. What do you think? It
> doesn't seem to make sense to develop two implementations in parallel...
Right, but the thing is the progress there is more than poor - can't 
afford much time spending on that. Anyway, that is a hack into the 
XToolkit stack directly and that saved me a lot of time as there is no 
need to build the hierarchy from "scratch", just picked the existing 
stuff up.
I realize that solution isn't so flexible and are considered like a 
proof of concept.

> 
>> You did inherited from the SunToolkit class and left Runnable aside. 
>> Perhaps this could save some more lines of code.
> 
> Surely. I'm not sure yet what SunToolkit has to do with Runnable, but I
> guess I'll study the code and learn :-)
> 
> 
>> As a matter of fact I also tried some more complicated AWT test which I 
>> believe covers all components and failed on TextArea peer 
>> initialization.
> 
> Yeha! I only implemented Window, Frame, Canvas, Button and Label so far.
> The other toplevels and Panel seem to be some more low hanging fruits.
> The text components shouldn't be so bad - I already had these working to
> some degree in the old Swing peers of GNU Classpath. What I'm really
> scared about are the compound components like Scrollpane and Choice and
> the Menu related stuff.
Sigh, agree, that must be a scrupulous job. XChoice peer has never been 
in a good shape. :)
Thanks,
   Andrei

> 
>>  The good thing is we actually have semi-lightweight peer 
>> for text components in X11 code so we probably may be kept from part of 
>> this work. Just in case you haven't realized that yet. :)
> 
> Yeah, I've seen that. Very cool. Infact, my inspiration for all this is
> both the XAWT peers of OpenJDK and my old work on GNU Classpath, and to
> me, this new code is a merge of ideas from both.
> 
>> Thanks,
>>    Andrei
> 
> Thank you!
> 
> /Roman
> 


From roman.kennke at aicas.com  Fri Sep  5 11:55:05 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Fri, 05 Sep 2008 20:55:05 +0200
Subject: <AWT Dev> [PATCH] SwingUtilities2.isLocalDisplay()
Message-ID: <1220640905.6422.43.camel@moonlight>

Hi there,

I've just synced up the Cacio forest with the JDK7 master forest, and
I'd like to discuss and try to merge back (into JDK7) some of our
patches. The following one affects all of AWT, Swing and J2D, this is
why I'm posting it to 3 lists at once.

In SwingUtilities2.isLocalDisplay(), we have some crazy platform
specific code to find if we have a local display or not. This is of
course not very nice for other Toolkit implementations than the Win32
and X11 ones in OpenJDK. Our solution is to introduce an abstract method
isLocalDisplay() in SunGraphicsEnvironment, which we call from
SwingUtilities2. This method is then overridden by the specific GE
implementations. If we don't have a SGE, we assume a local display.

There are also some changes in the native font code, which used to call
the static X11GraphicsEnvironment.isLocalDisplay(), to call the new
instance method in SGE.

What do you think? Is this reasonable to merge into mainline?

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt
-------------- next part --------------
# HG changeset patch
# User Mario Torre <mario.torre at aicas.com>
# Date 1217450571 -7200
# Node ID f3ae1241a9b87efec5e22618dcf978ae38c94abd
# Parent  9e3c020a78dd72dcbcc8580762f2542055110e2e
imported patch j2d-localdisplay.patch

diff -r 9e3c020a78dd -r f3ae1241a9b8 src/share/classes/sun/java2d/SunGraphicsEnvironment.java
--- a/src/share/classes/sun/java2d/SunGraphicsEnvironment.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/sun/java2d/SunGraphicsEnvironment.java	Wed Jul 30 22:42:51 2008 +0200
@@ -1270,6 +1270,13 @@
         displayChanger.notifyPaletteChanged();
     }
 
+    /**
+     * Returns true when the display is local, false for remote displays.
+     *
+     * @return true when the display is local, false for remote displays
+     */
+    public abstract boolean isDisplayLocal();
+
     /*
      * ----DISPLAY CHANGE SUPPORT----
      */
diff -r 9e3c020a78dd -r f3ae1241a9b8 src/share/classes/sun/swing/SwingUtilities2.java
--- a/src/share/classes/sun/swing/SwingUtilities2.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/sun/swing/SwingUtilities2.java	Wed Jul 30 22:42:51 2008 +0200
@@ -55,6 +55,7 @@
 import java.util.*;
 import sun.font.FontDesignMetrics;
 import sun.font.FontManager;
+import sun.java2d.SunGraphicsEnvironment;
 
 import java.util.concurrent.Callable;
 import java.util.concurrent.Future;
@@ -1482,22 +1483,14 @@
      * appear capable of performing gamma correction needed for LCD text.
      */
     public static boolean isLocalDisplay() {
-        try {
-            // On Windows just return true. Permission to read os.name
-            // is granted to all code but wrapped in try to be safe.
-            if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
-                return true;
-            }
-            // Else probably Solaris or Linux in which case may be remote X11
-            Class x11Class = Class.forName("sun.awt.X11GraphicsEnvironment");
-            Method isDisplayLocalMethod = x11Class.getMethod(
-                      "isDisplayLocal", new Class[0]);
-            return (Boolean)isDisplayLocalMethod.invoke(null, (Object[])null);
-        } catch (Throwable t) {
+        boolean isLocal;
+        GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
+        if (ge instanceof SunGraphicsEnvironment) {
+            isLocal = ((SunGraphicsEnvironment) ge).isDisplayLocal();
+        } else {
+            isLocal = true;
         }
-        // If we get here we're most likely being run on some other O/S
-        // or we didn't properly detect Windows.
-        return true;
+        return isLocal;
     }
 
     /**
diff -r 9e3c020a78dd -r f3ae1241a9b8 src/solaris/classes/sun/awt/X11GraphicsEnvironment.java
--- a/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java	Wed Jul 30 22:42:51 2008 +0200
@@ -208,7 +208,7 @@
     private static native int checkShmExt();
 
     private static  native String getDisplayString();
-    private static Boolean isDisplayLocal;
+    private Boolean isDisplayLocal;
 
     /**
      * This should only be called from the static initializer, so no need for
@@ -233,7 +233,7 @@
         return getScreenDevices()[getDefaultScreenNum()];
     }
 
-    public static boolean isDisplayLocal() {
+    public boolean isDisplayLocal() {
         if (isDisplayLocal == null) {
             SunToolkit.awtLock();
             try {
diff -r 9e3c020a78dd -r f3ae1241a9b8 src/solaris/native/sun/awt/fontpath.c
--- a/src/solaris/native/sun/awt/fontpath.c	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/solaris/native/sun/awt/fontpath.c	Wed Jul 30 22:42:51 2008 +0200
@@ -150,15 +150,26 @@
     static jboolean isLocalSet = False;
     jboolean ret;
 
-    if (isLocalSet) {
-        return isLocal;
+    if (! isLocalSet) {
+      jclass geCls = (*env)->FindClass(env, "java/awt/GraphicsEnvironment");
+      jmethodID getLocalGE = (*env)->GetStaticMethodID(env, geCls,
+                                                 "getLocalGraphicsEnvironment",
+                                           "()Ljava/awt/GraphicsEnvironment;");
+      jobject ge = (*env)->CallStaticObjectMethod(env, geCls, getLocalGE);
+
+      jclass sgeCls = (*env)->FindClass(env,
+                                        "sun/java2d/SunGraphicsEnvironment");
+      if ((*env)->IsInstanceOf(env, ge, sgeCls)) {
+        jmethodID isDisplayLocal = (*env)->GetMethodID(env, sgeCls,
+                                                       "isDisplayLocal",
+                                                       "()Z");
+        isLocal = (*env)->CallBooleanMethod(env, ge, isDisplayLocal);
+      } else {
+        isLocal = True;
+      }
+      isLocalSet = True;
     }
 
-    isLocal = JNU_CallStaticMethodByName(env, NULL,
-                                         "sun/awt/X11GraphicsEnvironment",
-                                         "isDisplayLocal",
-                                         "()Z").z;
-    isLocalSet = True;
     return isLocal;
 }
 
diff -r 9e3c020a78dd -r f3ae1241a9b8 src/windows/classes/sun/awt/Win32GraphicsEnvironment.java
--- a/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java	Wed Jul 30 22:42:51 2008 +0200
@@ -346,4 +346,8 @@
 
         return new WFontConfiguration(this, preferLocaleFonts,preferPropFonts);
     }
+
+    public boolean isDisplayLocal() {
+        return true;
+    }
 }

From Dmitri.Trembovetski at Sun.COM  Fri Sep  5 13:25:25 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Fri, 05 Sep 2008 13:25:25 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <1220640905.6422.43.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
Message-ID: <48C195B5.2010205@Sun.COM>


   Hi Roman,

   the patch looks reasonable to me.

   Thanks,
     Dmitri


Roman Kennke wrote:
> Hi there,
> 
> I've just synced up the Cacio forest with the JDK7 master forest, and
> I'd like to discuss and try to merge back (into JDK7) some of our
> patches. The following one affects all of AWT, Swing and J2D, this is
> why I'm posting it to 3 lists at once.
> 
> In SwingUtilities2.isLocalDisplay(), we have some crazy platform
> specific code to find if we have a local display or not. This is of
> course not very nice for other Toolkit implementations than the Win32
> and X11 ones in OpenJDK. Our solution is to introduce an abstract method
> isLocalDisplay() in SunGraphicsEnvironment, which we call from
> SwingUtilities2. This method is then overridden by the specific GE
> implementations. If we don't have a SGE, we assume a local display.
> 
> There are also some changes in the native font code, which used to call
> the static X11GraphicsEnvironment.isLocalDisplay(), to call the new
> instance method in SGE.
> 
> What do you think? Is this reasonable to merge into mainline?
> 
> /Roman
> 
> 


From son.two at gmail.com  Fri Sep  5 21:07:15 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Sat, 6 Sep 2008 08:07:15 +0400
Subject: <AWT Dev> [PATCH] SwingUtilities2.isLocalDisplay()
In-Reply-To: <1220640905.6422.43.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
Message-ID: <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>

I'm not the person who is supposed to review this changes from
technical point of view,
but I have one concern about idea of the fix.  It adds one more place
where Swing uses sun-specific API.
Of course you can say that SwingUtilities2.isLocalDisplay() even
before your fix uses code which is specific
for Sun's implementation, and you will be right.  But this doesn't
mean that we should leave with this.
IMHO, if we change such code we should remove dependency between Swing
and Sun-specific code,
i.e. we should add public API.

Regards, Oleg.

On Fri, Sep 5, 2008 at 10:55 PM, Roman Kennke <roman.kennke at aicas.com> wrote:
> Hi there,
>
> I've just synced up the Cacio forest with the JDK7 master forest, and
> I'd like to discuss and try to merge back (into JDK7) some of our
> patches. The following one affects all of AWT, Swing and J2D, this is
> why I'm posting it to 3 lists at once.
>
> In SwingUtilities2.isLocalDisplay(), we have some crazy platform
> specific code to find if we have a local display or not. This is of
> course not very nice for other Toolkit implementations than the Win32
> and X11 ones in OpenJDK. Our solution is to introduce an abstract method
> isLocalDisplay() in SunGraphicsEnvironment, which we call from
> SwingUtilities2. This method is then overridden by the specific GE
> implementations. If we don't have a SGE, we assume a local display.
>
> There are also some changes in the native font code, which used to call
> the static X11GraphicsEnvironment.isLocalDisplay(), to call the new
> instance method in SGE.
>
> What do you think? Is this reasonable to merge into mainline?
>
> /Roman
>
> --
> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
> aicas Allerton Interworks Computer Automated Systems GmbH
> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
> http://www.aicas.com   * Tel: +49-721-663 968-48
> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
> Gesch?ftsf?hrer: Dr. James J. Hunt
>

From oleg.sukhodolsky at gmail.com  Fri Sep  5 21:16:36 2008
From: oleg.sukhodolsky at gmail.com (Oleg Sukhodolsky)
Date: Sat, 6 Sep 2008 08:16:36 +0400
Subject: <AWT Dev> Ideas about improved architecture of the generic
	Swing peers
In-Reply-To: <1220353774.8444.16.camel@moonlight>
References: <1218794992.6783.44.camel@moonlight>
	<1220353774.8444.16.camel@moonlight>
Message-ID: <271e55d20809052116he4e24e9t659e3f0d67121096@mail.gmail.com>

I like the idea, but I'll add some skepticism to your discussion :)

Based on our previous experience with text components in XAWT? I'd say that
this can be hard (very hard or even impossible( to write GOOD AWT components
using Swing.  By "good" I mean components which will compatible with current
behavior of the same component.  Also I wonder if AWT component will
have  AWT LaF
when it is being used in application which uses both AWT and Swing.

So, I'd suggest to run JCK tests on this new toolkit and be a little
bit more skeptic and
try to find weak places of this approach.  Because if you want to
incorporate this toolkit to
JDK you must have compatible behavior, LaF, and pass JCK.

Regards, Oleg.

On Tue, Sep 2, 2008 at 3:09 PM, Roman Kennke <roman at kennke.org> wrote:
> Hi folks,
>
> I'm CCing awt-dev now, I think this could be interesting. Please scroll
> down and read the original mail so that you know what I'm talking about.
> Basically, I'm trying to implement AWT peers that are based on Swing
> (for the widgets) and require minimum effort for porting to new
> platforms. Basically, the only thing that is required to be implemented
> on a new platform is the windowing functionality, abstracted out nicely
> by the PlatformWindow interface.
>
> Today I pushed a first prototype of the new Swing based AWT peers. It
> follows the basic architecture described in the original email (all
> components have their own native window, which is abstracted behind an
> interface, components are backed by their Swing counterparts for drawing
> and state handling). So far, this only serves as proof-of-concept. It is
> possible to open a Frame and put Canvas inside it. The code is based on
> the patches of the Caciocavallo project (which should probably be merged
> in mainline at some point). You can find the code here:
>
> http://hg.openjdk.java.net/caciocavallo/ng/
>
> The basic framework is located in the package sun.awt.peer.cacio, an
> example implementation based on Escher [1] can be found in
> gnu.java.awt.peer.x (start looking at EscherToolkit maybe).
>
> and the patched OpenJDK forest here:
>
> http://hg.openjdk.java.net/caciocavallo/jdk7/
>
>
> Questions, suggestions, comments and code are heartily welcome :-)
>
> Cheers, Roman
>
> [1] http://escher.sf.net
>
> Am Freitag, den 15.08.2008, 12:09 +0200 schrieb Roman Kennke:
>> Hello people,
>>
>> I'd like to outline my ideas about an improved architecture of the
>> generic Swing based peers. But let me first describe the current state
>> and the problem(s) we need to address:
>>
>> Currently, the Swing peers implement most of the peers in
>> java.awt.peer.* (well ok, minus a couple of complex ones, like
>> ScrollPane, Choice, etc). They are not supposed to work standalone, but
>> need some support by a real backend. Most notably, this would be an
>> implementation of java.awt.Toolkit and the top-level window peers
>> (WindowPeer, DialogPeer and FramePeer). Based on these toplevel windows,
>> the Swing peers handle all the widgets in a semi-lightweight fashion:
>> all the drawing is done using Graphics contexts from the toplevel
>> windows. However, the actual Swing components are not connected to the
>> component hierarchy in any way, they are only 'hooked in' in a way, so
>> that from the perspective of the Swing component it appears as if it
>> were in the component hierarchy, but infact it isn't (from the
>> perspective of the hierarchy).
>>
>> This architecture, requiring the real backend to implement the toplevel
>> windows, and do everything else in a quasi-lightweight fashion has some
>> disadvantages, or at least, one big disadvantage. It is really hard to
>> get the special behaviour of AWT heavyweight components correct. For
>> example, suppose you have a Frame, inside this frame you have a Swing
>> component, and a Panel. The panel would always be on top of the Swing
>> component, regardless of the stacking order in the window. To make it
>> even more complex, if you had a Swing component in the Panel, it would
>> be drawn on the Panel, not on the Window (an thus, it would appear to be
>> always on top of the other Swing component). To get this right in the
>> Swing peers, we had to implement a bunch of hacks, that involve double
>> buffers for all components and other ugly stuff, and it never worked
>> really well.
>>
>> The answer, for me, was found in the implementation of the XWindow peers
>> in OpenJDK. All AWT components are 'simply' given their own X Windows.
>> I, coming from a Swing background, first had to get over this concept a
>> little, but then it seemed all logical, and I think most toolkits (at
>> least in the X world) are implemented like that. And even though not
>> specified exactly, Java AWT applications expect such behavior from AWT
>> components.
>>
>> What I would like to propose is a kind of blend between the architecture
>> of the XAWT peers in OpenJDK and the Swing peers: Let all AWT components
>> be drawn in their own window, but let Swing do the drawing and handling
>> of logic and events. This way, we would get a maximum portable AWT peer
>> implementation, that requires only minimal effort to port to any new
>> platform. The interesting part is to implement this idea:
>>
>> The first thing to think about is that all components should have their
>> own window. To me, this means, that the common superclass of all the
>> peers, the SwingComponentPeer, must implement all the necessary
>> windowing behaviour. This is done similarily in the XAWT peers, but in a
>> very X specific way. All other peers, including the toplevel peers and
>> the widgets, derive from this class (an exception would probably be the
>> menu related peers). Since SwingComponentPeer already implements all the
>> necessary windowing functionality, the toplevel peers don't have much to
>> do on their own, except delegating to super here and there. The widget
>> peers now don't search for a parent graphics for drawing, but can do
>> everything in their own window.
>>
>> The tricky part here is, when the SwingComponentPeer is at the top of
>> the hierarchy, how can we 'plug in' platform specific code there?
>> Subclassing surely isn't it. My idea is to have a kind of PlatformWindow
>> interface, which is used by the SwingComponentPeer to delegate all the
>> real window implementation stuff to. We should be careful to create a
>> nice clean interface there. Porting the AWT would then be as simple as
>> implementing this one interface (plus J2D pipeline), and boing! have all
>> the AWT widgets and toplevel windows available.
>>
>> And we need to consider that not only SwingComponentPeer calls into the
>> PlatformWindow impl, but the PlatformWindow impl also needs to call back
>> to the SwingComponentPeer for handling events. In the XAWT
>> implementation this is done by passing back X events. Of course, we
>> don't want platform specific events in the Swing peers. So the
>> PlatformWindow implementation needs to take care and transform all
>> platform specific events to Java AWT events before passing them back to
>> the SwingComponentPeer. It might be necessary to introduce a couple of
>> internal peer events for handling stuff that is not covered by the
>> 'official' AWT events.
>>
>> Summary of the architecture outline (this would be a good point to slip
>> in an UML diagram, but I really don't like diagrams ;-) ):
>>
>> SwingComponentPeer is the all-mighty master superclass here. It provides
>> all the necessary windowing functionality. But it doesn't implement this
>> itself, but instead delegates to a PlatformWindow implementation.
>> PlatformWindow would be an interface that specifies all the windowing
>> functionality that we need from the underlying platform. The
>> PlatformWindow implementation is also expected to pass all the events
>> from the window to the SwingComponentPeer, in the form of AWT event
>> objects (it must already translate the native event types to the
>> corresponding AWT events). Subclasses of SwingComponentPeer implement
>> both the widgets as well as the toplevel windows. Drawing the widgets
>> and handling the state logic of the component is done by Swing.
>>
>> Please tell me what you think.
>>
>> Cheers, Roman
>>
> --
> http://kennke.org/blog/
>


From roman at kennke.org  Sat Sep  6 02:01:48 2008
From: roman at kennke.org (Roman Kennke)
Date: Sat, 06 Sep 2008 11:01:48 +0200
Subject: <AWT Dev> Ideas about improved architecture of the
	generic	Swing peers
In-Reply-To: <271e55d20809052116he4e24e9t659e3f0d67121096@mail.gmail.com>
References: <1218794992.6783.44.camel@moonlight>
	<1220353774.8444.16.camel@moonlight>
	<271e55d20809052116he4e24e9t659e3f0d67121096@mail.gmail.com>
Message-ID: <1220691708.6571.19.camel@moonlight>

Thanks Oleg, I really like scepticism :-)

> Based on our previous experience with text components in XAWT? I'd say that
> this can be hard (very hard or even impossible( to write GOOD AWT components
> using Swing.  By "good" I mean components which will compatible with current
> behavior of the same component.

I see this is a problem, but nothing that can't be solved with some
hacking :-)

>   Also I wonder if AWT component will
> have  AWT LaF
> when it is being used in application which uses both AWT and Swing.

Eh, I was not aware there was something like AWT LaF. I thought AWT just
uses whatever the backend uses (Motif, Win32, or in the case of GNU
Classpath, GTK or Qt). Having the same LaF for Swing and AWT should be
good IMO. But if not, it should be possible to install a special UI
class on the backing Swing components...

> So, I'd suggest to run JCK tests on this new toolkit and be a little
> bit more skeptic and
> try to find weak places of this approach.

Surely I am. Regarding the JCK - yeah funny. Give me access to it, and
I'll do it :-)

>   Because if you want to
> incorporate this toolkit to
> JDK you must have compatible behavior, LaF, and pass JCK.

I can solve the first two points (compatibility and LaF) but not the
last one :-)

Thanks for giving me some perspective.

Cheers, Roman

-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080906/bf3d71af/attachment.bin 

From roman.kennke at aicas.com  Sat Sep  6 02:04:01 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Sat, 06 Sep 2008 11:04:01 +0200
Subject: <AWT Dev> [PATCH] SwingUtilities2.isLocalDisplay()
In-Reply-To: <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
Message-ID: <1220691841.6571.22.camel@moonlight>

Hi Oleg,

> I'm not the person who is supposed to review this changes from
> technical point of view,
> but I have one concern about idea of the fix.  It adds one more place
> where Swing uses sun-specific API.

No. It takes advantage of Sun internal API, but it does not depend on
it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
else { useReasonableDefault(); } ).

> Of course you can say that SwingUtilities2.isLocalDisplay() even
> before your fix uses code which is specific
> for Sun's implementation, and you will be right.  But this doesn't
> mean that we should leave with this.
> IMHO, if we change such code we should remove dependency between Swing
> and Sun-specific code,
> i.e. we should add public API.

I completely agree. That, of course, would be the best solution. But in
the past it has been communicated several times to me that I can't just
send in patches to public API and hope that it will be accepted easily.
I propose to get in this patch if possible first, then start a
discussion about adding public API.

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From neugens at limasoftware.net  Sat Sep  6 04:54:09 2008
From: neugens at limasoftware.net (Mario Torre)
Date: Sat, 06 Sep 2008 13:54:09 +0200
Subject: <AWT Dev> Ideas about improved architecture of the
	generic	Swing peers
In-Reply-To: <1220691708.6571.19.camel@moonlight>
References: <1218794992.6783.44.camel@moonlight>
	<1220353774.8444.16.camel@moonlight>
	<271e55d20809052116he4e24e9t659e3f0d67121096@mail.gmail.com>
	<1220691708.6571.19.camel@moonlight>
Message-ID: <1220702049.3290.7.camel@nirvana>

Il giorno sab, 06/09/2008 alle 11.01 +0200, Roman Kennke ha scritto:

Hi all!

> I see this is a problem, but nothing that can't be solved with some
> hacking :-)

SMOP :)

> >   Because if you want to
> > incorporate this toolkit to
> > JDK you must have compatible behavior, LaF, and pass JCK.
> 
> I can solve the first two points (compatibility and LaF) but not the
> last one :-)

Maybe you guys at Sun can do this for us, but I find it quite odd, maybe
OpenJDK sponsored projects should have access to the JCK?

I think it's important to do this while we develop the software so we
can fix problems in realtime, especially design issues, because we then
have to live with them, I don't want to do the wrong thing here.

Thanks for adding some pepper to the mix, though :)

Cheers,
Mario



From mark at klomp.org  Sun Sep  7 04:29:29 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 07 Sep 2008 13:29:29 +0200
Subject: <AWT Dev> Ideas about improved architecture of
	the	generic	Swing peers
In-Reply-To: <1220702049.3290.7.camel@nirvana>
References: <1218794992.6783.44.camel@moonlight>
	<1220353774.8444.16.camel@moonlight>
	<271e55d20809052116he4e24e9t659e3f0d67121096@mail.gmail.com>
	<1220691708.6571.19.camel@moonlight> <1220702049.3290.7.camel@nirvana>
Message-ID: <1220786969.3614.12.camel@hermans.wildebeest.org>

Hi,

On Sat, 2008-09-06 at 13:54 +0200, Mario Torre wrote:
> Il giorno sab, 06/09/2008 alle 11.01 +0200, Roman Kennke ha scritto:
> > >   Because if you want to
> > > incorporate this toolkit to
> > > JDK you must have compatible behavior, LaF, and pass JCK.
> > 
> > I can solve the first two points (compatibility and LaF) but not the
> > last one :-)
> 
> Maybe you guys at Sun can do this for us, but I find it quite odd, maybe
> OpenJDK sponsored projects should have access to the JCK?
> 
> I think it's important to do this while we develop the software so we
> can fix problems in realtime, especially design issues, because we then
> have to live with them, I don't want to do the wrong thing here.

Yeah, requiring passing a proprietary closed, legally troublesome
testsuite only available under NDA is somewhat odd for contributions to
an open free software community project. The JCK is proprietary and
access is only granted under NDA so it is impossible to share tests and
code snippets from it with the rest of the community. It seems only fair
that someone that wants to require JCK passing does the testing
themselves and rewrites any failing tests for the community contributors
so you can at least share those publicly with others on the mailinglists
and everybody can see and verify the reasons why certain design
decisions have been taken.

The current proprietary nature of the JCK also prevents most distros
from running it since their build systems are public. So running the TCK
can only be done afterward by another entity that has some proprietary
closed secret setup on the binaries. Which is really a bit too late for
a community project. (Luckily most distros do run the mauve and
integrated jtreg tests now for each build of icedtea.)

So I agree that all this sounds a bit odd. We really should start
working on some way to make new TCK tests (for JDK7 at least) added as
free software (to either the standard jtreg or mauve suite) so they can
be shared like the rest of OpenJDK. So that we will no longer be dragged
down by the current proprietary NDA JCK setup.

Cheers,

Mark



From Dalibor.Topic at Sun.COM  Sun Sep  7 17:09:36 2008
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Mon, 08 Sep 2008 02:09:36 +0200
Subject: <AWT Dev> Ideas about improved architecture of
 the	generic	Swing peers
In-Reply-To: <1220691708.6571.19.camel@moonlight>
References: <1218794992.6783.44.camel@moonlight>
	<1220353774.8444.16.camel@moonlight>
	<271e55d20809052116he4e24e9t659e3f0d67121096@mail.gmail.com>
	<1220691708.6571.19.camel@moonlight>
Message-ID: <48C46D40.3060507@sun.com>

Roman Kennke wrote:
> Surely I am. Regarding the JCK - yeah funny. Give me access to it, and
> I'll do it :-)
>   
http://openjdk.java.net/groups/conformance/JckAccess/index.html 

cheers,
dalibor topic

-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer
Vorsitzender des Aufsichtsrates: Martin H?ring




From Artem.Ananiev at Sun.COM  Mon Sep  8 01:37:53 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Mon, 08 Sep 2008 12:37:53 +0400
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: <1ccfd1c10809072139rbeb31ceh55eb24b028fab9c2@mail.gmail.com>
References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com>
	<48B679C7.8060605@sun.com>
	<1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com>
	<1ccfd1c10808281458t4ce2543difcb2f3442826e095@mail.gmail.com>
	<48B7CFB6.3020006@sun.com>
	<1ccfd1c10808291056g42f92780n7ca1cedc0530b01b@mail.gmail.com>
	<48BF9B3A.6070701@sun.com>
	<1ccfd1c10809040205r40b2cf53r99feb0620dea7e8c@mail.gmail.com>
	<48BFDEC0.1070902@sun.com>
	<1ccfd1c10809041341k22db2a66ua36dc809ebe5e821@mail.gmail.com>
	<1ccfd1c10809072139rbeb31ceh55eb24b028fab9c2@mail.gmail.com>
Message-ID: <48C4E461.8000503@sun.com>

Hi, Martin,

yes, the patch is OK, and you can push it to AWT gate.

Thanks,

Artem

Martin Buchholz wrote:
> Artem and/or Anthony,
> 
> Ping: Can I get an OK to commit this to awt-gate/jdk?
> 
> Martin
> 
> On Thu, Sep 4, 2008 at 13:41, Martin Buchholz <martinrb at google.com> wrote:
>> On Thu, Sep 4, 2008 at 06:12, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>>>> But I've never done a push to awt.  I plan to push
>>>> to the jdk7/awt-gate/jdk repository.
>>>> Let me know if that's not the right thing to do.
>>> only group members may push any changes to workspace,
>> I don't believe that is true - a member of any group can
>> do pushes to any group forest.  Of course, before doing so,
>> one gets permission from reviewers who are group members.
>> I have done pushes to multiple forests already.
>> I believe the rules for Sun-internal engineers are equally open.
>>
>>> and each group has its
>>> own list of trusted contributors, right? I understand you may have pushed
>>> many patches into different OpenJDK areas, but I don't remember any for AWT
>>> group.
>> I have not made many contributions to awt, but IIRC there are some.
>> You can check for teamware changes by "mb29450".
>>
>> I'm trying to help Sun do community building.  It helps to empower
>> external contributors to do as much as possible without involving
>> a Sun sponsor.  So again, I would like to do the hg push myself.
>>
>> Thanks,
>>
>> Martin
>>
>>> Your current fix looks safe, and I can push it to the workspace, if you
>>> agree. In any case, thank you for the work,
>>>
>>> Artem


From mr at sun.com  Mon Sep  8 09:53:54 2008
From: mr at sun.com (Mark Reinhold)
Date: Mon, 08 Sep 2008 09:53:54 -0700
Subject: <AWT Dev> [indiana-discuss] any hope to see java5 into indiana?
In-Reply-To: luca@morettoni.net; Mon, 08 Sep 2008 16:24:15 +0200;
	<48C5358F.7060607@morettoni.net> 
Message-ID: <20080908165354.1AFC0611E@eggemoggin.niobe.net>

> Date: Mon, 08 Sep 2008 16:24:15 +0200
> From: Luca Morettoni <luca at morettoni.net>

> I try to install java5SE under indiana snv_96 (for sun spot developing)
> put if I try to intall java5 pkg's I receive the warning about motif
> package, and when I run javaws I receive this error:
> 
> $ javaws
> Exception in thread "main" java.lang.UnsatisfiedLinkError:
> /usr/jdk/instances/jdk1.5.0/jre/lib/i386/motif21/libmawt.so: ld.so.1:
> java: fatal: libXm.so.4: open failed: No such file or directory
> 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
> 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1647)
> 	at java.lang.Runtime.load0(Runtime.java:769)
> 
> any hope to use java5 and/or sun Spot under opensolaris?

The default AWT toolkit in JDK 5 on Solaris is Motif, but OpenSolaris
doesn't (yet, so far as I know) have a Motif library.

In JDK 5 there's an alternative AWT toolkit, XAWT, which is a complete
rewrite that depends only upon Xlib and contains very little native code.
XAWT became the default on Solaris in JDK 6, but you can enable it on JDK
5 by following the instructions in the JDK 5 AWT guide [1].

A higher-level question, though, is why do you need JDK 5 in the first
place?  If there's a compatibility issue preventing you from using JDK 6
then we'd really like to know about it.

- Mark


[1] http://java.sun.com/j2se/1.5.0/docs/guide/awt/1.5/xawt.html


From roman.kennke at aicas.com  Mon Sep  8 12:04:33 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Mon, 08 Sep 2008 21:04:33 +0200
Subject: <AWT Dev> [PATCH] SwingUtilities2.isLocalDisplay()
In-Reply-To: <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
Message-ID: <1220900673.7112.25.camel@moonlight>

Hi Oleg and lists,

> >> I'm not the person who is supposed to review this changes from
> >> technical point of view,
> >> but I have one concern about idea of the fix.  It adds one more place
> >> where Swing uses sun-specific API.
> >
> > No. It takes advantage of Sun internal API, but it does not depend on
> > it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
> > else { useReasonableDefault(); } ).
> 
> it uses Sun-specific class, so this code can not be compiled by JDK
> from another vendor :(

Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
(Ok, the Caciocavallo project will certainly help alot, but we are still
very far away from such a portable Swing).

> >> Of course you can say that SwingUtilities2.isLocalDisplay() even
> >> before your fix uses code which is specific
> >> for Sun's implementation, and you will be right.  But this doesn't
> >> mean that we should leave with this.
> >> IMHO, if we change such code we should remove dependency between Swing
> >> and Sun-specific code,
> >> i.e. we should add public API.
> >
> > I completely agree. That, of course, would be the best solution. But in
> > the past it has been communicated several times to me that I can't just
> > send in patches to public API and hope that it will be accepted easily.
> > I propose to get in this patch if possible first, then start a
> > discussion about adding public API.
> 
> I understand your point, but I have a feeling that we you will not
> start the discussion right now,
> the idea of new API may be lost :(  So, I'd suggest to try one more time ;)

Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
method is now declared in GraphicsEnvironment, with the addition of
throwing a HeadlessException in the headless case. Also, in fontpath.c,
we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
call it on X11GraphicsEnvironment only. In my original patch I tried to
be more portable by calling
GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
this resulted in an initialization loop (this code is very sensible to
this kind of problem). I left that out for now, because fontpath.c is
X11 specific anyway, and a real solution will come soon in the form of a
huge FontManager patch :-)

What do you think? Can we add this API to GE?

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From roman.kennke at aicas.com  Mon Sep  8 12:11:14 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Mon, 08 Sep 2008 21:11:14 +0200
Subject: <AWT Dev> [PATCH] SwingUtilities2.isLocalDisplay()
In-Reply-To: <1220900673.7112.25.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
Message-ID: <1220901074.7112.27.camel@moonlight>

Bah, forgot the actual patch. Here it comes now!

/Roman

Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
> Hi Oleg and lists,
> 
> > >> I'm not the person who is supposed to review this changes from
> > >> technical point of view,
> > >> but I have one concern about idea of the fix.  It adds one more place
> > >> where Swing uses sun-specific API.
> > >
> > > No. It takes advantage of Sun internal API, but it does not depend on
> > > it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
> > > else { useReasonableDefault(); } ).
> > 
> > it uses Sun-specific class, so this code can not be compiled by JDK
> > from another vendor :(
> 
> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
> (Ok, the Caciocavallo project will certainly help alot, but we are still
> very far away from such a portable Swing).
> 
> > >> Of course you can say that SwingUtilities2.isLocalDisplay() even
> > >> before your fix uses code which is specific
> > >> for Sun's implementation, and you will be right.  But this doesn't
> > >> mean that we should leave with this.
> > >> IMHO, if we change such code we should remove dependency between Swing
> > >> and Sun-specific code,
> > >> i.e. we should add public API.
> > >
> > > I completely agree. That, of course, would be the best solution. But in
> > > the past it has been communicated several times to me that I can't just
> > > send in patches to public API and hope that it will be accepted easily.
> > > I propose to get in this patch if possible first, then start a
> > > discussion about adding public API.
> > 
> > I understand your point, but I have a feeling that we you will not
> > start the discussion right now,
> > the idea of new API may be lost :(  So, I'd suggest to try one more time ;)
> 
> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
> method is now declared in GraphicsEnvironment, with the addition of
> throwing a HeadlessException in the headless case. Also, in fontpath.c,
> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
> call it on X11GraphicsEnvironment only. In my original patch I tried to
> be more portable by calling
> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
> this resulted in an initialization loop (this code is very sensible to
> this kind of problem). I left that out for now, because fontpath.c is
> X11 specific anyway, and a real solution will come soon in the form of a
> huge FontManager patch :-)
> 
> What do you think? Can we add this API to GE?
> 
> /Roman
> 
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 4808 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080908/8cfaf878/attachment.bin 

From martinrb at google.com  Mon Sep  8 17:28:35 2008
From: martinrb at google.com (martinrb at google.com)
Date: Tue, 09 Sep 2008 00:28:35 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6744609: Disable MMX support when
	building libpng	library
Message-ID: <20080909002846.9E958D56F@hg.openjdk.java.net>

Changeset: 31a7769b5fd1
Author:    martin
Date:      2008-09-08 17:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/31a7769b5fd1

6744609: Disable MMX support when building libpng library
Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux
Reviewed-by: anthony, art

! make/sun/splashscreen/Makefile



From son.two at gmail.com  Mon Sep  8 20:26:46 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Tue, 9 Sep 2008 07:26:46 +0400
Subject: <AWT Dev> [PATCH] SwingUtilities2.isLocalDisplay()
In-Reply-To: <1220901074.7112.27.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
Message-ID: <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>

I'd vote for this API, but it is 2D team who should make the decision.

Oleg.

On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke <roman.kennke at aicas.com> wrote:
> Bah, forgot the actual patch. Here it comes now!
>
> /Roman
>
> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
>> Hi Oleg and lists,
>>
>> > >> I'm not the person who is supposed to review this changes from
>> > >> technical point of view,
>> > >> but I have one concern about idea of the fix.  It adds one more place
>> > >> where Swing uses sun-specific API.
>> > >
>> > > No. It takes advantage of Sun internal API, but it does not depend on
>> > > it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
>> > > else { useReasonableDefault(); } ).
>> >
>> > it uses Sun-specific class, so this code can not be compiled by JDK
>> > from another vendor :(
>>
>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
>> (Ok, the Caciocavallo project will certainly help alot, but we are still
>> very far away from such a portable Swing).
>>
>> > >> Of course you can say that SwingUtilities2.isLocalDisplay() even
>> > >> before your fix uses code which is specific
>> > >> for Sun's implementation, and you will be right.  But this doesn't
>> > >> mean that we should leave with this.
>> > >> IMHO, if we change such code we should remove dependency between Swing
>> > >> and Sun-specific code,
>> > >> i.e. we should add public API.
>> > >
>> > > I completely agree. That, of course, would be the best solution. But in
>> > > the past it has been communicated several times to me that I can't just
>> > > send in patches to public API and hope that it will be accepted easily.
>> > > I propose to get in this patch if possible first, then start a
>> > > discussion about adding public API.
>> >
>> > I understand your point, but I have a feeling that we you will not
>> > start the discussion right now,
>> > the idea of new API may be lost :(  So, I'd suggest to try one more time ;)
>>
>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
>> method is now declared in GraphicsEnvironment, with the addition of
>> throwing a HeadlessException in the headless case. Also, in fontpath.c,
>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
>> call it on X11GraphicsEnvironment only. In my original patch I tried to
>> be more portable by calling
>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
>> this resulted in an initialization loop (this code is very sensible to
>> this kind of problem). I left that out for now, because fontpath.c is
>> X11 specific anyway, and a real solution will come soon in the form of a
>> huge FontManager patch :-)
>>
>> What do you think? Can we add this API to GE?
>>
>> /Roman
>>
> --
> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
> aicas Allerton Interworks Computer Automated Systems GmbH
> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
> http://www.aicas.com   * Tel: +49-721-663 968-48
> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
> Gesch?ftsf?hrer: Dr. James J. Hunt
>

From Artem.Ananiev at Sun.COM  Tue Sep  9 04:55:57 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Tue, 09 Sep 2008 15:55:57 +0400
Subject: <AWT Dev> EventQueue changes
Message-ID: <48C6644D.2020504@sun.com>

Hi, AWT team,

there are several issues related to EventQueue class with a long 
history. The number of user votes constantly grows, so I think it would 
be fine if we can get them fixed in some nearest future.

The list of bugs include (but not limited to):

6424157: java.awt.EventQueue push/pop might cause threading issues

6542185: Threading issues with java.awt.EventQueue.push/pop
(closed as not a defect, but some of described problems still exist)

4913324: Deadlock when using two event queues.

4516924: Request public access to pumpEvents(Conditional) type 
functionality.

6727884: Some Uncaught Exceptions are no longer getting sent to the 
Uncaught Exception Handlers

Some of the described problems don't look related to each other, however 
after a closer look I found they really do. That's why I listed them 
here altogether, and would like to discuss some possible improvements:

1. Synchronization changes. Most of the problems with push/pop are 
caused by imperfect synchronization in EventQueue. Currently, all the 
actions like postEvent() or getNextEvent() are transferred back and 
forth in the stack of event queues, and each queue is accessed in its 
'synchronized' block. Instead, a single lock looks more correct here.

2. EventDispatchThread lifecycle. It is a known fact, that event 
dispatch thread may die for some reason (for example, because of 
unhandled exception). When a new event comes, new EDT is created. 
Another case when EDT is switched is push/pop methods: when a new EQ is 
pushed/popped, a new EDT is created.

I'm sure these changes of current dispatch thread is not what developers 
expect. Swing is considered as single-threaded toolkit, but it is really 
not...

3. Controllable event pump. This is what developers have been requesting 
for at least 8 years. With the current API this task cannot be solved, 
and all the external libs like Foxtrot are really just hacks and depend 
on JDK internals.

 From technical point of view, controllable event pump is just a several 
lines of code changes: we only need to make public the code which is 
used for modality event pumps.

----

I have a prototype fix with all the three items implemented. Still, it 
would be fine to hear what all AWT developers think about proposed changes.

Thanks,

Artem


From Andrei.Dmitriev at Sun.COM  Tue Sep  9 09:14:56 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Tue, 09 Sep 2008 20:14:56 +0400
Subject: <AWT Dev> Ideas about improved architecture of
 the	generic	Swing peers
In-Reply-To: <48C46D40.3060507@sun.com>
References: <1218794992.6783.44.camel@moonlight>
	<1220353774.8444.16.camel@moonlight>
	<271e55d20809052116he4e24e9t659e3f0d67121096@mail.gmail.com>
	<1220691708.6571.19.camel@moonlight> <48C46D40.3060507@sun.com>
Message-ID: <48C6A100.5050504@sun.com>

Roman,

for convenience you first could try getting access to those tests. That 
allows you to get more involved into technical details of (hm... 
potential) issues if they are :) I'm also ready to make JCK trials and 
supply with reports.

BTW, opened regression tests are also of a high value. Here is the 
harness for them: [1].

Thanks,
   Andrei

[1] http://openjdk.java.net/jtreg/

Dalibor Topic wrote:
> Roman Kennke wrote:
>> Surely I am. Regarding the JCK - yeah funny. Give me access to it, and
>> I'll do it :-)
>>   
> http://openjdk.java.net/groups/conformance/JckAccess/index.html 
> 
> cheers,
> dalibor topic
> 


From son.two at gmail.com  Tue Sep  9 10:57:22 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Tue, 9 Sep 2008 21:57:22 +0400
Subject: <AWT Dev> EventQueue changes
In-Reply-To: <48C6644D.2020504@sun.com>
References: <48C6644D.2020504@sun.com>
Message-ID: <271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>

On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
> Hi, AWT team,
>
> there are several issues related to EventQueue class with a long history.
> The number of user votes constantly grows, so I think it would be fine if we
> can get them fixed in some nearest future.
>
> The list of bugs include (but not limited to):
>
> 6424157: java.awt.EventQueue push/pop might cause threading issues
>
> 6542185: Threading issues with java.awt.EventQueue.push/pop
> (closed as not a defect, but some of described problems still exist)
>
> 4913324: Deadlock when using two event queues.
>
> 4516924: Request public access to pumpEvents(Conditional) type
> functionality.
>
> 6727884: Some Uncaught Exceptions are no longer getting sent to the Uncaught
> Exception Handlers
>
> Some of the described problems don't look related to each other, however
> after a closer look I found they really do. That's why I listed them here
> altogether, and would like to discuss some possible improvements:
>
> 1. Synchronization changes. Most of the problems with push/pop are caused by
> imperfect synchronization in EventQueue. Currently, all the actions like
> postEvent() or getNextEvent() are transferred back and forth in the stack of
> event queues, and each queue is accessed in its 'synchronized' block.
> Instead, a single lock looks more correct here.
>
> 2. EventDispatchThread lifecycle. It is a known fact, that event dispatch
> thread may die for some reason (for example, because of unhandled
> exception). When a new event comes, new EDT is created. Another case when
> EDT is switched is push/pop methods: when a new EQ is pushed/popped, a new
> EDT is created.
>
> I'm sure these changes of current dispatch thread is not what developers
> expect. Swing is considered as single-threaded toolkit, but it is really
> not...
>
> 3. Controllable event pump. This is what developers have been requesting for
> at least 8 years. With the current API this task cannot be solved, and all
> the external libs like Foxtrot are really just hacks and depend on JDK
> internals.
>
> From technical point of view, controllable event pump is just a several
> lines of code changes: we only need to make public the code which is used
> for modality event pumps.
>
> ----
>
> I have a prototype fix with all the three items implemented. Still, it would
> be fine to hear what all AWT developers think about proposed changes.

I see list of problems, but do not see list of proposed changes :(
Did I miss something?

With best regards, Oleg.


From Dmitri.Trembovetski at Sun.COM  Tue Sep  9 11:16:20 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Tue, 09 Sep 2008 11:16:20 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
Message-ID: <48C6BD74.1070705@Sun.COM>


   Hi Oleg, Roman,

   I myself don't think that this API belongs in public.

   It is used by the platform implementation for doing
   specific tasks and is of questionable value for
   general public. Also, it is too platform-specific
   and typically we refrain from adding platform-specific
   APIs to the Java platform.

   How do you think the developers would use it anyway?

   Those developers who know what a "remote display" is -
   which I assume is a minority since most developers never
   leave the Windows world - can detect it themselves if
   they really needed something like this - it's not a
   big deal, just read the DISPLAY env. variable and
   figure it out.

   In the specific case of SwingUtilities I believe they
   only use it to determine whether to enable AA text
   or not. So perhaps that's something that should
   be exposed instead.

   And talking about implementation - if we were to add
   something to this effect to the platform, we'd need
   to go all the way and possibly detect remote desktop
   session on Windows as well. And what about VNC sessions?
   In our current implementation we only care about
   "remote X display" situation, but the developers who
   see this public API could assume otherwise.

   I suggest to fall back to the original Roman's
   patch which just exposed this method in
   SunGraphicsEnvironment.

   Thanks,
     Dmitri

Oleg Sukhodolsky wrote:
> I'd vote for this API, but it is 2D team who should make the decision.
> 
> Oleg.
> 
> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke <roman.kennke at aicas.com> wrote:
>> Bah, forgot the actual patch. Here it comes now!
>>
>> /Roman
>>
>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
>>> Hi Oleg and lists,
>>>
>>>>>> I'm not the person who is supposed to review this changes from
>>>>>> technical point of view,
>>>>>> but I have one concern about idea of the fix.  It adds one more place
>>>>>> where Swing uses sun-specific API.
>>>>> No. It takes advantage of Sun internal API, but it does not depend on
>>>>> it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
>>>>> else { useReasonableDefault(); } ).
>>>> it uses Sun-specific class, so this code can not be compiled by JDK
>>>> from another vendor :(
>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
>>> (Ok, the Caciocavallo project will certainly help alot, but we are still
>>> very far away from such a portable Swing).
>>>
>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even
>>>>>> before your fix uses code which is specific
>>>>>> for Sun's implementation, and you will be right.  But this doesn't
>>>>>> mean that we should leave with this.
>>>>>> IMHO, if we change such code we should remove dependency between Swing
>>>>>> and Sun-specific code,
>>>>>> i.e. we should add public API.
>>>>> I completely agree. That, of course, would be the best solution. But in
>>>>> the past it has been communicated several times to me that I can't just
>>>>> send in patches to public API and hope that it will be accepted easily.
>>>>> I propose to get in this patch if possible first, then start a
>>>>> discussion about adding public API.
>>>> I understand your point, but I have a feeling that we you will not
>>>> start the discussion right now,
>>>> the idea of new API may be lost :(  So, I'd suggest to try one more time ;)
>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
>>> method is now declared in GraphicsEnvironment, with the addition of
>>> throwing a HeadlessException in the headless case. Also, in fontpath.c,
>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
>>> call it on X11GraphicsEnvironment only. In my original patch I tried to
>>> be more portable by calling
>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
>>> this resulted in an initialization loop (this code is very sensible to
>>> this kind of problem). I left that out for now, because fontpath.c is
>>> X11 specific anyway, and a real solution will come soon in the form of a
>>> huge FontManager patch :-)
>>>
>>> What do you think? Can we add this API to GE?
>>>
>>> /Roman
>>>
>> --
>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
>> aicas Allerton Interworks Computer Automated Systems GmbH
>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
>> http://www.aicas.com   * Tel: +49-721-663 968-48
>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
>> Gesch?ftsf?hrer: Dr. James J. Hunt
>>


From martinrb at google.com  Tue Sep  9 13:09:13 2008
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 9 Sep 2008 13:09:13 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <48C6BD74.1070705@Sun.COM>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
Message-ID: <1ccfd1c10809091309q60417565y3303817c4f3bff63@mail.gmail.com>

It's very hard to get these kinds of UI issues right.

I once tried to configure my xemacs to have less eye candy
when talking to a "slow" X server by actually timing
some operation that requires a round trip.

Note that a method like isLocalDisplay would have the
wrong semantics for me, because I mostly cared about
whether I was bottlenecked by VPN.

This did help me get my work done, but this kind of
timing-dependent behavior is disconcerting to the user,
especially if they feel they have no control or do not
understand the behavior.  It "looks like a bug".

Will FAQs and bug reports appear
Q: Sometimes my java app starts up with funky fonts.
A: Try restarting a few times in a loop, or try setting this magic
system property:

Martin

On Tue, Sep 9, 2008 at 11:16, Dmitri Trembovetski
<Dmitri.Trembovetski at sun.com> wrote:
>
>  Hi Oleg, Roman,
>
>  I myself don't think that this API belongs in public.
>
>  It is used by the platform implementation for doing
>  specific tasks and is of questionable value for
>  general public. Also, it is too platform-specific
>  and typically we refrain from adding platform-specific
>  APIs to the Java platform.
>
>  How do you think the developers would use it anyway?
>
>  Those developers who know what a "remote display" is -
>  which I assume is a minority since most developers never
>  leave the Windows world - can detect it themselves if
>  they really needed something like this - it's not a
>  big deal, just read the DISPLAY env. variable and
>  figure it out.
>
>  In the specific case of SwingUtilities I believe they
>  only use it to determine whether to enable AA text
>  or not. So perhaps that's something that should
>  be exposed instead.
>
>  And talking about implementation - if we were to add
>  something to this effect to the platform, we'd need
>  to go all the way and possibly detect remote desktop
>  session on Windows as well. And what about VNC sessions?
>  In our current implementation we only care about
>  "remote X display" situation, but the developers who
>  see this public API could assume otherwise.
>
>  I suggest to fall back to the original Roman's
>  patch which just exposed this method in
>  SunGraphicsEnvironment.
>
>  Thanks,
>    Dmitri
>
> Oleg Sukhodolsky wrote:
>>
>> I'd vote for this API, but it is 2D team who should make the decision.
>>
>> Oleg.
>>
>> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke <roman.kennke at aicas.com>
>> wrote:
>>>
>>> Bah, forgot the actual patch. Here it comes now!
>>>
>>> /Roman
>>>
>>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
>>>>
>>>> Hi Oleg and lists,
>>>>
>>>>>>> I'm not the person who is supposed to review this changes from
>>>>>>> technical point of view,
>>>>>>> but I have one concern about idea of the fix.  It adds one more place
>>>>>>> where Swing uses sun-specific API.
>>>>>>
>>>>>> No. It takes advantage of Sun internal API, but it does not depend on
>>>>>> it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
>>>>>> else { useReasonableDefault(); } ).
>>>>>
>>>>> it uses Sun-specific class, so this code can not be compiled by JDK
>>>>> from another vendor :(
>>>>
>>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
>>>> (Ok, the Caciocavallo project will certainly help alot, but we are still
>>>> very far away from such a portable Swing).
>>>>
>>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even
>>>>>>> before your fix uses code which is specific
>>>>>>> for Sun's implementation, and you will be right.  But this doesn't
>>>>>>> mean that we should leave with this.
>>>>>>> IMHO, if we change such code we should remove dependency between
>>>>>>> Swing
>>>>>>> and Sun-specific code,
>>>>>>> i.e. we should add public API.
>>>>>>
>>>>>> I completely agree. That, of course, would be the best solution. But
>>>>>> in
>>>>>> the past it has been communicated several times to me that I can't
>>>>>> just
>>>>>> send in patches to public API and hope that it will be accepted
>>>>>> easily.
>>>>>> I propose to get in this patch if possible first, then start a
>>>>>> discussion about adding public API.
>>>>>
>>>>> I understand your point, but I have a feeling that we you will not
>>>>> start the discussion right now,
>>>>> the idea of new API may be lost :(  So, I'd suggest to try one more
>>>>> time ;)
>>>>
>>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
>>>> method is now declared in GraphicsEnvironment, with the addition of
>>>> throwing a HeadlessException in the headless case. Also, in fontpath.c,
>>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
>>>> call it on X11GraphicsEnvironment only. In my original patch I tried to
>>>> be more portable by calling
>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
>>>> this resulted in an initialization loop (this code is very sensible to
>>>> this kind of problem). I left that out for now, because fontpath.c is
>>>> X11 specific anyway, and a real solution will come soon in the form of a
>>>> huge FontManager patch :-)
>>>>
>>>> What do you think? Can we add this API to GE?
>>>>
>>>> /Roman
>>>>
>>> --
>>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
>>> aicas Allerton Interworks Computer Automated Systems GmbH
>>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
>>> http://www.aicas.com   * Tel: +49-721-663 968-48
>>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
>>> Gesch?ftsf?hrer: Dr. James J. Hunt
>>>
>


From Dmitri.Trembovetski at Sun.COM  Tue Sep  9 15:12:03 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Tue, 09 Sep 2008 15:12:03 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <1ccfd1c10809091309q60417565y3303817c4f3bff63@mail.gmail.com>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<1ccfd1c10809091309q60417565y3303817c4f3bff63@mail.gmail.com>
Message-ID: <48C6F4B3.50506@Sun.COM>



Martin Buchholz wrote:
> It's very hard to get these kinds of UI issues right.
> 
> I once tried to configure my xemacs to have less eye candy
> when talking to a "slow" X server by actually timing
> some operation that requires a round trip.
> 
> Note that a method like isLocalDisplay would have the
> wrong semantics for me, because I mostly cared about
> whether I was bottlenecked by VPN.
> 
> This did help me get my work done, but this kind of
> timing-dependent behavior is disconcerting to the user,
> especially if they feel they have no control or do not
> understand the behavior.  It "looks like a bug".
> 
> Will FAQs and bug reports appear
> Q: Sometimes my java app starts up with funky fonts.
> A: Try restarting a few times in a loop, or try setting this magic
> system property:

   http://java.sun.com/javase/6/webnotes/trouble/TSG-Desktop/html/gdlvo.html#gdlwn

   Thanks,
     Dmitri


> 
> Martin
> 
> On Tue, Sep 9, 2008 at 11:16, Dmitri Trembovetski
> <Dmitri.Trembovetski at sun.com> wrote:
>>  Hi Oleg, Roman,
>>
>>  I myself don't think that this API belongs in public.
>>
>>  It is used by the platform implementation for doing
>>  specific tasks and is of questionable value for
>>  general public. Also, it is too platform-specific
>>  and typically we refrain from adding platform-specific
>>  APIs to the Java platform.
>>
>>  How do you think the developers would use it anyway?
>>
>>  Those developers who know what a "remote display" is -
>>  which I assume is a minority since most developers never
>>  leave the Windows world - can detect it themselves if
>>  they really needed something like this - it's not a
>>  big deal, just read the DISPLAY env. variable and
>>  figure it out.
>>
>>  In the specific case of SwingUtilities I believe they
>>  only use it to determine whether to enable AA text
>>  or not. So perhaps that's something that should
>>  be exposed instead.
>>
>>  And talking about implementation - if we were to add
>>  something to this effect to the platform, we'd need
>>  to go all the way and possibly detect remote desktop
>>  session on Windows as well. And what about VNC sessions?
>>  In our current implementation we only care about
>>  "remote X display" situation, but the developers who
>>  see this public API could assume otherwise.
>>
>>  I suggest to fall back to the original Roman's
>>  patch which just exposed this method in
>>  SunGraphicsEnvironment.
>>
>>  Thanks,
>>    Dmitri
>>
>> Oleg Sukhodolsky wrote:
>>> I'd vote for this API, but it is 2D team who should make the decision.
>>>
>>> Oleg.
>>>
>>> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke <roman.kennke at aicas.com>
>>> wrote:
>>>> Bah, forgot the actual patch. Here it comes now!
>>>>
>>>> /Roman
>>>>
>>>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
>>>>> Hi Oleg and lists,
>>>>>
>>>>>>>> I'm not the person who is supposed to review this changes from
>>>>>>>> technical point of view,
>>>>>>>> but I have one concern about idea of the fix.  It adds one more place
>>>>>>>> where Swing uses sun-specific API.
>>>>>>> No. It takes advantage of Sun internal API, but it does not depend on
>>>>>>> it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
>>>>>>> else { useReasonableDefault(); } ).
>>>>>> it uses Sun-specific class, so this code can not be compiled by JDK
>>>>>> from another vendor :(
>>>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
>>>>> (Ok, the Caciocavallo project will certainly help alot, but we are still
>>>>> very far away from such a portable Swing).
>>>>>
>>>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even
>>>>>>>> before your fix uses code which is specific
>>>>>>>> for Sun's implementation, and you will be right.  But this doesn't
>>>>>>>> mean that we should leave with this.
>>>>>>>> IMHO, if we change such code we should remove dependency between
>>>>>>>> Swing
>>>>>>>> and Sun-specific code,
>>>>>>>> i.e. we should add public API.
>>>>>>> I completely agree. That, of course, would be the best solution. But
>>>>>>> in
>>>>>>> the past it has been communicated several times to me that I can't
>>>>>>> just
>>>>>>> send in patches to public API and hope that it will be accepted
>>>>>>> easily.
>>>>>>> I propose to get in this patch if possible first, then start a
>>>>>>> discussion about adding public API.
>>>>>> I understand your point, but I have a feeling that we you will not
>>>>>> start the discussion right now,
>>>>>> the idea of new API may be lost :(  So, I'd suggest to try one more
>>>>>> time ;)
>>>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
>>>>> method is now declared in GraphicsEnvironment, with the addition of
>>>>> throwing a HeadlessException in the headless case. Also, in fontpath.c,
>>>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
>>>>> call it on X11GraphicsEnvironment only. In my original patch I tried to
>>>>> be more portable by calling
>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
>>>>> this resulted in an initialization loop (this code is very sensible to
>>>>> this kind of problem). I left that out for now, because fontpath.c is
>>>>> X11 specific anyway, and a real solution will come soon in the form of a
>>>>> huge FontManager patch :-)
>>>>>
>>>>> What do you think? Can we add this API to GE?
>>>>>
>>>>> /Roman
>>>>>
>>>> --
>>>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
>>>> aicas Allerton Interworks Computer Automated Systems GmbH
>>>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
>>>> http://www.aicas.com   * Tel: +49-721-663 968-48
>>>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
>>>> Gesch?ftsf?hrer: Dr. James J. Hunt
>>>>


From son.two at gmail.com  Tue Sep  9 20:40:29 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Wed, 10 Sep 2008 07:40:29 +0400
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <48C6BD74.1070705@Sun.COM>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
Message-ID: <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>

Hi Dmitri,

I understand than you do not want to add questionable code in 2D,
but I do not like the idea to make this by adding questionable code
to Swing. So before falliwing back to hack I'd suggest to thinkabout
possible API, otherwise we have a good chance to keep this hack
in Swing code forever :(

Oleg.

On Tue, Sep 9, 2008 at 10:16 PM, Dmitri Trembovetski
<Dmitri.Trembovetski at sun.com> wrote:
>
>  Hi Oleg, Roman,
>
>  I myself don't think that this API belongs in public.
>
>  It is used by the platform implementation for doing
>  specific tasks and is of questionable value for
>  general public. Also, it is too platform-specific
>  and typically we refrain from adding platform-specific
>  APIs to the Java platform.
>
>  How do you think the developers would use it anyway?
>
>  Those developers who know what a "remote display" is -
>  which I assume is a minority since most developers never
>  leave the Windows world - can detect it themselves if
>  they really needed something like this - it's not a
>  big deal, just read the DISPLAY env. variable and
>  figure it out.
>
>  In the specific case of SwingUtilities I believe they
>  only use it to determine whether to enable AA text
>  or not. So perhaps that's something that should
>  be exposed instead.
>
>  And talking about implementation - if we were to add
>  something to this effect to the platform, we'd need
>  to go all the way and possibly detect remote desktop
>  session on Windows as well. And what about VNC sessions?
>  In our current implementation we only care about
>  "remote X display" situation, but the developers who
>  see this public API could assume otherwise.
>
>  I suggest to fall back to the original Roman's
>  patch which just exposed this method in
>  SunGraphicsEnvironment.
>
>  Thanks,
>    Dmitri
>
> Oleg Sukhodolsky wrote:
>>
>> I'd vote for this API, but it is 2D team who should make the decision.
>>
>> Oleg.
>>
>> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke <roman.kennke at aicas.com>
>> wrote:
>>>
>>> Bah, forgot the actual patch. Here it comes now!
>>>
>>> /Roman
>>>
>>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
>>>>
>>>> Hi Oleg and lists,
>>>>
>>>>>>> I'm not the person who is supposed to review this changes from
>>>>>>> technical point of view,
>>>>>>> but I have one concern about idea of the fix.  It adds one more place
>>>>>>> where Swing uses sun-specific API.
>>>>>>
>>>>>> No. It takes advantage of Sun internal API, but it does not depend on
>>>>>> it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
>>>>>> else { useReasonableDefault(); } ).
>>>>>
>>>>> it uses Sun-specific class, so this code can not be compiled by JDK
>>>>> from another vendor :(
>>>>
>>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
>>>> (Ok, the Caciocavallo project will certainly help alot, but we are still
>>>> very far away from such a portable Swing).
>>>>
>>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even
>>>>>>> before your fix uses code which is specific
>>>>>>> for Sun's implementation, and you will be right.  But this doesn't
>>>>>>> mean that we should leave with this.
>>>>>>> IMHO, if we change such code we should remove dependency between
>>>>>>> Swing
>>>>>>> and Sun-specific code,
>>>>>>> i.e. we should add public API.
>>>>>>
>>>>>> I completely agree. That, of course, would be the best solution. But
>>>>>> in
>>>>>> the past it has been communicated several times to me that I can't
>>>>>> just
>>>>>> send in patches to public API and hope that it will be accepted
>>>>>> easily.
>>>>>> I propose to get in this patch if possible first, then start a
>>>>>> discussion about adding public API.
>>>>>
>>>>> I understand your point, but I have a feeling that we you will not
>>>>> start the discussion right now,
>>>>> the idea of new API may be lost :(  So, I'd suggest to try one more
>>>>> time ;)
>>>>
>>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
>>>> method is now declared in GraphicsEnvironment, with the addition of
>>>> throwing a HeadlessException in the headless case. Also, in fontpath.c,
>>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
>>>> call it on X11GraphicsEnvironment only. In my original patch I tried to
>>>> be more portable by calling
>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
>>>> this resulted in an initialization loop (this code is very sensible to
>>>> this kind of problem). I left that out for now, because fontpath.c is
>>>> X11 specific anyway, and a real solution will come soon in the form of a
>>>> huge FontManager patch :-)
>>>>
>>>> What do you think? Can we add this API to GE?
>>>>
>>>> /Roman
>>>>
>>> --
>>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
>>> aicas Allerton Interworks Computer Automated Systems GmbH
>>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
>>> http://www.aicas.com   * Tel: +49-721-663 968-48
>>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
>>> Gesch?ftsf?hrer: Dr. James J. Hunt
>>>
>

From dmitry.cherepanov at sun.com  Wed Sep 10 04:06:59 2008
From: dmitry.cherepanov at sun.com (dmitry.cherepanov at sun.com)
Date: Wed, 10 Sep 2008 11:06:59 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6743433: IM candidate window is not
	shown until	window is deactivated and reactivated again
Message-ID: <20080910110711.6199BD693@hg.openjdk.java.net>

Changeset: fd13d8cce933
Author:    dcherepanov
Date:      2008-09-10 15:02 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/fd13d8cce933

6743433: IM candidate window is not shown until window is deactivated and reactivated again
Summary: OpenCandidateWindow procedure should directly call ::DefWindowProc
Reviewed-by: art

! src/windows/native/sun/windows/awt_Component.cpp



From Dmitri.Trembovetski at Sun.COM  Wed Sep 10 09:19:51 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Wed, 10 Sep 2008 09:19:51 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
Message-ID: <48C7F3A7.6010803@Sun.COM>



   Hi Oleg,

Oleg Sukhodolsky wrote:
> I understand than you do not want to add questionable code in 2D,
> but I do not like the idea to make this by adding questionable code
> to Swing. So before falliwing back to hack I'd suggest to thinkabout

   I'm not sure what you mean by "adding questionable code
   to Swing" - the code was already there. Now instead of
   directly calling sun internal API it will call a better
   defined internal API.

> possible API, otherwise we have a good chance to keep this hack
> in Swing code forever :(

   Swing is part of the platform, and will always have to
   use some APIs in the implementation which are not available
   to external developers.

   I don't see a problem with that. In this particular case
   I really don't see any benefit in exposing this very
   platform-specific API to the developers.

   Thanks,
     Dmitri


> 
> Oleg.
> 
> On Tue, Sep 9, 2008 at 10:16 PM, Dmitri Trembovetski
> <Dmitri.Trembovetski at sun.com> wrote:
>>  Hi Oleg, Roman,
>>
>>  I myself don't think that this API belongs in public.
>>
>>  It is used by the platform implementation for doing
>>  specific tasks and is of questionable value for
>>  general public. Also, it is too platform-specific
>>  and typically we refrain from adding platform-specific
>>  APIs to the Java platform.
>>
>>  How do you think the developers would use it anyway?
>>
>>  Those developers who know what a "remote display" is -
>>  which I assume is a minority since most developers never
>>  leave the Windows world - can detect it themselves if
>>  they really needed something like this - it's not a
>>  big deal, just read the DISPLAY env. variable and
>>  figure it out.
>>
>>  In the specific case of SwingUtilities I believe they
>>  only use it to determine whether to enable AA text
>>  or not. So perhaps that's something that should
>>  be exposed instead.
>>
>>  And talking about implementation - if we were to add
>>  something to this effect to the platform, we'd need
>>  to go all the way and possibly detect remote desktop
>>  session on Windows as well. And what about VNC sessions?
>>  In our current implementation we only care about
>>  "remote X display" situation, but the developers who
>>  see this public API could assume otherwise.
>>
>>  I suggest to fall back to the original Roman's
>>  patch which just exposed this method in
>>  SunGraphicsEnvironment.
>>
>>  Thanks,
>>    Dmitri
>>
>> Oleg Sukhodolsky wrote:
>>> I'd vote for this API, but it is 2D team who should make the decision.
>>>
>>> Oleg.
>>>
>>> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke <roman.kennke at aicas.com>
>>> wrote:
>>>> Bah, forgot the actual patch. Here it comes now!
>>>>
>>>> /Roman
>>>>
>>>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
>>>>> Hi Oleg and lists,
>>>>>
>>>>>>>> I'm not the person who is supposed to review this changes from
>>>>>>>> technical point of view,
>>>>>>>> but I have one concern about idea of the fix.  It adds one more place
>>>>>>>> where Swing uses sun-specific API.
>>>>>>> No. It takes advantage of Sun internal API, but it does not depend on
>>>>>>> it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
>>>>>>> else { useReasonableDefault(); } ).
>>>>>> it uses Sun-specific class, so this code can not be compiled by JDK
>>>>>> from another vendor :(
>>>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
>>>>> (Ok, the Caciocavallo project will certainly help alot, but we are still
>>>>> very far away from such a portable Swing).
>>>>>
>>>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even
>>>>>>>> before your fix uses code which is specific
>>>>>>>> for Sun's implementation, and you will be right.  But this doesn't
>>>>>>>> mean that we should leave with this.
>>>>>>>> IMHO, if we change such code we should remove dependency between
>>>>>>>> Swing
>>>>>>>> and Sun-specific code,
>>>>>>>> i.e. we should add public API.
>>>>>>> I completely agree. That, of course, would be the best solution. But
>>>>>>> in
>>>>>>> the past it has been communicated several times to me that I can't
>>>>>>> just
>>>>>>> send in patches to public API and hope that it will be accepted
>>>>>>> easily.
>>>>>>> I propose to get in this patch if possible first, then start a
>>>>>>> discussion about adding public API.
>>>>>> I understand your point, but I have a feeling that we you will not
>>>>>> start the discussion right now,
>>>>>> the idea of new API may be lost :(  So, I'd suggest to try one more
>>>>>> time ;)
>>>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
>>>>> method is now declared in GraphicsEnvironment, with the addition of
>>>>> throwing a HeadlessException in the headless case. Also, in fontpath.c,
>>>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
>>>>> call it on X11GraphicsEnvironment only. In my original patch I tried to
>>>>> be more portable by calling
>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
>>>>> this resulted in an initialization loop (this code is very sensible to
>>>>> this kind of problem). I left that out for now, because fontpath.c is
>>>>> X11 specific anyway, and a real solution will come soon in the form of a
>>>>> huge FontManager patch :-)
>>>>>
>>>>> What do you think? Can we add this API to GE?
>>>>>
>>>>> /Roman
>>>>>
>>>> --
>>>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
>>>> aicas Allerton Interworks Computer Automated Systems GmbH
>>>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
>>>> http://www.aicas.com   * Tel: +49-721-663 968-48
>>>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
>>>> Gesch?ftsf?hrer: Dr. James J. Hunt
>>>>


From roman.kennke at aicas.com  Wed Sep 10 12:04:31 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Wed, 10 Sep 2008 21:04:31 +0200
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <48C7F3A7.6010803@Sun.COM>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM>
Message-ID: <1221073471.6592.27.camel@moonlight>

Hi Dmitri and Oleg,

> > I understand than you do not want to add questionable code in 2D,
> > but I do not like the idea to make this by adding questionable code
> > to Swing. So before falliwing back to hack I'd suggest to thinkabout
> 
>    I'm not sure what you mean by "adding questionable code
>    to Swing" - the code was already there. Now instead of
>    directly calling sun internal API it will call a better
>    defined internal API.

Yeah, I agree.

> > possible API, otherwise we have a good chance to keep this hack
> > in Swing code forever :(
> 
>    Swing is part of the platform, and will always have to
>    use some APIs in the implementation which are not available
>    to external developers.
> 
>    I don't see a problem with that. In this particular case
>    I really don't see any benefit in exposing this very
>    platform-specific API to the developers.

Yeah. It looks like most (all?) Sun-specific code is in SwingUtilities2
anyway, so this is more or less the porting interface for Swing for
people who really need to port OpenJDK Swing to a different JDK. If it
is a goal to support that, it might make sense to find all remaining
uses of Sun-specific code in Swing and refactor that to also use
SwingUtilities2. Or even better, create a separate interface and factory
for implementations of that interface that would be provided by the
developer who ports Swing. But that seems a little over the top right
now. I also suggest to get the original patch through.

/Roman
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From roman at kennke.org  Wed Sep 10 14:54:34 2008
From: roman at kennke.org (Roman Kennke)
Date: Wed, 10 Sep 2008 23:54:34 +0200
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <1221073471.6592.27.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM>  <1221073471.6592.27.camel@moonlight>
Message-ID: <1221083674.6592.35.camel@moonlight>

I need to repost my original patch for two reasons: 1. it doesn't apply
cleanly (only with some fuzz), 2. it also has this init-loop problem.
Find attached the correct version. I'd be happy to see it committed
ASAP.

/Roman

Am Mittwoch, den 10.09.2008, 21:04 +0200 schrieb Roman Kennke:
> Hi Dmitri and Oleg,
> 
> > > I understand than you do not want to add questionable code in 2D,
> > > but I do not like the idea to make this by adding questionable code
> > > to Swing. So before falliwing back to hack I'd suggest to thinkabout
> > 
> >    I'm not sure what you mean by "adding questionable code
> >    to Swing" - the code was already there. Now instead of
> >    directly calling sun internal API it will call a better
> >    defined internal API.
> 
> Yeah, I agree.
> 
> > > possible API, otherwise we have a good chance to keep this hack
> > > in Swing code forever :(
> > 
> >    Swing is part of the platform, and will always have to
> >    use some APIs in the implementation which are not available
> >    to external developers.
> > 
> >    I don't see a problem with that. In this particular case
> >    I really don't see any benefit in exposing this very
> >    platform-specific API to the developers.
> 
> Yeah. It looks like most (all?) Sun-specific code is in SwingUtilities2
> anyway, so this is more or less the porting interface for Swing for
> people who really need to port OpenJDK Swing to a different JDK. If it
> is a goal to support that, it might make sense to find all remaining
> uses of Sun-specific code in Swing and refactor that to also use
> SwingUtilities2. Or even better, create a separate interface and factory
> for implementations of that interface that would be provided by the
> developer who ports Swing. But that seems a little over the top right
> now. I also suggest to get the original patch through.
> 
> /Roman
-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 4368 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080910/be736a0a/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080910/be736a0a/attachment-0001.bin 

From Dmitri.Trembovetski at Sun.COM  Wed Sep 10 15:45:04 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Wed, 10 Sep 2008 15:45:04 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <1221083674.6592.35.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight>
	<1221083674.6592.35.camel@moonlight>
Message-ID: <48C84DF0.1090506@Sun.COM>



Roman Kennke wrote:
> I need to repost my original patch for two reasons: 1. it doesn't apply
> cleanly (only with some fuzz), 2. it also has this init-loop problem.
> Find attached the correct version. I'd be happy to see it committed
> ASAP.

   I have a question about the fix:
--- a/src/solaris/native/sun/awt/fontpath.c	Thu Aug 07 09:42:31 2008 -0700
+++ b/src/solaris/native/sun/awt/fontpath.c	Wed Sep 10 23:52:15 2008 +0200
@@ -156,7 +156,7 @@

      isLocal = JNU_CallStaticMethodByName(env, NULL,
                                           "sun/awt/X11GraphicsEnvironment",
-                                         "isDisplayLocal",
+                                         "_isDisplayLocal",
                                           "()Z").z;

   Didn't you change isDisplayLocal to be non-static
   in X11GraphicsEnvironment? If so how does this actually
   work since you still call CallStaticMethodByName?

   Thanks,
     Dmitri


> 
> /Roman
> 
> Am Mittwoch, den 10.09.2008, 21:04 +0200 schrieb Roman Kennke:
>> Hi Dmitri and Oleg,
>>
>>>> I understand than you do not want to add questionable code in 2D,
>>>> but I do not like the idea to make this by adding questionable code
>>>> to Swing. So before falliwing back to hack I'd suggest to thinkabout
>>>    I'm not sure what you mean by "adding questionable code
>>>    to Swing" - the code was already there. Now instead of
>>>    directly calling sun internal API it will call a better
>>>    defined internal API.
>> Yeah, I agree.
>>
>>>> possible API, otherwise we have a good chance to keep this hack
>>>> in Swing code forever :(
>>>    Swing is part of the platform, and will always have to
>>>    use some APIs in the implementation which are not available
>>>    to external developers.
>>>
>>>    I don't see a problem with that. In this particular case
>>>    I really don't see any benefit in exposing this very
>>>    platform-specific API to the developers.
>> Yeah. It looks like most (all?) Sun-specific code is in SwingUtilities2
>> anyway, so this is more or less the porting interface for Swing for
>> people who really need to port OpenJDK Swing to a different JDK. If it
>> is a goal to support that, it might make sense to find all remaining
>> uses of Sun-specific code in Swing and refactor that to also use
>> SwingUtilities2. Or even better, create a separate interface and factory
>> for implementations of that interface that would be provided by the
>> developer who ports Swing. But that seems a little over the top right
>> now. I also suggest to get the original patch through.
>>
>> /Roman


From roman at kennke.org  Wed Sep 10 16:45:08 2008
From: roman at kennke.org (Roman Kennke)
Date: Thu, 11 Sep 2008 01:45:08 +0200
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <48C84DF0.1090506@Sun.COM>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight>
	<1221083674.6592.35.camel@moonlight>  <48C84DF0.1090506@Sun.COM>
Message-ID: <1221090308.6500.3.camel@moonlight>

Hi Dmitri,

> > I need to repost my original patch for two reasons: 1. it doesn't apply
> > cleanly (only with some fuzz), 2. it also has this init-loop problem.
> > Find attached the correct version. I'd be happy to see it committed
> > ASAP.
> 
>    I have a question about the fix:
> --- a/src/solaris/native/sun/awt/fontpath.c	Thu Aug 07 09:42:31 2008 -0700
> +++ b/src/solaris/native/sun/awt/fontpath.c	Wed Sep 10 23:52:15 2008 +0200
> @@ -156,7 +156,7 @@
> 
>       isLocal = JNU_CallStaticMethodByName(env, NULL,
>                                            "sun/awt/X11GraphicsEnvironment",
> -                                         "isDisplayLocal",
> +                                         "_isDisplayLocal",
>                                            "()Z").z;
> 
>    Didn't you change isDisplayLocal to be non-static
>    in X11GraphicsEnvironment? If so how does this actually
>    work since you still call CallStaticMethodByName?

The _isDisplayLocal() is a static method in X11GraphicsEnvironment,
which is called by isDisplayLocal() after entering the AWT monitor. The
above code is already executed inside the AWT lock, so this is not a
problem. And it is only called from the X11 backend anyway. Calling
isDisplayLocal() results in a loop though, because it tries to load the
X11GraphicsEnvironment class, which in turn causes the class initializer
of SGE to be executed, which calls back into the code above, ad
infinitum. This is why we call the static _isDisplayLocal() instead. The
real solution would be to rework all the SGE and FontManager code, which
we did, but send in a separate patch. :-) (You can also take a peek at
this code in our repository
(http://hg.openjdk.java.net/caciocavallo/jdk7/) ).

Thanks, Roman


-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080911/ec816682/attachment.bin 

From Dmitri.Trembovetski at Sun.COM  Wed Sep 10 16:54:02 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Wed, 10 Sep 2008 16:54:02 -0700
Subject: <AWT Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <1221090308.6500.3.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight>
	<1221083674.6592.35.camel@moonlight> <48C84DF0.1090506@Sun.COM>
	<1221090308.6500.3.camel@moonlight>
Message-ID: <48C85E1A.3030801@Sun.COM>


   Yep, I see. I didn't look at the file itself, only at the
   patch, and got confused.

   Thanks,
     Dmitri


Roman Kennke wrote:
> Hi Dmitri,
> 
>>> I need to repost my original patch for two reasons: 1. it doesn't apply
>>> cleanly (only with some fuzz), 2. it also has this init-loop problem.
>>> Find attached the correct version. I'd be happy to see it committed
>>> ASAP.
>>    I have a question about the fix:
>> --- a/src/solaris/native/sun/awt/fontpath.c	Thu Aug 07 09:42:31 2008 -0700
>> +++ b/src/solaris/native/sun/awt/fontpath.c	Wed Sep 10 23:52:15 2008 +0200
>> @@ -156,7 +156,7 @@
>>
>>       isLocal = JNU_CallStaticMethodByName(env, NULL,
>>                                            "sun/awt/X11GraphicsEnvironment",
>> -                                         "isDisplayLocal",
>> +                                         "_isDisplayLocal",
>>                                            "()Z").z;
>>
>>    Didn't you change isDisplayLocal to be non-static
>>    in X11GraphicsEnvironment? If so how does this actually
>>    work since you still call CallStaticMethodByName?
> 
> The _isDisplayLocal() is a static method in X11GraphicsEnvironment,
> which is called by isDisplayLocal() after entering the AWT monitor. The
> above code is already executed inside the AWT lock, so this is not a
> problem. And it is only called from the X11 backend anyway. Calling
> isDisplayLocal() results in a loop though, because it tries to load the
> X11GraphicsEnvironment class, which in turn causes the class initializer
> of SGE to be executed, which calls back into the code above, ad
> infinitum. This is why we call the static _isDisplayLocal() instead. The
> real solution would be to rework all the SGE and FontManager code, which
> we did, but send in a separate patch. :-) (You can also take a peek at
> this code in our repository
> (http://hg.openjdk.java.net/caciocavallo/jdk7/) ).
> 
> Thanks, Roman
> 
> 


From mario.torre at aicas.com  Wed Sep 10 16:15:54 2008
From: mario.torre at aicas.com (Mario Torre)
Date: Thu, 11 Sep 2008 01:15:54 +0200
Subject: <AWT Dev> [OpenJDK 2D-Dev]
	[PATCH]	SwingUtilities2.isLocalDisplay()
In-Reply-To: <48C84DF0.1090506@Sun.COM>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight>
	<1221083674.6592.35.camel@moonlight>  <48C84DF0.1090506@Sun.COM>
Message-ID: <1221088554.3336.17.camel@nirvana>

Il giorno mer, 10/09/2008 alle 15.45 -0700, Dmitri Trembovetski ha
scritto:

> --- a/src/solaris/native/sun/awt/fontpath.c	Thu Aug 07 09:42:31 2008 -0700
> +++ b/src/solaris/native/sun/awt/fontpath.c	Wed Sep 10 23:52:15 2008 +0200
> @@ -156,7 +156,7 @@
> 
>       isLocal = JNU_CallStaticMethodByName(env, NULL,
>                                            "sun/awt/X11GraphicsEnvironment",
> -                                         "isDisplayLocal",
> +                                         "_isDisplayLocal",
>                                            "()Z").z;

Hi Dmitri!

Calling "isDisplayLocal" fires up a infinite loop. Here we call
_isDisplayLocal, which is declared as:

private static boolean _isDisplayLocal

And we don't touch it in the patch.

We are not super happy with this, but I don't see much alternatives.
This code is X11 specific anyway.

All this Font code is really sensible to this kind of infinite loops...

Cheers,
Mario
-- 
?Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-53
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Gesch?ftsf?hrer: Dr. James J. Hunt

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/



From artem.ananiev at sun.com  Wed Sep 10 23:44:38 2008
From: artem.ananiev at sun.com (artem.ananiev at sun.com)
Date: Thu, 11 Sep 2008 06:44:38 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6727884: Some Uncaught Exceptions are
	no longer	getting sent to the Uncaught Exception Handlers
Message-ID: <20080911064450.53DEBD8CD@hg.openjdk.java.net>

Changeset: b0c557c745e8
Author:    art
Date:      2008-09-11 10:38 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/b0c557c745e8

6727884: Some Uncaught Exceptions are no longer getting sent to the Uncaught Exception Handlers
Reviewed-by: anthony, dav

! src/share/classes/java/awt/EventDispatchThread.java
+ test/java/awt/EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java



From Artem.Ananiev at Sun.COM  Thu Sep 11 01:10:01 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Thu, 11 Sep 2008 12:10:01 +0400
Subject: <AWT Dev> EventQueue changes
In-Reply-To: <271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>
References: <48C6644D.2020504@sun.com>
	<271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>
Message-ID: <48C8D259.8040809@sun.com>

Hi, Oleg,

Oleg Sukhodolsky wrote:
> On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>> Hi, AWT team,
>>
>> there are several issues related to EventQueue class with a long history.
>> The number of user votes constantly grows, so I think it would be fine if we
>> can get them fixed in some nearest future.
>>
>> The list of bugs include (but not limited to):
>>
>> 6424157: java.awt.EventQueue push/pop might cause threading issues
>>
>> 6542185: Threading issues with java.awt.EventQueue.push/pop
>> (closed as not a defect, but some of described problems still exist)
>>
>> 4913324: Deadlock when using two event queues.
>>
>> 4516924: Request public access to pumpEvents(Conditional) type
>> functionality.
>>
>> 6727884: Some Uncaught Exceptions are no longer getting sent to the Uncaught
>> Exception Handlers
>>
>> Some of the described problems don't look related to each other, however
>> after a closer look I found they really do. That's why I listed them here
>> altogether, and would like to discuss some possible improvements:
>>
>> 1. Synchronization changes. Most of the problems with push/pop are caused by
>> imperfect synchronization in EventQueue. Currently, all the actions like
>> postEvent() or getNextEvent() are transferred back and forth in the stack of
>> event queues, and each queue is accessed in its 'synchronized' block.
>> Instead, a single lock looks more correct here.
>>
>> 2. EventDispatchThread lifecycle. It is a known fact, that event dispatch
>> thread may die for some reason (for example, because of unhandled
>> exception). When a new event comes, new EDT is created. Another case when
>> EDT is switched is push/pop methods: when a new EQ is pushed/popped, a new
>> EDT is created.
>>
>> I'm sure these changes of current dispatch thread is not what developers
>> expect. Swing is considered as single-threaded toolkit, but it is really
>> not...
>>
>> 3. Controllable event pump. This is what developers have been requesting for
>> at least 8 years. With the current API this task cannot be solved, and all
>> the external libs like Foxtrot are really just hacks and depend on JDK
>> internals.
>>
>> From technical point of view, controllable event pump is just a several
>> lines of code changes: we only need to make public the code which is used
>> for modality event pumps.
>>
>> ----
>>
>> I have a prototype fix with all the three items implemented. Still, it would
>> be fine to hear what all AWT developers think about proposed changes.
> 
> I see list of problems, but do not see list of proposed changes :(
> Did I miss something?

You're right, the changes are not included, my fault... Here they are:

1. A single lock is introduced to handle all the EQ operations like 
push, pop, getNextEvent, etc. instead of locking all EQ objects one by 
one, if several.

2. EventDispatchThread is reused as much as possible. When a new EQ is 
pushed, it uses the old EDT instead of creating a new one. The same is 
true for pop().

3. pumpEvents() API is made public, probably with some minor changes.

Thanks,

Artem

> With best regards, Oleg.


From roman at kennke.org  Fri Sep 12 00:42:11 2008
From: roman at kennke.org (Roman Kennke)
Date: Fri, 12 Sep 2008 09:42:11 +0200
Subject: <AWT Dev> <Swing Dev> [OpenJDK 2D-Dev]
	[PATCH]	SwingUtilities2.isLocalDisplay()
In-Reply-To: <48C85E1A.3030801@Sun.COM>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight>
	<1221083674.6592.35.camel@moonlight> <48C84DF0.1090506@Sun.COM>
	<1221090308.6500.3.camel@moonlight>  <48C85E1A.3030801@Sun.COM>
Message-ID: <1221205331.6511.0.camel@moonlight>

Hi,

> Yep, I see. I didn't look at the file itself, only at the
>    patch, and got confused.

Ok, what's next? Will the patch be included?

/Roman

> 
>    Thanks,
>      Dmitri
> 
> 
> Roman Kennke wrote:
> > Hi Dmitri,
> > 
> >>> I need to repost my original patch for two reasons: 1. it doesn't apply
> >>> cleanly (only with some fuzz), 2. it also has this init-loop problem.
> >>> Find attached the correct version. I'd be happy to see it committed
> >>> ASAP.
> >>    I have a question about the fix:
> >> --- a/src/solaris/native/sun/awt/fontpath.c	Thu Aug 07 09:42:31 2008 -0700
> >> +++ b/src/solaris/native/sun/awt/fontpath.c	Wed Sep 10 23:52:15 2008 +0200
> >> @@ -156,7 +156,7 @@
> >>
> >>       isLocal = JNU_CallStaticMethodByName(env, NULL,
> >>                                            "sun/awt/X11GraphicsEnvironment",
> >> -                                         "isDisplayLocal",
> >> +                                         "_isDisplayLocal",
> >>                                            "()Z").z;
> >>
> >>    Didn't you change isDisplayLocal to be non-static
> >>    in X11GraphicsEnvironment? If so how does this actually
> >>    work since you still call CallStaticMethodByName?
> > 
> > The _isDisplayLocal() is a static method in X11GraphicsEnvironment,
> > which is called by isDisplayLocal() after entering the AWT monitor. The
> > above code is already executed inside the AWT lock, so this is not a
> > problem. And it is only called from the X11 backend anyway. Calling
> > isDisplayLocal() results in a loop though, because it tries to load the
> > X11GraphicsEnvironment class, which in turn causes the class initializer
> > of SGE to be executed, which calls back into the code above, ad
> > infinitum. This is why we call the static _isDisplayLocal() instead. The
> > real solution would be to rework all the SGE and FontManager code, which
> > we did, but send in a separate patch. :-) (You can also take a peek at
> > this code in our repository
> > (http://hg.openjdk.java.net/caciocavallo/jdk7/) ).
> > 
> > Thanks, Roman
> > 
> > 
-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080912/ee2c4cda/attachment.bin 

From son.two at gmail.com  Mon Sep 15 00:05:52 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Mon, 15 Sep 2008 11:05:52 +0400
Subject: <AWT Dev> EventQueue changes
In-Reply-To: <48C8D259.8040809@sun.com>
References: <48C6644D.2020504@sun.com>
	<271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>
	<48C8D259.8040809@sun.com>
Message-ID: <271e55d20809150005u39a8fde8nb5837d7f0d752524@mail.gmail.com>

Hi Artem,

I believe that three problems you want to fix are rather independent
so, I will write one message for every problem (also this way we will
have shorter messages ;)

> 2. EventDispatchThread is reused as much as possible. When a new EQ is
> pushed, it uses the old EDT instead of creating a new one. The same is true
> for pop().

here is a question: what "as much as possible" means?  If it means one
EDT for one EQ than it looks reasonable,
and the only issue is correct implemtation of this idea.  If you meant
something else, please clarify this.

BTW, as a side note: do not forget that we can not guarantee that
thread which is used as EDT will be the same all the time,
because of AWT autoshutdown.

Oleg.

On Thu, Sep 11, 2008 at 12:10 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
> Hi, Oleg,
>
> Oleg Sukhodolsky wrote:
>>
>> On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>> wrote:
>>>
>>> Hi, AWT team,
>>>
>>> there are several issues related to EventQueue class with a long history.
>>> The number of user votes constantly grows, so I think it would be fine if
>>> we
>>> can get them fixed in some nearest future.
>>>
>>> The list of bugs include (but not limited to):
>>>
>>> 6424157: java.awt.EventQueue push/pop might cause threading issues
>>>
>>> 6542185: Threading issues with java.awt.EventQueue.push/pop
>>> (closed as not a defect, but some of described problems still exist)
>>>
>>> 4913324: Deadlock when using two event queues.
>>>
>>> 4516924: Request public access to pumpEvents(Conditional) type
>>> functionality.
>>>
>>> 6727884: Some Uncaught Exceptions are no longer getting sent to the
>>> Uncaught
>>> Exception Handlers
>>>
>>> Some of the described problems don't look related to each other, however
>>> after a closer look I found they really do. That's why I listed them here
>>> altogether, and would like to discuss some possible improvements:
>>>
>>> 1. Synchronization changes. Most of the problems with push/pop are caused
>>> by
>>> imperfect synchronization in EventQueue. Currently, all the actions like
>>> postEvent() or getNextEvent() are transferred back and forth in the stack
>>> of
>>> event queues, and each queue is accessed in its 'synchronized' block.
>>> Instead, a single lock looks more correct here.
>>>
>>> 2. EventDispatchThread lifecycle. It is a known fact, that event dispatch
>>> thread may die for some reason (for example, because of unhandled
>>> exception). When a new event comes, new EDT is created. Another case when
>>> EDT is switched is push/pop methods: when a new EQ is pushed/popped, a
>>> new
>>> EDT is created.
>>>
>>> I'm sure these changes of current dispatch thread is not what developers
>>> expect. Swing is considered as single-threaded toolkit, but it is really
>>> not...
>>>
>>> 3. Controllable event pump. This is what developers have been requesting
>>> for
>>> at least 8 years. With the current API this task cannot be solved, and
>>> all
>>> the external libs like Foxtrot are really just hacks and depend on JDK
>>> internals.
>>>
>>> From technical point of view, controllable event pump is just a several
>>> lines of code changes: we only need to make public the code which is used
>>> for modality event pumps.
>>>
>>> ----
>>>
>>> I have a prototype fix with all the three items implemented. Still, it
>>> would
>>> be fine to hear what all AWT developers think about proposed changes.
>>
>> I see list of problems, but do not see list of proposed changes :(
>> Did I miss something?
>
> You're right, the changes are not included, my fault... Here they are:
>
> 1. A single lock is introduced to handle all the EQ operations like push,
> pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
> several.
>
> 2. EventDispatchThread is reused as much as possible. When a new EQ is
> pushed, it uses the old EDT instead of creating a new one. The same is true
> for pop().
>
> 3. pumpEvents() API is made public, probably with some minor changes.
>
> Thanks,
>
> Artem
>
>> With best regards, Oleg.
>


From son.two at gmail.com  Mon Sep 15 00:07:50 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Mon, 15 Sep 2008 11:07:50 +0400
Subject: <AWT Dev> EventQueue changes
In-Reply-To: <271e55d20809150005u39a8fde8nb5837d7f0d752524@mail.gmail.com>
References: <48C6644D.2020504@sun.com>
	<271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>
	<48C8D259.8040809@sun.com>
	<271e55d20809150005u39a8fde8nb5837d7f0d752524@mail.gmail.com>
Message-ID: <271e55d20809150007q402b3c01hba4fd937eab03ff1@mail.gmail.com>

On Mon, Sep 15, 2008 at 11:05 AM, Oleg Sukhodolsky <son.two at gmail.com> wrote:
> Hi Artem,
>
> I believe that three problems you want to fix are rather independent
> so, I will write one message for every problem (also this way we will
> have shorter messages ;)
>
>> 2. EventDispatchThread is reused as much as possible. When a new EQ is
>> pushed, it uses the old EDT instead of creating a new one. The same is true
>> for pop().
>
> here is a question: what "as much as possible" means?  If it means one
> EDT for one EQ than it looks reasonable,
> and the only issue is correct implemtation of this idea.  If you meant
> something else, please clarify this.
>
> BTW, as a side note: do not forget that we can not guarantee that
> thread which is used as EDT will be the same all the time,
> because of AWT autoshutdown.

also the same EDT for different EQs will not work for the following code:

--- executed on EDT --
pushd(newEQ);
//do something
pop()

Oleg.
>
> Oleg.
>
> On Thu, Sep 11, 2008 at 12:10 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>> Hi, Oleg,
>>
>> Oleg Sukhodolsky wrote:
>>>
>>> On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>>> wrote:
>>>>
>>>> Hi, AWT team,
>>>>
>>>> there are several issues related to EventQueue class with a long history.
>>>> The number of user votes constantly grows, so I think it would be fine if
>>>> we
>>>> can get them fixed in some nearest future.
>>>>
>>>> The list of bugs include (but not limited to):
>>>>
>>>> 6424157: java.awt.EventQueue push/pop might cause threading issues
>>>>
>>>> 6542185: Threading issues with java.awt.EventQueue.push/pop
>>>> (closed as not a defect, but some of described problems still exist)
>>>>
>>>> 4913324: Deadlock when using two event queues.
>>>>
>>>> 4516924: Request public access to pumpEvents(Conditional) type
>>>> functionality.
>>>>
>>>> 6727884: Some Uncaught Exceptions are no longer getting sent to the
>>>> Uncaught
>>>> Exception Handlers
>>>>
>>>> Some of the described problems don't look related to each other, however
>>>> after a closer look I found they really do. That's why I listed them here
>>>> altogether, and would like to discuss some possible improvements:
>>>>
>>>> 1. Synchronization changes. Most of the problems with push/pop are caused
>>>> by
>>>> imperfect synchronization in EventQueue. Currently, all the actions like
>>>> postEvent() or getNextEvent() are transferred back and forth in the stack
>>>> of
>>>> event queues, and each queue is accessed in its 'synchronized' block.
>>>> Instead, a single lock looks more correct here.
>>>>
>>>> 2. EventDispatchThread lifecycle. It is a known fact, that event dispatch
>>>> thread may die for some reason (for example, because of unhandled
>>>> exception). When a new event comes, new EDT is created. Another case when
>>>> EDT is switched is push/pop methods: when a new EQ is pushed/popped, a
>>>> new
>>>> EDT is created.
>>>>
>>>> I'm sure these changes of current dispatch thread is not what developers
>>>> expect. Swing is considered as single-threaded toolkit, but it is really
>>>> not...
>>>>
>>>> 3. Controllable event pump. This is what developers have been requesting
>>>> for
>>>> at least 8 years. With the current API this task cannot be solved, and
>>>> all
>>>> the external libs like Foxtrot are really just hacks and depend on JDK
>>>> internals.
>>>>
>>>> From technical point of view, controllable event pump is just a several
>>>> lines of code changes: we only need to make public the code which is used
>>>> for modality event pumps.
>>>>
>>>> ----
>>>>
>>>> I have a prototype fix with all the three items implemented. Still, it
>>>> would
>>>> be fine to hear what all AWT developers think about proposed changes.
>>>
>>> I see list of problems, but do not see list of proposed changes :(
>>> Did I miss something?
>>
>> You're right, the changes are not included, my fault... Here they are:
>>
>> 1. A single lock is introduced to handle all the EQ operations like push,
>> pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
>> several.
>>
>> 2. EventDispatchThread is reused as much as possible. When a new EQ is
>> pushed, it uses the old EDT instead of creating a new one. The same is true
>> for pop().
>>
>> 3. pumpEvents() API is made public, probably with some minor changes.
>>
>> Thanks,
>>
>> Artem
>>
>>> With best regards, Oleg.
>>
>


From son.two at gmail.com  Mon Sep 15 00:11:34 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Mon, 15 Sep 2008 11:11:34 +0400
Subject: <AWT Dev> EventQueue changes
In-Reply-To: <48C8D259.8040809@sun.com>
References: <48C6644D.2020504@sun.com>
	<271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>
	<48C8D259.8040809@sun.com>
Message-ID: <271e55d20809150011q4317d9e1rd5eadd8c57d98197@mail.gmail.com>

> 1. A single lock is introduced to handle all the EQ operations like push,
> pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
> several.

this change is backward incompatible :(  Why do you think that this is
the only way to fix synchronization problems.
Could you describe this problems with more details?

Thanks in advance, Oleg.

On Thu, Sep 11, 2008 at 12:10 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
> Hi, Oleg,
>
> Oleg Sukhodolsky wrote:
>>
>> On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>> wrote:
>>>
>>> Hi, AWT team,
>>>
>>> there are several issues related to EventQueue class with a long history.
>>> The number of user votes constantly grows, so I think it would be fine if
>>> we
>>> can get them fixed in some nearest future.
>>>
>>> The list of bugs include (but not limited to):
>>>
>>> 6424157: java.awt.EventQueue push/pop might cause threading issues
>>>
>>> 6542185: Threading issues with java.awt.EventQueue.push/pop
>>> (closed as not a defect, but some of described problems still exist)
>>>
>>> 4913324: Deadlock when using two event queues.
>>>
>>> 4516924: Request public access to pumpEvents(Conditional) type
>>> functionality.
>>>
>>> 6727884: Some Uncaught Exceptions are no longer getting sent to the
>>> Uncaught
>>> Exception Handlers
>>>
>>> Some of the described problems don't look related to each other, however
>>> after a closer look I found they really do. That's why I listed them here
>>> altogether, and would like to discuss some possible improvements:
>>>
>>> 1. Synchronization changes. Most of the problems with push/pop are caused
>>> by
>>> imperfect synchronization in EventQueue. Currently, all the actions like
>>> postEvent() or getNextEvent() are transferred back and forth in the stack
>>> of
>>> event queues, and each queue is accessed in its 'synchronized' block.
>>> Instead, a single lock looks more correct here.
>>>
>>> 2. EventDispatchThread lifecycle. It is a known fact, that event dispatch
>>> thread may die for some reason (for example, because of unhandled
>>> exception). When a new event comes, new EDT is created. Another case when
>>> EDT is switched is push/pop methods: when a new EQ is pushed/popped, a
>>> new
>>> EDT is created.
>>>
>>> I'm sure these changes of current dispatch thread is not what developers
>>> expect. Swing is considered as single-threaded toolkit, but it is really
>>> not...
>>>
>>> 3. Controllable event pump. This is what developers have been requesting
>>> for
>>> at least 8 years. With the current API this task cannot be solved, and
>>> all
>>> the external libs like Foxtrot are really just hacks and depend on JDK
>>> internals.
>>>
>>> From technical point of view, controllable event pump is just a several
>>> lines of code changes: we only need to make public the code which is used
>>> for modality event pumps.
>>>
>>> ----
>>>
>>> I have a prototype fix with all the three items implemented. Still, it
>>> would
>>> be fine to hear what all AWT developers think about proposed changes.
>>
>> I see list of problems, but do not see list of proposed changes :(
>> Did I miss something?
>
> You're right, the changes are not included, my fault... Here they are:
>
> 1. A single lock is introduced to handle all the EQ operations like push,
> pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
> several.
>
> 2. EventDispatchThread is reused as much as possible. When a new EQ is
> pushed, it uses the old EDT instead of creating a new one. The same is true
> for pop().
>
> 3. pumpEvents() API is made public, probably with some minor changes.
>
> Thanks,
>
> Artem
>
>> With best regards, Oleg.
>


From son.two at gmail.com  Mon Sep 15 00:12:30 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Mon, 15 Sep 2008 11:12:30 +0400
Subject: <AWT Dev> EventQueue changes
In-Reply-To: <48C8D259.8040809@sun.com>
References: <48C6644D.2020504@sun.com>
	<271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>
	<48C8D259.8040809@sun.com>
Message-ID: <271e55d20809150012g586b08bbu380d53cab2982dca@mail.gmail.com>

> 3. pumpEvents() API is made public, probably with some minor changes.

what use cases you want to address by this new API?

Regards, Oleg.

On Thu, Sep 11, 2008 at 12:10 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
> Hi, Oleg,
>
> Oleg Sukhodolsky wrote:
>>
>> On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>> wrote:
>>>
>>> Hi, AWT team,
>>>
>>> there are several issues related to EventQueue class with a long history.
>>> The number of user votes constantly grows, so I think it would be fine if
>>> we
>>> can get them fixed in some nearest future.
>>>
>>> The list of bugs include (but not limited to):
>>>
>>> 6424157: java.awt.EventQueue push/pop might cause threading issues
>>>
>>> 6542185: Threading issues with java.awt.EventQueue.push/pop
>>> (closed as not a defect, but some of described problems still exist)
>>>
>>> 4913324: Deadlock when using two event queues.
>>>
>>> 4516924: Request public access to pumpEvents(Conditional) type
>>> functionality.
>>>
>>> 6727884: Some Uncaught Exceptions are no longer getting sent to the
>>> Uncaught
>>> Exception Handlers
>>>
>>> Some of the described problems don't look related to each other, however
>>> after a closer look I found they really do. That's why I listed them here
>>> altogether, and would like to discuss some possible improvements:
>>>
>>> 1. Synchronization changes. Most of the problems with push/pop are caused
>>> by
>>> imperfect synchronization in EventQueue. Currently, all the actions like
>>> postEvent() or getNextEvent() are transferred back and forth in the stack
>>> of
>>> event queues, and each queue is accessed in its 'synchronized' block.
>>> Instead, a single lock looks more correct here.
>>>
>>> 2. EventDispatchThread lifecycle. It is a known fact, that event dispatch
>>> thread may die for some reason (for example, because of unhandled
>>> exception). When a new event comes, new EDT is created. Another case when
>>> EDT is switched is push/pop methods: when a new EQ is pushed/popped, a
>>> new
>>> EDT is created.
>>>
>>> I'm sure these changes of current dispatch thread is not what developers
>>> expect. Swing is considered as single-threaded toolkit, but it is really
>>> not...
>>>
>>> 3. Controllable event pump. This is what developers have been requesting
>>> for
>>> at least 8 years. With the current API this task cannot be solved, and
>>> all
>>> the external libs like Foxtrot are really just hacks and depend on JDK
>>> internals.
>>>
>>> From technical point of view, controllable event pump is just a several
>>> lines of code changes: we only need to make public the code which is used
>>> for modality event pumps.
>>>
>>> ----
>>>
>>> I have a prototype fix with all the three items implemented. Still, it
>>> would
>>> be fine to hear what all AWT developers think about proposed changes.
>>
>> I see list of problems, but do not see list of proposed changes :(
>> Did I miss something?
>
> You're right, the changes are not included, my fault... Here they are:
>
> 1. A single lock is introduced to handle all the EQ operations like push,
> pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
> several.
>
> 2. EventDispatchThread is reused as much as possible. When a new EQ is
> pushed, it uses the old EDT instead of creating a new one. The same is true
> for pop().
>
> 3. pumpEvents() API is made public, probably with some minor changes.
>
> Thanks,
>
> Artem
>
>> With best regards, Oleg.
>


From andrei.dmitriev at sun.com  Tue Sep 16 01:26:44 2008
From: andrei.dmitriev at sun.com (andrei.dmitriev at sun.com)
Date: Tue, 16 Sep 2008 08:26:44 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6315717: Support for mouse with
	multiple scroll	wheels and 4 or more buttons
Message-ID: <20080916082705.8F184DC93@hg.openjdk.java.net>

Changeset: 3b9a288d7ddb
Author:    dav
Date:      2008-09-16 12:17 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3b9a288d7ddb

6315717: Support for mouse with multiple scroll wheels and 4 or more buttons
Summary: implementation of the more mouse buttons support
Reviewed-by: art, dcherepanov

! make/sun/xawt/mapfile-vers
! src/share/classes/java/awt/Robot.java
! src/share/classes/java/awt/Toolkit.java
! src/share/classes/java/awt/doc-files/DesktopProperties.html
! src/share/classes/java/awt/event/InputEvent.java
! src/share/classes/java/awt/event/MouseEvent.java
! src/share/classes/java/awt/peer/RobotPeer.java
! src/share/classes/sun/awt/HeadlessToolkit.java
! src/solaris/classes/sun/awt/X11/XBaseWindow.java
! src/solaris/classes/sun/awt/X11/XConstants.java
! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java
! src/solaris/classes/sun/awt/X11/XRobotPeer.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
! src/solaris/native/sun/awt/awt_Robot.c
! src/windows/classes/sun/awt/windows/WRobotPeer.java
! src/windows/classes/sun/awt/windows/WToolkit.java
! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Component.h
! src/windows/native/sun/windows/awt_Robot.cpp
! src/windows/native/sun/windows/awt_Robot.h
! src/windows/native/sun/windows/awt_Toolkit.cpp
! src/windows/native/sun/windows/awt_Toolkit.h
! src/windows/native/sun/windows/awt_TrayIcon.cpp
+ test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java
+ test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java
+ test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java
+ test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java
+ test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java
+ test/java/awt/Robot/ManualInstructions/ManualInstructions.java
+ test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java
+ test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java
+ test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java
+ test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java
+ test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java
+ test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java
+ test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java
+ test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java
+ test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java
+ test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java
+ test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java
+ test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java
+ test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java



From Artem.Ananiev at Sun.COM  Tue Sep 16 01:57:52 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Tue, 16 Sep 2008 12:57:52 +0400
Subject: <AWT Dev> EventQueue changes
In-Reply-To: <271e55d20809150011q4317d9e1rd5eadd8c57d98197@mail.gmail.com>
References: <48C6644D.2020504@sun.com>
	<271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>
	<48C8D259.8040809@sun.com>
	<271e55d20809150011q4317d9e1rd5eadd8c57d98197@mail.gmail.com>
Message-ID: <48CF7510.5090605@sun.com>


Oleg Sukhodolsky wrote:
>> 1. A single lock is introduced to handle all the EQ operations like push,
>> pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
>> several.
> 
> this change is backward incompatible :(  Why do you think that this is
> the only way to fix synchronization problems.
> Could you describe this problems with more details?

This change is formally backwards compatible, as there is no single word 
about EQ synchronization in specification :) I clearly understand some 
libraries may be broken - see http://foxtrot.sourceforge.net/ project 
for example - however any code that relies on JDK internals is written 
by developers on their own risk.

A couple of words about the code. As described in 4913324, the order of 
locks may be different when using 3+ event queues which lead to 
deadlocks. To resolve this problem we either need: replace many locks 
with a single one, or make all the machinery single-threaded, or always 
specify the order of locks. The second approach is hardly implementable, 
because AWT is multi-threaded. The third approach is also difficult, in 
particular, because of event queue is accessed from at least two 
packages: java.awt and sun.awt - while all the information about EQ 
stack is package private in java.awt

Another possible solution I haven't thought about yet is to try to 
eliminate SunToolkit$PostEventQueue usage at all. This would resolve 
some (but probably, not all) problems, but it may have some impact on 
security and performance at the same time.

My general argumentation is following. Some basic usages of EQ API must 
not be broken by suggested changes. Complex libraries/applications may 
indeed be broken, however I'm not sure if they even exist - there are 
too many problems with the current implementation.

Thanks,

Artem

> Thanks in advance, Oleg.
> 
> On Thu, Sep 11, 2008 at 12:10 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>> Hi, Oleg,
>>
>> Oleg Sukhodolsky wrote:
>>> On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>>> wrote:
>>>> Hi, AWT team,
>>>>
>>>> there are several issues related to EventQueue class with a long history.
>>>> The number of user votes constantly grows, so I think it would be fine if
>>>> we
>>>> can get them fixed in some nearest future.
>>>>
>>>> The list of bugs include (but not limited to):
>>>>
>>>> 6424157: java.awt.EventQueue push/pop might cause threading issues
>>>>
>>>> 6542185: Threading issues with java.awt.EventQueue.push/pop
>>>> (closed as not a defect, but some of described problems still exist)
>>>>
>>>> 4913324: Deadlock when using two event queues.
>>>>
>>>> 4516924: Request public access to pumpEvents(Conditional) type
>>>> functionality.
>>>>
>>>> 6727884: Some Uncaught Exceptions are no longer getting sent to the
>>>> Uncaught
>>>> Exception Handlers
>>>>
>>>> Some of the described problems don't look related to each other, however
>>>> after a closer look I found they really do. That's why I listed them here
>>>> altogether, and would like to discuss some possible improvements:
>>>>
>>>> 1. Synchronization changes. Most of the problems with push/pop are caused
>>>> by
>>>> imperfect synchronization in EventQueue. Currently, all the actions like
>>>> postEvent() or getNextEvent() are transferred back and forth in the stack
>>>> of
>>>> event queues, and each queue is accessed in its 'synchronized' block.
>>>> Instead, a single lock looks more correct here.
>>>>
>>>> 2. EventDispatchThread lifecycle. It is a known fact, that event dispatch
>>>> thread may die for some reason (for example, because of unhandled
>>>> exception). When a new event comes, new EDT is created. Another case when
>>>> EDT is switched is push/pop methods: when a new EQ is pushed/popped, a
>>>> new
>>>> EDT is created.
>>>>
>>>> I'm sure these changes of current dispatch thread is not what developers
>>>> expect. Swing is considered as single-threaded toolkit, but it is really
>>>> not...
>>>>
>>>> 3. Controllable event pump. This is what developers have been requesting
>>>> for
>>>> at least 8 years. With the current API this task cannot be solved, and
>>>> all
>>>> the external libs like Foxtrot are really just hacks and depend on JDK
>>>> internals.
>>>>
>>>> From technical point of view, controllable event pump is just a several
>>>> lines of code changes: we only need to make public the code which is used
>>>> for modality event pumps.
>>>>
>>>> ----
>>>>
>>>> I have a prototype fix with all the three items implemented. Still, it
>>>> would
>>>> be fine to hear what all AWT developers think about proposed changes.
>>> I see list of problems, but do not see list of proposed changes :(
>>> Did I miss something?
>> You're right, the changes are not included, my fault... Here they are:
>>
>> 1. A single lock is introduced to handle all the EQ operations like push,
>> pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
>> several.
>>
>> 2. EventDispatchThread is reused as much as possible. When a new EQ is
>> pushed, it uses the old EDT instead of creating a new one. The same is true
>> for pop().
>>
>> 3. pumpEvents() API is made public, probably with some minor changes.
>>
>> Thanks,
>>
>> Artem
>>
>>> With best regards, Oleg.


From roman.kennke at aicas.com  Tue Sep 16 02:02:27 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Tue, 16 Sep 2008 11:02:27 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
Message-ID: <1221555747.6579.11.camel@moonlight>

Hello,

The peer interfaces have a lot of duplicate methods, where one is
deprecated and 'replaced' by a new one (for example, preferredSize() and
getPreferredSize() ). I see that this makes sense for public API
_classes_ to maintain backward compatibility, but it does _not_ make
sense for interfaces. It only confuses those who have to implement those
interfaces (which method should I implement? Which one is called, and
which should call which?), and adds no value at all. Also: the new
interface methods are not used (i.e. called by AWT) at all. As part of
the Caciocavallo project I went through this stuff and removed the
duplicates, leaving the new methods in the interfaces and made AWT call
the new methods instead. There were also a couple of methods that are
never called from AWT (like ComponentPeer.repaint() ), which I also
removed (some of such methods are used, but only in the interface
implementation, so it is not required to have them in the public
interface). What do you think? Should this be merged into main JDK7?

Cheers, Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt
-------------- next part --------------
# HG changeset patch
# User Mario Torre <mario.torre at aicas.com>
# Date 1217450571 -7200
# Node ID 87fd234ed5ab0bac1ffa8731e80ded5830aa1684
# Parent  9af1670d56ecb4d3e49a21c9389c390e4c9e003f
imported patch RepaintManager.patch

diff -r 9af1670d56ec -r 87fd234ed5ab src/share/classes/javax/swing/RepaintManager.java
--- a/src/share/classes/javax/swing/RepaintManager.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/javax/swing/RepaintManager.java	Wed Jul 30 22:42:51 2008 +0200
@@ -1261,9 +1261,12 @@
             if (doubleBufferingEnabled && !nativeDoubleBuffering) {
                 switch (bufferStrategyType) {
                 case BUFFER_STRATEGY_NOT_SPECIFIED:
-                    if (((SunToolkit)Toolkit.getDefaultToolkit()).
-                                                useBufferPerWindow()) {
-                        paintManager = new BufferStrategyPaintManager();
+                    Toolkit tk = Toolkit.getDefaultToolkit();
+                    if (tk instanceof SunToolkit) {
+                        SunToolkit stk = (SunToolkit) tk;
+                        if (stk.useBufferPerWindow()) {
+                            paintManager = new BufferStrategyPaintManager();
+                        }
                     }
                     break;
                 case BUFFER_STRATEGY_SPECIFIED_ON:
@@ -1285,9 +1288,16 @@
 
     private void scheduleProcessingRunnable(AppContext context) {
         if (processingRunnable.markPending()) {
-            SunToolkit.getSystemEventQueueImplPP(context).
-                postEvent(new InvocationEvent(Toolkit.getDefaultToolkit(),
-                                              processingRunnable));
+            Toolkit tk = Toolkit.getDefaultToolkit();
+            if (tk instanceof SunToolkit) {
+                SunToolkit.getSystemEventQueueImplPP(context).
+                  postEvent(new InvocationEvent(Toolkit.getDefaultToolkit(),
+                                                processingRunnable));
+            } else {
+                Toolkit.getDefaultToolkit().getSystemEventQueue().
+                      postEvent(new InvocationEvent(Toolkit.getDefaultToolkit(),
+                                                    processingRunnable));
+            }
         }
     }
 

From Artem.Ananiev at Sun.COM  Tue Sep 16 02:03:35 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Tue, 16 Sep 2008 13:03:35 +0400
Subject: <AWT Dev> EventQueue changes
In-Reply-To: <271e55d20809150012g586b08bbu380d53cab2982dca@mail.gmail.com>
References: <48C6644D.2020504@sun.com>
	<271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>
	<48C8D259.8040809@sun.com>
	<271e55d20809150012g586b08bbu380d53cab2982dca@mail.gmail.com>
Message-ID: <48CF7667.408@sun.com>


Oleg Sukhodolsky wrote:
>> 3. pumpEvents() API is made public, probably with some minor changes.
> 
> what use cases you want to address by this new API?

There are several tens of votes for all the related bugs. One more 
argument is that all the modern toolkits (Win32, GTK, SWT) have this API 
implemented, while AWT/Swing still misses it.

I also constantly face with scenarios, when some developer needs to 
start a nested event pump and use a modal dialog for this, which looks 
quite ugly and unstable.

Thanks,

Artem

> Regards, Oleg.
> 
> On Thu, Sep 11, 2008 at 12:10 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>> Hi, Oleg,
>>
>> Oleg Sukhodolsky wrote:
>>> On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>>> wrote:
>>>> Hi, AWT team,
>>>>
>>>> there are several issues related to EventQueue class with a long history.
>>>> The number of user votes constantly grows, so I think it would be fine if
>>>> we
>>>> can get them fixed in some nearest future.
>>>>
>>>> The list of bugs include (but not limited to):
>>>>
>>>> 6424157: java.awt.EventQueue push/pop might cause threading issues
>>>>
>>>> 6542185: Threading issues with java.awt.EventQueue.push/pop
>>>> (closed as not a defect, but some of described problems still exist)
>>>>
>>>> 4913324: Deadlock when using two event queues.
>>>>
>>>> 4516924: Request public access to pumpEvents(Conditional) type
>>>> functionality.
>>>>
>>>> 6727884: Some Uncaught Exceptions are no longer getting sent to the
>>>> Uncaught
>>>> Exception Handlers
>>>>
>>>> Some of the described problems don't look related to each other, however
>>>> after a closer look I found they really do. That's why I listed them here
>>>> altogether, and would like to discuss some possible improvements:
>>>>
>>>> 1. Synchronization changes. Most of the problems with push/pop are caused
>>>> by
>>>> imperfect synchronization in EventQueue. Currently, all the actions like
>>>> postEvent() or getNextEvent() are transferred back and forth in the stack
>>>> of
>>>> event queues, and each queue is accessed in its 'synchronized' block.
>>>> Instead, a single lock looks more correct here.
>>>>
>>>> 2. EventDispatchThread lifecycle. It is a known fact, that event dispatch
>>>> thread may die for some reason (for example, because of unhandled
>>>> exception). When a new event comes, new EDT is created. Another case when
>>>> EDT is switched is push/pop methods: when a new EQ is pushed/popped, a
>>>> new
>>>> EDT is created.
>>>>
>>>> I'm sure these changes of current dispatch thread is not what developers
>>>> expect. Swing is considered as single-threaded toolkit, but it is really
>>>> not...
>>>>
>>>> 3. Controllable event pump. This is what developers have been requesting
>>>> for
>>>> at least 8 years. With the current API this task cannot be solved, and
>>>> all
>>>> the external libs like Foxtrot are really just hacks and depend on JDK
>>>> internals.
>>>>
>>>> From technical point of view, controllable event pump is just a several
>>>> lines of code changes: we only need to make public the code which is used
>>>> for modality event pumps.
>>>>
>>>> ----
>>>>
>>>> I have a prototype fix with all the three items implemented. Still, it
>>>> would
>>>> be fine to hear what all AWT developers think about proposed changes.
>>> I see list of problems, but do not see list of proposed changes :(
>>> Did I miss something?
>> You're right, the changes are not included, my fault... Here they are:
>>
>> 1. A single lock is introduced to handle all the EQ operations like push,
>> pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
>> several.
>>
>> 2. EventDispatchThread is reused as much as possible. When a new EQ is
>> pushed, it uses the old EDT instead of creating a new one. The same is true
>> for pop().
>>
>> 3. pumpEvents() API is made public, probably with some minor changes.
>>
>> Thanks,
>>
>> Artem
>>
>>> With best regards, Oleg.


From Artem.Ananiev at Sun.COM  Tue Sep 16 02:06:20 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Tue, 16 Sep 2008 13:06:20 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1221555747.6579.11.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
Message-ID: <48CF770C.5030802@sun.com>

Hi, Roman,

AWT peer interfaces are really not a part of specification and can be 
changed at any moment, so we/you shouldn't bother about backwards 
compatibility. That's why I consider this suggested cleanup valuable.

Could you provide some more details about what methods and interfaces 
are changed/removed, please?

Thanks,

Artem

Roman Kennke wrote:
> Hello,
> 
> The peer interfaces have a lot of duplicate methods, where one is
> deprecated and 'replaced' by a new one (for example, preferredSize() and
> getPreferredSize() ). I see that this makes sense for public API
> _classes_ to maintain backward compatibility, but it does _not_ make
> sense for interfaces. It only confuses those who have to implement those
> interfaces (which method should I implement? Which one is called, and
> which should call which?), and adds no value at all. Also: the new
> interface methods are not used (i.e. called by AWT) at all. As part of
> the Caciocavallo project I went through this stuff and removed the
> duplicates, leaving the new methods in the interfaces and made AWT call
> the new methods instead. There were also a couple of methods that are
> never called from AWT (like ComponentPeer.repaint() ), which I also
> removed (some of such methods are used, but only in the interface
> implementation, so it is not required to have them in the public
> interface). What do you think? Should this be merged into main JDK7?
> 
> Cheers, Roman
> 
> 


From roman.kennke at aicas.com  Tue Sep 16 02:45:33 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Tue, 16 Sep 2008 11:45:33 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48CF770C.5030802@sun.com>
References: <1221555747.6579.11.camel@moonlight>  <48CF770C.5030802@sun.com>
Message-ID: <1221558333.6579.31.camel@moonlight>

Hi Artem,

> AWT peer interfaces are really not a part of specification and can be 
> changed at any moment, so we/you shouldn't bother about backwards 
> compatibility. That's why I consider this suggested cleanup valuable.
> 
> Could you provide some more details about what methods and interfaces 
> are changed/removed, please?

Sure:

ChoicePeer.addItem()             removed, use add() instead.
ComponentPeer.enable()           removed, use setEnabled() instead.
ComponentPeer.disable()          removed, use setEnabled() instead.
ComponentPeer.show()             removed, use setVisible() instead.
ComponentPeer.hide()             removed, use setVisible() instead.
ComponentPeer.preferredSize()    removed, use getPreferredSize().
ComponentPeer.minimumSize()      removed, use getMinimumSize().
ContainerPeer.insets()           removed, use getInsets() instead.
ListPeer.addItem()               removed, use add() instead.
ListPeer.clear()                 removed, use removeAll() instead.
ListPeer.setMultipleSelections() removed, use setMultipleMode().
ListPeer.preferredSize(int)      removed, use getPreferredSize(int).
ListPeer.minimumSize(int)        removed, use getMinimumSize(int).
MenuItemPeer.enable()            removed, use setEnabled() instead.
MenuItemPeer.disable()           removed, use setEnabled() instead.
TextAreaPeer.insertText()        removed, use insert() instead.
TextAreaPeer.replaceText()       removed, use replaceRange().
TextAreaPeer.preferredSize(..)   removed, use getPreferredSize(..).
TextAreaPeer.minimumSize(..)     removed, use getMinimumSize(..).
TextFieldPeer.setEchoCharacter() removed, use setEchoChar().
TextFieldPeer.preferredSize(..)  removed, use getPreferredSize(..).
TextFieldPeer.minimumSize(..)    removed, use getMinimumSize(..).

Removed, because not used (anymore?) by AWT:
ComponentPeer.repaint()
ComponentPeer.getBounds()
ComponentPeer.reshape()
ContainerPeer.isPaintPending()
TextComponentPeer.getIndexAtPoint()
TextComponentPeer.getCharacterBounds()
TextComponentPeer.filterEvents()
WindowPeer.requestWindowFocus()

Hope this helps,
/Roman

> 
> Thanks,
> 
> Artem
> 
> Roman Kennke wrote:
> > Hello,
> > 
> > The peer interfaces have a lot of duplicate methods, where one is
> > deprecated and 'replaced' by a new one (for example, preferredSize() and
> > getPreferredSize() ). I see that this makes sense for public API
> > _classes_ to maintain backward compatibility, but it does _not_ make
> > sense for interfaces. It only confuses those who have to implement those
> > interfaces (which method should I implement? Which one is called, and
> > which should call which?), and adds no value at all. Also: the new
> > interface methods are not used (i.e. called by AWT) at all. As part of
> > the Caciocavallo project I went through this stuff and removed the
> > duplicates, leaving the new methods in the interfaces and made AWT call
> > the new methods instead. There were also a couple of methods that are
> > never called from AWT (like ComponentPeer.repaint() ), which I also
> > removed (some of such methods are used, but only in the interface
> > implementation, so it is not required to have them in the public
> > interface). What do you think? Should this be merged into main JDK7?
> > 
> > Cheers, Roman
> > 
> > 
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From roman.kennke at aicas.com  Tue Sep 16 03:11:53 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Tue, 16 Sep 2008 12:11:53 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1221555747.6579.11.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
Message-ID: <1221559913.6579.36.camel@moonlight>

Sorry, I sent the wrong patch. Here's the correct one.

/Roman

Am Dienstag, den 16.09.2008, 11:02 +0200 schrieb Roman Kennke:
> Hello,
> 
> The peer interfaces have a lot of duplicate methods, where one is
> deprecated and 'replaced' by a new one (for example, preferredSize() and
> getPreferredSize() ). I see that this makes sense for public API
> _classes_ to maintain backward compatibility, but it does _not_ make
> sense for interfaces. It only confuses those who have to implement those
> interfaces (which method should I implement? Which one is called, and
> which should call which?), and adds no value at all. Also: the new
> interface methods are not used (i.e. called by AWT) at all. As part of
> the Caciocavallo project I went through this stuff and removed the
> duplicates, leaving the new methods in the interfaces and made AWT call
> the new methods instead. There were also a couple of methods that are
> never called from AWT (like ComponentPeer.repaint() ), which I also
> removed (some of such methods are used, but only in the interface
> implementation, so it is not required to have them in the public
> interface). What do you think? Should this be merged into main JDK7?
> 
> Cheers, Roman
> 
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt
-------------- next part --------------
# HG changeset patch
# User Mario Torre <mario.torre at aicas.com>
# Date 1217450572 -7200
# Node ID 94efba2ca4347bb035935b2ced7e42fedcdcfb25
# Parent  87fd234ed5ab0bac1ffa8731e80ded5830aa1684
imported patch cleanawtpeer.patch

diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/Choice.java
--- a/src/share/classes/java/awt/Choice.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/Choice.java	Wed Jul 30 22:42:52 2008 +0200
@@ -230,7 +230,7 @@
         pItems.insertElementAt(item, index);
         ChoicePeer peer = (ChoicePeer)this.peer;
         if (peer != null) {
-            peer.addItem(item, index);
+            peer.add(item, index);
         }
         // no selection or selection shifted up
         if (selectedIndex < 0 || selectedIndex >= index) {
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/Component.java
--- a/src/share/classes/java/awt/Component.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/Component.java	Wed Jul 30 22:42:52 2008 +0200
@@ -1292,7 +1292,7 @@
                 enabled = true;
                 ComponentPeer peer = this.peer;
                 if (peer != null) {
-                    peer.enable();
+                    peer.setEnabled(true);
                     if (visible) {
                         updateCursorImmediately();
                     }
@@ -1341,7 +1341,7 @@
                 }
                 ComponentPeer peer = this.peer;
                 if (peer != null) {
-                    peer.disable();
+                    peer.setEnabled(false);
                     if (visible) {
                         updateCursorImmediately();
                     }
@@ -1433,7 +1433,7 @@
                 mixOnShowing();
                 ComponentPeer peer = this.peer;
                 if (peer != null) {
-                    peer.show();
+                    peer.setVisible(true);
                     createHierarchyEvents(HierarchyEvent.HIERARCHY_CHANGED,
                                           this, parent,
                                           HierarchyEvent.SHOWING_CHANGED,
@@ -1503,7 +1503,7 @@
                 }
                 ComponentPeer peer = this.peer;
                 if (peer != null) {
-                    peer.hide();
+                    peer.setVisible(false);
                     createHierarchyEvents(HierarchyEvent.HIERARCHY_CHANGED,
                                           this, parent,
                                           HierarchyEvent.SHOWING_CHANGED,
@@ -2402,7 +2402,7 @@
         if (dim == null || !(isPreferredSizeSet() || isValid())) {
             synchronized (getTreeLock()) {
                 prefSize = (peer != null) ?
-                    peer.preferredSize() :
+                    peer.getPreferredSize() :
                     getMinimumSize();
                 dim = prefSize;
             }
@@ -2472,7 +2472,7 @@
         if (dim == null || !(isMinimumSizeSet() || isValid())) {
             synchronized (getTreeLock()) {
                 minSize = (peer != null) ?
-                    peer.minimumSize() :
+                    peer.getMinimumSize() :
                     size();
                 dim = minSize;
             }
@@ -3147,7 +3147,7 @@
     private Insets getInsets_NoClientCode() {
         ComponentPeer peer = this.peer;
         if (peer instanceof ContainerPeer) {
-            return (Insets)((ContainerPeer)peer).insets().clone();
+            return (Insets)((ContainerPeer)peer).getInsets().clone();
         }
         return new Insets(0, 0, 0, 0);
     }
@@ -6635,7 +6635,7 @@
 
                 // Hide peer first to stop system events such as cursor moves.
                 if (visible) {
-                    p.hide();
+                    p.setVisible(false);
                 }
 
                 peer = null; // Stop peer updates.
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/Container.java
--- a/src/share/classes/java/awt/Container.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/Container.java	Wed Jul 30 22:42:52 2008 +0200
@@ -350,7 +350,7 @@
         ComponentPeer peer = this.peer;
         if (peer instanceof ContainerPeer) {
             ContainerPeer cpeer = (ContainerPeer)peer;
-            return (Insets)cpeer.insets().clone();
+            return (Insets)cpeer.getInsets().clone();
         }
         return new Insets(0, 0, 0, 0);
     }
@@ -3976,7 +3976,7 @@
                 if (comp.isVisible()) {
                     ComponentPeer peer = comp.getPeer();
                     if (peer != null) {
-                        peer.show();
+                        peer.setVisible(true);
                     }
                 }
             }
@@ -3997,7 +3997,7 @@
                 if (comp.isVisible()) {
                     ComponentPeer peer = comp.getPeer();
                     if (peer != null) {
-                        peer.hide();
+                        peer.setVisible(false);
                     }
                 }
             }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/Dialog.java
--- a/src/share/classes/java/awt/Dialog.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/Dialog.java	Wed Jul 30 22:42:52 2008 +0200
@@ -941,7 +941,7 @@
                 // does not invoke the super.show(). So wried... :(
                 mixOnShowing();
 
-                peer.show(); // now guaranteed never to block
+                peer.setVisible(true); // now guaranteed never to block
                 if (isModalBlocked()) {
                     modalBlocker.toFront();
                 }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/List.java
--- a/src/share/classes/java/awt/List.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/List.java	Wed Jul 30 22:42:52 2008 +0200
@@ -378,7 +378,7 @@
 
         ListPeer peer = (ListPeer)this.peer;
         if (peer != null) {
-            peer.addItem(item, index);
+            peer.add(item, index);
         }
     }
 
@@ -413,7 +413,7 @@
     public synchronized void clear() {
         ListPeer peer = (ListPeer)this.peer;
         if (peer != null) {
-            peer.clear();
+            peer.removeAll();
         }
         items = new Vector();
         selected = new int[0];
@@ -718,7 +718,7 @@
             multipleMode = b;
             ListPeer peer = (ListPeer)this.peer;
             if (peer != null) {
-                peer.setMultipleSelections(b);
+                peer.setMultipleMode(b);
             }
         }
     }
@@ -768,7 +768,7 @@
         synchronized (getTreeLock()) {
             ListPeer peer = (ListPeer)this.peer;
             return (peer != null) ?
-                       peer.preferredSize(rows) :
+                       peer.getPreferredSize(rows) :
                        super.preferredSize();
         }
     }
@@ -818,7 +818,7 @@
         synchronized (getTreeLock()) {
             ListPeer peer = (ListPeer)this.peer;
             return (peer != null) ?
-                       peer.minimumSize(rows) :
+                       peer.getMinimumSize(rows) :
                        super.minimumSize();
         }
     }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/MenuItem.java
--- a/src/share/classes/java/awt/MenuItem.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/MenuItem.java	Wed Jul 30 22:42:52 2008 +0200
@@ -268,7 +268,7 @@
         enabled = true;
         MenuItemPeer peer = (MenuItemPeer)this.peer;
         if (peer != null) {
-            peer.enable();
+            peer.setEnabled(true);
         }
     }
 
@@ -294,7 +294,7 @@
         enabled = false;
         MenuItemPeer peer = (MenuItemPeer)this.peer;
         if (peer != null) {
-            peer.disable();
+            peer.setEnabled(false);
         }
     }
 
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/TextArea.java
--- a/src/share/classes/java/awt/TextArea.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/TextArea.java	Wed Jul 30 22:42:52 2008 +0200
@@ -321,7 +321,7 @@
     public synchronized void insertText(String str, int pos) {
         TextAreaPeer peer = (TextAreaPeer)this.peer;
         if (peer != null) {
-            peer.insertText(str, pos);
+            peer.insert(str, pos);
         } else {
             text = text.substring(0, pos) + str + text.substring(pos);
         }
@@ -385,7 +385,7 @@
     public synchronized void replaceText(String str, int start, int end) {
         TextAreaPeer peer = (TextAreaPeer)this.peer;
         if (peer != null) {
-            peer.replaceText(str, start, end);
+            peer.replaceRange(str, start, end);
         } else {
             text = text.substring(0, start) + str + text.substring(end);
         }
@@ -500,7 +500,7 @@
         synchronized (getTreeLock()) {
             TextAreaPeer peer = (TextAreaPeer)this.peer;
             return (peer != null) ?
-                       peer.preferredSize(rows, columns) :
+                       peer.getPreferredSize(rows, columns) :
                        super.preferredSize();
         }
     }
@@ -552,7 +552,7 @@
         synchronized (getTreeLock()) {
             TextAreaPeer peer = (TextAreaPeer)this.peer;
             return (peer != null) ?
-                       peer.minimumSize(rows, columns) :
+                       peer.getMinimumSize(rows, columns) :
                        super.minimumSize();
         }
     }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/TextField.java
--- a/src/share/classes/java/awt/TextField.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/TextField.java	Wed Jul 30 22:42:52 2008 +0200
@@ -281,7 +281,7 @@
             echoChar = c;
             TextFieldPeer peer = (TextFieldPeer)this.peer;
             if (peer != null) {
-                peer.setEchoCharacter(c);
+                peer.setEchoChar(c);
             }
         }
     }
@@ -378,7 +378,7 @@
         synchronized (getTreeLock()) {
             TextFieldPeer peer = (TextFieldPeer)this.peer;
             return (peer != null) ?
-                       peer.preferredSize(columns) :
+                       peer.getPreferredSize(columns) :
                        super.preferredSize();
         }
     }
@@ -426,7 +426,7 @@
         synchronized (getTreeLock()) {
             TextFieldPeer peer = (TextFieldPeer)this.peer;
             return (peer != null) ?
-                       peer.minimumSize(columns) :
+                       peer.getMinimumSize(columns) :
                        super.minimumSize();
         }
     }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/peer/ChoicePeer.java
--- a/src/share/classes/java/awt/peer/ChoicePeer.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/peer/ChoicePeer.java	Wed Jul 30 22:42:52 2008 +0200
@@ -37,8 +37,4 @@
     void removeAll();
     void select(int index);
 
-    /*
-     * DEPRECATED:  Replaced by add(String, int).
-     */
-    void addItem(String item, int index);
 }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/peer/ComponentPeer.java
--- a/src/share/classes/java/awt/peer/ComponentPeer.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/peer/ComponentPeer.java	Wed Jul 30 22:42:52 2008 +0200
@@ -56,7 +56,6 @@
     void                setVisible(boolean b);
     void                setEnabled(boolean b);
     void                paint(Graphics g);
-    void                repaint(long tm, int x, int y, int width, int height);
     void                print(Graphics g);
     void                setBounds(int x, int y, int width, int height, int op);
     void                handleEvent(AWTEvent e);
@@ -112,47 +111,10 @@
      */
     void        layout();
 
-
-        Rectangle getBounds();
-
     /**
      * Applies the shape to the native component window.
      * @since 1.7
      */
     void applyShape(Region shape);
 
-    /**
-     * DEPRECATED:  Replaced by getPreferredSize().
-     */
-    Dimension           preferredSize();
-
-    /**
-     * DEPRECATED:  Replaced by getMinimumSize().
-     */
-    Dimension           minimumSize();
-
-    /**
-     * DEPRECATED:  Replaced by setVisible(boolean).
-     */
-    void                show();
-
-    /**
-     * DEPRECATED:  Replaced by setVisible(boolean).
-     */
-    void                hide();
-
-    /**
-     * DEPRECATED:  Replaced by setEnabled(boolean).
-     */
-    void                enable();
-
-    /**
-     * DEPRECATED:  Replaced by setEnabled(boolean).
-     */
-    void                disable();
-
-    /**
-     * DEPRECATED:  Replaced by setBounds(int, int, int, int).
-     */
-    void                reshape(int x, int y, int width, int height);
 }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/peer/ContainerPeer.java
--- a/src/share/classes/java/awt/peer/ContainerPeer.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/peer/ContainerPeer.java	Wed Jul 30 22:42:52 2008 +0200
@@ -39,7 +39,6 @@
     void endValidate();
     void beginLayout();
     void endLayout();
-    boolean isPaintPending();
 
     /**
      * Restacks native windows - children of this native window - according to Java container order
@@ -53,11 +52,4 @@
      * @since 1.5
      */
     boolean isRestackSupported();
-    /**
-
-
-
-     * DEPRECATED:  Replaced by getInsets().
-     */
-    Insets insets();
 }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/peer/ListPeer.java
--- a/src/share/classes/java/awt/peer/ListPeer.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/peer/ListPeer.java	Wed Jul 30 22:42:52 2008 +0200
@@ -45,28 +45,4 @@
     Dimension getPreferredSize(int rows);
     Dimension getMinimumSize(int rows);
 
-    /**
-     * DEPRECATED:  Replaced by add(String, int).
-     */
-    void addItem(String item, int index);
-
-    /**
-     * DEPRECATED:  Replaced by removeAll().
-     */
-    void clear();
-
-    /**
-     * DEPRECATED:  Replaced by setMultipleMode(boolean).
-     */
-    void setMultipleSelections(boolean v);
-
-    /**
-     * DEPRECATED:  Replaced by getPreferredSize(int).
-     */
-    Dimension preferredSize(int v);
-
-    /**
-     * DEPRECATED:  Replaced by getMinimumSize(int).
-     */
-    Dimension minimumSize(int v);
 }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/peer/MenuItemPeer.java
--- a/src/share/classes/java/awt/peer/MenuItemPeer.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/peer/MenuItemPeer.java	Wed Jul 30 22:42:52 2008 +0200
@@ -35,13 +35,4 @@
     void setLabel(String label);
     void setEnabled(boolean b);
 
-    /**
-     * DEPRECATED:  Replaced by setEnabled(boolean).
-     */
-    void enable();
-
-    /**
-     * DEPRECATED:  Replaced by setEnabled(boolean).
-     */
-    void disable();
 }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/peer/TextAreaPeer.java
--- a/src/share/classes/java/awt/peer/TextAreaPeer.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/peer/TextAreaPeer.java	Wed Jul 30 22:42:52 2008 +0200
@@ -39,23 +39,4 @@
     Dimension getPreferredSize(int rows, int columns);
     Dimension getMinimumSize(int rows, int columns);
 
-    /**
-     * DEPRECATED:  Replaced by insert(String, int).
-     */
-    void insertText(String txt, int pos);
-
-    /**
-     * DEPRECATED:  Replaced by ReplaceRange(String, int, int).
-     */
-    void replaceText(String txt, int start, int end);
-
-    /**
-     * DEPRECATED:  Replaced by getPreferredSize(int, int).
-     */
-    Dimension preferredSize(int rows, int cols);
-
-    /**
-     * DEPRECATED:  Replaced by getMinimumSize(int, int).
-     */
-    Dimension minimumSize(int rows, int cols);
 }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/peer/TextComponentPeer.java
--- a/src/share/classes/java/awt/peer/TextComponentPeer.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/peer/TextComponentPeer.java	Wed Jul 30 22:42:52 2008 +0200
@@ -24,7 +24,6 @@
  */
 package java.awt.peer;
 
-import java.awt.Rectangle;
 import java.awt.im.InputMethodRequests;
 
 /**
@@ -43,8 +42,5 @@
     void select(int selStart, int selEnd);
     void setCaretPosition(int pos);
     int getCaretPosition();
-    int getIndexAtPoint(int x, int y);
-    Rectangle getCharacterBounds(int i);
-    long filterEvents(long mask);
     InputMethodRequests getInputMethodRequests();
 }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/peer/TextFieldPeer.java
--- a/src/share/classes/java/awt/peer/TextFieldPeer.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/peer/TextFieldPeer.java	Wed Jul 30 22:42:52 2008 +0200
@@ -38,18 +38,4 @@
     Dimension getPreferredSize(int columns);
     Dimension getMinimumSize(int columns);
 
-    /**
-     * DEPRECATED:  Replaced by setEchoChar(char echoChar).
-     */
-    void setEchoCharacter(char c);
-
-    /**
-     * DEPRECATED:  Replaced by getPreferredSize(int).
-     */
-    Dimension preferredSize(int cols);
-
-    /**
-     * DEPRECATED:  Replaced by getMinimumSize(int).
-     */
-    Dimension minimumSize(int cols);
 }
diff -r 87fd234ed5ab -r 94efba2ca434 src/share/classes/java/awt/peer/WindowPeer.java
--- a/src/share/classes/java/awt/peer/WindowPeer.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/java/awt/peer/WindowPeer.java	Wed Jul 30 22:42:52 2008 +0200
@@ -39,7 +39,6 @@
     void toBack();
     void setAlwaysOnTop(boolean alwaysOnTop);
     void updateFocusableWindowState();
-    boolean requestWindowFocus();
     void setModalBlocked(Dialog blocker, boolean blocked);
     void updateMinimumSize();
     void updateIconImages();
diff -r 87fd234ed5ab -r 94efba2ca434 src/solaris/classes/sun/awt/motif/MComponentPeer.java
--- a/src/solaris/classes/sun/awt/motif/MComponentPeer.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/solaris/classes/sun/awt/motif/MComponentPeer.java	Wed Jul 30 22:42:52 2008 +0200
@@ -587,7 +587,7 @@
                     // but return true for compatibility.
                     return true;
                 } else if (getNativeFocusedWindow() != parentWindow) {
-                    WindowPeer wpeer = (WindowPeer)parentWindow.getPeer();
+                    MWindowPeer wpeer = (MWindowPeer)parentWindow.getPeer();
                     boolean res = wpeer.requestWindowFocus();
                     if (focusLog.isLoggable(Level.FINER)) {
                         focusLog.log(Level.FINER, "Requested window focus: " + res);

From roman.kennke at aicas.com  Tue Sep 16 04:06:16 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Tue, 16 Sep 2008 13:06:16 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1221559913.6579.36.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
Message-ID: <1221563176.20626.5.camel@moonlight>

Also see the webrevs to this patch:

http://kennke.org/~roman/webrev/cleanpeers/webrev/

/Roman

Am Dienstag, den 16.09.2008, 12:11 +0200 schrieb Roman Kennke:
> Sorry, I sent the wrong patch. Here's the correct one.
> 
> /Roman
> 
> Am Dienstag, den 16.09.2008, 11:02 +0200 schrieb Roman Kennke:
> > Hello,
> > 
> > The peer interfaces have a lot of duplicate methods, where one is
> > deprecated and 'replaced' by a new one (for example, preferredSize() and
> > getPreferredSize() ). I see that this makes sense for public API
> > _classes_ to maintain backward compatibility, but it does _not_ make
> > sense for interfaces. It only confuses those who have to implement those
> > interfaces (which method should I implement? Which one is called, and
> > which should call which?), and adds no value at all. Also: the new
> > interface methods are not used (i.e. called by AWT) at all. As part of
> > the Caciocavallo project I went through this stuff and removed the
> > duplicates, leaving the new methods in the interfaces and made AWT call
> > the new methods instead. There were also a couple of methods that are
> > never called from AWT (like ComponentPeer.repaint() ), which I also
> > removed (some of such methods are used, but only in the interface
> > implementation, so it is not required to have them in the public
> > interface). What do you think? Should this be merged into main JDK7?
> > 
> > Cheers, Roman
> > 
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From son.two at gmail.com  Tue Sep 16 20:40:26 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Wed, 17 Sep 2008 07:40:26 +0400
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6315717: Support for mouse with
	multiple scroll wheels and 4 or more buttons
In-Reply-To: <20080916082705.8F184DC93@hg.openjdk.java.net>
References: <20080916082705.8F184DC93@hg.openjdk.java.net>
Message-ID: <271e55d20809162040w6e32e9d2qbd6c70491f507599@mail.gmail.com>

Congratulations!!! You have  completed  this project (finally ;)

On Tue, Sep 16, 2008 at 12:26 PM,  <andrei.dmitriev at sun.com> wrote:
> Changeset: 3b9a288d7ddb
> Author:    dav
> Date:      2008-09-16 12:17 +0400
> URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3b9a288d7ddb
>
> 6315717: Support for mouse with multiple scroll wheels and 4 or more buttons
> Summary: implementation of the more mouse buttons support
> Reviewed-by: art, dcherepanov
>
> ! make/sun/xawt/mapfile-vers
> ! src/share/classes/java/awt/Robot.java
> ! src/share/classes/java/awt/Toolkit.java
> ! src/share/classes/java/awt/doc-files/DesktopProperties.html
> ! src/share/classes/java/awt/event/InputEvent.java
> ! src/share/classes/java/awt/event/MouseEvent.java
> ! src/share/classes/java/awt/peer/RobotPeer.java
> ! src/share/classes/sun/awt/HeadlessToolkit.java
> ! src/solaris/classes/sun/awt/X11/XBaseWindow.java
> ! src/solaris/classes/sun/awt/X11/XConstants.java
> ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java
> ! src/solaris/classes/sun/awt/X11/XRobotPeer.java
> ! src/solaris/classes/sun/awt/X11/XToolkit.java
> ! src/solaris/classes/sun/awt/X11/XWindow.java
> ! src/solaris/classes/sun/awt/X11/XWindowPeer.java
> ! src/solaris/native/sun/awt/awt_Robot.c
> ! src/windows/classes/sun/awt/windows/WRobotPeer.java
> ! src/windows/classes/sun/awt/windows/WToolkit.java
> ! src/windows/native/sun/windows/awt_Component.cpp
> ! src/windows/native/sun/windows/awt_Component.h
> ! src/windows/native/sun/windows/awt_Robot.cpp
> ! src/windows/native/sun/windows/awt_Robot.h
> ! src/windows/native/sun/windows/awt_Toolkit.cpp
> ! src/windows/native/sun/windows/awt_Toolkit.h
> ! src/windows/native/sun/windows/awt_TrayIcon.cpp
> + test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java
> + test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java
> + test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java
> + test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java
> + test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java
> + test/java/awt/Robot/ManualInstructions/ManualInstructions.java
> + test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java
> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java
> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java
> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java
> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java
> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java
> + test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java
> + test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java
> + test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java
> + test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java
> + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java
> + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java
> + test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java
>
>


From andrei.dmitriev at sun.com  Tue Sep 16 20:54:23 2008
From: andrei.dmitriev at sun.com (Andrei Dmitriev)
Date: Wed, 17 Sep 2008 07:54:23 +0400
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6315717: Support for mouse with
 multiple scroll wheels and 4 or more buttons
In-Reply-To: <271e55d20809162040w6e32e9d2qbd6c70491f507599@mail.gmail.com>
References: <20080916082705.8F184DC93@hg.openjdk.java.net>
	<271e55d20809162040w6e32e9d2qbd6c70491f507599@mail.gmail.com>
Message-ID: <48D07F6F.2080901@sun.com>

Thanks!
Oleg Sukhodolsky wrote:
> Congratulations!!! You have  completed  this project (finally ;)
>
> On Tue, Sep 16, 2008 at 12:26 PM,  <andrei.dmitriev at sun.com> wrote:
>   
>> Changeset: 3b9a288d7ddb
>> Author:    dav
>> Date:      2008-09-16 12:17 +0400
>> URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3b9a288d7ddb
>>
>> 6315717: Support for mouse with multiple scroll wheels and 4 or more buttons
>> Summary: implementation of the more mouse buttons support
>> Reviewed-by: art, dcherepanov
>>
>> ! make/sun/xawt/mapfile-vers
>> ! src/share/classes/java/awt/Robot.java
>> ! src/share/classes/java/awt/Toolkit.java
>> ! src/share/classes/java/awt/doc-files/DesktopProperties.html
>> ! src/share/classes/java/awt/event/InputEvent.java
>> ! src/share/classes/java/awt/event/MouseEvent.java
>> ! src/share/classes/java/awt/peer/RobotPeer.java
>> ! src/share/classes/sun/awt/HeadlessToolkit.java
>> ! src/solaris/classes/sun/awt/X11/XBaseWindow.java
>> ! src/solaris/classes/sun/awt/X11/XConstants.java
>> ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java
>> ! src/solaris/classes/sun/awt/X11/XRobotPeer.java
>> ! src/solaris/classes/sun/awt/X11/XToolkit.java
>> ! src/solaris/classes/sun/awt/X11/XWindow.java
>> ! src/solaris/classes/sun/awt/X11/XWindowPeer.java
>> ! src/solaris/native/sun/awt/awt_Robot.c
>> ! src/windows/classes/sun/awt/windows/WRobotPeer.java
>> ! src/windows/classes/sun/awt/windows/WToolkit.java
>> ! src/windows/native/sun/windows/awt_Component.cpp
>> ! src/windows/native/sun/windows/awt_Component.h
>> ! src/windows/native/sun/windows/awt_Robot.cpp
>> ! src/windows/native/sun/windows/awt_Robot.h
>> ! src/windows/native/sun/windows/awt_Toolkit.cpp
>> ! src/windows/native/sun/windows/awt_Toolkit.h
>> ! src/windows/native/sun/windows/awt_TrayIcon.cpp
>> + test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java
>> + test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java
>> + test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java
>> + test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java
>> + test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java
>> + test/java/awt/Robot/ManualInstructions/ManualInstructions.java
>> + test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java
>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java
>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java
>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java
>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java
>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java
>> + test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java
>> + test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java
>> + test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java
>> + test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java
>> + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java
>> + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java
>> + test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java
>>
>>
>>     



From Andrei.Dmitriev at Sun.COM  Wed Sep 17 07:24:07 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Wed, 17 Sep 2008 18:24:07 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1221563176.20626.5.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
Message-ID: <48D11307.5020400@sun.com>

I like that stuff!
Isn't it reasonable to push that into JDK7? Sure!
I'll file a defect and send CR number in a separate message.
Thanks,
   Andrei

Roman Kennke wrote:
> Also see the webrevs to this patch:
> 
> http://kennke.org/~roman/webrev/cleanpeers/webrev/
> 
> /Roman
> 
> Am Dienstag, den 16.09.2008, 12:11 +0200 schrieb Roman Kennke:
>> Sorry, I sent the wrong patch. Here's the correct one.
>>
>> /Roman
>>
>> Am Dienstag, den 16.09.2008, 11:02 +0200 schrieb Roman Kennke:
>>> Hello,
>>>
>>> The peer interfaces have a lot of duplicate methods, where one is
>>> deprecated and 'replaced' by a new one (for example, preferredSize() and
>>> getPreferredSize() ). I see that this makes sense for public API
>>> _classes_ to maintain backward compatibility, but it does _not_ make
>>> sense for interfaces. It only confuses those who have to implement those
>>> interfaces (which method should I implement? Which one is called, and
>>> which should call which?), and adds no value at all. Also: the new
>>> interface methods are not used (i.e. called by AWT) at all. As part of
>>> the Caciocavallo project I went through this stuff and removed the
>>> duplicates, leaving the new methods in the interfaces and made AWT call
>>> the new methods instead. There were also a couple of methods that are
>>> never called from AWT (like ComponentPeer.repaint() ), which I also
>>> removed (some of such methods are used, but only in the interface
>>> implementation, so it is not required to have them in the public
>>> interface). What do you think? Should this be merged into main JDK7?
>>>
>>> Cheers, Roman
>>>


From son.two at gmail.com  Wed Sep 17 11:23:58 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Wed, 17 Sep 2008 22:23:58 +0400
Subject: <AWT Dev> EventQueue changes
In-Reply-To: <48CF7667.408@sun.com>
References: <48C6644D.2020504@sun.com>
	<271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>
	<48C8D259.8040809@sun.com>
	<271e55d20809150012g586b08bbu380d53cab2982dca@mail.gmail.com>
	<48CF7667.408@sun.com>
Message-ID: <271e55d20809171123p1b2399ddg35559e3aa136a909@mail.gmail.com>

On Tue, Sep 16, 2008 at 1:03 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>
> Oleg Sukhodolsky wrote:
>>>
>>> 3. pumpEvents() API is made public, probably with some minor changes.
>>
>> what use cases you want to address by this new API?
>
> There are several tens of votes for all the related bugs. One more argument
> is that all the modern toolkits (Win32, GTK, SWT) have this API implemented,
> while AWT/Swing still misses it.
>
> I also constantly face with scenarios, when some developer needs to start a
> nested event pump and use a modal dialog for this, which looks quite ugly
> and unstable.

What kind of scenarios do you mean?

Thanks, Oleg.
>
> Thanks,
>
> Artem
>
>> Regards, Oleg.
>>
>> On Thu, Sep 11, 2008 at 12:10 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>> wrote:
>>>
>>> Hi, Oleg,
>>>
>>> Oleg Sukhodolsky wrote:
>>>>
>>>> On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>>>> wrote:
>>>>>
>>>>> Hi, AWT team,
>>>>>
>>>>> there are several issues related to EventQueue class with a long
>>>>> history.
>>>>> The number of user votes constantly grows, so I think it would be fine
>>>>> if
>>>>> we
>>>>> can get them fixed in some nearest future.
>>>>>
>>>>> The list of bugs include (but not limited to):
>>>>>
>>>>> 6424157: java.awt.EventQueue push/pop might cause threading issues
>>>>>
>>>>> 6542185: Threading issues with java.awt.EventQueue.push/pop
>>>>> (closed as not a defect, but some of described problems still exist)
>>>>>
>>>>> 4913324: Deadlock when using two event queues.
>>>>>
>>>>> 4516924: Request public access to pumpEvents(Conditional) type
>>>>> functionality.
>>>>>
>>>>> 6727884: Some Uncaught Exceptions are no longer getting sent to the
>>>>> Uncaught
>>>>> Exception Handlers
>>>>>
>>>>> Some of the described problems don't look related to each other,
>>>>> however
>>>>> after a closer look I found they really do. That's why I listed them
>>>>> here
>>>>> altogether, and would like to discuss some possible improvements:
>>>>>
>>>>> 1. Synchronization changes. Most of the problems with push/pop are
>>>>> caused
>>>>> by
>>>>> imperfect synchronization in EventQueue. Currently, all the actions
>>>>> like
>>>>> postEvent() or getNextEvent() are transferred back and forth in the
>>>>> stack
>>>>> of
>>>>> event queues, and each queue is accessed in its 'synchronized' block.
>>>>> Instead, a single lock looks more correct here.
>>>>>
>>>>> 2. EventDispatchThread lifecycle. It is a known fact, that event
>>>>> dispatch
>>>>> thread may die for some reason (for example, because of unhandled
>>>>> exception). When a new event comes, new EDT is created. Another case
>>>>> when
>>>>> EDT is switched is push/pop methods: when a new EQ is pushed/popped, a
>>>>> new
>>>>> EDT is created.
>>>>>
>>>>> I'm sure these changes of current dispatch thread is not what
>>>>> developers
>>>>> expect. Swing is considered as single-threaded toolkit, but it is
>>>>> really
>>>>> not...
>>>>>
>>>>> 3. Controllable event pump. This is what developers have been
>>>>> requesting
>>>>> for
>>>>> at least 8 years. With the current API this task cannot be solved, and
>>>>> all
>>>>> the external libs like Foxtrot are really just hacks and depend on JDK
>>>>> internals.
>>>>>
>>>>> From technical point of view, controllable event pump is just a several
>>>>> lines of code changes: we only need to make public the code which is
>>>>> used
>>>>> for modality event pumps.
>>>>>
>>>>> ----
>>>>>
>>>>> I have a prototype fix with all the three items implemented. Still, it
>>>>> would
>>>>> be fine to hear what all AWT developers think about proposed changes.
>>>>
>>>> I see list of problems, but do not see list of proposed changes :(
>>>> Did I miss something?
>>>
>>> You're right, the changes are not included, my fault... Here they are:
>>>
>>> 1. A single lock is introduced to handle all the EQ operations like push,
>>> pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
>>> several.
>>>
>>> 2. EventDispatchThread is reused as much as possible. When a new EQ is
>>> pushed, it uses the old EDT instead of creating a new one. The same is
>>> true
>>> for pop().
>>>
>>> 3. pumpEvents() API is made public, probably with some minor changes.
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>>> With best regards, Oleg.
>


From son.two at gmail.com  Wed Sep 17 11:42:29 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Wed, 17 Sep 2008 22:42:29 +0400
Subject: <AWT Dev> EventQueue changes
In-Reply-To: <48CF7510.5090605@sun.com>
References: <48C6644D.2020504@sun.com>
	<271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>
	<48C8D259.8040809@sun.com>
	<271e55d20809150011q4317d9e1rd5eadd8c57d98197@mail.gmail.com>
	<48CF7510.5090605@sun.com>
Message-ID: <271e55d20809171142g6a567551v5fbbf434fd6ab968@mail.gmail.com>

On Tue, Sep 16, 2008 at 12:57 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>
> Oleg Sukhodolsky wrote:
>>>
>>> 1. A single lock is introduced to handle all the EQ operations like push,
>>> pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
>>> several.
>>
>> this change is backward incompatible :(  Why do you think that this is
>> the only way to fix synchronization problems.
>> Could you describe this problems with more details?
>
> This change is formally backwards compatible, as there is no single word
> about EQ synchronization in specification :) I clearly understand some
> libraries may be broken - see http://foxtrot.sourceforge.net/ project for
> example - however any code that relies on JDK internals is written by
> developers on their own risk.

I do not want to argue on this topic, but we both know that the
changes may break
some apps, and this is the main problem.

> A couple of words about the code. As described in 4913324, the order of
> locks may be different when using 3+ event queues which lead to deadlocks.

as far as I can see from evaluation of the bug the problem is caused
by the fact that
internal methods of EQ use "this" for synchronization.

> To resolve this problem we either need: replace many locks with a single
> one, or make all the machinery single-threaded, or always specify the order
> of locks. The second approach is hardly implementable, because AWT is
> multi-threaded. The third approach is also difficult, in particular, because
> of event queue is accessed from at least two packages: java.awt and sun.awt
> - while all the information about EQ stack is package private in java.awt

I think we should try to reconsider synchronization strategy for
internal methods,
but try to keep synchronization we have in public methods unchanged.
(I'm not sure
that this is possible,but we (you ;) should try)

> Another possible solution I haven't thought about yet is to try to eliminate
> SunToolkit$PostEventQueue usage at all. This would resolve some (but
> probably, not all) problems, but it may have some impact on security and
> performance at the same time.
>
> My general argumentation is following. Some basic usages of EQ API must not
> be broken by suggested changes. Complex libraries/applications may indeed be
> broken, however I'm not sure if they even exist - there are too many
> problems with the current implementation.

I remember similar reasoning for focus api which developed for 1.4,
and the fact is
that apps/libs which will be broken by such changes may cause VERY BIG
problems (just imagin what if some VERY BIG customer will be affected, what kind
of flame will generated about this)

Oleg.
>
> Thanks,
>
> Artem
>
>> Thanks in advance, Oleg.
>>
>> On Thu, Sep 11, 2008 at 12:10 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>> wrote:
>>>
>>> Hi, Oleg,
>>>
>>> Oleg Sukhodolsky wrote:
>>>>
>>>> On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>>>> wrote:
>>>>>
>>>>> Hi, AWT team,
>>>>>
>>>>> there are several issues related to EventQueue class with a long
>>>>> history.
>>>>> The number of user votes constantly grows, so I think it would be fine
>>>>> if
>>>>> we
>>>>> can get them fixed in some nearest future.
>>>>>
>>>>> The list of bugs include (but not limited to):
>>>>>
>>>>> 6424157: java.awt.EventQueue push/pop might cause threading issues
>>>>>
>>>>> 6542185: Threading issues with java.awt.EventQueue.push/pop
>>>>> (closed as not a defect, but some of described problems still exist)
>>>>>
>>>>> 4913324: Deadlock when using two event queues.
>>>>>
>>>>> 4516924: Request public access to pumpEvents(Conditional) type
>>>>> functionality.
>>>>>
>>>>> 6727884: Some Uncaught Exceptions are no longer getting sent to the
>>>>> Uncaught
>>>>> Exception Handlers
>>>>>
>>>>> Some of the described problems don't look related to each other,
>>>>> however
>>>>> after a closer look I found they really do. That's why I listed them
>>>>> here
>>>>> altogether, and would like to discuss some possible improvements:
>>>>>
>>>>> 1. Synchronization changes. Most of the problems with push/pop are
>>>>> caused
>>>>> by
>>>>> imperfect synchronization in EventQueue. Currently, all the actions
>>>>> like
>>>>> postEvent() or getNextEvent() are transferred back and forth in the
>>>>> stack
>>>>> of
>>>>> event queues, and each queue is accessed in its 'synchronized' block.
>>>>> Instead, a single lock looks more correct here.
>>>>>
>>>>> 2. EventDispatchThread lifecycle. It is a known fact, that event
>>>>> dispatch
>>>>> thread may die for some reason (for example, because of unhandled
>>>>> exception). When a new event comes, new EDT is created. Another case
>>>>> when
>>>>> EDT is switched is push/pop methods: when a new EQ is pushed/popped, a
>>>>> new
>>>>> EDT is created.
>>>>>
>>>>> I'm sure these changes of current dispatch thread is not what
>>>>> developers
>>>>> expect. Swing is considered as single-threaded toolkit, but it is
>>>>> really
>>>>> not...
>>>>>
>>>>> 3. Controllable event pump. This is what developers have been
>>>>> requesting
>>>>> for
>>>>> at least 8 years. With the current API this task cannot be solved, and
>>>>> all
>>>>> the external libs like Foxtrot are really just hacks and depend on JDK
>>>>> internals.
>>>>>
>>>>> From technical point of view, controllable event pump is just a several
>>>>> lines of code changes: we only need to make public the code which is
>>>>> used
>>>>> for modality event pumps.
>>>>>
>>>>> ----
>>>>>
>>>>> I have a prototype fix with all the three items implemented. Still, it
>>>>> would
>>>>> be fine to hear what all AWT developers think about proposed changes.
>>>>
>>>> I see list of problems, but do not see list of proposed changes :(
>>>> Did I miss something?
>>>
>>> You're right, the changes are not included, my fault... Here they are:
>>>
>>> 1. A single lock is introduced to handle all the EQ operations like push,
>>> pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
>>> several.
>>>
>>> 2. EventDispatchThread is reused as much as possible. When a new EQ is
>>> pushed, it uses the old EDT instead of creating a new one. The same is
>>> true
>>> for pop().
>>>
>>> 3. pumpEvents() API is made public, probably with some minor changes.
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>>> With best regards, Oleg.
>


From mario.torre at aicas.com  Wed Sep 17 13:58:06 2008
From: mario.torre at aicas.com (Mario Torre)
Date: Wed, 17 Sep 2008 22:58:06 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48D11307.5020400@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight> <48D11307.5020400@sun.com>
Message-ID: <1221685086.2838.2.camel@nirvana>

Il giorno mer, 17/09/2008 alle 18.24 +0400, Andrei V. Dmitriev ha
scritto:
> I like that stuff!
> Isn't it reasonable to push that into JDK7? Sure!
> I'll file a defect and send CR number in a separate message.
> Thanks,
>    Andrei

:)

If I can suggest, is it possible that this time we have the review to
happen in public?

Cheers,
Mario
-- 
?Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-53
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Gesch?ftsf?hrer: Dr. James J. Hunt

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/



From Andrei.Dmitriev at Sun.COM  Thu Sep 18 01:09:35 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Thu, 18 Sep 2008 12:09:35 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1221685086.2838.2.camel@nirvana>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D11307.5020400@sun.com> <1221685086.2838.2.camel@nirvana>
Message-ID: <48D20CBF.908@sun.com>

After a short chat with Anton Tarasov believe I got your intention. :)
Sure, I personally prefer if everyone interested would take part in 
review. I'd also prefer if some of you do push once you get the OK from 
each side.

Still, changing the state of the bug [1] which will become available for 
public shortly, is an action for me.

Regards,
   Andrei

[1] http://bugs.sun.com/view_bug.do?bug_id=6749750

Mario Torre wrote:
> Il giorno mer, 17/09/2008 alle 18.24 +0400, Andrei V. Dmitriev ha
> scritto:
>> I like that stuff!
>> Isn't it reasonable to push that into JDK7? Sure!
>> I'll file a defect and send CR number in a separate message.
>> Thanks,
>>    Andrei
> 
> :)
> 
> If I can suggest, is it possible that this time we have the review to
> happen in public?
> 
> Cheers,
> Mario


From mario.torre at aicas.com  Thu Sep 18 03:40:50 2008
From: mario.torre at aicas.com (Mario Torre)
Date: Thu, 18 Sep 2008 12:40:50 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48D20CBF.908@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D11307.5020400@sun.com> <1221685086.2838.2.camel@nirvana>
	<48D20CBF.908@sun.com>
Message-ID: <1221734450.2972.35.camel@nirvana>

Il giorno gio, 18/09/2008 alle 12.09 +0400, Andrei V. Dmitriev ha
scritto:
> After a short chat with Anton Tarasov believe I got your intention. :)
> Sure, I personally prefer if everyone interested would take part in 
> review. I'd also prefer if some of you do push once you get the OK from 
> each side.
> 
> Still, changing the state of the bug [1] which will become available for 
> public shortly, is an action for me.
> 
> Regards,
>    Andrei
> 
> [1] http://bugs.sun.com/view_bug.do?bug_id=6749750

Hi Andrei!

Thanks for this, this definitely help to build up the community!

Let's defeat the remaining sceptical!! :)

Cheers,
Mario
-- 
?Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-53
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Gesch?ftsf?hrer: Dr. James J. Hunt

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/



From Andrei.Dmitriev at Sun.COM  Thu Sep 18 03:50:38 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Thu, 18 Sep 2008 14:50:38 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1221563176.20626.5.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
Message-ID: <48D2327E.8020306@sun.com>

Just built a fresh local repo with these changes and tried a bunch of 
Container, Component and Window-related reg-tests. They are just fine.

1) Just curious if the concrete peer code are supposed to be changed? 
Looking on XTextFieldPeer we may notice something like that:

     /**
      * DEPRECATED
      * @see java.awt.peer.TextFieldPeer
      */
     public Dimension preferredSize(int cols) {
         return getPreferredSize(cols);
     }

     public Dimension getPreferredSize() {
         return xtext.getPreferredSize();
     }

With this patch applied we aren't obliged anymore to support that stuff, 
right? Along with your new toolkit it's probably doesn't matter but does 
it look reasonable to cover that issue by some other CR? Or just add 
into the current patch if you are real hot? Predict that there are a lot 
of the code are supposed to be affected: 
src/windows/classes/sun/awt/windows/WxyzPeer.java, etc.
So the total number of files would be doubled. So be aware. :)

2)I don't take Motif toolkit into account. You are fixing that as well, 
- src/solaris/classes/sun/awt/motif/MComponentPeer.java.
You'll probably be suggested by the system to ignore that patch on the 
push stage. So be prepared.

Anyway, I'm fine with that patch. Approved.
Thanks,
   Andrei

Roman Kennke wrote:
> Also see the webrevs to this patch:
> 
> http://kennke.org/~roman/webrev/cleanpeers/webrev/
> 
> /Roman
> 
> Am Dienstag, den 16.09.2008, 12:11 +0200 schrieb Roman Kennke:
>> Sorry, I sent the wrong patch. Here's the correct one.
>>
>> /Roman
>>
>> Am Dienstag, den 16.09.2008, 11:02 +0200 schrieb Roman Kennke:
>>> Hello,
>>>
>>> The peer interfaces have a lot of duplicate methods, where one is
>>> deprecated and 'replaced' by a new one (for example, preferredSize() and
>>> getPreferredSize() ). I see that this makes sense for public API
>>> _classes_ to maintain backward compatibility, but it does _not_ make
>>> sense for interfaces. It only confuses those who have to implement those
>>> interfaces (which method should I implement? Which one is called, and
>>> which should call which?), and adds no value at all. Also: the new
>>> interface methods are not used (i.e. called by AWT) at all. As part of
>>> the Caciocavallo project I went through this stuff and removed the
>>> duplicates, leaving the new methods in the interfaces and made AWT call
>>> the new methods instead. There were also a couple of methods that are
>>> never called from AWT (like ComponentPeer.repaint() ), which I also
>>> removed (some of such methods are used, but only in the interface
>>> implementation, so it is not required to have them in the public
>>> interface). What do you think? Should this be merged into main JDK7?
>>>
>>> Cheers, Roman
>>>


From roman.kennke at aicas.com  Thu Sep 18 03:59:14 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Thu, 18 Sep 2008 12:59:14 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48D2327E.8020306@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight> <48D2327E.8020306@sun.com>
Message-ID: <1221735554.6609.16.camel@moonlight>

Hi Andrei,

> Just built a fresh local repo with these changes and tried a bunch of 
> Container, Component and Window-related reg-tests. They are just fine.
> 
> 1) Just curious if the concrete peer code are supposed to be changed? 
> Looking on XTextFieldPeer we may notice something like that:
> 
>      /**
>       * DEPRECATED
>       * @see java.awt.peer.TextFieldPeer
>       */
>      public Dimension preferredSize(int cols) {
>          return getPreferredSize(cols);
>      }
> 
>      public Dimension getPreferredSize() {
>          return xtext.getPreferredSize();
>      }
> 
> With this patch applied we aren't obliged anymore to support that stuff, 
> right?

Yeah sure. I reviewed all the existing implementations and they should
not break, but a lot of stuff could be removed.

>  Along with your new toolkit it's probably doesn't matter but does 
> it look reasonable to cover that issue by some other CR? Or just add 
> into the current patch if you are real hot?

No, I'm not really hot with this :-)

>  Predict that there are a lot 
> of the code are supposed to be affected: 
> src/windows/classes/sun/awt/windows/WxyzPeer.java, etc.
> So the total number of files would be doubled. So be aware. :)

Yeah. Especially Windows, which I have no way to test.

> 2)I don't take Motif toolkit into account. You are fixing that as well, 
> - src/solaris/classes/sun/awt/motif/MComponentPeer.java.

This specific case needed to be fixed, because it was casting to
WindowPeer, only to be able to call the requestWindowFocus() method
which is not used by AWT, but only internally in the Motif toolkit. I
removed this method from WindowPeer, so we need to cast to MWindowPeer
instead, that's all.

> You'll probably be suggested by the system to ignore that patch on the 
> push stage. So be prepared.

If I ignore it, we can't build MComponentPeer anymore. Be prepared :-)

> Anyway, I'm fine with that patch. Approved.

Cheers, Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From Andrei.Dmitriev at Sun.COM  Thu Sep 18 05:28:33 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Thu, 18 Sep 2008 16:28:33 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1221735554.6609.16.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221735554.6609.16.camel@moonlight>
Message-ID: <48D24971.5050104@sun.com>

I meant that there is no such class in the JDK7 anymore:
http://hg.openjdk.java.net/jdk7/awt/jdk/file/3b9a288d7ddb/src/solaris/classes/sun/awt/motif/
Actually there are few motif classes are remaining there though they 
still are compiled while building the repo.
Regards,
   Andrei

>> 2)I don't take Motif toolkit into account. You are fixing that as well, 
>> - src/solaris/classes/sun/awt/motif/MComponentPeer.java.
> 
> This specific case needed to be fixed, because it was casting to
> WindowPeer, only to be able to call the requestWindowFocus() method
> which is not used by AWT, but only internally in the Motif toolkit. I
> removed this method from WindowPeer, so we need to cast to MWindowPeer
> instead, that's all.
> 
>> You'll probably be suggested by the system to ignore that patch on the 
>> push stage. So be prepared.
> 
> If I ignore it, we can't build MComponentPeer anymore. Be prepared :-)
> 
>> Anyway, I'm fine with that patch. Approved.
> 
> Cheers, Roman
> 


From roman.kennke at aicas.com  Thu Sep 18 12:50:37 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Thu, 18 Sep 2008 21:50:37 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48D2327E.8020306@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight> <48D2327E.8020306@sun.com>
Message-ID: <1221767437.31171.5.camel@moonlight>

Hi Andrei,

> Anyway, I'm fine with that patch. Approved.

Cool. So should I commit and push this patch (minus the MComponentPeer
thing) to the awt-gate? Or do I have to wait for another OK? Does my
(SSH-level) permission to push to the Cacio-Repos also extend to the
other gates automatically? Also, I probably need some guidance with the
exact commit message.

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From Denis.Fokin at Sun.COM  Fri Sep 19 00:07:23 2008
From: Denis.Fokin at Sun.COM (Denis S. Fokin)
Date: Fri, 19 Sep 2008 11:07:23 +0400
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6315717: Support for mouse with
 multiple scroll wheels and 4 or more buttons
In-Reply-To: <48D07F6F.2080901@sun.com>
References: <20080916082705.8F184DC93@hg.openjdk.java.net>
	<271e55d20809162040w6e32e9d2qbd6c70491f507599@mail.gmail.com>
	<48D07F6F.2080901@sun.com>
Message-ID: <48D34FAB.3080208@sun.com>

Ups...

Looks like we have a problem with the implementation.

I have got an exception

Sep 19, 2008 10:59:47 AM sun.awt.X11.XToolkit processException
WARNING: Exception on Toolkit thread
java.lang.ArrayIndexOutOfBoundsException: 24
        at sun.awt.X11.XWindow.handleMotionNotify(XWindow.java:776)
        at sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1083)
        at sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1053)
        at sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:511)
        at sun.awt.X11.XToolkit.run(XToolkit.java:606)
        at sun.awt.X11.XToolkit.run(XToolkit.java:541)
        at java.lang.Thread.run(Thread.java:674)

in the next part of the code

        //this doesn't work for extra buttons because Xsystem is sending 
state==0 for every extra button event.
        // we can't correct it in MouseEvent class as we done it with 
modifiers, because exact type (DRAG|MOVE)
        // should be passed from XWindow.
        //TODO: eliminate it with some other value obtained w/o AWTLock.
        for (int i = 0; i < XToolkit.getNumMouseButtons(); i++){
            // TODO : here is the bug in WM: extra buttons doesn't have 
state!=0 as they should.
            if ((i != 4) && (i != 5)) {
                mouseKeyState = mouseKeyState | (xme.get_state() & 
XConstants.buttonsMask[i]);
            }
        }

Should I file a CR?

Thank you,
              Denis.

Andrei Dmitriev wrote:
> Thanks!
> Oleg Sukhodolsky wrote:
>> Congratulations!!! You have  completed  this project (finally ;)
>>
>> On Tue, Sep 16, 2008 at 12:26 PM,  <andrei.dmitriev at sun.com> wrote:
>>  
>>> Changeset: 3b9a288d7ddb
>>> Author:    dav
>>> Date:      2008-09-16 12:17 +0400
>>> URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3b9a288d7ddb
>>>
>>> 6315717: Support for mouse with multiple scroll wheels and 4 or more 
>>> buttons
>>> Summary: implementation of the more mouse buttons support
>>> Reviewed-by: art, dcherepanov
>>>
>>> ! make/sun/xawt/mapfile-vers
>>> ! src/share/classes/java/awt/Robot.java
>>> ! src/share/classes/java/awt/Toolkit.java
>>> ! src/share/classes/java/awt/doc-files/DesktopProperties.html
>>> ! src/share/classes/java/awt/event/InputEvent.java
>>> ! src/share/classes/java/awt/event/MouseEvent.java
>>> ! src/share/classes/java/awt/peer/RobotPeer.java
>>> ! src/share/classes/sun/awt/HeadlessToolkit.java
>>> ! src/solaris/classes/sun/awt/X11/XBaseWindow.java
>>> ! src/solaris/classes/sun/awt/X11/XConstants.java
>>> ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java
>>> ! src/solaris/classes/sun/awt/X11/XRobotPeer.java
>>> ! src/solaris/classes/sun/awt/X11/XToolkit.java
>>> ! src/solaris/classes/sun/awt/X11/XWindow.java
>>> ! src/solaris/classes/sun/awt/X11/XWindowPeer.java
>>> ! src/solaris/native/sun/awt/awt_Robot.c
>>> ! src/windows/classes/sun/awt/windows/WRobotPeer.java
>>> ! src/windows/classes/sun/awt/windows/WToolkit.java
>>> ! src/windows/native/sun/windows/awt_Component.cpp
>>> ! src/windows/native/sun/windows/awt_Component.h
>>> ! src/windows/native/sun/windows/awt_Robot.cpp
>>> ! src/windows/native/sun/windows/awt_Robot.h
>>> ! src/windows/native/sun/windows/awt_Toolkit.cpp
>>> ! src/windows/native/sun/windows/awt_Toolkit.h
>>> ! src/windows/native/sun/windows/awt_TrayIcon.cpp
>>> + test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java
>>> + test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java
>>> + 
>>> test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java 
>>>
>>> + 
>>> test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java 
>>>
>>> + 
>>> test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java 
>>>
>>> + test/java/awt/Robot/ManualInstructions/ManualInstructions.java
>>> + test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java
>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java
>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java
>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java
>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java
>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java
>>> + 
>>> test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java 
>>>
>>> + 
>>> test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java 
>>>
>>> + 
>>> test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java 
>>>
>>> + 
>>> test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java
>>> + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java
>>> + 
>>> test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java 
>>>
>>> + 
>>> test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java 
>>>
>>>
>>>
>>>     
>



From Artem.Ananiev at Sun.COM  Fri Sep 19 00:42:14 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Fri, 19 Sep 2008 11:42:14 +0400
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6315717: Support for mouse with
 multiple scroll wheels and 4 or more buttons
In-Reply-To: <48D34FAB.3080208@sun.com>
References: <20080916082705.8F184DC93@hg.openjdk.java.net>
	<271e55d20809162040w6e32e9d2qbd6c70491f507599@mail.gmail.com>
	<48D07F6F.2080901@sun.com> <48D34FAB.3080208@sun.com>
Message-ID: <48D357D6.7060600@sun.com>

Yes, please,

Thanks,

Artem

Denis S. Fokin wrote:
> Ups...
> 
> Looks like we have a problem with the implementation.
> 
> I have got an exception
> 
> Sep 19, 2008 10:59:47 AM sun.awt.X11.XToolkit processException
> WARNING: Exception on Toolkit thread
> java.lang.ArrayIndexOutOfBoundsException: 24
>        at sun.awt.X11.XWindow.handleMotionNotify(XWindow.java:776)
>        at sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1083)
>        at sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1053)
>        at sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:511)
>        at sun.awt.X11.XToolkit.run(XToolkit.java:606)
>        at sun.awt.X11.XToolkit.run(XToolkit.java:541)
>        at java.lang.Thread.run(Thread.java:674)
> 
> in the next part of the code
> 
>        //this doesn't work for extra buttons because Xsystem is sending 
> state==0 for every extra button event.
>        // we can't correct it in MouseEvent class as we done it with 
> modifiers, because exact type (DRAG|MOVE)
>        // should be passed from XWindow.
>        //TODO: eliminate it with some other value obtained w/o AWTLock.
>        for (int i = 0; i < XToolkit.getNumMouseButtons(); i++){
>            // TODO : here is the bug in WM: extra buttons doesn't have 
> state!=0 as they should.
>            if ((i != 4) && (i != 5)) {
>                mouseKeyState = mouseKeyState | (xme.get_state() & 
> XConstants.buttonsMask[i]);
>            }
>        }
> 
> Should I file a CR?
> 
> Thank you,
>              Denis.
> 
> Andrei Dmitriev wrote:
>> Thanks!
>> Oleg Sukhodolsky wrote:
>>> Congratulations!!! You have  completed  this project (finally ;)
>>>
>>> On Tue, Sep 16, 2008 at 12:26 PM,  <andrei.dmitriev at sun.com> wrote:
>>>  
>>>> Changeset: 3b9a288d7ddb
>>>> Author:    dav
>>>> Date:      2008-09-16 12:17 +0400
>>>> URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3b9a288d7ddb
>>>>
>>>> 6315717: Support for mouse with multiple scroll wheels and 4 or more 
>>>> buttons
>>>> Summary: implementation of the more mouse buttons support
>>>> Reviewed-by: art, dcherepanov
>>>>
>>>> ! make/sun/xawt/mapfile-vers
>>>> ! src/share/classes/java/awt/Robot.java
>>>> ! src/share/classes/java/awt/Toolkit.java
>>>> ! src/share/classes/java/awt/doc-files/DesktopProperties.html
>>>> ! src/share/classes/java/awt/event/InputEvent.java
>>>> ! src/share/classes/java/awt/event/MouseEvent.java
>>>> ! src/share/classes/java/awt/peer/RobotPeer.java
>>>> ! src/share/classes/sun/awt/HeadlessToolkit.java
>>>> ! src/solaris/classes/sun/awt/X11/XBaseWindow.java
>>>> ! src/solaris/classes/sun/awt/X11/XConstants.java
>>>> ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java
>>>> ! src/solaris/classes/sun/awt/X11/XRobotPeer.java
>>>> ! src/solaris/classes/sun/awt/X11/XToolkit.java
>>>> ! src/solaris/classes/sun/awt/X11/XWindow.java
>>>> ! src/solaris/classes/sun/awt/X11/XWindowPeer.java
>>>> ! src/solaris/native/sun/awt/awt_Robot.c
>>>> ! src/windows/classes/sun/awt/windows/WRobotPeer.java
>>>> ! src/windows/classes/sun/awt/windows/WToolkit.java
>>>> ! src/windows/native/sun/windows/awt_Component.cpp
>>>> ! src/windows/native/sun/windows/awt_Component.h
>>>> ! src/windows/native/sun/windows/awt_Robot.cpp
>>>> ! src/windows/native/sun/windows/awt_Robot.h
>>>> ! src/windows/native/sun/windows/awt_Toolkit.cpp
>>>> ! src/windows/native/sun/windows/awt_Toolkit.h
>>>> ! src/windows/native/sun/windows/awt_TrayIcon.cpp
>>>> + test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java
>>>> + test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java
>>>> + 
>>>> test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java 
>>>>
>>>> + 
>>>> test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java 
>>>>
>>>> + 
>>>> test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java 
>>>>
>>>> + test/java/awt/Robot/ManualInstructions/ManualInstructions.java
>>>> + test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java
>>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java
>>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java
>>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java
>>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java
>>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java
>>>> + 
>>>> test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java 
>>>>
>>>> + 
>>>> test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java 
>>>>
>>>> + 
>>>> test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java 
>>>>
>>>> + 
>>>> test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java
>>>> + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java
>>>> + 
>>>> test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java 
>>>>
>>>> + 
>>>> test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java 
>>>>
>>>>
>>>>
>>>>     
>>
> 


From Artem.Ananiev at Sun.COM  Fri Sep 19 02:01:08 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Fri, 19 Sep 2008 13:01:08 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1221767437.31171.5.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221767437.31171.5.camel@moonlight>
Message-ID: <48D36A54.2060204@sun.com>

Hi, Roman,

I don't see you in the list of people who signed SCA. Your company - 
"aicas GmbH" - only has two members "iproetel" and "rabbit78", which is 
probably due to our SCA list is incomplete, but this should be checked 
first. Have you signed SCA? If yes, please, let us take a day or two to 
resolve this issue.

 From the technical point of view you first need to synchronize your 
OpenJDK workspace with AWT one, because we had a number of fixes there 
which are not integrated into the master workspace yet.

Thanks,

Artem

Roman Kennke wrote:
> Hi Andrei,
> 
>> Anyway, I'm fine with that patch. Approved.
> 
> Cool. So should I commit and push this patch (minus the MComponentPeer
> thing) to the awt-gate? Or do I have to wait for another OK? Does my
> (SSH-level) permission to push to the Cacio-Repos also extend to the
> other gates automatically? Also, I probably need some guidance with the
> exact commit message.
> 
> /Roman
> 


From gnu_andrew at member.fsf.org  Fri Sep 19 02:12:51 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 19 Sep 2008 10:12:51 +0100
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48D36A54.2060204@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight> <48D2327E.8020306@sun.com>
	<1221767437.31171.5.camel@moonlight> <48D36A54.2060204@sun.com>
Message-ID: <17c6771e0809190212k441cfe04nc08fe27fc25930c9@mail.gmail.com>

2008/9/19 Artem Ananiev <Artem.Ananiev at sun.com>:
> Hi, Roman,
>
> I don't see you in the list of people who signed SCA. Your company - "aicas
> GmbH" - only has two members "iproetel" and "rabbit78", which is probably
> due to our SCA list is incomplete, but this should be checked first. Have
> you signed SCA? If yes, please, let us take a day or two to resolve this
> issue.
>
> From the technical point of view you first need to synchronize your OpenJDK
> workspace with AWT one, because we had a number of fixes there which are not
> integrated into the master workspace yet.
>
> Thanks,
>
> Artem
>
> Roman Kennke wrote:
>>
>> Hi Andrei,
>>
>>> Anyway, I'm fine with that patch. Approved.
>>
>> Cool. So should I commit and push this patch (minus the MComponentPeer
>> thing) to the awt-gate? Or do I have to wait for another OK? Does my
>> (SSH-level) permission to push to the Cacio-Repos also extend to the
>> other gates automatically? Also, I probably need some guidance with the
>> exact commit message.
>>
>> /Roman
>>
>

I believe rabbit78 is one of Roman's pseudonyms.
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8


From gnu_andrew at member.fsf.org  Fri Sep 19 02:15:13 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 19 Sep 2008 10:15:13 +0100
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48D36A54.2060204@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight> <48D2327E.8020306@sun.com>
	<1221767437.31171.5.camel@moonlight> <48D36A54.2060204@sun.com>
Message-ID: <17c6771e0809190215v532b7376of55d3dd5a285b7f6@mail.gmail.com>

2008/9/19 Artem Ananiev <Artem.Ananiev at sun.com>:
> Hi, Roman,
>
> I don't see you in the list of people who signed SCA. Your company - "aicas
> GmbH" - only has two members "iproetel" and "rabbit78", which is probably
> due to our SCA list is incomplete, but this should be checked first. Have
> you signed SCA? If yes, please, let us take a day or two to resolve this
> issue.
>
> From the technical point of view you first need to synchronize your OpenJDK
> workspace with AWT one, because we had a number of fixes there which are not
> integrated into the master workspace yet.
>
> Thanks,
>
> Artem
>
> Roman Kennke wrote:
>>
>> Hi Andrei,
>>
>>> Anyway, I'm fine with that patch. Approved.
>>
>> Cool. So should I commit and push this patch (minus the MComponentPeer
>> thing) to the awt-gate? Or do I have to wait for another OK? Does my
>> (SSH-level) permission to push to the Cacio-Repos also extend to the
>> other gates automatically? Also, I probably need some guidance with the
>> exact commit message.
>>
>> /Roman
>>
>

http://savannah.gnu.org/users/rabbit78 :)
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8


From Artem.Ananiev at Sun.COM  Fri Sep 19 02:24:53 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Fri, 19 Sep 2008 13:24:53 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <17c6771e0809190212k441cfe04nc08fe27fc25930c9@mail.gmail.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221767437.31171.5.camel@moonlight>
	<48D36A54.2060204@sun.com>
	<17c6771e0809190212k441cfe04nc08fe27fc25930c9@mail.gmail.com>
Message-ID: <48D36FE5.30002@sun.com>


Andrew John Hughes wrote:
> 2008/9/19 Artem Ananiev <Artem.Ananiev at sun.com>:
>> Hi, Roman,
>>
>> I don't see you in the list of people who signed SCA. Your company - "aicas
>> GmbH" - only has two members "iproetel" and "rabbit78", which is probably
>> due to our SCA list is incomplete, but this should be checked first. Have
>> you signed SCA? If yes, please, let us take a day or two to resolve this
>> issue.
>>
>> From the technical point of view you first need to synchronize your OpenJDK
>> workspace with AWT one, because we had a number of fixes there which are not
>> integrated into the master workspace yet.
>>
>> Thanks,
>>
>> Artem
>>
>> Roman Kennke wrote:
>>> Hi Andrei,
>>>
>>>> Anyway, I'm fine with that patch. Approved.
>>> Cool. So should I commit and push this patch (minus the MComponentPeer
>>> thing) to the awt-gate? Or do I have to wait for another OK? Does my
>>> (SSH-level) permission to push to the Cacio-Repos also extend to the
>>> other gates automatically? Also, I probably need some guidance with the
>>> exact commit message.
>>>
>>> /Roman
>>>
> 
> I believe rabbit78 is one of Roman's pseudonyms.

Oh, I see... Now I need to find out why his OpenJDK username (rkennke) 
differs from SCA signature name rabbit78, and if this may be a problem.

Thanks,

Artem


From roman.kennke at aicas.com  Fri Sep 19 03:06:43 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Fri, 19 Sep 2008 12:06:43 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48D36A54.2060204@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221767437.31171.5.camel@moonlight>
	<48D36A54.2060204@sun.com>
Message-ID: <1221818803.7545.26.camel@moonlight>

Hi Artem,

> I don't see you in the list of people who signed SCA. Your company - 
> "aicas GmbH" - only has two members "iproetel" and "rabbit78", which is 
> probably due to our SCA list is incomplete, but this should be checked 
> first.

I am rabbit78, this is my java.net login. I also signed the SCA as
individual though. I received an email on August, 8th from Jonathan
Gibbons saying:

<< Your SCA has been reviewed and accepted. >>

It's probably been forgotten to put on the list.

>  From the technical point of view you first need to synchronize your 
> OpenJDK workspace with AWT one, because we had a number of fixes there 
> which are not integrated into the master workspace yet.

Yeah, I'll do that right now.

Thanks, Roman
 
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From Andrei.Dmitriev at Sun.COM  Fri Sep 19 05:14:59 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Fri, 19 Sep 2008 16:14:59 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1221735554.6609.16.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221735554.6609.16.camel@moonlight>
Message-ID: <48D397C3.8060604@sun.com>

Hi folks,
>>
>> 1) Just curious if the concrete peer code are supposed to be changed? 
>> Looking on XTextFieldPeer we may notice something like that:
>>
>>      /**
>>       * DEPRECATED
>>       * @see java.awt.peer.TextFieldPeer
>>       */
>>      public Dimension preferredSize(int cols) {
>>          return getPreferredSize(cols);
>>      }
>>
>>      public Dimension getPreferredSize() {
>>          return xtext.getPreferredSize();
>>      }
>>
>> With this patch applied we aren't obliged anymore to support that stuff, 
>> right?
> 
> Yeah sure. I reviewed all the existing implementations and they should
> not break, but a lot of stuff could be removed.
Just appeared to public access:
http://bugs.sun.com/view_bug.do?bug_id=6749920

Thanks,
   Andrei



From roman.kennke at aicas.com  Fri Sep 19 06:56:04 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Fri, 19 Sep 2008 15:56:04 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48D397C3.8060604@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221735554.6609.16.camel@moonlight>
	<48D397C3.8060604@sun.com>
Message-ID: <1221832564.983.7.camel@moonlight>

Hi Andrei,

> > Yeah sure. I reviewed all the existing implementations and they should
> > not break, but a lot of stuff could be removed.
> Just appeared to public access:
> http://bugs.sun.com/view_bug.do?bug_id=6749920

Cool. BTW, I have another patch for the peer interfaces in the Cacio
repo, that one adds API docs to all the interfaces. Nothing serious,
only roughly what it does (this might be obvious by the method names
anyway) and pointers to where it is used in AWT (I found this important
for implementing the peers, so that people can look up the nitty gritty
details themselves). In the projects I was involved in so far we had
policies to separate code changes from doc and formatting changes, but I
don't know how this is handled in OpenJDK. Maybe we want to push these
together. Find this doc patch attached (this follows up on the
cleanpeers patch, will not apply on clean OpenJDK!)

Cheers, Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: docpeers.txt
Type: text/x-patch
Size: 66431 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080919/0c4fcf0a/attachment.bin 

From Andrei.Dmitriev at Sun.COM  Fri Sep 19 07:02:26 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Fri, 19 Sep 2008 18:02:26 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1221832564.983.7.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221735554.6609.16.camel@moonlight>
	<48D397C3.8060604@sun.com> <1221832564.983.7.camel@moonlight>
Message-ID: <48D3B0F2.6030605@sun.com>

Hi,

I found that reasonable since the very first time evaluated the cacio 
code. Though this patch probably requires more time to get reviewed...

Thanks,
   Andrei

Roman Kennke wrote:
> Hi Andrei,
> 
>>> Yeah sure. I reviewed all the existing implementations and they should
>>> not break, but a lot of stuff could be removed.
>> Just appeared to public access:
>> http://bugs.sun.com/view_bug.do?bug_id=6749920
> 
> Cool. BTW, I have another patch for the peer interfaces in the Cacio
> repo, that one adds API docs to all the interfaces. Nothing serious,
> only roughly what it does (this might be obvious by the method names
> anyway) and pointers to where it is used in AWT (I found this important
> for implementing the peers, so that people can look up the nitty gritty
> details themselves). In the projects I was involved in so far we had
> policies to separate code changes from doc and formatting changes, but I
> don't know how this is handled in OpenJDK. Maybe we want to push these
> together. Find this doc patch attached (this follows up on the
> cleanpeers patch, will not apply on clean OpenJDK!)
> 
> Cheers, Roman
> 
> 


From roman.kennke at aicas.com  Fri Sep 19 07:08:38 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Fri, 19 Sep 2008 16:08:38 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48D3B0F2.6030605@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221735554.6609.16.camel@moonlight>
	<48D397C3.8060604@sun.com> <1221832564.983.7.camel@moonlight>
	<48D3B0F2.6030605@sun.com>
Message-ID: <1221833318.21961.0.camel@moonlight>

Hi,


> I found that reasonable since the very first time evaluated the cacio 
> code. Though this patch probably requires more time to get reviewed...

So? We do it in a separate review&push or we put both (the peer cleanup
and the documentation) together?

/Roman

> 
> Thanks,
>    Andrei
> 
> Roman Kennke wrote:
> > Hi Andrei,
> > 
> >>> Yeah sure. I reviewed all the existing implementations and they should
> >>> not break, but a lot of stuff could be removed.
> >> Just appeared to public access:
> >> http://bugs.sun.com/view_bug.do?bug_id=6749920
> > 
> > Cool. BTW, I have another patch for the peer interfaces in the Cacio
> > repo, that one adds API docs to all the interfaces. Nothing serious,
> > only roughly what it does (this might be obvious by the method names
> > anyway) and pointers to where it is used in AWT (I found this important
> > for implementing the peers, so that people can look up the nitty gritty
> > details themselves). In the projects I was involved in so far we had
> > policies to separate code changes from doc and formatting changes, but I
> > don't know how this is handled in OpenJDK. Maybe we want to push these
> > together. Find this doc patch attached (this follows up on the
> > cleanpeers patch, will not apply on clean OpenJDK!)
> > 
> > Cheers, Roman
> > 
> > 
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From Andrei.Dmitriev at Sun.COM  Fri Sep 19 07:22:00 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Fri, 19 Sep 2008 18:22:00 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1221833318.21961.0.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221735554.6609.16.camel@moonlight>
	<48D397C3.8060604@sun.com> <1221832564.983.7.camel@moonlight>
	<48D3B0F2.6030605@sun.com> <1221833318.21961.0.camel@moonlight>
Message-ID: <48D3B588.5090802@sun.com>

I'd like to see them separated as we are in the process of reviewing 
the peers cleanup already.
   Andrei

Roman Kennke wrote:
> Hi,
> 
> 
>> I found that reasonable since the very first time evaluated the cacio 
>> code. Though this patch probably requires more time to get reviewed...
> 
> So? We do it in a separate review&push or we put both (the peer cleanup
> and the documentation) together?
> 
> /Roman
> 
>> Thanks,
>>    Andrei
>>
>> Roman Kennke wrote:
>>> Hi Andrei,
>>>
>>>>> Yeah sure. I reviewed all the existing implementations and they should
>>>>> not break, but a lot of stuff could be removed.
>>>> Just appeared to public access:
>>>> http://bugs.sun.com/view_bug.do?bug_id=6749920
>>> Cool. BTW, I have another patch for the peer interfaces in the Cacio
>>> repo, that one adds API docs to all the interfaces. Nothing serious,
>>> only roughly what it does (this might be obvious by the method names
>>> anyway) and pointers to where it is used in AWT (I found this important
>>> for implementing the peers, so that people can look up the nitty gritty
>>> details themselves). In the projects I was involved in so far we had
>>> policies to separate code changes from doc and formatting changes, but I
>>> don't know how this is handled in OpenJDK. Maybe we want to push these
>>> together. Find this doc patch attached (this follows up on the
>>> cleanpeers patch, will not apply on clean OpenJDK!)
>>>
>>> Cheers, Roman
>>>
>>>


From Andrei.Dmitriev at Sun.COM  Fri Sep 19 07:27:18 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Fri, 19 Sep 2008 18:27:18 +0400
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6315717: Support for mouse with
 multiple scroll wheels and 4 or more buttons
In-Reply-To: <48D357D6.7060600@sun.com>
References: <20080916082705.8F184DC93@hg.openjdk.java.net>
	<271e55d20809162040w6e32e9d2qbd6c70491f507599@mail.gmail.com>
	<48D07F6F.2080901@sun.com> <48D34FAB.3080208@sun.com>
	<48D357D6.7060600@sun.com>
Message-ID: <48D3B6C6.5010005@sun.com>

Thanks for catching that!
We got it, keep track on CR 6750288. Guys outside, as usual, you are 
having a 24h timeout... the system is sneezing updating the web view. :(
Initial evaluation is like this: that's because the X decided that its 
mouse has 32 buttons though I thought X standard mentions 24 as the 
maximum.
Anyway, we predict a lot of people has similar environments. Attempt to 
address this issue with using long type instead of int sounds safe enough.
Thanks,
   Andrei

Artem Ananiev wrote:
> Yes, please,
> 
> Thanks,
> 
> Artem
> 
> Denis S. Fokin wrote:
>> Ups...
>>
>> Looks like we have a problem with the implementation.
>>
>> I have got an exception
>>
>> Sep 19, 2008 10:59:47 AM sun.awt.X11.XToolkit processException
>> WARNING: Exception on Toolkit thread
>> java.lang.ArrayIndexOutOfBoundsException: 24
>>        at sun.awt.X11.XWindow.handleMotionNotify(XWindow.java:776)
>>        at sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1083)
>>        at sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1053)
>>        at sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:511)
>>        at sun.awt.X11.XToolkit.run(XToolkit.java:606)
>>        at sun.awt.X11.XToolkit.run(XToolkit.java:541)
>>        at java.lang.Thread.run(Thread.java:674)
>>
>> in the next part of the code
>>
>>        //this doesn't work for extra buttons because Xsystem is 
>> sending state==0 for every extra button event.
>>        // we can't correct it in MouseEvent class as we done it with 
>> modifiers, because exact type (DRAG|MOVE)
>>        // should be passed from XWindow.
>>        //TODO: eliminate it with some other value obtained w/o AWTLock.
>>        for (int i = 0; i < XToolkit.getNumMouseButtons(); i++){
>>            // TODO : here is the bug in WM: extra buttons doesn't have 
>> state!=0 as they should.
>>            if ((i != 4) && (i != 5)) {
>>                mouseKeyState = mouseKeyState | (xme.get_state() & 
>> XConstants.buttonsMask[i]);
>>            }
>>        }
>>
>> Should I file a CR?
>>
>> Thank you,
>>              Denis.
>>
>> Andrei Dmitriev wrote:
>>> Thanks!
>>> Oleg Sukhodolsky wrote:
>>>> Congratulations!!! You have  completed  this project (finally ;)
>>>>
>>>> On Tue, Sep 16, 2008 at 12:26 PM,  <andrei.dmitriev at sun.com> wrote:
>>>>  
>>>>> Changeset: 3b9a288d7ddb
>>>>> Author:    dav
>>>>> Date:      2008-09-16 12:17 +0400
>>>>> URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3b9a288d7ddb
>>>>>
>>>>> 6315717: Support for mouse with multiple scroll wheels and 4 or 
>>>>> more buttons
>>>>> Summary: implementation of the more mouse buttons support
>>>>> Reviewed-by: art, dcherepanov
>>>>>
>>>>> ! make/sun/xawt/mapfile-vers
>>>>> ! src/share/classes/java/awt/Robot.java
>>>>> ! src/share/classes/java/awt/Toolkit.java
>>>>> ! src/share/classes/java/awt/doc-files/DesktopProperties.html
>>>>> ! src/share/classes/java/awt/event/InputEvent.java
>>>>> ! src/share/classes/java/awt/event/MouseEvent.java
>>>>> ! src/share/classes/java/awt/peer/RobotPeer.java
>>>>> ! src/share/classes/sun/awt/HeadlessToolkit.java
>>>>> ! src/solaris/classes/sun/awt/X11/XBaseWindow.java
>>>>> ! src/solaris/classes/sun/awt/X11/XConstants.java
>>>>> ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java
>>>>> ! src/solaris/classes/sun/awt/X11/XRobotPeer.java
>>>>> ! src/solaris/classes/sun/awt/X11/XToolkit.java
>>>>> ! src/solaris/classes/sun/awt/X11/XWindow.java
>>>>> ! src/solaris/classes/sun/awt/X11/XWindowPeer.java
>>>>> ! src/solaris/native/sun/awt/awt_Robot.c
>>>>> ! src/windows/classes/sun/awt/windows/WRobotPeer.java
>>>>> ! src/windows/classes/sun/awt/windows/WToolkit.java
>>>>> ! src/windows/native/sun/windows/awt_Component.cpp
>>>>> ! src/windows/native/sun/windows/awt_Component.h
>>>>> ! src/windows/native/sun/windows/awt_Robot.cpp
>>>>> ! src/windows/native/sun/windows/awt_Robot.h
>>>>> ! src/windows/native/sun/windows/awt_Toolkit.cpp
>>>>> ! src/windows/native/sun/windows/awt_Toolkit.h
>>>>> ! src/windows/native/sun/windows/awt_TrayIcon.cpp
>>>>> + test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java
>>>>> + test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java
>>>>> + 
>>>>> test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java 
>>>>>
>>>>> + 
>>>>> test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java 
>>>>>
>>>>> + 
>>>>> test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java 
>>>>>
>>>>> + test/java/awt/Robot/ManualInstructions/ManualInstructions.java
>>>>> + test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java
>>>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java
>>>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java
>>>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java
>>>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java
>>>>> + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java
>>>>> + 
>>>>> test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java 
>>>>>
>>>>> + 
>>>>> test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java 
>>>>>
>>>>> + 
>>>>> test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java 
>>>>>
>>>>> + 
>>>>> test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java 
>>>>>
>>>>> + 
>>>>> test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java
>>>>> + 
>>>>> test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java 
>>>>>
>>>>> + 
>>>>> test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java 
>>>>>
>>>>>
>>>>>
>>>>>     
>>>
>>


From mario.torre at aicas.com  Fri Sep 19 09:00:42 2008
From: mario.torre at aicas.com (Mario Torre)
Date: Fri, 19 Sep 2008 18:00:42 +0200
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6315717: Support for mouse
	with	multiple scroll wheels and 4 or more buttons
In-Reply-To: <48D3B6C6.5010005@sun.com>
References: <20080916082705.8F184DC93@hg.openjdk.java.net>
	<271e55d20809162040w6e32e9d2qbd6c70491f507599@mail.gmail.com>
	<48D07F6F.2080901@sun.com> <48D34FAB.3080208@sun.com>
	<48D357D6.7060600@sun.com>  <48D3B6C6.5010005@sun.com>
Message-ID: <1221840042.26154.56.camel@lou.aicas.burg>


On Fri, 2008-09-19 at 18:27 +0400, Andrei V. Dmitriev wrote:
> Thanks for catching that!
> We got it, keep track on CR 6750288. Guys outside, as usual, you are 
> having a 24h timeout... the system is sneezing updating the web view. :(
> Initial evaluation is like this: that's because the X decided that its 
> mouse has 32 buttons though I thought X standard mentions 24 as the 
> maximum.
> Anyway, we predict a lot of people has similar environments. Attempt to 
> address this issue with using long type instead of int sounds safe enough.
> Thanks,
>    Andrei

How many buttons and scroll wheels do yo have on your mouse??? :)

Cheers,
Mario
-- 
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-53
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Gesch?ftsf?hrer: Dr. James J. Hunt

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/



From Denis.Fokin at Sun.COM  Mon Sep 22 03:18:32 2008
From: Denis.Fokin at Sun.COM (Denis Fokin)
Date: Mon, 22 Sep 2008 14:18:32 +0400
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6315717: Support for
	mouse	with	multiple scroll wheels and 4 or more buttons
In-Reply-To: <1221840042.26154.56.camel@lou.aicas.burg>
References: <20080916082705.8F184DC93@hg.openjdk.java.net>
	<271e55d20809162040w6e32e9d2qbd6c70491f507599@mail.gmail.com>
	<48D07F6F.2080901@sun.com> <48D34FAB.3080208@sun.com>
	<48D357D6.7060600@sun.com> <48D3B6C6.5010005@sun.com>
	<1221840042.26154.56.camel@lou.aicas.burg>
Message-ID: <48D770F8.1000909@sun.com>

Hi Mario,

two buttons + wheel

--
Denis

Mario Torre wrote:
> On Fri, 2008-09-19 at 18:27 +0400, Andrei V. Dmitriev wrote:
>   
>> Thanks for catching that!
>> We got it, keep track on CR 6750288. Guys outside, as usual, you are 
>> having a 24h timeout... the system is sneezing updating the web view. :(
>> Initial evaluation is like this: that's because the X decided that its 
>> mouse has 32 buttons though I thought X standard mentions 24 as the 
>> maximum.
>> Anyway, we predict a lot of people has similar environments. Attempt to 
>> address this issue with using long type instead of int sounds safe enough.
>> Thanks,
>>    Andrei
>>     
>
> How many buttons and scroll wheels do yo have on your mouse??? :)
>
> Cheers,
> Mario
>   



From Artem.Ananiev at Sun.COM  Wed Sep 24 02:52:05 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Wed, 24 Sep 2008 13:52:05 +0400
Subject: <AWT Dev> EventQueue changes
In-Reply-To: <271e55d20809171123p1b2399ddg35559e3aa136a909@mail.gmail.com>
References: <48C6644D.2020504@sun.com>
	<271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>
	<48C8D259.8040809@sun.com>
	<271e55d20809150012g586b08bbu380d53cab2982dca@mail.gmail.com>
	<48CF7667.408@sun.com>
	<271e55d20809171123p1b2399ddg35559e3aa136a909@mail.gmail.com>
Message-ID: <48DA0DC5.2030605@sun.com>


Oleg Sukhodolsky wrote:
> On Tue, Sep 16, 2008 at 1:03 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>> Oleg Sukhodolsky wrote:
>>>> 3. pumpEvents() API is made public, probably with some minor changes.
>>> what use cases you want to address by this new API?
>> There are several tens of votes for all the related bugs. One more argument
>> is that all the modern toolkits (Win32, GTK, SWT) have this API implemented,
>> while AWT/Swing still misses it.
>>
>> I also constantly face with scenarios, when some developer needs to start a
>> nested event pump and use a modal dialog for this, which looks quite ugly
>> and unstable.
> 
> What kind of scenarios do you mean?

I'm currently aware of at least 3 requests for this functionality: from 
NetBeans team, from JWebPane team and from JavaWebStart/deploment team. 
In general, in every application with multiple AppContexts controllable 
event pump is required to implement cross-AppContext synchronous calls 
(like COM).

Thanks,

Artem

> Thanks, Oleg.
>> Thanks,
>>
>> Artem
>>
>>> Regards, Oleg.
>>>
>>> On Thu, Sep 11, 2008 at 12:10 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>>> wrote:
>>>> Hi, Oleg,
>>>>
>>>> Oleg Sukhodolsky wrote:
>>>>> On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>>>>> wrote:
>>>>>> Hi, AWT team,
>>>>>>
>>>>>> there are several issues related to EventQueue class with a long
>>>>>> history.
>>>>>> The number of user votes constantly grows, so I think it would be fine
>>>>>> if
>>>>>> we
>>>>>> can get them fixed in some nearest future.
>>>>>>
>>>>>> The list of bugs include (but not limited to):
>>>>>>
>>>>>> 6424157: java.awt.EventQueue push/pop might cause threading issues
>>>>>>
>>>>>> 6542185: Threading issues with java.awt.EventQueue.push/pop
>>>>>> (closed as not a defect, but some of described problems still exist)
>>>>>>
>>>>>> 4913324: Deadlock when using two event queues.
>>>>>>
>>>>>> 4516924: Request public access to pumpEvents(Conditional) type
>>>>>> functionality.
>>>>>>
>>>>>> 6727884: Some Uncaught Exceptions are no longer getting sent to the
>>>>>> Uncaught
>>>>>> Exception Handlers
>>>>>>
>>>>>> Some of the described problems don't look related to each other,
>>>>>> however
>>>>>> after a closer look I found they really do. That's why I listed them
>>>>>> here
>>>>>> altogether, and would like to discuss some possible improvements:
>>>>>>
>>>>>> 1. Synchronization changes. Most of the problems with push/pop are
>>>>>> caused
>>>>>> by
>>>>>> imperfect synchronization in EventQueue. Currently, all the actions
>>>>>> like
>>>>>> postEvent() or getNextEvent() are transferred back and forth in the
>>>>>> stack
>>>>>> of
>>>>>> event queues, and each queue is accessed in its 'synchronized' block.
>>>>>> Instead, a single lock looks more correct here.
>>>>>>
>>>>>> 2. EventDispatchThread lifecycle. It is a known fact, that event
>>>>>> dispatch
>>>>>> thread may die for some reason (for example, because of unhandled
>>>>>> exception). When a new event comes, new EDT is created. Another case
>>>>>> when
>>>>>> EDT is switched is push/pop methods: when a new EQ is pushed/popped, a
>>>>>> new
>>>>>> EDT is created.
>>>>>>
>>>>>> I'm sure these changes of current dispatch thread is not what
>>>>>> developers
>>>>>> expect. Swing is considered as single-threaded toolkit, but it is
>>>>>> really
>>>>>> not...
>>>>>>
>>>>>> 3. Controllable event pump. This is what developers have been
>>>>>> requesting
>>>>>> for
>>>>>> at least 8 years. With the current API this task cannot be solved, and
>>>>>> all
>>>>>> the external libs like Foxtrot are really just hacks and depend on JDK
>>>>>> internals.
>>>>>>
>>>>>> From technical point of view, controllable event pump is just a several
>>>>>> lines of code changes: we only need to make public the code which is
>>>>>> used
>>>>>> for modality event pumps.
>>>>>>
>>>>>> ----
>>>>>>
>>>>>> I have a prototype fix with all the three items implemented. Still, it
>>>>>> would
>>>>>> be fine to hear what all AWT developers think about proposed changes.
>>>>> I see list of problems, but do not see list of proposed changes :(
>>>>> Did I miss something?
>>>> You're right, the changes are not included, my fault... Here they are:
>>>>
>>>> 1. A single lock is introduced to handle all the EQ operations like push,
>>>> pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
>>>> several.
>>>>
>>>> 2. EventDispatchThread is reused as much as possible. When a new EQ is
>>>> pushed, it uses the old EDT instead of creating a new one. The same is
>>>> true
>>>> for pop().
>>>>
>>>> 3. pumpEvents() API is made public, probably with some minor changes.
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>>> With best regards, Oleg.


From son.two at gmail.com  Wed Sep 24 06:44:53 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Wed, 24 Sep 2008 17:44:53 +0400
Subject: <AWT Dev> EventQueue changes
In-Reply-To: <48DA0DC5.2030605@sun.com>
References: <48C6644D.2020504@sun.com>
	<271e55d20809091057t622803a4q12f7bb77862f43a8@mail.gmail.com>
	<48C8D259.8040809@sun.com>
	<271e55d20809150012g586b08bbu380d53cab2982dca@mail.gmail.com>
	<48CF7667.408@sun.com>
	<271e55d20809171123p1b2399ddg35559e3aa136a909@mail.gmail.com>
	<48DA0DC5.2030605@sun.com>
Message-ID: <271e55d20809240644x15e4121atd2a583a1034c7bf@mail.gmail.com>

On Wed, Sep 24, 2008 at 1:52 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>
> Oleg Sukhodolsky wrote:
>>
>> On Tue, Sep 16, 2008 at 1:03 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>> wrote:
>>>
>>> Oleg Sukhodolsky wrote:
>>>>>
>>>>> 3. pumpEvents() API is made public, probably with some minor changes.
>>>>
>>>> what use cases you want to address by this new API?
>>>
>>> There are several tens of votes for all the related bugs. One more
>>> argument
>>> is that all the modern toolkits (Win32, GTK, SWT) have this API
>>> implemented,
>>> while AWT/Swing still misses it.
>>>
>>> I also constantly face with scenarios, when some developer needs to start
>>> a
>>> nested event pump and use a modal dialog for this, which looks quite ugly
>>> and unstable.
>>
>> What kind of scenarios do you mean?
>
> I'm currently aware of at least 3 requests for this functionality: from
> NetBeans team, from JWebPane team and from JavaWebStart/deploment team. In
> general, in every application with multiple AppContexts controllable event
> pump is required to implement cross-AppContext synchronous calls (like COM).

You know, there is public API for AppContext, so why you want to add
Public API to work with them? ;)
IMHO people who works with AppContexts directly can use private API
for controlled message processing.

Oleg.

>
> Thanks,
>
> Artem
>
>> Thanks, Oleg.
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>>> Regards, Oleg.
>>>>
>>>> On Thu, Sep 11, 2008 at 12:10 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>>>> wrote:
>>>>>
>>>>> Hi, Oleg,
>>>>>
>>>>> Oleg Sukhodolsky wrote:
>>>>>>
>>>>>> On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi, AWT team,
>>>>>>>
>>>>>>> there are several issues related to EventQueue class with a long
>>>>>>> history.
>>>>>>> The number of user votes constantly grows, so I think it would be
>>>>>>> fine
>>>>>>> if
>>>>>>> we
>>>>>>> can get them fixed in some nearest future.
>>>>>>>
>>>>>>> The list of bugs include (but not limited to):
>>>>>>>
>>>>>>> 6424157: java.awt.EventQueue push/pop might cause threading issues
>>>>>>>
>>>>>>> 6542185: Threading issues with java.awt.EventQueue.push/pop
>>>>>>> (closed as not a defect, but some of described problems still exist)
>>>>>>>
>>>>>>> 4913324: Deadlock when using two event queues.
>>>>>>>
>>>>>>> 4516924: Request public access to pumpEvents(Conditional) type
>>>>>>> functionality.
>>>>>>>
>>>>>>> 6727884: Some Uncaught Exceptions are no longer getting sent to the
>>>>>>> Uncaught
>>>>>>> Exception Handlers
>>>>>>>
>>>>>>> Some of the described problems don't look related to each other,
>>>>>>> however
>>>>>>> after a closer look I found they really do. That's why I listed them
>>>>>>> here
>>>>>>> altogether, and would like to discuss some possible improvements:
>>>>>>>
>>>>>>> 1. Synchronization changes. Most of the problems with push/pop are
>>>>>>> caused
>>>>>>> by
>>>>>>> imperfect synchronization in EventQueue. Currently, all the actions
>>>>>>> like
>>>>>>> postEvent() or getNextEvent() are transferred back and forth in the
>>>>>>> stack
>>>>>>> of
>>>>>>> event queues, and each queue is accessed in its 'synchronized' block.
>>>>>>> Instead, a single lock looks more correct here.
>>>>>>>
>>>>>>> 2. EventDispatchThread lifecycle. It is a known fact, that event
>>>>>>> dispatch
>>>>>>> thread may die for some reason (for example, because of unhandled
>>>>>>> exception). When a new event comes, new EDT is created. Another case
>>>>>>> when
>>>>>>> EDT is switched is push/pop methods: when a new EQ is pushed/popped,
>>>>>>> a
>>>>>>> new
>>>>>>> EDT is created.
>>>>>>>
>>>>>>> I'm sure these changes of current dispatch thread is not what
>>>>>>> developers
>>>>>>> expect. Swing is considered as single-threaded toolkit, but it is
>>>>>>> really
>>>>>>> not...
>>>>>>>
>>>>>>> 3. Controllable event pump. This is what developers have been
>>>>>>> requesting
>>>>>>> for
>>>>>>> at least 8 years. With the current API this task cannot be solved,
>>>>>>> and
>>>>>>> all
>>>>>>> the external libs like Foxtrot are really just hacks and depend on
>>>>>>> JDK
>>>>>>> internals.
>>>>>>>
>>>>>>> From technical point of view, controllable event pump is just a
>>>>>>> several
>>>>>>> lines of code changes: we only need to make public the code which is
>>>>>>> used
>>>>>>> for modality event pumps.
>>>>>>>
>>>>>>> ----
>>>>>>>
>>>>>>> I have a prototype fix with all the three items implemented. Still,
>>>>>>> it
>>>>>>> would
>>>>>>> be fine to hear what all AWT developers think about proposed changes.
>>>>>>
>>>>>> I see list of problems, but do not see list of proposed changes :(
>>>>>> Did I miss something?
>>>>>
>>>>> You're right, the changes are not included, my fault... Here they are:
>>>>>
>>>>> 1. A single lock is introduced to handle all the EQ operations like
>>>>> push,
>>>>> pop, getNextEvent, etc. instead of locking all EQ objects one by one,
>>>>> if
>>>>> several.
>>>>>
>>>>> 2. EventDispatchThread is reused as much as possible. When a new EQ is
>>>>> pushed, it uses the old EDT instead of creating a new one. The same is
>>>>> true
>>>>> for pop().
>>>>>
>>>>> 3. pumpEvents() API is made public, probably with some minor changes.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>>> With best regards, Oleg.
>


From andrei.dmitriev at sun.com  Mon Sep 29 04:15:42 2008
From: andrei.dmitriev at sun.com (andrei.dmitriev at sun.com)
Date: Mon, 29 Sep 2008 11:15:42 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6746212: Broken MouseEvents for TrayIcon
Message-ID: <20080929111553.ADA53D647@hg.openjdk.java.net>

Changeset: 7e0533679ea1
Author:    dav
Date:      2008-09-29 14:54 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/7e0533679ea1

6746212: Broken MouseEvents for TrayIcon
Reviewed-by: dcherepanov, art

! src/windows/native/sun/windows/awt_TrayIcon.cpp



From Artem.Ananiev at Sun.COM  Mon Sep 29 07:48:02 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Mon, 29 Sep 2008 18:48:02 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48D36FE5.30002@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221767437.31171.5.camel@moonlight>
	<48D36A54.2060204@sun.com>
	<17c6771e0809190212k441cfe04nc08fe27fc25930c9@mail.gmail.com>
	<48D36FE5.30002@sun.com>
Message-ID: <48E0EAA2.6020206@sun.com>

Hi, Roman,

the issue with SCA/OpenJDK user names (see email below) is resolved, so 
you can push your changes into awt-gate workspace. Note, we decided to 
push the docs change in a separate patch (and it is still in progress, 
as far as I see).

Thanks,

Artem

Artem Ananiev wrote:
> 
> Andrew John Hughes wrote:
>> 2008/9/19 Artem Ananiev <Artem.Ananiev at sun.com>:
>>> Hi, Roman,
>>>
>>> I don't see you in the list of people who signed SCA. Your company - 
>>> "aicas
>>> GmbH" - only has two members "iproetel" and "rabbit78", which is 
>>> probably
>>> due to our SCA list is incomplete, but this should be checked first. 
>>> Have
>>> you signed SCA? If yes, please, let us take a day or two to resolve this
>>> issue.
>>>
>>> From the technical point of view you first need to synchronize your 
>>> OpenJDK
>>> workspace with AWT one, because we had a number of fixes there which 
>>> are not
>>> integrated into the master workspace yet.
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>> Roman Kennke wrote:
>>>> Hi Andrei,
>>>>
>>>>> Anyway, I'm fine with that patch. Approved.
>>>> Cool. So should I commit and push this patch (minus the MComponentPeer
>>>> thing) to the awt-gate? Or do I have to wait for another OK? Does my
>>>> (SSH-level) permission to push to the Cacio-Repos also extend to the
>>>> other gates automatically? Also, I probably need some guidance with the
>>>> exact commit message.
>>>>
>>>> /Roman
>>>>
>>
>> I believe rabbit78 is one of Roman's pseudonyms.
> 
> Oh, I see... Now I need to find out why his OpenJDK username (rkennke) 
> differs from SCA signature name rabbit78, and if this may be a problem.
> 
> Thanks,
> 
> Artem


From Andrei.Dmitriev at Sun.COM  Mon Sep 29 07:56:35 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Mon, 29 Sep 2008 18:56:35 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48E0EAA2.6020206@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221767437.31171.5.camel@moonlight>
	<48D36A54.2060204@sun.com>
	<17c6771e0809190212k441cfe04nc08fe27fc25930c9@mail.gmail.com>
	<48D36FE5.30002@sun.com> <48E0EAA2.6020206@sun.com>
Message-ID: <48E0ECA3.5050404@sun.com>

Artem Ananiev wrote:
> Hi, Roman,
> 
> the issue with SCA/OpenJDK user names (see email below) is resolved, so 
> you can push your changes into awt-gate workspace. Note, we decided to 
> push the docs change in a separate patch (and it is still in progress, 
> as far as I see).
Confirmed!

And GL, Roman! :)
   Andrei

> 
> Thanks,
> 
> Artem
> 
> Artem Ananiev wrote:
>>
>> Andrew John Hughes wrote:
>>> 2008/9/19 Artem Ananiev <Artem.Ananiev at sun.com>:
>>>> Hi, Roman,
>>>>
>>>> I don't see you in the list of people who signed SCA. Your company - 
>>>> "aicas
>>>> GmbH" - only has two members "iproetel" and "rabbit78", which is 
>>>> probably
>>>> due to our SCA list is incomplete, but this should be checked first. 
>>>> Have
>>>> you signed SCA? If yes, please, let us take a day or two to resolve 
>>>> this
>>>> issue.
>>>>
>>>> From the technical point of view you first need to synchronize your 
>>>> OpenJDK
>>>> workspace with AWT one, because we had a number of fixes there which 
>>>> are not
>>>> integrated into the master workspace yet.
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> Roman Kennke wrote:
>>>>> Hi Andrei,
>>>>>
>>>>>> Anyway, I'm fine with that patch. Approved.
>>>>> Cool. So should I commit and push this patch (minus the MComponentPeer
>>>>> thing) to the awt-gate? Or do I have to wait for another OK? Does my
>>>>> (SSH-level) permission to push to the Cacio-Repos also extend to the
>>>>> other gates automatically? Also, I probably need some guidance with 
>>>>> the
>>>>> exact commit message.
>>>>>
>>>>> /Roman
>>>>>
>>>
>>> I believe rabbit78 is one of Roman's pseudonyms.
>>
>> Oh, I see... Now I need to find out why his OpenJDK username (rkennke) 
>> differs from SCA signature name rabbit78, and if this may be a problem.
>>
>> Thanks,
>>
>> Artem


From roman.kennke at aicas.com  Mon Sep 29 08:56:11 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Mon, 29 Sep 2008 17:56:11 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48E0EAA2.6020206@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221767437.31171.5.camel@moonlight>
	<48D36A54.2060204@sun.com>
	<17c6771e0809190212k441cfe04nc08fe27fc25930c9@mail.gmail.com>
	<48D36FE5.30002@sun.com>  <48E0EAA2.6020206@sun.com>
Message-ID: <1222703771.6815.11.camel@moonlight>

Hi Artem,

> the issue with SCA/OpenJDK user names (see email below) is resolved, so 
> you can push your changes into awt-gate workspace. Note, we decided to 
> push the docs change in a separate patch (and it is still in progress, 
> as far as I see).

Wow cool, my first self-committed patch :-) Ok, I think I still need a
hand for writing the commit message. I propose sth like:

<<
6749920: Cleanup AWT peer interfaces
Reviewed-by: ???
>>

I think Andrei reviewed this patch (somebody else?). What is his
shortname? I think, it would be useful to have a list of AWT group
members and their shortnames somewhere. (This applies to all groups I
suppose..)

Besides that, does that sound ok?

Thanks, Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From martinrb at google.com  Mon Sep 29 09:07:49 2008
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 29 Sep 2008 09:07:49 -0700
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1222703771.6815.11.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight> <48D2327E.8020306@sun.com>
	<1221767437.31171.5.camel@moonlight> <48D36A54.2060204@sun.com>
	<17c6771e0809190212k441cfe04nc08fe27fc25930c9@mail.gmail.com>
	<48D36FE5.30002@sun.com> <48E0EAA2.6020206@sun.com>
	<1222703771.6815.11.camel@moonlight>
Message-ID: <1ccfd1c10809290907g13df9903w65f1804be65cb8aa@mail.gmail.com>

On Mon, Sep 29, 2008 at 08:56, Roman Kennke <roman.kennke at aicas.com> wrote:
> I think, it would be useful to have a list of AWT group
> members and their shortnames somewhere. (This applies to all groups I
> suppose..)

There is a list of all "people"

http://db.openjdk.java.net/people

but I don't know how to get group subsets of this.


From Artem.Ananiev at Sun.COM  Mon Sep 29 09:37:55 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Mon, 29 Sep 2008 20:37:55 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1222703771.6815.11.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221767437.31171.5.camel@moonlight>
	<48D36A54.2060204@sun.com>
	<17c6771e0809190212k441cfe04nc08fe27fc25930c9@mail.gmail.com>
	<48D36FE5.30002@sun.com> <48E0EAA2.6020206@sun.com>
	<1222703771.6815.11.camel@moonlight>
Message-ID: <48E10463.6040802@sun.com>


Roman Kennke wrote:
> Hi Artem,
> 
>> the issue with SCA/OpenJDK user names (see email below) is resolved, so 
>> you can push your changes into awt-gate workspace. Note, we decided to 
>> push the docs change in a separate patch (and it is still in progress, 
>> as far as I see).
> 
> Wow cool, my first self-committed patch :-) Ok, I think I still need a
> hand for writing the commit message. I propose sth like:
> 
> <<
> 6749920: Cleanup AWT peer interfaces
> Reviewed-by: ???

Please, add me (OpenJDK user 'art') and Andrei ('dav') to the list of 
reviewers.

Thanks,

Artem

> I think Andrei reviewed this patch (somebody else?). What is his
> shortname? I think, it would be useful to have a list of AWT group
> members and their shortnames somewhere. (This applies to all groups I
> suppose..)
> 
> Besides that, does that sound ok?
> 
> Thanks, Roman
> 


From roman.kennke at aicas.com  Mon Sep 29 10:10:20 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Mon, 29 Sep 2008 19:10:20 +0200
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <48E10463.6040802@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221767437.31171.5.camel@moonlight>
	<48D36A54.2060204@sun.com>
	<17c6771e0809190212k441cfe04nc08fe27fc25930c9@mail.gmail.com>
	<48D36FE5.30002@sun.com> <48E0EAA2.6020206@sun.com>
	<1222703771.6815.11.camel@moonlight>  <48E10463.6040802@sun.com>
Message-ID: <1222708220.6815.14.camel@moonlight>

Hi again,

> >> the issue with SCA/OpenJDK user names (see email below) is resolved, so 
> >> you can push your changes into awt-gate workspace. Note, we decided to 
> >> push the docs change in a separate patch (and it is still in progress, 
> >> as far as I see).
> > 
> > Wow cool, my first self-committed patch :-) Ok, I think I still need a
> > hand for writing the commit message. I propose sth like:
> > 
> > <<
> > 6749920: Cleanup AWT peer interfaces
> > Reviewed-by: ???
> 
> Please, add me (OpenJDK user 'art') and Andrei ('dav') to the list of 
> reviewers.

Ok, I did. I tried to push and then got this:

remote: Invalid changeset author: Roman Kennke <roman.kennke at aicas.com>

I can rollback and re-do my commit, but what would be a valid changeset
author name?

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From roman at kennke.org  Mon Sep 29 11:19:28 2008
From: roman at kennke.org (roman at kennke.org)
Date: Mon, 29 Sep 2008 18:19:28 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6749920: Cleanup AWT peer interfaces
Message-ID: <20080929181940.814B5D692@hg.openjdk.java.net>

Changeset: 672290c883fd
Author:    rkennke
Date:      2008-09-29 20:16 +0200
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/672290c883fd

6749920: Cleanup AWT peer interfaces
Summary: Remove duplicate and obsolete methods in the AWT peer interfaces.
Reviewed-by: art, dav

! src/share/classes/java/awt/Choice.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java
! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/List.java
! src/share/classes/java/awt/MenuItem.java
! src/share/classes/java/awt/TextArea.java
! src/share/classes/java/awt/TextField.java
! src/share/classes/java/awt/peer/ChoicePeer.java
! src/share/classes/java/awt/peer/ComponentPeer.java
! src/share/classes/java/awt/peer/ContainerPeer.java
! src/share/classes/java/awt/peer/ListPeer.java
! src/share/classes/java/awt/peer/MenuItemPeer.java
! src/share/classes/java/awt/peer/TextAreaPeer.java
! src/share/classes/java/awt/peer/TextComponentPeer.java
! src/share/classes/java/awt/peer/TextFieldPeer.java
! src/share/classes/java/awt/peer/WindowPeer.java



From martinrb at google.com  Mon Sep 29 11:20:15 2008
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 29 Sep 2008 11:20:15 -0700
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1222708220.6815.14.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight> <48D2327E.8020306@sun.com>
	<1221767437.31171.5.camel@moonlight> <48D36A54.2060204@sun.com>
	<17c6771e0809190212k441cfe04nc08fe27fc25930c9@mail.gmail.com>
	<48D36FE5.30002@sun.com> <48E0EAA2.6020206@sun.com>
	<1222703771.6815.11.camel@moonlight> <48E10463.6040802@sun.com>
	<1222708220.6815.14.camel@moonlight>
Message-ID: <1ccfd1c10809291120g6e551edbu752910920d9a8ac7@mail.gmail.com>

On Mon, Sep 29, 2008 at 10:10, Roman Kennke <roman.kennke at aicas.com> wrote:

>> Please, add me (OpenJDK user 'art') and Andrei ('dav') to the list of
>> reviewers.
>
> Ok, I did. I tried to push and then got this:
>
> remote: Invalid changeset author: Roman Kennke <roman.kennke at aicas.com>
>
> I can rollback and re-do my commit, but what would be a valid changeset
> author name?

Use the user names from the people database, e.g.

user:        alanb
Reviewed-by: iris, sherman, chegar


From andrei.dmitriev at sun.com  Mon Sep 29 13:27:05 2008
From: andrei.dmitriev at sun.com (Andrei Dmitriev)
Date: Tue, 30 Sep 2008 00:27:05 +0400
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6749920: Cleanup AWT peer interfaces
In-Reply-To: <20080929181940.814B5D692@hg.openjdk.java.net>
References: <20080929181940.814B5D692@hg.openjdk.java.net>
Message-ID: <48E13A19.5020108@sun.com>

Congrats, Roman!

I'm updating the CR 6749750 (seem you mentioned a little bit another CR 
in a push comment, see). So now the status of that CR is Fix Available.
BTW, seem when pushing a patch for 6749920 we would suggested to provide 
another CR number because duplicate are prohibited.

And thanks for the help!
  Andrei


roman at kennke.org wrote:
> Changeset: 672290c883fd
> Author:    rkennke
> Date:      2008-09-29 20:16 +0200
> URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/672290c883fd
>
> 6749920: Cleanup AWT peer interfaces
> Summary: Remove duplicate and obsolete methods in the AWT peer interfaces.
> Reviewed-by: art, dav
>
> ! src/share/classes/java/awt/Choice.java
> ! src/share/classes/java/awt/Component.java
> ! src/share/classes/java/awt/Container.java
> ! src/share/classes/java/awt/Dialog.java
> ! src/share/classes/java/awt/List.java
> ! src/share/classes/java/awt/MenuItem.java
> ! src/share/classes/java/awt/TextArea.java
> ! src/share/classes/java/awt/TextField.java
> ! src/share/classes/java/awt/peer/ChoicePeer.java
> ! src/share/classes/java/awt/peer/ComponentPeer.java
> ! src/share/classes/java/awt/peer/ContainerPeer.java
> ! src/share/classes/java/awt/peer/ListPeer.java
> ! src/share/classes/java/awt/peer/MenuItemPeer.java
> ! src/share/classes/java/awt/peer/TextAreaPeer.java
> ! src/share/classes/java/awt/peer/TextComponentPeer.java
> ! src/share/classes/java/awt/peer/TextFieldPeer.java
> ! src/share/classes/java/awt/peer/WindowPeer.java
>
>   



From roman at kennke.org  Mon Sep 29 13:35:45 2008
From: roman at kennke.org (Roman Kennke)
Date: Mon, 29 Sep 2008 22:35:45 +0200
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6749920: Cleanup AWT peer	interfaces
In-Reply-To: <48E13A19.5020108@sun.com>
References: <20080929181940.814B5D692@hg.openjdk.java.net>
	<48E13A19.5020108@sun.com>
Message-ID: <1222720545.6815.26.camel@moonlight>

Hi,

> I'm updating the CR 6749750 (seem you mentioned a little bit another CR 
> in a push comment, see).

Whoops. I was just copy+pasting a bug ID I found on this thread. Bad
me :-)

>  So now the status of that CR is Fix Available.

Is it possible for people like me to do anything with the bugs, except
read them and submit comments? I don't see any 'status' select box or
similar.

> BTW, seem when pushing a patch for 6749920 we would suggested to provide 
> another CR number because duplicate are prohibited.

Maybe use the original one 6749750 ? ;-) Sorry for messing things up.

> And thanks for the help!

Thanks for your help!

Cheers, Roman

>   Andrei
> 
> 
> roman at kennke.org wrote:
> > Changeset: 672290c883fd
> > Author:    rkennke
> > Date:      2008-09-29 20:16 +0200
> > URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/672290c883fd
> >
> > 6749920: Cleanup AWT peer interfaces
> > Summary: Remove duplicate and obsolete methods in the AWT peer interfaces.
> > Reviewed-by: art, dav
> >
> > ! src/share/classes/java/awt/Choice.java
> > ! src/share/classes/java/awt/Component.java
> > ! src/share/classes/java/awt/Container.java
> > ! src/share/classes/java/awt/Dialog.java
> > ! src/share/classes/java/awt/List.java
> > ! src/share/classes/java/awt/MenuItem.java
> > ! src/share/classes/java/awt/TextArea.java
> > ! src/share/classes/java/awt/TextField.java
> > ! src/share/classes/java/awt/peer/ChoicePeer.java
> > ! src/share/classes/java/awt/peer/ComponentPeer.java
> > ! src/share/classes/java/awt/peer/ContainerPeer.java
> > ! src/share/classes/java/awt/peer/ListPeer.java
> > ! src/share/classes/java/awt/peer/MenuItemPeer.java
> > ! src/share/classes/java/awt/peer/TextAreaPeer.java
> > ! src/share/classes/java/awt/peer/TextComponentPeer.java
> > ! src/share/classes/java/awt/peer/TextFieldPeer.java
> > ! src/share/classes/java/awt/peer/WindowPeer.java
> >
> >   
> 
-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080929/92a28b6d/attachment.bin 

From andrei.dmitriev at sun.com  Mon Sep 29 13:46:46 2008
From: andrei.dmitriev at sun.com (Andrei Dmitriev)
Date: Tue, 30 Sep 2008 00:46:46 +0400
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6749920: Cleanup AWT peer	interfaces
In-Reply-To: <1222720545.6815.26.camel@moonlight>
References: <20080929181940.814B5D692@hg.openjdk.java.net>
	<48E13A19.5020108@sun.com> <1222720545.6815.26.camel@moonlight>
Message-ID: <48E13EB6.3020909@sun.com>


>>  So now the status of that CR is Fix Available.
>>     
>
> Is it possible for people like me to do anything with the bugs, except
> read them and submit comments? I don't see any 'status' select box or
> similar.
>   
Unfortunately, no, there is no any public access to the bug database yet. :(

>   
>> BTW, seem when pushing a patch for 6749920 we would suggested to provide 
>> another CR number because duplicate are prohibited.
>>     
>
> Maybe use the original one 6749750 ? ;-) Sorry for messing things up.
>   
Never mind, things happens. We'll think on this suggestion. :)

Regards,
  Andrei
>   
>> And thanks for the help!
>>     
>
> Thanks for your help!
>
> Cheers, Roman
>
>   
>>   Andrei
>>
>>
>> roman at kennke.org wrote:
>>     
>>> Changeset: 672290c883fd
>>> Author:    rkennke
>>> Date:      2008-09-29 20:16 +0200
>>> URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/672290c883fd
>>>
>>> 6749920: Cleanup AWT peer interfaces
>>> Summary: Remove duplicate and obsolete methods in the AWT peer interfaces.
>>> Reviewed-by: art, dav
>>>
>>> ! src/share/classes/java/awt/Choice.java
>>> ! src/share/classes/java/awt/Component.java
>>> ! src/share/classes/java/awt/Container.java
>>> ! src/share/classes/java/awt/Dialog.java
>>> ! src/share/classes/java/awt/List.java
>>> ! src/share/classes/java/awt/MenuItem.java
>>> ! src/share/classes/java/awt/TextArea.java
>>> ! src/share/classes/java/awt/TextField.java
>>> ! src/share/classes/java/awt/peer/ChoicePeer.java
>>> ! src/share/classes/java/awt/peer/ComponentPeer.java
>>> ! src/share/classes/java/awt/peer/ContainerPeer.java
>>> ! src/share/classes/java/awt/peer/ListPeer.java
>>> ! src/share/classes/java/awt/peer/MenuItemPeer.java
>>> ! src/share/classes/java/awt/peer/TextAreaPeer.java
>>> ! src/share/classes/java/awt/peer/TextComponentPeer.java
>>> ! src/share/classes/java/awt/peer/TextFieldPeer.java
>>> ! src/share/classes/java/awt/peer/WindowPeer.java
>>>
>>>   
>>>       



From mario.torre at aicas.com  Mon Sep 29 14:13:23 2008
From: mario.torre at aicas.com (Mario Torre)
Date: Mon, 29 Sep 2008 23:13:23 +0200
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6749920: Cleanup AWT	peer	interfaces
In-Reply-To: <1222720545.6815.26.camel@moonlight>
References: <20080929181940.814B5D692@hg.openjdk.java.net>
	<48E13A19.5020108@sun.com>  <1222720545.6815.26.camel@moonlight>
Message-ID: <1222722803.2957.6.camel@nirvana>

Il giorno lun, 29/09/2008 alle 22.35 +0200, Roman Kennke ha scritto:

> Maybe use the original one 6749750 ? ;-) Sorry for messing things up.
> 
> > And thanks for the help!
> 
> Thanks for your help!

Btw, this was a really big step. Thanks to you all for being so
collaborative!

Cheers,
Mario
-- 
?Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-53
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Gesch?ftsf?hrer: Dr. James J. Hunt

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/



From gnu_andrew at member.fsf.org  Mon Sep 29 14:38:57 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 29 Sep 2008 22:38:57 +0100
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6749920: Cleanup AWT peer interfaces
In-Reply-To: <20080929181940.814B5D692@hg.openjdk.java.net>
References: <20080929181940.814B5D692@hg.openjdk.java.net>
Message-ID: <17c6771e0809291438i6dde89f4l7e974ee1bc5ac3c8@mail.gmail.com>

2008/9/29  <roman at kennke.org>:
> Changeset: 672290c883fd
> Author:    rkennke
> Date:      2008-09-29 20:16 +0200
> URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/672290c883fd
>
> 6749920: Cleanup AWT peer interfaces
> Summary: Remove duplicate and obsolete methods in the AWT peer interfaces.
> Reviewed-by: art, dav
>
> ! src/share/classes/java/awt/Choice.java
> ! src/share/classes/java/awt/Component.java
> ! src/share/classes/java/awt/Container.java
> ! src/share/classes/java/awt/Dialog.java
> ! src/share/classes/java/awt/List.java
> ! src/share/classes/java/awt/MenuItem.java
> ! src/share/classes/java/awt/TextArea.java
> ! src/share/classes/java/awt/TextField.java
> ! src/share/classes/java/awt/peer/ChoicePeer.java
> ! src/share/classes/java/awt/peer/ComponentPeer.java
> ! src/share/classes/java/awt/peer/ContainerPeer.java
> ! src/share/classes/java/awt/peer/ListPeer.java
> ! src/share/classes/java/awt/peer/MenuItemPeer.java
> ! src/share/classes/java/awt/peer/TextAreaPeer.java
> ! src/share/classes/java/awt/peer/TextComponentPeer.java
> ! src/share/classes/java/awt/peer/TextFieldPeer.java
> ! src/share/classes/java/awt/peer/WindowPeer.java
>
>


Woo! Is that the first external author on a JDK7 changeset?
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From mario.torre at aicas.com  Mon Sep 29 14:48:06 2008
From: mario.torre at aicas.com (Mario Torre)
Date: Mon, 29 Sep 2008 23:48:06 +0200
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6749920: Cleanup AWT peer	interfaces
In-Reply-To: <17c6771e0809291438i6dde89f4l7e974ee1bc5ac3c8@mail.gmail.com>
References: <20080929181940.814B5D692@hg.openjdk.java.net>
	<17c6771e0809291438i6dde89f4l7e974ee1bc5ac3c8@mail.gmail.com>
Message-ID: <1222724886.2957.14.camel@nirvana>

Il giorno lun, 29/09/2008 alle 22.38 +0100, Andrew John Hughes ha
scritto:

> Woo! Is that the first external author on a JDK7 changeset?

In fact I think is the second, Martin Buchholz was the first.

But I think it's indeed a very big step, because the process was very
open at some point, I expect this to be better and better as the time
pass.

Cheers,
Mario
-- 
?Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-53
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Gesch?ftsf?hrer: Dr. James J. Hunt

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/



From Artem.Ananiev at Sun.COM  Tue Sep 30 00:34:01 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Tue, 30 Sep 2008 11:34:01 +0400
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1222708220.6815.14.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221767437.31171.5.camel@moonlight>
	<48D36A54.2060204@sun.com>
	<17c6771e0809190212k441cfe04nc08fe27fc25930c9@mail.gmail.com>
	<48D36FE5.30002@sun.com> <48E0EAA2.6020206@sun.com>
	<1222703771.6815.11.camel@moonlight> <48E10463.6040802@sun.com>
	<1222708220.6815.14.camel@moonlight>
Message-ID: <48E1D669.9000700@sun.com>


Roman Kennke wrote:
> Hi again,
> 
>>>> the issue with SCA/OpenJDK user names (see email below) is resolved, so 
>>>> you can push your changes into awt-gate workspace. Note, we decided to 
>>>> push the docs change in a separate patch (and it is still in progress, 
>>>> as far as I see).
>>> Wow cool, my first self-committed patch :-) Ok, I think I still need a
>>> hand for writing the commit message. I propose sth like:
>>>
>>> <<
>>> 6749920: Cleanup AWT peer interfaces
>>> Reviewed-by: ???
>> Please, add me (OpenJDK user 'art') and Andrei ('dav') to the list of 
>> reviewers.
> 
> Ok, I did. I tried to push and then got this:
> 
> remote: Invalid changeset author: Roman Kennke <roman.kennke at aicas.com>
> 
> I can rollback and re-do my commit, but what would be a valid changeset
> author name?

You should use 'rkennke' as your user name. This can be configured in 
~/.hgrc file, like this (sorry, if this information is already known to 
you):

[ui]
merge = hgmerge
username = rkennke

[extensions]
hgext.forest =
jcheck = /export/jcheck/jcheck.py

[hooks]
pretxncommit = python:jcheck.hook
pretxnchangegroup = python:jcheck.hook

Thanks,

Artem

> /Roman
>