Headaches of Switching to Mac OS X for Development
When you’ve been working primarily in one environment for nearly two decades, switching to a new one is never painless.
This is the fifth of several articles about my journey developing an application for NASA’s Fermi Gamma-ray Space Telescope mission. Earlier articles can be found here:
Let me say right from the beginning that I have nothing against OS X. In fact, there are many nice things about the operating system and it definitely looks nice. It’s just that I’ve been using some form of Linux (mostly RedHat and it’s derivatives) since 1997 and was using VAX and Solaris before that. That was for school and work. At home I run Linux and Windows. I’ve never owned a Macintosh computer although I’ve occasionally used one here and there through the years.
I knew when I started developing the mobile app, I would eventually find myself on a Mac for development work because of Apple’s restriction that iOS apps can only developed on OS X. And I knew there were going to be adjustments to be made. Here are the ones I ran into that caused me the most grief.
Focus follows mouse
The first was the lack of “focus follows mouse” behavior on OS X. I’ve spent the last 15 years with my windows set up so that when I move the mouse, the window it is over has focus and I can immediately start typing. Many times I’ll have multiple terminal windows open (sometimes with just a line or two showing) and slide the mouse from window to window and launch programs.
No longer having that as an option definitely caused me several false starts and a bunch of retyping. It wasn’t so much of an issue for the mobile development and that was mostly being done in a single IDE plus the emulators, but for my other Mac project, which involved a lot of building and compiling and running tools in the terminal windows, it was definitely causing a hassle.
I can understand completely why OS X doesn’t have this as an option. The windowing system design with the menu bar always at the top of the screen and not attached to the individual windows definitely makes the idea of focus follows mouse undesirable. It’s just something I’m used to that I miss on the Mac.
Command vs Control Key and Muscle Memory
I think of all the adjustments this one has caused me the most grief. My hands have been trained, over the past two decades, to know exactly where the Control Key is located for all my keyboard shortcuts and the spacing between that key and the other keys in the command. All of those same short cuts, on a Mac, use the command key which is one key over and which I still continue to miss for the first hour or two working on the Mac unless I make a conscious effort. Eventually, I remember that I’m on a Mac and hit the right key, but in the mean time, since my IDE responds differently to Control-C versus Command-C for example, I’m having to hit a lot of extra key strokes to recover form my mistake.
Middle Mouse Button ≠ Paste
This one I use extensively and it’s absence drives me batty. Instead of doing this:
- highlight selection
- move mouse to target window
- click the middle button
I have to do the following:
- highlight selection
- Command- (not Control-) C to copy
- move to the new window
- click to activate the window (remember, no focus follows mouse)
- Command- (again not Control-) V to paste.
In my Linux windowing environment, this works everywhere, no questions asked. In fact, I can’t think of a single place where I’ve not been able to use it.
On the Mac, it does work (sort of) in the terminal windows. But in the Titanium IDE it doesn’t work at all. Maybe it works in other places but I don’t use much else right now and where I do spend my time, it doesn’t work.
Page 1 of 2 | Next page