qtcreator.qdoc

    \note On Mac OS X, press \key{Cmd+K} instead of \key{Ctrl+K}.

*/


/*!
    \contentspage index.html
    \previouspage creator-navigation.html
    \page creator-session.html
    \nextpage creator-version-management.html

    \title Session Management in Qt Creator

    In Qt Creator, a session is a collection of:

    \list
        \o Open projects with their dependencies
        \o Open editors
        \o Breakpoints and watches
        \o Bookmarks
    \endlist

    When you run Qt Creator, you enter a default session. You can create a new
    session using the \gui{Session Manager...} option, available in the
    \gui{File > Session} menu.


    \image qtcreator-session-manager.png


    To switch between sessions, select \gui{File > Session}. If you do not
    create and select any session, Qt Creator always uses the default
    session.

    \image qtcreator-session-menu.png

    When you launch Qt Creator, a list of your sessions is
    displayed on the \gui{Welcome screen}.

    \image qtcreator-welcome-session.png

*/


/*!
    \contentspage index.html
    \previouspage creator-qt-for-symbian.html
    \page creator-debugging.html
    \nextpage creator-version-control.html

    \title Qt Creator and Debugging


    \section1 About Debugging with Qt Creator

    Qt Creator does not have its own debugger. Instead, it provides a graphical
    frontend to various debugger engines:

    \table
        \header
            \o Platform
            \o Compiler
            \o Debugger Engine
        \row
            \o Linux, Unixes, Mac OS
            \o gcc
            \o GNU Symbolic Debugger (gdb)
        \row
            \o Windows/MinGW
            \o gcc
            \o GNU Symbolic Debugger (gdb)
        \row
            \o Windows
            \o Microsoft Visual C++ Compiler
            \o Debugging Tools for Windows/Microsoft Console Debugger (CDB)
    \endtable

    The frontend allows you to:
    \list
        \o Go through a program line-by-line or instruction-by-instruction.
        \o Interrupt running programs.
        \o Set breakpoints.
        \o Examine the contents of the call stack, local and global variables, etc.
    \endlist

    Qt Creator displays the raw information provided by the engine
    in a clear and concise manner. This simplifies the debugging process.

    Qt Creator comes with generic IDE functionality: stack view, views for locals and
    watchers, registers, etc. In addition, Qt Creator includes features to make
    debugging Qt-based applications easy. The debugger frontend understands the
    internal layout of several Qt classes such as QString, the QTL containers,
    and most importantly QObject (and classes derived from it), as well as
    most containers of the C++ Standard Library. Therefore, the debugger can
    present their contents in a useful way.


    \section1 Debugger Engine Installation Notes

    \table
        \header
            \o Debugger engine
            \o Notes
        \row
            \o Gdb
            \o Requires gdb version 6.8 on Linux. On Mac OS X, please install the latest available Xcode
               available for your OS version.
        \row
            \o Debugging tools for Windows
            \o Using this engine requires you to install the
               \e{Debugging tools for Windows}
               \l{http://www.microsoft.com/whdc/devtools/debugging/installx86.Mspx}{32-bit}
               or
               \l{http://www.microsoft.com/whdc/devtools/debugging/install64bit.Mspx}{64-bit}
               package (Version 6.11.1.404 for the 32-bit or the 64-bit version of Qt Creator, respectively),
               which is freely available for download from the
               \l{http://msdn.microsoft.com/en-us/default.aspx}
               {Microsoft Developer Network}.

               The pre-built \e{Qt SDK for Windows} makes use
               of the library if it is present on the system. When building Qt
               Creator using the Microsoft Visual C++ Compiler, the
               \c{"%ProgramFiles%\Debugging Tools for Windows"} path is
               checked to ensure that all required header files are there.
    \endtable


    \section1 Interaction with the Debugger

    In \gui Debug mode, several dock widgets are used to interact with the
    program you are debugging. The frequently used dock widgets are visible by
    default; the rarely used ones are hidden. To change the default settings,
    select \gui Debug and then select \gui View.

    \image qtcreator-debug-view.png

    Here, you can lock or unlock the location of your views as well as display
    or hide them. Among the views you can display are \gui Breakpoints,
    \gui Stack, \gui Thread, \gui Modules, \gui Registers, \gui Disassembler,
    and \gui Debugger. The position of your dock widgets is saved for future
    sessions.


    \section2 Usage of the Debugger

    To start a program under the debugger's control, select the \gui{Debug}
    menu and \gui{Start Debugging}, or press \key{F5}. Qt Creator
    checks whether the compiled program is up-to-date, rebuilding it if
    necessary. The debugger then takes over and starts the program.

    \note Starting a program in the debugger can take a considerable amount of
    time, typically in the range of several seconds to minutes if complex
    features (like QtWebKit) are used.

    Once the program starts running, it behaves and performs as usual.
    The user can interrupt a running program by selecting
    \gui {Interrupt} from the \gui{Debug} menu. The program is automatically
    interrupted as soon as a breakpoint is hit.

    Once the program stops, Qt Creator:

    \list
        \o Retrieves data representing the call stack at the program's current
           position.
        \o Retrieves the contents of local variables.
        \o Examines \gui Watchers.
        \o Updates the \gui Registers, \gui Modules, and \gui Disassembler
           views.
    \endlist


    You can use the debugger views to examine the data in more detail.

    To finish debugging, press \key{Shift+F5}. A line of code can be executed
    as a whole with \key F10; to step into a function or a sub-function, use
    \key F11. Alternatively, you can continue running the program with \key F5.
    It is also possible to continue executing the program until the current
    function completes or jump to an arbitrary position in the current
    function.


    \section2 Breakpoints

    Breakpoints are shown in the \gui{Breakpoints} view which is enabled
    by default. This view is also accessible when the debugger and the program
    being debugged is not running.

    A breakpoint represents a position or sets of positions in the code that,
    when executed, interrupts the program being debugged and passes the
    control to the user. The user is then free to examine the state of the
    interrupted program, or continue execution either line-by-line or continuously.

    Typically, breakpoints are associated with a source code file and line, or
    the start of a function -- both are allowed in Qt Creator.

    Also, the interruption of a program by a breakpoint can be restricted with
    certain conditions.

    You can set a breakpoint:

    \list
       \o At a particular line you want the program to stop -- click on the
          left margin or press \key F9 (\key F8 for Mac OS X).
       \o At a function that you want the program to interrupt -- enter the
          function's name in \gui{Set Breakpoint at Function...} in
          \gui Debug menu.
    \endlist

    You can remove a breakpoint:

    \list
        \o By clicking on the breakpoint marker in the text editor.
        \o By selecting the breakpoint in the breakpoint view and pressing
           \key{Delete}.
        \o By selecting \gui{Delete Breakpoint} from the breakpoint's context
           menu in the \gui Breakpoints view.
    \endlist

    Breakpoints can be set and deleted before the program has actually started
    running or while it is running under the debugger's control. Also,
    breakpoints are saved together with a session.


    \section2 Stack

    When the program being debugged is interrupted, Qt Creator displays the
    nested function calls leading to the current position as a \e call stack
    trace. This stack trace is built up from \e{call stack frames}, each
    representing a particular function. For each function, Qt Creator tries
    to retrieve the file name and line number of the corresponding source
    file. This data is shown in the \gui Stack view.

    \image qtcreator-debug-stack.png

    Since the call stack leading to the current position may originate or go
    through code for which no debug information is available, not all stack
    frames have corresponding source locations. These frames are
    grayed out in the \gui Stack view.

    If you click on a frame with a known source location, the text editor
    jumps to the corresponding location and updates the \gui{Locals and Watchers}
    view, making it seem like the program was interrupted before entering the
    function.


    \section2 Threads

    If a multi-threaded program is interrupted, the \gui Thread view  or the
    combobox named \gui Thread in the debugger's status bar can be used to
    switch from one thread to another. The \gui Stack view adjusts itself
    accordingly.


    \section2 Modules View and Source Files View

    These views display the debugger's idea of the components of the
    application. By default, both views are hidden.


    \section2 Disassembler View and Registers View

    By default, both \gui Disassembler and \gui Registers view are hidden.
    The \gui Disassembler view displays disassembled code for the current
    function; the \gui Registers view displays the current state of the CPU's
    registers. Both views are useful for low-level commands such as
    \gui{Step Single Instruction} and \gui{Step Over Single Instruction}.

    \section2 Locals and Watchers

    Whenever a program stops under the control of the debugger, it retrieves
    information about the topmost stack frame and displays it in the
    \gui{Locals and Watchers} view. This typically includes information about
    parameters of the function in that frame as well as the local variables.

    Compound variables of struct or class type are displayed as
    "expandable" in the view. Click on the "+" to expand the entry and show
    all members. Together with the display of value and type, the user can
    examine and traverse the low-level layout of an object's data.


    \table
        \row
            \i  \bold{Note:}

        \row
            \i  Gdb, and therefore Qt Creator's debugger works for optimized
                builds on Linux and Mac OS X. However, optimization may lead
                to re-ordering of instructions or sometimes even complete
                removal of some local variables. In this case, the
                \gui{Locals and Watchers} view may show unexpected data.

        \row
            \i  The debug information provided by gcc does not include enough
                information about the time when a variable is initialized.
                Therefore, Qt Creator can not tell whether the contents of a
                local variable contains "real data", or "initial noise". If a
                QObject appears uninitialized, its value is reported as
                "out of scope". However, not all uninitialized objects can be
                recognized as such.
    \endtable


    The \gui{Locals and Watchers} view also provides access to the most
    powerful feature of the debugger: comprehensive display of data belonging
    to Qt's basic objects. To enable this feature, select \gui{Use
    debugging helper} from the \gui Debug menu.The
    \gui{Locals and Watchers} view is re-organized to provide a high-level
    view of the objects. For example, in case of QObject, instead of displaying
    a pointer to some private data structure, you see a list of children,
    signals and slots.

    Similarly, instead of displaying many pointers and integers, Qt Creator's
    debugger displays the contents of a QHash or QMap in an orderly manner.
    Also, the debugger displays access data for QFileInfo and provides
    access to the "real" contents of QVariant.

    The \gui{Locals and Watchers} view can be used to change the contents of
    variables of simple data types such as \c int or \c float when the program
    is interrupted. To do so, click on the \gui Value column, modify the value
    with the inplace editor, and hit \key Enter (or \key Return).

    \note The set of watched items is saved in your session.


    \section1 Debugging Helper Library with C++

    While debugging, Qt Creator dynamically loads a helper library into your
    program. This helper library enables Qt Creator to pretty print Qt and STL
    types. The Qt SDK package already contains a prebuilt debugging helper
    library. To create an own debugging helper library, select \gui{Options}
    from the \gui{Tools} menu, and go to the \gui{Qt4 > Qt Versions} pane. As
    the internal data structures of Qt can change between versions, the debugging
    helper library is built for each Qt version.


    \section1 Debugging Helper Library with Python

    Using a gdb version that has Python scripting available it is possible to
    use Debugging Helpers also for user defined types. All that is needed is
    to define one Python function per user defined type in .gdbinit.

    The function's name has to be qdump__NS__Foo where  NS::Foo is the class
    or class template to be examined. Nested namespaces are possible.

    Qt Creator's debugger integration will call this function whenever it
    wants to display an object of this type. The function gets passed two
    parameters, 'd' of type 'Dumper', and 'item' of type 'Item'. The function
    itself has to feed the Dumper object with certain information that
    are used to build up the object and it's children's display in the
    Locals-and-Watchers view.


    Example:

    \code
    def qdump__QVector(d, item):
        d_ptr = item.value["d"]
        p_ptr = item.value["p"]
        alloc = d_ptr["alloc"]
        size = d_ptr["size"]

        check(0 <= size and size <= alloc and alloc <= 1000 * 1000 * 1000)
        check(d_ptr["ref"]["_q_value"] > 0)

        innerType = item.value.type.template_argument(0)
        d.putItemCount(size)
        d.putNumChild(size)
        if d.isExpanded(item):
            p = gdb.Value(p_ptr["array"]).cast(innerType.pointer())
            d.beginChildren([size, 2000], innerType)
            for i in d.childRange():
                d.safePutItem(Item(p.dereference(), item.iname, i))
                p += 1
            d.endChildren()
    \endcode

    \section2

    The 'Item' Python class is a thin wrapper around values corresponding to one
    line in the Locals-and-Watchers view. Its members are the following:

    \list

    \o \gui{__init__(self, value, parentiname, iname, name = None)} - A
       constructor. The object's internal name is created by concatenating
       \a parentiname and \a iname. If \c None is passed as \a name, a
       serial number is used.

    \o \gui{value} - An object of type gdb.Value representing the value to
        be displayed.

    \o \gui{iname} - The internal name of the object, i.e. a dot-separated
    list of identifiers, corresponding to the position of the object's
    representation in the view.

    \o \gui{name} - An optional name. If given, it will be used in the
    \gui{name} column of the view. If not, a simple number in brackets
    will be used instead.

    \endlist


    \section2

    For each line in the Locals and Watcher view, a string like the following
    needs to be created and channeled to Creator's debugger plugin.
    \code
    "{iname='some internal name',
      addr='object address in memory',
      name='contents of the name column',
      value='contents of the value column',
      type='contents of the type column',
      numchild='number of children',        // zero/nonzero is sufficient
      childtype='default type of children', // optional
      childnumchild='default number of grandchildren', // optional
      children=[              // only needed if item is expanded in view
         {iname='internal name of first child',
          ... },
         {iname='internal name of second child',
          ... },
         ...
      ]}"
    \endcode

    While in theory, this string can be build up entirely manually, it is
    easier to employ the 'Dumper' Python class for that purpose. It contains
    a complete framework to take care of the 'iname' and 'addr' fields,
    to handle children of simple types, references,
    pointers, enums, known and unknown structs as well as some
    convenience method to handle common situations.

    The 'Dumper' members are the following:

    \list

    \o \gui{__init__(self)} - Initializes the output to an empty string and
        empties the child stack.

    \o \gui{put(self, value)} - Low level method to directly append to the
        output string.

    \o \gui{putCommaIfNeeded(self)} - Appends a comma if the current output
        ends in '}', '"' or ']' .

    \o \gui{putField(self, name, value)} - Appends a comma if needed, and a
         name='value' field.

    \o \gui{beginHash(self)} - Appends a comma if needed and a '{', marking
        the begin of a set of fields.

    \o \gui{endHash(self)} - Appends a '}', marking the end of a set of
        fields.

    \o \gui{beginItem(self, name)} - Starts writing a field by writing \c {name='}.

    \o \gui{endItem(self)} - Ends writing a field by writing \c {'}.

    \o \gui{beginChildren(self, numChild_ = 1, childType_ = None, childNumChild_ = None)}
        - Starts writing a list of \a numChild children, with type
        \a childType_ and \a childNumChild grandchildren each. If \a numChild_
        is a list of two integers, the first one specifies the actual number
        of children and the second the maximum number of children to print.

    \o \gui{endChildren(self)} - Ends writing a list of children.

    \o \gui{childRange(self)} - Return the range of children specified in
        \c beginChildren.

    \o \gui{putItemCount(self, count)} - Appends a field  \c {value='<%d items'}
        to the output.

    \o \gui{putEllipsis(self)} - Appends fields
        \c {'{name="<incomplete>",value="",type="",numchild="0"}'}. This is
        automatically done by \c endChildren if the number of children to
        print is smaller than the number of actual children.

    \o \gui{putName(self, name)} - Appends a \c {name='...'} field.

    \o \gui{putType(self, type)} - Appends a field \c {type='...'} unless the
        \a type coincides with the parent's default child type.

    \o \gui{putNumChild(self, numchild)} - Appends a field \c {numchild='...'}
        unless the \a numchild coincides with the parent's default child numchild
        value.

    \o \gui{putValue(self, value, encoding = None)} - Append a file \c {value='...'},
        optionally followed by a field \c {valueencoding='...'}. The \a value
        needs to be convertiable to a string entirely consisting of
        alphanumerical values. The \a encoding parameter can be used to
        specify the encoding in case the real value had to be encoded in some
        way to meet the alphanumerical-only requirement.
        Currently the following encodings are supported:

        \list
            \o 0: unencoded 8 bit data, interpreted as Latin1.

            \o 1: base64 encoded 8 bit data, used for QByteArray,
                double quotes will be added.

            \o 2: base64 encoded 16 bit data, used for QString,
                double quotes will be added.

            \o 3: base64 encoded 32 bit data,
                double quotes will be added.

            \o 4: base64 encoded 16 bit data, without quotes (see 2)

            \o 5: base64 encoded 8 bit data, without quotes (see 1)

            \o 6: %02x encoded 8 bit data (as with \c QByteArray::toHex),
                double quotes will be added.

            \o 7: %04x encoded 16 bit data (as with \c QByteArray::toHex),
                double quotes will be added.
        \endlist

    \o \gui{putStringValue(self, value)} - Encodes a QString and calls
        \c putValue with the correct \a encoding setting.

    \o \gui{putByteArrayValue(self, value)} - Encodes a QByteArray and calls
        \c putValue with the corrent \a encoding setting.

    \o \gui{isExpanded(self, item)} - Checks whether the item with the
        internal name \c item.iname is expanded in the view.

    \o \gui{isExpandedIName(self, iname)} - Checks whether the item with the
        internal name \c iname is expanded in the view.

    \o \gui{putIntItem(self, name, value)} - Equivalent to
        \code
        self.beginHash()
        self.putName(name)
        self.putValue(value)
        self.putType("int")
        self.putNumChild(0)
        self.endHash()
        \endcode

    \o \gui{putBoolItem(self, name, value)} - Equivalent to
        \code
        self.beginHash()
        self.putName(name)
        self.putValue(value)
        self.putType("bool")
        self.putNumChild(0)
        self.endHash()
        \endcode

    \o \gui{pushOutput(self)} - Moves output string to a safe location
        from with it will be send to the frontend even if further operations
        raise exception.

    \o \gui{putCallItem(self, name, item, func)} -
        Uses gdb to call the function \a func on the value specified by
        \a {item.value} and output the resulting item. This function is
        not available when debugging core dumps and it is not available
        on the Symbian platform due to restrictions imposed by AppTRK.

    \o \gui{putItemHelper(self, item)} - The "master function", handling
        basic types, references, pointers and enums directly, iterates
        over base classes and class members of compound types and calls
        \c qdump__* functions whenever appropriate.

    \o \gui{putItem(self, item)} - Equivalent to
        self.beginHash()
        self.putItemHelper(item)
        self.endHash()

    \o \gui{safePutItemHelper(self, item)} - Calls \c putItemHelper(self, item).
        If an exception is raised, catch it, and replace all output produced by
        \c putItemHelper by \code
            self.putName(item.name)
            self.putValue("<invalid>")
            self.putType(str(item.value.type))
            self.putNumChild(0)
            self.beginChildren()
            self.endChildren() \endcode


    \o \gui{safePutItem(self, item)} - Equivalent to
        self.beginHash()
        self.safePutItemHelper(item)
        self.endHash()

    \endlist

    \section1 Walkthrough for the Debugger Frontend

    In our \l{Writing a Simple Program with Qt Creator}{TextFinder} example, we
    read a text file into QString and then display it with QTextEdit.
    Suppose you want to look at this QString, \c{line}, and see what
    data it actually stores. Follow the steps described below to place a
    breakpoint and view the QString object's data.

    \table
        \row
            \i \inlineimage qtcreator-setting-breakpoint1.png
            \i \bold{Setting a Breakpoint}

    \list 1
        \o Click in between the line number and the window border on the line
        where we invoke \l{http://doc.trolltech.com/qtextedit.html#plainText-prop}{setPlainText()}
        to set a breakpoint.
        \o Select \gui{Start Debugging} from the \gui{Debug} menu or press \key{F5}.
    \endlist

        \row
            \i \inlineimage qtcreator-setting-breakpoint2.png
            \i \bold{Viewing and removing breakpoints}

    Breakpoints are visible in the \gui{Breakpoints} view in
    \gui{Debug} mode. To remove a breakpoint, right-click on
    it and select \gui{Delete breakpoint} from the context menu.

        \row
            \i \inlineimage qtcreator-watcher.png
            \i \bold{Viewing Locals and Watchers}

    To view the contents of \c{line}, go to the \gui{Locals and
    Watchers} view.

    \endtable

    Suppose we modify our \c{on_findButton_clicked()} function to move back to
    the start of the document and continue searching once the cursor hits the
    end of the document. Adding this functionality can be done with the code
    snippet below:

    \code
    void TextFinder::on_findButton_clicked()
    {
        QString searchString = ui->lineEdit->text();

        QTextDocument *document = ui->textEdit->document();
        QTextCursor cursor = ui->textEdit->textCursor();
        cursor = document->find(searchString, cursor,
            QTextDocument::FindWholeWords);
        ui->textEdit->setTextCursor(cursor);

        bool found = cursor.isNull();

        if (!found && previouslyFound) {
            int ret = QMessageBox::question(this, tr("End of Document"),
            tr("I have reached the end of the document. Would you like "
            "me to start searching from the beginning of the document?"),
            QMessageBox::Yes | QMessageBox::No, QMessageBox::Yes);

            if (ret == QMessageBox::Yes) {
                cursor = document->find(searchString,
                    QTextDocument::FindWholeWords);
                ui->textEdit->setTextCursor(cursor);
            } else
                return;
        }
        previouslyFound = found;
    }
    \endcode

    However, if you compile and run this code, the application does not work
    correctly due to a logic error. To locate this logic error, step
    through the code using the following buttons:

    \image qtcreator-debugging-buttons.png

*/


