April 2018
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
Helium Foot Software develops MercuryMover: Don't let the mouse slow you down! Move and resize windows on your Mac with the keyboard.
Recent Entries
GroceryList and Beyond(04/18 11:26)
Go, Go, GroceryList(01/28 22:53)
Indie+Relief(01/19 23:13)
One Fifth of a Five Fingered Discount(11/06 11:18)
On the Job, On the Train(10/30 13:09)
Hey Mac(10/21 11:38)
Dog Fed(10/15 10:53)
20 Questions(10/08 10:59)
A Gallon of Milk and an Onion(10/06 12:34)
The iPhone Doesn't Need Me(09/24 12:46)
Recent Comments
Recent Trackbacks
There are no trackbacks.
Helium Foot (28 items)
Software (5 items)
MercuryMover (37 items)
Blog (3 items)
MacSanta (3 items)
Marketing (12 items)
Philanthropy (2 items)
Podcasts (3 items)
Highbrow (3 items)
iPhone (1 items)
GroceryList (4 items)

Syndicate this site (XML)

RSS/RDF 0.91

Entries : Category [ MercuryMover ]

02 January

In the background

MyWi runs in the background as a faceless application (referred to by Apple's documentation, and heretofore as an "agent application") and brings up a minimal user interface when a hot key is typed. In order to have a good user experience, the UI absolutely has to come forward immediately. When using development builds of MyWi myself I was often having to wait for the window to appear, especially when all of my physical memory was in use. During the day, I'm a java developer for a small software company. In addition to eclipse, safari, mail, itunes, ical etc, I also have four additional java virtual machines running our application(s). Let's just say that this does not leave a lot of memory lying around to keep my agent out of the swap file. I was hoping that there was some way to keep my agent resident in physical memory, and lo and behold, there is. Daniel Waylonis pointed out the following thread to me from the core audio list in which the task_wire mach call is described. It was very easy to implement like so:

        #import <mach/vm_map.h>
        //stay resident in memory
        vm_map_t me = mach_task_self();
        kern_return_t code = task_wire(me, true);
        if (code == KERN_INVALID_HOST) {
                NSLog(@"vm_wire returned KERN_INVALID_HOST.\n");
        } else if (code) {
                NSLog(@"task_wire error code = %d.\n", code);
        } else {
                NSLog(@"task_wire(..., true) succeeded.\n");

Now the UI usually comes up immediately. The first time I hit the hot key in the morning, it still takes a while to present the UI and I'll have to do some additional analysis to figure out why.

Posted by kalperin at 21:18
05 August

Sneak Peek

MyWi Revealed, Sort of

Check out our homepage for the first ever screenshot of MyWi. The beta is ever so slowly coming to fruition (though my birthday is [like my youth] long past. Look for another exciting post next week. It won't be a beta announcement, but it will be something that every kid-in-a-candy-store will appreciate.

Posted by kalperin at 23:12
19 September

Stay on Target

Where Keith is almost there

By the time we had put the kids to bed and I getting-things-did all of the things that i needed to done get it was about 9:30pm. There were six items on my MyWi beta to do list. Now there is just one: write a help file. I'm booked up for the rest of the week, but Sunday has a few hours free. Could this long elusive goal be close? Watch this space to find out.

(Of course, this to do list just gets me to a beta build. At that point, i still need to rustle up some beta testers and manage a beta program. One thing at a time, please.)

Posted by kalperin at 00:09
24 September

Introducing: MyWi

Where Keith finally spills the beans on what MyWi is

We're in Beta! Everyone reading this blog (ie me) can now give himself a high-five. I spun a beta build and posted it to the site tonight. Shortly thereafter, I sent an email to the first group of beta testers. Admittedly, this group only has two people in it and both of them are close relatives, but we're in beta nonetheless.

So what is it? MyWi is a program that lets you move and resize your windows from the keyboard. It's simple and straightforward, but to the power users among you who like to keep your fingers on the keyboard and your mouse at bay, this program is the missing link in your anti-mouse campaign. Stay tuned, i'll be posting more about MyWi in the near future.

Posted by kalperin at 00:23
09 October

What's not in a Name

Where Keith gets cold (yet light) feet about the name "MyWi"

MyWi (our keyboard controlled window mover and resizer) has been in beta for about two weeks now, and there has been a lot of valid criticism of the name. It's supposed to stand for "My Windows" and i thought that it sounded cute. If anything, it sounds like an accessory for a Nintendo Wii (to some, it didn't even sound like anything.) So let's throw open the gates to the 30(!) people that are reading (or at least have read) this blog. Here are some names that are in the running. Does anyone out there in bloggy land have any opinions?

  • Quick Size
  • Prime Mover
  • Nudge
  • Quick Mover
  • WinKey
  • Window Painless
  • Light Window
  • Fleet Window
  • Glazier (props to Daniel Jalkut)
  • Glaze (sound familiar?)
  • Mercury Window
  • something else???

I haven't yet vetted these names for availability. C'mon, it's almost midnight 8-) .

Posted by kalperin at 00:55 | Comments (0)
10 October

Mode Mojo

Where Keith describes how MyWi ended up with three modes

MyWi, the coolest window moving and resizing program known to me, has three modes of operation: Move, Resize along the right and bottom edges and Resize along the top and right edges. Early builds actually had separate grow and shrink modes. When using these builds, i frequently found myself struggling to get the window size that i wanted and wasn't able to formulate why that was so. Then i read this article about item selection by John Gruber. While the piece is about selecting items from a list, or selecting text, it perfectly articulated my problem. When growing a window to the right, if i overshot my mark, i would instinctively use the left arrow key to correct my mistake. Since i was in grow mode, this would of course grow my window to the left, rather than undo my previous overgrowth. By using an anchored model (where one corner of the window stays in place) MyWi started to behave more predictably. Stated more accurately: it was much more difficult for me to misuse MyWi. As a bonus my lengthy usability study (sample size of 1) suggests that resizing windows along the right and bottom edges of a window is by far the most common resize operation. This is supported by the fact that Mac OS windows have always (unto this very day) had their resize widget only on the bottom right corner. While i've been very happy with the separate resize modes, i can't say that i'm thrilled with the three hot-key approach. During the v1.1 cycle i'll be experimenting with other mechanisms to select the mode. For now, let's just try to this thing out the door: 51 days until launch day.

Posted by kalperin at 11:53 | Comments (0)
12 October

Naming Collision

Where Keith removes the most popular choice from the list of possible names

In a previous episode i listed some possible new names for MyWi (the soon to be released program for moving and resizing your windows via the keyboard). Unfortunately, the most popular one (voted for by all three commenters) is already taken. Nudge is a utility by Rainer Brockerhoff which tells the Finder "to update the information it displays about a file or folder". The search is still on; here's the current list which is sorta kinda maybe in order of what i like best:

  • Prime Mover
  • Glazier
  • Mercury Window
  • Fleet Window
  • Light Window
  • Window Painless
  • Glaze
  • something else???

Posted by kalperin at 17:41 | Comments (0)
16 October

And the Winner is...

Where Keith learns to stop worrying and finally pick a name for his app

MercuryMover! For the uninitiated, MercuryMover is a program that lets you move and resize your windows from the keyboard. Until now, MercuryMover was called MyWi. While i never disliked the name, i wasn't really sold on it either. The number of people in the beta group who said that they thought it sounded like something to do with the Nintendo Wii really tipped the scales in favor of making a change.

So how did we end up with MercuryMover? After soliciting ideas from wives, friends, family and loyal blog reader i was left with three favorites:

  • PrimeMover
  • Glazier
  • MercuryMover

pretty much in that order. As a recovering philosophy geek, i really liked PrimeMover . The whimsicalness and symbolism of Glazier appealed to my Mac sensibilities. MercuryMover was a dark horse, but had the advantage that Mercury had an elemental sort of parallel with Helium (and truth be told, i'm even more of a recovering molecular biologist that i am recovering philosopher). So how did the dark horse brighten? Two reasons:

  1. mercurymover.com was available
  2. The dearth of other mercurymovers on google.

If you're a beta tester (or want to be one) there's a new build out with the new name at http://www.heliumfoot.com/mercurymover/beta . Thanks to everyone who weighed in on possible names!

46 days until launch day.

Posted by kalperin at 01:45 | Comments (0)
25 October

Inch by Inch

Where Keith inexorably closes in on the first release

My apologies to all of my loyal reader for the radio silence. I've been busy with the many and varied tasks required to start a company. With the launch date for MercuryMover (Don't you wish you could move and resize your windows from the keyboard like MecuryMover users can?) fast approaching i had a company to officialy form, a marketing plan to get rolling, a build and deploy process to automate, a site to populate with content, a web store to put up and Guilder to frame for it; i've been swamped! In addition to mailing in my Articles of Incorporation to the IL Secretary of State earlier today, here is what i had on my list for tonight:

  • email my contact at PRMac
  • email my intellectual property attorney (an old family friend)
  • get quickbooks (as directed by my accountant)
  • get a paypal account
  • sign up for google checkout
  • sign up for E-Junkie
  • sign up for FogBugz
  • Blog something. Anything!

I'm happy to report that all of these items are now done. I did want to write something about hiring an accountant and incorporating, but i also wanted to go to sleep tonight. Here's the cliff notes:

  • Accountant good
  • S-Corp cheaper up front than LLC
  • DIY S-Corp kit worth the price, despite copy/paste errors that the author wouldn't respond to.

40 days until launch.

Posted by kalperin at 00:36 | Comments (0)
02 November

Da Ploy

Where keith is feeling smug about his kickin' automated build and deploy process

It's a well known fact that we software developers are a lazy bunch. Part of what we like to do is eliminate future work for ourselves. A less well known fact, is that developers think that they're pretty smart. For the last few days i've been letting my lazy and smart streaks work together to automate my MercuryMover (The very soon to be released program that lets you move and resize windows on your Mac via the keyboard) build such that with one click i can:

  • build a specific distribution
  • build a specific version
  • create an installer package
  • zip the package
  • push it to my website
  • update the download link
  • update the appcast

Not only will this save me a lot of (very valuable) time as i frequently spin new builds in the run up to launch, but more importantly i'm certain that this procedure is going to save my posterior many times in the future. The build is designed to be fool proof (perfect for a developer like me) and prevent me from making dumb yet costly mistakes as i scramble to get a fix out.

I thought that i'd briefly describe each step and give the how and why in order to help out some other lazy people like me.

Build a Specific Distribution

I have two distributions: Pre-Release and Release. There is a corresponding xcode build configuration for each. Pre-Release builds expire 60 days after they are built (see this post from Daniel Jalkut for some background). To make that work, i have a build setting called EXPIREAFTERDAYS which is 60 in the Pre-Release configuration and 0 everywhere else. Whenever MercuryMover is invoked, it'll execute the following:

        NSString* nowString =
        [NSString stringWithUTF8String:__DATE__];
        NSCalendarDate* nowDate =
                [NSCalendarDate dateWithNaturalLanguageString:nowString];
        NSCalendarDate* expireDate =
                [nowDate addTimeInterval:(60*60*24* EXPIREAFTERDAYS)];

        if ([expireDate earlierDate:[NSDate date]] == expireDate)
                isExpired = YES;

Now when i first tried this, it failed and there are a few (3 by my count) builds of MyWi (MercuryMover's gestational name) out there that will never expire. Any enterprising developers out there know why? That EXPIREAFTERDAYS is just a build setting. As such it doesn't mean anything to the class where i implemented the check. To hook that up, you need to edit the value "Preprocessor Macros" for all configurations to say this:


As you can imagine, this is like adding a #define EXPIREAFTERDAYS to my classes. Without this kind of automation, i wouldn't try to have self expiring builds. There would be too great a chance that one would get deployed to my site, and there would N ticking time bombs out on the internets where N is the number of people that have purchased a license and are running an expiring build.

Build a Specific Version

I wanted my build and deploy script to take the version as a parameter so that i could simplify keeping the version in sync everywhere and also to enforce my self imposed source control policies. Before i developed this build, i just had an xcode target that would push a build to my site. More than once i would push the build (complete with version number) without bothering to tag the sources. That's all well and good while you're in beta, but after launch, i'll need to be able to determine the precise version in order to provide support.

This was trickier than i thought, but only due to path issues. The script is simple:


#first export the tagged project from svn
rm -rf /tmp/MercuryMover
mkdir /tmp/MercuryMover
cd /tmp/MercuryMover
svn export file:///usr/local/svnroot/repos/MercuryMover/tags/$1/src/MercuryMover

cd MercuryMover
xcodebuild clean
xcodebuild -target Deploy.Production -configuration Pre-Release APPLICATION_VERSION=$1 SRCROOT=`pwd` SOURCE_ROOT=`pwd`
echo "done"

the trickier stuff happens in a script that is run by the Deploy.Production target. Eagle eyed readers will notice that the configuration is hard coded. This was on purpose to make it really difficult to screw up.


This might be a controversial decision amongst the members of the Mac developer community, but i really can't do a drag and drop install. MercuryMover ships as a PreferencePane. Inside that PreferencePane is a program called MercuryMoverAgent.app . This agent is what listens for the hotkeys and does the window moving and resizing magic. If you currently have MercuryMover enabled, you can't even drag a new MercuryMover.prefPane to your PreferencePanes folder because MercuryMoverAgent is running. You can double click on your new version of MercuryMover.prefPane that you downloaded to your desktop and System Preferences will dutifully upgrade your existing install; however, it will not restart MercuryMoverAgent.app . Thus, in order to see the changes in the new version, you would have to manually disable and re-enable MercuryMover (which stops and restarts MercuryMoverAgent.app).

Enter Installer.app . With a pretty vanilla .pkg file i can use a preflight script to kill MercuryMoverAgent and a postflight script to start it again. Using PackageMaker, i was able to specify what goes into my .pkg via the gui which yeilds a .pmproj file. I can then use the command line packagemaker as part of my Deploy.Production run script phase:

/Developer/Tools/packagemaker -build -proj ${PACKAGEMAKER_PROJECT_FILE_PATH} -p ${PACKAGE_DESTINATION}

The only thing i couldn't figure out how to do with the command line packagemaker was set the .pkg's version number. This is an important value as Installer.app keeps receipts of the packages that you install and uses that version number to determine how to handle your .pkg. I ended up punting and getting my pyth on to update the Info.plist file inside MercuryMover.pkg/Contents/ . In a future rev, i may try to engineer a drag and drop install. When i go Leopard only, i can use FSEvent to determine when the PreferencePane changes, but for now this will have to suffice.


I went with a zip file instead of a disk image for two reasons. One, the consensus of the MacSB yahoo group seems to be that zip files are simpler for users. Two, the consensus of me is that zip files are simpler for the industrious developer. I can zip the installer with one line:

ditto -ck --sequesterRsrc --keepParent ${PACKAGE_DESTINATION} ${ZIPPED_PATH}

Push to Website

The benefit of this is obvious. Especially since it's kind of a slow step to push the bits over the wire. I made a hierarchy on my site with release and pre-release directories under /files . This is another check against accidentally deploying the wrong file. I just use vanilla scp to push the file.

Update Download Link

The zipped .pkg file has the version name embedded in it (ie MercuryMover_0.9.4.zip) in order to groove with Sparkle . However, i don't really want to update my site every time i spin a build, so i cheat with a symlink. Once the build has been pushed, i just do a:

ssh -l username heliumfoot.com "rm -f ${SYMBOLIC_LINK_NAME}"
ssh -l username heliumfoot.com "ln -s ${DESTINATION_DIRECTORY}${ZIPPED_NAME} ${SYMBOLIC_LINK_NAME}"

easy. perfect.

Update appcast.xml

Another no brainer. When i was doing these by hand, i grew to hate the appcast file. And it's so short! I got my pyth on for this one too. My script is quick and dirty but it works. I'm aided by the fact that i don't really have automatic updates, but rather automatic update checking (powered by Sparkle). The MercuryMover UI didn't really groove with the Sparkle info panels, so i rolled my own solution which uses Sparkle to check for updates, and I show my own UI. Without the Sparkle windows, i didn't need release notes which really simplified the appcast processing. I'm sure i'll put them in later when i get a better update system going, but this will be fine for now.

Apparently, i had a lot to say about my build. My wife often calls me the smug chef whenever i'm particularly happy with some dish i made. Anyone care to call me the smug deployer?

31 days until launch.

Posted by kalperin at 02:08 | Comments (4)
[1]   2   3   4   Next