Swing Actions + Icons + Menus

Hello swing-dev Recently we discussed this blog http://cafe.elharo.com/java/menu-icons-considered-ugly/ and didn't come to a unified conclusion There were two opposite opinion about actions + icons + menus = First opinion = The statement "Menu Icons Considered Ugly" is a personal opin

Re: Updating a JComboBox's values at popup-opening-time

Hello Clemens It sounds very similar to the bug 4743225 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225 As far as I know there is no any good workaround for this problem, sorry alexp Hello, This is both a question and (if its really a problem) maybe an idea for enhancement. I'v

Re: Updating a JComboBox's values at popup-opening-time

Hello Clemens It sounds very similar to the bug 4743225 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225 As far as I know there is no any good workaround for this problem, sorry alexp Hello, This is both a question and (if its really a problem) maybe an idea for enhancement. I'v

Re: Updating a JComboBox's values at popup-opening-time

Yet another option is to call BasicComboBoxUI.getAccessibleChild() passing 0 as the second parameter. Here you don't have any guarantees that it won't break under the future JDK versions, but that would be also highly unlikely. Kirill - Original Message From: Alexander Potochkin <[EMAIL PROTE

Re: 6179357: Request interface javax.swing.tree.TreeModel to have a generic type for nodes

Hello Florian Welcome to the swing-dev The RFE #6179357 is definitely worth investigating we was going to generify Swing for 1.6 but unfortunately didn't have enough time Your fixes are welcome Here is the information how to contribute: http://openjdk.java.net/contribute/ For now the process

Re: 6179357: Request interface javax.swing.tree.TreeModel to have a generic type for nodes

ated questions Thanks alexp I'will post to this list again when there are more news or questions arise. -Florian |Alexander Potochkin schrieb: Hello Florian Welcome to the swing-dev The RFE #6179357 is definitely worth investigating we was going to generify Swing for 1.6 but unfortunately

Re: @version conventions

Hello Florian Hi, what are the conventions for the @version tag? How do you increment versions? What is the used date format? All tags will be removed when we move to Mercurial version system so you don't have to update it Thanks alexp Thanks. -Florian

Re: 6179357-related: Working on warnings removal

s arise. -Florian |Alexander Potochkin schrieb: Hello Florian Welcome to the swing-dev The RFE #6179357 is definitely worth investigating we was going to generify Swing for 1.6 but unfortunately didn't have enough time Your fixes are welcome Here is the information how to contribute

Re: [PATCH] 6179357-related: Working on warnings removal

ks alexp -Florian ** -Florian Alexander Potochkin schrieb: Hello Florian Hi, I decided first to remove some warning for trivial cases, since even if I compile with -Xlint:-serial -Xlint:-deprecation -Xlint:-cast -Xlint:-fallthrough -Xmaxwarns 1200 I get 977 warnings! And since most of

Re: Bug 6499857: JMenuItem.getRootPane() returns null

Hello Miguel I plan to fix bug 6499857. There are a couple of approaches, but I think I know the best way to fix it. Has anybody else looked at this? Currently no one works on this fix so you are welcome to start with it ! Thanks alexp -- Miguel Muñoz ___ There are 10 ki

Re: Bug 6499857: JMenuItem.getRootPane() returns null

Unit Thanks alexp -- Miguel Muñoz On Sep 20, 2007, at 6:55 AM, Alexander Potochkin wrote: Hello Miguel I plan to fix bug 6499857. There are a couple of approaches, but I think I know the best way to fix it. Has anybody else looked at this? Currently no one works on this fix so you are we

Re: Bug 6499857: JMenuItem.getRootPane() returns null

If that works, it would be a better fix, because it would fix all four of the methods above, as well as every individual developer's parent=parent.getParent() loop. It would be really great to investigate all of that questions Thanks alexp -- Miguel */Alexander Potochkin <[EMAIL

Re: Bug 6499857: JMenuItem.getRootPane() returns null

RootPane from a JMenuItem, but it has a parent when I call it from a JButton. I don't know where it's value gets set yet, but I'm investigating. Ok Thanks alexp -- Miguel Muñoz */Alexander Potochkin <[EMAIL PROTECTED]>/* wrote: Hello Miguel > http://bugs

Re: [PATCH] 6179357-related: Working on warnings removal

the basis to add generics support to the Swing framework and I will try to further reduce the number of warnings once I started with this task. I'll look into it next week Thanks for you work ! alexp -Florian Alexander Potochkin schrieb: Hello Florian Hi, here's my first p

Re: JViewport fixlet

Hello Roman Ping! Any opinion on this? Sorry for delay This code is obsolete I absolutely agree with you I particularly like the comment from this metod: * do the song and dance to avoid allocating * a Rectangle object This kind of optimization is gone We should fix it to make our code be

Re: Two Gtk-LNF bugs+fixes

Hello Clemens I just want to say thank you for being with us and sorry for the late response Our super-busy days are getting over and we'll be more responsive so please keep sending your valuable feedback Thanks again alexp Hi Kirill, It's me you're talking about. You're absolutely right ab

Re: Two Gtk-LNF bugs+fixes

alexp lg Clemens 2008/1/16, Alexander Potochkin <[EMAIL PROTECTED]>: Hello Clemens I just want to say thank you for being with us and sorry for the late response Our super-busy days are getting over and we'll be more responsive so please keep sending your valuable feedback Thanks

Re: Possible bug - buttons do not regain rollover state after reenabling

Hello Martin Your observation is correct, Swing doesn't count a button as rollovered if it was disabled and enabled again (actually I haven't seen a GUI library which is ready for such situations) This problem very rare affects anybody so I'd see it as a Swing limitation (however limitation is a

