Documented here:

http://trac.wxwidgets.org/ticket/14351

Seems that there is a way to add it back in, but are we sure the window behind the menu bar is still a prob with wx3?

Leland wrote:
> Seems that there is a way to add it back in, but are we sure the window 
> behind the menu bar is still a prob with wx3?
On my 1024x768 screen I get the window behind the menu bar every time in 2.1.2-alpha, only sometimes in 2.1.1. 

Nothing I can do playing with Y, Normal_Y, Height and Normal Height in audacity.cfg seems to help. Deleting audacity.cfg does not help.

I assume I am an unusual case here?

I can make it happen too with my 1280x800 resolution by deleting my audacity.cfg and setting the dock to NOT auto hide (I normally have it set to hide).  This leaves (in my case) about 710 pixels for windows.

Unfortuantely, the default project window size is 940x729 on OSX, 940x694 on Linux and 940x714 on Windows.

The simple solution is to simply lower the default size in AudacityProject.cpp:GetDefaultWindowRect().  But, there may be a way to figure out what the maximum size a window can be without falling off an edge or being hidden by the menu bar.

Fix for windows opening under the menu bar is available in pull request:

https://github.com/audacity/audacity/pull/69

This will serve as a workaround for the missing Window menu until wxWidgets addresses their ticket.

Thanks Leland. We did not have a bug open for window title trapped under the menu bar so I created it at bug 1195.

DEVEL-FIXMADE as part of this change set.
https://github.com/audacity/audacity/commit/17e2761330154e37e529a7ecdf389d22adc2f7b2

Please mark as REOPENED if I misinterpreted the comment trail and fixes.  Untested as I do not have a Mac.

REOPENED and removed unwanted block on 1243, the fixes for which do not reinstate the Window menu on Mac.

Window menu partially reimplmemented, perhaps adequately enough to close this bug.

https://github.com/audacity/audacity/commit/617fdb387fd56a358510abc0ce33a3d2940a9249

Testing on c9422aa 08Jul16 on Mac El Capitan

Windows Menu restored with the follwing entries
*Minimize
*Zoom
*Bring All to Front

And that's the only three entries that the alpha Manual has:   http://alphamanual.audacityteam.org/man/Window_Menu

The 2.1.2 released Manual has an extra entry for "List of open windows":  http://manual.audacityteam.org/man/window_menu.html