/*!
    \contentspage index.html
    \previouspage creator-project-pane.html
    \page creator-cmake-support.html
    \nextpage creator-generic-projects.html

    \title CMake Support in Qt Creator

    Since Qt Creator 1.1, support for \c CMake project files is available.
    Qt Creator 1.3 supports the Microsoft Toolchain if the CMake version
    is at least 2.8.

    \section1 Opening CMake Projects

    To open a \c CMake project, select \gui Open from the \gui File menu and
    select the \c{CMakeLists.txt} file from your \c CMake project. A wizard
    guides you with the rest of the process. If the \c CMake project does
    not have an in-place build, Qt Creator lets you specify the directory in
    which the project is built (\l{glossary-shadow-build}{shadow build}).

    \image qtcreator-cmake-import-wizard1.png

    The screenshot below shows how you can specify command line arguments to
    \c CMake for your project.

    \image qtcreator-cmake-import-wizard2.png

    Normally, there is no need to pass any command line arguments for projects
    that are already built, as \c CMake caches that information.


    \section1 Building CMake Projects

    Qt Creator builds \c CMake projects by running \c make, \c mingw32-make, or
    \c nmake depending on your platform. The build errors and warnings are
    parsed and displayed in the \gui{Build Issues} output pane.

    By default, Qt Creator builds the \e{all} target. You can specify which
    targets to build in \gui{Project} mode, under \gui{Build Settings}.

    \image qtcreator-cmake-build-settings.png

    Qt Creator supports multiple build configurations. Also, the build
    directory can be modified after the initial import.

    \section1 Running CMake Projects
    Qt Creator automatically adds \gui{Run Configurations} for all targets
    specified in the \c CMake project file.

    Known issues for the current version can be found
    \l{Known Issues of version 1.3.80}{here}.
*/


