Posts in the Mac Category

I’ve been a bit over a month now on my new 14” MacBook Pro, and I have complaints.  Not about the hardware, which is solid yet lightweight, super-quiet yet incredibly fast and powerful, long-lived on battery, and decent enough under the fingertips.  Plus, all the keyboard keys Just Work™, unlike the MBP it replaced!  So that’s nice.

No, my complaints are entirely about the user environment.  At first I thought this was because I skipped directly from OS X 10.14 to macOS 13, and simply wasn’t used to How The Kids Do Things These Days®, but apparently I would’ve felt the same even if I’d kept current with OS updates.  So I’m going to gripe here in hopes someone who knows more than me will have recommendations to ameliorate my annoyance.

DragThing Dismay

This isn’t on Apple, but still, it’s a huge loss for me.  I know I already complained about the lack of DragThing, but I really, really do miss what it did for me.  You never know what you’ve got ’til it’s gone, right?  But let me be clear about exactly what it did for me, which so far as I can tell no macOS application does, nor does macOS itself.

The way I used DragThing was to have a long shelf down the right side of my monitor containing small-but-recognizable icons representing my most-used folders (home directory, Downloads, Documents, Applications, a few other folders) and a number of applications.  It stayed there all the time, and the icons were always there whether or not the application was running.

When I launched, say, Firefox, then there would be a little indicator next to its application icon in DragThing to indicate it was running.  When I quit Firefox, the indicator went away but the Firefox icon stayed.  And also, if I launched an application that wasn’t in the DragThing shelf, it did not add an icon for that application to the shelf. (I used the Dock at the bottom of the screen to show me that.)

There are super-powered application switchers available for macOS, but as far as I’ve seen, they only list the applications actually running.  Launch an application, its icon is added.  Quit an application, its icon disappears.  None of these switchers let me keep persistent static one-click shortcuts to launch a variety of applications and open commonly-used folders.

Dock Folder Disgruntlement

Now I’m on to macOS itself.  Given the previous problem, the Dock is the only thing available to me, and I have gripes about it.  One of the bigger ones is rooted in folders kept on the Dock, to the right of the bar that divides them from the application icons.  When I click on them, I get a popup (wince) or a Stack (shudder) instead of them just opening the target folder in the Finder.

In the Before Times, I could create an alias to the folder and drop that in the Dock, the icon in the Dock would look like the target folder, and clicking on the alias opened the folder’s window.  If I do that now, the click-to-open part works, but the aliases all look like blank text documents with tiny arrows.  What the hell?

If I instead add actual folders (not aliases) to the Dock, holding down ⌥⌘ (option-command) when I click them does exactly what I want.  Only, I don’t want to have to hold down modifier keys, especially when using the trackpad.  I’ve mostly adapted to the key combo, but even on desktop I still sometimes click a folder and blink in irritation at the popup thingy for a second before remembering that things are stupider now.

Translucency Tribulation

The other problem with the Dock is that mine is too opaque.  That’s because the nearly-transparent Finder menu bar was really not doing it for me, so acting on a helpful tip, I went and checked the “Reduce Transparency” option in the Accessibility settings.  That fixed the menu bar nicely, but it also made the Dock opaque, which I didn’t actually want.  I can pretty easily live with it, but I do wish I could make just the menu bar opaque (without having to resort to desktop wallpaper hacks, which I suspect do not do well with changes of display resolution).

Shortcut Stupidity

And while I’m on the subject of the menu bar: no matter the application or even the Finder itself, dropdown menus from the menu bar render the actions you can do in black and the actions you can’t do in washed-out gray.  Cool.  But also, all the keyboard shortcuts are now a washed-out gray, which I keep instinctively thinking means they’ve been disabled or something.  They’re also a lot more difficult for my older eyes to pick out, and I have to flick my eyes back and forth to make sure a given keyboard shortcut corresponds to a thing I actually can do.  Seriously, Apple, what the hell?

Trash Can Troubles

I used to have the Trash can on the desktop, down in the lower right corner, and now I guess I can’t.  I vaguely recall this is something DragThing made possible, so maybe that’s another reason to gripe about the lack of it, but it’s still bananas to me that the Trash can is not there by default.  I understand that I may be very old.

Preview Problems

