source: trunk/README.OS2@ 760

This is Qt version 4.6.2 for OS/2 and eCS.

This document contains a brief information on the OS/2 version of the Qt
library. Please read it carefully before starting your work. You may also
visit the project page at

  http://svn.netlabs.org/qt4/wiki

to get more information and the latest news and also to report bugs.

To get a brief list of OS/2-specific changes from release to release
please see the CHANGES.OS2 file included in this distribution.

Please note that this version is binary incompatible with previous versions of
Qt 4 for OS/2! This is not a behavior of the original Qt library (where versions
with the same major number are usually binary compatible), but it is due to the
fact that we continue to add missing features to the OS/2 version ot Qt and this
cannot be done witout breaking the binary compatibility. On practice, this means
that you need to recompile your applications with the new version of the Qt
library in order to make them work with it.



REQUIREMENTS

In order to compile the Qt library and Qt-based applications, you will need
the following tools:

  - One of the OS/2 Warp 4, OS/2 Warp 4.5 or eComStation operating systems.

  - GCC compiler version 4.4.2 for OS/2, patched OpenWatcom linker and
    GNU Make 3.81beta1 or above. The GCC compiler must be set up to use the
    OpenWatcom linker for linking.

    If you do not have a working GCC environment with the above requirements, it
    is recommended to download a ready-to-use GCC 4.2.2 distribution from here:

      ftp://ftp.netlabs.org/pub/qt4/gcc-4_4_2-complete-20091205.zip

    This distribution includes all tools necessary to compile and build the Qt
    library from the source code. Just follow the installation instructions
    contained in the README file inside this ZIP archive to set up the GCC
    environment.

    Please note that starting from Qt 4.6.2, support for GCC 3.3.5 and earlier
    versions of the compiler has been dropped and the Qt library will most
    likely not build if you use one of these compilers. Later versions prior to
    GCC 4.4.2 may work but they are not tested and not supported.

There is also a set of optional tools which are necessary to enable the selected
features of the Qt library. If these tools are missing, the Qt configuration
script (discussed in section "COMPILING QT" below) will automatically disable
the corresponding feature:

  - LxLite 1.3.3 or above (not tested) to enable the compression of Qt DLLs and
    application executables (which saves hard disk space and application startup
    time). If you use a recent version of eComStation (e.g. 2.0 rc6) you will
    already have LxLite installed. Otherwise, you may take it from here:

      http://www.os2site.com/sw/util/archiver/lxlt133.zip

  - eCUPS 1.3.11 or later to support printing in Qt. The eCUPS WPI is available
    from:

      ftp://ftp.netlabs.org/incoming/eCUPS003.wpi   or
      ftp://ftp.netlabs.org/pub/ecups/eCUPS003.wpi

    Linking against eCUPS also requires pthread.lib:

      http://web.os2power.com/download/lib/pthread-20100217-os2.zip



SETTING UP THE ENVIRONMENT

First of all, make sure that your GCC environment is set up and meets the
specified requirements. To perform a quick check, you may run the following
command:

  gcc --version && make --version && wl /version

If the setup is done properly, it will print the versions of the key tools
to the console.

