Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

JPRT job ran OK. Just need +1s from Phil/Mandy for the comment change shown below. On 11/1/16 9:56 AM, Pete Brunet wrote: > Mandy and Phil, I thought it would be helpful to add this to the comment > in AccesssBridgeCalls.h: > > * > * Also note that the API is used in the j

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

the JPRT job today and then once I get your approval for that comment I will push this into 9. Pete On 11/1/16 4:27 AM, Erik Joelsson wrote: > Looks good. > > /Erik > > On 2016-10-31 15:36, Pete Brunet wrote: >> >> On 10/28/16 8:14 PM, Mandy Chung wrote: >>>&

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

Erik, I need your +1 again because the make files have changed since you last looked. I'll also be running JPRT before I push. Pete > > -phil. > > On 10/31/2016 07:36 AM, Pete Brunet wrote: >> >> On 10/28/16 8:14 PM, Mandy Chung wrote: >>>> On Oct 28, 2016,

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

gt;> > This works for me. Updated: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.09/ > > Mandy > >> -phil. >> >> On 10/28/16, 12:42 PM, Mandy Chung wrote: >>>> On Oct 28, 2016, at 11:32 AM, Pete Brunet<peter.bru...@oracle.com>

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

Hi Mandy, That simplifies things. The new patch is at: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.08/ Pete On 10/27/16 6:51 PM, Mandy Chung wrote: >> On Oct 27, 2016, at 4:31 PM, Pete Brunet <peter.bru...@oracle.com> wrote: >> >> I moved the source to

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

On 10/27/16 6:31 PM, Pete Brunet wrote: > On 10/27/16 1:30 PM, Mandy Chung wrote: >>> On Oct 27, 2016, at 10:44 AM, Phil Race <philip.r...@oracle.com> wrote: >>> >>> No, we are definitely shipping those. >>> Unless of course you think we should stop s

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

On 10/27/16 1:30 PM, Mandy Chung wrote: >> On Oct 27, 2016, at 10:44 AM, Phil Race wrote: >> >> No, we are definitely shipping those. >> Unless of course you think we should stop shipping JNI headers too … >> > No. I tried to understand what is external interface. I

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

On 10/27/16 1:47 PM, Pete Brunet wrote: > > On 10/27/16 1:34 PM, Phil Race wrote: >> In which case be careful it is not built by the JDK build .. > Build team, Is there anything I need to handle here to make sure it isn't? Actually, let me give it a try. I should be able to res

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

On 10/27/16 1:34 PM, Phil Race wrote: > In which case be careful it is not built by the JDK build .. Build team, Is there anything I need to handle here to make sure it isn't? > unless that is actually required .. which I didn't think it was. > > -phil. > > On 10/27/2016 11:30 AM, Mandy Chung

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

On 10/27/16 1:34 PM, Phil Race wrote: > In which case be careful it is not built by the JDK build .. > unless that is actually required .. which I didn't think it was. It isn't. > > -phil. > > On 10/27/2016 11:30 AM, Mandy Chung wrote: >> Please move AccessBridgeCalls.c to >>

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

BridgeCalls.c >> <http://hg.openjdk.java.net/jdk9/client/jdk/file/tip/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c> >> >> Regards, >> Anirvan Sarkar >> >> On Thursday 27 October 2016, Pete Brunet <peter.bru...@oracle.com >&g

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

The .h files are unlicensed in the bundle/install so no need? On 10/26/16 11:52 PM, Mandy Chung wrote: > Should the same change be applied to the .h files as well? > > Mandy > >> On Oct 26, 2016, at 7:24 PM, Pete Brunet <peter.bru...@oracle.com> wrote: >> >

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

net/jdk9/client/jdk/file/tip/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c > <http://hg.openjdk.java.net/jdk9/client/jdk/file/tip/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c> > > Regards, > Anirvan Sarkar > > On

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

