You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
139 lines
6.7 KiB
139 lines
6.7 KiB
14 years ago
|
<!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>Qt/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>Qt/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 Qt/Mac is compliant, and the grey areas where
|
||
|
compliance is more questionable. (See also the document
|
||
|
<a href="mac-differences.html">Qt/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). Qt/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> Qt/Mac does this via the <a href="qmenubar.html">QMenuBar</a> abstraction. Mac users expect to
|
||
|
have a menubar at the top of the screen and Qt/Mac honors this.
|
||
|
<p> Additionally, users expect certain conventions to be respected, for
|
||
|
example the application menu should contain About, Preferences,
|
||
|
Quit, etc. Qt/Mac handles this automatically, although it does not
|
||
|
provide a means of interacting directly with the application menu.
|
||
|
(By doing this automatically, Qt/Mac makes it easier to port Qt/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 Qt/Mac provides widgets that look like
|
||
|
those described in the Human Interface Descriptions. Qt/Mac's
|
||
|
widgets use the Appearance Manager to implement the look, so
|
||
|
Apple's own API's are doing the rendering (Qt/Mac <3.1 used an
|
||
|
emulation style with pixmaps, however this quickly 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 Qt/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 Qt has other concerns to bear in mind, especially
|
||
|
remaining multiplatform. Some "baggage" that Qt 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 Qt/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
|
||
|
Qt/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. Qt/Mac is fully API compatible with Qt/Windows
|
||
|
and Qt/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="qwidget.html#setIcon">QWidget::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 Qt 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 Qt 3.3 Qt/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). Qt/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 Qt's preprocessors (moc
|
||
|
and uic) since qmake automatically handles them and ensures that
|
||
|
everything necessary is linked into your application.
|
||
|
<p> Qt 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 Qt'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>Qt 3.3.8</div>
|
||
|
</table></div></address></body>
|
||
|
</html>
|