On my old machine, Preview was probably the most rock-solid application on there.  On the new machine, Preview occasionally hangs on closing heavily-commented PDFs when I choose not to save changes.  I can force-quit it and so far haven’t experienced any data corruption, but it’s still annoying.

---

Those are the things that have stood out the most to me about Ventura.  How about you?  What bothers you about your operating system (whichever one that is) and how would you like to see it fixed?

Oh, and I’ll follow this up soon with a post about what I like in Ventura, because it’s not all frowns and grumbles.

• Ventura Vexations was published on Tuesday, April 4th, 2023.
• It was assigned to the Commentary, Mac, and Rants categories.
• There have been five replies.

A sizeable chunk of my work at Igalia so far involves editing and updating the Mozilla Developer Network (MDN), and a smaller chunk has me working on the Web Platform Tests (WPT).  In both cases, the content is stored in large public repositories (MDN, WPT) and contributors are encouraged to fork the repositories, clone them locally, and push updates via the fork as PRs (Pull Requests).  And while both repositories roll in localhost web server setups so you can preview your edits locally, each has its own.

As useful as these are, if you ignore the whole “auto-force a browser page reload every time the file is modified in any way whatsoever” thing that I’ve been trying very hard to keep from discouraging me from saving often, each has to be started in its own way, from within their respective repository directories, and it’s generally a lot more convenient to do so in a separate Terminal window.

I was getting tired of constantly opening a new Terminal window, cding into the correct place, remembering the exact invocation needed to launch the local server, and on and on, so I decided to make my life slightly easier with a few short scripts and aliases.  Maybe this will be useful to you as well.

First, I decided to keep things relatively simple.  Instead of writing a small program that would handle all server startups by parsing shell arguments and what have you, I wrote a couple of very similar shell scripts.  Here’s the script for launching MDN’s localhost:

#!/bin/bash
cd ~/repos/mdn/content/
yarn start

Then I added an alias to ~/.bashrc which employs a technique I swiped from this Stack Overflow answer.

alias mdn-server="open -a Terminal.app ~/bin/mdn-start.bsh"

Translated into English, that means “open the file ~/bin/mdn-start.bsh using the -application Terminal.app”.

Thus, when I type mdn-server in any command prompt, a new Terminal window will open and the shell script mdn-start.bsh will be run; the script switches into the needed directory and launches the localhost server using yarn, as per the MDN instructions.  What’s more, when I’m done working on MDN, I can switch to the window running the server, stop the server with ⌃C (control-C), and the Terminal window closes automatically.

I did something very similar for WPT, except in this case the alias reads:

alias wpt-server="open -a Terminal.app ~/bin/wpt-serve.bsh"

And the script to which it points reads:

#!/bin/bash
cd ~/repos/wpt/
./wpt serve

As I mentioned before, I chose to do it this way rather than writing a single alias (say, local-server) that would accept arguments (mdn, wpt, etc.) and fire off scripts accordingly, but that’s also an option and a viable one at that.

So that’s my little QoL (Quality of Life) upgrade to make working on MDN and WPT a little easier.  I hope it helps you in some way!

• Scripted Server Startup for MDN and WPT was published on Friday, April 16th, 2021.
• It was assigned to the Mac and Tools categories.
• There have been no replies.

What happened was, I was preparing to roll out new designs for the News section and event pages of An Event Apart, and I had each rollout in its own branch.  Somewhere in the process of bringing both into the master branch, I managed to create a merge conflict that rapidly led to more and more conflicts.  I very nearly had to take off and nuke the entire site from orbit, just to start over.  (A couple of branches, including dev, did have to get erased and re-pulled.)

Part of what made it worse was that at one point, I accidentally committed a quick edit to master, because I’d forgotten to check out the branch I was trying to edit, and my attempts to undo that mistake just compounded whatever other mistakes already existed.  Once all the dust settled and things were back into good shape, I said to myself, “Self, I bet there’s a way to prevent commits to the master branch, because git is second only to emacs in the number of things you can do to/with it.”  So I went looking, and yes, there is a way: add the following to your .git/hooks/pre-commit file.

#!/bin/sh

branch="$(git rev-parse --abbrev-ref HEAD)"

if [ "$branch" = "master" ]; then
  echo "You can't commit directly to master branch"
  exit 1
fi

