Talk:Mac OS X
BillW 08Dec10: Looking over this page it seems we have three categories of active issues.
- 1) Apply to 1.2.x,
- 2) apply to 1.3.0 to 1.3.3 (I make this distinction since those running OS X 10.3.x must use 1.3.3)
- 3) apply to the latest beta only.
Issues with 1.2.x will never be cleared, so they must remain "active".
Issues with 1.3.0 to 1.3.3 will never be cleared from the point of view of users of OS X 10.3.x, so must remain (?)
Issues with 1.3.4 to 1.3.11, that have been cleared in 1.3.12 should be moved to "cleared".
So perhaps this page would be reorganized along those lines. If there is support for this I'll have a crack at it here in the talk page.
Gale 12Dec10: Thanks, Bill. Yes I largely agree, though I think we don't want to make this page a clone of bugzilla or it will be hard to maintain. It is useful a) as a page of quirks where Mac is different to other OS'es, or b) where things that are expected to work on Mac don't do so in Audacity. Those things a) and b) will mostly need a fourth category "apply to all versions" - and a) will never be fixed unless Mac "fixes" them.
Of the listed "bugs" that still appear to be "active" in 1.3.13, does "greyed out Audacity menu" still apply? I don't recall mentions of it.
Two issues valid in 1.3.13 come to mind that probably should be listed here
- No support for two-finger Trackpad gestures
- Some Audacity shortcuts operate Mac system shortcuts e.g. Command-M
- any others worthy of note?
You say in "Input sources not selectable in Audacity" on Mac Bugs "In versions prior to 1.3.2, Audacity's Mixer Toolbar input selector would normally show only "Default Input Source". Starting with version 1.3.2, the Mixer Toolbar input selector will show the inputs available when the input device is "Core Audio: Built-in Audio". Where is "Core Audio: Built-in Audio" being selected - in Audacity Preferences? Since Bug 11 suggests built-in sources may not always be selectable in Mixer Toolbar on Mac, I've asked for clarification on -devel.
BillW 12Dec10: Thanks, Gale. I'll give this some more thought.
- Re: input devices. "Core Audio: Built-in Audio" is the selection in Devices Toolbar. In Devices Preferences it would be Host: Core Audio (the only choice) and Recording / Device: Built-in Audio. In that case only, the Input Selector is available and shows the choices available within "Built-in Audio". These could be "Line Input", "Digital Input" and "Microphone". If you make any other choice in Devices Toolbar or Preferences / Devices / Recording / Device, the input selector disappears. I consider this correct behaviour. Regarding Bug 11 I consider that cleared on Mac a long time ago. It appears to work "correctly" in 1.3.8 on Mac. I don't know what the issue was on Windows, or why Michael thought it was a problem on Mac. The behaviour is sensible. If a "device" has only one "input" there is no need for the input selector, and it goes away.
I'll edit that section to make it clearer where the device selection is being made.
In the meantime, see User:BillWharrie/Device_and_Input_selection_on_Mac
- Gale:13Dec10: OK, I tried to make this clearer on the Mac Bugs page - edit it further if you wish. If ultimately you wanted to link in that section to a reduced User:BillWharrie/Device_and_Input_selection_on_Mac (which just gave examples of the different scenarios, probably moved to Mac Bugs/Device and Input Selection), I think some might find that useful.
- Re: greyed-out Audacity menu. I've never encountered that. Are we sure it wasn't the users being in Pause instead of Stop? Was it just the Audacity menu that was greyed out?
- Gale:13Dec10: It was specific to the situation after processing the Automatic Crash Recovery Dialogue, not user error. Could you try crashing then recovering a project, select it all and Effect > Amplify, then cancel Amplify while in progress? If you still have access to the menus after that, this can be moved down to "cleared" - you may want to try it in 1.3.3 to see if it reproduces there - I suspect it won't.
- Re: no support for two-finger trackpad gestures. Add to that no support for horizontal scrolling using SHIFT + trackwheel, and no support for horizontal scrolling using the trackball on the "Mighty Mouse", or horizontal scrolling gestures on the "Magic Mouse".
- Gale:13Dec10: Re "No support for horizontal scrolling using SHIFT + trackwheel", I'm not clear whether "Trackwheel" is Mac-specific? Horizontal mouse wheel/ball scrolling without modifier won't work on any OS until we move to Widgets 2.9.x. SHIFT + mouse wheel/ball "should" work on all OS'es. When I asked someone on Mac recently about this he said:
"I can confirm that I can scroll horizontally while holding down the shift key using the trackpad - Mac OS X 10.6.5. In System Preferences on Mac OS under trackpad i have 'use two fingers to scroll' and 'allow horizontal scrolling' checked. I also tested with mouse using Apple's Bluetooth Mighty Mouse. SHIFT + wheel works here too. However in Systems Preferences under 'Mouse' i did have to uncheck the box that said 'zoom using scroll ball while holding Command' to enable holding the Command key to zoom in."
- If he means "uncheck" that looks like a bug?
- Re: system shortcuts. I don't think there's any way around that other than Mac users re-mapping those shortcuts. The ones that come to mind are CMD+M and the F-key shortcuts for Exposé and Spaces. Those conflicts are noted on the Keyboard Shortcut Reference page in the manual. Do we want to repeat them here?
- Gale:13Dec10: I think it should be mentioned - it's listed as bug 88 and Leland regarded it as something we should address. In 1.2 I believe CTRL + M performs the Audacity action. If we don't force the Audacity shortcut to work then we could change the affected default shortcuts on Mac, which I think might be preferable. Could you comment in Bug 88 about that - what do other Mac apps do?