I found a comment from Mandy in the bug. That hex number can be replaced with "tip". I uploaded http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.04/ Pete On 10/26/16 11:05 PM, Pete Brunet wrote: > > > On 10/26/16 10:44 PM, Philip Race wrote: >> >

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

ot;latest" link. Maybe some other reader will know. > > But I am not sure about that either .. it may need to be split between the > main URL and the location in the repo. > > -phil > > > On 10/26/16, 7:24 PM, Pete Brunet wrote: >> Please review the latest up

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

/25/16 6:48 AM, Alexandr Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 10/24/2016 1:18 PM, Erik Joelsson wrote: >> The last change looks good and simple to me. >> >> /Erik >> >> >> On 2016-10-21 06:55, Pet

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

with the current API and related calls into WindowsAccessBridge*.dll. Pete On 10/18/16 12:28 PM, Pete Brunet wrote: > I've updated the webrev. Please see > http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/ > > Rather than removing the files needed by Assistive Technology develope

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

directory to a new javaaccessbridge directory. On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote: > On 2016-10-14 17:51, Pete Brunet wrote: >> Please review the following. >> >> The .h files and .c file provided to allow Assistive Technology to >> interface to the Java

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

icense > as they will not be in an Oracle JDK which strips the GPL > > So if you are going to do this then these files first need to be > dual-licensed > because otherwise people can't link their commercial products with these. > > -phil. > > On 10/14/2016 08:51 AM, Pete Brunet wrote: >> Please r

RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

Please review the following. The .h files and .c file provided to allow Assistive Technology to interface to the Java Access Bridge API are being removed from the built JRE/JDK images. They are not used much and they can be obtained online via the OpenJDK web site. The pubs will be updated to

Re: RfR JDK-8160893 [macosx] JMenuItems in JPopupMenu are not accessible

/16 16:22, Anton Tarasov wrote: >> Hi Pete, >> >> The fix looks fine to me. >> >> Thanks, >> Anton. >> >> On 9/24/2016 2:59 AM, Pete Brunet wrote: >>> New webrev: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.02/ >>

Re: RfR JDK-8160893 [macosx] JMenuItems in JPopupMenu are not accessible

New webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.02/ I added a null check at line 688 like the one at line 693. Pete On 9/23/16 2:46 PM, Pete Brunet wrote: > Please review the patch for JDK-8160893. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160893 >

Re: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild

JPRT jobs ran OK. On 7/19/16 1:43 PM, Alexandr Scherbatiy wrote: > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/19/2016 8:50 PM, Pete Brunet wrote: >> Look at .02 instead. I had an extraneous println left in .01. >> http://cr.openjdk.java.net/~

Re: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild

gt;> matter. I haven't seen any other style so just assumed that is/was >> the standard. Is there an alternative standard I should start to use? >> >> Pete >>> >>> -phil. >>> >>> On 07/19/2016 11:43 AM, Alexandr Scherbatiy wrote: >>>> The fix looks

Re: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild

andard. Is there an alternative standard I should start to use? Pete > > -phil. > > On 07/19/2016 11:43 AM, Alexandr Scherbatiy wrote: >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 7/19/2016 8:50 PM, Pete Brunet wrote: >>> Look at

Re: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild

Look at .02 instead. I had an extraneous println left in .01. http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.02/ On 7/19/16 11:48 AM, Pete Brunet wrote: > I added a regression test: > http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.01/ > > Could someone p

Re: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild

gt; > On 7/19/2016 5:10 AM, Pete Brunet wrote: >> Please review the following: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161483 >> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.00/ >> >> This is a followon to the patch for >&g

RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild

Please review the following: Bug: https://bugs.openjdk.java.net/browse/JDK-8161483 Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.00/ This is a followon to the patch for JDK-8145207 [macosx] JList, VO can't access non-visible list items In order to fixJDK-8145207the

Re: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items

