Software Development

I recently had a feature request to add Direct-Paste to ScreenFloat. I had not idea what that meant, so I looked it up. It basically combines the copy-paste operations into one, immediately pasting the freshly copied content into the currently active, frontmost app’s active window. So instead of having to copy the shot and then pasting it into the active app using command-v (or your method of choice), it’s all done in one go.

Now, there is no way this is allowed in the Mac App Store: ScreenFloat would require the Accessibility sandbox entitlement for it (to emulate the command-v key press), and that’s a big no-no. Why? I have no idea – they do have an entire process of reviewing apps set up for this sort of thing, after all. But I digress.

With the recently released ScreenFloat v2.2, I introduced support for Application Scripts, where users can supply their own, custom-made AppleScripts, and ScreenFloat can run them with a copy of a double-clicked floating shot. With that, it’s possible to set up a direct-paste double-click workflow.
Here’s how.

A floating shot being double-clicked, immediately copy-pasting it into the currently active app, TextEdit.
The AppleScript

The AppleScript is fairly simple, and I’ve prepared it for you to download here (.zip, ~4KB).
It expects the shot already having been copied to the clipboard (doable within the same double-click workflow), and then emulates a command-v key press to paste it into the active, frontmost app’s active window.

After you download and unzip the script, place it into this folder on your Mac:
/Users/yourname/Library/Application Scripts/at.EternalStorms.ScreenFloat-[appstore|trial]/

Now it’s accessible from within ScreenFloat for the Run AppleScript double-click action.

Creating the Double-Click Workflow

Your double-click workflow will consist of two actions:

  1. Copy Shot
    copies the double-clicked shot as a file path, or as image data (png, tiff, etc)
  2. Run AppleScript
    runs the selected AppleScript

To set it up, open ScreenFloat’s Settings, select the Floating Shots tab, and under Double-clicking:, click with the mouse-button and modifier keys of your choice (you can set up multiple double-click workflows for different mouse buttons, with different modifier keys).

Press the + button below and select Copy Shot > Filepath | PNG | TIFF | etc
Press the + button again and select Run AppleScript > Direct-Paste Double-Clicked Shot into Active App

Now, when you double-click a shot with your specified mouse button and modifier keys, the shot will be copied to your clipboard, and then the AppleScript will be executed, pasting the clipboard’s contents (your shot) to the active app’s active window.

That’s it. You can now easily copy-paste floating shots into the active app, without having to do the copy and pasting manually.

Minor Caveat
If you set up the double-click workflow for a mouse button with a bunch of modifier keys, be sure to release the modifier keys as soon as you finish the double-click, otherwise the AppleScript will not send command-v to the active app, but [your pressed modifiers] – v, possibly resulting in a beep.
That’s why I implemented a slight delay into the script (0.5 seconds), which you can adjust yourself by just changing that number, giving you more leeway for releasing the modifier keys you set up for the double-click workflow.

Links

Download AppleScript: Paste into currently active app (.zip, ~4KB)
ScreenFloat Application Scripts Instructions

ScreenFloat Website (+ free trial)
Get to Know ScreenFloat 2 Blog Post Series
ScreenFloat Usage Tips

ScreenFloat on the Mac App Store
Eternal Storms Software Productivity Bundle (includes ScreenFloat, Yoink and Transloader at ~25% off)

Enjoy : )

Read more

To start with: it’s difficult, but it can “work”. Sort of.

The star of the show, the MacBook Pro Mid-2012, running macOS Ventura (far right)

Why do this to yourself?

Quite frankly, I didn’t feel like shelling out ~€600 for a refurbished Mac Mini just to be able to test the odd app of mine with iCloud sync. It just seems overkill. And I did have this old MBP lying around, so I thought: why not give it a try?
If all else failed, I’d still have the Mac Mini option, anyway.
And a Virtual Machine doesn’t work, because you can’t log into iCloud / Apple ID in a VM environment for some reason. It could have been so easy…

I’d done it before, too. That 2012-MBP has served me so well over the years, with 6 partitions, reaching from macOS 10.10 Yosemite to macOS 10.15 Catalina, all for testing purposes.

It really speaks to the quality and longevity of these machines. Eleven years old, and still rocking.

Installing macOS 13 Ventura on the MBPMid2012

Getting macOS Ventura (released in 2022) to run on a Mac that’s not supposed to run even macOS 11 Big Sur (released in 2020) is surprisingly easy.
Using OpenCore Legacy Patcher, it was pretty straight forward, with only one *gasp*-I-think-I-just-bricked-this-11-year-old-Mac moment that was resolved by a simple restart (a dialog appeared telling me the installation had to be aborted due to an unknown error, which had no effect at all).
There’s really only one thing that I thought could be improved (complaining on a high level here, since it’s a miracle this works at all in the first place):
You *have* to use an external drive to create the installer drive, you can’t use an internal partition. And you cannot use a partition of an external drive, you have to wipe that drive entirely.
None of my USB thumb drives were big enough (the biggest I have is 8 GB), and all my other drives have more or less important data on them, so wiping one of them was out of the question.
Thankfully, my girlfriend had a completely empty 2TB hard drive handy that she was supposed to use for backups (and never did), so I was able to use that.
Once that was out of the way, it was all just a matter of following the on-screen instructions and waiting. And waiting. It takes a while.

Running Xcode 15 on it

It runs. It compiles. It fails to attach the debugger to the app (the LLDB RPC server crashes). But the compiled app continues running. So, debugging and coding directly on the Mac is impossible.

In hindsight, I think I may have overshot with macOS 13 Ventura and perhaps should have installed macOS 12 Monterey instead with Xcode 14, but I did what I did. It’s done. I’m not doing it over. You can’t make me.

In my case, it’s just as well. All I wanted to do was to test ScreenFloat 2’s iCloud sync with another Mac. And as far as that’s concerned, it’s working perfectly.
It would have been the icing on the cake to be able to debug directly on that Mac, and commit changes back and forth, but what can you do…
I debug on my main Mac, and then commit-and-pull the new code over on the old Mac, and then re-build. It’s tedious, but I can’t really complain. Well, I can. And I am. But I shouldn’t.

Other Observations

I’m making use of the Vision framework in ScreenFloat, and that completely crashes the app on the old Mac. Apparently, there is a reason why macOS Ventura is not supported on these old Macs.

I don’t think you could use this as a machine for work, as I’d imagine you’d run into a lot of little, annoying, and big, terrifying issues. For instance, I imagine Preview would crash a lot, since it also uses the Vision framework for its OCR and whatnot.

For testing apps in development, however, it might work, depending on what it is you’re testing/developing. I had to jump through some hoops (disabling my Vision framework code) to get my app to run. Your mileage may vary.

As a no-cost alternative to a refurbished Mac Mini at ~€600, I couldn’t be more happy.
Here’s to my old, loyal MacBook Pro Mid-2012. It still has some life in it.

Unpacking the MacBook Pro Mid-2012 in… mid-2012.
Read more
Why is Xcode’s popup-documentation tied to the compiler? Kind of defeats its purpose at times.