From Marek.Slama at Sun.COM Thu Nov 6 03:17:22 2008 From: Marek.Slama at Sun.COM (Marek Slama) Date: Thu, 06 Nov 2008 12:17:22 +0100 Subject: Bad component spacing Message-ID: <4912D242.1010404@sun.com> Hello, we encounter problem with too big spacing around text in Swing components in openjdk. I attach 2 snapshots of MenuLookDemo on openjdk and Sun JDK 6u10 on Ubuntu 8.10/Metal L&F. I was pointed to this maling list. Is it known problem? I do not know if it is specific to Ubuntu only. java version "1.6.0_10" Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) java version "1.6.0_0" IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) Both use the same font: javax.swing.plaf.FontUIResource[family=Dialog,name=Dialog,style=bold,size=12] Original issue report is https://bugs.launchpad.net/bugs/289784 Thanks Marek -------------- next part -------------- A non-text attachment was scrubbed... Name: menu-openjdk1.png Type: image/png Size: 6863 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20081106/9951d2f3/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: menu-openjdk2.png Type: image/png Size: 15206 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20081106/9951d2f3/attachment-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: menu-sunjdk1.png Type: image/png Size: 6538 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20081106/9951d2f3/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: menu-sunjdk2.png Type: image/png Size: 15200 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20081106/9951d2f3/attachment-0003.png From Artem.Ananiev at Sun.COM Thu Nov 6 04:27:27 2008 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Thu, 06 Nov 2008 15:27:27 +0300 Subject: Bad component spacing In-Reply-To: <4912D242.1010404@sun.com> References: <4912D242.1010404@sun.com> Message-ID: <4912E2AF.6090708@sun.com> Hi, Marek, as your test uses Swing menus, it looks like a Swing (or probably Java2D, because of font metrics) problem, rather than AWT one. Thanks, Artem Marek Slama wrote: > Hello, > > we encounter problem with too big spacing around text in Swing > components in openjdk. I attach > 2 snapshots of MenuLookDemo on openjdk and Sun JDK 6u10 on Ubuntu > 8.10/Metal L&F. I was pointed > to this maling list. Is it known problem? I do not know if it is > specific to Ubuntu only. > > java version "1.6.0_10" > Java(TM) SE Runtime Environment (build 1.6.0_10-b33) > Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) > > java version "1.6.0_0" > IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) > OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) > > Both use the same font: > javax.swing.plaf.FontUIResource[family=Dialog,name=Dialog,style=bold,size=12] > > > Original issue report is https://bugs.launchpad.net/bugs/289784 > > Thanks > > Marek From Igor.Nekrestyanov at Sun.COM Thu Nov 6 09:47:40 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Thu, 06 Nov 2008 20:47:40 +0300 Subject: [OpenJDK 2D-Dev] Bad component spacing In-Reply-To: <4912E2AF.6090708@sun.com> References: <4912D242.1010404@sun.com> <4912E2AF.6090708@sun.com> Message-ID: <49132DBC.5080106@sun.com> This is likely to be same as http://monaco.sfbay.sun.com/detail.jsf?cr=6761856 that was recently fixed and did not make it into main openjdk ws yet but you can pull these changes from 2D workspace to test. -igor Artem Ananiev wrote: > Hi, Marek, > > as your test uses Swing menus, it looks like a Swing (or probably > Java2D, because of font metrics) problem, rather than AWT one. > > Thanks, > > Artem > > Marek Slama wrote: >> Hello, >> >> we encounter problem with too big spacing around text in Swing >> components in openjdk. I attach >> 2 snapshots of MenuLookDemo on openjdk and Sun JDK 6u10 on Ubuntu >> 8.10/Metal L&F. I was pointed >> to this maling list. Is it known problem? I do not know if it is >> specific to Ubuntu only. >> >> java version "1.6.0_10" >> Java(TM) SE Runtime Environment (build 1.6.0_10-b33) >> Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) >> >> java version "1.6.0_0" >> IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) >> OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) >> >> Both use the same font: >> javax.swing.plaf.FontUIResource[family=Dialog,name=Dialog,style=bold,size=12] >> >> >> Original issue report is https://bugs.launchpad.net/bugs/289784 >> >> Thanks >> >> Marek From mark at klomp.org Fri Nov 7 05:05:47 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 07 Nov 2008 14:05:47 +0100 Subject: [OpenJDK 2D-Dev] Bad component spacing In-Reply-To: <49132DBC.5080106@sun.com> References: <4912D242.1010404@sun.com> <4912E2AF.6090708@sun.com> <49132DBC.5080106@sun.com> Message-ID: <1226063147.3310.12.camel@dijkstra.wildebeest.org> Hi, On Thu, 2008-11-06 at 20:47 +0300, Igor Nekrestyanov wrote: > This is likely to be same as > http://monaco.sfbay.sun.com/detail.jsf?cr=6761856 > that was recently fixed and did not make it into main openjdk ws yet but > you can pull these changes from 2D workspace to test. For those in the community without access to internal sun machines this is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6761856 and: http://hg.openjdk.java.net/jdk7/2d-gate/jdk/rev/9cdababf6179 This was also reported against IcedTea as: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=227 I have imported the patch into IcedTea6 and tested that it fixes the mentioned issues: 2008-10-29 Mark Wielaard * patches/icedtea-6761856-freetypescaler.patch: New patch. * Makefile.am (ICEDTEA_PATCHES): Add new patch. * HACKING: Document new patch. Cheers, Mark From Igor.Nekrestyanov at Sun.COM Fri Nov 7 06:10:14 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Fri, 07 Nov 2008 17:10:14 +0300 Subject: [OpenJDK 2D-Dev] Bad component spacing In-Reply-To: <1226063147.3310.12.camel@dijkstra.wildebeest.org> References: <4912D242.1010404@sun.com> <4912E2AF.6090708@sun.com> <49132DBC.5080106@sun.com> <1226063147.3310.12.camel@dijkstra.wildebeest.org> Message-ID: <49144C46.9090303@sun.com> Thank you Mark! i keep forgetting that bug database is not available to everyone yet :( -igor Mark Wielaard wrote: > Hi, > > On Thu, 2008-11-06 at 20:47 +0300, Igor Nekrestyanov wrote: > >> This is likely to be same as >> http://monaco.sfbay.sun.com/detail.jsf?cr=6761856 >> that was recently fixed and did not make it into main openjdk ws yet but >> you can pull these changes from 2D workspace to test. >> > > For those in the community without access to internal sun machines this > is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6761856 > and: http://hg.openjdk.java.net/jdk7/2d-gate/jdk/rev/9cdababf6179 > > This was also reported against IcedTea as: > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=227 > > I have imported the patch into IcedTea6 and tested that it fixes the > mentioned issues: > > 2008-10-29 Mark Wielaard > > * patches/icedtea-6761856-freetypescaler.patch: New patch. > * Makefile.am (ICEDTEA_PATCHES): Add new patch. > * HACKING: Document new patch. > > Cheers, > > Mark > > From Marek.Slama at Sun.COM Fri Nov 7 06:22:02 2008 From: Marek.Slama at Sun.COM (Marek Slama) Date: Fri, 07 Nov 2008 15:22:02 +0100 Subject: [OpenJDK 2D-Dev] Bad component spacing In-Reply-To: <49132DBC.5080106@sun.com> References: <4912D242.1010404@sun.com> <4912E2AF.6090708@sun.com> <49132DBC.5080106@sun.com> Message-ID: <49144F0A.4080902@sun.com> Igor Nekrestyanov wrote: > This is likely to be same as > http://monaco.sfbay.sun.com/detail.jsf?cr=6761856 > that was recently fixed and did not make it into main openjdk ws yet > but you can pull these changes from 2D workspace to test. > I can confirm spacing issue is fixed. I tested on 2D workspace. Marek > -igor > > Artem Ananiev wrote: >> Hi, Marek, >> >> as your test uses Swing menus, it looks like a Swing (or probably >> Java2D, because of font metrics) problem, rather than AWT one. >> >> Thanks, >> >> Artem >> >> Marek Slama wrote: >>> Hello, >>> >>> we encounter problem with too big spacing around text in Swing >>> components in openjdk. I attach >>> 2 snapshots of MenuLookDemo on openjdk and Sun JDK 6u10 on Ubuntu >>> 8.10/Metal L&F. I was pointed >>> to this maling list. Is it known problem? I do not know if it is >>> specific to Ubuntu only. >>> >>> java version "1.6.0_10" >>> Java(TM) SE Runtime Environment (build 1.6.0_10-b33) >>> Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) >>> >>> java version "1.6.0_0" >>> IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) >>> OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) >>> >>> Both use the same font: >>> javax.swing.plaf.FontUIResource[family=Dialog,name=Dialog,style=bold,size=12] >>> >>> >>> Original issue report is https://bugs.launchpad.net/bugs/289784 >>> >>> Thanks >>> >>> Marek > From Andrei.Dmitriev at Sun.COM Wed Nov 12 06:29:58 2008 From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev) Date: Wed, 12 Nov 2008 17:29:58 +0300 Subject: [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: <491AE866.10605@sun.com> Hi Roman, here are some comments on the patch. 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. The same for the following classes: src/share/classes/java/awt/peer/ChoicePeer.java file. src/share/classes/java/awt/peer/FileDialogPeer.java src/share/classes/java/awt/peer/FramePeer.java src/share/classes/java/awt/peer/LabelPeer.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/PopupMenuPeer.java src/share/classes/java/awt/peer/ScrollPanePeer.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 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. 3) Common thing. true have a shorter synonym since JDK 5: {@code true} 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. 5) src/share/classes/java/awt/peer/RobotPeer.java public int getNumberOfButtons(); has left w/o any comments. 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". 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? 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); The rest is just fine! Finally I've applied the patch and reviewed the webrev. It was just more convenient for me. There was an exception for ComponentPeer.java - it caused some conflicts and I didn't succeeded to resolve them fast enough so just looked on the patch itself for that file. At last the JDK7 workspace was successfully built. Thanks, 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 roman.kennke at aicas.com Wed Nov 12 06:52:29 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 12 Nov 2008 15:52:29 +0100 Subject: [PATCH] Cleanup AWT peer interfaces In-Reply-To: <491AE866.10605@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> Message-ID: <1226501549.21659.17.camel@moonlight> Hi Anrei, Thanks for reviewing! I comment on your comments below: > 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. Hmm, this was most likely added by Eclipse. No, {@link...} doesn't require this. I'll remove it. > 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. I'll fix this. > 3) Common thing. > true have a shorter synonym since JDK 5: {@code true} Oh cool. Didn't know that. I'll fix this too. > 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. Oh hmm. Don't know what happened here. I'll remove the mods. > 5) src/share/classes/java/awt/peer/RobotPeer.java > public int getNumberOfButtons(); has left w/o any comments. Oops. Needs fixing. > 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". Ok, sounds better. > 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. Many modern applications do stuff like this: public void paint(Graphics g) { Graphics2D g2d = (Graphics2D) g; g.doFancyStuff(); } This will break when we let peers return plain Graphics objects. I don't have specific examples, but from my time as GNU Classpath developer I know that quite alot of applications do the above thing, without checking type. Even the Java2D/Swing tutorials from Sun advertise this. The thing is that the official API in java.awt.Component only says java.awt.Graphics, and that has probably been left that way for eternal backwards compatibility ;-) We can't change this, but we can change the internal peer interface. > We > probably need to introduce another peer for that, right? No, why? > 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); > Yeah, the answer is similar to 7 too: there are many apps out that expect exactly this behaviour, so we should probably give them what they want. Can't change the public API, but we can change the peers. > The rest is just fine! > > Finally I've applied the patch and reviewed the webrev. It was just more > convenient for me. > There was an exception for ComponentPeer.java - it caused some conflicts > and I didn't succeeded to resolve them fast enough so just looked on the > patch itself for that file. > At last the JDK7 workspace was successfully built. Cool. I'll do the suggested changes and post another webrev for final review. /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 Wed Nov 12 07:07:40 2008 From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev) Date: Wed, 12 Nov 2008 18:07:40 +0300 Subject: [PATCH] Cleanup AWT peer interfaces In-Reply-To: <1226501549.21659.17.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> <1226501549.21659.17.camel@moonlight> Message-ID: <491AF13C.5030009@sun.com> Roman, >> 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. > > Many modern applications do stuff like this: > > public void paint(Graphics g) { > Graphics2D g2d = (Graphics2D) g; > g.doFancyStuff(); > } > > This will break when we let peers return plain Graphics objects. I don't > have specific examples, but from my time as GNU Classpath developer I > know that quite alot of applications do the above thing, without > checking type. Even the Java2D/Swing tutorials from Sun advertise this. > > The thing is that the official API in java.awt.Component only says > java.awt.Graphics, and that has probably been left that way for eternal > backwards compatibility ;-) We can't change this, but we can change the > internal peer interface. Thanks for that clarification. > >> We >> probably need to introduce another peer for that, right? > > No, why? Oh, please ignore that. You described that pretty clear. Regards, Andrei > > >> 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); >> > > Yeah, the answer is similar to 7 too: there are many apps out that > expect exactly this behaviour, so we should probably give them what they > want. Can't change the public API, but we can change the peers. > >> The rest is just fine! >> >> Finally I've applied the patch and reviewed the webrev. It was just more >> convenient for me. >> There was an exception for ComponentPeer.java - it caused some conflicts >> and I didn't succeeded to resolve them fast enough so just looked on the >> patch itself for that file. >> At last the JDK7 workspace was successfully built. > > Cool. I'll do the suggested changes and post another webrev for final > review. > > /Roman > From artem.ananiev at sun.com Wed Nov 26 05:33:59 2008 From: artem.ananiev at sun.com (artem.ananiev at sun.com) Date: Wed, 26 Nov 2008 13:33:59 +0000 Subject: hg: jdk7/awt/jdk: 6699589: java/awt/EventQueue/PostEventOrderingTest.java fails Message-ID: <20081126133420.00AD9DC75@hg.openjdk.java.net> Changeset: 9daa41eca0d9 Author: art Date: 2008-11-26 16:25 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/9daa41eca0d9 6699589: java/awt/EventQueue/PostEventOrderingTest.java fails Reviewed-by: dav, anthony ! src/share/classes/sun/awt/SunToolkit.java