/*!
    \contentspage index.html
    \previouspage creator-cmake-support.html
    \page creator-generic-projects.html
    \nextpage creator-external-library-handling.html

    \title Support for Generic Projects in Qt Creator

    Since Qt Creator 1.1, generic projects are supported in addition to
    \c qmake projects. In other words, you can import existing projects that do
    not use \c qmake or \c CMake and Qt Creator ignores your build
    system.

    This feature lets you use Qt Creator as a code editor. You can change the
    way your project is built by modifying the \c make command under
    \gui{Build Settings} in the \gui{Projects} mode.

    For a generic project, you have to manually specify which files belong to
    your project and which include directories/defines you want to pass to your
    compiler.


    \section1 Specifying Files

    The list of files for a generic project is specified in the \c{.files}
    file. When you first create a generic project, Qt Creator adds any
    files it recognizes to your project. To add or remove files later,
    edit the \c{.files} file in Qt Creator. Your project tree is refreshed
    when you save this file. You can also add or remove files from the context
    menu in the project tree.

    If you frequently need to update the \c{.files} file, we recommend the use
    of a small script that updates the files for you. If the
    file is modified externally, Qt Creator must be restarted for the changes
    to take effect.


    \section1 Specifying Include Paths

    The include paths are specified in the \c{.includes} file, one include
    path per line. The paths can be either absolute or relative to the
    \c{.includes} file.

    \section1 Specifying Defines

    The defines are specified in the \c{.config} file. This file is a regular
    C++ file, prepended to all your source files when they are being parsed.
    However, you should only use it to add lines like the following:

    \code
    #define NAME value
    \endcode


    \section1 Creating a Run Configuration

    Qt Creator cannot automatically determine which executable it should run.
    To set up a custom executable run configuration in the \gui Projects mode,
    use the \bold{Add} button. Here you can specify the name, executable, and
    some optional arguments. By default, the working directory is
    \c{$BUILDDIR} which should work fine.
*/


