Red Sweater Blog Official blog of Red Sweater Software Thu, 05 Mar 2015 19:09:29 +0000 en-US hourly 1 MarsEdit 3.6.8: Retina Image Uploads Thu, 05 Mar 2015 04:57:59 +0000 MarsEdit 3.6.8 is available now from the MarsEdit home page, and has been submitted to the Mac App Store for review by Apple.

This update includes a large number of bug fixes as well as one important change in the way that MarsEdit handles the uploading of images intended to be displayed at a “Retina” compatible resolution.

One of the problems with handling Retina graphics well is that there is a huge variety of solutions in use by different web sites, depending on the priorities for bandwidth, ease of editing, backwards compatibility, etc. My expectation that MarsEdit users would want the app to support this variety has kept me thus far from releasing any solution at all to the problem. In the interim, I have been adopting the workaround myself of uploading images at twice the resolution I wanted them to display at, and hand-editing the HTML to reference them at half-size. So, if I wanted a 400x400pt screenshot on my blog, I’d upload an 800×800 image and hand-edit the HTML to look like:

<img src="..." width="400" height="400" />

As of MarsEdit 3.6.8, a checkbox when uploading or inserting an image to Treat as Retina image will enable behavior like the above, completely automatically.

That is to say, if you want a 400×400 image on your blog to look nice on Retina displays, just supply an image at least 800×800 and check the “Treat as Retina image” checkbox. MarsEdit will produce the expected HTML and upload the image at twice the width and height.

This solution will not meet everybody’s expectations for how Retina images should be handled, but it’s a good step up from what MarsEdit has offered thus far. This solution has the benefits of being both simple and backward-compatible. The main downside is that readers with standard-resolution displays are forced to download a higher resolution image than necessary. As high resolution displays become more and more popular, and bandwidth use becomes a less typically critical issue, I think the adoption of a compromise like this one will be common.

Here is a list of all the specific changes that went into this release:

  • Address issues with images being uploaded for display on Retina screens:
    • Images are now uploaded at 2x specified dimensions when Retina checkbox selected
    • Width and height fields now show size as “points” instead of “pixels”
    • Width and height fields now limited based on size of image and Retina setting
  • Rich and HTML Editor bug fixes
    • Fix a bug where pressing return in a blockquote could cause a new blockquote to be created
    • Fix a bug where smart quotes, etc. were erroneously allowed in plain HTML
    • Fix a bug that prevented images from being pasted into post editor content
  • Other media-related fixes
    • Fix a bug that caused Tumblr images to publish at constrained size even if the size is changed in Media Manager
    • Fix a bug where media style macro was not applied to re-inserted, previously uploaded images
    • Fix a bug where media style macro with prefix and suffix did not wrap the active selection
  • Other bug fixes
    • Fix a bug that prevented post documents from showing unsaved changes after changing custom field contents
    • Fix a bug in “Show Text Statistics” sample script that caused inaccurate word count to be shown
    • Fix a bug in Media Manager that failed to show the entire folder name for folders with periods (.) in their names
    • Default newly added Blogspot blogs to “Apply Preview Filter” before publishing, to ensure paragraph tags are added if needed

Let me know if you have any questions or run into any problems!

]]> 2
Clarion 2.1: Modern Times Mon, 12 Jan 2015 16:20:51 +0000 Clarion 2.1 is available now from the Clarion home page. I also intend to submit this version to the Mac App Store, for what will be Clarion’s debut on the store.

Clarion is Red Sweater’s utility for practicing the recognition of musical intervals (the distances between two pitches). It’s the oldest of my shipping apps, and over the past several years I had lost sight of how far into disrepair it had fallen. Very cool features such as its ability to customize from a variety of built-in synthesizer sounds were no longer functioning. I’ve brought that back in Clarion 2.1:

Screenshot of the Clarion musical instrument chooser.

Additionally, Clarion had not seen any updates since the advent of Apple’s high-resolution “Retina” displays. I’ve updated the graphics in Clarion’s main quiz window to look sharp on these screens:

Screen shot of Clarion's main window.

The playful VU-meter-styled gauge in the middle of the screen reflects your overall accuracy for a given quiz session. Up until now, the “needle” just jumped to its new location whenever you made a guess, but starting with 2.1, the needle animates smoothly to the new location, making a further approximation of its real-world equivalent.

