Partially fixed at dfa91655d3c30af60f347c70106661c68911980a

so far as making the Enter key invoke OK button again.

My recent fixes for bug 682 and others at https://github.com/audacity/audacity/commit/e68b614095119b187e805c6bcfd77bbecedb7539

fixed nost of the symptoms of this bug.

I reverted the previous partial fix at dfa91655d3c30af60f347c70106661c68911980a as no longer necessary.

I think I can claim a complete fix.

I do observe the graying-out of real time effects.  But command-~ on Mac cycles among the open windows of Audacity.  This shows that the real time effect window was not closed, but only lowered behing the project window.  It was therefore correct that real time effects should be disabled in the menu, because only one at a time may be active.  Close the effect window, and the menu items are enabled again.

So the only remaining issue might be to avoid the lowering of the window.  I think that merits a separate and lower priority bug report.

Testing on c9422aa 08Jul16 on Mac El Capitan

Testing with Normalize (as suggested in the steps ...)

The tab key only seems to shift focus to and from the normalization ampiltude box.
The Ok button is always highlighted blue
a) with focus on the normalization ampiltude box and pressing enter the effect works
b) with focus off that box pressing enter does nothing.

The workaround in Steps ... of switching out of an back into Audacity produces the same resukts as above - but after this the RTP effects are no longer grayed out.

(In reply to Peter Sampson from comment #4)

Remember that the focus does move now, but it is not always visible.  The fix for invisible focus on Mac isn't yet shared with you.

You should count eight presses of Tab between highlightings of the dB field.

The focus is really moving to other controls, as you can verify by pressing space.

Commit number 84c0337 may fix TAB key navigability in even more cases on Mac, but focus may still be invisible.

Peter, I would like you to try it again after 84c0337c.

Better, if Gale could make binaries that contain the wxWidgets patches that I will share to make focus visible.

I cannot reproduce your report.  I open the Normalize dialog, which then has focus, and then I only press Tab and Enter keys.  Enter applies the effect, no matter whether I press TAB 0, 1, 2, ..., or 7 times.

Perhaps you did not do exactly that?  Did you click somewhere else so that the effect dialog loses focus?  Did you use any other keys?

Testeing on Mac El Capital 01Aug16 r5c0b183

a) At Step 2 I can tab to and round the effect and pressing enter applies the effect.

b) at steps 3/4 I can still navigate an apply the effect (if I skip step 2)

so fa so good - but ...

c) With an RTP effect at Step 5 I could navigate with tab - but pressing Enter with the Apply higlighted does nothing - but then clicking on Apply does apply the effect - BUT subsequently all the RTP effects are grayed-out and unavailable

I've RESOLVED this with new bugs created - see below.  