/*!
    \contentspage index.html
    \previouspage creator-external-library-handling.html
    \page creator-qt-for-symbian.html
    \nextpage creator-debugging.html

    \title Development of Qt for Symbian Based Applications

    Qt Creator 1.3 comes with preliminary support for development of
    applications using Qt for the Symbian Platform.

    \e{Note that this is highly experimental, and not intended for production use.
    The primary aim is to allow Symbian developers to familiarize themselves with Qt Creator
    and provide feedback that helps us improve Symbian support in future versions of
    Qt Creator.}

    Please provide us with feedback, using the mailing list or IRC, as described on the
    \l{http://qt.gitorious.org/qt-creator/pages/Home}{Qt Creator Development Wiki}.

    \section1 Getting Started with Symbian Based Applications

    You need the following software installed on your PC.
    Only Windows development is supported.

    \list
        \o \l{http://www.forum.nokia.com/main/resources/tools_and_sdks/S60SDK/}
            {S60 Platform SDK 3rd Edition FP1 or higher}
        \o \l{http://www.forum.nokia.com/main/resources/technologies/openc_cpp/}
            {Open C/C++ v1.6.0 or higher} (Install this to all S60 SDKs you plan to use Qt with.
            This is included in the Qt for Symbian binary installers.)
        \o Either the GCCE ARM Toolchain that is included in the S60 Platform SDKs, or
            RVCT 2.2 [build 686] or later (which is not available free of charge)
            (Your environment needs to find the compiler in the PATH.)
        \o Qt for Symbian 4.6.0, installed into the S60 SDKs you want to use

    \endlist

    For deploying and running applications on the device, you need the following:
    \list
        \o The Nokia USB drivers that come e.g. with PC Suite
        \o The \l{http://tools.ext.nokia.com/trk/}{App TRK} application for your device
    \endlist

    Running Qt based applications on real devices requires the following packages to be installed on
    your device. The packages can be found in the S60 SDK where you installed Open C/C++:
    \list
        \o nokia_plugin\\openc\\s60opencsis\\pips_s60_\<version\>.sis
        \o nokia_plugin\\openc\\s60opencsis\\openc_ssl_s60_\<version\>.sis
        \o nokia_plugin\\opencpp\\s60opencppsis\\stdcpp_s60_\<version\>.sis
    \endlist

    If you want to run your applications in the Symbian emulator, you also need to install
    Carbide.c++ v2.0.0 or higher.

    \section1 Setting Up Qt Creator

    When you run Qt Creator after installing the S60 Platform SDK and Qt for Symbian,
    the installed SDKs and their corresponding Qt versions are automatically detected.
    For each detected S60 SDK with Qt, a special entry is made in the Qt version management
    settings \gui{Tools > Options... > Qt4 > Qt Versions}.

    \e{Note that if you manually add a Qt version for Symbian, you must
    also manually specify the S60 SDK to use for this version.}

    \image qtcreator-qt4-qtversions-win-symbian.png

    If you want to run your applications in the Symbian emulator, you need to point Qt Creator
    to the Metrowerks Compiler that you want to use, by setting the \gui{Carbide Directory}
    of the Qt version to the corresponding Carbide.c++ installation directory.

    You can check what S60 SDKs and corresponding Qt versions are found in the
    \gui{Tools > Options... > Qt4 > S60 SDKs} preference page.

    \image qtcreator-qt4-s60sdks.png

    \section1 Building Your Project

    After installing all the prerequisites and checking the setup in Qt Creator as described
    above, you need to set up your project.
    \e{Note that the only supported build system for Qt for Symbian applications in Qt Creator
    is qmake.}

    Before you can build your project for the Symbian platform, you need to create build
    configurations for it.
    Open \gui{Projects mode} and make sure that your project is selected for editing in
    \gui{Edit Project Settings for Project ...}. Add debug and release build configurations
    for the Symbian target by selecting the corresponding Qt version from the build configuration
    \gui{Add} menu.

    \image qtcreator-symbian-add-buildconfiguration.png

    The created build configurations default to using the GCCE tool chain. If you want to build
    for the device using RVCT, or for the Symbian emulator using WINSCW, select \gui{Show Details}
    and change the tool chain in the \gui{General} section of the build configuration settings.

    Now you can switch to building your project for the device by selecting one of the
    new build configurations as the active configuration at the top of \gui{Projects mode}.

    \image qtcreator-symbian-change-buildconfiguration.png

    \section1 Running Your Project

    \section2 Running Your Project in the Emulator

    Similar to the build configuration setup for your project, you need to create a run
    configuration for running your project in the Symbian emulator:
    \list 1
        \o Switch to \gui{Projects mode}.
        \o Select \gui{Run Settings} > \gui{Add > YourApplication in Symbian Emulator}
    \endlist

    \image qtcreator-symbian-add-run-in-emulator.png

    To start your project in the emulator, select this run configuration as the active configuration
    at the top of \gui{Projects mode} window and press the run button.

    \image qtcreator-symbian-change-run-in-emulator.png

    \section2 Running Your Project on the Device

    To run your project on a real Symbian device, just add another run configuration in
    \gui{Projects mode} via \gui{Run Settings} > \gui{Add > YourApplication on Symbian Device}.

    \image qtcreator-symbian-add-runconfiguration.png

    \image qtcreator-symbian-details-runconfiguration.png

    In the details of the run configuration you can specify a certificate to use, and
    select one of the devices that you have currently attached to your computer.
    The only connection mode supported at the moment is USB in \e{PC Suite} mode.
    For actually running your application on the device, you need to set the device run configuration
    as the active configuration at the top of \gui{Projects mode}.
    Start the \gui{App TRK} application on your device and press the run button to create
    a package for your application, deploy, install and run it automatically on your device.

    \image qtcreator-symbian-change-runconfiguration.png

    \section2 Troubleshooting

    When something goes wrong, check the following:
    \list
        \o Did you build your application with a Qt version for Symbian?
        \o Are the settings for the Qt version you use to build your project correct? Check the
           path to the S60 SDK. Check also whether you need to specify the path to your compiler tool chain.
        \o Is the emulator/device run configuration selected as the active run configuration?
        \o Did you build using the right toolchain, i.e. WINSCW for running in the emulator,
            GCCE or RVCT for running on the device?
        \o If the emulator process could not be started, try closing Qt Creator and starting the
            application directly from your file manager. Having done this, Qt Creator should be
            able to run your projects in the emulator.
        \o Is the device connected via USB in \e{PC Suite} mode?
        \o Is App TRK running on the device, using the USB connection, and does it have status
            \e{connected}?
        \o Is your device detected and selected in the run configuration details?
    \endlist

    If neither of this helps to solve your problem, search the qt-creator@trolltech.com
    mailing list archives or provide feedback to us via the methods described on the
    \l{http://qt.gitorious.org/qt-creator/pages/Home}{Qt Creator Development Wiki}.

*/


