Re: Suggestions for StageStyle.UNIFIED on macOS

I took a look at this and discovered that UNIFIED doesn’t really work on any platform. It was never supported on Linux, the Mac implementation doesn’t really unify anything, and Windows is broken (see JDK-8154847 ). In that bug report it’s sugge

Re: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors

On Wed, 1 Dec 2021 17:44:21 GMT, Martin Fox wrote: > Turning on warnings-as-errors for the macOS glass native code. Deprecated > declarations are excluded and still appear as warnings. > > In the code that tries to locate the application's dock icon there were three > inst

[jfx18] Integrated: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage

On Thu, 13 Jan 2022 19:18:33 GMT, Martin Fox wrote: > When a window is closed while handling performKeyEquivalent the same NSEvent > might be passed to the new key window causing it to being processed twice. > Long ago a fix was put in for this case; when the GlassWindow was closed

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v5]

; > System test is included (I'm surprised, it really is possible to generate > Cmd+Enter using a Robot). This is new territory for me so I have a manual > test I can submit as a backup. Martin Fox has updated the pull request incrementally with one additional c

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3]

On Tue, 18 Jan 2022 23:35:43 GMT, Jose Pereda wrote: >> Martin Fox has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull request contains

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v4]

; > System test is included (I'm surprised, it really is possible to generate > Cmd+Enter using a Robot). This is new territory for me so I have a manual > test I can submit as a backup. Martin Fox has updated the pull request incrementally with one additional commit since the

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3]

; > System test is included (I'm surprised, it really is possible to generate > Cmd+Enter using a Robot). This is new territory for me so I have a manual > test I can submit as a backup. Martin Fox has refreshed the contents of this pull request, and previous commits have been

RFR: 8278924: [Linux] Robot key test can fail if multiple keyboard layouts are installed

The Robot implementation on Linux did not consult the current layout when mapping from a KeyCode to a hardware code. Internally it retrieved results for all the layouts but just picked the first one it saw leading to random effects. Though not part of the original bug report, the code also ignor

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v6]

On Tue, 21 Dec 2021 16:42:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as >> expected by more accurately mapping from a Mac key code to a Java key code >> based on the user’s active keyboard layout (the existing code assum

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v2]

; > System test is included (I'm surprised, it really is possible to generate > Cmd+Enter using a Robot). This is new territory for me so I have a manual > test I can submit as a backup. Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The

RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage

When a window is closed while handling performKeyEquivalent the same NSEvent might be passed to the new key window causing it to being processed twice. Long ago a fix was put in for this case; when the GlassWindow was closed a flag was set to ensure that we would return YES from performKeyEquiva

Re: RFR: 8278938: [Win] Robot can target wrong key for punctuation and symbols [v2]

gt; layout, like PLUS. > > In this PR if we don't find the Java code in the table or if it maps to an > OEM key (which may be wrong) we sweep through all the OEM keys looking for > the matching Java code. Martin Fox has updated the pull request incrementally with one additi

Integrated: 8242544: CMD+ENTER key event crashes the application when invoked on dialog

On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote: > The OS crashes if the contentView of a window is set to nil while handling > processKeyEquivalent. With this PR we just set the contentView to a basic > do-nothing NSView for the interim. This pull request has now been i

Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2]

On Wed, 12 Jan 2022 16:56:12 GMT, Martin Fox wrote: >> The OS crashes if the contentView of a window is set to nil while handling >> processKeyEquivalent. With this PR we just set the contentView to a basic >> do-nothing NSView for the interim. > > Martin Fox has

Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2]

On Wed, 12 Jan 2022 18:24:36 GMT, Kevin Rushforth wrote: >> Martin Fox has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Releasing dummy NSView > > modules/javafx.graphics/src/main/native-glass/mac/Gla

Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2]

On Wed, 12 Jan 2022 18:23:20 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 847: >> >>> 845: { >>> 846: // If the contentView is set to nil within >>> performKeyEquivalent: the OS will crash. >>> 847: NSView* d

Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2]

> The OS crashes if the contentView of a window is set to nil while handling > processKeyEquivalent. With this PR we just set the contentView to a basic > do-nothing NSView for the interim. Martin Fox has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog

On Wed, 12 Jan 2022 16:24:48 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 848: >> >>> 846: // If the contentView is set to nil within >>> performKeyEquivalent: the OS will crash. >>> 847: NSView* dummy = [[NSView all

RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog

The OS crashes if the contentView of a window is set to nil while handling processKeyEquivalent. With this PR we just set the contentView to a basic do-nothing NSView for the interim. - Commit messages: - Prevent OS crash when contentView is set to nil while processing shortcut Ch

Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog

On Wed, 29 Dec 2021 00:44:44 GMT, Andreas Heger wrote: > This also solves [JDK-8205915 [macOS] Accelerator assigned to button in > dialog fires menuItem in owning > stage](https://bugs.openjdk.java.net/browse/JDK-8205915l). > > I must admit that I don't have 100% insight about what actually ca

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v5]

On Mon, 20 Dec 2021 12:11:11 GMT, Johan Vos wrote: >> Martin Fox has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains five addi

Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog

On Wed, 29 Dec 2021 00:44:44 GMT, Andreas Heger wrote: > This also solves [JDK-8205915 [macOS] Accelerator assigned to button in > dialog fires menuItem in owning > stage](https://bugs.openjdk.java.net/browse/JDK-8205915l). > > I must admit that I don't have 100% insight about what actually ca

RFR: 8278938: [Win] Robot can target wrong key for punctuation and symbols

When processing a `WM_CHAR` event on an OEM key (punctuation, symbol, dead key) the glass code will dynamically query the key's unshifted character to determine the Java code to assign to it. This is necessary since the relationship between OEM key codes and the characters they generate varies f

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v6]

On Tue, 21 Dec 2021 16:42:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as >> expected by more accurately mapping from a Mac key code to a Java key code >> based on the user’s active keyboard layout (the existing code assum

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v6]

t > take into account azerty keyboard layout > https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard > Layout (Y/Z) Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Bug fixes in Robot. Ensu

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v5]

On Thu, 16 Dec 2021 21:40:47 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as >> expected by more accurately mapping from a Mac key code to a Java key code >> based on the user’s active keyboard layout (the existing code assum

Re: RFR: DRAFT 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v4]

On Mon, 13 Dec 2021 19:40:47 GMT, Martin Fox wrote: >> There was a mismatch between the way `get_glass_key` generated the Java key >> code for a given key press and how `getKeyCodeForChar` determined the key >> code for the matching character. For example, when pressing the

Re: RFR: DRAFT 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards

On Mon, 15 Nov 2021 20:13:11 GMT, Martin Fox wrote: > The code that maps from a Windows virtual key code to a Java key code in > `getKeyCodeForChar` did not match the similar code in > `ViewContainer::HandleViewKeyEvent`. The OEM keys are assigned to printable > punctuation an

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v5]

t > take into account azerty keyboard layout > https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard > Layout (Y/Z) Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes br

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]

On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as >> expected by more accurately mapping from a Mac key code to a Java key code >> based on the user’s active keyboard layout (the existing code assum

Re: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v2]

e also enabling the keypad (a common complaint is that Ctrl+’+’ only > works on the main keyboard and not the keypad, see JDK-8090275). > > This PR improves the situation for key events generated by keystrokes. > Manually constructed key events won’t work any better or worse than the

Re: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout

On Mon, 13 Dec 2021 19:46:27 GMT, Martin Fox wrote: > The algorithm in `KeyCharacterCombination.match` relies on the call > `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It > defies the way most keyboard API’s work and no platform has got it right yet. > I

Re: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout

On Mon, 13 Dec 2021 19:46:27 GMT, Martin Fox wrote: > The algorithm in `KeyCharacterCombination.match` relies on the call > `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It > defies the way most keyboard API’s work and no platform has got it right yet. > I

Re: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v4]

On Mon, 13 Dec 2021 19:40:47 GMT, Martin Fox wrote: >> There was a mismatch between the way `get_glass_key` generated the Java key >> code for a given key press and how `getKeyCodeForChar` determined the key >> code for the matching character. For example, when pressing the

RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout

The algorithm in `KeyCharacterCombination.match` relies on the call `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It defies the way most keyboard API’s work and no platform has got it right yet. In particular the Mac and Linux implementations have to resort to a brute-fo

Re: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v4]

test case > [CharComboTest.txt](https://github.com/openjdk/jfx/files/7247265/CharComboTest.txt) > . Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Learn-as-they-type approach to implementing getKeyCodeForChar - Chang

Re: RFR: 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards

On Mon, 15 Nov 2021 20:13:11 GMT, Martin Fox wrote: > The code that maps from a Windows virtual key code to a Java key code in > `getKeyCodeForChar` did not match the similar code in > `ViewContainer::HandleViewKeyEvent`. The OEM keys are assigned to printable > punctuation an

Re: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v3]

On Wed, 10 Nov 2021 18:48:04 GMT, Martin Fox wrote: >> There was a mismatch between the way `get_glass_key` generated the Java key >> code for a given key press and how `getKeyCodeForChar` determined the key >> code for the matching character. For example, when pressing the

RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors

Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`