Complete list of changes in 2.1:

  • Screen graphics optimized for Macs with “Retina” displays
  • Slight update to UI incorporates always-on piano keyboard in main window
  • Fix a bug that caused many instrument names to be listed as “Unknown Category”
  • Now recovers gracefully from bad synth settings that could be set in previous versions
  • Fix a bug that prevented changing Apple Synthesizer settings on recent OS X versions
  • Now supports automatic checking for future software updates

If you want to develop your ear for musical intervals, give Clarion a try!

]]> 0
MarsEdit Live Source Preview Tue, 23 Dec 2014 17:20:55 +0000 Recently a customer wrote asking whether I would consider adding a feature to MarsEdit, so that as you’re writing a blog post, you could also keep an eye on exactly what the resulting HTML will look like. This feature would be handy for folks writing in Markdown or in the Rich Text editor, but also for folks writing in plain HTML, depending on what “preview filter” settings they have configured.

I told the customer I could see the value of such a feature, and that I would consider it for a future update. But the idea stuck with me until I suddenly realized that in fact MarsEdit could support such a feature today, without any update to the app.

Currently MarsEdit’s editor supports writing in either plain-text markup such as HTML or Markdown, or in Rich text. In any of these cases, the final result can be previewed in MarsEdit’s preview window, where the results of e.g. running Markdown or converting from rich text to HTML are shown in the context of a “preview template,” essentially a custom HTML document that users can tweak e.g. to match the appearance of their blog.

Preview window with default configuration

Because users can edit the template and add arbitrary HTML to the preview window’s content, it occurred to me that JavaScript could be added to the template such that every change to window’s content would be matched by a live display of the HTML being shown in that very window.

MarsEdit’s default preview template contains a body section that looks like this:

<div style="padding:10px 20px;">

The #body# and #extended# placeholders are replaced with the actual content of the post while you are writing it. For the purposes of this proof-of-concept, I decided to just focus on the body text, since many people don’t use “extended” entries. I added a bit of HTML in the template to hold the source view I plan to add:

<pre style="white-space:pre-wrap">
<div id="sourceContent" style="padding:10px 20px;">

Now the only trick remaining is to pay attention to changes and update the contents of the “sourceContent” div above with my content’s HTML. This required a little inside-knowledge that would have been admittedly challenging to discover on one’s own. The way MarEdit currently handles updates to the preview window content is to load the HTML template once, and then as you type, recompute and replace just the “body” of the HTML document. So I added a new script element outside the scope of the body tag, where it won’t get replaced constantly:

<script type="text/javascript">
	var ignoreUpdates = false;

	function escapeHTML(theHTML) {
		var escapedHTML = theHTML
		escapedHTML.replace("&", "&amp;");
		escapedHTML.replace("<", "&lt;");
		return escapedHTML;

	function updateSource() {
		var bodyDiv = document.getElementById("bodyText");
		var sourceDiv = document.getElementById("sourceContent");
		if (bodyDiv && sourceDiv) {
			var bodyHTML = bodyDiv.innerHTML;
			sourceDiv.innerText = escapeHTML(bodyHTML);

	document.addEventListener("DOMNodeInserted", function(e) {
		if (ignoreUpdates == false) {
			ignoreUpdates = true;
			ignoreUpdates = false;
	}, false);

I’ll leave making sense of that JavaScript as an exercise for the (very) curious reader, but the gist of it is that it listens for changes to the structure of the HTML document, and when it notices that happening, it grabs all the HTML out of the “bodyText” div, converts it to escaped HTML source, and sets that on the new “sourceContent” div that I added to the template.

Here’s what the MarsEdit preview window looks like now, with the live source preview in effect:

Preview window with new source display

While this isn’t as polished as a dedicated feature for previewing source, I found it interesting that I was able to come up with a creative solution using only the powerful and flexible preview infrastructure of the app. If you’re interested to try out the preview, you can download it here. Just copy and paste the text into MarsEdit’s preview template editor.

Let me know if you come are inspired to come up with any creative preview window solutions of your own!

]]> 0
MarsEdit 3.6.7: Jumpy Text Cursor Wed, 12 Nov 2014 14:15:13 +0000 MarsEdit 3.6.7 is available now from the MarsEdit home page, and has been submitted to the Mac App Store for review by Apple.

This release comes hot on the tails of 3.6.6, mainly because of a harmless but nonetheless obnoxious bug that was introduced in that release. While typing in either the HTML source or Rich Text editor, if you manually save a local draft of a post (as many people compulsively do), the insertion point cursor in the post would jump to the end or beginning of the post. Frustrating!

3.6.7 addresses this problem and also includes my workaround for the WebKit bug I described in depth a few days ago.

  • Fix a problem from 3.6.6 where saving a local draft caused the insertion point in the post to jump
  • Work around a bug cause a crash when closing documents with active JavaScript running
  • Fix a bug where a long list of blogs could draw funny when scrolling off the bottom of the source list

Hopefully this update will get you back to saving as compulsively as you like, without any resulting hijinx in the editor!

]]> 1
Burn After Releasing Thu, 06 Nov 2014 23:25:34 +0000 For folks interested in the more technical side of Red Sweater, I’ve written up a fairly long technical analysis of a recent MarsEdit crash report I received and how I ended up fixing it:

