by Kyle D'Addario & Wincent Colaiuta The Best Way To Optimize Mac OS X. Mac OS X is a wonderful operating system; it has a raft of innovative new features (like the dock), easy access to the power of Unix and all its industrial-strength serving applications (like Apache), the famous Mac ease of use, and some of the most delicious eye candy ever seen outside of a science fiction movie (hmmm. Aqua). But all is not perfect just yet. One of the biggest and most oft-voiced criticisms of the new OS is its lack of speed and responsiveness. Despite all the good things about Mac OS X many users find themselves switching back to Mac OS 9 because they are frustrated. Laner mac os. 'Things are simply faster in 9', they say. 'I spend half of my time watching the spinning rainbow (busy) cursor,' they say. In this edition of Hot Cocoa I will talk about some ways in which I personally have overcome these frustrations. The tips I offer here won't work for everybody, although they certainly will help some. I offer them to illustrate a larger point and hopefully to encourage people to persist with Mac OS X even if they feel that it is a barrier to their productivity at first. The point is this: often the best way to optimize a system is not to install the latest software shortcut, or upgrade to the latest hardware; rather, it is the optimization of usage habits that a user can make as he or she becomes more familiar with the operating environment. This takes time. Use Mac OS X for a week and you might decide that you hate it; use it for a month and you'll find dozens of ways to work around the things that annoy you; use it for three months and you'll have forgotten what it was like to work under 9 -- you'll be working in ways that you never even thought of before, and perhaps you won't even be seeing that dreaded spinning rainbow cursor at all. Mr. cube (realhannugupta) mac os. So now, on with the show. I'll list the various things that I initially found frustrating about Mac OS X and then provide explanations of how I addressed the issues. Complaint: I thought this thing had preemptive multitasking! One of Mac OS X's selling points is that it has fully preemptive multitasking. This means that the machine will keep on chugging along even if one process wants to be greedy and hog the CPU. Movies will keep playing smoothly while files are decompressing; progress bars continue to update while menus are down; you can switch to other applications and work with them while other applications are launching. Why this rainbow busy cursor all the time? This is the cursor that Mac OS X displays while the front most application is busy doing something and is not ready to receive user input. Users get frustrated waiting for it to go away because it impedes their workflow. 'So much for preemptive multitasking; I seem to spend most of my time waiting!' Solution: do some multitasking yourself! Notice that even when the rainbow cursor appears that other apps continue to run smoothly under Mac OS X. Even if the Finder locks up for minutes at a time, you can mouse over the dock and note that the textual labels still pop up instantly and you can switch to other apps. Unlike under OS 9, the machine as a whole rarely locks up; it's mostly only individual apps that become unresponsive. So the solution is to take care of the multitasking yourself. If one app is busy, switch to another and do something else. Run a lot of apps at once. Keep multiple tasks in progress at any one time. This might require a bit of adjustment to your usage habits, but it will be worth it. When I was using Mac OS X a few months ago I think I spent about a quarter of all my time waiting for the busy cursor to go away. Nowadays I spend only a few seconds each day waiting for it. Complaint: The Finder is slowwwww! Many people complain about the Finder's speed: Window resizing is slow; there are a lot of busy cursors; there are delays before new windows appear, and so forth. Given that the Finder is one of the most heavily-used applications in any user's arsenal this presents a bit of a problem. Many of the Finder's problems stem from the fact that it is written using Carbon rather than Mac OS X's much more mature Cocoa API. Apple wanted to show that it could 'eat its own dog food' and code something major with Carbon; unfortunately for us, they chose one of the apps that we rely on the most. So how do we tackle the problem? Solution: Reduce your dependency on the Finder Painful but true: we have to reduce our reliance on the Finder. Learn to use all of Mac OS X's shortcuts and tricks for opening and organizing files. Use the 'Recent items' submenu in the Apple menu as much as possible, or the recent items menus offered within individual applications. Put shortcuts in the dock (you could put applications in the dock, or a folder containing shortcuts to all of your favorite items). Learn to use the command line interface (the Terminal) -- some operations are much faster in it. Make the most of docklings -- these are little apps which run in the dock and handle simple tasks like going to specific panes in the System Preferences application. Learn about third party tools, like the excellent DragThing -- some of these can be real time savers. Finally, and most obviously, take the time to set up the Finder exactly as you want it. The first few weeks (and even months) you'll be rearranging icons, resizing columns and windows, agonizingly copying files and folders, and customizing toolbars. But once this is done, using the Finder should become more and more pleasant; especially seeing as you'll have developed so many other strategies for performing tasks that you won't need the Finder much anyway. Complaint: Apps take ages to launch Under Mac OS 9 the really big applications -- Adobe Photoshop, Illustrator and the like -- took a long time to launch but pretty much everything else launched very snappily. Under Mac OS X things are different. Apps like Photoshop are Classic apps and they can take more than a minute to launch if the Classic environment is not already running. Other (non-Classic) apps still entail seemingly interminable waits at times. People pass the time counting the number of dock bounces an app takes to launch. Solution: Think 'Unix' Mac OS X runs on a Unix core and this has several implications. One is that many apps are slow to launch. I have used many Unix operating systems over the years, and although they boast amazing stability and reliability, their launch times are often disappointing. But what do they offer in return and how can we take advantage of it? Obviously, if apps take ages to launch then we shouldn't launch them often. 'Launch 'em and leave 'em,' I say. Unlike Mac OS 9, Mac OS X's modern virtual memory system should enable you to leave as many apps running at once as you please. And because each app operates in a protected memory environment there are no stability issues to be fearful about with so many apps running at the same time. If it takes a long time to launch an app, why not launch several at once? Under Mac OS 9 you could tell the Finder to open several apps and it would open then one at a time, in sequence. Mac OS X actually launches all of them concurrently, with very little speed penalty. Because Mac OS X offers a preemptively multitasked environment you can also switch to another app while you are waiting for another to finish launching. Try doing that with Adobe Illustrator under Mac OS 9. The final aspect of Unix mentality that will be beneficial to adopt is 'don't reboot.' Once your system is up and running it will happily continue on for a long, long time. There's no need to worry about the system degrading and becoming unstable the longer it runs. Get your system up and then keep it up, if you can. I have a laptop, so unfortunately I have to shutdown whenever I am moving between locations -- but for other people, leave the machine up as long as you can bear it and you'll find your productivity increases (and as for electricity, er. what can I say?) Conclusion These are just some of the strategies that I have found myself using over the last few months living with Mac OS X as my full-time OS. I don't think I would've discovered them unless I had stuck with the OS despite all of its little annoyances. Persist. Be bold -- try new things. Open your mind to new ways of working and don't cling to your old habits. Learn keyboard shortcuts. Try new software. Share your knowledge with others (a great way to start is by leaving a comment on this article). One of the most exciting things about Mac OS X is that it is only a beginning and is still a work in progress. I wrote this article because one of the shortcomings of the OS is that it is less responsive and speedy than we all hoped it would be. But thankfully for us, the future is bright: machines are getting faster, graphics cards are getting better, and Apple is working long, long days for us optimizing and improving the code of Mac OS X. Other developers too, are getting more familiar with the OS and are writing better and better code for it. If you're even mildly happy with the way Mac OS X is right now, imagine what you'll think of it this time next year. -Wincent Colaiuta You are encouraged to send Richard your comments, or to post them below. Most Recent Hot Cocoa Columns Mac OS X & Firewalls: Part One - The Basics Console Yourself: Understanding Mac OS X Logs Making NFS Work On Mac OS X Hot Cocoa Archives Back to The Mac Observer For More Mac News! Kyle D'Addario is the assistant editor of The Mac Observer and has logged about as much time on Mac OS X as is humanly possible. Kyle studies Computer-Mediated Communication, whatever that is, at the graduate level, and was a founding member of the original Webintosh team. Wincent Colaiuta runs Macintosh news and criticism site, wincent.org, and joined The Mac Observer team as a contributor in March 2001. He has worked with computers since 1984, and his interests in that area include Macs, PHP programming and security. |
Mac OS X is a UNIX platform and behaves similar to other Unix-like platforms. The main difference is X11 is not used as the primary windowing system. Instead, Mac OS X uses its own native windowing system that is accessible through the Carbon and Cocoa APIs. Application development on Mac OS X is done using Xcode Tools, an optional install included on every Mac with updates available from Apple's developer website. Xcode Tools includes Apple-modified versions of the GCC compiler.
Our website provides a free download of Chill Lite 1.4 for Mac. The application is included in Productivity Tools. This Mac download was checked by our built-in antivirus and was rated as malware free. The latest version of the program is supported on Mac OS X 10.6 or later. This free Mac application is a product of Dave Cheng. Its successor Mac OS X 5 also ran on PowerPC when it first launched; it wasn't until 10.4 that Apple began to switch to Intel processors instead, and 10.6 when PowerPC was finally dropped. Mac OS X was a huge step forward from Mac OS 9 in a number of ways, including preemptive multitasking so that you could actually run multiple things at. Enjoy Fever's rich RSS experience while taking advantage of Cocoa and all of the other modern technologies in Mac OS X. System-wide Integration - Filling the void where Web applications fail, Chill Pill allows you to set Fever as your default RSS reader, change hot keys via System Preferences, get notified when new items are available, and much. STEP 1: Remove Unknown Profiles Created by Chill-tab.com Program From Mac OS. Profiles are utility that allows business or organizations to control the actions and behavior of the Mac system. Thus, any profile created by the admins will prevent the users to change them. However, adware distributes design their programs that may create new profile. Well, to create applications for cocoa on Mac OS X, Apple created its own IDE called Project Builder. Just as Darwin is based on an open foundation, Davidson said that Project Builder is based on.
What Versions of Mac OS X are Supported?
As of Qt 4.7, Qt supports Mac OS X versions 10.4 and up. It is usually in the best interest of the developer and user to be running the latest updates to any version. We test internally against Mac OS X 10.4.11 as well as the updated release of Mac OS X 10.5 and Mac OS X 10.6.
Carbon or Cocoa?
Qt supports building in two flavors, using either the Carbon or Cocoa API. Using the Cocoa API, Qt requires 10.5 and provides both 32-bit and 64-bit support. With Carbon, Qt can be developed on and deployed to 10.4, but there is no 64-bit support.
Note: There is no accessibility support in the Cocoa version. This is planned for Qt 4.8.
With Qt 4.7 we recommend using the Cocoa version of Qt for development, unless you want to target the 10.4 platform. Qt uses Cocoa by default, both for the binary package and when configuring Qt from source (using the configure script). To build Qt for Carbon, specify the -carbon flag to configure.
There are two versions of the Qt binary, one with x86 and x86_64 Cocoa and another with x86 and ppc Carbon. If you want a different setup you must build Qt yourself using the source package. To explicitly configure Qt to build for 34-bit or 64-bit architectures (or both), use the -arch flags (see Universal Binaries). For the Cocoa version, 64 bit is chosen by default.
Currently, Apple's default GCC compiler is used by default (GCC 4.0.1 on 10.4 and 10.5, GCC 4.2 on 10.6). You can specify alternate compilers though. For example, on Mac OS X 10.5, Apple's GCC 4.2 is also available and selectable with the configure flag: -platform macx-g++42. LLVM-GCC support is available by passing in the -platform macx-llvm flag. GCC 3.x will not work. Though they may work, We do not support custom-built GCC's.
The following table summarizes the different versions of Mac OS X and what capabilities are used by Qt.
| Mac OS X Version | Cat Name | Native API Used by Qt | Bits available to address memory | CPU Architecture Supported | Development Platform |
|---|---|---|---|---|---|
| 10.4 | Tiger | Carbon | 32 | PPC/Intel | Yes |
| 10.5 | Leopard | Carbon | 32 | PPC/Intel | Yes |
| 10.5 | Leopard | Cocoa | 32/64 | PPC/Intel | Yes |
| 10.6 | Snow Leopard | Cocoa/Carbon | 32 | PPC/Intel | Yes |
| 10.6 | Snow Leopard | Cocoa | 64 | Intel | Yes |
Note that building for ppc-64 is not supported on 10.6.
Which One Should I Use?
Carbon and Cocoa both have their advantages and disadvantages. Probably the easiest way to determine is to look at the version of Mac OS X you are targetting. If your application can target 10.5 and up, then we recommend using Cocoa. If you need to target earlier versions of the operating system and do not need access to 64-bit or newer Apple technologies, then Carbon is a good fit. If your needs fall in between, you can go with a 64-bit Cocoa and 32-bit Carbon universal application.
For Mac OS X 10.6, Apple has started recommending developers to build their applications 64-bit. The main reason is that there is a small speed increase due to the extra registers on Intel CPU's, all their machine offerings have been 64-bit since 2007, and there is a cost for reading all the 32-bit libraries into memory if everything else is 64-bit. If you want to follow this advice, there is only one choice, 64-bit Cocoa.
Building Qt statically
Roundabout demo mac os. We recommend building Qt as shared frameworks. Static builds are only partially supported, meaning that you can build most of Qt statically, but some modules, like web-kit and Designer, will fail. You can specify which modules to build from configure (e.g. -no-webkit -nomake tools). For Cocoa configurations, both static and no-framework builds requires manually copying the 'src/gui/mac/qt_menu.nib/ directory into the ' Resources' directory in the application bundle.
Universal Binaries
In 2006, Apple begin transitioning from PowerPC (PPC) to Intel (x86) systems. Both architectures are supported by Qt. The release of Mac OS X 10.5 in October 2007 added the possibility of writing and deploying 64-bit GUI applications. Qt 4.5 and up supports both the 32-bit (PPC and x86) and 64-bit (PPC64 and x86-64) versions of PowerPC and Intel-based systems.
Universal binaries are used to bundle binaries for more than one architecture into a single package, simplifying deployment and distribution. When running an application the operating system will select the most appropriate architecture. Universal binaries support the following architectures; they can be added to the build at configure time using the -arch arguments:
| Architecture | Flag |
|---|---|
| Intel, 32-bit | -arch x86 |
| Intel, 64-bit | -arch x86_64 |
| PPC, 32-bit | -arch ppc |
| PPC, 64-bit | -arch ppc64 |
If there are no -arch flags specified, configure builds Qt for a 32-bit architecture when using Carbon, and a 64-bit architecture when using Cocoa. Universal binaries were initially used to simplify the PPC to Intel migration. You can use -universal to build for both the 32-bit Intel and PPC architectures.
Note: The -arch flags at configure time only affect how Qt is built. Applications are by default built for the 32-bit architecture you are currently on. To build a universal binary, add the architectures to the CONFIG variable in the .pro file:
Working with several versions of Qt
Chill Cocoa Mac Os Download
You can only install one version of Qt at a time when using the binary package. The reason for this is that a binary installation will install different parts of Qt (frameworks, documentation, examples, tools, etc) to different predefined locations on the OS, as described by Apple. If you want to work against other versions at the same time, you need to build the other versions explicitly from source. When doing so, you can provide -prefix to configure to set install location. The binary package will install Qt to the following locations:
| Qt | Location |
|---|---|
| Designer, Linguist . | /Developer/Applications/Qt |
| Documentation | /Developer/Documentation/Qt |
| Examples | /Developer/Examples/Qt |
| Plugins | /Developer/Applications/Qt/Plugins |
| Frameworks | /Library/Frameworks |
| Libraries | /usr/lib |
| qmake, moc, uic . | /Developer/Tools/Qt (symlink to /usr/bin) |
| uninstall-qt.py, uninstall-qtsdk.py | /Developer/Tools |
Day-to-Day Application Development on OS X
On the command-line, applications can be built using qmake and make. Optionally, qmake can generate project files for Xcode with -spec macx-xcode. If you are using the binary package, qmake generates Xcode projects by default; use -spec macx-gcc to generate makefiles.
The result of the build process is an application bundle, which is a directory structure that contains the actual application executable. The application can be launched by double-clicking it in Finder, or by referring directly to its executable from the command line, i. e. myApp.app/Contents/MacOS/myApp.
Note: There is no accessibility support in the Cocoa version. This is planned for Qt 4.8.
With Qt 4.7 we recommend using the Cocoa version of Qt for development, unless you want to target the 10.4 platform. Qt uses Cocoa by default, both for the binary package and when configuring Qt from source (using the configure script). To build Qt for Carbon, specify the -carbon flag to configure.
There are two versions of the Qt binary, one with x86 and x86_64 Cocoa and another with x86 and ppc Carbon. If you want a different setup you must build Qt yourself using the source package. To explicitly configure Qt to build for 34-bit or 64-bit architectures (or both), use the -arch flags (see Universal Binaries). For the Cocoa version, 64 bit is chosen by default.
Currently, Apple's default GCC compiler is used by default (GCC 4.0.1 on 10.4 and 10.5, GCC 4.2 on 10.6). You can specify alternate compilers though. For example, on Mac OS X 10.5, Apple's GCC 4.2 is also available and selectable with the configure flag: -platform macx-g++42. LLVM-GCC support is available by passing in the -platform macx-llvm flag. GCC 3.x will not work. Though they may work, We do not support custom-built GCC's.
The following table summarizes the different versions of Mac OS X and what capabilities are used by Qt.
| Mac OS X Version | Cat Name | Native API Used by Qt | Bits available to address memory | CPU Architecture Supported | Development Platform |
|---|---|---|---|---|---|
| 10.4 | Tiger | Carbon | 32 | PPC/Intel | Yes |
| 10.5 | Leopard | Carbon | 32 | PPC/Intel | Yes |
| 10.5 | Leopard | Cocoa | 32/64 | PPC/Intel | Yes |
| 10.6 | Snow Leopard | Cocoa/Carbon | 32 | PPC/Intel | Yes |
| 10.6 | Snow Leopard | Cocoa | 64 | Intel | Yes |
Note that building for ppc-64 is not supported on 10.6.
Which One Should I Use?
Carbon and Cocoa both have their advantages and disadvantages. Probably the easiest way to determine is to look at the version of Mac OS X you are targetting. If your application can target 10.5 and up, then we recommend using Cocoa. If you need to target earlier versions of the operating system and do not need access to 64-bit or newer Apple technologies, then Carbon is a good fit. If your needs fall in between, you can go with a 64-bit Cocoa and 32-bit Carbon universal application.
For Mac OS X 10.6, Apple has started recommending developers to build their applications 64-bit. The main reason is that there is a small speed increase due to the extra registers on Intel CPU's, all their machine offerings have been 64-bit since 2007, and there is a cost for reading all the 32-bit libraries into memory if everything else is 64-bit. If you want to follow this advice, there is only one choice, 64-bit Cocoa.
Building Qt statically
Roundabout demo mac os. We recommend building Qt as shared frameworks. Static builds are only partially supported, meaning that you can build most of Qt statically, but some modules, like web-kit and Designer, will fail. You can specify which modules to build from configure (e.g. -no-webkit -nomake tools). For Cocoa configurations, both static and no-framework builds requires manually copying the 'src/gui/mac/qt_menu.nib/ directory into the ' Resources' directory in the application bundle.
Universal Binaries
In 2006, Apple begin transitioning from PowerPC (PPC) to Intel (x86) systems. Both architectures are supported by Qt. The release of Mac OS X 10.5 in October 2007 added the possibility of writing and deploying 64-bit GUI applications. Qt 4.5 and up supports both the 32-bit (PPC and x86) and 64-bit (PPC64 and x86-64) versions of PowerPC and Intel-based systems.
Universal binaries are used to bundle binaries for more than one architecture into a single package, simplifying deployment and distribution. When running an application the operating system will select the most appropriate architecture. Universal binaries support the following architectures; they can be added to the build at configure time using the -arch arguments:
| Architecture | Flag |
|---|---|
| Intel, 32-bit | -arch x86 |
| Intel, 64-bit | -arch x86_64 |
| PPC, 32-bit | -arch ppc |
| PPC, 64-bit | -arch ppc64 |
If there are no -arch flags specified, configure builds Qt for a 32-bit architecture when using Carbon, and a 64-bit architecture when using Cocoa. Universal binaries were initially used to simplify the PPC to Intel migration. You can use -universal to build for both the 32-bit Intel and PPC architectures.
Note: The -arch flags at configure time only affect how Qt is built. Applications are by default built for the 32-bit architecture you are currently on. To build a universal binary, add the architectures to the CONFIG variable in the .pro file:
Working with several versions of Qt
Chill Cocoa Mac Os Download
You can only install one version of Qt at a time when using the binary package. The reason for this is that a binary installation will install different parts of Qt (frameworks, documentation, examples, tools, etc) to different predefined locations on the OS, as described by Apple. If you want to work against other versions at the same time, you need to build the other versions explicitly from source. When doing so, you can provide -prefix to configure to set install location. The binary package will install Qt to the following locations:
| Qt | Location |
|---|---|
| Designer, Linguist . | /Developer/Applications/Qt |
| Documentation | /Developer/Documentation/Qt |
| Examples | /Developer/Examples/Qt |
| Plugins | /Developer/Applications/Qt/Plugins |
| Frameworks | /Library/Frameworks |
| Libraries | /usr/lib |
| qmake, moc, uic . | /Developer/Tools/Qt (symlink to /usr/bin) |
| uninstall-qt.py, uninstall-qtsdk.py | /Developer/Tools |
Day-to-Day Application Development on OS X
On the command-line, applications can be built using qmake and make. Optionally, qmake can generate project files for Xcode with -spec macx-xcode. If you are using the binary package, qmake generates Xcode projects by default; use -spec macx-gcc to generate makefiles.
The result of the build process is an application bundle, which is a directory structure that contains the actual application executable. The application can be launched by double-clicking it in Finder, or by referring directly to its executable from the command line, i. e. myApp.app/Contents/MacOS/myApp.
If you wish to have a command-line tool that does not use the GUI (e.g., moc, uic or ls), you can tell qmake not to execute the bundle creating steps by removing it from the CONFIG in your .pro file: 50 lions slot game.
Deployment - 'Compile once, deploy everywhere'
In general, Qt supports building on one Mac OS X version and deploying on all others, both forward and backwards. You can build on 10.4 Tiger and run the same binary on 10.5 and up.
Some restrictions apply:
- Some functions and optimization paths that exist in later versions of Mac OS X will not be available if you build on an earlier version of Mac OS X.
- The CPU architecture should match.
- Cocoa support is only available for Mac OS X 10.5 and up.
Universal binaries can be used to provide a smorgasbord of configurations catering to all possible architectures.
Mac applications are typically deployed as self-contained application bundles. The application bundle contains the application executable as well as dependencies such as the Qt libraries, plugins, translations and other resources you may need. Third party libraries like Qt are normally not installed system-wide; each application provides its own copy.
Chill Cocoa Mac Os Catalina
The most common way to distribute applications is to provide a compressed disk image (.dmg file) that the user can mount in Finder. The Mac deployment tool (macdeployqt) can be used to create the self-contained bundles, and optionally also create a .dmg archive. See the Mac deployment guide for more information about deployment. It is also possible to use an installer wizard. More information on this option can be found in Apple's documentation.
© 2016 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.