Anton, If you'd like to check out the changeset I just pushed it. Pete On 7/18/16 3:25 PM, Pete Brunet wrote: > JPRT ran OK. > > On 7/15/16 9:24 AM, Pete Brunet wrote: >> On 7/15/16 8:42 AM, Alexandr Scherbatiy wrote: >>> On 7/15/2016 4:39 AM, Pete Brunet wrote: >&

Re: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items

JPRT ran OK. On 7/15/16 9:24 AM, Pete Brunet wrote: > > On 7/15/16 8:42 AM, Alexandr Scherbatiy wrote: >> On 7/15/2016 4:39 AM, Pete Brunet wrote: >>> Hi Alexandr, Thanks very much for the review. I updated the webrev. >>> See >>> http://cr.openjdk.j

Re: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items

On 7/15/16 8:42 AM, Alexandr Scherbatiy wrote: > On 7/15/2016 4:39 AM, Pete Brunet wrote: >> Hi Alexandr, Thanks very much for the review. I updated the webrev. >> See >> http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.01/ > The fix looks good to me. Than

Re: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items

API of JList.AccessibleJList.AccessibleJListChild: >Just create a private subclass of the AccessibleJListChild which implements AccessibleAction and return it in all places where new instance of the AccessibleJListChild is returned. I made that change. On 7/4/16 4:14 AM, Alexandr Scherbatiy wrote: > On 6/18/2016 5:31

Re: RfR JDK-8154069, Jaws reads wrong values from comboboxes when no element is selected

JPRT results: Build Stats: 9 pass, 0 fail On 6/30/16 10:45 PM, Pete Brunet wrote: > I ran all Swing JCK and regression tests and found no failures with the > fix applied that do not also occur with the fix not applied. > > On 6/30/16 11:51 AM, Alexander Scherbatiy wrote: >>

Re: RfR JDK-8154069, Jaws reads wrong values from comboboxes when no element is selected

o > possible regressions. > > Thanks, > Alexandr. > > On 30/06/16 18:49, Pete Brunet wrote: >> >> On 6/30/16 8:28 AM, Pete Brunet wrote: >>> Please review the following: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154069

Re: RfR JDK-8154069, Jaws reads wrong values from comboboxes when no element is selected

d be used. > > On 30.06.16 16:28, Pete Brunet wrote: >> Please review the following: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154069 >> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8154069/webrev.01/ >> >> The scenario is resetting a second combo box

Re: RfR JDK-8154069, Jaws reads wrong values from comboboxes when no element is selected

On 6/30/16 1:15 PM, Pete Brunet wrote: > > On 6/30/16 12:59 PM, Sergey Bylokhov wrote: >> A few comments about the test: >> - The frame should be disposed at the end of the test(in finally block) >> - The correct GPL header should be used. > I fixed the header. Can

Re: RfR JDK-8154069, Jaws reads wrong values from comboboxes when no element is selected

30.06.16 16:28, Pete Brunet wrote: >> Please review the following: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154069 >> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8154069/webrev.01/ >> >> The scenario is resetting a second combo box via set

Re: RfR JDK-8154069, Jaws reads wrong values from comboboxes when no element is selected

n/jtreg -jdk:./build/windows-x86_64-normal-server-release/images/jdk ./jdk/test/javax/swing/plaf/basic/BasicComboPopup/8154069/ Thanks, Pete > > Thanks, > Alexandr. > > On 30/06/16 18:49, Pete Brunet wrote: >> >> On 6/30/16 8:28 AM, Pete Brunet wrote: >>> Please revi

Re: RfR JDK-8154069, Jaws reads wrong values from comboboxes when no element is selected

On 6/30/16 8:28 AM, Pete Brunet wrote: > Please review the following: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154069 > Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8154069/webrev.01/ > > The scenario is resetting a second combo box via setSelectedIndex(-1) > w

RfR JDK-8154069, Jaws reads wrong values from comboboxes when no element is selected

Please review the following: Bug: https://bugs.openjdk.java.net/browse/JDK-8154069 Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8154069/webrev.01/ The scenario is resetting a second combo box via setSelectedIndex(-1) when a first combo box changes. With the fix the selection is now cleared.