“I love it when customers take the time to write something about the circumstances surrounding a crash. Often even a little clue can be enough to lead to the unique series of steps that will ultimately reproduce the problem.”

I used to write more about this kind of stuff right here on the blog, but in general I leave most of this “programmer-level” stuff on the Indie Stack blog these days. Give it a look if you’re interested in reading more stuff like this.

]]> 0
MarsEdit 3.6.6: Performance And Bug Fixes Thu, 06 Nov 2014 16:33:25 +0000 MarsEdit 3.6.6 is available now from the MarsEdit home page, and has been submitted to the Mac App Store for review by Apple.

This release addresses a pair of performance issues affecting some people on OS X Yosemite, in which typing in the post editor or sorting items in the main window can become very slow.

The update also improves overall reliability, including fixes for several nuisances and crashing scenarios:

  • Fix a performance problem that caused slow typing in the post editor for some users
  • Fix a performance problem with sorting large lists of posts in the main window
  • Fix a bug in which image attachments could be removed erroneously when canceling a draft save
  • Fix the functionality of the AppleScript “save” command to save a post as a local draft
  • Fix a bug that prevented sorting posts by the Tags column
  • Fix updating of post editor window contents when left open after publishing
  • Prevent a crash when pasting text with invisible characters
  • Fix a bug that could prevent the main category from being changed by the category popup

Let me know if you notice anything unusual after updating to the latest release!

]]> 0
Black Ink 1.6.2: Fix New York Times Login Thu, 30 Oct 2014 21:49:32 +0000 Black Ink 1.6.2 is now available from the Black Ink home page, and will soon be submitted to the Mac App Store for review by Apple.

Starting with version 1.6.1, Black Ink supports the ability to download premium puzzles from the New York Times, prompting for your username and password as needed.

The main purpose of 1.6.2 is to fix a problem that cropped up due to a change in the New York Times’s web page, making it so Black Ink did not detect the need to authenticate and thus could get stuck unable to download premium puzzles.

This update also makes a minor refinement to the drawing of clue numbers within puzzle squares.

Black Ink 1.6.2

  • Fix an issue that prevented NY Times Premium login request from appearing
  • Fine-tune drawing of clue numbers so they aren’t so close to the left edge of squares

Please let me know if you run into any problems with the update.

]]> 0
Yosemite’s Automation Improvements Wed, 29 Oct 2014 13:59:20 +0000 Ray Robertson of Automated Workflows offers a good rundown of the automation changes Apple provides in OS X Yosemite and their iWork suite of apps. When you look at the mass of changes, including enhancements to AppleScript, Automator, and the addition of an all new JavaScript dialect for application scripting, it reads like a pretty huge update to the state of automation. So much for AppleScript being “dead” to Apple, huh?

One of the interesting new features in AppleScript is support for scripts exposing their own “progress” as they run. This facilitates the system displaying e.g. a busy indicator, or even a progress bar that fills up as the script moves along the steps of its work. Unfortunately the progress feature of AppleScript has not been exposed to 3rd party developers, so far as I can tell. So an app like FastScripts, or any other app that runs scripts on its own, cannot yet take advantage of showing users the fancy progress feedback.

I’m especially impressed and intrigued by the changes Apple has made to iWork to better facilitate scripting. When they launched the major updates to the suite last year, they gutted AppleScript support in the apps. They’ve been gradually adding stuff back, and the latest updates make another big leap. As described by the Automated Workflows post, they’ve gone so far as to provide custom UI in the app for labeling fields with scriptable terms. I look forward to seeing what I can do now with some automated Pages workflows that I’ve been holding back to the previous generation of the app.

]]> 0
FastScripts 2.6.8: Fix Folder Aliases Fri, 24 Oct 2014 15:45:39 +0000 FastScripts 2.6.8 is available now from the FastScripts home page, and will soon be submitted to the Mac App Store for review by Apple.

