diff options
Diffstat (limited to 'doc/html/qtmac-as-native.html')
| -rw-r--r-- | doc/html/qtmac-as-native.html | 138 |
1 files changed, 138 insertions, 0 deletions
diff --git a/doc/html/qtmac-as-native.html b/doc/html/qtmac-as-native.html new file mode 100644 index 000000000..bafba120d --- /dev/null +++ b/doc/html/qtmac-as-native.html @@ -0,0 +1,138 @@ +<!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="qmenubar.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="qwidget.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> |