Re: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items

ere is any way I can come up with a different solution that will allow me to backport it. Pete On 6/23/16 12:21 PM, Anton Tarasov wrote: > Hi Pete, > >> On 22 Jun 2016, at 17:41, Pete Brunet <peter.bru...@oracle.com >> <mailto:peter.bru...@oracle.com>> wrote: >>

Re: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items

ity.java > > A typo in the comment: "will will annouce” > > Also, I gave it a try with jdk8u-dev, locally, along with the > following pre-applied: > > 8076554: [macosx] Custom Swing text components need to allow standard > accessibility > > JList is spoken fine by VO,

RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items

Please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8145207 Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.00/ This fixes the following functionality that was not working with the JList of ListDemo of SwingSet2. - start VoiceOver - start SwingSet2 -

Re: Programmatically clicking a JLabel in a JList

; calling java.awt.Component.dispatchEvent(AWTEvent). >> >> Best regards, >> Andrej Golovnin >> >> On Wed, Jun 8, 2016 at 10:46 PM, Pete Brunet <peter.bru...@oracle.com> wrote: >>> To add some accessibility support I need to programmatically click a >>&

Programmatically clicking a JLabel in a JList

To add some accessibility support I need to programmatically click a JLabel in a JList. If I can figure out the code path for when this happens with a real click I can probably do what I need to do but as of yet I haven't figured it out. Does anyone on the list know at least part of the code

keyboard (not mouse) multi-select on Mac

How do you do a mouseless (keyboard only) multi-select on Mac, e.g. in the List Demo of SwingSet2? On Win, to move the focus point without moving the selection, you use ctrl + arrow. Then when you are at the next list item you want to select you use ctrl + space. I tried arrow with control,

Re: RfR JDK-8076554, [macosx] Custom Swing text components need to allow standard accessibility

bugs. Pete > > On 19.04.16 22:16, Phil Race wrote: >> +1 >> >> -phil. >> >> On 04/19/2016 12:05 PM, Pete Brunet wrote: >>> New patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.03/ >>> >>> Changes: >>> - removed _Acc

Re: RfR JDK-8076554, [macosx] Custom Swing text components need to allow standard accessibility

p.s. JPRT ran OK. Still need one more +1. On 4/19/16 2:16 PM, Phil Race wrote: > +1 > > -phil. > > On 04/19/2016 12:05 PM, Pete Brunet wrote: >> New patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8076554/webrev.03/ >> >> Changes: >> - removed _Access

Re: RfR JDK-8076554, [macosx] Custom Swing text components need to allow standard accessibility

er than the v0 .. >> >> -phil. >> >> On 04/19/2016 08:54 AM, Pete Brunet wrote: >>> Thanks for noticing that Alexandr. I see this state was added in >>> 1.5 and apparently the code from which I borrowed this from was >>> never updated. I will re

Re: RfR JDK-8153149, Uninitialised memory in WinAccessBridge.cpp:1128

To all, I added more information to the bug report. Is the patch OK? https://bugs.openjdk.java.net/browse/JDK-8153149 http://cr.openjdk.java.net/~ptbrunet/JDK-8153149/webrev.00/ Pete On 4/4/16 9:09 AM, Pete Brunet wrote: > > On 4/1/16 5:54 PM, Phil Race wrote: >> You say its a simp

Re: RfR: JDK-8153153, Format string argument mismatch in jaccesswalker.cpp:545

Evaluation added. Is the patch OK? https://bugs.openjdk.java.net/browse/JDK-8153153 http://cr.openjdk.java.net/~ptbrunet/JDK-8153153/webrev.00/ Pete On 4/4/16 12:10 PM, Phil Race wrote: > All bugs should have an evaluation. Period. > > -phil. > > On 04/04/2016 06:33 AM, Pe

Re: RfR JDK-8153149, Uninitialised memory in WinAccessBridge.cpp:1128