Re: [TEST CASE] 6219960 NullPointer on ToolTipManager.mouseEntered

Hello Jason Your test case is really helpful, thank you very much I reopened this bug and upgraded its priority Thanks again alexp Bug 6219960 has marked Closed, will not be fixed because the evaluator could not create a test case. Attached is a test case that will produce the null pointer

Re: [PATCH] 6219960 NullPointer on ToolTipManager.mouseEntered

Hello Jason Reordered some statements for this final patch. Thank you I'll have a look on Monday see you alexp Jason Test your Star IQ Play now!

Re: JViewport Performance issues

Hello Chen Thanks for the information I wonder if JViewport in the BACKINGSTORE_SCROLL_MODE works better in this case? Could you please give more details about the workaround from JadeDisplay which you mentioned below ? Thanks alexp Hello Swing Dev, Could we get some visibility on bugs

Re: Compilation problems

Hello Florian Have you read this FAQ http://hg.openjdk.java.net/jdk7/2d/raw-file/8a275f439862/README-builds.html there also some blogs about building OpenJDK can be found in the internet I am not sure it is possible to build the Swing only I would try to build the whole JDK project Thanks alex

Re: [PATCH] Make RepaintManager more portable

Hello Roman Hi there, how can we go about getting this patch into OpenJDK mainline? Sorry for delay The fix looks good, I see no reasons why not to push it to openJDK 6 I filed an RFE #6759311 RepaintManager casts Tookit to SunToolkit without instanceof check It usually requires a couple o

Re: [PATCH] Make RepaintManager more portable

Hello Roman Hello Alexander, The fix looks good, I see no reasons why not to push it to openJDK 6 Thanks. I suppose you mean JDK7? I thought external contributors can only push fixes to openJDK 6, having it in JDK 7 is fine also I filed an RFE #6759311 RepaintManager casts Tookit to Su

Re: [PATCH] Make RepaintManager more portable

Hello Roman Hi Alexander, The fix looks good, I see no reasons why not to push it to openJDK 6 Thanks. I suppose you mean JDK7? I thought external contributors can only push fixes to openJDK 6, having it in JDK 7 is fine also There's not even a public JDK6 repository. And it doesn't make a

Re: are you there ...

Hello Octavian What are you guys working on? We are working on Swing bugs (consulting, evaluating and fixing) and Swing features (e.g. JSR 295 & 296) please let me know if need any specific information Thanks alexp --Octavian

Re: 6179357: Generics: JList: getSelectedValues