(In reply to Peter Sampson from comment #8)
> With an RTP effect at Step 5 I could navigate with tab - but
> pressing Enter with the Apply higlighted does nothing - but then 
> clicking on Apply does apply the effect - BUT subsequently all 
> the RTP effects are grayed-out and unavailable
In HEAD with Widgets rebuilt for Paul's latest patches, ENTER does apply the RTP or other effect even if Audacity has lost and regained focus, but in that case the effect will go behind the project window. The effect is however still running, so RTP effects will be greyed out. Paul explained this in comment 3 and I have now placed that as part of bug 1471.

I noticed that the selected control reverts on switching away from an effect. I put this at bug 1472.

REOPENED. Was fixed at "09cf0a6" on 28Sep16. Suspect https://github.com/audacity/audacity/commit/2e8ee5f .

2.1.3 is now blocking on this.

Gale's suspicion of https://github.com/audacity/audacity/commit/2e8ee5f is correct.

If you revert only part of that -- the change to AudacityApp.cpp -- then that is a sufficient, one-line change.  However, 868 and 1196 would need to be tested again.

A known undesirable effect of this reversion is that if you have a modeless dialog open, such as the freqeuncy window, then cycle repeatedly with command-~ , then the focus in the modeless window changes.  That might merit a lower priority bug.

However the other intended fixes for behavior of command + f6 should remain.

(In reply to Paul L from comment #11)

I confused command + f6 with alt + f6.

This reversion will, unfortunately, cause focus to change when cycling windows with alt + f6.

(In reply to Paul L from comment #12)
> This reversion will, unfortunately, cause focus to change when cycling
> windows with alt + f6.
Bug 868 is already reopened for Xfce. For bug 1196, do you expect no trappage, but on your return to any modeless window after the ALT + F6, the selected button is different? But focus in undocked toolbars and main project window returns to where it was?   

And this would affect Mac and Linux but not Windows?   

I assume then we would exchange a P2 for a new P3 which is an improvement. How would we fix the new P3 without undoing our fix for this P2?

(In reply to Gale Andrews from comment #13)

I observe on Mac that the alt+f6 cycle gets trapped in an undocked toolbar, whether with or without the proposed change.  This is bug 868.  But if you TAB once in the toolbar, then the alt+f6 cycle is unstuck again.

bug 1196 was about the TAB key cycle getting trapped, but I do not see that.

Yes, alt + f6 cycle with modeless dialogs will cause different controls to be focused each time which is a bother.

I don't know what to expect in Linux.

"How would we fix the new P3 without undoing our fix for this P2?"

The ultimate answer might involve changes in wxWidgets sources again, which I am not inclined to research just now.

(In reply to Paul L from comment #14)
> I observe on Mac that the alt+f6 cycle gets trapped in an undocked toolbar,
> whether with or without the proposed change.  This is bug 868.  But if you
> TAB once in the toolbar, then the alt+f6 cycle is unstuck again.
I retested on Mac and Ubuntu 14.04 and don't seem to get any trappage with ALT + F6 or ALT + SHIFT + F6 (these are release builds).  

Is there any way to move selection to the first control in an effect dialogue (where it should be) if selection is not already there?  Would ENTER not then work?

I have made the proposed one line change here:  https://github.com/audacity/audacity/commit/ba263d07791def87352c27d041575f72e0bf508f

Claiming fix made, but the undesirable change of focused control remains.

Cleared "test_single_OS" keyword because the change affects Linux too.

(In reply to Gale Andrews from comment #17)
Paul write is the latest commit for this:
>Now, if you open an effect dialog, Return key will apply it.  
>But, if you cycle among windows with alt+f6, then the focus moves 
>among the controls in the effect dialog, and I don't know how to 
>prevent that.

Testing on Macbook Pro with Sierra ba263d0

This is not what I am seeing

1) Generate Chirp max amplitide 0.5
2) Effect > Normalize
3) dialog opens no focus on the "Normalize maximum amplitude to" input box
4) Enter - does nothing
5) Tab to shift focus to "Normalize maximum amplitude to" input box
6) press Enter - effect works

Also with Alt+F6 I don't get focus moving among the controls of the effect dialog, rathher I get focus shifting between the dialog window and the Audacity window.  The only control that shows blue is the OK.

I don't understand why Peter says tests OK after that description.  Are you sure that the build of Audacity that you have includes the changes I made in wxWidgets?  These affect the focus rings.

I do not see the same behavior.  I have El Capitan.

With the Chirp dialog and the Normalize, the Manage button has focus when they appear, and Spacebar opens the Manage window.  But the OK button has a blue background and in both cases is invoked by Enter.  The effect of Normalize, with no other changes to settings, is not obvious in the waveform, but you can see it in the Undo history.

What I mean about alt+f6 is that focus does indeed alternate between the Audacity project and the dialog, but when it returns to the dialog, it is not at the same control as before.

The test OK flag that I set for MAc after those tests was the minus flag i.e. does not work  (+ flag means it works and ? flag means partly works or unsure).

I have no idea what widgets it has (I never look under the hood) - I just get the latest download from its normal location in this case the 04Dec16 ba263d0, click on it and drag the DMG over as the dialog instructs me and then run Audacity from the Applications folder,  Every time I download I totally trash any existing Audacity so I should be getting a clean install each time.

The ALT+F6 just switches for me flipping between the dialog with OK button blued to the Audacity Window than back to the dialog with the OK button blued.  I get no switching of blue/focus to any of the other buttons: Manage, Preview or Cancel.


And when I invoke the Normalize button it is the OK button that has the blue focus not the MAnage button.

"Focus" means the pale blue border about controls, not the dark blue background that stays on OK always.