Re: [External] : Re: Cleaning up warnings in the Mac glass code

2:24 PM, Kevin Rushforth wrote: >> >> >> On 11/30/2021 12:18 PM, Martin Fox wrote: >>> I can set this up to exclude deprecation warnings. When I turn on >>> warnings-as-errors and exclude deprecations there are only a handful of >>> changes needed in gla

Re: Cleaning up warnings in the Mac glass code

he use of deprecated APIs be an error). > > -- Kevin > > > On 11/24/2021 7:44 PM, Michael Strauß wrote: >> That's a good idea. In general, warnings should always be treated as errors. >> >> >> On Thu, Nov 25, 2021 at 2:01 AM Martin Fox wrote: >>>

Cleaning up warnings in the Mac glass code

The Mac glass code generates a lot of compiler warnings. I tried cleaning this up and discovered that two of the warnings are brand new, courtesy of me. One of the headers in PR #651 has a typo that I didn’t catch and neither did the two reviewers. The compiler generated two warnings but they we

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]

On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as >> expected by more accurately mapping from a Mac key code to a Java key code >> based on the user’s active keyboard layout (the existing code assum

RFR: 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards

The code that maps from a Windows virtual key code to a Java key code in `getKeyCodeForChar` did not match the similar code in `ViewContainer::HandleViewKeyEvent`. The OEM keys are assigned to printable punctuation and symbols in way which varies across layouts and even keyboards. To determine

Integrated: 8227371: Drag&Drop while holding the CMD key does not work on macOS

On Fri, 22 Oct 2021 17:32:10 GMT, Martin Fox wrote: > During a drag-and-drop operation on the Mac the Command key will filter out > every drag source operation except `NSDragOperationGeneric` (this behavior is > provided by the OS). JavaFX drag sources only set the Move, Copy, and Lin

Integrated: 8232812: [MacOS] Double click title bar does not restore window size

On Tue, 5 Oct 2021 20:36:37 GMT, Martin Fox wrote: > The test case for JDK-8160241 creates a window in a zoomed state (as defined > by macOS). When the OS later goes to unzoom the window it will try to shrink > it down to 1 point wide. This was entered as JDK-8163137 but the fix

Re: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v3]

test case > [CharComboTest.txt](https://github.com/openjdk/jfx/files/7247265/CharComboTest.txt) > . Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Remove extraneous whitespace - Changes: - all: https://git.openjdk.j

Re: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v2]

test case > [CharComboTest.txt](https://github.com/openjdk/jfx/files/7247265/CharComboTest.txt) > . Martin Fox has updated the pull request incrementally with two additional commits since the last revision: - Add manual test for KeyCharacterCombination - Handle same characte

Re: RFR: 8227371: Drag&Drop while holding the CMD key does not work on macOS

On Fri, 22 Oct 2021 17:32:10 GMT, Martin Fox wrote: > During a drag-and-drop operation on the Mac the Command key will filter out > every drag source operation except `NSDragOperationGeneric` (this behavior is > provided by the OS). JavaFX drag sources only set the Move, Copy, and Lin

RFR: 8227371: Drag&Drop while holding the CMD key does not work on macOS

During a drag-and-drop operation on the Mac the Command key will filter out every drag source operation except `NSDragOperationGeneric` (this behavior is provided by the OS). JavaFX drag sources only set the Move, Copy, and Link drag operation bits so the Command key reduces the set of available

Re: Mac drag-and-drop questions

choose the transfer mode based on context it needs to know that the user isn’t trying to force a specific transfer mode. I don’t see how that’s possible with the current API. > On Sep 30, 2021, at 3:55 PM, Martin Fox wrote: > > Kevin, > > As a heads up there are actually two beha

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]

On Wed, 6 Oct 2021 19:42:41 GMT, Johan Vos wrote: >> @tomsontom I've added the Swing-style code as WIP PR #519. There are >> comments in the PR that probably should be in the code but I wanted to >> reduce the code diffs. >> >> PR #519 (and Swing) tend to get codes for punctuation keys wrong o