/*!
    \contentspage index.html
    \previouspage creator-generic-projects.html
    \page creator-external-library-handling.html
    \nextpage creator-qt-for-symbian.html

    \title External Libraries

    The ability to recognize external libraries is not only important for the
    underlying build system, but also for Qt Creator itself. This ability
    allows Qt Creator to support code completion and syntax highlighting for
    external libraries as if they were part of the current project or the Qt
    library.

    The procedure of adding a library to a project depends on the type of
    project, which influences the build system used. The following sections
    describe the procedure required for each project type.


    \section1 qmake Projects (the default)

    Open your project file (\c{.pro}) from the \gui{Projects} pane. Then,
    follow the guidelines in the
    \l{http://doc.trolltech.com/latest/make-project-files.html#declaring-other-libraries}
    {Declaring other Libraries} section of the Qt documentation.

    Syntax completion and highlighting work once your project successfully builds
    and links against the external library.


    \section1 CMake Projects

    In CMake, libraries are usually detected using the \c{FIND_PACKAGE()}
    macro. A couple of them are already being shipped with CMake, they can be
    found in the \c{Modules} directory of your CMake installation. If you
    provide libraries on your own, you need to provide your own
    \c{FindFoo.cmake} file. Refer to the
    \l{http://vtk.org/Wiki/CMake_FAQ#Writing_FindXXX.cmake_files}{CMake FAQ}
    for details.

    As with \c qmake projects, syntax completion and highlighting work
    once you successfully build and link against the external library.


    \section1 Generic Projects

    If you import a project using the \e{Generic Projects} function, Qt Creator
    creates a file called \c{<projectname>.includes} in your project root
    directory. This file contains all project subdirectories for which Qt Creator
    found relevant headers. Add your include paths here.