sergey.bylokhov | 3 May 16:16 2011
Picon

hg: jdk7/awt/jdk: 7016528: Deadlock during mutual initialization of DataTransferer and DataTransferer$DataFlavorComparator

Changeset: d400711b8cd2
Author:    serb
Date:      2011-05-03 15:19 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/d400711b8cd2

7016528: Deadlock during mutual initialization of DataTransferer and DataTransferer$DataFlavorComparator
Reviewed-by: dav, art, denis

! src/share/classes/sun/awt/datatransfer/DataTransferer.java

andrei.dmitriev | 4 May 10:41 2011
Picon

hg: jdk7/awt/jdk: 7040577: Default implementation of Toolkit.loadSystemColors(int[]) and many others doesn't throw HE in hl env

Changeset: 1b154e3ab359
Author:    dav
Date:      2011-05-04 14:46 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/1b154e3ab359

7040577: Default implementation of Toolkit.loadSystemColors(int[]) and many others doesn't throw HE
in hl env
Reviewed-by: dcherepanov, denis

! src/share/classes/java/awt/Toolkit.java
+ test/java/awt/Toolkit/Headless/ExceptionContract/ExceptionContract.java

Herve Girod | 5 May 00:14 2011
Picon

Paint a JComponent without clipping children

Hello,

I'm new to this mailing list and I'm not *really* asking how to do it because I know how it's possible to do it by using a hack (mainly getting and setting the BUFFER and TILE parts of the "flags" field for the JComponent by reflection, and "rewriting" the paintChildren method without the clipping part). I'm using it in the http://sourceforge.net/projects/j661/  project to be able to use custom Swing containers which only offset the position or transform their children graphic context, without clipping them (allowing to use negative positions for the children widgets, for example).

I'm asking if there is a way to do this without playing with the private "flags" field, because I need to be able to do the same thing in a restricted JNLP environment. I know a "regular"' way to do this, but it would be a little cumbersome (offsetting the positions of all children widgets in the parent container, to be sure that the positions of the children are never negative, for example). But it's not very good for performance when something change in the parent container....

There are many projects which either play with this private field, or use transforms, but in this later case they still apply a clipping. Is it possible to play with the Graphics2D clippings for example before using the JComponent paintChildren method - or would this approach work ?  Or would the only way to do it without compromising Security be to have a way to get / set the TILE and BUFFER value of the "flags" field without reflection ?

Thanks by advance if you have ideas about this, and sorry if this prose is not crystal clear ;)

Herve Girod


Anthony Petrov | 5 May 20:46 2011
Picon

Re: Paint a JComponent without clipping children

Hi Herve,

JComponent is a Swing component. I suggest you to subscribe to the 
swing-dev@... mailing list and post your question there.

--
best regards,
Anthony

On 5/5/2011 2:14 AM, Herve Girod wrote:
> Hello,
> 
> I'm new to this mailing list and I'm not *really* asking how to do it 
> because I know how it's possible to do it by using a hack (mainly 
> getting and setting the BUFFER and TILE parts of the "flags" field for 
> the JComponent by reflection, and "rewriting" the paintChildren method 
> without the clipping part). I'm using it in 
> the http://sourceforge.net/projects/j661/  project to be able to use 
> custom Swing containers which only offset the position or transform 
> their children graphic context, without clipping them (allowing to use 
> negative positions for the children widgets, for example).
> 
> I'm asking if there is a way to do this without playing with the private 
> "flags" field, because I need to be able to do the same thing in a 
> restricted JNLP environment. I know a "regular"' way to do this, but it 
> would be a little cumbersome (offsetting the positions of all children 
> widgets in the parent container, to be sure that the positions of the 
> children are never negative, for example). But it's not very good for 
> performance when something change in the parent container....
> 
> There are many projects which either play with this private field, or 
> use transforms, but in this later case they still apply a clipping. Is 
> it possible to play with the Graphics2D clippings for example before 
> using the JComponent paintChildren method - or would this approach work 
> ?  Or would the only way to do it without compromising Security be to 
> have a way to get / set the TILE and BUFFER value of the "flags" field 
> without reflection ?
> 
> Thanks by advance if you have ideas about this, and sorry if this prose 
> is not crystal clear ;)
> 
> Herve Girod
> 
> 

Herve Girod | 6 May 00:45 2011
Picon

Re: Paint a JComponent without clipping children

Thanks, I was not sure on which mailing list it should be posted, but you are right, it could only be swing...

Regards,

Herve

2011/5/5 Anthony Petrov <anthony.petrov-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Hi Herve,

JComponent is a Swing component. I suggest you to subscribe to the swing-dev <at> openjdk.java.net mailing list and post your question there.

--
best regards,
Anthony


On 5/5/2011 2:14 AM, Herve Girod wrote:
Hello,

I'm new to this mailing list and I'm not *really* asking how to do it because I know how it's possible to do it by using a hack (mainly getting and setting the BUFFER and TILE parts of the "flags" field for the JComponent by reflection, and "rewriting" the paintChildren method without the clipping part). I'm using it in the http://sourceforge.net/projects/j661/  project to be able to use custom Swing containers which only offset the position or transform their children graphic context, without clipping them (allowing to use negative positions for the children widgets, for example).