Hello Florian So, does everybody agree? Would be great to also have opinions from someone working at Sun? Sorry for delay public E[] getSelectedValues() looks ok at the first glance (but I didn't do all testing) there is no way to create a generified array like this: E[] array = new E[10];

Re: 6179357: Generics: JList: getSelectedValues

Hello Tom but you can use the following workaround: @SuppressWarnings("unchecked") E[] array = (E[])new Object[10]; Consider this client code: JList list = ...; String[] strs = list.getSelectedValues(); In that code you have a ClassCastException from Object[] to String[]. Unfortun

Re: 6179357: Generics: JList: Constructors & Model

Hello Florian I am sorry if I ask this question too late, but what is the main reason of generifiying these components? It is quite difficult to make it right because we have some difficult to generify public API. If JList and JComboBox are mostly used with Strings values there is an approach #

Re: [PATCH] DefaultDesktopPane fix

Hello Roman I found a problem in DefaultDesktopPane. Dragging in fast mode does not work correctly (at least not on all platforms) if the pane is obscured by another heavyweight. Graphics.copyArea() isn't guaranteed to work correctly in this case. This looks like a bug to me, could you please

Re: [PATCH] DefaultDesktopPane fix

Hello Roman Hi Alexander, I found a problem in DefaultDesktopPane. Dragging in fast mode does not work correctly (at least not on all platforms) if the pane is obscured by another heavyweight. Graphics.copyArea() isn't guaranteed to work correctly in this case. This looks like a bug to me, c

Re: Swing Group Status?

Hello Florian Hi, I posted several e-mails the past 2 weeks but unfortunatly the only response from Sun was some shorts thoughts from Alexander Potochkin. Now, I don't want to blame anyone (I cannot always react as fast as I would like to, myself), but for the better understanding:

Re: Swing Group Status?

or your support alexp -Florian Alexander Potochkin schrieb: Hello Florian Hi, I posted several e-mails the past 2 weeks but unfortunatly the only response from Sun was some shorts thoughts from Alexander Potochkin. Now, I don't want to blame anyone (I cannot always react as fast

Re: 6179357: Generics: JList: ListCellRenderer & prototypeCellValue

Hello Florian I must confess that I don't think it is desirable to generify every class in Swing, so #1 looks good for me :-) Two generic parameters add to much of typing, in my opinion Could you please provide a complete example of a JList with a custom ListCellRenderer that proves that render

Re: 6179357: Generics: JList: ListCellRenderer & prototypeCellValue

Hello Tom It's nice to see you here Could you please provide a complete example of a JList with a custom ListCellRenderer that proves that renderer should be generified I bet if you used NetBeans to find implementations of ListCellRenderer even within the JDK most useful implementations wou

Re: 6179357: Generics: JList: ListCellRenderer & prototypeCellValue

ell renderer is used.) -Florian Am Dienstag, 3. März 2009 schrieb Alexander Potochkin: Hello Tom It's nice to see you here Could you please provide a complete example of a JList with a custom ListCellRenderer that proves that renderer should be generified I bet if you used NetBeans to fi

Re: 6179357: Generics: JList: ListCellRenderer & prototypeCellValue

; types than String, such as Integer, Long and Short, can profit from generics. It also shows why JList should specify ListCellRenderer cellRenderer rather than ListCellRenderer cellRenderer (Here: a common Number-cell renderer is used.) -Florian Am Dienstag, 3. März 2009 schrieb Alexander P

Re: 6179357: Generics: JList: Constructors & Model

Hi Florian, I'd like more consistent variant #2 because of the javax.swing.ComboBoxModel#setSelectedItem() method prevents to use construction like "" in the JComboBox class (as you noticed before)... I second Pavel, "" doesn't work well for getters/setters #2 is preferable Thanks alexp

Re: [PATCH] 6179357: Generics: JList

Hello Florian Great! :-) In the case of other issues please note that I'm on holiday until the end of next week. Have a nice holiday! (I am reviewing the fix right now) Thanks alexp -Florian Pavel Porvatov schrieb: Hi Florian, Hi Pavel, I agree that we should avoid to mix several d

Re: [PATCH] 6179357: Generics: JList