For years FastScripts has supported the ability to follow Mac OS X aliases, so you can drop an alias to a script, or an alias to a folder of scripts, and it “just works.” For example, some folks found this to be a handy way of keeping a bunch of scripts on Dropbox that would be accessible from whatever computer they use FastScripts from.

At some point along the line, this functionality started breaking in subtle ways that I didn’t track down until now. The long and short of it is Apple has moved away from “alias files” in recent years, and now favors a format they call “bookmarks.” To users, the files behave the same way, and Apple continues to call them “aliases” e.g. in the Finder when it offers to make an alias to a file. However, the older system service for “resolving an alias file” does not work on bookmarks. Thus, existing aliases in your FastScripts tree may have worked, but new aliases created recently would actually be “bookmarks” and thus not work.

The problem was compounded at some point, maybe as recently as OS X Yosemite, when Apple started aggressively converting old alias files into bookmarks. So even if you had an old, functional alias to a folder in your script tree, it may have recently stopped working in FastScripts because Apple converted it … helpfully … to a bookmark.

FastScripts 2.6.8 solves this problem once and for all by using newer system services that resolve both alias files and bookmarks. You should now be able to make an alias to a folder or script, drop it into your Scripts folder, and have it show up as expected.

This update also addresses a cosmetic issue with 2.6.7, where my efforts to update the FastScripts icon for Yosemite’s “dark mode” caused it to appear inadvertently too light when running in standard mode.

FastScripts 2.6.8

  • Fix a bug from 2.6.7 that caused the menu bar icon to draw too lightly in OS X Yosemite
  • Restore proper functionality of aliases to folders within the script hierarchy
  • Fix a typo in the first-launch welcome message

Let me know if you run into any issues!

]]> 4
Yosemite’s Speakable Scripts Fri, 17 Oct 2014 16:15:14 +0000 One of the cool new features in OS X Yosemite is a major expansion of the system’s dictation features. Not only has the dictation become more accurate and reliable (probably by leveraging the work that goes into Siri on iOS), but there are new integration points that facilitate really interesting workflows.

I developed FastScripts many years ago expressly because at the time I found it tedious to have to open a script in Script Editor, and run it. For quick-fix type scripts, it was easier to just do the thing than jump through the hoops of running it!

Over the years, Apple has improved the built-in mechanisms for running scripts, by adding their own standard script menu, and slowly increasing the ways in which scripts can be invoked through various built-in actions. Still, when it comes to organizing and invoking scripts by keyboard shortcut, I am convinced FastScripts is best.

But a nuanced feature of Yosemite’s Dictation feature actually leapfrogs FastScripts in one interesting area: it’s now possible to configure app-specific speaking commands that run arbitrary scripts.

I learned about this feature via Macworld’s Christopher Breen, who writes extensively about the new speech commands and how they can be used to create custom Automator workflows.

At first I griped that the commands could not be configured to run scripts, because that is what any reasonable person would infer from the selection of choices:


Granted, these are all fine choices and you can perform some pretty interesting tasks by configuring a specific spoken phrase to open a file, paste a specific text phrase, or simulate a keyboard shortcut. But why can’t I run a script?

Going out on a limb I chose “Run Workflow…” and navigated in the file chooser to my scripts folder. Lo and behold, you can run a script, you just choose one instead of a workflow and speakable commands will handle it with aplomb.

Whether or not you use FastScripts to accelerate script execution with keyboard shortcuts, I think you might find some uses for speakable scripts. Enjoy!

Update Oct 17, 3:17PM EDT: Well, my excitement may have been a little premature. It seems the scripts are run not as the streamlined items that they are but are instead sort of wrapped in an automator action and run. It’s nice that you don’t have to go out of your way to translate a script into an Automator Workflow, but unfortunately this means that “Speakable Scripts” do put up the little Automator gear icon in the menu bar, and are probably ultimately slowed down at least a bit by being run as a full-on workflow.

Update Oct 19, 5:50PM EDT: Wait a minute, maybe it is running them as native scripts. There’s just a change on OS X Yosemite with how the system runs scripts, such that they always show an Automator-style progress indicator in the menu bar. I find this pretty irksome as a default behavior because for example short-lived scripts don’t need progress to be indicated at all. I’ve also noticed that the system automation progress indicator is liable to pop up at semi-random location in the menu bar, and then leave a gap when it goes away.

]]> 6