I'm asking if there is a way to do this without playing with the private "flags" field, because I need to be able to do the same thing in a restricted JNLP environment. I know a "regular"' way to do this, but it would be a little cumbersome (offsetting the positions of all children widgets in the parent container, to be sure that the positions of the children are never negative, for example). But it's not very good for performance when something change in the parent container....

There are many projects which either play with this private field, or use transforms, but in this later case they still apply a clipping. Is it possible to play with the Graphics2D clippings for example before using the JComponent paintChildren method - or would this approach work ?  Or would the only way to do it without compromising Security be to have a way to get / set the TILE and BUFFER value of the "flags" field without reflection ?

Thanks by advance if you have ideas about this, and sorry if this prose is not crystal clear ;)

Herve Girod



Clemens Eisserer | 8 May 00:06 2011
Picon

Cross-Platform print dialog ignores Window's default printer setting?

Hi,

I am currently writing some all-in-one solution for a small airport,
inclusing some JasperReport based reports.

JasperReports uses the cross platform print dialog based on Swing,
however the dialog seems to completly ignore the default printer.

E.g. although the epson receipt printer is set to default, some filter
driver is choosen by the swing dialog instead:
https://picasaweb.google.com/lh/photo/5xW_wB63hRQJzbwRCsg_TgBiX1r6uK8ZJh_dEiJnndQ?feat=directlink
https://picasaweb.google.com/lh/photo/nClqBtgcf4Lh8-DEACd6zwBiX1r6uK8ZJh_dEiJnndQ?feat=directlink

Any idea what can be done about that?

Thank you in advance, Clemens

Phil Race | 8 May 04:30 2011
Picon

Re: Cross-Platform print dialog ignores Window's default printer setting?

Hello Clemens,

Just so you know: printing in JDK is entirely a 2D area. Package name isn't
a useful indicator. You should move this to a 2D forum as how all printer
selection is done is in 2D code ..

And (forgive me for being nit picky), this is really more of a question for
one of the forums on using the APIs rather than the openjdk ones for
working on the implementation. That's my standard reminder on this to
be consistent.

But if I knew the answer off hand, I'd give it, but I don't. We just
query the default printer and so the cross platform dialog
should show whatever the native dialog does.

Maybe there's a locale issue I am not aware of.

-phil.

On 5/7/2011 3:06 PM, Clemens Eisserer wrote:
> Hi,
>
> I am currently writing some all-in-one solution for a small airport,
> inclusing some JasperReport based reports.
>
> JasperReports uses the cross platform print dialog based on Swing,
> however the dialog seems to completly ignore the default printer.
>
> E.g. although the epson receipt printer is set to default, some filter
> driver is choosen by the swing dialog instead:
> https://picasaweb.google.com/lh/photo/5xW_wB63hRQJzbwRCsg_TgBiX1r6uK8ZJh_dEiJnndQ?feat=directlink
> https://picasaweb.google.com/lh/photo/nClqBtgcf4Lh8-DEACd6zwBiX1r6uK8ZJh_dEiJnndQ?feat=directlink
>
> Any idea what can be done about that?
>
> Thank you in advance, Clemens

Denis Lila | 10 May 15:48 2011
Picon

Add mutter as a window manager.

Hi.

We have this bug where, using the mutter window manager,
if one moves netbeans anywhere on the screen except at
the top left and then maximizes it, clicking is broken.
This is because after maximizing the position of the
XDecoratedPeer is not updated. On Metacity and some other
WMs this is done using a WM specific workaround.

I've added Mutter as a WM, and this webrev fixes the problem:
http://icedtea.classpath.org/~dlila/webrevs/mutterBug/

Any comments are much appreciated.

Thank you,
Denis.

dmitry.cherepanov | 10 May 16:22 2011
Picon

hg: jdk7/awt/jdk: 7035053: java/awt/event/MouseWheelEvent/DisabledComponent/DisabledComponent.java fails against jdk7 b134

Changeset: 997f464f8446
Author:    bagiras
Date:      2011-05-10 17:56 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/997f464f8446

7035053: java/awt/event/MouseWheelEvent/DisabledComponent/DisabledComponent.java fails
against jdk7 b134
Reviewed-by: art, denis, ant, dcherepanov

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

anthony.petrov | 10 May 16:28 2011
Picon

hg: jdk7/awt/jdk: 7041387: Introduce new boolean system property java.awt.smartInvalidate

Changeset: dde5cc0d768c
Author:    anthony
Date:      2011-05-10 18:28 +0400
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/dde5cc0d768c

7041387: Introduce new boolean system property java.awt.smartInvalidate
Summary: The behavior introduced with 6852592 is now enabled by the new system property only
Reviewed-by: dcherepanov

! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java
! test/java/awt/Component/Revalidate/Revalidate.java
! test/java/awt/Container/ValidateRoot/InvalidateMustRespectValidateRoots.java


Gmane