anks alexp -Florian Alexander Potochkin schrieb: Hello Florian Great! :-) In the case of other issues please note that I'm on holiday until the end of next week. Have a nice holiday! (I am reviewing the fix right now) Thanks alexp -Florian Pavel Porvatov schrieb: Hi Florian,

Re: JColorChooser on GTK (GTKColorChooserPanel)

Hello Elliott Thanks for signing SCA! Lots of Swing team members very busy with the JavaOne conference, so please allow some delays in communication I personally taking couple of weeks for vacation after the conference, will be back with you after that Thanks again alexp On Wed, May 27, 2009

Re: Background/Foreground colors and Gtk Look and Feel

Hello Gentlemen The truth is that L&F can completely ignore the background and foreground properties see JComponent.setBackground() javadoc: * It is up to the look and feel to honor this property, some may * choose to ignore it. So for reliable implementation I'd recommend to choos

Re: Word wrap broken in JTextArea

Hello Lillian I am sorry for delay, most of the people just returned from vacations the fix will be reviewed shortly! Thanks for your support alexp Lillian Angel wrote: Andrew John Hughes wrote: 2009/6/16 Lillian Angel : Hi, I posted a bug report, including a testcase and webrev here fo

Re: Background/Foreground colors and Gtk Look and Feel

Hello Joel If you just need to have a multiple line JLabel, you may be interested in following discussion: http://www.coderanch.com/t/338648/Swing-AWT-SWT-JFace/java/Multiple-lines-JLabel Thanks alexp Thus spake Alexander Potochkin: Hello Gentlemen The truth is that L&F can comple

Re: Lw/Hw mixing vs revalidate()/validate()/invalidate()

Hello Anthony So may I assume that the silence means agreement? Yep! I see no problems with overridden JComponent.invalidate() If there's no objections coming within about a week, then I'm going to make a patch with an overridden JComponent.invalidate() method. There is no need to wait, pl

Re: Review request: 6852592 (revalidate() must be smarter)

Hello Anthony Can we do the same for isValidatRoot()? Yes, that is a smaller solution (in terms of the code size), smaller fix is less error-prone and gives better maintainable code for future changes though I prefer to minimize calling Swing stuff from AWT code. What do others think? let

Re: Review request: 6852592 (revalidate() must be smarter)

Hello Anthony While the fix itself does what we need, its implementation is quite confusing Component.invalidate() calls invalidImpl() and JComponent.invalidate() also calls invalidImpl() for validate roots and otherwise calls super.invalidte() I think checking isValidatRoot() on AWT side will

Re: Review request: 6852592 (revalidate() must be smarter)

Hello Christopher Hi Anthony, One more concern that comes to my mind is that the logic stated in the Swing's method specification is going to be implemented on the AWT's side, which I don't like much. So definitely we need more opinions on this proposal. This may be a stupid idea, so disrega

Re: Review request #3: 6852592 (revalidate() must be smarter)

Hello Christopher Anthony, I think I disagree with Applet returning true to isValidateRoot. If I am not mistaken, I think I saw some people placing an applet in their component hierarchy as if it was a normal component. Invalidation should propagate so that outer components can revalidate and t

Re: Review request #3: 6852592 (revalidate() must be smarter)

Hello Anthony Hi Alex, On 7/27/2009 8:41 PM Alexander Potochkin wrote: By the way, when isValidateRoot() method will be brought up to Component, I expect the cast to be removed if ((c instanceof JComponent) && (((JComponent)c).isValidateRoot())) A component cannot be a validate

Re: Review request #3: 6852592 (revalidate() must be smarter)

Hello Anthony Hi Alex, On 7/27/2009 10:18 PM Alexander Potochkin wrote: Could you please elaborate on possible situations that could break after making the Window/Applet the validate root? Let me describe the "best fix" 1) Bring isValidateRoot() up to the Component class

Re: Review request #3: 6852592 (revalidate() must be smarter)

Hello Anthony Hello Alex, On 07/27/2009 10:54 PM, Anthony Petrov wrote: 1) Bring isValidateRoot() up to the Component class 2) Make it return false 3) Leave all other stuff intact The current fix does almost that with a few exceptions. Could you please describe at what exact cases promoting

