Talk:Mac Bugs

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.  "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: 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.
 * Bill:13Dec10: Edited that page further and added images, according to my current understanding of the PPC/Intel differences.
 * Gale:13Dec10: OK I tried to make the Intel/PPC difference a bit clearer in the first sentence in each. It strikes me though that it may not be read when given as a "cleared" bug. Wouldn't it be better to have the current situation as per images as an "active" issue? The emphasis on "active issue" is that it means "current behaviour". Cleared bugs mainly really are Audacity bugs so can be distinguished as such.
 * 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.
 * Bill:13Dec10: Tried this in 1.3.13 and 1.3.3 and no greyed-out Audacity menu.
 * Gale:13Dec10: OK thanks - please move it to "cleared" and "applied to 1.3.2 and earlier".
 * 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:
 * Bill:13Dec10: Command-scrollwheel is a system "shortcut" for magnifying the screen for VI users. Besides turning it off in System Preferences > Mouse and Keyboard > Mouse, the user can instead set a different modifier-key combination to magnify the screen - I've set it to CMD + CTRL + OPTION. So just another case of Audacity shortcuts conflicting with Mac system shortcuts. In Photoshop CS2, with the System Pref set to "Command+scrollwheel" for screen zooming, CMD+scrollwheel zooms the screen. CMD+OPTION+scrollwheel zooms the image. So it would seem that PS CS2 has avoided this conflict by using a different modifier key combination for image zooming. This would be a good option for Audacity as well. And yes, sorry, SHIFT+scrollwheel does do horizontal scrolling in Audacity. However the Magic Mouse scroll button and two-finger scrolling on trackpads does not work. So the above report is accurate.
 * 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?
 * Bill:13Dec10: I'll comment in Bug 88 as well, but Photoshop CS2 uses CMD+M to bring up the "Curves" dialog. In the PS CS2 "Window" menu there is no "Minimize" choice. Function keys are complicated on Mac. With default settings the option in System Prefs > Keyboard and Mouse > Keyboard, "Use all F1, F2, etc. keys as standard function keys" is not checked. So the "special functions" printed on the keys (e.g. volume up/down, brightness up/down) are what the keys do. You have to hold the "fn" key to make them behave as "standard" function keys. Checking that option reverses that behaviour. Further complicating the issue is that the user can set any function key they want to trigger Exposé and Spaces.
 * Gale:28Dec10 I've added your comments and more of my own to Bug 88, expanding it to include the mouse binding conflict.