one. Maybe the code was much different at one time. The extra unneeded indentation might indicate that. I looked through the code to see if pkgVMID might have been an in/out instead of just an out on the call to findAccessBrdige but it's just an out. Pete > > -phil. > > O

Re: RfR: JDK-8153153, Format string argument mismatch in jaccesswalker.cpp:545

t; > On 4/1/16, 11:56 AM, Pete Brunet wrote: >> Please review this simple fix: >> https://bugs.openjdk.java.net/browse/JDK-8153153 >> http://cr.openjdk.java.net/~ptbrunet/JDK-8153153/webrev.00/

RfR JDK-8153149, Uninitialised memory in WinAccessBridge.cpp:1128

Please review this simple fix: https://bugs.openjdk.java.net/browse/JDK-8153149 http://cr.openjdk.java.net/~ptbrunet/JDK-8153149/webrev.00/

Re: RfR, JDK-8145228 , Java Access Bridge, getAccessibleStatesStringFromContext doesn't wrap the call to getAccessibleRole

it is ok to use lambda syntax in this >> file, the rest of the file still uses the anonymous inner class syntax. >> >> On Mon, Feb 29, 2016 at 12:35 PM, Pete Brunet >> <peter.bru...@oracle.com <mailto:peter.bru...@oracle.com>> wrote: >> >> Please review

Re: RfR, JDK-8145228 , Java Access Bridge, getAccessibleStatesStringFromContext doesn't wrap the call to getAccessibleRole

Thanks Andrej, That's a good idea. I already pushed the patch for 8145228 but I opened a new bug for this work: https://bugs.openjdk.java.net/browse/JDK-8152192 Pete On 3/18/16 5:30 AM, Andrej Golovnin wrote: > Hi Pete, > >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8145228/webrev.01/ > please

RfR, JDK-8145228 , Java Access Bridge, getAccessibleStatesStringFromContext doesn't wrap the call to getAccessibleRole

Please review this change which runs code on the EDT like it should have. http://cr.openjdk.java.net/~ptbrunet/JDK-8145228/webrev.00/

