<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- /home/espenr/tmp/qt - 3.3.8 - espenr - 2499/qt - x11 - free - 3.3.8/doc/qtmac - as - native.doc:36 -->
< html >
< head >
< meta http-equiv = "Content-Type" content = "text/html; charset=ISO-8859-1" >
< title > TQt/Mac is Mac OS X Native< / title >
< style type = "text/css" > < ! - -
fn { margin-left: 1cm; text-indent: -1cm; }
a:link { color: #004faf; text-decoration: none }
a:visited { color: #672967; text-decoration: none }
body { background: #ffffff; color: black; }
-->< / style >
< / head >
< body >
< table border = "0" cellpadding = "0" cellspacing = "0" width = "100%" >
< tr bgcolor = "#E5E5E5" >
< td valign = center >
< a href = "index.html" >
< font color = "#004faf" > Home< / font > < / a >
| < a href = "classes.html" >
< font color = "#004faf" > All Classes< / font > < / a >
| < a href = "mainclasses.html" >
< font color = "#004faf" > Main Classes< / font > < / a >
| < a href = "annotated.html" >
< font color = "#004faf" > Annotated< / font > < / a >
| < a href = "groups.html" >
< font color = "#004faf" > Grouped Classes< / font > < / a >
| < a href = "functions.html" >
< font color = "#004faf" > Functions< / font > < / a >
< / td >
< td align = "right" valign = "center" > < img src = "logo32.png" align = "right" width = "64" height = "32" border = "0" > < / td > < / tr > < / table > < h1 align = center > TQt/Mac is Mac OS X Native< / h1 >
< p >
< p > This document explains what makes an application "native" on Mac OS X.
It shows the areas where TQt/Mac is compliant, and the grey areas where
compliance is more questionable. (See also the document
< a href = "mac-differences.html" > TQt/Mac Issues< / a > .)
< p > Normally when referring to a native application, one really means an
application that talks directly to the underlying window system and
operating system, rather than one that uses some intermediary (for
example the X11 server, or a web browser). TQt/Mac applications run as
first class citizens, just like Cocoa, Java, and Carbon applications.
< p > When an application is running as a first class citizen it means that
it can interact with specific components of the Mac OS X experience:
< p > < ul >
< li > < b > The global menubar< / b > < br >
< p > TQt/Mac does this via the < a href = "ntqmenubar.html" > TQMenuBar< / a > abstraction. Mac users expect to
have a menubar at the top of the screen and TQt/Mac honors this.
< p > Additionally, users expect certain conventions to be respected, for
example the application menu should contain About, Preferences,
Quit, etc. TQt/Mac handles this automatically, although it does not
provide a means of interacting directly with the application menu.
(By doing this automatically, TQt/Mac makes it easier to port TQt/Mac
applications to other platforms.)
< p > < li > < b > Aqua< / b > < br >
< p > This is a critical piece of Mac OS X (documentation can be found at
< a href = "http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html" > http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html< / a > ).
It is a huge topic, but the most important guidelines for GUI
design are probably these:
< p > < ul >
< li > < em > Aqua look< / em > < br >
< p > As with Cocoa/Carbon TQt/Mac provides widgets that look like
those described in the Human Interface Descriptions. TQt/Mac's
widgets use the Appearance Manager to implement the look, so
Apple's own API's are doing the rendering (TQt/Mac < 3.1 used an
emulation style with pixmaps, however this tquickly proved to be
cumbersome, and unable to keep up with style changes at Apple).
< p > < li > < em > Aqua feel< / em > < br >
< p > This is a bit more subjective, but certainly TQt/Mac strives to
provide the same feel as any Mac OS X application (and we
consider situations where it doesn't achieve this to be bugs).
Of course TQt has other concerns to bear in mind, especially
remaining multiplatform. Some "baggage" that TQt carries is in
an effort to provide a widget on a platform for which an
equivelant doesn't exist, or so that a single API can be used to
do something, even if the API doesn't make entire sense for a
specific widget (for example pushbuttons with a popup menu are
really bevel buttons in Mac OS X, but TQt/Mac cannot guess that
this bevel button is right next to other real pushbuttons).
< p > < li > < em > Aqua guides< / em > < br >
< p > This is the most subjective, but there are many suggestions and
guidelines in the Aqua style guidelines. This is the area where
TQt/Mac is of least assistance. The decisions that must be made
to conform (widget sizes, widget layouts with respect to other
widgets, window margins, etc) must be made based on the user
experience demanded by your application. If your user base is
small or mostly comes from the Windows or Unix worlds, these are
minor issues much less important than trying to make a mass
market product. TQt/Mac is fully API compatible with TQt/Windows
and TQt/X11, but Mac OS X is a significantly different platform
to Windows and some special considerations must be made based on
your audience.
< p > < / ul >
< p > < li > < b > Dock< / b > < br >
< p > Interaction with the dock is limited, but at the very least the icon
should be able to be interacted with. This can be achieved with
< a href = "ntqwidget.html#setIcon" > TQWidget::setIcon< / a > (). The setIcon() call can be made as often as
necessary, so can be used to provide a constantly updating pixmap
that works as expected.
< p > < li > < b > Accessiblity< / b > < br >
< p > Although many users never use this, some users will only interact
with your applications via assistive devices. With TQt the aim is to
make this automatic in your application so that it conforms to
accepted practice on its platform (X11 accessiblity support is
still in the works due to the developing nature of its
accessibility design). With TQt 3.3 TQt/Mac will support
accessiblity, and hopefully a host of assistive devices.
< p > < li > < b > Build tools< / b > < br >
< p > Mac OS X developers expect a certain level of interopability
between their development toolkit and the platform's developer
tools (for example MSVC, gmake, etc). TQt/Mac supports both Unix
style Makefiles, and ProjectBuilder/Xcode project files by using
the qmake tool. For example:
< p > < pre >
qmake -spec macx-pbuilder project.pro
< / pre >
< p > will generate an Xcode project file from project.pro. With qmake
you do not have to worry about rules for TQt's preprocessors (moc
and uic) since qmake automatically handles them and ensures that
everything necessary is linked into your application.
< p > TQt does not entirely interact with the development environment (for
example plugins to set a file to 'mocable' from within the Xcode
user interface). Trolltech is actively working on improving TQt's
interoperability with various IDEs, so hopefully this will be
supported soon.
< p > < / ul >
< p >
<!-- eof -->
< p > < address > < hr > < div align = center >
< table width = 100% cellspacing = 0 border = 0 > < tr >
< td > Copyright © 2007
< a href = "troll.html" > Trolltech< / a > < td align = center > < a href = "trademarks.html" > Trademarks< / a >
< td align = right > < div align = right > TQt 3.3.8< / div >
< / table > < / div > < / address > < / body >
< / html >