The next step is to set up the Qt environment. If you installed the Qt
development libraries from the WPI archive (refer to section "USING OFFICIAL
BINARY QT ARCHIVES" below for more details about existing WPI archives), you
will only need to run the supplied "QtEnv.cmd" script which will do all the
setup job for you. The script is located in the directory where you installed
the developmnent libraries (or in the WPS folder created by the WPI installer).
Execute this script in a command line session to make it ready for building
Qt 4 applications (for example, using the "qmake" command follwed by "make"
for applications based on qmake project files which most of them are). If you
go that way, you may skip the rest of this section and proceed directly to
section called "USING OFFICIAL BINARY QT ARCHIVES" or further. 

If you use the full source code ZIP distribution of the Qt library or work
directly with the Qt SVN tree, you will need to set up the environment yourself
by performing the following steps:

  - Add the "bin" subdirectory of the directory where you unpacked the Qt4
    source tree to PATH and BEGINLIBPATH, like this:

      set PATH=D:\Coding\Qt4\bin;%PATH%
      set BEGINLIBPATH=D:\Coding\Qt4\bin;%BEGINLIBPATH%

  - Add the system DLLs to the GCC library path with the following command:

      set LIBRARY_PATH=C:\OS2\DLL;C:\MPTN\DLL;%LIBRARY_PATH%

    where C: is your boot drive.

  - Make sure CMD.EXE is your command line processor (the generated makefiles
    will rely on its 'copy', 'if' and other commands). If you have a Unix shell
    (SH.EXE) in your environment, you may need to force GNU make to use CMD.EXE
    by executing the followingn command:

       set MAKESHELL=C:\OS2\CMD.EXE

    where C: is your boot drive.

Note that the QTDIR environment variable used in previous Qt versions is not
used in Qt4 anymore. Therefore, there is no need to set this variable
explicitly.

There is also no need to set the QMAKESPEC variable explicitly. If it is absent,
qmake will use the specification stored in the <Qt4_Home>/mkspecs/default
directory, which on OS/2 always refers to the "os2-g++" specification, the only
one supported at the present time.

NOTE:

    It is especially important to make sure that there are no traces of any
    other Watcom or OpenWatcom installation in the environment where you build
    Qt as it will interfere with the patched OpenWatcom linker we use. This
    basically means removing all environment variables containing "WATCOM" in
    their names and also removing references to all those Watcom installations
    from PATH.



SETTING UP OPTIONAL TOOLS

The following list describes the steps necessary to set up the optional tools
that the Qt library depends on:

  - Install the eCUPS WPI archive to enable printing support. If this WPI is
    installed, the Qt build system will pick up all necessary libraries
    automatically. Otherwise (e.g. if you use a ZIP or build eCUPS yourself),
    you will need to use the following environment variables to tell it where to
    look for CUPS:

      set CUPS_INCLUDEPATH=X:\Path\to\CUPS\include
      set CUPS_LIBS=X:\Path\to\CUPS\lib\libcups.a

    You will also need to make sure that pthread.lib is placed somewhere in your
    system library path so that the compiler can find it.



COMPILING QT

You should skip this section if you installed the Qt development libraries using
the WPI archive (that already contains compiled release versions of the
libraries) and proceed directly to the next section.

When the environment is set up, go to the directory where you unpacked the
Qt4 source tree and type:

  configure.cmd

This will set up the Qt library (by creating necessary configuration and include
files and a bunch of Makefiles for variuos components) and build the qmake tool.

The next step is to type:

  make

This will compile and link the Qt library. Note that by default both the release
and the debug version of the library are built (please be patient, it may take
quite some time depending on your hardware). The release and debug libraries can
co-exist in the same source tree and may be used in parallel: all the debug DLLs
get a 'd' letter in their name preceeding the Qt major version number and use
separate directories for object files.

To save time, you may build the release and the debug versions of the Qt library
separately by typing 'make release' or 'make debug' accordingly instead of just
'make'.

Once the library is successfully built, you may try to compile the demos and
examples by visiting the individual example subdirectories in the source tree
and typing 'qmake' followed by one of 'make', 'make release' or 'make debug'
in that subdirectory.

NOTE:

     This version of Qt for OS/2 includes the Extended system tray plugin for
     XCenter/eCenter which is necessary to enable Qt support for the special
     notification area on the XCenter/eCenter panel (called the "system tray")
     which is used by many long-running applications to display their status.
     In order to activate this support, you need to install this plugin to your
     XCenter or eCenter. The plugin is built during the normal Qt build process
     and can be found in the file \plugins\xcenter\xsystray.dll in the Qt source
     tree. In order to install the plugin, do the following:

     a. Copy xsystray.dll to <XWorkplace installation folder>\plugins\xcenter\
        (on eComStation, this will be C:\ecs\system\ewps\plugins\xcenter\ where
        C: is your boot drive).

     b. Restart WPS.

     c. Add the "Extended system tray" widget to the XCenter/eCenter panel using
        the XCenter context menu ('Create new widget').

     Note that if you upgrade from the previous version of the plugin then
     please unlock xsystray.dll in the target folder using the UNLOCK.EXE
     utility (which you can find in the LxLite package, for example) before
     performing step a., otherwise the copy operation will fail.

IMPORTANT NOTE:

     Please take into account that the Qt library you build on your own as
     described above is NOT intended for wide distribution with Qt applications
     you port or create. Such private Qt builds help you develop Qt applications
     (because you can easily debug your program and parts of the Qt framework at
     the source level) but being widely distributed they will create a so-called
     DLL hell when a program running on a user computer crashes because it picks
     up a wrong build of the Qt library. This will happen because even a single
     change to Qt configuration options may make your build binary incompatible
     with another build. And even if you convince the user to isolate different
     DLLs (using LIBPATHSTRICT and BEGINLIBPATH) it will create another major
     problem: two different Qt applications will load two different copies of Qt
     into memory which will create an unnecessary overhead by doubling the
     amount of used system resources.

     In order to nicely solve this problem, netlabs.org provides the official
     binary builds of the Qt library distributed as WPI archives which are
     described in the next section.



USING OFFICIAL BINARY QT ARCHIVES

For your convenience, netlabs.org provides the following binary distributions
of the Qt library (where X_Y_Z is the Qt version number) distributed as WPI
archives:

  qt-lib-X_Y_Z.wpi   - Runtime DLLs and binaries ("lib" archive)
  qt-dev-X_Y_Z.wpi   - Development libraries, tools and headers ("dev" archive)

These archives are called the official binary archives of the Qt library for
OS/2. An official binary archive contains the most complete Qt build that
enables all features of the Qt library and includes all standard Qt plugins
implemented for the OS/2 platform at the time of the release.

The "lib" archive contains the release versions of DLLs (and may contain a few
helper binaries) necessary to run applications created using the Qt framework.
This package is usually installed by end users together with Qt applications
they want to use.

The "dev" archive contains pre-built release versions of import libraries and
a complete set of C++ include headers of the Qt framework. This package is used
by developers and porters of Qt applications to build release versions of the
applications that are binary compatibie with the Qt runtime provided by the
official "lib" archive described above. Using the "dev" package requires the
same environment as described in section "SETTING UP THE ENVIRONMET" above.

Please note again that the "dev" archive is intended to make a final release
build of the Qt application which you do when you decide to ship a new version
to the end users -- makes sure that the deployed application will share the same
Qt runtime with other Qt applications. However, for daily work it is highly
recommended that you build the debug version of the Qt library yourself (using
the full source code ZIP archive or directly from SVN) as described in section
"COMPILING QT").

