Category Archives: Developer
how to change all Desktop backgrounds
With Lion came the welcome ability to have individual background wallpapers for each Desktop. However, what Apple forgot to add was an option to easily make all the Desktops have the same background image when you want it that way.
There are a few workarounds, but probably the simplest – once it is setup – is to use this little script I wrote for some ASC members. It should take you about 5 to 10 minutes to set this up if you follow the procedure carefully.
1. Open TextEdit, and choose TextEdit > Preferences.
Change the settings from ‘Rich Text’ to ‘Plain text’ for New Documents. Close the Preference pane and chose File > New.
2. Copy everything in the box below and paste it into the TextEdit file you just opened:
#! /bin/bash
#script to change all desktop backgroundsecho -n “Drag and drop an image file here then press ‘return’ or
press ‘control-c’ to cancel…”
read -e WLPR;function change_wallpaper
{
defaults write com.apple.desktop Background “{default = {ImageFilePath=’$WLPR’; };}”; killall Dock
}
change_wallpaper
3. Save the file to
/Library/Desktop Pictures
with the name ‘ChangeAllDesktops’.
IMPORTANT: Make sure you remove the ‘.txt’ file extension in the name field AND uncheck the option at the bottom of the Save box that says ‘If no extension is provided, use .txt’.
Note that you will need to press the ‘authenticate’ button when prompted in order to save anything into the ‘Desktop Pictures’ folder. Type your password in the dialogue that pops up.
4. Open Terminal.app.
Make the ‘ChangesAllDesktops’ file executable by copy/pasting this into the Terminal window:
sudo chmod a+x /Library/Desktop\ Pictures/ChangeAllDesktops
Press ‘return’ and type in your password. The password won’t echo to the screen, so type carefully.
5. Make Terminal the default app for the file
Open a Finder window. Click on your hard disk icon in the sidebar (if you can’t see it, go to Finder > Preferences > Sidebar and check Hard disks under the ‘Devices’ section). Navigate to the Library/Desktop Pictures folder and right-click on the ‘ChangeAllDesktops’ file.
Select Open with and then Other…. In the window, navigate to Terminal.app in /Applications/Utilities. It will be greyed out, so change “Recommended Applications” to “All Applications” in the menu at the bottom of the window. Do not check “Always Open With”. Choose ‘Terminal.app’ and ‘OK’.
6. Make a shortcut for Desktop Pictures
Drag the folder ‘Desktop Pictures’ to the Finder sidebar to make a convenient shortcut. Now when you want to change all Desktop backgrounds at the same time, click in ‘Desktop Pictures’ in the Finder sidebar, run the ‘ChangeAllDesktops’ file, and drag an image from the (already) open Finder window into the Terminal window that appears.
Press ‘return’ and your desktops are all changed! 
Related Posts
learning the Terminal — Part One
learning the Terminal — Part Two
learning the Terminal – Part Two
In the last post, we learned how to see all the contents of a folder – invisible and visible files – in the Terminal. However, most of us prefer working in the GUI, so this post is going to show you how to work a bit of Terminal magic to easily turn on and off your invisible files and folders in Finder and the desktop.
Open Terminal, and type or copy/paste the following to the command prompt:
defaults write com.apple.finder AppleShowAllFiles TRUE; killall Finder
(note that all commands in these posts should always be assumed to be case-sensitive).
Press Return.
Now switch out of Terminal and have a look at Finder or your desktop. You should see some ‘hidden’ files now in a sort of greyed-out 50% opacity (files like .DS_Store). If you can’t see such files, go back and check that you typed or copied the entire command correctly.
Assuming you can now see your invisible files in Finder, switch back to Terminal. Press the up arrow key on your keyboard. Notice that the last command you typed reappears.
That’s a handy trick to remember. You can move between your previous commands with the up arrow and down arrow keys to save time re-typing or modifying commands.
In this case, we want to use the last command again, but we also want to modify it. Use the left arrow key to move the cursor back to “True” and then use delete to remove “True”. Leave the cursor where the letter ‘T” was and type FALSE. Make sure the semi-colon ; is still there.
Press Return — you don’t need to move the cursor to the end of the line as you would with a word processor. You can hit Return no matter where the cursor is in the command line and it will execute (or try to) whatever is typed on the whole of the command line.
Now, if you switch back to Finder or the desktop, you should see that all your hidden files have disappeared again.
OK, now that we have tested these commands to check that they work, let’s do something a bit more useful with them.
Switch back to Terminal. Type
^FALSE^TRUE
and press Return.
Wow! Did you see what just happened? You substituted the word “FALSE” from the last command with the word “TRUE” and executed the entire command. In other words, you just made your hidden files visible again! Go and look at the desktop and you’ll see that your invisible files just returned. Try it again. Switch back to Finder and type
^TRUE^FALSE
to replace the word “TRUE” in the last command with the word “FALSE”. Hit Return to execute it.
Using the pattern ^error^correction is a great way to both correct commands you type incorrectly and to run two commands one after the other that have only one term or option different.
Back in Terminal, hit the up arrow to bring the last command back onto the command line. This time, I want you to hit control-A on your keyboard. Notice that this brings the cursor to the start of the command line, which is what we want as we’re going to type in a new command before the “defaults…” part.
With the cursor at the beginning of the line, type
echo
and a space. Then type a double quotation mark right next to the ‘d’ of ‘defaults, so the beginning part looks like this
echo “defaults…
(the ellipsis or ‘…’ is used here just to show that the command continues and should not be in your actual command line)
On the keyboard, press control-E.
This takes the cursor to the end of the command line (remember: control-A to go to the start, control-E to go to the end).
Type another double-quotation mark right after the word ‘Finder’ so the ending looks like this
… ; killall Finder”
Now hit the spacebar once, and type a double right angle-bracket
>>
Hit the spacebar again and type
.bash_profile
The entire command should look like this:
echo “defaults write com.apple.finder AppleShowAllFiles FALSE; killall Finder” >> .bash_profile
Now press Return. Type
^FALSE^TRUE
and press Return one more time.
What did we just do?
To see what you did, type
emacs .bash_profile
As you can see, after testing those two commands on the command line, we’ve now sent them to the .bash_profile file, saving us the job of typing them out again (and possibly making an error when we do so). However, we can’t leave the commands like that – if we do, then they will run every time we log into the Terminal. Rather, we want to use these commands to define functions, just like we did last time with ‘show’ and ‘up’.
To do that, press control-L on the keyboard, then use the down arrow key to bring the cursor to the beginning of the first line with a ‘defaults’ command on it.
Press Return. Press the up arrow once, then type
function hide_all
Press Return and in the new line created type
{
Use the down arrow key to move the cursor down to the line below the “Defaults…FALSE” line and press Return.
In the new line created type
}
Then press Return. Type
function show_all
Press Return and type
{
Use the down arrow key to move the cursor below the “Defaults…TRUE” command. (If you can’t go below the last typed line, then on the keyboard press control-E to move the cursor to the end of the line, the press Return).
Then type
}
Check that the whole thing looks like this:
Once you’re satisfied, hold down the control key while pressing first the x and then c keys. Press y when prompted to confirm the save. You should be returned to the command line. Type
exit
to logout. Then press command-W and command-N to close and reopen Terminal.
What did we do this time?
We just made some new, easy-to-remember commands to show and hide our hidden files in Finder and the desktop. On the way, we learned how to append commands to files using the >> function, as well as how to move the cursor to the beginning and end of a line using ‘control-A’ and ‘control-E’ respectively. We also learned how to recall previous commands on the command line using the arrow keys and how to correct or modify previous commands using the ^error^correction pattern.
Wow, you’ve come a long way in two short tutorials!
To test out what you just did, type
show_all
then press Return.
Switch to Finder and there’s all your hidden files! To make them invisible again, switch back to Terminal and type
hide_all
then Return.
From now on, whenever you want to see your hidden files, just use the show_all command in Terminal. Hide them again with hide_all. 
SUMMARY
control-A – places the cursor at the beginning of the command line (also works in emacs editor)
control-E – places the cursor at the end of the command line (also works in emacs editor)
control-L – on the command line, this clears the screen (equivalent to the ‘clear’ command); in emacs, this places the caret inside the editor allowing you to edit (=insert point)
up & down keyboard arrows – moves through history of commands
^error^correction – replaces the term after the first ^ with the term given after the second ^ in the previous command, then executes the entire command
echo – sends the following string or command to the specified file (if no file is specified, the string will output back to your terminal screen. In other words, if you type echo hello, the Terminal will print “Hello” on the next line; hence the term ‘echo’! )
Related Posts:
learning the Terminal – Part One
how to change all Desktop backgrounds
Fasttasks – a utility for ten common terminal tasks
how to become an Apple app developer
Developing apps for iPhone, iPod, iPad, and Mac OS seems like the California gold-rush of the 21st century — the press are full of reports of the riches to be had in this amazing land, stories of “little people” making “big bucks”. Anyone can be an app developer, they say, but what’s the truth behind the hype, and how do you actually learn how to do it?
Last I heard, there were currently something like 600,000 apps on the Apple App store (for iPhone/iPad) and some 100,000 or so on the App store for Mac OS. Apple have paid out (i.e., passed on customer payments after taking their 30% cut) literally billions of dollars to developers. That’s a lot of cash! The question is, can you get a slice of it too?
In theory, there’s no reason why not. As I’ll detail below, the route to becoming an app developer is not particularly hard, nor is it particularly costly. But that doesn’t guarantee success. Anyone can write a book, but writing a killer book that’ll sell like Harry Potter is not so easy, and writing a killer app that will sell like Angry Birds is every bit as difficult.
The analogy holds for success in both cases: you need a great idea, you need to execute it well, and you need to market it properly. Did I mention those 600,000 apps on the App store? How, exactly, are you going to make your fortune if your app is buried in a pile like that? Well, I’ll save ideas and marketing for a future post. In this one, I want to focus on the things that we know we can achieve and only have to depend on ourselves for: developing the skills needed to turn that great idea into an actual piece of software that will run on Apple machines.
Learn the language
If you want to write a killer novel, the first thing you have to do is learn the language that you want to write the novel in, be it French, Chinese, or English. If you want to write a killer app, the same goes. Visual Basic? Visual C++? Java? Yes, that kind of thing except…if you’re developing for iOS (the iPhone/iPad operating system) or Mac OS (Mac computer operating system) you have to learn the Apple language, not any of those common ones associated with lesser machines!
So what is the Apple language? It’s called ‘Objective-C’, and it runs in a programming environment called ‘Cocoa’. You’ll need to learn ‘Cocoa’, but in order to learn that you’ll need to learn ‘Objective-C’, and to learn that, you’ll need to learn the basics of the standard (Ansi) C programming language. Oh my!
And once you’ve got a hold on all that, you’ll then need to learn Xcode, which isn’t a language or a programming environment at all, but a very sophisticated development tool (in fact, Xcode is itself an app!), in which you do all your Apple programming. You’re probably now thinking that it’d be easier to write that next Harry Potter novel and are already hunting around for the back of an envelope to start scratching down your ideas, but wait…
I know it sounds disheartening, but there is some good news. After all, it can’t be that hard if so many other people are doing it, right? (Well, actually, yeah it can, there’s a lot of dedicated programming geeks out there!). But look, I’ve been down this road too, and while I haven’t produced any killer apps (still waiting for that great idea…), I have gone from knowing next to nothing about programming to being able to put together an application that does what I tell it to and doesn’t crash my system.
(OK, not entirely true that I didn’t know anything about programming: in the 1980s, I once learned how to get a monochrome computer screen to print “Hello World” in BBC BASIC, which basically involved nothing other than typing >Print “Hello World”; it seemed so ridiculously pointless in 1982 that it turned me off programming for the next thirty years! Other than that, I’m a newbie ).
And the good news gets better: most all of the documentation you need to learn how to be an app developer is available free from Apple. Truly, and I mean this with no trace of irony, it is hugely generous of Apple to put the amount of free material they have online for anyone to use. Want to be a Windows developer? Find your local bookstore and start shelling out one heck of a lot of $$$!! The cynical, of course, will say that Apple only do the giveaway to benefit themselves; others might say that giving away free training justifies their 30% cut.
I think of it as a symbiotic relationship: would-be developers who aren’t in computer science departments or big companies could never afford to buy all the material. Likewise, Apple could never have built an App store with such a huge number and wide variety of programs to Wow! their users if they had only had universities and commercial software developers to rely on. This way, both the little people, that’s me (and — I’m assuming — you), and Apple get to win.
I’ll tell you how to get started in a minute, but before I do let me point out that the ride is not entirely free. There’s probably a point at the beginning and certainly one at the end where you will need to lay out some of your hard-earned. So let’s deal with that now.
What you need
Right off, you’re going to need a Mac computer. Sorry, if you don’t already have one, you’re going to have to buy one; a low-range Macbook Air or Mac Mini will do, anything that can run OS X Lion. You can’t develop Mac apps on your iPhone or iPad, I’m afraid (but it does work the other way too: you don’t need an iPad or iPhone to develop apps for these devices. More on this below).
And what about if you have a good-spec PC? Yes, you could get a Mac emulator (VMmare) or mess around with OSx86, but frankly, these options are likely to cause you more grief than they’re worth; you could end up with apps that don’t build properly, and/or which breach Apple’s licensing conditions.
I’m not saying don’t do it, that’s your choice; I am saying your chances of successfully building an app, making it stable, and getting it accepted into the App store by Apple are significantly reduced if you go that route. Given the price of a basic Mac Mini on Ebay, you could well end up spending more money (as well as time) trying to avoid buying a Mac than just buying a cheap one.
The other expense you might need to lay out for is a basic ‘Intro to C’ book. There’s plenty of web offerings, but really a good ‘idiots’ book like the Dummies or Absolute Beginners should be enough and has the benefit of being reasonably likely to get you to the level of proficiency you need in the shortest amount of time. After that, you learn the rest for free (Objective-C, Cocoa, Xcode) from Apple. At the end of the process, when your app is built and you want to submit your app to the App store, you’ll have to register with Apple for a licence as an app developer and vendor; current cost $99.
Take the first step
“Sign me up”, you say, “where do I start?” The first thing to do is to sign up to Apple’s developer community: this is free (don’t confuse it with the Developer Program or Licensing, which costs $99 and which you don’t need till you’ve built an app you want to upload to the App store).
Once you’re in the Developer Community, download Xcode 4, Apple’s development environment (a different thing from a programming environment, but don’t worry, you’ll get the hang of all this terminology easily enough once you start reading the docs). This is a 4GB monster of a program – bigger than your average operating system, so make sure you have the space – and it is also free. Xcode comes with free iPhone and iPad simulators and in itself, this is a piece of software that’s probably worth a couple of thousand dollars. So smile: you’re already making a profit even though you bought that Mac Mini! This is also the reason why you don’t need, and in fact can’t use, your own iPad or iPhone to test your apps: everything has to be done in Xcode, and this monster app only runs on Mac OS X.
Once you’ve downloaded Xcode, you can play around with it if you want, but unless you’ve worked with an IDE (integrated development environment) before, it’s pretty complicated, so it’s best to wait till you work through the tutorials. It’s not the kind of software you can learn through serendipitous exploration.
Instead, go to the documentation resources and start with the tutorial Your First Mac Application.
By the time you get through this, you’re going to realise why you need to learn Ansi C, Objective-C and Cocoa. So put Xcode away for now, and start on the path of learning to speak Apple’s language. When you get there, just add 1 great idea + 1 great marketing strategy, and you’re on your way to California!
The short guide:
1. Get a Mac
2. Learn C, learn Objective-C, learn Cocoa, learn Xcode
3. Come up with an idea for a great app and plan it out carefully
4. Build and test your app
5. Pay the licensing fee and submit your app to Apple
6. Once it’s been through the review process and accepted, implement your marketing strategy
7. Watch the millions role in and retire.
