| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
| |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3
- Removed LICENSE.GPL
Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2
Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
|
| |
|
|
|
|
|
|
|
|
| |
Instead of having the application delegate set up a UIWindow and root
view-controller, we move the responsibility to QScreen, since in a multi
screen scenario we will need one UIWindow per screen, as well as one
root viewcontroller per window.
Change-Id: If5b0d44b8f8a697d830b33b4fe420bff56a7629b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
|
|
|
|
|
|
| |
We might have more of them in a multi-screen setup or when implementing
support for modal windows using sub-viewcontrollers.
Change-Id: Ibe98273a13af981fffe2704a2c05bfd9d3f3e9e0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
| |
We only control the application delegate in the wrapped case anyways,
so QIOSApplicationDelegate is good enough for our use.
Change-Id: Ib738592dc306c5b6652632b9ae4dab431639a89a
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As it stood, we always relied on the root view controller
being a QIOSViewController if isQtApplication() returned
true. For mixed application, this might not always be true
as native code can choose to replace the root view controller
at times, or even rip it out, and place it as a child of
another (e.g UISplitViewController).
This change will give an extra protection against that.
Change-Id: I0cb85796a8b82f9037c32f9e85e04e1dc7aad8e2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the typical Qt app the developer will have an existing main() that
looks something like:
int main(int argc, char *argv[])
{
QGuiApplication app(argc, argv);
return app.exec();
}
To support this, we provide our own 'main' function in the
qtmain static library that we link into the application, which calls
UIApplicationMain and redirects to the 'main' function of the application
after the event loop has started spinning. For this to work, the applications
'main' function needs to manually be renamed 'qt_main' for now. In a later
patch, this renaming will happen automatically by redefining main from either a
header file, or more likely, from the Makefile created by qmake.
For the case of an iOS developer wanting to use Qt in their existing app
the main will look something like:
int main(int argc, char *argv[])
{
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
This is supported right now by just linking in libqios.a without libqiosmain.a.
QGuiApplication should then be created e.g inside the native apps application
delegate (but QGuiApplication::exec should not be called).
In the future, we plan to but use a wrapper library that
brings in all the Qt dependencies into one single static library. This library will
not link against qtmain, so there won't be a symbol clash if the -ObjC linker option
is used. We should then add the required magic to the future Objective-C convenience
wrapper for QML to bring up a QGuiApplication, which would allow using Qt from
storyboards and NIBs. This would also be the place to inject our own
application delegate into the mix, while proxying the delegate callbacks
to the user's application delegate.
Change-Id: Iba5ade114b27216be8285f36100fd735a08b9d59
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
This change will let you call QApplication::exec() instead of UiApplicationMain
from main. Also added an application delegate that we will need sooner
or later for catching application activation events.
Change-Id: I4edba5ce2059a804782d67c160755fc0e2e5267d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