Re: Review request #3: 6852592 (revalidate() must be smarter)

Hello Anthony Hi Alex, Artem, On 7/28/2009 8:05 PM Alexander Potochkin wrote: As for the second question about making Window/Applet validate roots, I just don't see any practical benefits of this Could you please give more details why it is worth doing? As to the Applet class, ther

Re: Review request #3: 6852592 (revalidate() must be smarter)

Hello Anthony On 07/28/2009 10:31 PM, Alexander Potochkin wrote: As for the second question about making Window/Applet validate roots, I just don't see any practical benefits of this Could you please give more details why it is worth doing? As to the Applet class, there'

Re: Review request #3: 6852592 (revalidate() must be smarter)

Hello Anthony So the code is ready to the situation when there is no validate root If you make Window a validate root, the for loop will always find it and the logic will be changed Yes! And that seems to be completely correct: we HAVE TO call validate() on a validate root (or a top-level c

hg: jdk7/swing/jdk: 6822696: Integrating JXLayer component to Swing library

Changeset: 8e65977e4969 Author:alexp Date: 2009-08-10 16:29 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/8e65977e4969 6822696: Integrating JXLayer component to Swing library Reviewed-by: peterz, art + src/share/classes/javax/swing/JLayer.java + src/share/classes/javax/s

Re: hg: jdk7/swing/jdk: 6822696: Integrating JXLayer component to Swing library

Hello Phil Alex, Mark is correct. They need to have the usual GPL+CP for the source files and GPL for the test. Wow, sorry my fault Please file a bug to fix this. Bug #6872492 is filed and will be fixed soon Thank you Mark for finding it! alexp -phil. On Aug 15, 2009, at 1:58 PM,

hg: jdk7/swing/jdk: 6872492: JLayer sources contain wrong header

Changeset: fa334ff12794 Author:alexp Date: 2009-08-19 17:24 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/fa334ff12794 6872492: JLayer sources contain wrong header Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/plaf/Laye

hg: jdk7/swing/jdk: 6824395: Several Swing core components prevent using them in wrapper classes

Changeset: 799439873bf9 Author:alexp Date: 2009-08-24 19:22 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/799439873bf9 6824395: Several Swing core components prevent using them in wrapper classes Reviewed-by: peterz ! src/share/classes/javax/swing/JEditorPane.java ! src/

hg: jdk7/swing/jdk: 6872503: JLayer event handling should be rewritten

Changeset: e7d311b4ae94 Author:alexp Date: 2009-08-31 18:39 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e7d311b4ae94 6872503: JLayer event handling should be rewritten Reviewed-by: art ! src/share/classes/javax/swing/JLayer.java + test/javax/swing/JLayer/6872503/bug687

hg: jdk7/swing/jdk: 6875153: JLayer.isOptimizedDrawingEnabled() throws NPE for null glass pane set

Changeset: 935814bd43a6 Author:alexp Date: 2009-09-01 18:51 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/935814bd43a6 6875153: JLayer.isOptimizedDrawingEnabled() throws NPE for null glass pane set Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java ! src/s

hg: jdk7/swing/jdk: 6797139: JButton title is truncating for some strings irrespective of preferred size.

Changeset: 281fbd82a971 Author:alexp Date: 2009-09-02 17:47 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/281fbd82a971 6797139: JButton title is truncating for some strings irrespective of preferred size. Reviewed-by: peterz ! src/share/classes/javax/swing/SwingUtilitie

Re: Synth LnF developers?

Hello Matthieu I Alex, the tech lead of Swing team Please give the bug's number and your fix feel free to add any additional comments I'll keep an eye on this bug Thanks alexp Hello there, I would like to get in touch with one of the active developers of synth. Here is why: I filed a bug a

hg: jdk7/swing/jdk: 6878792: Sample provided in javax.swing.JLayer class description is not usable

Changeset: 6216604c05e2 Author:alexp Date: 2009-09-09 17:32 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/6216604c05e2 6878792: Sample provided in javax.swing.JLayer class description is not usable Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java

hg: jdk7/swing/jdk: 6875716: JLayer.remove((Component)null) should behave consistently in (not) throwing NPE

Changeset: 51ccbb892a1f Author:alexp Date: 2009-09-15 16:26 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/51ccbb892a1f 6875716: JLayer.remove((Component)null) should behave consistently in (not) throwing NPE Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.j

hg: jdk7/swing/jdk: 4833524: BasicTreeUI.isToggleSelectionEvent() does not properly handle popup triggers

Changeset: 481c01572c62 Author:alexp Date: 2009-09-17 19:08 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/481c01572c62 4833524: BasicTreeUI.isToggleSelectionEvent() does not properly handle popup triggers Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/

hg: jdk7/swing/jdk: 6883341: SWAT: jdk7-b72 swat build(2009-09-17) threw exceptions when running Java2D demo by clicking Paint ta

Changeset: 9d78c3d9def2 Author:alexp Date: 2009-09-21 17:58 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9d78c3d9def2 6883341: SWAT: jdk7-b72 swat build(2009-09-17) threw exceptions when running Java2D demo by clicking Paint ta Reviewed-by: peterz ! src/share/classes/s

Re: Synth LnF developers?

t doing this on my leisure time. The problem is just an incorrect use of String.substring(). BTW, I think synth has a great potential, I really like it. It is central to my current 'leisure project'. Thanks again and best regards, Matthieu Alexander Potochkin wrote: Hello Matthieu

Re: Review request #4: 6852592 (invalidate() must be smarter) - approved

Hello Anthony I looked through the Swing code and didn't find any problems, if all relevant tests passed I approve Thanks alexp P.S. Container.descendUnconditionallyWhenValidating looks fishy indeed, it's better to get rig of it indeed Hi Artem, On 10/01/2009 12:24 PM, Artem Ananiev wrote:

Re: Review request #4: 6852592 (invalidate() must be smarter) - approved

Hello Anthony Container.descendUnconditionallyWhenValidating looks fishy indeed, it's better to get rig of it indeed Could you elaborate please? Sure By the way, I meant "the extra if statements containing Container.descendUnconditionallyWhenValidating look fishy" now it should be a bit

Re: Review request #4: 6852592 (invalidate() must be smarter) - approved

Hello Anthony There are enough serious reasons why not to use it, I have read them in a "Java Concurrency" book which is alway on my table That's really surprising to hear from a developer of a single-threaded GUI-toolkit! We, AWT people, should have this book instead! ;) :-) Now back to

Re: Review request #4: 6852592 (invalidate() must be smarter) - approved

Hello Anthony If so I'll approve this one ;-) I already got your approval in your message on 10/06/2009 08:23 PM. The only "if" was about whether the tests pass, and they do! ;) What?! already approved... Okay, you got this time :-) Thanks alexp -- best regards, Anthony Thanks alexp

hg: jdk7/swing/jdk: 6795356: Leak caused by javax.swing.UIDefaults.ProxyLazyValue.acc

Changeset: 65da4a7fbf7f Author:alexp Date: 2009-10-22 18:42 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/65da4a7fbf7f 6795356: Leak caused by javax.swing.UIDefaults.ProxyLazyValue.acc Reviewed-by: hawtin ! src/share/classes/javax/swing/JTable.java ! src/share/classes/ja

Re: [PATCH] 6179357: Generics: JList

Hello Florian Hi Pavel, Hmm, do you know where the problem lies? I understand that changes to the public API need thorough reviews, but it's already months. It would be great if we could continue with the work. I'll try to speed up the process We'll let you know about the results soon Tha

Re: [PATCH] 6179357: Generics: JList

Wow! Congratulations Pavel & Florian! Thanks alexp Hi Florian, I've got an approve for the fix and committed it: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/7bcb1864f424 Thanks for your work, Pavel Ok, thanks -Florian Alexander Potochkin schrieb: Hello Florian Hi Pavel,

Re: Fw: review request for 6899434: Add affine transformsupport to JLayer

Hello Artem As a side effect, this would give the developers a flexibility to use non-affine transforms. They will even be able to use different transforms for forward and reverse operations, but I doubt anyone will want this (or we could add an explicit warning to JavaDoc about this). a smal

Re: Fw: review request for 6899434: Add affine transformsupport to JLayer

Hello Artem I haven't mentioned JLayer at all. When we make some of our API public/protected, developers will be able to implement their own components with transformations of any kind - this is what I wrote about. Aga, okay It would be quite difficult to support any other transforms then Aff

Re: Fw: review request for6899434:Addaffinetransformsupport to JLayer

Hello Piet I am fine with 3rd version, waiting for the comments from AWT guys Thanks! alexp Hi Artem, The webrev for version 3.1: http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/ Hi, Piet, the 3rd version looks really great! I haven't looked to Swing code much, though :) A small

Re: Fw: review request for6899434:Addaffinetransformsupport to JLayer

Hello Piet I am fine with 3rd version, waiting for the comments from AWT guys small correction: I meant 3.1 version (the latest one) Thanks again alexp Thanks! alexp Hi Artem, The webrev for version 3.1: http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/ Hi, Piet, the 3rd v

Re: Fw: reviewrequestfor6899434:Addaffinetransformsupport to JLayer

Hello Piet and the team While the AWT part of the fix is clear and almost done there are some alternatives how we should make the best out of it on the Swing side To make the best decision and get the early feedback from the community I propose to split the generic support of mouse events from a

Re: Fw:reviewrequestfor6899434:Addaffinetransformsupport to JLayer

Hello Piet Piet, could you please make a new webrev for 6929295? It should be basically the same fix as for 6899434 but with no changes in JLayer Done. Please see here http://www.pbjar.org/OpenJDK/6929295/webrev/ The main idea is to enable users to easily use transforms in custom Swing com

Re: Fw:reviewrequestfor6899434:Addaffinetransformsupport to JLayer

Hi Alex, Anthony and others, Hello Piet Aha, I misinterpreted the request to only an awt change. I'll start working on an uptaed implementation on the swing side (RepaintManager, JPopupMenu, ToolTipManager and JComponent), only using toLayoutSpace and toRendereredSpace in Container. Then I

Test

Test please ignore

Re: Webrev available for rfe 6929295 Generic support of mouse event transformation for AWT/Swing

Hello Anthony Hi Piet, I've reviewed the AWT part of the fix only. Some comments follow. src/share/classes/java/awt/Container.java 2356 * @throws IllegalComponentStateException when inverse transformation is not possible I believe IllegalArgumentException works best in that case since wheth

hg: jdk7/swing/jdk: 6899413: Fix for CR #6878399 should be refactored

Changeset: ff11655cf75b Author:alexp Date: 2010-04-29 18:38 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/ff11655cf75b 6899413: Fix for CR #6878399 should be refactored Reviewed-by: peterz ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/J

hg: jdk7/swing/jdk: 6899453: Remove unnecessary methods from LayerUI

Changeset: d5b94f5b3c3a Author:alexp Date: 2010-04-29 18:56 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/d5b94f5b3c3a 6899453: Remove unnecessary methods from LayerUI Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/LayerUI.java

hg: jdk7/swing/jdk: 6899405: Specification for JLayer.setLayerEventMask() should mention that eventDispatch() might not be called

Changeset: 0f5ef61eea9e Author:alexp Date: 2010-04-29 19:07 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/0f5ef61eea9e 6899405: Specification for JLayer.setLayerEventMask() should mention that eventDispatch() might not be called Reviewed-by: peterz ! src/share/classes/j

hg: jdk7/swing/jdk: 6786238: api/javax_swing/DefaultDesktopManager/descriptions.html#xxxFrame Fails with NPE since 6u12 b02

Changeset: 3de717f6ddab Author:alexp Date: 2010-05-25 20:22 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/3de717f6ddab 6786238: api/javax_swing/DefaultDesktopManager/descriptions.html#xxxFrame Fails with NPE since 6u12 b02 Reviewed-by: rupashka ! src/share/classes/javax

hg: jdk7/swing/jdk: 6937798: Nimbus: Issues with JTable grid

Changeset: 1297a41dbb47 Author:alexp Date: 2010-05-25 20:30 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/1297a41dbb47 6937798: Nimbus: Issues with JTable grid Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java + test/javax/swing/JTable/69

hg: jdk7/swing/jdk: 6768387: REGRESSION: JTable no longer serializable

Changeset: 8d59b361635f Author:alexp Date: 2010-05-25 20:39 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/8d59b361635f 6768387: REGRESSION: JTable no longer serializable Reviewed-by: rupashka ! src/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java + test/

hg: jdk7/swing/jdk: 6884066: JTableHeader listens mouse in disabled state and doesn't work when not attached to a table

Changeset: d540eeccf73a Author:alexp Date: 2010-05-25 20:54 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/d540eeccf73a 6884066: JTableHeader listens mouse in disabled state and doesn't work when not attached to a table Reviewed-by: rupashka ! src/share/classes/com/sun/j

hg: jdk7/swing/jdk: 6670274: Incorrect tab titles for JTabbedPane if using HTML (BasicTabbedPanelUI problem)

Changeset: 82524b068f77 Author:alexp Date: 2010-05-28 19:55 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/82524b068f77 6670274: Incorrect tab titles for JTabbedPane if using HTML (BasicTabbedPanelUI problem) Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/bas

hg: jdk7/swing/jdk: 6889007: No resize cursor during hovering mouse over JTable

Changeset: 9b247a6290a4 Author:alexp Date: 2010-05-28 19:46 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9b247a6290a4 6889007: No resize cursor during hovering mouse over JTable Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java + t

Re: hg: jdk7/swing/jdk: 6884066: JTableHeader listens mouse in disabled state and doesn't work when not attached to a table

Hello Jason So 6550602 can be closed and added to the umbrella bug? indeed I closed 6550602 as a duplicate of 6884066 Thanks for noticing it! alexp Jason > From: alexander.potoch...@sun.com > To: jdk7-chan...@openjdk.java.net; swing-dev@openjdk.java.net > Date: Tue, 25 May 2010 16:47

hg: jdk7/swing/jdk: 6735259: NPE at WindowsComboBoxUI$XPComboBoxButton.getState(WindowsComboBoxUI.java:408)

Changeset: 987677418c27 Author:alexp Date: 2010-06-02 18:14 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/987677418c27 6735259: NPE at WindowsComboBoxUI$XPComboBoxButton.getState(WindowsComboBoxUI.java:408) Reviewed-by: rupashka ! src/share/classes/com/sun/java/swing/pl

hg: jdk7/swing/jdk: 6788484: NPE in DefaultTableCellHeaderRenderer.getColumnSortOrder() with null table

Changeset: 12e0d9a44478 Author:alexp Date: 2010-06-02 18:25 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/12e0d9a44478 6788484: NPE in DefaultTableCellHeaderRenderer.getColumnSortOrder() with null table Reviewed-by: rupashka ! src/share/classes/sun/swing/table/DefaultTa

Re: Bug Report (with fix): NPE in CompoundBorder.getInsets()

Hello Jon in the description of this bug http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=477 we can read that "It functions correctly when using the JDK from Sun." Do you have an idea why it happens? I checked that we don't have the null check in that method either in the Sun JDK Thanks

hg: jdk7/swing/jdk: 2 new changesets

Changeset: cf13f6389bdd Author:alexp Date: 2010-06-15 19:05 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/cf13f6389bdd 6788484: NPE in DefaultTableCellHeaderRenderer.getColumnSortOrder() with null table Reviewed-by: rupashka ! src/share/classes/sun/swing/table/DefaultTa

hg: jdk7/swing/jdk: 2 new changesets

Changeset: cd565c554dc6 Author:alexp Date: 2010-06-15 21:28 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/cd565c554dc6 6771547: SynthParser throws StringIndexOutOfBoundsException parsing custom ColorTypes Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/synth/

hg: jdk7/swing/jdk: 6777378: NullPointerException in XPDefaultRenderer.paint()

Changeset: dea63f6dda7a Author:alexp Date: 2010-06-22 19:38 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/dea63f6dda7a 6777378: NullPointerException in XPDefaultRenderer.paint() Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java + te

  1   2   3   >