I got that from this StackOverflow answer, and it was perfect for me, since I use the bash shell.  So I created the pre-commit file, made a trivial README.md edit, and tried to commit to master.  That’s when OS X Mojave’s Terminal spit back:

fatal: cannot exec '.git/hooks/pre-commit': Operation not permitted

Huh.  I mean, it prevented me from committing to master, but not in a useful way.  Once I verified that it happened in all branches, not just master, I knew there was trouble.

I checked permissions and all the rest, but I was still getting the error.  If I went into .git/hooks and ran the script from the command line by ./pre-commit, I got a slightly different error:

-bash: ./pre-commit: /bin/bash: bad interpreter: Operation not permitted

So I submitted my own StackOverflow question, detailing what I’d done and the file and directory permissions and all the rest.  I was stunned to find out the answer was that Mojave itself was blocking things, through its System Integrity Protection feature.  Why did this simple file trigger SIP?  I don’t know.

The fix, shared by both Jeff and Rich, was to go into .git/hooks and then type the following to check for SIP status:

xattr -l pre-commit

It showed a com.apple.quarantine value, so I then typed:

xattr -d com.apple.quarantine pre-commit

And that was it!  Now if I try to commit a change to the master branch, the commit is rejected and I get a warning message.  At that point, I can git stash the changes, check out the proper branch (or a new one), and then git stash pop to bring the changes into that branch, where I can commit them and then merge the changes in properly.

I may modify the script to reject commits to the dev branch as well, but I’m holding off on that for now, since the dev branch is often where merge conflicts are worked out before going to master.  Either way, at least I’ll be less likely to accidentally foul up master when I’m hip-deep in other problems.

• Preventing Commits to the master Branch in OS X Mojave was published on Monday, February 10th, 2020.
• It was assigned to the Guide, Mac, and Tools categories.
• There have been no replies.

One of the things you discover as a speaker and, especially, a conference organizer is this:  Keynote generates really frickin’ enormous PDFs.  Seriously.  Much like Miles O’Keefe, they’re huge.  We had one speaker last year whose lovingly crafted and beautifully designed 151-slide deck resulted in a 175MB PDF.

Now, hard drives and bandwidth may be cheap, but when you have four hundred plus attendees all trying to download the same 175MB PDF at the same time, the venue’s conference manager will drop by to find out what the bleeding eyestalks your attendees are doing and why it’s taking down the entire outbound pipe.  Not to mention the network will grind to a nearly complete halt.  Whatever you personally may think of net access at conferences, at this point, not providing net access is roughly akin to not providing functioning bathrooms.

So what’s the answer?  ShrinkIt is fine if the slides use lots of vectors and you’re running Snow Leopard.  If the slides use lots of bitmapped images, or you’re not on Snow Leopard, ShrinkIt can’t help you.

If the slides are image-heavy, then you can always load the PDF into Preview and then do a “Save As…” where you select the “Reduce File Size” Quartz filter.  That will indeed drastically shrink the file size — that 175MB PDF goes down to 13MB — but it can also make the slides look thoroughly awful.  That’s because the filter achieves its file size reduction by scaling all the images down by at least 50% and to no more than 512 pixels on a side, plus it uses aggressive JPEG compression.  So not only are the images infested with compression artifacts, they also tend to get that lovely up-scaling blur.  Bleah.

I Googled around a bit and found “Quality reduced file size in Mac OS X Preview” from early 2006.  There I discovered that anyone can create their own Quartz filters, which was the key I needed.  Thus armed with knowledge, I set about creating a filter that struck, in my estimation, a reasonable balance between image quality and file size reduction.  And I think I’ve found it.  That 175MB PDF gets taken down to 34MB with what I created.

If you’d like to experience this size reduction for yourself (and how’s that for an inversion of common spam tropes?) it’s pretty simple:

1. Download and unzip Reduce File Size (75%).  Note that the “75%” relates to settings in the filter, not the amount of reduction you’ll get by using it.
2. Drop the unzipped .qfilter file into ~/Library/Filters in Leopard/Snow Leopard or /Library/PDF Services in Lion.  (Apparently no ~ in Lion.)

Done.  The next time you need to reduce the size of a PDF, load it up in Preview, choose “Save As…”, and save it using the Quartz filter you just installed.

If you’re the hands-on type who’d rather set things up yourself, or you’re a paranoid type who doesn’t trust downloading zipped files from sites you don’t control (and I actually don’t blame you if you are), then you can manually create your own filter like so:

1. Go to /Applications/Utilities and launch ColorSync Utility.
2. Select the “Filters” icon in the application’s toolbar.
3. Find the “Reduce File Size” filter and click on the little downward-arrow-in-gray-circle icon to the right.
4. Choose “Duplicate Filter” in the menu.
5. Use the twisty arrow to open the duplicated filter, then open each of “Image Sampling” and “Image Compression”.
6. Under “Image Sampling”, set “Scale” to 75% and “Max” to 1280.
7. Under “Image Compression”, move the arrow so it’s halfway between the rightmost marks.  You’ll have to eyeball it (unless you bust out xScope or a similar tool) but you should be able to get it fairly close to the halfway point.
8. Rename the filter to whatever will help you remember its purpose.

As you can see from the values, the “75%” part of the filter’s name comes from the fact that two of the filter’s values are 75%.  In the original Reduce File Size filter, both are at 50%.  The maximum size of images in my version is also quite a bit bigger than the original’s — 1280 versus 512 — which means that the file size reductions won’t be the same as the original.

Of course, you now have the knowledge needed to fiddle with the filter to create your own optimal balance of quality and compression, whether you downloaded and installed the zip or set it up manually — either way, ColorSync Utility has what you need.  If anyone comes up with an even better combination of values, I’d love to hear about it in the comments.  In the meantime, share and enjoy!

Translations

• Belorussian courtesy Patricia Clausnitzer
• German courtesy Andreas Beraz

Update 2 Aug 11: apparently there have been changes in Lion — here’s an Apple forum discussion of the problem.  There are two workarounds described in the thread: either to open and save files with ColorSync Utility itself, or to copy the filter to another folder in your Library (or install it there in the first place, above).

Update 27 Mar 12: edited the Lion install directory to remove an errant ~ .  Thanks to Brian Christiansen for catching the error!

• Better PDF File Size Reduction in OS X was published on Thursday, February 25th, 2010.
• It was assigned to the Mac, Speaking, and Tools categories.
• There have been sixty-eight replies.

One of the things that I’ve found mind-bendingly annoying about Leopard (besides its complete refusal to allow classic window management) is the “this file was downloaded from the internet, are you sure you want to open it?” dialog box.  Yes, damn it: I just downloaded the file with the express intent of opening it.  Stop bothering me.  Keep it up and I might mistake you for PC.

What’s even worse is that the dialog requires mouse input to get past.  It would be just within the limits of acceptability if the dialog buttons responded to keyboard input; if I could hit command-O or something to invoke “Open”, then I’d probably keep the safeguard in place, because I could just charge past it with a quick twitch of the fingers.  Since I can’t, I want it gone.  And of course there’s no “don’t ask me again” checkbox to tick.

After a plea on Twitter, I got pointers to a couple of ways to disable this annoyance (as well as a ton of “oh God, I hate that too; let me know if you find an answer!” replies).  The first way is done as a Folder Action.  For a variety of reasons, I’m not that thrilled by folder actions, so I gave it a pass.  The other approach is to write your own preference file.  Ah, much better!  (Why is this better?  I don’t know.  It just intuitively feel like the better approach to me.)

Now, one way is to just disable the warning for all public.item files—which is to say, every type of file.  I was tempted, but it turns out there’s a finer grain that can be applied:  listing specific file types to be ignored.  Better still!  That way I can switch this off for the file types that I download all the time, like HTML files, and keep the safeguard in place for file types I almost never download, like executable scripts.

Doing this means you need a list of OS X’s Uniform Type Identifiers, so I dug around to find that listing, which appears to have moved in the not-too-distant past.  Here’s the preference file I’ve put together with that listing as a guide.  This file lists all of the file types I don’t want to be nagged about.

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
   "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>LSRiskCategoryNeutral</key>
    <dict>
      <key>LSRiskCategoryContentTypes</key>
      <array>
        <string>public.text</string>
        <string>public.plain-text</string>
        <string>public.xml</string>
        <string>public.archive</string>
        <string>public.image</string>
        <string>public.audiovisual-content</string>
        <string>public.font</string>
      </array>
    </dict>
  </dict>
</plist>