Besides the "lib" and the "dev" archives, the following official archives exist
that you may also find useful:

  qt-examples-X_Y_Z.wpi  - Demo and example sources ("examples")

The "examples" archive contains the source code and compiled binaries of the
demo and example applications shipped with Qt. They serve as a good
demonstration of the Qt library features and it is recommended to look at them.
The binaries are compiled using the official "lib" archive. Please note that
some demos and examples may miss from the arcvhice since not all features have
been implemented in the OS/2 version of Qt yet.

NOTE:

     All .DLL and .EXE files of the official binary build contain a DESCRIPTION
     string with the vendor field set to "netlabs.org" (by contrast, all custom
     Qt builds will set the vendor field to what the USER environment variable
     contains or to "anonymous" if USER is not set). Please note that you must
     NOT set vendor to "netlabs.org" when creating your own builds of the Qt
     library because it will make it difficult to identify various distributions
     and track possible problems with the builds.



QMAKE CONFIG OPTIONS

The following CONFIG options of the qmake tool have a special meaning in OS/2:

  windows           Turns on generation of PM (WINDOWAPI) executables. By
                    default, this option is set for release builds that link
                    to the Qt GUI library.

  console           Turns on generation of text mode (WINDOWCOMPAT) executables.
                    By default, this option is set when setting the "windows"
                    option is not appropriate (see above).

