Currently, the Qt Reference Documentation is not shipped with the OS/2 version of the Qt Toolkit (it will be done later).
You can view it online using this link: http://doc.trolltech.com/3.3/index.html.
The OS/2 version of the Qt Library is not yet complete. Some features are still under development and there are some known bugs. They are briefly described below.
1 | Drag & Drop (QT_NO_DRAGANDDROP is constantly
defined for now) |
2 | OS/2 widget style (a native look and feel of buttons, combo boxes and other common widgets) |
3 | Printing support (QPrinter class is absent,
QT_NO_PRINTER is constantly defined for now) |
4 | Process management (QProcess class is absent) |
5 | Audio support (QSound class) |
6 | sql module (QSql class and friends) |
7 | table module (QTable class, depends only
on Drag & Drop) |
8 | iconview module (QIconView class, depends
only on Drag & Drop) |
9 | canvas module (QCanvas and friends) |
10 | OpenGL module (QGL class and friends) |
11 | Plugin support |
12 | Qt Designer tool (depends only on Drag & Drop) |
13 | Qt Linguist tool (depends only on Drag & Drop) |
14 | Qt Assistant tool (depends only on Drag & Drop) |
1 | Unicode is not fully supported in GUI, to the effect that only the symbols from the current (system) 8-bit charset can appear in widgets and when drawing text. |
2 | Alpha blending for pixmaps is not yet implemented
[themes example]. |
3 | Complex text transformations (rotation etc.) don't work correctly
with the FreeType2 rendering engine. Most likely a bug or a limitation
of FreeType2 [xform example]. |
4 | Text rotation to values greater than 90 degrees clockwise doesn't
work with truetype fonts and the standard TTF rendering engine. This
seems like an OS/2 bug [xform example]. |
5 | Stay-on-top is not supported system-wide. |
The GNUMAKE backend generates makefiles for the GNU Make utility from qmake's project files. A separate generator became necessary because the previously used MINGW generator has some problems and limitations that make it impossible to generate correct makefiles in several situations. This new generator is primarily intended to be used with GNU Make under OS/2, but theoretically can be used on any platform after some modifications. However, its usage under other platforms is not tested and not supported.
The GNUMAKE backend was initially based on the existing MINGW backend, so here is the list of its differences and improvements comparing to the MINGW backend:
1. QMAKE_LINK_OBJECT_MAX
,
QMAKE_LINK_OBJECT_SCRIPT
,
QMAKE_LINK_OBJMOC_SCRIPT
are no longer supported, since the
OS/2 version of GNU LD (linker) seems not to support object
link scripts. The OS/2 CMD.EXE command line length limitation (1024 chars)
is worked around in a different way (see the
\mkspecs\os2-g++\qmake.conf if interested).
2. Added new qmake varibales QMAKE_RUN_LINK
and
QMAKE_RUN_LIB
(intended to be used in qmake.conf) to
explicitly specify the command to execute the linker and the librarian,
respectively. These variables are optional and have the following
defaults:
$(LINK) $(LFLAGS) -o $(TARGET) $(DEF_FILE) $(OBJECTS) $(OBJMOC) $(LIBS) $(LIB) $(TARGET) $(OBJECTS) $(OBJMOC)
3. QMAKE_EXTRA_WIN_COMPILERS
and
QMAKE_EXTRA_WIN_TARGETS
are renamed to
QMAKE_EXTRA_COMPILERS
and QMAKE_EXTRA_TARGETS
respectively, for clarity.
4. Leaving QMAKE_LIBS_QT_ENTRY
empty does not produce a
qmake warning any more.
5. Added the new qmake variable QMAKE_RUN_IMPLIB
used to
produce the import library when the target is the dynamic link library. It
is expected that this variable specifies the output import library name
with the $(TARGET_IMPLIB)
macro, which is defined by qmake as
the project's target dll full basename with the .lib
extension.
6. Added new qmake variables QMAKE_RUN_GENDEF
and
QMAKE_GENDEF_DEPS
. They are intended to generate a
.def file containing a list of DLL exports when the target is
the dynamic link library (i.e. when TEMPLATE = lib
and
CONFIG
contains dll
) and the
DEF_FILE
variable is empty or not specified in the project
file. In this case, the DEF_FILE
macro is defined by qmake as
the project's target full basename with the .def extension.
QMAKE_RUN_GENDEF
is the command to generate this
DEF_FILE
(its output must go to $(DEF_FILE)
).
QMAKE_GENDEF_DEPS
is the list of dependencies for the
DEF_FILE
.
7. Empty OBJECTS_DIR
and MOC_DIR
qmake
variables do not cause GNU Make to print warnings any more.
8. Fixed the dist makefile target: the generated zip didn't have the name (only extension).
9. Commands for custom (user defined) targets and for extra compilers
(i.e. values of <my_target>.commands
variables) are now
splitted at ' ;; ' sequences (a double semicolon
surrounded by single spaces) and placed to separate lines in the makefile.
For example, the definition
'<my_target>.command = c1 ;; c2
'
will apperar as follows:
<my_target>: <my_target_deps> c1 c2
10. Added new qmake variables QMAKE_QUIET_CLEAN
and
QMAKE_IF_FILE_EXISTS
. QMAKE_QUIET_CLEAN
is
similar QMAKE_CLEAN
, but adds
$(QMAKE_IF_FILE_EXISTS)
to the beginning of each
$(DEL_FILE)
statement to delete a file only if it exists (to
avoid system warnings).
11. Object files are no more forced to have the .o
extension. The standard qmake QMAKE_EXT_OBJ
variable is used
instead (by default, on OS/2 it equals to .obj).
QMAKE_EXT_CPP
variable is regarded as well.
12. Library files now have the .lib extension (instead of .a), and the lib... prefix is no more prepended.
13. Added new QMAKE_CFLAGS_INCDIR
,
QMAKE_LFLAGS_LIBDIR
, QMAKE_LFLAGS_LIB
qmake
variables to make it possible to customize the coorresponding flags (i.e.,
-I, -L and -l, as for GCC) in the
.conf file.
14. Added new QMAKE_LIBS_QT_DLL
and
QMAKE_LIBS_QT_THREAD_DLL
qmake variables to specify the list
of libraries required when the application is linked against the DLL
version of Qt, separately from the list of libraries required for linking
against the static Qt library.
15. The QMAKESPECDIR
variable is defined in the generated
makefile and points to the directory where a qmake.conf file
being used was read from.
16. Added new qmake variables DEF_FILE_TEMPLATE
and
DEF_FILE_MAP
. When the target is the dynamic link library and
DEF_FILE
is not defined in the project file, these
variables (when defined) go to the generated makefile w/o any changes.
They are also appended (as GNU make variables) to the contents of the
QMAKE_GENDEF_DEPS
variable (see 6).
DEF_FILE_TEMPLATE
is intended to point to an existing
template for a .def file. DEF_FILE_MAP
should
point to an existing file used to store ordinals assigned to exported
symbols (to make assignments persistent from build to build). The backend
itself doesn't use these variables, they are used only to pass the
information from the project file to the generated makefile. It is the
responsibility of the .conf file to implement the described
functionality.
17. Objects defining custom targets got the .extradeps
attribute. This attrubute allows to specify additional target dependencies
that are not followed by commands. That is, if you have the following
extra target definition:
my_target.target = somefile my_target.depends = anotherfile my_target.extradeps = export SOMETHING = something my_target.commands = coolcmd > $$my_target.target
you'll get in the generated makefile:
somefile : export SOMETHING = something somefile : anotherfile coolcmd > somefile
Note that if you two or more additional dependencies each placed on a
separate line, you can separate them using ' ;; ' (a
double semicolon surrounded by single spaces) in the definition of the
.extradeps
attribute.
18. Besides the standard INCPATH
make variable that
defines a list of include directories for the C/C++ compiler (separated by
spaces and usually prepended with a compiler switch), all generated
makefiles contain the INCLUDEPATH
make variable that defines
the same list of directories but separated by semicolons (and therefore
suitable for assigning to PATH-like environment variables).
19. Added internal qmake variables QMAKE_RUN_RC_RES
and
QMAKE_RUN_RC_EXE
necessary to implement the support for
RC_FILE
and RES_FILE
project variables.
QMAKE_RUN_RC_RES
defines a command line to generate a project
.res file from an .rc file specified in
RC_FILE
. It should use $(RC_FILE)
as a source
and $(RES_FILE)
as a target of the operation. This command is
used only when the RC_FILE
project variable is not empty.
QMAKE_RUN_RC_EXE
defines a command line to bind a
.res file to the project executable. It should use
$(RES_FILE)
to specify the .res file to bind and
$(TARGET)
to specify the executable file name.
20. Added the internal qmake variable
QMAKE_LIBDIR_QT_DEBUG
. It defines where to place the Qt
library when the debug version is being built, and also where to search
for it when the project file of an application contains qt and
debug keywords in the CONFIG
statement.
21. The VERSION
project variable is copied by
qmake (as is) to the generated makefile. Note that its value
does not affect the name of the generated DLL target anymore (for projects
with the lib template and with the dll keyword in
CONFIG
), as opposed to other qmake backends. Appending a
version number to the DLL name could implicitly lead to running out of the
8x3 naming limit that is still present in OS/2 for DLLs loaded by module
name (the most common case). Instead, the VERSION
macro can
be used by qmake compiler specifications to embed the version to the
generated DLL file itself (as the GCC specification does).
22. Added the internal qmake variable QMAKE_DEFINES_QT
. It
is intended to list a set of C/C++ defines to be used during compilation
of C/C++ sources when either qt, qtinc or
build_qt is present in the CONFIG
statement. Using
this variable instead of DEFINES
keeps non-Qt projects free
from Qt-only related defines (otherwise added to every Makefile generated
by qmake from any project file).