Another post thanks to Many Tricks' Peter Maurer; this particular bug bit me last night—I spent 30 minutes trying to figure out why a compiled AppleScript with a droplet wasn't working. I never did get it, so I emailed Peter, and he pointed me to these tweets from a while back…
…which means the app won't launch. You have to "chmod +x applet" manually to make it work.
I'm documenting this here so that I can find it more easily the next time I save a compiled droplet AppleScript and forget about this not-so-little bug.
While playing around with Messages this morning, I noticed that it ships with a feature that, if used, throws an error. Steps to reproduce:
Open Messages' preferences.
Set the Applescript handler pop-up to any of the listed scripts:
Close preferences, and try to send a message to anyone.
Revel in the brokenness.
I especially like the execution error: No error message…it's that rare non-error that tosses up an error dialog!
In any event, I think it's shameful that Apple ships the app with a feature—plainly obvious in prefs—that breaks when used. Yes, I know AppleScript is probably dying, but that doesn't excuse shipping the app with a clearly-broken feature; if it doesn't work, just remove it. Apparently this has been an issue since Yosemite's release in October of 2014!
With all that said, fixing this is incredibly easy—it took me about 30 seconds of "work" to find and fix the problem. If you'd like to use the bundled AppleScripts in Messages—either as is, or in some modified form—here's what you need to do
Over the weekend, I wrote about my totally useless search in Mail. I got so frustrated by my inability to search in Mail that I decided it was time to for a complete rebuild. I exported all my locally-saved mail, deleted my accounts, quit Mail, trashed its prefs and data files, rebooted, then rebuild it mailbox by mailbox, account by account.
I started with my iCloud account, which I barely use for anything—it has a total of seven messages in the inbox (four of which are iTunes Store receipts), and only 121 sent messages. As a test, I searched for Linea, an excellent drawing app that I had recently purchased. No matches.
At that point, I decided to quit Mail and force Spotlight to rebuild its index overnight. In Terminal, sudo mdutil -i on / will do just that (and take many hours). Today, opened Mail, and search was still dead. Argh! (I had also tried this suggested fix, but it made no difference.)
But doing some random testing today, I discovered a fix! It's a weird fix, but it seems to work:
If I move all the messages from an inbox or local storage folder into a different local storage folder, they'll be indexed and findable. I can then move them back into the inbox or source folder, and they remain findable. Even more important, newly-added messages seem to be properly indexed, in both the inboxes and the local storage folders.
This doesn't make any sense to me, as any one of my recent actions—rebuilding mailbox indexes, reimporting, and redoing the entire Spotlight index—should have been enough to force a rebuild. But for whatever reason, only manually moving the messages seems to force a rebuild.
Now pardon me while I go back to manually dragging a quarter-million email messages around…
For the last couple macOS releases, I've had nothing but trouble searching in Mail. Note that I didn't write "trouble searching mail," but rather, "trouble searching in Mail." For example, today I needed to find an email from my business partner Peter about a hidden pref in Butler. (I was hoping this pref could help a user who was having problems with the pasteboard in a certain app.)
Based on a document on my hard drive, I knew the name of the default was Pasteboard Normalization Interval, but I couldn't remember the syntax of the defaults write command to set its value. So I searched in Mail…
So clearly, no emails in my database contain the words I'm looking for, right? Here's the exact same search, run in Spotlight:
Not one but two email messages match my search, and provided the needed syntax for the command.
Wait, I know what you're thinking: "Ahh, look, it's in quotes!" Doesn't matter; searching Mail for "Pasteboard Normalization Interval" still results in zero matches. Searching on even one word of the phrase, like Normalization, also finds no matches.
Again, I know what you're thinking: "Oh, I bet the Mail index is screwed up." Nope; even after rebuilding the index on all 250,000+ messages in my database, no matches are found. (And yes, I let the index complete its rebuild, which took hours.)
I've heard from others that search in Mail works for them. But it's a no go for me, and I know, for others. So something's wrong, but I don't know exactly what it is, nor how to fix it.
So for now, I have to rely on Spotlight to search Mail…or a third-party app, but more on that in a bit.
Once a month, I download roughly 25 gzipped (.gz) files from Apple—these are our Mac App Store sales reports, with one file for each App Store region. I could have Safari expand these files (via the "Open 'safe' files after downloading' item in its preferences), but I prefer to leave that option unchecked. (Why? I often download archives that I want to leave archived, and I like to keep originals of many of the things I download).
If you work with lots of compressed files, you're probably familiar with what happens in Finder (see note) when you go to expand any semi-large number of files: The infamous Dancing Dialog™. It looks something like this…
[Note: Technically, this isn't Finder, it's Archive Utility doing the expansion. But this is the service that Apple provides to expand compressed files, and it's what 99% of macOS users will use. It can be changed via the Get Info dialog, but very few people will take that step. So to most users, it seems it's Finder handling the expansion. For ease of reference, I'm going to say it's Finder doing the expansion.]
Not only is this randomly-resizing dialog box visually annoying, it turns what should be a super-fast process into one that takes a ridiculous amount of time. The end result is that users think they have a slow machine—"it took over 12 seconds to expand 25 tiny little archives!"—when what they really have is a horrendously slow GUI interface to a super fast task.
Just how fast is the task, if the GUI doesn't get in the way? Thanks to the Unix core of macOS, we can answer that question using Terminal, the geeky front-end to the Unix core. The Unix command to expand .gz archives is gzip; so to expand all the .gz files in a folder (and keep the originals), you'd use this command in Terminal:
gzip -d -k *.gz
If you try this, you'll find out it's nearly instantaneous—press Return, and the files are expanded. Unix actually gives us a way to see exactly how fast it is, via the time command:
$ time gzip -d -k *.gz
real 0m0.013s
user 0m0.002s
sys 0m0.005s
This was for a set of 24 .gz archive files (on a solid state drive), and the real line in the output shows exactly how long it took to expand them all: 0.013 seconds. By comparison, I made a screen recording (with an onscreen stopwatch for timing) of Finder expanding the same 24 files; it took 12.8 seconds for all the dialog dancing to end. Think about that…
Expand 24 .gz files
Finder: 12.8 seconds
Terminal: .013 seconds
Terminal is 984.6x faster than Finder
To put those results another way, if expansion time is linear, gzip could expand 23,631 files in the time Finder takes to expand 24 files. That's nuts!
(You can watch this video for a visual comparison of expanding the same set of files in Finder and Terminal.)
So it's not the computer that's slow, it's the GUI interface to the computer that (in this particular use case) is incredibly, horrendously slow. And there's no need for it—the separate individual progress bars, appearing and vanishing in under a second each, provide no useful feedback to the user. They just slow down the task.
Finder (née Archive Utility) should just execute the task without any visual feedback (though it should pop up a window if there are exceptions). If visual feedback is really required, a window with a single progress bar for the entire task would be OK, but would still slow operations down.
This is a great example of how an everyday task can make you think you have a slow computer, when what you really have is a fast computer with a slow interface element. Given how often we all deal with compressed files, it'd be nice to see Apple clean up this mess. Until they do, however, you can harness the power of Unix—even while in Finder—to speed up the task. Here's one way to do just that.
Kirk McElhearn explains how Messages in Yosemite has trouble sending pasted images. These problems typically only occur between people who use AIM accounts in Messages; sending pasted messages when using iMessages' accounts seems to work fine. (I use an AIM account to keep iMessage traffic off my main Mac, and for its great screen sharing.)
Kirk's article details the fix, which is to kill the imagent process, which is what controls Messages. He uses Activity Monitor to do so, which works fine. But I have to kill the stupid imagent many times a day, so I wrote the World's Easiest AppleScript™ to do the work for me.
Unlike my previousincidents with iTunes and iOS devices, today's report isn't on a sync problem per se.
It's more like a math problem which then leads to a sync problem. Here's the tl;dr version: I have an iPad with 5GB of free space, and I cannot add a 1.8GB movie to it, as iTunes eventually tells me it needs another 526MB of space in order to do so.
During the attempted sync of this movie, iTunes displays some horridly bad math skills; just watch the video to see.
I have no idea how to resolve this, short of restoring the iPad, which I'd rather not do. (I've already unsynced and resynced everything, in an attempt to straighten out the math, but to no avail.)
For those who aren't familiar, Console (found in Applications > Utilities) is an application that shows you what's happening beneath the lovely skin of OS X. Open the application, and you'll see a combination of status and error messages from any number of sources.
If you've never looked at Console before, you might be surprised by just how much stuff gets written there. But with the release of Yosemite, things have really taken a turn for the worse—the amount of stuff written to Console is greater than I recall for prior OS X releases.
As a test, I set up a new Yosemite virtual machine, installed ScreenFlow (and nothing else), then launched and interacted with a number of Apple's apps for two minutes while recording the screen. The results are quite sobering; here's what two minutes of Console logging looks like, reduced to a 10-second movie:
As you can see, there are a lot of Console entries in just two minutes.
Those following me on Twitter this weekend will have noticed that my (lovely, stunning, amazing, I am keeping it) iPhone 6 is not playing nicely with iTunes. I've invested over 10 hours—in one day—just trying to get music and movies onto my iPhone.
Frustrated as hell, I decided ask Tim Cook for some tech help, not that I have much hope of any sort of reply. Emails to his address, however, are apparently all read by someone. For those having similar issues, I think it may be useful to also send your feedback in Tim's direction; his email address (not a secret, published in many places) is tcook at Apple's domain. Perhaps if there are enough voices providing feedback in high places (not that Tim reads these himself), we might see some action.
Further update: I have now done two full system restores. I did the second just before bed last night, and let the iPhone sync overnight. On wake, everything worked! So then I added in a few more movies, and—of course—they failed to sync. So now I'm back where I started, oh so many hours ago.
Anyway, For the curious, here's the tech support request I sent to Tim yesterday.
Note: Dropbox—sadly—removed this feature in July of 2017, so don't even bother reading any further.
Did you know that Dropbox lets you create photo albums? No? Me neither, until this morning, that is. And it turns out, it's incredibly easy to do:
Copy or move a folder of images into your Dropbox folder. Choose any location within the Dropbox folder that you wish; I set up a Photos folder to hold slideshows.
Open the Dropbox web site, and sign in to your account.
Navigate to the folder you just uploaded, right click, and choose Create album.
Click Share album, then copy the link or directly invite those you'd like to see the album.
That's it, your'e done. The only time-consuming portion of the process is uploading the images; creating and sharing the album takes almost no time at all. That's about as simple as it gets.
Now assume you want to do the same thing using iPhoto: create a web-based slideshow of images for anyone to see via a shared URL. Sure, you could use iCloud's Photo Stream, but that's not a web-based solution. Instead, you'll need to use File > Export in iPhoto, and either create a Web Page or a Slideshow. Slideshow is really misnamed, though, as what it really creates is a movie of your images. So Web Page it is.
Did you know that