Re: RfR JDK-8145735, Tests api/javax_swing/JTabbedPane/AccessibleJTabbedPane/* are failing

How does this look? http://cr.openjdk.java.net/~ptbrunet/JDK-8145735/webrev.01/ Pete On 1/13/16 7:16 AM, Alexander Scherbatiy wrote: > On 1/13/2016 1:12 AM, Pete Brunet wrote: >> Hi Alexandr, >> >> On 1/12/16 1:03 PM, Alexander Scherbatiy wrote: >>> It seems that th

Re: RfR JDK-8145735, Tests api/javax_swing/JTabbedPane/AccessibleJTabbedPane/* are failing

y do this in the getTitle() method. In any event, are you suggesting just always using parent.indexOfComponent(), i.e. always using getTitle()? The regression test runs OK with that change. Is there a case where indexOfComponent would not work but indexOfTabComponent would? Pete > > Thanks,

RfR JDK-8145735, Tests api/javax_swing/JTabbedPane/AccessibleJTabbedPane/* are failing

Please review this patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8145735/webrev.00/ The issue being resolved is that the JTabbedPane code can't solely rely on tabComponent when fetching the index in the parent component. tabComponent is optionally used and its presence indicates that the

Re: RfR: JDK-8071334, Investigate JAB changes required to support the version string change

Technology Vendors). > > Thanks, > Alexandr. > > On 12/10/2015 1:59 AM, Pete Brunet wrote: >> Please review this simple patch: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8071334/webrev.00/ >> >> There was some old "if JDK 1.4" code that was remo

Re: RfR: JDK-8071334, Investigate JAB changes required to support the version string change

ation since it did not exist when Swing was developed. On the other hand UIA is implemented in JavaFX and that is used by ATVs for access to JavaFX apps. > > Thanks, > Alexandr. > > On 12/10/2015 1:59 AM, Pete Brunet wrote: >> Please review this simple patch: >> htt

RfR: JDK-8071334, Investigate JAB changes required to support the version string change

Please review this simple patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8071334/webrev.00/ There was some old "if JDK 1.4" code that was removed via this patch. There was no version string change impact; the JAB (Java Access Bridge) just passes the java.version property through via the JAB

Re: Tool to display Swing control hierarchy

https://github.com/robotframework/swingexplorer On 11/24/15 10:23 PM, Pete Brunet wrote: > Is there a tool that will show me the control hierarchy of a Swing app? > -Pete

RfR JDK-8056925 Add jaccessinspector and jaccesswalker to the bin directory

Please review: http://cr.openjdk.java.net/~ptbrunet/JDK-8056925/webrev.00/

Re: RfR JDK-8056925 Add jaccessinspector and jaccesswalker to the bin directory

Thanks for looking at this Phil. How's this: http://cr.openjdk.java.net/~ptbrunet/JDK-8056925/webrev.01/ Pete On 11/20/15 3:07 PM, Phil Race wrote: > On 11/20/2015 09:24 AM, Pete Brunet wrote: >> Please review: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8056925/webrev.00

RfR JDK-8134116, Add more comprehensive fix and regression test for JDK-8133897

Please review this patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.02/ The issue raised/fixed in 8133897 and now resolved in a better fashion in this patch is caused by an override of the functionality of JTabbedPane such that its Page inner class title field is not kept up to date

Re: Swing Dev RfR: JDK-8133897, IndexOutOfBounds exception being thrown

Is this fix trivial enough to qualify for the noreg-trivial tag? On 8/19/15 4:56 PM, Pete Brunet wrote: On 8/19/15 4:50 PM, Pete Brunet wrote: Please review this patch. http://cr.openjdk.java.net/~ptbrunet/JDK-8133897/webrev.00/ The issue is that the application has a tab with a visible

Swing Dev RfR: JDK-8133897, IndexOutOfBounds exception being thrown

Please review this patch. http://cr.openjdk.java.net/~ptbrunet/JDK-8133897/webrev.00/ The issue is that the application has a tab with a visible title but for some reason JTabbedPane's title field was . This caused indexOfTab(title) to return -1 and then getTabBounds(parent, -1) raised

Re: Swing Dev RfR: JDK-8133897, IndexOutOfBounds exception being thrown

On 8/19/15 4:50 PM, Pete Brunet wrote: Please review this patch. http://cr.openjdk.java.net/~ptbrunet/JDK-8133897/webrev.00/ The issue is that the application has a tab with a visible title but for some reason JTabbedPane's title field was . This caused indexOfTab(title) to return -1

Re: Swing Dev AWT Dev RfR JDK-8055831 Open Source Java Access Bridge

. Thanks Erik, My build and tests ran OK so apparently they are no longer needed. To all: My hope is to push this patch into 9 tomorrow (Thursday) so please let me know if there are any additional issues as soon as you can. Pete /Erik On 2015-03-24 22:36, Pete Brunet wrote: Here's the latest

Re: Swing Dev AWT Dev RfR JDK-8055831 Open Source Java Access Bridge

Hi Sergey, Which methods are you referring to? -Pete On 3/25/15 10:16 AM, Sergey Bylokhov wrote: The fix looks fine. But it is interesting, do we have an option to remove all deprecated methods during this opening? or can we do it later? or we cannot? 25.03.15 17:44, Pete Brunet wrote

Re: Swing Dev AWT Dev RfR JDK-8055831 Open Source Java Access Bridge

think the safe thing to do is undo that change in Copy-java.gmk and leave the closed file in place and discuss off-line with the security team why the files differ .. I'll start a discussion on this. -phil. On 3/25/2015 8:55 AM, Pete Brunet wrote: Hi Sergey, Which methods are you referring

Re: Swing Dev AWT Dev RfR JDK-8055831 Open Source Java Access Bridge

and Monkey test tools which will be the subject of a later patch - removed the DEF files; although they were used in the build, there are no build or runtime problems after their removal On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote: On 2015-03-23 18:31, Pete Brunet wrote: Hi Erik, I tried

Swing Dev Request for review, JDK-8048022 Fix raw and unchecked warnings in javax.accessibility

Hi Swing team, Please review a change to javax.accessibility to fix the rawtype and unchecked lint warnings for that package. Bug: https://bugs.openjdk.java.net/browse/JDK-8048022 Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8048022/webrev.00/ Best regards, Pete

Re: Swing Dev Request for review, JDK-8009883, REGRESSION: test/closed/javax/swing/AbstractButton/4246045/bug4246045.java fails

I'd like one more reviewer of this fix. Also I removed the @Deprecated and will deal with this in a following JBS issue. http://cr.openjdk.java.net/~ptbrunet/JDK-8009883/webrev.04/ Pete On 5/21/14 10:08 AM, Pete Brunet wrote: On 5/21/14 7:04 AM, Alexander Scherbatiy wrote: On 5/21/2014 2:56

Re: Swing Dev Request for review, JDK-8009883, REGRESSION: test/closed/javax/swing/AbstractButton/4246045/bug4246045.java fails

!= null) { accessibleContext.firePropertyChange( AccessibleContext.ACCESSIBLE_STATE_PROPERTY, AccessibleState.FOCUSED, null); } } } Thanks, Alexandr. On 5/7/2014 5:45 AM, Pete Brunet wrote

Re: Swing Dev Request for review, JDK-8009883, REGRESSION: test/closed/javax/swing/AbstractButton/4246045/bug4246045.java fails

On 5/16/14 10:45 AM, Alexander Scherbatiy wrote: On 5/16/2014 7:15 PM, Pete Brunet wrote: On 5/16/14 6:45 AM, Alexander Scherbatiy wrote: Hi Peter, Is there any difference between AccessibleAWTFocusHandler and AccessibleFocusHandler classes? Hi Alexandr, The former is the focus

Re: Swing Dev [Accessibility]Focus unable to traverse in the menubar

Hi, The word Accessibility in the subject line caught my eye when cleaning out my inbox this morning. I couldn't determine the essence of the issue in the history below but wanted to throw out one comment in case it's useful. If the comment isn't useful then please ignore. I don't know the

Swing Dev Fwd: Please review fix for 7177111 : Jcomponent.AccessibleJComponent.AddPropertyListeners adds exponential listeners

Could someone from the Swing team please review this? Original Message Subject:Please review fix for 7177111 : Jcomponent.AccessibleJComponent.AddPropertyListeners adds exponential listeners Date: Thu, 08 Nov 2012 15:51:19 -0600 From: Pete Brunet peter.bru

Re: Swing Dev Please review fix for 7179482 : Component.accessibleContext and JComponent.accessibleContext refactoring

This bug includes a coordination of fixes for both awt (2 files) and swing (1 file). Which repo should I use? jdk8/awt or jdk8/swing? I'm guessing the latter. (AccessibleJComponent inherits from AccessibleAWTContainer). Pete On 11/9/12 3:27 PM, Pete Brunet wrote: Please review the following

Swing Dev Please review fix for 7179482 : Component.accessibleContext and JComponent.accessibleContext refactoring

Please review the following fix planned for JDK8. Part of the fix will go into 7u12 under 7177111. Problem: In the process of evaluating 7177111 the following problems were noticed: - Both Component and JComponent have field accessibleContext. In Component it is package-private and accessed by

Swing Dev Please review fix for 7177111 : Jcomponent.AccessibleJComponent.AddPropertyListeners adds exponential listeners

Hi Everyone, Please review the following fix planned for 7u12. It will also go into 8 under 7179482. Problem: When an AT (Assistive Technology) accesses a Java application with several nested frames, too many property change listeners are added resulting in a severe performance impact for an AT