Thanks, Paul. I think we must reopen, because the required Mac shortcut to navigate open application windows is not well known and is only listed on "Keyboard shortcuts for accessibility features" (https://support.apple.com/en-gb/HT204434).  

Even when I pointed out the shortcut, most complainants still went back to 2.1.1.   

REOPENED, title changed from "Window" menu not available" to "Window menu list of open windows not available" and updated the Release Note.

More usefully, if you right click on the Audacity icon in the Task bar at the bottom of the Mac screen, you can then select "Show All Windows".  This will display all open Audacity project windows enabling to choose any on eby clicking it.

Fix in:

https://github.com/audacity/audacity/commit/18cbc2e

This should sufficiently complete the Window menu to resolve the bug's subject.

I should point out that it only includes active projects.  It does not include any non-modal windows.  Though it could be extended to do that, I think it looks cleaner to just have projects.

(In reply to Leland Lucius from comment #15)
Testing on macOS 10.15.4 with Audacity 2.4.0 4475dee

The Window command now shows all active projects



>I think it looks cleaner to just have projects.

I agree

I considered the fix unacceptable because it introduced source code dependency cycles.

I fixed it again at commit c3d0d0370b408435e3c3f7340f1bbd4feaf66d60

Please re-test.

RM decided we go with Leland's fix, which has already been tested, for 2.4.0.  Commit c3d0d0370b4 overruled.

But as I also stated in email, the first fix was also incorrect in case at least one project has been closed.  It could result in the checkmark being placed incorrectly.

(In reply to Paul L from comment #20)
> But as I also stated in email, the first fix was also incorrect in case at
> least one project has been closed.  It could result in the checkmark being
> placed incorrectly.

You mean the project numbers are reused?  I thought they were ever increasing???  

I didn't use the project number for menu placement, only for menu item IDs.  How would that be affected by closing projects?  I'll certainly go give 'er a try just to double check though.

(In reply to Leland Lucius from comment #21)
> (In reply to Paul L from comment #20)
> > But as I also stated in email, the first fix was also incorrect in case at
> > least one project has been closed.  It could result in the checkmark being
> > placed incorrectly.
> 
> You mean the project numbers are reused?  I thought they were ever
> increasing???  
> 
> I didn't use the project number for menu placement, only for menu item IDs. 
> How would that be affected by closing projects?  I'll certainly go give 'er
> a try just to double check though.

Maybe I'm doing something wrong, but I can't get it to incorrectly check the menu item.  I've created 3 projects, saved them to different names, deleted the first one created and then created a new one.  All throughout the correct menu item was checked.

(In reply to Leland Lucius from comment #22)

Sorry, I was mistaken.  No problem with the menu ids.

But there is another problem in case you set locale to French or another language that translates the "&Window" menu title.

I made pull request 496 to fix that.

Testing on macOS 10.15.4 with eb92fc0

The fenêtre command now shows the open Audacity projects when the language is switched to français

-------------------------------------------

One inconsistency this throws up is ...

Why is the "fenêtre" command not capitalized?

This is our normal consistent convention for menu items in Audacity and this one appears to be the only menu or sub-menu command in French Audacity which is not capitalized.

Created attachment 971 [details]
wx313 Windows menu

Well, this was a total waste of time and Paul will be happy that we can rip out my commit for this bug. :-)

It seems that wxWidgets 3.1.3 brings back the full and system managed Windows menu.

We will need to remove our management of the Windows menu entirely or at least the fix I added for this bug once we move to wx313 otherwise we get duplicate entries...the one we add and the one the system adds.

Should I reopen this or should we start some sort of wx313 category of bugs?

A wx313 bug is NOT-A-BUG until we are working on a release that is intended to support wx313.  (Just as not supporting Qt toolkit or SuSE is not a bug currently).

Therefore - I suggest a wiki page for such issues.  When they do become actual bugs they will be new bugs with brand new bug numbers.  This bug can stay closed, with a 'see also' if it is useful to have such.

(In reply to James Crook from comment #27)
> A wx313 bug is NOT-A-BUG until we are working on a release that is intended
> to support wx313.  (Just as not supporting Qt toolkit or SuSE is not a bug
> currently).
> 
> Therefore - I suggest a wiki page for such issues.  When they do become
> actual bugs they will be new bugs with brand new bug numbers.  This bug can
> stay closed, with a 'see also' if it is useful to have such.

Understood, but I'll hold of on a wiki page for now.  I'm not sure how much more I'm going to put into wx313 at this time.  It was really just a diversion to keep me from doing "real job" related stuff that I need to complete.  :-)

(In reply to Peter Sampson from comment #24)
>One inconsistency this throws up is ...
>Why is the "fenêtre" command not capitalized?

This is now logged as P3 Bug #2434

Please verify the fix again after commit
https://github.com/audacity/audacity/commit/2e3c072fd5277d255c650799348fae0522188a67

(In reply to Paul L from comment #30)
> Please verify the fix again after commit
> https://github.com/audacity/audacity/commit/
> 2e3c072fd5277d255c650799348fae0522188a67

But, you might want to hold off until I get wx313 committed as it will be affecting this as well.

So, what I've found is that our version of the Window menu isn't even necessary.  I don't know if it was wx313 that allowed the system to supply the menu or if it was "fixed" earlier.  But, I've built 2.4.2 without ours and the system supplied it on all OSX versions from 10.7 to 10.15.

Try it out in commit:

https://github.com/audacity/audacity/commit/1efb10c

https://github.com/audacity/audacity/actions/runs/113627385

(In reply to Leland Lucius from comment #32)
Testing on macOS 10.15.4 with Audacity 2.4.2 35e88d9

This works fine on Catalina Mac