I led with public.text because it encompasses not just regular text files, but HTML files as well; public.xml appears to cover XHTML, though I’m not 100% sure where those files fall.  public.audiovisual-content covers all audio and video files, as you might guess.  There are probably a few other types I’ll add over time, as I encounter enough resistance on certain types of files that I don’t need to be safeguarded.  I’ll probably never add public.script or public.executable to the list; personally, I prefer to be warned about that sort of stuff.

To make the magic happen, save the above file (or your own variation) as ~/Library/Preferences/com.apple.DownloadAssessment.plist.  Then log out of and back into your account.  Finito.

So if you’d like to get your Mac to be less of a nag about opening downloaded files, there’s how.  As the links above show, I’m standing on the shoulders of giants here, so my thanks to those who paved the way.  I hope that you will be able to benefit from both their work and my small additions thereto.

Update [13 Mar 09]: Potentially very bad news, folks.  I just tried this on my 10.5.6 machine and it failed utterly.  As did the Folder Action approach.  Older versions of Leopard apparently didn’t have this problem.  Anyone else seeing the same kind of thing on their machines?  If either way is still working for you under 10.5.6, can you tell us which one it is in the comments?  Thanks.

Update [18 Mar 09]: Great news, folks.  Ben Millett kindly sent me a copy of his working-under-10.5.6 file and I tried it out, and it worked!  The difference seems to be that the version I was using was encoded as “Unicode™ (UTF-8, no BOM)” whereas the encoding of the file Ben sent me is “Western (Mac OS Roman)” (both according to BBEdit).  So if your copy doesn’t work, check the file encoding.  Next I’m going to experiment with adding file extensions, and will report back if I meet with success.

• Selectively Disabling Downloaded-File Warnings in Leopard was published on Friday, March 13th, 2009.
• It was assigned to the Mac category.
• There have been twenty-seven replies.

So I’ve been putting off upgrading from Panther to Tiger for quite some time now.  My base reason is that I’ve been really, really busy, but the other reason is that I kept hearing that it wasn’t worth it.  Now, I’m used to the 10.x.0 version of any major OS X release being unstable and the source of many complaints, but it’s up to 10.4.4 now.  That seems like enough time to work out the kinks.

Plus, I have to use Tiger if I want to play with the Mac version of Google Earth.  So there’s that.

Admittedly, I do have Tiger installed on a partition of an external drive, and I’ve played around with it a little bit.  Still, that’s a very far cry from upgrading my laptop’s hard drive from Panther to Tiger.  I know that any major OS upgrade will mean time and energy spent on managing the transition, including re-installing or upgrading some third-party software.  That’s where the “I’ve been busy” thing comes back into play.  It’s a lot easier to take the lazy route: the system I have now works, so why mess with it?  Then again, that same attitude would have kept me in the Classic OS if I’d let it.  At some point, you have to upgrade.

So I put it to the crowd: is Tiger (now) worth taking the plunge?

• The Lazy or the Tiger? was published on Thursday, January 12th, 2006.
• It was assigned to the Mac category.
• There have been thirty-eight replies.

I recently wrote that the font Freight Micro had broken Unicode references.  It turns out that I was basing my comments on a beta version of the font without realizing it.  The designer of the Freight family was good enough to provide me with a copy of the final version of the font, which I tested, and I’m delighted to report that it does not suffer from the same problem.

So my deepest apologies for any misinformation I may have spread. If you see anyone referencing my previous post on this topic, please point them to this one.  Thank you.

• Full Freight was published on Monday, December 19th, 2005.
• It was assigned to the Mac category.
• There have been no replies.

A followup to my previous post: thanks to the nearly impossible to find Character Palette (and thanks to Todd Dominey for instructions on how to enable and use it), I was able to determine the problem and restore my editing pencils.  It turns out that a beta copy of the font “Freight” was what caused the problem.  This beta copy of Freight was for some reason convinced that Unicode 9999 is the reference to a Z-caron instead of a pencil symbol.  It didn’t do this for 9998 or 10000.  Just 9999.

So I removed “beta Freight”, and the pencils returned.  Thanks to everyone who helped me out!

Update: there’s more to the story, namely that the copy of Freight in question was a beta, and not the final release, and the final release doesn’t have the problem that bit me.  I’ve edited this post to reflect that fact.

• Pencilled In was published on Thursday, December 15th, 2005.
• It was assigned to the Mac category.
• There have been three replies.