Small beefs about OS X Mavericks misbehavior continue to annoy
Longtime Mac users can be set in their ways. They have workflows that want to be maintained and can present a protective attitude towards their hard-won understandings of the OS X interface and its actions. But Apple keeps messing with them.
You can see this attitude from users and power-users in recent posts about Mavericks and its numerous changes in interface and a bundled applications.
For example, a post by Andrew Cunningham at Ars Technica brought up five complaints from readers, covering the Dock, Finder windows, USB compatibility, Quick Look performance, and QuickTime video conversions.
Quick Look is a very useful feature that Apple introduced with Mac OS X Leopard in 2007. Instead of having to launch an application to view a file, users can get a "look" at a preview image. However, this preview isn't a thumbnail or some small view. It's a goodly-sized image that can fill the screen, and for documents with links, the links are active and clickable. Quick Look is activated through the right-click contextual menu or by selecting the file in the Finder and hitting the spacebar. Newer users to the Mac often don't know about it.
The native file types for Quick Look are HTML, RTF, TXT, TIFF, PNG, JPEG, PDF, DAE, and QuickTime movies. For the other formats, Apple asks developers to create CFPlugIn-style bundled plug-ins, called generators.
However, applications with documents that are of less common or even private content types can still take advantage of the Quick Look feature. Those applications can include Quick Look generators: plug-ins that convert a given document from its native format into a format that Quick Look can display to users.
Cunningham notes recent complaints about Quick View performance.
However, both in our comments and on Twitter, we've noticed complaints about Quick Look's quickness since Mavericks hit. In one comment with 35 upvotes and no downvotes (as of this writing), Ars reader GreyAreaUk complained of a two-to-three-second delay when using Quick Look that didn't exist before.
He suggests that users run qlmanage -l from the Terminal to see if there are third-party Quick Look generators that might be causing the issue. The idea is that they need to be updated for Mavericks. That 's a good idea, however, it could be that Mavericks has changed the formula that OS X uses to decide which graphics card to use in machines with two cards.
For example, my MacBook Pro has an Intel HD Graphics 3000 subsystem and a AMD Radeon 6770M card — the OS decides which to use based on the type of application being used and the file format. Content requiring heavy lifting will get the better, faster graphics subsystem. In Mavericks, this algorithm may now be choosing the slower graphics subsystem to save power. If so, this will likely be fixed in a forthcoming maintenance update.
Meanwhile, over at Betalogue, blogger Pierre Igot points out a significant new interface issue with Saving and Replacing. Both of these functions have been in play starting with Lion a couple of years ago.
Igot points out a new, strange behavior in saving attachments in Mail. There are different options with the Save to Downloads Folder command and Save Attachment... command. Sometimes there's a dialog box asking if you want to replace an existing file.
The problem is with what happens if you click on “Replace” here. Instead of actually replacing the existing file with the new file, OS X… saves the new attachment with the same name in the folder with “-1” added to its name. In other words, it completely ignores your request to replace the existing file and does the same thing as the “Save to Downloads Folder” menu item does! Ironically, if you opt to save your attachments manually in a folder other than Mail’s “Downloads” folder, the problem does not occur. OS X correctly replaces the file. The problem is only with files saved in the default “Downloads” folder.
Like I said, it’s a detail, but it’s not an insignificant one. If you don’t pay attention and don’t notice this behaviour, you might end up having and using the wrong version of a file. You might think that your existing file with the name has been replaced, but it has not and is still the “old” file.
Igot complains that this is another example of Apple focusing on iOS, and the transition of iOS behaviors and interface sensibilities to the Mac. Like many of us, he views this with alarm. iOS is fine — as a mobile OS in a mobile context — but not as the driving paradigm behind workstation computing.
Such a flaw means that you essentially can no longer trust Apple to handle your files reliably without your supervision. Sadly, I am not surprised. When you see that the very notion of a file is being slowly deprecated in a computing environment such as iOS, you do wonder whether Apple can still be counted on to provide a proper “conventional” computing environment, where people create files, share them, store them, handle multiple versions of them, and so on.
Exactly! As I've mentioned in posts over the past couple of years, the iOS creep into the Mac OS is not a good thing for Mac users, especially power users. The fiasco with the rollout of Mavericks and updated iWork applications were due to this strategy down in Cupertino. Please stop it, Apple!
I use St. Clair Software's $35.95 Default Folder X file-saving utility, which can mitigate some of these Save As issues. It lets you quickly select where you want to save a file, presenting favorites, recent and open folders automatically for you. Like Mavericks, it lets you insert Spotlight tags into the file while in the Save dialog, when the details are in short-term memory. And it presents useful permissions and other information about the file. It's more of an every-minute piece of software, rather than everyday one. (Note: I purchased this software myself without any consideration or knowledge from the company).
Here's another Mavericks beef from a recent Apple Support Note. It appears that sometimes Mavericks users are constantly asked to unlock the Local Items keychain for each application being used. This is a great annoyance. It's due to the application sandboxing architecture — another iOS import.
It's the current solution that ticks me off.
In Finder Select Go > Go to folder… (⇧⌘G)
In the window that appears, type the following:
~/Library/Keychains/
Click OK.
Look for a folder with a name similar to this "A8F5E7B8-CEC1-4479-A7DF-F23CB076C8B8". Note: Each folder will have a unique number.
Move this folder to the Trash.
Immediately choose Apple Menu () > Restart to restart your Mac.
After restarting the computer, a new folder is created in the Keychains folder with a name similar to "4B29A0BB-599D-47FC-A2D1-42B5592B130B". There is no need to repeat the steps in this article, or to delete this folder. The new folder is expected and corrects the symptom described in this article.
Okay. Now explain this "resolution" to your Uncle Joe over the phone in Minnesota. If something needs a fix, fix it. If it needs a scriptlet or some user interaction to fix, then supply it. This one is a support nightmare.