In my recent post A new set of Hubble deep space iMac retina desktops, I included a set of auto-cropped 5120×2880 desktops. In that post, I wrote:
These images were automatically cropped from the master image (after I cropped that; more detail on what I did is coming in a follow-up post), via ImageMagick.
So this would be that post: How to auto-crop huge images using ImageMagick. If you’re not familiar with it, ImageMagick is a set of command-line tools to manipulate images. There are a number of ways to install ImageMagick, but I used Homebrew (brew install imagemagick).
In Part 1 of my 2014 vs 2019 iMac comparison articles, I provided an overview and a number of comparison benchmark results. In Part 2, I looked at changes in gaming performance between the two machines.
But there was one more thing I wanted to do: Compare Blu-ray ripping speeds. At the time, though, I didn’t have any new movies to rip, and I really didn’t want to spend the time re-ripping an existing movie. Now, though, I do have a few new movies to rip, as I’m trying to finish our collection of all the films in the first three phases (now called the Infinity Saga) of the Marvel Cinematic Universe.
That meant buying the films I’d liked the least—The Incredible Hulk and the first two Thor movies. With that came the chance to compare the Blu-ray ripping speed of the two iMacs. I use the method described in my article Revisiting ripping Blu-ray discs, which is this:
- Use MakeMKV to create an MKV file on the hard drive that contains the video and audio tracks.
- Use Don Melton’s Video Transcoding tools to create the final movie from the MKV file.
Using The Incredible Hulk, I timed how long it took to create the MKV file and how long it took to create the finished movie. Without further ado, the results (times are in hh:mm:ss format)…
I recently reviewed my new third-party mouse, the Logitech MX Master 2s ($70 at Amazon). I love all the customizable buttons on this mouse, and in particular, the ability to create gestures (which are simply a directional drag while holding down a button).
I’ve used two buttons to create a total of 10 gesture actions on my mouse:
I created the above image from the Logitech Options app, so I can refer to it if I forget which action I’ve assigned to which gesture. But it’s a pain to find the folder on the disk and open it just to see the image. Then I remembered I had an unused button on my mouse1The upper button of the two near the side scroll wheel…
Note: While the following is specific to my Logitech mouse in terms of implementation, read on if you’re curious about how to access QuickLook previews from Terminal and/or via a simple AppleScript.
My new iMac runs Mojave; my old iMac never moved off High Sierra, which I felt was a fine version of macOS. Now that I have no choice but to use Mojave full time (I have it on my laptop for work purposes), I’m finding some annoying changes. Amongst those annoyances, this one is—by far—the most annoying…
That’s a set of messages in Mail, as viewed in Classic View mode (using San Francisco Display at 15pt on both Macs).
Somewhere in Apple, someone thought it’d be a great idea to reduce the line spacing in Mail—only when using Classic View, which is my forever-preferred view. Maybe they’re doing this to force us to upgrade to the modern view?
There are some musical tracks that—even though they’re distinct on the CD (or sold as separate tracks online)—are meant to be played together. As examples, there are a number of such Pink Floyd tracks, Queen’s We Will Rock You and We are the Champions, and Jackson Browne’s The Load Out and Stay.
I thought I remembered that iTunes used to be able to merge such tracks, and said as much on Twitter:
From the responses, I learned that my memory was wrong: You could only merge tracks during a CD import, which you can still do today:
But for online purchases or other non-CD music, the only solution appeared to be exporting the tracks, merging them together, then reimporting as one. (Doug Adams’ $5 Join Together, for example, makes the process about as simple as possible.)
I only had a few such tracks I wanted to combine, so duplicating song data and using an external tool seemed like overkill, but it seemed like the only way. Then Chris Jennings came up with a solution that works for me (with some caveats…).
Note: Revised on December 4, 2018 with a much better implementation of the pop-up palette, and some changes in timing and mouse movement.
One of the “problems” with Keyboard Maestro is that it’s so useful I use it a lot, leading to a large collection of macros. Due to the number of macros, sometimes when I want to add a new shortcut, I can’t remember if I’ve used that shortcut before or not. Today’s tip comes in two flavors to address that problem: Simple and Complex.
The Simple solution
Short of just trying the shortcut, there’s a way to check from within Keyboard Maestro itself: Type the macro’s activation keys into the search box, as seen in the box at right.
You can’t do this by pressing the actual shortcut keys—you have to type their character representations. You can do this with the “Show Emoji & Symbols” option under the flag icon in the menu bar, if you’ve enabled it in the Keyboard System Preferences panel. But finding those few special keys (if you even know how to search for them) is a pain.
Technically, you could also use the pop-up character palette macro I wrote, except there’s an issue: When the palette activates, it deactivates the search box, so the characters don’t make it there. It’s also overkill for this task, because there are characters that wouldn’t be part of keyboard shortcuts, and you’d never need the HTML codes, just the characters.
So I wrote what wound up being a set of new macros that make searching for assigned keyboard shortcuts much easier.
I occasionally need to help one of our customers get the bundle identifier for a given app, for some purpose with one of our apps. While the task isn’t complicated—the value is stored in a file named Info.plist within each app bundle—it’s not something that’s necessarily easy to explain to someone who doesn’t have a lot of Mac experience.
I figured there must be a less-complicated solution, and I was right, though it’s probably higher on the geek factor. After some searching, I found this thread at Super User, which offers a number of solutions. The simplest—and always working, in my experience—was the very first one: Open Terminal and run this command:
osascript -e 'id of app "Name of App"'
The "Name of App" is replaced with the name of the app as it appears when hovering over its Dock icon. For Excel, for example, it’d be:
osascript -e 'id of app "Microsoft Excel"'
Run that command, and it returns com.microsoft.Excel, which is just what I need—I just have the customer copy the output and email it back to me.
A fair number of my apps are still 32-bit—see how many you still have—though many I don’t really care about all that much. But there’s one suite of apps that I use every day, usually multiple times a day: Fujitsu’s ScanSnap apps. This is the software bundled with the ScanSnap ix500 scanner.
While Fujitsu has been good about updating their software in the past, I was a bit concerned about the upcoming 64-bit transition. So I both tweeted at them and sent them an email. I haven’t seen a reply on Twitter, but a (clearly form letter) reply to my email is at least somewhat encouraging:
There is no problem in the behavior of the application or the OS concerned. The message is only inform that the application needs to be modified for compatibility with next-generation macOS (which should be available near the end of the year). PFU is going to resolve this, but the resolution date is not set yet. In the meantime, please continue using the latest version of the software available.
This blurb was obviously prepared as a response to those complaining about the new 32-bit warning dialog in macOS 10.13.4, but it does seem to address the longer-term question: Fujitsu is planning to “resolve this,” which hopefully implies 64-bit versions are in our future, though at some not-yet-disclosed date.
There are very few things in my workflow that I couldn’t replace…but replacing my ScanSnap and everything it does for me would be quite difficult. Hopefully we’ll see a 64-bit ScanSnap suite before this fall’s deadline.
The other day while browsing the Mac App Store, I clicked on an app’s web site link, only to be greeted with this lovely “Can’t Find the Server” error message in Safari…
That got me wondering about just how often that happens—how many apps are out there that are still in the store, yet their developers have closed down their work and moved on to other projects? I thought it might be interesting to look at my App Store purchases and see just how many of them had broken web site links in their App Store entries.
Then I thought that as long as I was looking at each of my purchases, I might as well collect some additional data. So I put together a simple FileMaker Pro database with a few fields for each app…
During my spare time over a few days and nights, I went through every entry in my App Store Purchased list (after unhiding some apps that I’d hidden). I installed them (if they weren’t already installed), tried to run them, and completed the above data card for each app.
I then tried to answer some questions about my App Store purchases over the years…
- How many apps have I purchased? 
- How many do I still use? 
- What types of apps do I purchase? [A variety; lots of games]
- How many appear to have no-longer-there developers? 
- How many of the apps are still in the App Store? 
- How recently have those apps been updated? [Check the chart]
If you want more detail than the [bracketed tl;dr notes] provide, keep reading…
As part of this longer post on my purchases from the Mac App Store over the last seven years, one particular bit really struck me: Based on my purchases, at least, there are a a lot of rarely-updated apps—and games in particular—in the Mac App Store.
Of the 116 purchases (or free downloads) I’ve made since the App Store opened, 90 are still available in the App Store today. At first glance, that seems pretty good—78% of what I have is still in the App Store. But it doesn’t look quite so good if I examine when each of those 90 apps was last updated:
Yes, 51 of those 90 apps (57%) have been updated within the last year, and that’s good. But what’s not good is that the remaining 39 apps (43%) haven’t been updated in at least a year—and of those 39 apps, 21 of them (over half!) haven’t been updated in four or more years.
Digging into those 21 apps reveals that four of them are utilities, five are general use apps, and 12 of them are games.