RFR: 8232812: [MacOS] Double click title bar does not restore window size

The test case for JDK-8160241 creates a window in a zoomed state (as defined by macOS). When the OS later goes to unzoom the window it will try to shrink it down to 1 point wide. This was entered as JDK-8163137 but the fix for that bug inadvertently disabled unzooming altogether. This PR fixes 8

Re: Mac drag-and-drop questions

https://bugs.openjdk.java.net/browse/RT-31449 --> > https://bugs.openjdk.java.net/browse/JDK-8116268 > > -- Kevin > > On 9/30/2021 3:03 PM, Martin Fox wrote: >> I was just looking at JDK-8237329 which is a drag-and-drop bug on the Mac; >> holding down the Command k

Mac drag-and-drop questions

I was just looking at JDK-8237329 which is a drag-and-drop bug on the Mac; holding down the Command key alone is guaranteed to disable an internal dnd operation. I’m putting together a PR to fix this. While going through the bug database looking for related bugs I ran across JDK-8153032 which n

RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout

There was a mismatch between the way `get_glass_key` generated the Java key code for a given key press and how `getKeyCodeForChar` determined the key code for the matching character. For example, when pressing the plus sign on a US keyboard `get_glass_key` correctly generated `KeyCode.EQUALS` bu

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]

On Tue, 25 May 2021 10:40:50 GMT, Tom Schindl wrote: >> Is there some reason you would prefer a Swing-style implementation over the >> approach I submitted in this PR? The Swing code breaks down if an >> accelerator calls for the Option modifier alone or in addition to Command. >> I'm still in

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]

On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as >> expected by more accurately mapping from a Mac key code to a Java key code >> based on the user’s active keyboard layout (the existing code assum

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]

On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as >> expected by more accurately mapping from a Mac key code to a Java key code >> based on the user’s active keyboard layout (the existing code assum

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]

On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as >> expected by more accurately mapping from a Mac key code to a Java key code >> based on the user’s active keyboard layout (the existing code assum

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)

On Wed, 24 Mar 2021 22:00:03 GMT, Kevin Rushforth wrote: >> I've written a command line utility that runs through all the keyboard >> layouts available in macOS 11.2.3 and generates a report on how this PR >> would change the Java key codes for each layout. I used it to spot-check the >> behav

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]

t > take into account azerty keyboard layout > https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard > Layout (Y/Z) Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Fixed whitespace error. -

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v3]

t > take into account azerty keyboard layout > https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard > Layout (Y/Z) Martin Fox has updated the pull request incrementally with one additional commit since the last revision: A small number of keyboard layouts r

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)

On Tue, 16 Mar 2021 19:48:56 GMT, Martin Fox wrote: >> Maybe this is a very dumb idea but why are we not using the char to map back >> to the keycode? At least for everything in the ASCII-Range this would be ok >> not? We'd only have to check for special keys

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)

On Tue, 16 Mar 2021 11:13:39 GMT, Tom Schindl wrote: >> On the French keyboard the digits are shifted but I assumed we would still >> want those keys to map to KeyCode.0-9 as they do on Windows. My solution was >> to hard-code those key positions to be digits but this interferes with >> Dvorak

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)

On Fri, 12 Mar 2021 21:28:38 GMT, Tom Schindl wrote: >> @kevinrushforth I have a manual app that can perform a simple test to verify >> that when a robot sends KeyCode.A through KeyCode.Z the system receives the >> characters 'a' to 'z'. On the Mac this sanity test was failing on German and >>

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v2]

t > take into account azerty keyboard layout > https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard > Layout (Y/Z) Martin Fox has updated the pull request incrementally with one additional commit since the last revision: The code now queries both the shifted

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)

On Fri, 12 Mar 2021 18:57:45 GMT, Kevin Rushforth wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as >> expected by more accurately mapping from a Mac key code to a Java key code >> based on the user’s active keyboard layout (the existing code assumes a US >> QWE

RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)

This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user’s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can

Mac key event code and accelerator fixes

. These bugs also tend to generate a lot of duplicate bugs entered against various Mac apps built using JavaFX, I could easily pull more than five out of the Defold issues list. Is anyone else working on this at the moment? These bugs are all unassigned and most are years old. Thanks, Martin Fox