In addition, qmake recognizes the following OS/2-specific CONFIG options:

  map               Turns on generation of the .map files for executables and
                    DLLs. This option is set by default.

  exepack           Turns on compression for executables and DLLs. The option is
                    turned on by default for release builds if configure.cmd
                    finds a compression tool (LxLite) in PATH.

  highmem           Turns on high memory usage for dynamically allocated memory
                    in DLLs and executables. When this option is set, a special
                    compiler flag (-Zhigh-mem for GCC) is used to enable high
                    memory support in the C library (LIBC). This option is set
                    by default so that all Qt DLLs and Qt applications built
                    with qmake are enabled for high memory. Note that high
                    memory support must be enabled for all LIBC-based DLLs
                    linked to the executable as well as for the executable
                    itself: high memory usage will be disabled if one of them
                    votes against it.

  export_all        Cause the linker to export all public symbols in a generated
                    DLL. By default (when this option is absent), only the
                    symbols marked with the __declspec(dllexport) compiler
                    directive in the source files.



PRINTING SUPPORT

Starting with version 4.6.2, Qt for OS/2 supports printing through the CUPS
framework (provided that this support is enabled when building Qt, see the
respective sections in the beginning of this document). The OS/2 implementation
of the CUPS framework is provided by the eCUPS package available at
http://svn.netlabs.org/ecups/.

The Qt Runtime detects the presence of eCUPS in the system on the fly and talks
to the CUPS daemon directly, bypassing the standard OS/2 printing subsystem.
This means that in order to print from Qt applications, you don't need to create
and configure printer objects using the standard OS/2 system printer setup
procedure -- you only need to install eCUPS and configure your printers in
there. Please refer to the eCUPS user manual to obtain the detailed instructions
on how to configure CUPS printers.



ENVIRONMENT VARIABLES

The Qt library recognizes a number of OS/2-specific environment variables that
affect its functionality at runtime. The table below lists these variables and
their meaning:

  QT_PM_NO_DIVE             If set, Qt will not use DIVE (direct interface video
                            extensions) for painting widgets even if DIVE (which
                            provides a much faster painting speed than the
                            regular GPI approach) is available. Currently, this
                            is the default setting if the Panorama video driver
                            is detected because its DIVE implementation contains
                            a number of bugs.

  QT_PM_DIVE=<mode>         Enables using DIVE for painting widgets. <mode> is
                            one of:

                              - FB (direct framebuffer access, which is the
                                fastest mode but causes the curruption of the
                                screen under the software mouse pointer due to
                                the limitation of DIVE). If this mode is not
                                available, BLIT will be used (see below).

                              - FBSWM (the same FB but hides the mouse pointer
                                before painting which introduces mouse flicker
                                and may be a bit slower than the raw FB).

                              - BLIT (slower than both FB and FBSWM but prevents
                                screen corruption under the mouse pointer and
                                does not produce a mouse pointer flicker
                                effect).

                            This variable is ignored if QT_PM_NO_DIVE is set. If
                            neither this nor the QT_PM_NO_DIVE variable is set,
                            the FBSWM mode is used by default (unless the
                            current video driver is Panorama, see above).

  QT_PM_NO_SOUND_SHARE      If set, Qt will open the audio device in exclusive
                            only one sound may be played on the computer at a
                            time. This mode is recommended for some sound cards
                            when using the Uniaud audio driver as it is known to
                            have problems with simultaneous playback. In current
                            Qt builds, this is the default behavior if neither
                            this nor the QT_PM_SOUND_SHARE variable is set.

  QT_PM_SOUND_SHARE         The opposite to the above. If set, Qt will open the
                            audio device in shared mode. This variable is
                            ignored if QT_PM_NO_SOUND_SHARE is set.

  QT_PM_NO_REGISTRY         If set, Qt will not use the Open32 registry to store
                            application settings with QSettings. Instead, plain
                            text INI files will be used for both NativeFormat
                            and IniFormat. Due to a number of problems in the
                            Open32 registry implementation (that may easily lead
                            to registry corruption), this is the default
                            behavior if neither this nor the QT_PM_REGISTRY
                            variable is set.

  QT_PM_REGISTRY            The opposite to the above. If set, Qt will use the
                            Open32 registry to store application settings. This
                            variable is ignored if QT_PM_NO_REGISTRY is set.

  QT_PM_NO_SYSTEM_LOCALE    If set, Qt will ignore the regional settings from
                            the system locale object found in the Country
                            Palette located in the System Setup folder and will
                            take them from the internal Qt locale database
                            according to the current country and language
                            settings. Due to the fact that this internal Qt
                            database usually has a better representation of the
                            regional settings, this is the default behavior if
                            neither this nor the QT_PM_SYSTEM_LOCALE variable is
                            set.

  QT_PM_SYSTEM_LOCALE       The opposite to the above. If set, Qt will use the
                            regional settings as found in the default locale
                            object set the Country Palette.  This variable is
                            ignored if QT_PM_NO_SYSTEM_LOCALE is set.

  LANG                      This variable can be used to override the default
                            country and language used in the Qt application both
                            for regional settings and for translations. The
                            format of the value is "ll_CC" where <ll> is the
                            two-letter ISO language code and <CC> is the two-
                            letter ISO country code. Note that if this variable
                            is not set, Qt will derive the language and country
                            from the system country code specified in the
                            COUNTRY statement of CONFIG.SYS.