In Audacity 2.1.2 on Mac, the focus is invisible.  There is no change as you Tab.  (It does change what Spacebar will do, but you just don't see the ring.)

In 2.1.3 focus rings should move as you Tab, but it requires our custom build of wxWidgets.

If you see moving focus rings with Tab, then you have it, and that is not the explanation.

no moving focus rings for me ...

(In reply to Peter Sampson from comment #22)
On Linux (Debian Xfce), when opening the Nyquist Prompt effect, the fix causes focus to be on the "Load" button rather than (correctly) on the text box.

The "steps to reproduce" are not reproducible on Debian, so perhaps we can make the fix Mac only? (I've tested on my Linux machine and it works for me).

The fix was made Mac-only as suggested by Steve.
 
The fix works correctly for me in my own build and the those provided by Leland which Peter is using. The Leland build has the focus rings in effects. ENTER applies the effect at once even while Manage has focus. If you TAB into random controls and change their values, ENTER still applies the effect as it did in 2.1.1. 

I opened a bug for wandering focus in modeless dialogues, caused by this fix, at bug 1556. 

There is already a separate bug for focus not being in the first control when opening the effect (bug 1518). I refer to focus as "selection" there because we sometimes talk about selecting a control (which should give it the focus ring). I suppose developers prefer it to be described as "focus".

Bill/Cliff have pointed out that the fix depends on Full Keyboard Access https://support.apple.com/en-gb/HT204434#fullkeyboard being enabled by the user, which it isn't by default. 2.1.1 could apply effects on ENTER without Full Keyboard Access being on. 

So I'm reopening and leaving at P2, but the behaviour is now much better than it was in that even with Full Keyboard Access off, only one TAB press is required to then ENTER to close/apply. Release Note and title adjusted.

Another behaviour worse than in 2.1.1 with Full Keyboard Access off is that it is possible to TAB once past the last control into a state where no control has focus and so again, the OK button does not respond to ENTER.

Just to add an observation that the TAB, ENTER sequence does NOT work if the dialog does not have a text field. Using the TAB key is the same as if the user clicked in the text field and entered data the pressed Enter. Examples in point:

1. Normalize takes text input so using tab highlights the text field and Enter then enters the data and starts the effect.

2. Compression effect. This only uses sliders and check boxes to modify the input so without the text field there is no where for the TAB to go so the user can TAB all day and not be able to use the ENTER key to start the effect. 

Using Ctrl+F7 and TABBING twice with the Compression effect will then allow ENTER to start the effect, but of course in those effects with text fields it may take many TABS to get to the field one wants to modify. In the case of Normalize it takes 7 TABs to get to the text field to enter data. Not an efficient way to work.

*** STEPS UPDATED *** with more detail about Compressor and AU/VST.

Testing on macOS 10.13.6 with Mac 2.3.0 alpha 30Jul18 - testing with Normalize effect 

Step 3 - Normalize effect not applied

Step 4 effect still not applied - though the steps to reproduce suggests it does

Step 5 effect still not applied - though the steps to reproduce suggests it does

I confirm Steps 6 & 7 sill fails as the steps suggest

Step 8 Change Pitch effect is not applied - though the steps to reproduce suggests it does

Downgraded to P3 (retains Release Note)

Also, the "Advanced Mixing Options" does not respond to "Enter".

Upgrading this to P3 on the basis of multiple complaints about this on the Forum

Good. This has bugged me for a long time.

(In reply to Peter Sampson from comment #32)

OOPS maent to say:  Upgrading this to P32 from P3 on the basis of multiple complaints about this on the Forum

(In reply to Peter Sampson from comment #34)
P2 that is <sighs very deeply>

Testing on macOS 10.14.6 with 2.3.3 alpha jc007

This now works properly tested with Amplify, Distortion and Compressor

Testing on MacOS 10.14.6, Built Aug 14th, Commit: 44c46f ,using the Normalize, Compressor and Amplify effects, this does NOT work. 

FYI, some time ago the problem was made worse in that the Tab workaround for effects that had text fields stopped working as well. I know of no effect/generator that will respond to the enter key without full keyboard access on.

Changed Test-OK-Mac to off.

This was a pull request by Paul for bug 2107:
https://github.com/audacity/audacity/pull/361

It may also fix this bug - see the comments on the pull request.

MacOS 10.14.6, Commit: efc951

Works fine now. Defaults settings are applied as expected.

DEVEL - FIX MADE
https://github.com/audacity/audacity/commit/da66806bc0a1c5ef517a8403621a2e2dae401f0e

The fix for 2107 also fixes this bug.

Cliff mented in close cousin Bug 2107
https://bugzilla.audacityteam.org/show_bug.cgi?id=2107#c13

"Cliff Scott 2019-08-20 14:59:13 EDT 
Also works for Bug 1329.!

Closing this as FIXED on the basis of Cliff's testing

BTW this works (and always has done) on Windows

As for 2107, so too for this.  I am reopening it for re-verification after I fix 2267.

bug 2267 is now fixed a https://github.com/audacity/audacity/commit/8b532546c905af1168a5d654dc71dda6a5188af5

Retesting adter fix to Bug #2267 on macOS 10.15.2 with Cliff's build of 29Dec19

At step 3 the effect is applied - I tested with several effects