From omajid at redhat.com Mon Jan 5 07:57:46 2009 From: omajid at redhat.com (Omair Majid) Date: Mon, 05 Jan 2009 10:57:46 -0500 Subject: [PATCH] Fix invalid PropertyChangeEvents from being propagated Message-ID: <49622DFA.4030007@redhat.com> Hi, The current implementation of AccessibleContext propagates PropertyChangeEvents that dont correspond do a change. This patch checks that the new value and the old value are different before firing a PropertyChangeEvent. This has been committed to icedtea as http://icedtea.classpath.org/hg/icedtea6/rev/136f40a0dae4. Apologies in advance if this isn't the correct list to post this patch. Cheers, Omair -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: icedtea-a11y-property-change.patch Url: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20090105/187c032b/attachment.ksh From omajid at redhat.com Fri Jan 9 11:49:16 2009 From: omajid at redhat.com (Omair Majid) Date: Fri, 09 Jan 2009 14:49:16 -0500 Subject: [PATCH] Fix X11 window size calculation Message-ID: <4967AA3C.2020704@redhat.com> Hi, This patch fixes an error in the calculation of an X11 window size. The inset size was being included in the calculation of the client area size for a window. A jtreg test is included. This was tested with openjdk6 but seems to be present in openjdk7 too. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6721088 Cheers, Omair -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: icedtea-awt-window-size.patch Url: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20090109/8bbacb57/attachment.ksh From Andrei.Dmitriev at Sun.COM Sun Jan 11 01:33:07 2009 From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev) Date: Sun, 11 Jan 2009 12:33:07 +0300 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <4967AA3C.2020704@redhat.com> References: <4967AA3C.2020704@redhat.com> Message-ID: <4969BCD3.9080001@sun.com> Hi, thanks for the patch! The defect is against Swing and in the closed state since July. Considering the fix perhaps AWT should take care on and track that CR. Thanks, Andrei Omair Majid wrote: > Hi, > > This patch fixes an error in the calculation of an X11 window size. The > inset size was being included in the calculation of the client area size > for a window. A jtreg test is included. This was tested with openjdk6 > but seems to be present in openjdk7 too. > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6721088 > > Cheers, > > Omair > From Artem.Ananiev at Sun.COM Sun Jan 11 01:45:03 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Sun, 11 Jan 2009 12:45:03 +0300 Subject: [PATCH] Cleanup AWT peer interfaces In-Reply-To: <1230546467.6637.1.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> <491AE866.10605@sun.com> <1228822765.6920.37.camel@moonlight> <49466A31.1070901@sun.com> <4950A7AB.4080105@sun.com> <1230546467.6637.1.camel@moonlight> Message-ID: <4969BF9F.1030102@sun.com> Roman Kennke wrote: > Hi Artem, > >>> Cool! I'm comfortable with this fix now. >>> >>> We still need second approve vote to push this change in. >>> Artem...? Others? ;) >> Well, I'm fine with the proposed changes in general. Still, some JavaDoc >> comments looks to be too implementation-specific. For example, most of >> Container's methods contain a statement like this: >> >> This is called from {@link ...}, before/after ... >> >> and they really called from the specified places, however this may not >> be true in future. I'd remove all these statements from JavaDoc, leaving >> only behavioral description. > > Yeah, you are right. I put these in because I found it very useful while > implementing the peers to see exactly where and when it is called. I > removed those comments and only let the @see references in there. The > updated webrev is here: > > http://kennke.org/~roman/docpeers/webrev/ > > Ok now? Fine, thank you. Artem > Cheers, Roman > >> Thanks, >> >> Artem >> >>> Thanks, >>> Andrei >>> >>> Roman Kennke wrote: >>>> Hi Andrei, >>>> >>>> Finally I came around to fix the suggested stuff. See comments inline. >>>> >>>>> 1) src/share/classes/java/awt/peer/CheckboxMenuItemPeer.java >>>>> >>>>> +import java.awt.CheckboxMenuItem; >>>>> if that's really needed? I thought that {@link ...} doesn't require >>>>> such stuff. >>>> I don't know. If you fully qualify the stuff in the {@link } it's not >>>> needed. Should I fully-qualify things everywhere or let the import in >>>> place? I don't care really. >>>> >>>> >>>>> 2) src/share/classes/java/awt/peer/ContainerPeer.java >>>>> There is a typo in the second word: >>>>> - * Indicates availabiltity of restacking operation in this >>>>> container. >>>>> + * Indicates availability of restacking operation in this >>>>> container. >>>> Fixed. >>>> >>>>> 3) Common thing. >>>>> true have a shorter synonym since JDK 5: {@code true} >>>> Fixed. >>>> >>>>> 4) src/share/classes/java/awt/peer/RobotPeer.java >>>>> I noticed that you prefer not to leave "public" modifier in an >>>>> interface. But here you are leaving all of them. >>>> Fixed. >>>> >>>>> 5) src/share/classes/java/awt/peer/RobotPeer.java >>>>> public int getNumberOfButtons(); has left w/o any comments. >>>> Fixed. I'm not sure if I got the sematics right. >>>> >>>>> 6) src/share/classes/java/awt/peer/ComponentPeer.java >>>>> + /** >>>>> + * Called by {@link EventQueue#coalescePaintEvent} to let the >>>>> component >>>>> + * peer coalesce paint events. >>>>> + * >>>>> + * @param e the paint event to consider to coalesce >>>>> + * >>>>> + * @see EventQueue#coalescePaintEvent >>>>> + */ >>>>> + void coalescePaintEvent(PaintEvent e); >>>>> >>>>> I'd say it's not "to let .... coalesce paint events", but "to >>>>> coalesce paint events". >>>> Fixed. >>>> >>>>> 7) at the same class. >>>>> You wrote: >>>>> + // TODO: Maybe change this to force Graphics2D, since many >>>>> things will >>>>> + // break with plain Graphics nowadays. >>>>> + Graphics getGraphics(); >>>>> >>>>> Do you know a scenario to show what's exactly might be broken. We >>>>> probably need to introduce another peer for that, right? >>>> I already explained my reason in earlier mails. You think this is >>>> reasonable? >>>> >>>> >>>>> 8) Similar to 7): >>>>> + // TODO: Maybe make that return a BufferedImage, because some >>>>> stuff will >>>>> + // break if a different kind of image is returned. >>>>> + Image createImage(int width, int height); >>>> Dito. >>>> >>>> This time I did the work on top of the -awt workspace and created a >>>> webrev for your reviewing pleasure: >>>> >>>> http://kennke.org/~roman/docpeers/webrev/ >>>> >>>> Thanks for having a look at it again, >>>> >>>> Roman >>>> From Andrei.Dmitriev at Sun.COM Sun Jan 11 01:53:14 2009 From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev) Date: Sun, 11 Jan 2009 12:53:14 +0300 Subject: [PATCH] Cleanup AWT peer interfaces In-Reply-To: <1230546467.6637.1.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> <491AE866.10605@sun.com> <1228822765.6920.37.camel@moonlight> <49466A31.1070901@sun.com> <4950A7AB.4080105@sun.com> <1230546467.6637.1.camel@moonlight> Message-ID: <4969C18A.4020103@sun.com> Gentlemen, I'm still fine with the patch. Thanks, Andrei Roman Kennke wrote: > Hi Artem, > >>> Cool! I'm comfortable with this fix now. >>> >>> We still need second approve vote to push this change in. >>> Artem...? Others? ;) >> Well, I'm fine with the proposed changes in general. Still, some JavaDoc >> comments looks to be too implementation-specific. For example, most of >> Container's methods contain a statement like this: >> >> This is called from {@link ...}, before/after ... >> >> and they really called from the specified places, however this may not >> be true in future. I'd remove all these statements from JavaDoc, leaving >> only behavioral description. > > Yeah, you are right. I put these in because I found it very useful while > implementing the peers to see exactly where and when it is called. I > removed those comments and only let the @see references in there. The > updated webrev is here: > > http://kennke.org/~roman/docpeers/webrev/ > > Ok now? > > Cheers, Roman > >> Thanks, >> >> Artem >> >>> Thanks, >>> Andrei >>> >>> Roman Kennke wrote: >>>> Hi Andrei, >>>> >>>> Finally I came around to fix the suggested stuff. See comments inline. >>>> >>>>> 1) src/share/classes/java/awt/peer/CheckboxMenuItemPeer.java >>>>> >>>>> +import java.awt.CheckboxMenuItem; >>>>> if that's really needed? I thought that {@link ...} doesn't require >>>>> such stuff. >>>> I don't know. If you fully qualify the stuff in the {@link } it's not >>>> needed. Should I fully-qualify things everywhere or let the import in >>>> place? I don't care really. >>>> >>>> >>>>> 2) src/share/classes/java/awt/peer/ContainerPeer.java >>>>> There is a typo in the second word: >>>>> - * Indicates availabiltity of restacking operation in this >>>>> container. >>>>> + * Indicates availability of restacking operation in this >>>>> container. >>>> Fixed. >>>> >>>>> 3) Common thing. >>>>> true have a shorter synonym since JDK 5: {@code true} >>>> Fixed. >>>> >>>>> 4) src/share/classes/java/awt/peer/RobotPeer.java >>>>> I noticed that you prefer not to leave "public" modifier in an >>>>> interface. But here you are leaving all of them. >>>> Fixed. >>>> >>>>> 5) src/share/classes/java/awt/peer/RobotPeer.java >>>>> public int getNumberOfButtons(); has left w/o any comments. >>>> Fixed. I'm not sure if I got the sematics right. >>>> >>>>> 6) src/share/classes/java/awt/peer/ComponentPeer.java >>>>> + /** >>>>> + * Called by {@link EventQueue#coalescePaintEvent} to let the >>>>> component >>>>> + * peer coalesce paint events. >>>>> + * >>>>> + * @param e the paint event to consider to coalesce >>>>> + * >>>>> + * @see EventQueue#coalescePaintEvent >>>>> + */ >>>>> + void coalescePaintEvent(PaintEvent e); >>>>> >>>>> I'd say it's not "to let .... coalesce paint events", but "to >>>>> coalesce paint events". >>>> Fixed. >>>> >>>>> 7) at the same class. >>>>> You wrote: >>>>> + // TODO: Maybe change this to force Graphics2D, since many >>>>> things will >>>>> + // break with plain Graphics nowadays. >>>>> + Graphics getGraphics(); >>>>> >>>>> Do you know a scenario to show what's exactly might be broken. We >>>>> probably need to introduce another peer for that, right? >>>> I already explained my reason in earlier mails. You think this is >>>> reasonable? >>>> >>>> >>>>> 8) Similar to 7): >>>>> + // TODO: Maybe make that return a BufferedImage, because some >>>>> stuff will >>>>> + // break if a different kind of image is returned. >>>>> + Image createImage(int width, int height); >>>> Dito. >>>> >>>> This time I did the work on top of the -awt workspace and created a >>>> webrev for your reviewing pleasure: >>>> >>>> http://kennke.org/~roman/docpeers/webrev/ >>>> >>>> Thanks for having a look at it again, >>>> >>>> Roman >>>> From Artem.Ananiev at Sun.COM Sun Jan 11 02:30:27 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Sun, 11 Jan 2009 13:30:27 +0300 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <4967AA3C.2020704@redhat.com> References: <4967AA3C.2020704@redhat.com> Message-ID: <4969CA43.7010208@sun.com> Hi, Omair, thank you for the patch. It seems that the bug was closed by mistake, so I have just reopened it against AWT. As for proposed changes, there is a single question: --- jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java.orig 2009-01-08 16:53:54.000000000 -0500 +++ jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java 2009-01-08 16:54:08.000000000 -0500 @@ -478,7 +478,10 @@ // do nothing but accept it. Rectangle reqBounds = newDimensions.getBounds(); Rectangle newBounds = constrainBounds(reqBounds.x, reqBounds.y, reqBounds.width, reqBounds.height); - newDimensions = new WindowDimensions(newBounds, newDimensions.getInsets(), newDimensions.isClientSizeSet()); + Insets insets = newDimensions.getInsets(); + Rectangle fixedBounds = new Rectangle(newBounds.x, newBounds.y, newBounds.width - insets.left - insets.right, + newBounds.height - insets.top - insets.bottom); + newDimensions = new WindowDimensions(fixedBounds, insets, newDimensions.isClientSizeSet()); } XToolkit.awtLock(); try { WindowDimensions class contains either client size or full size of the window, depending on 'isClientSizeSet' flag. fixedBounds from your patch is always a client rect, however isClientSizeSet is used from newDimensions... I'd rewrite the last changed line this way: + newDimensions = new WindowDimensions(fixedBounds, insets, true); or, even better, this this one: + newDimensions = new WindowDimensions(newDimensions.isClientSizeSet() ? fixedBounds : newBounds, insets, newDimensions.isClientSizeSet()); Your comments? Thanks, Artem Omair Majid wrote: > Hi, > > This patch fixes an error in the calculation of an X11 window size. The > inset size was being included in the calculation of the client area size > for a window. A jtreg test is included. This was tested with openjdk6 > but seems to be present in openjdk7 too. > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6721088 > > Cheers, > > Omair > From Artem.Ananiev at Sun.COM Sun Jan 11 02:31:02 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Sun, 11 Jan 2009 13:31:02 +0300 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <4969BCD3.9080001@sun.com> References: <4967AA3C.2020704@redhat.com> <4969BCD3.9080001@sun.com> Message-ID: <4969CA66.3030304@sun.com> Andrei V. Dmitriev wrote: > Hi, > > thanks for the patch! > The defect is against Swing and in the closed state since July. > Considering the fix perhaps AWT should take care on and track that CR. I've reopened this bug and dispatched it to AWT group. Artem > Thanks, > Andrei > > > Omair Majid wrote: >> Hi, >> >> This patch fixes an error in the calculation of an X11 window size. >> The inset size was being included in the calculation of the client >> area size for a window. A jtreg test is included. This was tested with >> openjdk6 but seems to be present in openjdk7 too. >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6721088 >> >> Cheers, >> >> Omair >> From roman.kennke at aicas.com Sun Jan 11 10:55:33 2009 From: roman.kennke at aicas.com (Roman Kennke) Date: Sun, 11 Jan 2009 19:55:33 +0100 Subject: [PATCH] Cleanup AWT peer interfaces In-Reply-To: <4969BF9F.1030102@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> <1221833318.21961.0.camel@moonlight> <491AE866.10605@sun.com> <1228822765.6920.37.camel@moonlight> <49466A31.1070901@sun.com> <4950A7AB.4080105@sun.com> <1230546467.6637.1.camel@moonlight> <4969BF9F.1030102@sun.com> Message-ID: <1231700133.19331.0.camel@moonlight> Hi Artem, > > http://kennke.org/~roman/docpeers/webrev/ > > > > Ok now? > > Fine, thank you. Cool. So I'm going to push this patch. Do we happen to have a bugreport that I can reference in the 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 Andrei.Dmitriev at Sun.COM Mon Jan 12 02:08:04 2009 From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev) Date: Mon, 12 Jan 2009 13:08:04 +0300 Subject: [PATCH] Cleanup AWT peer interfaces In-Reply-To: <1231700133.19331.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> <491AE866.10605@sun.com> <1228822765.6920.37.camel@moonlight> <49466A31.1070901@sun.com> <4950A7AB.4080105@sun.com> <1230546467.6637.1.camel@moonlight> <4969BF9F.1030102@sun.com> <1231700133.19331.0.camel@moonlight> Message-ID: <496B1684.1040500@sun.com> Roman, seem we don't have that one. Here is a new one: 6792515: specify awt peer's API. (As usual, give it a time to appear publicly) Feel free to use it for push comment. While trying to find non-existing one, got one more related to this area: CR 6749920. Don't you occasionally have a patch already? ;) Thanks, Andrei Roman Kennke wrote: > Hi Artem, > >>> http://kennke.org/~roman/docpeers/webrev/ >>> >>> Ok now? >> Fine, thank you. > > Cool. So I'm going to push this patch. Do we happen to have a bugreport > that I can reference in the commit message? > > /Roman > From omajid at redhat.com Mon Jan 12 07:16:57 2009 From: omajid at redhat.com (Omair Majid) Date: Mon, 12 Jan 2009 10:16:57 -0500 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <4969CA43.7010208@sun.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> Message-ID: <496B5EE9.8080400@redhat.com> Hi Artem, Artem Ananiev wrote: > Hi, Omair, > > thank you for the patch. It seems that the bug was closed by mistake, so > I have just reopened it against AWT. > Thanks! > As for proposed changes, there is a single question: > > --- jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java.orig > 2009-01-08 16:53:54.000000000 -0500 > +++ jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java > 2009-01-08 16:54:08.000000000 -0500 > @@ -478,7 +478,10 @@ > // do nothing but accept it. > Rectangle reqBounds = newDimensions.getBounds(); > Rectangle newBounds = constrainBounds(reqBounds.x, > reqBounds.y, reqBounds.width, reqBounds.height); > - newDimensions = new WindowDimensions(newBounds, > newDimensions.getInsets(), newDimensions.isClientSizeSet()); > + Insets insets = newDimensions.getInsets(); > + Rectangle fixedBounds = new Rectangle(newBounds.x, > newBounds.y, newBounds.width - insets.left - insets.right, > + newBounds.height - insets.top - insets.bottom); > + newDimensions = new WindowDimensions(fixedBounds, insets, > newDimensions.isClientSizeSet()); > } > XToolkit.awtLock(); > try { > > WindowDimensions class contains either client size or full size of the > window, depending on 'isClientSizeSet' flag. fixedBounds from your patch > is always a client rect, however isClientSizeSet is used from > newDimensions... I'd rewrite the last changed line this way: > > + newDimensions = new WindowDimensions(fixedBounds, insets, > true); > > or, even better, this this one: > > + newDimensions = new > WindowDimensions(newDimensions.isClientSizeSet() ? fixedBounds : > newBounds, insets, newDimensions.isClientSizeSet()); > > Your comments? > Thanks for looking over the patch! As for your change, that seems like the correct thing to do. Would it be possible to add the explanation for isClientSizeSet()'s usage to WindowDimensions class? I just want to make sure that nobody else makes the mistake I just did. Cheers, Omair From roman at kennke.org Tue Jan 13 11:07:54 2009 From: roman at kennke.org (roman at kennke.org) Date: Tue, 13 Jan 2009 19:07:54 +0000 Subject: hg: jdk7/awt/jdk: 6792515: Specify awt peer's API Message-ID: <20090113190810.A56A1D5AF@hg.openjdk.java.net> Changeset: 63d087cacbf9 Author: rkennke Date: 2009-01-13 20:04 +0100 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/63d087cacbf9 6792515: Specify awt peer's API Summary: Document AWT peer API. Reviewed-by: art, dav ! src/share/classes/java/awt/peer/ButtonPeer.java ! src/share/classes/java/awt/peer/CanvasPeer.java ! src/share/classes/java/awt/peer/CheckboxMenuItemPeer.java ! src/share/classes/java/awt/peer/CheckboxPeer.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/DesktopPeer.java ! src/share/classes/java/awt/peer/DialogPeer.java ! src/share/classes/java/awt/peer/FileDialogPeer.java ! src/share/classes/java/awt/peer/FontPeer.java ! src/share/classes/java/awt/peer/FramePeer.java ! src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java ! src/share/classes/java/awt/peer/LabelPeer.java ! src/share/classes/java/awt/peer/ListPeer.java ! src/share/classes/java/awt/peer/MenuBarPeer.java ! src/share/classes/java/awt/peer/MenuComponentPeer.java ! src/share/classes/java/awt/peer/MenuItemPeer.java ! src/share/classes/java/awt/peer/MenuPeer.java ! src/share/classes/java/awt/peer/MouseInfoPeer.java ! src/share/classes/java/awt/peer/PanelPeer.java ! src/share/classes/java/awt/peer/PopupMenuPeer.java ! src/share/classes/java/awt/peer/RobotPeer.java ! src/share/classes/java/awt/peer/ScrollPanePeer.java ! src/share/classes/java/awt/peer/ScrollbarPeer.java ! src/share/classes/java/awt/peer/SystemTrayPeer.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/TrayIconPeer.java ! src/share/classes/java/awt/peer/WindowPeer.java From roman.kennke at aicas.com Tue Jan 13 11:10:13 2009 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 13 Jan 2009 20:10:13 +0100 Subject: [PATCH] Cleanup AWT peer interfaces In-Reply-To: <496B1684.1040500@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> <1221833318.21961.0.camel@moonlight> <491AE866.10605@sun.com> <1228822765.6920.37.camel@moonlight> <49466A31.1070901@sun.com> <4950A7AB.4080105@sun.com> <1230546467.6637.1.camel@moonlight> <4969BF9F.1030102@sun.com> <1231700133.19331.0.camel@moonlight> <496B1684.1040500@sun.com> Message-ID: <1231873813.6347.15.camel@moonlight> Hi Andrei, > seem we don't have that one. Here is a new one: > 6792515: specify awt peer's API. > (As usual, give it a time to appear publicly) > Feel free to use it for push comment. Done. > While trying to find non-existing one, got one more related to this > area: CR 6749920. Don't you occasionally have a patch already? ;) No sorry. But should be fairly easy to implement. When I find some time, I can go over it. It's better to do now as long as it's 'hot', otherwise it becomes forgotten. /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 Fri Jan 16 06:14:01 2009 From: roman at kennke.org (Roman Kennke) Date: Fri, 16 Jan 2009 15:14:01 +0100 Subject: [PATCH] ComponentAccessor Message-ID: <1232115241.6255.12.camel@moonlight> Today I found the aweful (sorry) ComponentAccessor. I quickly rewrote it using what I call the 'friends for Java' pattern (described here: http://kennke.org/blog/2009/01/08/friends-for-java/ ). This has a couple of advantages: - no reflection (I don't like reflection) - compile-time safety - better IDE support (i.e. I was trying to trace ComponentPeer.getGraphicsConfiguration() back today, and only got to Window.resetGC(), because this one is only called via reflection in ComponentAccessor). - I'd guess that performance is slighly better, but that probably doesn't matter much in these cases. Do you think that should go into OpenJDK? Webrev: http://kennke.org/~roman/componentaccess/webrev/ Cheers, Roman -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20090116/cf30f192/attachment.bin From son.two at gmail.com Fri Jan 16 06:38:06 2009 From: son.two at gmail.com (Oleg Sukhodolsky) Date: Fri, 16 Jan 2009 17:38:06 +0300 Subject: [PATCH] ComponentAccessor In-Reply-To: <1232115241.6255.12.camel@moonlight> References: <1232115241.6255.12.camel@moonlight> Message-ID: <271e55d20901160638x66d38ed6jda1d78bc6268b506@mail.gmail.com> Hi Roman, I'd synchronized setting/getting of access field. And (perhaps) I'd only allow set this field once. Regards, Oleg. On Fri, Jan 16, 2009 at 5:14 PM, Roman Kennke wrote: > Today I found the aweful (sorry) ComponentAccessor. I quickly rewrote it > using what I call the 'friends for Java' pattern (described here: > > http://kennke.org/blog/2009/01/08/friends-for-java/ > > ). > > This has a couple of advantages: > > - no reflection (I don't like reflection) > - compile-time safety > - better IDE support (i.e. I was trying to trace > ComponentPeer.getGraphicsConfiguration() back today, and only got to > Window.resetGC(), because this one is only called via reflection in > ComponentAccessor). > - I'd guess that performance is slighly better, but that probably > doesn't matter much in these cases. > > Do you think that should go into OpenJDK? > > Webrev: http://kennke.org/~roman/componentaccess/webrev/ > > Cheers, Roman > > -- > http://kennke.org/blog/ > From roman at kennke.org Fri Jan 16 07:05:17 2009 From: roman at kennke.org (Roman Kennke) Date: Fri, 16 Jan 2009 16:05:17 +0100 Subject: [PATCH] ComponentAccessor In-Reply-To: <271e55d20901160638x66d38ed6jda1d78bc6268b506@mail.gmail.com> References: <1232115241.6255.12.camel@moonlight> <271e55d20901160638x66d38ed6jda1d78bc6268b506@mail.gmail.com> Message-ID: <1232118317.6255.20.camel@moonlight> Hi Oleg, > I'd synchronized setting/getting of access field. And (perhaps) I'd only allow > set this field once. Good ideas. I implemented both suggestions. Webrev is updated at the same URL. /Roman > > Regards, Oleg. > > On Fri, Jan 16, 2009 at 5:14 PM, Roman Kennke wrote: > > Today I found the aweful (sorry) ComponentAccessor. I quickly rewrote it > > using what I call the 'friends for Java' pattern (described here: > > > > http://kennke.org/blog/2009/01/08/friends-for-java/ > > > > ). > > > > This has a couple of advantages: > > > > - no reflection (I don't like reflection) > > - compile-time safety > > - better IDE support (i.e. I was trying to trace > > ComponentPeer.getGraphicsConfiguration() back today, and only got to > > Window.resetGC(), because this one is only called via reflection in > > ComponentAccessor). > > - I'd guess that performance is slighly better, but that probably > > doesn't matter much in these cases. > > > > Do you think that should go into OpenJDK? > > > > Webrev: http://kennke.org/~roman/componentaccess/webrev/ > > > > Cheers, Roman > > > > -- > > http://kennke.org/blog/ > > -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20090116/4d09d466/attachment.bin From son.two at gmail.com Fri Jan 16 08:26:37 2009 From: son.two at gmail.com (Oleg Sukhodolsky) Date: Fri, 16 Jan 2009 19:26:37 +0300 Subject: [PATCH] ComponentAccessor In-Reply-To: <1232118317.6255.20.camel@moonlight> References: <1232115241.6255.12.camel@moonlight> <271e55d20901160638x66d38ed6jda1d78bc6268b506@mail.gmail.com> <1232118317.6255.20.camel@moonlight> Message-ID: <271e55d20901160826q25c3f6b9kf6ae9bc833b87c55@mail.gmail.com> Hi Roman, On Fri, Jan 16, 2009 at 6:05 PM, Roman Kennke wrote: > Hi Oleg, > >> I'd synchronized setting/getting of access field. And (perhaps) I'd only allow >> set this field once. > > Good ideas. I implemented both suggestions. Webrev is updated at the > same URL. As far as I can see you add synchronization only to setter, but you should also add synchronization when you read this field. So you should either make access field volatile, or add synchronized getter and use it to get the field. Oleg. > /Roman > >> >> Regards, Oleg. >> >> On Fri, Jan 16, 2009 at 5:14 PM, Roman Kennke wrote: >> > Today I found the aweful (sorry) ComponentAccessor. I quickly rewrote it >> > using what I call the 'friends for Java' pattern (described here: >> > >> > http://kennke.org/blog/2009/01/08/friends-for-java/ >> > >> > ). >> > >> > This has a couple of advantages: >> > >> > - no reflection (I don't like reflection) >> > - compile-time safety >> > - better IDE support (i.e. I was trying to trace >> > ComponentPeer.getGraphicsConfiguration() back today, and only got to >> > Window.resetGC(), because this one is only called via reflection in >> > ComponentAccessor). >> > - I'd guess that performance is slighly better, but that probably >> > doesn't matter much in these cases. >> > >> > Do you think that should go into OpenJDK? >> > >> > Webrev: http://kennke.org/~roman/componentaccess/webrev/ >> > >> > Cheers, Roman >> > >> > -- >> > http://kennke.org/blog/ >> > > -- > http://kennke.org/blog/ > From roman at kennke.org Fri Jan 16 08:48:50 2009 From: roman at kennke.org (Roman Kennke) Date: Fri, 16 Jan 2009 17:48:50 +0100 Subject: [PATCH] ComponentAccessor In-Reply-To: <271e55d20901160826q25c3f6b9kf6ae9bc833b87c55@mail.gmail.com> References: <1232115241.6255.12.camel@moonlight> <271e55d20901160638x66d38ed6jda1d78bc6268b506@mail.gmail.com> <1232118317.6255.20.camel@moonlight> <271e55d20901160826q25c3f6b9kf6ae9bc833b87c55@mail.gmail.com> Message-ID: <1232124530.6255.28.camel@moonlight> Hi Oleg, > >> I'd synchronized setting/getting of access field. And (perhaps) I'd only allow > >> set this field once. > > > > Good ideas. I implemented both suggestions. Webrev is updated at the > > same URL. > > As far as I can see you add synchronization only to setter, but you > should also add > synchronization when you read this field. So you should either make > access field > volatile, or add synchronized getter and use it to get the field. Duh, you are right. I should better think twice before I send new patch :-). Now it should be correct, what do you think? Webrev still here: http://kennke.org/~roman/componentaccess/webrev/ /Roman -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20090116/eeb29d5f/attachment.bin From son.two at gmail.com Fri Jan 16 11:04:42 2009 From: son.two at gmail.com (Oleg Sukhodolsky) Date: Fri, 16 Jan 2009 22:04:42 +0300 Subject: [PATCH] ComponentAccessor In-Reply-To: <1232124530.6255.28.camel@moonlight> References: <1232115241.6255.12.camel@moonlight> <271e55d20901160638x66d38ed6jda1d78bc6268b506@mail.gmail.com> <1232118317.6255.20.camel@moonlight> <271e55d20901160826q25c3f6b9kf6ae9bc833b87c55@mail.gmail.com> <1232124530.6255.28.camel@moonlight> Message-ID: <271e55d20901161104p3abcb86bj42c7459fa1cf9326@mail.gmail.com> Looks fine for me. Oleg. On Fri, Jan 16, 2009 at 7:48 PM, Roman Kennke wrote: > Hi Oleg, > >> >> I'd synchronized setting/getting of access field. And (perhaps) I'd only allow >> >> set this field once. >> > >> > Good ideas. I implemented both suggestions. Webrev is updated at the >> > same URL. >> >> As far as I can see you add synchronization only to setter, but you >> should also add >> synchronization when you read this field. So you should either make >> access field >> volatile, or add synchronized getter and use it to get the field. > > Duh, you are right. I should better think twice before I send new > patch :-). Now it should be correct, what do you think? > > Webrev still here: http://kennke.org/~roman/componentaccess/webrev/ > > /Roman > > -- > http://kennke.org/blog/ > From roman at kennke.org Fri Jan 16 11:33:54 2009 From: roman at kennke.org (Roman Kennke) Date: Fri, 16 Jan 2009 20:33:54 +0100 Subject: [PATCH] ComponentAccessor In-Reply-To: <271e55d20901161104p3abcb86bj42c7459fa1cf9326@mail.gmail.com> References: <1232115241.6255.12.camel@moonlight> <271e55d20901160638x66d38ed6jda1d78bc6268b506@mail.gmail.com> <1232118317.6255.20.camel@moonlight> <271e55d20901160826q25c3f6b9kf6ae9bc833b87c55@mail.gmail.com> <1232124530.6255.28.camel@moonlight> <271e55d20901161104p3abcb86bj42c7459fa1cf9326@mail.gmail.com> Message-ID: <1232134434.6255.35.camel@moonlight> Hi Olegm > Looks fine for me. Cool. I take it, I have to wait for another reviewer, or can I push it now? What are the exact rules for this? /Roman > > Oleg. > > On Fri, Jan 16, 2009 at 7:48 PM, Roman Kennke wrote: > > Hi Oleg, > > > >> >> I'd synchronized setting/getting of access field. And (perhaps) I'd only allow > >> >> set this field once. > >> > > >> > Good ideas. I implemented both suggestions. Webrev is updated at the > >> > same URL. > >> > >> As far as I can see you add synchronization only to setter, but you > >> should also add > >> synchronization when you read this field. So you should either make > >> access field > >> volatile, or add synchronized getter and use it to get the field. > > > > Duh, you are right. I should better think twice before I send new > > patch :-). Now it should be correct, what do you think? > > > > Webrev still here: http://kennke.org/~roman/componentaccess/webrev/ > > > > /Roman > > > > -- > > http://kennke.org/blog/ > > -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20090116/674567a9/attachment.bin From son.two at gmail.com Fri Jan 16 13:23:49 2009 From: son.two at gmail.com (Oleg Sukhodolsky) Date: Sat, 17 Jan 2009 00:23:49 +0300 Subject: [PATCH] ComponentAccessor In-Reply-To: <1232134434.6255.35.camel@moonlight> References: <1232115241.6255.12.camel@moonlight> <271e55d20901160638x66d38ed6jda1d78bc6268b506@mail.gmail.com> <1232118317.6255.20.camel@moonlight> <271e55d20901160826q25c3f6b9kf6ae9bc833b87c55@mail.gmail.com> <1232124530.6255.28.camel@moonlight> <271e55d20901161104p3abcb86bj42c7459fa1cf9326@mail.gmail.com> <1232134434.6255.35.camel@moonlight> Message-ID: <271e55d20901161323y629780a8s2f46884f366a1009@mail.gmail.com> On Fri, Jan 16, 2009 at 10:33 PM, Roman Kennke wrote: > Hi Olegm > >> Looks fine for me. > > Cool. I take it, I have to wait for another reviewer, or can I push it > now? What are the exact rules for this? I'm afraid, I can not be counted as official reviewer, and you have to wait someone from AWT team to review the code :( Oleg. > > /Roman > >> >> Oleg. >> >> On Fri, Jan 16, 2009 at 7:48 PM, Roman Kennke wrote: >> > Hi Oleg, >> > >> >> >> I'd synchronized setting/getting of access field. And (perhaps) I'd only allow >> >> >> set this field once. >> >> > >> >> > Good ideas. I implemented both suggestions. Webrev is updated at the >> >> > same URL. >> >> >> >> As far as I can see you add synchronization only to setter, but you >> >> should also add >> >> synchronization when you read this field. So you should either make >> >> access field >> >> volatile, or add synchronized getter and use it to get the field. >> > >> > Duh, you are right. I should better think twice before I send new >> > patch :-). Now it should be correct, what do you think? >> > >> > Webrev still here: http://kennke.org/~roman/componentaccess/webrev/ >> > >> > /Roman >> > >> > -- >> > http://kennke.org/blog/ >> > > -- > http://kennke.org/blog/ > From Andrei.Dmitriev at Sun.COM Fri Jan 16 05:52:37 2009 From: Andrei.Dmitriev at Sun.COM (Andrei Dmitriev) Date: Fri, 16 Jan 2009 16:52:37 +0300 Subject: [PATCH] ComponentAccessor In-Reply-To: <271e55d20901161323y629780a8s2f46884f366a1009@mail.gmail.com> References: <1232115241.6255.12.camel@moonlight> <271e55d20901160638x66d38ed6jda1d78bc6268b506@mail.gmail.com> <1232118317.6255.20.camel@moonlight> <271e55d20901160826q25c3f6b9kf6ae9bc833b87c55@mail.gmail.com> <1232124530.6255.28.camel@moonlight> <271e55d20901161104p3abcb86bj42c7459fa1cf9326@mail.gmail.com> <1232134434.6255.35.camel@moonlight> <271e55d20901161323y629780a8s2f46884f366a1009@mail.gmail.com> Message-ID: <49709125.2000509@sun.com> Hi, here is my vote for this. Thanks, Andrei Oleg Sukhodolsky wrote: > On Fri, Jan 16, 2009 at 10:33 PM, Roman Kennke wrote: > >> Hi Olegm >> >> >>> Looks fine for me. >>> >> Cool. I take it, I have to wait for another reviewer, or can I push it >> now? What are the exact rules for this? >> > > I'm afraid, I can not be counted as official reviewer, and you have > to wait someone from AWT team to review the code :( > > Oleg. > > >> /Roman >> >> >>> Oleg. >>> >>> On Fri, Jan 16, 2009 at 7:48 PM, Roman Kennke wrote: >>> >>>> Hi Oleg, >>>> >>>> >>>>>>> I'd synchronized setting/getting of access field. And (perhaps) I'd only allow >>>>>>> set this field once. >>>>>>> >>>>>> Good ideas. I implemented both suggestions. Webrev is updated at the >>>>>> same URL. >>>>>> >>>>> As far as I can see you add synchronization only to setter, but you >>>>> should also add >>>>> synchronization when you read this field. So you should either make >>>>> access field >>>>> volatile, or add synchronized getter and use it to get the field. >>>>> >>>> Duh, you are right. I should better think twice before I send new >>>> patch :-). Now it should be correct, what do you think? >>>> >>>> Webrev still here: http://kennke.org/~roman/componentaccess/webrev/ >>>> >>>> /Roman >>>> >>>> -- >>>> http://kennke.org/blog/ >>>> >>>> >> -- >> http://kennke.org/blog/ >> >> From Artem.Ananiev at Sun.COM Mon Jan 19 03:40:15 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Mon, 19 Jan 2009 14:40:15 +0300 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <496B5EE9.8080400@redhat.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> <496B5EE9.8080400@redhat.com> Message-ID: <4974669F.9020004@sun.com> Hi, Omair, I've just updated bug #6721088 and included the information about the fix and the source of the problem. Do you prefer to push the fix into workspace yourself? You/your company must have signed SCA for doing that, and you also need a second reviewer from AWT group then. As for isClientSizeSet() - it's pretty self-explanatory :) What kind of additional comments do you suggest? Probably, something like this: /** * If isClient is true, the given rectangle is treated as a client rect, otherwise as a whole window rect with insets included. */ public WindowDimensions(Rectangle rec, Insets ins, boolean isClient); ? Thanks, Artem Omair Majid wrote: > Hi Artem, > > Artem Ananiev wrote: >> Hi, Omair, >> >> thank you for the patch. It seems that the bug was closed by mistake, >> so I have just reopened it against AWT. >> > Thanks! > >> As for proposed changes, there is a single question: >> >> --- jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java.orig >> 2009-01-08 16:53:54.000000000 -0500 >> +++ jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java >> 2009-01-08 16:54:08.000000000 -0500 >> @@ -478,7 +478,10 @@ >> // do nothing but accept it. >> Rectangle reqBounds = newDimensions.getBounds(); >> Rectangle newBounds = constrainBounds(reqBounds.x, >> reqBounds.y, reqBounds.width, reqBounds.height); >> - newDimensions = new WindowDimensions(newBounds, >> newDimensions.getInsets(), newDimensions.isClientSizeSet()); >> + Insets insets = newDimensions.getInsets(); >> + Rectangle fixedBounds = new Rectangle(newBounds.x, >> newBounds.y, newBounds.width - insets.left - insets.right, >> + newBounds.height - insets.top - insets.bottom); >> + newDimensions = new WindowDimensions(fixedBounds, insets, >> newDimensions.isClientSizeSet()); >> } >> XToolkit.awtLock(); >> try { >> >> WindowDimensions class contains either client size or full size of the >> window, depending on 'isClientSizeSet' flag. fixedBounds from your >> patch is always a client rect, however isClientSizeSet is used from >> newDimensions... I'd rewrite the last changed line this way: >> >> + newDimensions = new WindowDimensions(fixedBounds, insets, >> true); >> >> or, even better, this this one: >> >> + newDimensions = new >> WindowDimensions(newDimensions.isClientSizeSet() ? fixedBounds : >> newBounds, insets, newDimensions.isClientSizeSet()); >> >> Your comments? >> > > Thanks for looking over the patch! As for your change, that seems like > the correct thing to do. Would it be possible to add the explanation for > isClientSizeSet()'s usage to WindowDimensions class? I just want to make > sure that nobody else makes the mistake I just did. > > Cheers, > > Omair > From omajid at redhat.com Mon Jan 19 07:01:36 2009 From: omajid at redhat.com (Omair Majid) Date: Mon, 19 Jan 2009 10:01:36 -0500 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <4974669F.9020004@sun.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> <496B5EE9.8080400@redhat.com> <4974669F.9020004@sun.com> Message-ID: <497495D0.2050807@redhat.com> Hi Artem, Artem Ananiev wrote: > Hi, Omair, > > I've just updated bug #6721088 and included the information about the > fix and the source of the problem. Do you prefer to push the fix into > workspace yourself? You/your company must have signed SCA for doing > that, and you also need a second reviewer from AWT group then. Thanks for updating the bug report. I would love to push the fix myself. I work for Red Hat which has signed the SCA. Is there a procedure for asking for a second reviewer or should I use this mailing list? > > As for isClientSizeSet() - it's pretty self-explanatory :) What kind of > additional comments do you suggest? Probably, something like this: > > /** > * If isClient is true, the given rectangle is treated as a client rect, > otherwise as a whole window rect with insets included. > */ > public WindowDimensions(Rectangle rec, Insets ins, boolean isClient); > Yup, that looks great! Cheers, Omair From Artem.Ananiev at Sun.COM Mon Jan 19 07:44:12 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Mon, 19 Jan 2009 18:44:12 +0300 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <497495D0.2050807@redhat.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> <496B5EE9.8080400@redhat.com> <4974669F.9020004@sun.com> <497495D0.2050807@redhat.com> Message-ID: <49749FCC.4020904@sun.com> Hi, Omair, see my comments below. Omair Majid wrote: > Hi Artem, > > Artem Ananiev wrote: >> Hi, Omair, >> >> I've just updated bug #6721088 and included the information about the >> fix and the source of the problem. Do you prefer to push the fix into >> workspace yourself? You/your company must have signed SCA for doing >> that, and you also need a second reviewer from AWT group then. > > Thanks for updating the bug report. I would love to push the fix myself. > I work for Red Hat which has signed the SCA. Is there a procedure for > asking for a second reviewer or should I use this mailing list? Please, use this awt-dev at openjdk alias for submitting an updated version of the patch (with WindowDimensions comments?). I'll ask someone else from AWT to review it. Note, to push the changes into OpenJDK you need a valid mercurial user (which is also the author of the corresponding revision) with the access to AWT workspace. Do you have one or need any help with this? Thanks, Artem >> As for isClientSizeSet() - it's pretty self-explanatory :) What kind >> of additional comments do you suggest? Probably, something like this: >> >> /** >> * If isClient is true, the given rectangle is treated as a client >> rect, otherwise as a whole window rect with insets included. >> */ >> public WindowDimensions(Rectangle rec, Insets ins, boolean isClient); >> > > Yup, that looks great! > > Cheers, > > Omair From Anthony.Petrov at Sun.COM Mon Jan 19 07:50:09 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Mon, 19 Jan 2009 18:50:09 +0300 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <497495D0.2050807@redhat.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> <496B5EE9.8080400@redhat.com> <4974669F.9020004@sun.com> <497495D0.2050807@redhat.com> Message-ID: <4974A131.8080505@sun.com> Hi Omair, The fix looks fine (taking into account the changes suggested by Artem). I would also ask to remove the unneeded comment lines from the test code. The printout's, however, may safely be uncommented - this would be a useful information should the test ever fail. Please send the clean version of the latest patch to this mailing list for final reviewing. -- best regards, Anthony On 1/19/2009 6:01 PM Omair Majid wrote: > Hi Artem, > > Artem Ananiev wrote: >> Hi, Omair, >> >> I've just updated bug #6721088 and included the information about the >> fix and the source of the problem. Do you prefer to push the fix into >> workspace yourself? You/your company must have signed SCA for doing >> that, and you also need a second reviewer from AWT group then. > > Thanks for updating the bug report. I would love to push the fix myself. > I work for Red Hat which has signed the SCA. Is there a procedure for > asking for a second reviewer or should I use this mailing list? > >> >> As for isClientSizeSet() - it's pretty self-explanatory :) What kind >> of additional comments do you suggest? Probably, something like this: >> >> /** >> * If isClient is true, the given rectangle is treated as a client >> rect, otherwise as a whole window rect with insets included. >> */ >> public WindowDimensions(Rectangle rec, Insets ins, boolean isClient); >> > > Yup, that looks great! > > Cheers, > > Omair From omajid at redhat.com Mon Jan 19 08:57:18 2009 From: omajid at redhat.com (Omair Majid) Date: Mon, 19 Jan 2009 11:57:18 -0500 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <4974A131.8080505@sun.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> <496B5EE9.8080400@redhat.com> <4974669F.9020004@sun.com> <497495D0.2050807@redhat.com> <4974A131.8080505@sun.com> Message-ID: <4974B0EE.8010003@redhat.com> Hi Anthony, Anthony Petrov wrote: > The fix looks fine (taking into account the changes suggested by Artem). > I would also ask to remove the unneeded comment lines from the test > code. The printout's, however, may safely be uncommented - this would be > a useful information should the test ever fail. > > Please send the clean version of the latest patch to this mailing list > for final reviewing. > Patch is attached. It was diffed against jdk7 but should apply (with a fuzz) to jdk6 as well. Cheers, Omair -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: awt-x11-window-size.patch Url: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20090119/069daa3e/attachment.ksh From omajid at redhat.com Mon Jan 19 09:01:06 2009 From: omajid at redhat.com (Omair Majid) Date: Mon, 19 Jan 2009 12:01:06 -0500 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <49749FCC.4020904@sun.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> <496B5EE9.8080400@redhat.com> <4974669F.9020004@sun.com> <497495D0.2050807@redhat.com> <49749FCC.4020904@sun.com> Message-ID: <4974B1D2.6060204@redhat.com> Hi Artem, Artem Ananiev wrote: > > Note, to push the changes into OpenJDK you need a valid mercurial user > (which is also the author of the corresponding revision) with the access > to AWT workspace. Do you have one or need any help with this? > I dont have commit access to mercurial. How do I go about getting access? Thanks, Omair From Artem.Ananiev at Sun.COM Mon Jan 19 09:43:21 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Mon, 19 Jan 2009 20:43:21 +0300 Subject: [PATCH] ComponentAccessor In-Reply-To: <1232115241.6255.12.camel@moonlight> References: <1232115241.6255.12.camel@moonlight> Message-ID: <4974BBB9.8070108@sun.com> Hi, Roman, the idea you're proposing is fine, actually so fine that we have already partly implemented it in the latest JDK6 update releases :) The fix itself is also fine from my perspective. Unfortunately, our implementation is slightly different - I'm not sure if you have access to 6u10/6u12 sources, though - so if we integrate your fix as proposed to OpenJDK, we'll have some troubles with upcoming merge with 6u10/6u12 codebase... The only thing I'd suggest for you now is to rewrite your fix using the same approach as we have. BTW, to save your (and our) efforts next time, it may be worth notifying everybody from this dev group about what you're going to start working on - probably, someone else has almost implemented this in other manner. This is by no means not a requirement, I'm just trying to avoid conflicts like this in the future. Thanks, Artem Roman Kennke wrote: > Today I found the aweful (sorry) ComponentAccessor. I quickly rewrote it > using what I call the 'friends for Java' pattern (described here: > > http://kennke.org/blog/2009/01/08/friends-for-java/ > > ). > > This has a couple of advantages: > > - no reflection (I don't like reflection) > - compile-time safety > - better IDE support (i.e. I was trying to trace > ComponentPeer.getGraphicsConfiguration() back today, and only got to > Window.resetGC(), because this one is only called via reflection in > ComponentAccessor). > - I'd guess that performance is slighly better, but that probably > doesn't matter much in these cases. > > Do you think that should go into OpenJDK? > > Webrev: http://kennke.org/~roman/componentaccess/webrev/ > > Cheers, Roman > From roman at kennke.org Mon Jan 19 13:44:58 2009 From: roman at kennke.org (Roman Kennke) Date: Mon, 19 Jan 2009 22:44:58 +0100 Subject: [PATCH] ComponentAccessor In-Reply-To: <4974BBB9.8070108@sun.com> References: <1232115241.6255.12.camel@moonlight> <4974BBB9.8070108@sun.com> Message-ID: <1232401498.7656.4.camel@moonlight> Hi Artem, > the idea you're proposing is fine, actually so fine that we have already > partly implemented it in the latest JDK6 update releases :) The fix > itself is also fine from my perspective. > > Unfortunately, our implementation is slightly different - I'm not sure > if you have access to 6u10/6u12 sources, though - so if we integrate > your fix as proposed to OpenJDK, we'll have some troubles with upcoming > merge with 6u10/6u12 codebase... The only thing I'd suggest for you now > is to rewrite your fix using the same approach as we have. Hrmpf. Is this fix in OpenJDK6 already? Then I should be able to grab the stuff and see what I can do. OTOH, I probably don't care so much about this then. > BTW, to save your (and our) efforts next time, it may be worth notifying > everybody from this dev group about what you're going to start working > on - probably, someone else has almost implemented this in other manner. > This is by no means not a requirement, I'm just trying to avoid > conflicts like this in the future. Yeah, would be nice. I'm not sure how to do that though. Speaking of this, I'd like to get rid of those many initIDs() methods in public AWT classes some day, because I don't need them in the peer impls that I have, but they force me to be implemented w/ empty stubs. That's quite ugly IMO and can be avoided in most cases by doing the JNI ID initialization in the peer code that's actually using them. I know that there's the class un-/reloading problem to be thought about, but in most cases that is not an issue (e.g. a XYZButtonPeer.initIDs() can safely init Button fields, because the Button class is not unloaded as long as the XYZButtonPeer class is unloaded, etc). /Roman -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20090119/3c66693d/attachment.bin From Artem.Ananiev at Sun.COM Tue Jan 20 06:44:54 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Tue, 20 Jan 2009 17:44:54 +0300 Subject: [PATCH] ComponentAccessor In-Reply-To: <1232401498.7656.4.camel@moonlight> References: <1232115241.6255.12.camel@moonlight> <4974BBB9.8070108@sun.com> <1232401498.7656.4.camel@moonlight> Message-ID: <4975E366.90102@sun.com> Hi, Roman, Roman Kennke wrote: > Hi Artem, > >> the idea you're proposing is fine, actually so fine that we have already >> partly implemented it in the latest JDK6 update releases :) The fix >> itself is also fine from my perspective. >> >> Unfortunately, our implementation is slightly different - I'm not sure >> if you have access to 6u10/6u12 sources, though - so if we integrate >> your fix as proposed to OpenJDK, we'll have some troubles with upcoming >> merge with 6u10/6u12 codebase... The only thing I'd suggest for you now >> is to rewrite your fix using the same approach as we have. > > Hrmpf. Is this fix in OpenJDK6 already? Then I should be able to grab > the stuff and see what I can do. OTOH, I probably don't care so much > about this then. the changes I told about are not present in OpenJDK6 yet. >> BTW, to save your (and our) efforts next time, it may be worth notifying >> everybody from this dev group about what you're going to start working >> on - probably, someone else has almost implemented this in other manner. >> This is by no means not a requirement, I'm just trying to avoid >> conflicts like this in the future. > > Yeah, would be nice. I'm not sure how to do that though. > > Speaking of this, I'd like to get rid of those many initIDs() methods in > public AWT classes some day, because I don't need them in the peer impls > that I have, but they force me to be implemented w/ empty stubs. That's > quite ugly IMO and can be avoided in most cases by doing the JNI ID > initialization in the peer code that's actually using them. I know that > there's the class un-/reloading problem to be thought about, but in most > cases that is not an issue (e.g. a XYZButtonPeer.initIDs() can safely > init Button fields, because the Button class is not unloaded as long as > the XYZButtonPeer class is unloaded, etc). Right, initIDs look weird and should be moved to peer code when possible. However there are some cases when method IDs are stored for java.awt.* classes - see Java_java_awt_Font_initIDs() or Java_java_awt_FontMetrics_initIDs() for example. These cases should be carefully inspected and also moved to peer code. Thanks, Artem > /Roman From andrew.brygin at sun.com Tue Jan 20 09:04:06 2009 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Tue, 20 Jan 2009 17:04:06 +0000 Subject: hg: jdk7/awt/jdk: 6551075: screenshot image taken through clipboard on W2K terminal server is shifted Message-ID: <20090120170419.81899DC15@hg.openjdk.java.net> Changeset: 127e3269ee1f Author: bae Date: 2009-01-20 19:51 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/127e3269ee1f 6551075: screenshot image taken through clipboard on W2K terminal server is shifted Reviewed-by: dav, uta ! src/windows/native/sun/windows/awt_DataTransferer.cpp From Phil.Race at Sun.COM Tue Jan 20 11:12:19 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 20 Jan 2009 11:12:19 -0800 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <4974B1D2.6060204@redhat.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> <496B5EE9.8080400@redhat.com> <4974669F.9020004@sun.com> <497495D0.2050807@redhat.com> <49749FCC.4020904@sun.com> <4974B1D2.6060204@redhat.com> Message-ID: <49762213.3060801@sun.com> Omair Majid wrote: > Hi Artem, > > Artem Ananiev wrote: >> >> Note, to push the changes into OpenJDK you need a valid mercurial user >> (which is also the author of the corresponding revision) with the >> access to AWT workspace. Do you have one or need any help with this? >> > > I dont have commit access to mercurial. How do I go about getting access? See http://mail.openjdk.java.net/pipermail/swing-dev/2008-November/000334.html -phil. > > Thanks, > > Omair From Anthony.Petrov at Sun.COM Wed Jan 21 06:50:25 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Wed, 21 Jan 2009 17:50:25 +0300 Subject: One or many GraphicsConfiguration(s) per toplevel? Message-ID: <49773631.3090301@sun.com> Hello 2D and AWT teams, While working on the fix for 6783411 to enable re-parenting heavyweight components between toplevel windows, I found the Component.checkGD() method which verifies equality of GraphicsDevice's (by the way, a minor question: is it correct to check the equality of the GD (or GC) objects themselves rather than using their StringID's?). There's also an implementation of this method in the Container class that recursively calls this method for every child of the container. The question is: is it really possible for one toplevel to contain components having different GraphicsDevice's (and/or different GraphicsConfiguration's)? Or may I assume that all and every descendant components of a toplevel window use the same GC that the window uses (and therefore the Container.checkGD() may safely be removed)? -- best regards, Anthony From Anthony.Petrov at Sun.COM Wed Jan 21 07:01:50 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Wed, 21 Jan 2009 18:01:50 +0300 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <4974B0EE.8010003@redhat.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> <496B5EE9.8080400@redhat.com> <4974669F.9020004@sun.com> <497495D0.2050807@redhat.com> <4974A131.8080505@sun.com> <4974B0EE.8010003@redhat.com> Message-ID: <497738DE.9030207@sun.com> Hi Omair, I've just been thinking: shouldn't the test include a legal notice in the beginning of the file? Please use any existing test as an example. -- best regards, Anthony On 01/19/2009 07:57 PM Omair Majid wrote: > Hi Anthony, > > Anthony Petrov wrote: >> The fix looks fine (taking into account the changes suggested by >> Artem). I would also ask to remove the unneeded comment lines from the >> test code. The printout's, however, may safely be uncommented - this >> would be a useful information should the test ever fail. >> >> Please send the clean version of the latest patch to this mailing list >> for final reviewing. >> > > Patch is attached. It was diffed against jdk7 but should apply (with a > fuzz) to jdk6 as well. > > Cheers, > > Omair > From roman.kennke at aicas.com Wed Jan 21 07:17:20 2009 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 21 Jan 2009 16:17:20 +0100 Subject: One or many GraphicsConfiguration(s) per toplevel? In-Reply-To: <49773631.3090301@sun.com> References: <49773631.3090301@sun.com> Message-ID: <1232551040.6337.21.camel@moonlight> Hi Anthony, > While working on the fix for 6783411 to enable re-parenting heavyweight > components between toplevel windows, I found the Component.checkGD() > method which verifies equality of GraphicsDevice's (by the way, a minor > question: is it correct to check the equality of the GD (or GC) objects > themselves rather than using their StringID's?). There's also an > implementation of this method in the Container class that recursively > calls this method for every child of the container. > > The question is: is it really possible for one toplevel to contain > components having different GraphicsDevice's (and/or different > GraphicsConfiguration's)? Not sure, but in Xinerama-mode, when half of a window is on one screen and the other half on the other, I guess there could be components inside that have different GDs. /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 Anthony.Petrov at Sun.COM Wed Jan 21 07:37:34 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Wed, 21 Jan 2009 18:37:34 +0300 Subject: One or many GraphicsConfiguration(s) per toplevel? In-Reply-To: <1232551040.6337.21.camel@moonlight> References: <49773631.3090301@sun.com> <1232551040.6337.21.camel@moonlight> Message-ID: <4977413E.2070804@sun.com> Hi Roman, On 01/21/2009 06:17 PM Roman Kennke wrote: >> The question is: is it really possible for one toplevel to contain >> components having different GraphicsDevice's (and/or different >> GraphicsConfiguration's)? > > Not sure, but in Xinerama-mode, when half of a window is on one screen > and the other half on the other, I guess there could be components > inside that have different GDs. Yes, the components may physically be located on different screens, however I'm not 100% certain if they have different GD/GC from the point of view of Java at such moment. Hence the question. -- best regards, Anthony From Dmitri.Trembovetski at Sun.COM Wed Jan 21 09:40:06 2009 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 21 Jan 2009 09:40:06 -0800 Subject: [OpenJDK 2D-Dev] One or many GraphicsConfiguration(s) per toplevel? In-Reply-To: <4977413E.2070804@sun.com> References: <49773631.3090301@sun.com> <1232551040.6337.21.camel@moonlight> <4977413E.2070804@sun.com> Message-ID: <49775DF6.3090007@Sun.COM> Anthony Petrov wrote: > Hi Roman, > > On 01/21/2009 06:17 PM Roman Kennke wrote: >>> The question is: is it really possible for one toplevel to contain >>> components having different GraphicsDevice's (and/or different >>> GraphicsConfiguration's)? >> >> Not sure, but in Xinerama-mode, when half of a window is on one screen >> and the other half on the other, I guess there could be components >> inside that have different GDs. > Yes, the components may physically be located on different screens, > however I'm not 100% certain if they have different GD/GC from the point > of view of Java at such moment. Hence the question. AFAIK we only update the GC/GD on toplevel movement (not component movement), so all components inside a toplevel should have the same GC/GD (barring bugs). Thanks, Dmitri From Dmitri.Trembovetski at Sun.COM Wed Jan 21 09:43:31 2009 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 21 Jan 2009 09:43:31 -0800 Subject: [OpenJDK 2D-Dev] One or many GraphicsConfiguration(s) per toplevel? In-Reply-To: <49773631.3090301@sun.com> References: <49773631.3090301@sun.com> Message-ID: <49775EC3.90905@Sun.COM> Anthony Petrov wrote: > Hello 2D and AWT teams, > > While working on the fix for 6783411 to enable re-parenting heavyweight > components between toplevel windows, I found the Component.checkGD() > method which verifies equality of GraphicsDevice's (by the way, a minor > question: is it correct to check the equality of the GD (or GC) objects > themselves rather than using their StringID's?). There's also an Yes, it is better to check the instances. The GC is re-created on every display change, GDs may be added/removed as well (depending on what kind of event happend). > implementation of this method in the Container class that recursively > calls this method for every child of the container. > > The question is: is it really possible for one toplevel to contain > components having different GraphicsDevice's (and/or different > GraphicsConfiguration's)? Or may I assume that all and every descendant > components of a toplevel window use the same GC that the window uses > (and therefore the Container.checkGD() may safely be removed)? We should enforce that all components within a toplevel have the same GC. If checkGD does that I wouldn't remove it. Thanks, Dmitri From Anthony.Petrov at Sun.COM Wed Jan 21 10:03:46 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Wed, 21 Jan 2009 21:03:46 +0300 Subject: [OpenJDK 2D-Dev] One or many GraphicsConfiguration(s) per toplevel? In-Reply-To: <49775EC3.90905@Sun.COM> References: <49773631.3090301@sun.com> <49775EC3.90905@Sun.COM> Message-ID: <49776382.1040607@sun.com> Hi Dmitri, On 1/21/2009 8:43 PM Dmitri Trembovetski wrote: >> implementation of this method in the Container class that recursively >> calls this method for every child of the container. >> >> The question is: is it really possible for one toplevel to contain >> components having different GraphicsDevice's (and/or different >> GraphicsConfiguration's)? Or may I assume that all and every >> descendant components of a toplevel window use the same GC that the >> window uses (and therefore the Container.checkGD() may safely be >> removed)? > > We should enforce that all components within a toplevel have the > same GC. If checkGD does that I wouldn't remove it. "Asserts" are fine as long as they are simple and fast. But if we're sure we don't have several GC/GDs per toplevel window, then I don't see much reason to waste time recursively traversing the whole hierarchy of components of a container when it gets added to another container. Perhaps it would make sense to move the graphicsConfig member to the Window class and use its value for Component.getGraphicsConfiguration()? A component not currently contained in a toplevel window obviously should have a null GC. Thoughts? -- best regards, Anthony From Dmitri.Trembovetski at Sun.COM Wed Jan 21 10:16:06 2009 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 21 Jan 2009 10:16:06 -0800 Subject: [OpenJDK 2D-Dev] One or many GraphicsConfiguration(s) per toplevel? In-Reply-To: <49776382.1040607@sun.com> References: <49773631.3090301@sun.com> <49775EC3.90905@Sun.COM> <49776382.1040607@sun.com> Message-ID: <49776666.9090404@Sun.COM> Hi Anthony, Anthony Petrov wrote: > Hi Dmitri, > > On 1/21/2009 8:43 PM Dmitri Trembovetski wrote: >>> implementation of this method in the Container class that recursively >>> calls this method for every child of the container. >>> >>> The question is: is it really possible for one toplevel to contain >>> components having different GraphicsDevice's (and/or different >>> GraphicsConfiguration's)? Or may I assume that all and every >>> descendant components of a toplevel window use the same GC that the >>> window uses (and therefore the Container.checkGD() may safely be >>> removed)? >> >> We should enforce that all components within a toplevel have the >> same GC. If checkGD does that I wouldn't remove it. > "Asserts" are fine as long as they are simple and fast. But if we're > sure we don't have several GC/GDs per toplevel window, then I don't see > much reason to waste time recursively traversing the whole hierarchy of > components of a container when it gets added to another container. > > Perhaps it would make sense to move the graphicsConfig member to > the Window class and use its value for > Component.getGraphicsConfiguration()? A component not currently > contained in a toplevel window obviously should have a null GC. Thoughts? May not be a bad idea. The less copies of GC we have laying around the smaller chance it is that someone would use a stale version. The only consideration is that getting a GC is a very common operation, and traveling the hierarchy every time to retrieve it could result in performance degradation (wouldn't you need to grab the tree lock for that too?). Thanks, Dmitri From Anthony.Petrov at Sun.COM Wed Jan 21 11:23:03 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Wed, 21 Jan 2009 22:23:03 +0300 Subject: [OpenJDK 2D-Dev] One or many GraphicsConfiguration(s) per toplevel? In-Reply-To: <49776666.9090404@Sun.COM> References: <49773631.3090301@sun.com> <49775EC3.90905@Sun.COM> <49776382.1040607@sun.com> <49776666.9090404@Sun.COM> Message-ID: <49777617.40402@sun.com> On 1/21/2009 9:16 PM Dmitri Trembovetski wrote: >> Perhaps it would make sense to move the graphicsConfig member to >> the Window class and use its value for >> Component.getGraphicsConfiguration()? A component not currently >> contained in a toplevel window obviously should have a null GC. >> Thoughts? > > May not be a bad idea. The less copies of GC we have laying around > the smaller chance it is that someone would use a stale version. > > The only consideration is that getting a GC is a very common operation, > and traveling the hierarchy every time to retrieve it could > result in performance degradation (wouldn't you need to grab the tree > lock for that too?). Yeah, I see the point. Another option is to make the field private, create a final package-private getter (though why? we have a lovely public one already), and private setter. The setter would be invoked through the sun.awt.AWTAccessor by the toplevel window whenever its own GC gets changed (holding the TreeLock and traversing the whole hierarchy). It will also be assigned when adding a component to a container (by using the container's local copy of the gc - which we assume correct). This way we ensure there's only one value of gc in every single component in the given toplevel window at any moment of time. I guess changing the GC is not quite frequent operation to worry much about the performance of this approach? -- best regards, Anthony From Anthony.Petrov at Sun.COM Thu Jan 22 03:04:34 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Thu, 22 Jan 2009 14:04:34 +0300 Subject: [OpenJDK 2D-Dev] One or many GraphicsConfiguration(s) per toplevel? In-Reply-To: <49777617.40402@sun.com> References: <49773631.3090301@sun.com> <49775EC3.90905@Sun.COM> <49776382.1040607@sun.com> <49776666.9090404@Sun.COM> <49777617.40402@sun.com> Message-ID: <497852C2.7040608@sun.com> Hi Dmitri, On 01/21/2009 10:23 PM Anthony Petrov wrote: > Yeah, I see the point. Another option is to make the field private, > create a final package-private getter (though why? we have a lovely > public one already), and private setter. The setter would be invoked > through the sun.awt.AWTAccessor by the toplevel window whenever its own > GC gets changed (holding the TreeLock and traversing the whole > hierarchy). It will also be assigned when adding a component to a > container (by using the container's local copy of the gc - which we > assume correct). This way we ensure there's only one value of gc in > every single component in the given toplevel window at any moment of > time. I guess changing the GC is not quite frequent operation to worry > much about the performance of this approach? By the way, Canvases may be created with a non-default GC. How should these be treated then if we think we should have the same GC for every component in a Window? -- best regards, Anthony From Dmitri.Trembovetski at Sun.COM Thu Jan 22 09:40:21 2009 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 22 Jan 2009 09:40:21 -0800 Subject: [OpenJDK 2D-Dev] One or many GraphicsConfiguration(s) per toplevel? In-Reply-To: <497852C2.7040608@sun.com> References: <49773631.3090301@sun.com> <49775EC3.90905@Sun.COM> <49776382.1040607@sun.com> <49776666.9090404@Sun.COM> <49777617.40402@sun.com> <497852C2.7040608@sun.com> Message-ID: <4978AF85.2040607@Sun.COM> Anthony Petrov wrote: > Hi Dmitri, > > On 01/21/2009 10:23 PM Anthony Petrov wrote: >> Yeah, I see the point. Another option is to make the field private, >> create a final package-private getter (though why? we have a lovely >> public one already), and private setter. The setter would be invoked >> through the sun.awt.AWTAccessor by the toplevel window whenever its >> own GC gets changed (holding the TreeLock and traversing the whole >> hierarchy). It will also be assigned when adding a component to a >> container (by using the container's local copy of the gc - which we >> assume correct). This way we ensure there's only one value of gc in >> every single component in the given toplevel window at any moment of >> time. I guess changing the GC is not quite frequent operation to worry >> much about the performance of this approach? > > By the way, Canvases may be created with a non-default GC. How should > these be treated then if we think we should have the same GC for every > component in a Window? Hmm. Indeed, forgot about that. Canvas is pretty much a toplevel from this perspective. For Canvas it wasn't really meant to specify a location (like, which screen it appears on), but the visual of the window (or pixel format on windows). So we can modify our original suggestion, and treat Canvas as toplevel - allow it to have its own GC. But it's not clear what to do if its toplevel containing a canvas created with non-default GC is moved onto a different screen (or if a display change event happened which re-created all GCs). The only sensible option I see is to change it to the new default GC. This stuff was designed when there were no multiple screens, and it shows - at least, you couldn't move a window from one screen to another (windows didn't have multiscreen up until Win2k/WinXP, and xinerama was a rare beast back then). The bulk of multiscreen and display change support in Java was retrofitted later. Thanks, Dmitri From omajid at redhat.com Fri Jan 23 13:00:05 2009 From: omajid at redhat.com (Omair Majid) Date: Fri, 23 Jan 2009 16:00:05 -0500 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <497738DE.9030207@sun.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> <496B5EE9.8080400@redhat.com> <4974669F.9020004@sun.com> <497495D0.2050807@redhat.com> <4974A131.8080505@sun.com> <4974B0EE.8010003@redhat.com> <497738DE.9030207@sun.com> Message-ID: <497A2FD5.3080202@redhat.com> Hi all, Anthony Petrov wrote: > Hi Omair, > > I've just been thinking: shouldn't the test include a legal notice in > the beginning of the file? Please use any existing test as an example. > Whoops. Patch updated. Also, I wont be getting commit rights any time soon. So if this patch is ok, could someone please go ahead and commit it? Cheers, Omair -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: awt-x11-window-size.patch Url: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20090123/e402949c/attachment.ksh From Anthony.Petrov at Sun.COM Thu Jan 29 01:51:39 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Thu, 29 Jan 2009 12:51:39 +0300 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <497A2FD5.3080202@redhat.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> <496B5EE9.8080400@redhat.com> <4974669F.9020004@sun.com> <497495D0.2050807@redhat.com> <4974A131.8080505@sun.com> <4974B0EE.8010003@redhat.com> <497738DE.9030207@sun.com> <497A2FD5.3080202@redhat.com> Message-ID: <49817C2B.5040407@sun.com> Hi Omair, The fix looks fine, and I approve it. If Artem is OK with it also, he will push the fix in a while. Thank you for your contribution! -- best regards, Anthony On 01/24/2009 12:00 AM Omair Majid wrote: > Hi all, > > Anthony Petrov wrote: >> Hi Omair, >> >> I've just been thinking: shouldn't the test include a legal notice in >> the beginning of the file? Please use any existing test as an example. >> > > Whoops. Patch updated. Also, I wont be getting commit rights any time > soon. So if this patch is ok, could someone please go ahead and commit it? > > Cheers, > Omair > From artem.ananiev at sun.com Thu Jan 29 04:06:47 2009 From: artem.ananiev at sun.com (artem.ananiev at sun.com) Date: Thu, 29 Jan 2009 12:06:47 +0000 Subject: hg: jdk7/awt/jdk: 6721088: Bad window size calculation after using pack() Message-ID: <20090129120714.E809FE39B@hg.openjdk.java.net> Changeset: 9fa2e56c8a30 Author: art Date: 2009-01-29 14:58 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/9fa2e56c8a30 6721088: Bad window size calculation after using pack() Reviewed-by: anthony Contributed-by: Omair Majid ! src/solaris/classes/sun/awt/X11/WindowDimensions.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java + test/java/awt/Frame/FrameSize/TestFrameSize.java From Artem.Ananiev at Sun.COM Thu Jan 29 04:09:58 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Thu, 29 Jan 2009 15:09:58 +0300 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <49817C2B.5040407@sun.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> <496B5EE9.8080400@redhat.com> <4974669F.9020004@sun.com> <497495D0.2050807@redhat.com> <4974A131.8080505@sun.com> <4974B0EE.8010003@redhat.com> <497738DE.9030207@sun.com> <497A2FD5.3080202@redhat.com> <49817C2B.5040407@sun.com> Message-ID: <49819C96.2090707@sun.com> Anthony Petrov wrote: > Hi Omair, > > The fix looks fine, and I approve it. If Artem is OK with it also, he > will push the fix in a while. Thank you for your contribution! The fix has just been pushed into AWT workspace. Thank you for contribution. Artem > -- > best regards, > Anthony > > > On 01/24/2009 12:00 AM Omair Majid wrote: >> Hi all, >> >> Anthony Petrov wrote: >>> Hi Omair, >>> >>> I've just been thinking: shouldn't the test include a legal notice in >>> the beginning of the file? Please use any existing test as an example. >>> >> >> Whoops. Patch updated. Also, I wont be getting commit rights any time >> soon. So if this patch is ok, could someone please go ahead and commit >> it? >> >> Cheers, >> Omair >> From omajid at redhat.com Thu Jan 29 06:42:26 2009 From: omajid at redhat.com (Omair Majid) Date: Thu, 29 Jan 2009 09:42:26 -0500 Subject: [PATCH] Fix X11 window size calculation In-Reply-To: <49819C96.2090707@sun.com> References: <4967AA3C.2020704@redhat.com> <4969CA43.7010208@sun.com> <496B5EE9.8080400@redhat.com> <4974669F.9020004@sun.com> <497495D0.2050807@redhat.com> <4974A131.8080505@sun.com> <4974B0EE.8010003@redhat.com> <497738DE.9030207@sun.com> <497A2FD5.3080202@redhat.com> <49817C2B.5040407@sun.com> <49819C96.2090707@sun.com> Message-ID: <4981C052.3080204@redhat.com> Artem Ananiev wrote: > > Anthony Petrov wrote: >> Hi Omair, >> >> The fix looks fine, and I approve it. If Artem is OK with it also, he >> will push the fix in a while. Thank you for your contribution! > > The fix has just been pushed into AWT workspace. Thank you for > contribution. Glad I could help. Cheers, Omair