COMMAND LINE OPTIONS

Any Qt executable recognizes a number of command line options that may change
the behavior of the Qt application. Here are the most interesting ones:

  -style <name>             Changes the default Qt widget style (theme) to a
                            style with the given name. The buiil-in styles which
                            are always available in the official build include:
                            "windows" (currently, the default on OS/2), "motif",
                            "cde", "plastique" and "cleanlooks". Other styles
                            may be also provided by the style plugins.

  -graphicssystem <name>    Changes the graphics system used to paint widgets.
                            On OS/2, only two values are supported: "native"
                            (the default one) and "raster". The "native" system
                            uses DIVE (direct interface video extensions) when
                            it is available. If DIVE is not available or if it
                            is disabled (see the QT_PM_NO_DIVE environment
                            variable description for details), the "raster"
                            system will be automatically selected as a fallback.



CURRENT LIMITATIONS

  1. configure.cmd is does not build demos and examples by default (to save
     time). They may be built by hand, as described above.

  2. configure.cmd does not understand any command line options yet. If you want
     to customize your build of the Qt library (which is normally not
     recommended and not supported), you may try to modify configure.cmd itself.

  3. OS/2 bitmap fonts are not supported. Use TTF or Type1 (PFB) fonts with Qt.

  4. No native PM style, but Qt will use fonts and colors from the current
     OS/2 theme. Hint: if your default OS/2 font is "WarpSans", install the
     "Workplace Sans" TTF font from Alex Taylor to get more native look & feel.
     It is recommended to install version 0.7 of the Normal face and version 0.3
     of the Bold face which you can find here:

       http://users.socis.ca/~ataylo00/creative/fonts/workplace/

  5. QProcess: when starting PM applications from text-mode applications, the
     returned PID is a PID of the intermediate cmd.exe process, not the target
     application.

  6. The following classes are not available due to their rare usage or low
     importance on the OS/2 platform: QSharedMemory, QSystemSemaphore,
     QInputContext. On the source level, a number of macros is defined to
     reflect this, respectively: QT_NO_SYSTEMSEMAPHORE, QT_NO_SHAREDMEMORY,
     QT_NO_IM. Normally, Qt applications use these macros in the form of
     "#fndef QT_NO_SOMEFEATURE" to isolate the relevant parts of the code that
     uses these classes so that the application still builds when the
     corresponding feature is missing.

  7. No qt3support module. This functionality is rarely necessary in mature
     real life Qt applications and has low priority. In the code, it is
     reflected by the absense of the QT3_SUPPORT macro.

  8. The following features are missing (either because of the lack of the
     required support from the system side or because of the rare usage):

     - IPV6 support in the network module (QT_NO_IPV6 is defined).
     - OpenSSL support in the network module (QT_NO_OPENSSL is defined).
     - phonon module (QT_NO_PHONON is defined).
     - multimedia module (QT_NO_MULTIMEDIA is defined).
     - OpenGL module (QT_NO_OPENGL is defined).
     - declarative module (QT_NO_DECLARATIVE is defined).
     - tablet support (QT_NO_TABLET is defined).

  See the project roadmap for more information on the current progress and
  future plans:

    http://svn.netlabs.org/qt4/roadmap

  Feel free to request new features and report bugs using the project bug
  tracker abaialble at:

    http://svn.netlabs.org/qt4/report