For pure QNX (non-BlackBerry) devices, the path to the QML
files are decided by the user. Only adjust the path for BlackBerry
devices.
Change-Id: I909ed0a06bc6985a5a353aab61bda395afcfb7aa
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Reviewed-by: Mehdi Fekari <mfekari@rim.com>
This change makes QmlApplicationViewer applications find their qml
resources also in non-installed builds, regardless of the current
working directory.
On non-unix platforms applicationDirPath() is not used at all, and on
unix, it's used only for searching applicationDirPath/../path, which
is valid only after install. In-source or shadow-built apps find
their qml resources only if working directory == application
(executable) directory.
Path may refer to subdirectory in application directory. On windows,
non-installed application binary can also reside in /Release or
/Debug, so its resources need to be searched under parent directory
as well.
Change-Id: I81f602406787c20830c656fd5dffd11aa9b4afba
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
Reuse the QML application class provided by the standard QtQuick1
template.
Extends qtquickapp/qmlapplicationviewer/qmlapplicationviewer.cpp with
code paths for Q_OS_QNX
Change-Id: I04a283078299f662d630d9387cedc65100f545a0
Reviewed-by: Mehdi Fekari <mfekari@rim.com>
Reviewed-by: Alessandro Portale <alessandro.portale@digia.com>
Qt Creator's support for Symbian was at its peak in version
2.4.x. Nobody really verified it in Qt Creator 2.5 or 2.6.
It is most likely rotten. Let's remove it!
Also, the Symbian support code was spread throughout the whole
Qt Creator code base. The plugin interfaces evolved in the
meantime and target platforms like Android or QNX have 99% of
their code in separate plugins.
In case anyone wants to revive Symbian support in Qt Creator,
please create a plugin for it.
Change-Id: I56a758a3e2fd5b8c64d9aeb8f63d8e916c4883be
Reviewed-by: Alessandro Portale <alessandro.portale@nokia.com>
This patch makes a "QmlApplicationViewer" based application from
the Qt Quick app wizard buildable and runnable with Qt5. Note,
that this is still QtQuick 1.1. We are still missing a QtQuick 2.0
based pendant of QmlApplicationViewer.
In addition (separate patch), we may want to tweak the wizard
flags in a way that the wizard allows to create a "Qt Quick 1"
application for a Qt5 target. (Or perhaps we explicitly do not
want that, because we want the developer to use QtQuick 2 with
Qt5?)
Change-Id: Ie3fc8a77a1ff4fba3244f2047d2685c570014356
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
Reviewed-by: Alessandro Portale <alessandro.portale@nokia.com>
Getting the #include directives ready for Qt5. This includes the
new-project wizards.
Change-Id: Ia9261f1e8faec06b9285b694d2b7e9a095978d2b
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
Commit d687d11240 unfortunately caused
two severe regressions for MeeGo:
QTCREATORBUG-6473: The application creates two QDeclarativeViews
QTCREATORBUG-6490: QDView functions inaccessible. Existing apps broken
This commit removes most of d687d11240
just leaving the boosted QApplication. Now, QmlApplicationViewer *is*
again the QDeclarativeView.
Change-Id: I219540353ff4dd1061221d6cbe69ce9a58500e91
Task-Id: QTCREATORBUG-6473
Task-Id: QTCREATORBUG-6490
Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
There is no good reason to break the Qt coding style, here. The
strings "%1/../Resources/%2" and "%1/../%2" are Latin1 aswell
as Ascii.
Change-Id: Idbf3b7650fd650f93293496839fec4d21626cd0b
Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
Add support for the meego booster. This requires
- Telling qmake to link to right libraries
- Exporting main method
- using QApplication, QDeclarativeView objects from cache
- avoiding QCoreApplication::applicationDirPath()
To keep compatibility, QmlApplicationViewer is still derived from QDeclarativeView.
However, if the app booster is used it merely acts as a proxy to the view from the
cache.
Change-Id: I83e285d9ca3c2cfd86d1711e1fb93c72589ba14d
Reviewed-on: http://codereview.qt.nokia.com/3730
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Alessandro Portale <alessandro.portale@nokia.com>
Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>
Use QString().arg() instead of + , which might be undefined if the
user adds QT_USE_FAST_CONCATENATION to the .pro file.
Task-number: QTCREATORBUG-5796
Change-Id: Ic842cae650c8fa898d72065f3a1c672f5eb893d4
Reviewed-on: http://codereview.qt.nokia.com/2939
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: hjk <qthjk@ovi.com>
This can be confusing, since there is also the switch in the qmake step,
which is on by default for debug builds too. However, if one disables it
you expect that debugging has in fact been disabled.
Change-Id: Ia15cf1e245311fd97dcbaef3533a077fc8da25d2
Reviewed-on: http://codereview.qt.nokia.com/2511
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Alessandro Portale <alessandro.portale@nokia.com>
Reviewed-by: Christiaan Janssen <christiaan.janssen@nokia.com>
As of Qt 4.8 the observer and jsdebugger services are part of Qt. This
means the following changes are necessary in Qt Creator:
* Do not link to the QmlJSDebugger library.
* Do not create JSDebuggerAgent and QDeclarativeViewObserver instances
in the QmlApplicationViewer and use the new declarative_debug CONFIG
option to enable those services in Qt. This is done automatically
for debug builds.
* Point out the QML Debugging Library and the QML Observer are "Not
needed" in the Qt options page.
* Change the label in qmake options from "Link QML debugging library" to
"Enable QML debugging". It still remains as a way to enable this
functionality in release builds or for QtQuick applications not based
on Qt Creator's template.
* Rely on qmlviewer for debugging QML UI projects rather than the
observer, which is no longer necessary.
Reviewed-by: Kai Koehne
This makes sure it gets deleted together with the QmlApplicationViewer,
rather than probably not at all when no parent is specified for the
viewer (which is the default).
Reviewed-by: Alessandro Portale
Reviewed-by: Christiaan Janssen
