Software : Tutorial: How to sync your contacts with OS X Address Book

---

Tutorial: How to sync your contacts with OS X Address Book Posted: 10 Jan 2011 06:20 AM PST Once upon a time, emailing was something you did from your study at home or desk at work. All your contacts' details sat on your Mac for when you needed them. But email has changed – you can now ping off messages from just about anywhere, thanks largely to webmail accounts or your phone. But while there's been plenty said about syncing your email messages between the various systems, your contacts list can get overlooked. And that's where Address Book comes in. It enables you to manage your contacts list on your Mac and sync it to your iPhone or MobileMe account, or your Google contacts. You can even set up CardDAV, Exchange and LDAP accounts. You'll find Address Book in your Applications folder. To add a contact, just open it up and click the + button below the Name column. Fill in the details you'd like to add, and the contact will be instantly accessible from Mail. To use it, just start typing the person's name into the To: field and you'll see a drop-down of possible matches. If you've added multiple email addresses, such as home and work, you'll see them all. If you've got a long list of contacts in a webmail account, for example, let's import these into Address Book. In your webmail service, there should be an option to export contacts – do so in the vCard format. Then switch back into Address Book and go to File > Import…. Pick the vCard file you saved and it'll import all the names and addresses for you. You might find you've got some duplicates – you can merge these by going to Card > Look for Duplicates…. Careful though: you don't get any control over how it merges contacts, so if there are two 'Work' email addresses, one gets overwritten and you can't choose which. If you've got the time, go through them manually. How to organise and sync your contacts list 1. Organise your contacts If you regularly send mail to the same group of people, organise their addresses into groups. Click the + below the Group column and give it a name. Then drag the names to add from the All Contacts view. In Mail, type the group's name, and all the addresses are added. 2. Smart groups Address Book can create groups for you automatically. Smart groups work like Finder's smart folders, in that any contacts that match certain criteria pop up in the group. The more fields you fill in on each address card, the more effective it is. Go to File > New Smart Group… 3. Set conditions Give your group a name. You can set up any number of conditions that a contact must match to appear in the smart group. Use the leftmost drop-down to pick what you'd like to match, and type into the text box on the right. You can add as many fields as you want. 4. Use it! When someone joins your team, fill in their card and they'll appear in the group. See who's in the smart group by clicking it in the Groups pane. To email the group, start typing the group name into the To:, Cc: or Bcc: field. When it auto-completes, click in the main body 5. Sync to iPhone/iPad Chances are you'll want access to your contacts on your iOS device. Fire up iTunes and click your iPhone, iPod or iPad in the left column. On the Info tab, tick the Sync Address Book Contacts box and pick which groups to keep in sync. (You can't sync smart groups.) 6. Sync to Google Contacts Now to sync your contacts with your Google account. In Address Book's preferences, click Accounts, select On My Mac and tick Synchronize with Google. Click Configure, type in your details and click Agree. Now find iSync in your Applications folder and load it up. 7. Bring in iSync Open iSync's preferences and tick Show status in menu bar – you'll see its logo appear in the top-right of your screen. It's now fine to quit iSync – the menu will remain. Selecting Sync Now from this menu matches up your local address list with your Google Contacts. 8. Other account types If you have a CardDAV, LDAP or Exchange 2007 account, you can pull these contacts into Address Book. Open the Accounts tab in Preferences and click the + below the list. In the pop-up, pick your account type from the drop-down and enter your details.

20 things we'd change about installing software in Linux Posted: 10 Jan 2011 02:45 AM PST Software installation in Linux can confuse new users, while it pleases and irritates more experienced campaigners in equal measure. Here are 20 things we'd change about it. 1. Open Source doesn't mean Only Source "It's open source, here's the source" can be a cop out. Most users don't actually want the source (as long as it's open), they want a binary. Developers should be more proactive about making packages of their programs available. They don't have to do it themselves – there are plenty that would help given some encouragement. 2. How to run "I've installed Foo, how do I run it?" Hands up anyone who hasn't seen this on a help forum? All window managers that comply with the Freedesktop.org standards, which includes all the main ones, respect the standard XDG desktop files for menu entries. There's no excuse for installing a graphical program and it not appearing in the menus afterwards. 3. Standardised interface Forget all the arguments about a single package format; it'll never happen. We need a standard package manager interface that'll work with all packages. Imagine Synaptic running on Ubuntu and Fedora, and knowing whether to use RPMs or Debs. 4. Easier adding of repositories Adding repositories usually involves copying and pasting long, arcane text strings from a web browser into a terminal. A standard filetype for a repository addition file would enable the browser to launch the appropriate package manager to add to the repository – after the usual "are you sure/do you trust this" dialog. 5. Easier source building How many programs don't even have specific compilation and installation instructions? Many just have the generic Autotools text. If it's that easy, why not include an install.sh script that does it for the user? Even better, have it check for dependencies properly. 6. Autotools = yuck Please can we move into the 21st century with this? Autotools is slow and cryptic. It was intended for use by developers, and end users should not have to be exposed to this sort of thing if they want to install something not available as a binary. 7. Reduce filesystem splatter Is it really necessary to install files in countless directories? It's not so bad when installing from a package manager, as it knows what to clean up when uninstalling. Source builds, however, can be a nightmare to remove from the system, especially when developers don't provide a make uninstall target. 8. Standard metapackage If we can't agree on a single package format (and we never will; even if we did, someone would come up with a new one), how about a standard package container file? In a similar way to how an AVI file can contain various types of data, a metapackage format could hold RPM, Deb or Slackware TGZ information, or any combination of two or three, allowing the same package to work on multiple distros while still respecting the different systems. 9. Standardise package names Why do different distros give the same package different names? Resolving dependencies for source packages would be a lot easier if there were consistent naming between distros, enabling build scripts to state "you need to install libfoo", or even offer to do it for you. 10. Standardise package splits It's not just package naming that needs some consistency, the way projects are split into sub-packages by each distro is also inconsistent. Strong direction from the upstream developers would go a long way to giving consistency and reducing confusion. 11. Get rid of -dev package hell The -dev or -devel packages containing library headers cause no end of confusion when trying to compile source, such as "libfoo not found" messages when it is clearly there. A switch to automatically install associated -dev packages, turned on when you install GCC or Autotools, would save a lot of grief at the cost of a tiny amount of disk space. 12. Automatic installation of source packages If a different package is needed for each distro, maybe a single source package would cover all the edge cases, but only if package managers had the ability to download, compile and install the source for you. Current source package installation isn't much more than dumping the source code on to your hard drive. 13. Browser-based package management Package manager GUIs are pretty good now, but remote installation requires dropping back to the command line, with all its pros and cons. A package manager that ran in a web browser would make browsing and updating software on a remote computer so much more pleasant. 14. Do we need so many packages? Some projects have the source, along with Deb and RPM files, for download. Others have separate packages for every version of Ubuntu since brown was invented, plus every SUSE and Fedora variant. Is that really necessary, or is it just easier for the developer and to hell with the poor end user (or our poor disc editor Mike)? 15. No single directory installs The idea of installing each package in its own directory comes up from time to time. While it appears to have appeal, it's inefficient and adds more problems than it pretends to fix. If you had all-encompassing package management that took care of all details of installation for us, it wouldn't matter where files were installed – just click the install button then run the program from the menu. 16. Link to package manager from web pages When you find a website for a package you want to try, you then have to start looking for the package in your package manager, or risk using one direct from the site that hasn't been verified by your distro. A type of URL that launches the package manager to search for the package, like market:// URLs do in Android, would make it so much easier to go straight from the website to installation without the various risks associated with Windows-style EXE installers. 17. Run after installation If you're installing a piece of software that isn't a background process, there's a good chance that you want to actually run it as well as install it. How convenient would it be if your favourite package manager had a checkbox to run the program after installation? There'd be no hunting through menus after installation, just hit 'Install and run' and that's it. 18. Keep source builds in package database Not only is installing from source a bit of a pain, it also means that the package manager is unaware of what you've installed, so it thinks that dependencies aren't satisfied. Having a package manager that could also build source packages would not only ease the pain of installation, it would also enable it to keep track of just what is installed on the system. 19. No all-inclusive packages The separation of applications and libraries into separate packages introduces dependencies and other problems, but these are handled efficiently by most package managers. The alternative, as used by Windows, is to put everything in one package, meaning you can end up with different versions of the same library scattered across your filesystem. 20. Clean up old dependencies When you install a package its dependencies are also installed, but when you later remove the package those dependencies stay on the system, gradually filling up your filesystem with cruft. Not only should package managers remove dependencies that are no longer required, they should be able to check and clean up the system from time to time as well.

You are subscribed to email updates from TechRadar: All Applications feeds To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610