From Igor.Kushnirskiy at Sun.COM Mon Nov 12 16:57:48 2007 From: Igor.Kushnirskiy at Sun.COM (Igor Kushnirskiy) Date: Mon, 12 Nov 2007 11:57:48 -0500 Subject: 6480289 Replace ThreadPool creation code in SwingWorker with java.util.concurrent In-Reply-To: <22ec15240710220116x412a5751j8b60917e2e3cd989@mail.gmail.com> References: <22ec15240710220116x412a5751j8b60917e2e3cd989@mail.gmail.com> Message-ID: <4738860C.4010207@sun.com> Hi Matthias, Matthias Ernst wrote: > Hi, > > I don't know whether you guys still use jdk-collaboration[1], so I > double post here. > > I believe the fix is incomplete. The shutdown hook only > calls ExecutorService#shutdown but it also needs to call > #awaitTermination. #shutdown does not block. I've seen this > happen several times, the #shutdown method's naming is > unfortunate. Completely agree. A new bug was opened: 6628607 [SwingWorker's shutdownHook needs to call executorService.awaitTermination] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6628607 Thanks, Igor > > See the last example in > http://java.sun.com/javase/6/docs/api/java/util/concurrent/ExecutorService.html. > > Matthias > > [1] https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=21974&forumID=1463 From Jasper.Potts at Sun.COM Mon Nov 12 18:53:41 2007 From: Jasper.Potts at Sun.COM (Jasper Potts) Date: Mon, 12 Nov 2007 10:53:41 -0800 Subject: Fake-Opaque Swing Components References: <16B30056-92A2-4C30-8326-F2EA2E7A7068@Sun.COM> Message-ID: <335314A6-2076-4D58-8A83-A3D4DA71A514@sun.com> I have a problem with Nimbus that is common with other modern look and feels which we need to fix. The problem is how do setBackgound() and setForeground() map to how the component looks. ?Because of the some components having rounded corners and all components having 2px spacing for painting the focus glow. You end up with this background area around the component (in red above). The area is not really of color Component.getBackgound() as that has another meaning which is the background of the actual component content such as the text field background(in green above). The obvious solution to the problem is to make the component non- opaque. Which means the red area would be transparent. The issue with this is it the performance for opaque components is much worse so for components like a text field which needs to be very responsive as you type this could be a issue. Proposed Solution So the proposed solution is for the component to be opaque and the outer background area to be painted as before but be the parent components getBackgound() color. This seems the right answer but means a change at a low level. So what I propose is adding a UIManager property to turn this on and changing the ComponentUI.update () method from: public abstract class ComponentUI { ... public void update(Graphics g, JComponent c) { if (c.isOpaque()) { g.setColor(c.getBackground()); g.fillRect(0, 0, c.getWidth(),c.getHeight()); } paint(g, c); } ... } to: public abstract class ComponentUI { ... public void update(Graphics g, JComponent c) { if (c.isOpaque()) { if (UIManager.getBoolean ("Opaque.useParentBackgroundColor") && c.getParent() != null){ g.setColor(c.getParent().getBackground()); } else { g.setColor(c.getBackground()); } g.fillRect(0, 0, c.getWidth(),c.getHeight()); } paint(g, c); } ... } I am open for better suggestions for the UIManager key name but that is the basic idea. So what do you think?????? Thanks Jasper -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: component-colors.png Type: image/png Size: 8446 bytes Desc: not available URL: From kirillcool at yahoo.com Mon Nov 12 19:12:10 2007 From: kirillcool at yahoo.com (Kirill Grouchnikov) Date: Mon, 12 Nov 2007 11:12:10 -0800 (PST) Subject: Fake-Opaque Swing Components Message-ID: <858761.84247.qm@web52709.mail.re2.yahoo.com> Hi, Jasper Wouldn't that conflict with the optimizations made in the rendering pipeline? The component is still declared as opaque, but does not effectively paint all the pixels in its bounds. So, potentially you can have overlapping components (by design or during layout transitions) which will be cut off in that area around the visual painting of the components. In addition, this approach (as well as the existing one) doesn't address watermarking functionality. The issues with the performance can be addressed by repainting only the relevant area (such as caret does when it's blinking). Thanks Kirill ----- Original Message ---- From: Jasper Potts To: swing-dev at openjdk.java.net Sent: Monday, November 12, 2007 10:53:41 AM Subject: Fake-Opaque Swing Components I have a problem with Nimbus that is common with other modern look and feels which we need to fix. The problem is how do setBackgound() and setForeground() map to how the component looks. Because of the some components having rounded corners and all components having 2px spacing for painting the focus glow. You end up with this background area around the component (in red above). The area is not really of color Component.getBackgound() as that has another meaning which is the background of the actual component content such as the text field background(in green above). The obvious solution to the problem is to make the component non-opaque. Which means the red area would be transparent. The issue with this is it the performance for opaque components is much worse so for components like a text field which needs to be very responsive as you type this could be a issue. Proposed Solution So the proposed solution is for the component to be opaque and the outer background area to be painted as before but be the parent components getBackgound() color. This seems the right answer but means a change at a low level. So what I propose is adding a UIManager property to turn this on and changing the ComponentUI.update() method from: public abstract class ComponentUI { ... public void update(Graphics g, JComponent c) { if (c.isOpaque()) { g.setColor(c.getBackground()); g.fillRect(0, 0, c.getWidth(),c.getHeight()); } paint(g, c); } ... } to: public abstract class ComponentUI { ... public void update(Graphics g, JComponent c) { if (c.isOpaque()) { if (UIManager.getBoolean("Opaque.useParentBackgroundColor") && c.getParent() != null){ g.setColor(c.getParent().getBackground()); } else { g.setColor(c.getBackground()); } g.fillRect(0, 0, c.getWidth(),c.getHeight()); } paint(g, c); } ... } I am open for better suggestions for the UIManager key name but that is the basic idea. So what do you think?????? Thanks Jasper __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: component-colors.png Type: image/png Size: 8446 bytes Desc: not available URL: From Shannon.Hickey at Sun.COM Mon Nov 12 20:36:54 2007 From: Shannon.Hickey at Sun.COM (Shannon Hickey) Date: Mon, 12 Nov 2007 15:36:54 -0500 Subject: Fake-Opaque Swing Components In-Reply-To: <858761.84247.qm@web52709.mail.re2.yahoo.com> References: <858761.84247.qm@web52709.mail.re2.yahoo.com> Message-ID: <4738B966.7070003@sun.com> Hi Kirill, Kirill Grouchnikov wrote: > Hi, Jasper > > Wouldn't that conflict with the optimizations made in the rendering > pipeline? The component is still declared as opaque, but does not > effectively paint all the pixels in its bounds. Jasper's proposal WILL paint all pixels in its bounds. It simply mentions painting the outer edges in the parent background color. > So, potentially you can > have overlapping components (by design or during layout transitions) > which will be cut off in that area around the visual painting of the > components. In addition, this approach (as well as the existing one) > doesn't address watermarking functionality. > > The issues with the performance can be addressed by repainting only the > relevant area (such as caret does when it's blinking). Of course. Swing already tries to constrain the areas that it repaints. What Jasper refers to is the performance hit we'll take (although it's not quantified how much...Jasper?) by forcing painting to start at a higher level. Thanks! Shannon > > Thanks > Kirill > > ----- Original Message ---- > From: Jasper Potts > To: swing-dev at openjdk.java.net > Sent: Monday, November 12, 2007 10:53:41 AM > Subject: Fake-Opaque Swing Components > > I have a problem with Nimbus that is common with other modern look and > feels which we need to fix. The problem is how do setBackgound() and > setForeground() map to how the component looks. > Because of the some components having rounded corners and all components > having 2px spacing for painting the focus glow. You end up with this > background area around the component (in red above). The area is not > really of color Component.getBackgound() as that has another meaning > which is the background of the actual component content such as the text > field background(in green above). > > The obvious solution to the problem is to make the component non-opaque. > Which means the red area would be transparent. The issue with this is it > the performance for opaque components is much worse so for components > like a text field which needs to be very responsive as you type this > could be a issue. > > *P**roposed Solution* > So the proposed solution is for the component to be opaque and the outer > background area to be painted as before but be the parent components > getBackgound() color. This seems the right answer but means a change at > a low level. So what I propose is adding a UIManager property to turn > this on and changing the ComponentUI.update() method from: > > public abstract class ComponentUI { > ... > public void update(Graphics g, JComponent c) { > if (c.isOpaque()) { > g.setColor(c.getBackground()); > g.fillRect(0, 0, c.getWidth(),c.getHeight()); > } > paint(g, c); > } > ... > } > > to: > > public abstract class ComponentUI { > ... > public void update(Graphics g, JComponent c) { > if (c.isOpaque()) { > if (UIManager.getBoolean("Opaque.useParentBackgroundColor") && > c.getParent() != null){ > g.setColor(c.getParent().getBackground()); > } else { > g.setColor(c.getBackground()); > } > g.fillRect(0, 0, c.getWidth(),c.getHeight()); > } > paint(g, c); > } > ... > } > > I am open for better suggestions for the UIManager key name but that is > the basic idea. > > *So what do you think??????* > > Thanks > > Jasper > > -- Shannon Hickey shannon.hickey at sun.com Swing Team - Sun Microsystems, Inc. http://java.sun.com/javase/technologies/desktop From kirillcool at yahoo.com Mon Nov 12 20:42:06 2007 From: kirillcool at yahoo.com (Kirill Grouchnikov) Date: Mon, 12 Nov 2007 12:42:06 -0800 (PST) Subject: Fake-Opaque Swing Components Message-ID: <630769.72726.qm@web52705.mail.re2.yahoo.com> Shannon, My intent was that the component will paint pixels that don't really belong to it visually. While it will work for most of the application that have grid-like layouts, it will result in incorrect clipping of layout that use overlapping components. The same would apply for animating the layout changes where controls would slide from place to place - even if it happens for a fraction of second. And as far as i can tell from the rendering pipeline, a non-opaque component does not cause the entire parent to be repainted - only the relevant portion of the parent. While it still results in more repaints (especially if the parent itself is non-opaque), it shouldn't be that big of a problem. Thanks Kirill ----- Original Message ---- From: Shannon Hickey To: Kirill Grouchnikov Cc: swing-dev at openjdk.java.net Sent: Monday, November 12, 2007 12:36:54 PM Subject: Re: Fake-Opaque Swing Components Hi Kirill, Kirill Grouchnikov wrote: > Hi, Jasper > > Wouldn't that conflict with the optimizations made in the rendering > pipeline? The component is still declared as opaque, but does not > effectively paint all the pixels in its bounds. Jasper's proposal WILL paint all pixels in its bounds. It simply mentions painting the outer edges in the parent background color. > So, potentially you can > have overlapping components (by design or during layout transitions) > which will be cut off in that area around the visual painting of the > components. In addition, this approach (as well as the existing one) > doesn't address watermarking functionality. > > The issues with the performance can be addressed by repainting only the > relevant area (such as caret does when it's blinking). Of course. Swing already tries to constrain the areas that it repaints. What Jasper refers to is the performance hit we'll take (although it's not quantified how much...Jasper?) by forcing painting to start at a higher level. Thanks! Shannon > > Thanks > Kirill > > ----- Original Message ---- > From: Jasper Potts > To: swing-dev at openjdk.java.net > Sent: Monday, November 12, 2007 10:53:41 AM > Subject: Fake-Opaque Swing Components > > I have a problem with Nimbus that is common with other modern look and > feels which we need to fix. The problem is how do setBackgound() and > setForeground() map to how the component looks. > Because of the some components having rounded corners and all components > having 2px spacing for painting the focus glow. You end up with this > background area around the component (in red above). The area is not > really of color Component.getBackgound() as that has another meaning > which is the background of the actual component content such as the text > field background(in green above). > > The obvious solution to the problem is to make the component non-opaque. > Which means the red area would be transparent. The issue with this is it > the performance for opaque components is much worse so for components > like a text field which needs to be very responsive as you type this > could be a issue. > > *P**roposed Solution* > So the proposed solution is for the component to be opaque and the outer > background area to be painted as before but be the parent components > getBackgound() color. This seems the right answer but means a change at > a low level. So what I propose is adding a UIManager property to turn > this on and changing the ComponentUI.update() method from: > > public abstract class ComponentUI { > ... > public void update(Graphics g, JComponent c) { > if (c.isOpaque()) { > g.setColor(c.getBackground()); > g.fillRect(0, 0, c.getWidth(),c.getHeight()); > } > paint(g, c); > } > ... > } > > to: > > public abstract class ComponentUI { > ... > public void update(Graphics g, JComponent c) { > if (c.isOpaque()) { > if (UIManager.getBoolean("Opaque.useParentBackgroundColor") && > c.getParent() != null){ > g.setColor(c.getParent().getBackground()); > } else { > g.setColor(c.getBackground()); > } > g.fillRect(0, 0, c.getWidth(),c.getHeight()); > } > paint(g, c); > } > ... > } > > I am open for better suggestions for the UIManager key name but that is > the basic idea. > > *So what do you think??????* > > Thanks > > Jasper > > -- Shannon Hickey shannon.hickey at sun.com Swing Team - Sun Microsystems, Inc. http://java.sun.com/javase/technologies/desktop __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shannon.Hickey at Sun.COM Mon Nov 12 21:00:14 2007 From: Shannon.Hickey at Sun.COM (Shannon Hickey) Date: Mon, 12 Nov 2007 16:00:14 -0500 Subject: Fake-Opaque Swing Components In-Reply-To: <630769.72726.qm@web52705.mail.re2.yahoo.com> References: <630769.72726.qm@web52705.mail.re2.yahoo.com> Message-ID: <4738BEDE.6030608@sun.com> Hi Kirill, Kirill Grouchnikov wrote: > Shannon, > > My intent was that the component will paint pixels that don't really > belong to it visually. While it will work for most of the application > that have grid-like layouts, it will result in incorrect clipping of > layout that use overlapping components. The same would apply for > animating the layout changes where controls would slide from place to > place - even if it happens for a fraction of second. Completely agree. In fact, I'm personally not convinced of this proposal. I favor the correct use of isOpaque at this point. > > And as far as i can tell from the rendering pipeline, a non-opaque > component does not cause the entire parent to be repainted - only the > relevant portion of the parent. While it still results in more repaints > (especially if the parent itself is non-opaque), it shouldn't be that > big of a problem. I hope not. That's why I'm calling for concrete numbers. Thanks, Shannon > > Thanks > Kirill > > > ----- Original Message ---- > From: Shannon Hickey > To: Kirill Grouchnikov > Cc: swing-dev at openjdk.java.net > Sent: Monday, November 12, 2007 12:36:54 PM > Subject: Re: Fake-Opaque Swing Components > > Hi Kirill, > > Kirill Grouchnikov wrote: > > Hi, Jasper > > > > Wouldn't that conflict with the optimizations made in the rendering > > pipeline? The component is still declared as opaque, but does not > > effectively paint all the pixels in its bounds. > > Jasper's proposal WILL paint all pixels in its bounds. It simply > mentions painting the outer edges in the parent background color. > > > > So, potentially you can > > have overlapping components (by design or during layout transitions) > > which will be cut off in that area around the visual painting of the > > components. In addition, this approach (as well as the existing one) > > doesn't address watermarking functionality. > > > > The issues with the performance can be addressed by repainting only the > > relevant area (such as caret does when it's blinking). > > Of course. Swing already tries to constrain the areas that it repaints. > What Jasper refers to is the performance hit we'll take (although it's > not quantified how much...Jasper?) by forcing painting to start at a > higher level. > > Thanks! > Shannon > > > > > Thanks > > Kirill > > > > ----- Original Message ---- > > From: Jasper Potts > > > To: swing-dev at openjdk.java.net > > Sent: Monday, November 12, 2007 10:53:41 AM > > Subject: Fake-Opaque Swing Components > > > > I have a problem with Nimbus that is common with other modern look and > > feels which we need to fix. The problem is how do setBackgound() and > > setForeground() map to how the component looks. > > Because of the some components having rounded corners and all components > > having 2px spacing for painting the focus glow. You end up with this > > background area around the component (in red above). The area is not > > really of color Component.getBackgound() as that has another meaning > > which is the background of the actual component content such as the text > > field background(in green above). > > > > The obvious solution to the problem is to make the component non-opaque. > > Which means the red area would be transparent. The issue with this is it > > the performance for opaque components is much worse so for components > > like a text field which needs to be very responsive as you type this > > could be a issue. > > > > *P**roposed Solution* > > So the proposed solution is for the component to be opaque and the outer > > background area to be painted as before but be the parent components > > getBackgound() color. This seems the right answer but means a change at > > a low level. So what I propose is adding a UIManager property to turn > > this on and changing the ComponentUI.update() method from: > > > > public abstract class ComponentUI { > > ... > > public void update(Graphics g, JComponent c) { > > if (c.isOpaque()) { > > g.setColor(c.getBackground()); > > g.fillRect(0, 0, c.getWidth(),c.getHeight()); > > } > > paint(g, c); > > } > > ... > > } > > > > to: > > > > public abstract class ComponentUI { > > ... > > public void update(Graphics g, JComponent c) { > > if (c.isOpaque()) { > > if > (UIManager.getBoolean("Opaque.useParentBackgroundColor") && > > c.getParent() != null){ > > g.setColor(c.getParent().getBackground()); > > } else { > > g.setColor(c.getBackground()); > > } > > g.fillRect(0, 0, c.getWidth(),c.getHeight()); > > } > > paint(g, c); > > } > > ... > > } > > > > I am open for better suggestions for the UIManager key name but that is > > the basic idea. > > > > *So what do you think??????* > > > > Thanks > > > > Jasper > > > > > > -- > Shannon Hickey > shannon.hickey at sun.com > Swing Team - Sun Microsystems, Inc. > http://java.sun.com/javase/technologies/desktop > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com -- Shannon Hickey shannon.hickey at sun.com Swing Team - Sun Microsystems, Inc. http://java.sun.com/javase/technologies/desktop From fitzsim at redhat.com Thu Nov 22 20:32:02 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 22 Nov 2007 15:32:02 -0500 Subject: [PATCH] fix GTKLookAndFeel crash on recent versions of GTK Message-ID: <4745E742.9080400@redhat.com> Hi, With OpenJDK build b23, on recent GTK versions, showing a JComboBox when GTKLookAndFeel is active causes this assertion failure: (:11755): Gtk-WARNING **: Attempting to add a widget with type GtkButton to a GtkComboBoxEntry (need an instance of GtkEntry or of a subclass) The assertion was added in this commit: http://svn.gnome.org/viewcvs/gtk+?view=revision&revision=17657 Attached is a test case demonstrating the failure and a patch to fix it. The patch eliminates theme engines' ability to special-case the arrow button/text field combination but given the new assertion this appears to be the best option. Visually, JComboBox still looks fine under the theme engines shipped with Fedora 8. Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: GTKLookAndFeelComboBoxTest.java Type: text/x-java Size: 741 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-gtkplaf.patch Type: text/x-patch Size: 1175 bytes Desc: not available URL: From Alan.Bateman at Sun.COM Sun Nov 25 14:22:28 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 25 Nov 2007 14:22:28 +0000 Subject: [Fwd: Re: core-libs-dev Digest, Vol 7, Issue 8] Message-ID: <47498524.9040105@sun.com> I assume this was meant for swing-dev. -------------- next part -------------- An embedded message was scrubbed... From: Paulo Levi Subject: Re: core-libs-dev Digest, Vol 7, Issue 8 Date: Sat, 24 Nov 2007 23:18:19 +0000 Size: 7118 URL: From Kirill.Kirichenko at Sun.COM Tue Nov 27 12:51:03 2007 From: Kirill.Kirichenko at Sun.COM (Kirill Kirichenko) Date: Tue, 27 Nov 2007 15:51:03 +0300 Subject: [PATCH] fix GTKLookAndFeel crash on recent versions of GTK In-Reply-To: <4745E742.9080400@redhat.com> References: <4745E742.9080400@redhat.com> Message-ID: <474C12B7.3030002@sun.com> Hi Thomas. I'm responsible for GTK L&F. I's a bit straightforward way. At least we can add a GtkEntry there. We add Entry and Button in a ComboBoxEntry because we render JComboBox by parts in Java and in previous versions Entry and Button had to be in a ComboBoxEntry because they rendered differently if their parent was a ComboBoxEntry. Best way here is to find out how ArrowButtons are rendered in native gtk and do the same in our code. Unfortunately I'm busy at another project for 100% of my time. Such are priorities. It you find another solution I'd like to have a look. Thanks for your comments. Kirill Thomas Fitzsimmons wrote: > Hi, > > With OpenJDK build b23, on recent GTK versions, showing a JComboBox when > GTKLookAndFeel is active causes this assertion failure: > > (:11755): Gtk-WARNING **: Attempting to add a widget with type > GtkButton to a GtkComboBoxEntry (need an instance of GtkEntry or of a > subclass) > > The assertion was added in this commit: > > http://svn.gnome.org/viewcvs/gtk+?view=revision&revision=17657 > > Attached is a test case demonstrating the failure and a patch to fix > it. The > patch eliminates theme engines' ability to special-case the arrow > button/text > field combination but given the new assertion this appears to be the best > option. Visually, JComboBox still looks fine under the theme engines > shipped > with Fedora 8. > > Tom >