| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
QPlatformBackingStore::endPaint does not take a QRegion parameter.
6ce6b8a378b0d97ba950240ffb048a4b7e485235 set the API, but the
platform implementations were not all synced up since then. There
was anyway no point in overriding beginPaint and endPaint on
platforms which don't need to do anything there. This fixes
clang warnings of the form
QXcbBackingStore::endPaint hides overloaded virtual function
Change-Id: Id6cd0fc2c831a34576ac2c73eeb0d5741d26e622
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our previous event loop integration had two unfortunate flaws:
1. We would call qt_user_main() from a timer, after returning from
didFinishLaunchingWithOptions. This had the effect of showing the
iOS application window long before the Qt application UI had been
set up, resulting in a 1-2 second flash of black/pink between the
launch image disappearing and the actual application showing.
2. We spun a nested event loop, where our implementation of the
different event loop modes did not perfectly match the Apple
implementation. This resulted in scrolling being busted in
some cases such as when showing the virtual keyboard for
Emoji characters.
These two issues have now been solved by calling the user's main()
from didFinishLaunchingWithOptions. Normally this would not work, as
the user's main would call QApplication::exec() at the end of their
main(), which would block and we would never return back from the
didFinishLaunchingWithOptions callback, resulting in no UI on screen.
We work around this by longjmp'ing out of QApplication::exec(), back
into didFinishLaunchingWithOptions, so that it can return. Again,
this would normally not work, as the call stack where QApplication
and friends would live would get smashed as the application
continued executing. We work around this by allocating a block
of stack space at the start of main(), which we then redirect the
stack pointer to before calling the user's main. This results in
the whole stack of the user's main() and below being preserved, even
if we longjmp out of the call stack (which then restores the
stack pointer).
This approach should work fine together with garbage-collection as
well, since the mark-and-sweep phase will walk the stack from the
stack pointer to the stack base, including sections of the stack
that were part of qt_user_main() and live in the reserved area.
One case where GC will fail though is if it happens as part of the
qt_user_main() call, where the GC will not mark anything in the
'real' callstack below UIApplicationMain(), but this is not
expected to happen.
The size of the reserved stack can be controlled through the
Info.plist key 'QtRunLoopIntegrationStackSize', as well as the
'QtRunLoopIntegrationDisableSeparateStack' key to disable the
separate stack approach completely. This will fall back to the
old approach. The amount of stack space used by the user's
main can be determined by enabling a special debugging mode,
using the 'QtRunLoopIntegrationDebugStackUsage' key.
Change-Id: I2af7a6cfe1a006a80fd220ed83d8a66d4c45b523
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of using a define to rename the user's main() function during
compilation, we leave the user code alone, and inject our wrapper one
step earlier in the process, at the application entry point 'start'.
This entry point is provided by crt1.o, which is normally linked into
the application automatically. The start() function sets up some state
and then calls main(), but we change the start() function to instead
call our main wrapper.
Instead of shipping our own crt1 binary/sources, we make a copy of
the appropriate crt1.o at build time, and modify its symbol table in
place. This is unproblematic as long as we keep the same length for
the wrapper function name, as the symbol names are just entries in
the global string table of the object file.
The result is that for the regular Qt use-case the user won't see
any changes to their main function, and we have more control over
the startup sequence. For the hybrid use-case, we no longer rely
on the fragile solution of having our back-up 'main' symbol in
a single translation unit, which would break eg with --load_all,
and we don't need to provide a dummy 'qt_user_main' symbol.
OSX 10.8 and iOS 6.0 introduced a new load command called LC_MAIN,
which places the state setup in the shared dyld, and then just
calls main() directly. Once we bump the minimum deployment target
to iOS 6.0 we can start using this loader instead of LC_UNIXTHREAD,
but for now we force the classic loader using the -no_new_main flag.
There's also a bug in the ld64 linker provided by the current Xcode
toolchains that results in the -e linker flag (to set the entry
point) having no effect, but hopefully this bug has been fixed
(or Apple has switched to the LLVM lld linker) by the time we
bump our deployment target.
Change-Id: Ie0ba869c13ddc5277dc95c539aebaeb60e949dc2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the QIOSApplicationState object owned by the platform integration
was deleted we would deallocate QIOSApplicationStateListener, but would
then get a callback on the main queue later on where we would reference
the now invalid 'this' variable.
By moving the dispatch_async call to QIOSApplicationStateListener and
using 'self' we ensure that the listener is retained for as long as the
block is valid. This opens us up for receiving application state callbacks
after QCoreApplication has been deleted, so we need to guard against
that.
Change-Id: I2ac14d28d72fd79764e12b6657234b54d846cb79
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Now that it lives in QPlatformSupport, will be fleshed out more, and
might be used on OSX at some point in time. Still iOS specific, as
none of the iOS API usages have been ifdef'ed.
Change-Id: Ib7fde6403ef2dfef175a6f306a85d58027569a30
Reviewed-by: Ian Dean <ian@mediator-software.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We resize the render-buffer based on the CALayer of the UIView that's
backing the QPlatformWindow, so the logic in defaultFramebufferObject()
to determine if a resize is needed should be based on the relationship
between the render buffer-and the CALayer, not the render-buffer and
the QPlatformWindow.
There is still an issue of the QPlatformWindow and its UIView/CALayer
not being in sync, but that's a separate issue.
Change-Id: I84f617d07ec64fea0d027473e9720523eeae0c7a
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we await giving focus to a focus object until a press
release, it also makes sense to await activating a window until
a press release, since they both have to do with focus. By doing
so, the input panel now stays open if the user selects a line edit
in one window when a line edit in another window still has focus. We
also avoid activating a window in case of a touch cancel (e.g as
a result of the user flicking or triggering a gesture).
Change-Id: Ic00c4be69c257fceb10ce2d5a81cb490ea93710f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
| |
Change-Id: Ic8c5181d753925de0d8cd5fcb5e1347429ff5ba3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Changes f5dbc876378ae58a7bdfe1e9664fc81caca18dfb (Use QUrl in QFileDialog API)
and c96a6ab627100452864eb4d8da973300401c1bfa (Pass argc, argv to platform
plugin) introduced changes to the plugin API.
Task-number: QTBUG-29396
Change-Id: I46ee22d16f045b69f141dc6c982017586efef662
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Reviewed-by: David Faure (KDE) <faure@kde.org>
|
|
|
|
|
|
|
|
| |
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>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
qmake/generators/mac/pbuilder_pbx.cpp
src/corelib/json/qjsonwriter.cpp
src/corelib/kernel/qeventdispatcher_blackberry.cpp
src/plugins/platforms/cocoa/qcocoacolordialoghelper.mm
Change-Id: I24df576c4cbd18fa51b03122f71e32bb83b9028f
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a QWindow was destroyed, we'd delete its corresponding buffers,
but failed to make the correct EAGLContext current first. This would
result in deleting/invalidating buffers for another window (whatever
window's context was current at the time), and that window would then
seemingly stop rendering anything, and turn black on rotation.
Task-number: QTBUG-32246
Change-Id: I335a8c580203fc01e43da31c5cb6f567614c26fc
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I3ec2e2397d76f750f3263e67745aff082d253d15
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a window is active in Qt, it means that is has keyboard
focus. And on iOS, we only want a window to be rendered with
keyboard focus when the input panel is open. Therefore we
choose to call QWindowSystemInterface::handleWindowActivated()
as a response to the input panel opening or closing, rather than
from QPlatformWindow::requestActivateWindow(). And becoming or
resigning first responder is that same as showing or hiding
the input panel.
Change-Id: I33b1bad769bec1fdd7c6ae4119b4b445da2f930f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the user is tranferring input focus between line edits
(or similar controls), the edit that lost focus will close
the input panel, just to see that the input that gained
focus will open it again. This will cause the input panel
to "jump", and can also trigger other input panel related
code/signals unnecessary.
Change-Id: Iac0a103e8d2f0f7cdcc04b8ec5b10e07587d1ad6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I39858fe835c131d5c681db535f2ec9308e2f8223
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Move iOS event dispatcher from platform plugin to platform support, so
that it can be used by multiple iOS platform plugins.
Change-Id: I9041b2de5e00e5fe8f30af2dfd922b4f5c594802
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We can combine the hybrid and non-hybrid use-cases into a single static
library if we are careful about which symbols are included in which
object files. By limiting the main() and qt_user_main() functions to
their own translation units, the linker will only pick them up if they
are missing at link time (the user's program do not provide them).
This technique is resilient to the -ObjC linker flag, which includes all
object files that implement an ObjectiveC class or category, but will
fail if the -all_load flag is passed to the linker, as we'll then have
duplicate symbols for either main() or qt_user_main(). The latter should
not happen unless the user provides the flag manually, and in the case
he or she does, there's ways to work around it by providing less global
flags such as -ObjC or -force_load.
Change-Id: Ie2f8e10a7265d007bf45cb1dd83f19cff0693551
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of force-loading the whole static library of the platform plugin
we tell the linker to look for the missing symbol qt_registerPlatformPlugin.
This symbol is provided by the same object file as the plugin's static
initializer, so the object file is included in the final binary and
the static initializer is run, resulting in the plugin registering with
Qt.
We could have marked the actual static initializer wrapper provided by
Q_IMPORT_PLUGIN(QIOSIntegrationPlugin) as undefined, but due to the C++
mangling this would look less intuitive on the linker command line than
the custom dummy function that we provide, which has C linkage.
Change-Id: I6805537e1f49260a41d48c555376964cb1fe75d8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/global/qglobal.h
src/plugins/platforms/cocoa/qnsview.mm
Change-Id: I6fe345df5c417cb7a55a3f91285d9b47a22c04fa
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The old implementation was wrong since it did not use the
screen's height (which was already in primary orientation) to
calculate what the new y value of the target rect (which was in
portrait) should be.
Change-Id: Ie5b2241119e244d099e06d85f69953c1d64979aa
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The 3G versions are iPad2,6 and iPad2,7.
Change-Id: I43a00e84535d494550bca8a533a6d16af4be6722
Reviewed-by: Ian Dean <ian@mediator-software.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This implementation will look at the orientation of the main
screen to convert the touch coordinates. This will most
likely change in future work, where we might look at a views view
controller instead to decide orientation etc.
Change-Id: Ic7875c5ecc4f21538f82a4f0467350bdf8ecc0b0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Parts of the code seems to assume that all QWindows are
top-level windows. This will be false when not using
alien, as then, each widget will be wrapped inside a
QWidgetWindow. In that case, we should not tell QPA to
activate the "window".
This bug caused focus handling (and text input) to fall
apart for e.g graphicsview when using a QGLWidget as viewport.
Change-Id: I579db7a84d718973e02e96ed535fe6e25baf4bd5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Even if the call site is in the application binary, it's safer to use
RTLD_DEFAULT as that implies using the default library search order.
Change-Id: I1b30bded92b95fc7451fcdbf7afd7444dcecea71
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Set the current directory to application bundle on startup. This allows
Qt examples etc. that load resources from the deployment path to work
correctly without modification.
Change-Id: I5846de135c39d2158ee6c1ae21493739c3532239
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/io/qdatastream.cpp
src/corelib/io/qdatastream.h
src/corelib/json/qjsonwriter.cpp
src/plugins/platforms/cocoa/qcocoawindow.mm
src/plugins/platforms/xcb/qxcbkeyboard.cpp
Change-Id: I46fef1455f5a9f2ce1ec394a3c65881093c51b62
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The way we reported screen position (and normalized position)
for touch events was just wrong. The old implementation did
not take into account that a view could be anything else than
a direct child of the window, which fails for many cases (e.g
when using QGLWidgets). Nor did it take into account the status
bar, which made it hard to push small buttons since the touch
would always be slightly offset.
This patch calculates the screen pos by converting the touch pos
to window pos, and then subtract the application frame (that
contains the size of the status bar).
Change-Id: Ib7f5f6dcea3a611e1ed75d57fb4a4718564752f0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current implementation kept a list of TouchPoints that
was reused when sending active touces to QPA. This list was
never cleaned up, so if you pressed three fingers, and released
one, we would still continue to sendt three touches to QPA.
Especially, since this list was not cleaned up when receiving
a touch cancel, mouse events sometimes stopped working when trigging
a system gesture (like a four finger swipe). This can be seen by
using the fingerpaint example.
Since we cannot rely on TouchPoints having IDs that corresponds to
their index in the touch point list, it ends up being
simpler (and results in less code) to rewrite the implementation to use
a hash table of UITouch to TouchPoints instead.
Change-Id: I5b32f57a8d72a0b8759a64ac7cdfa6700109d2b3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
defaultFramebufferObject() may be called from anywhere, at any point,
not just makeCurrent(). One example is the glyph-cache, which uses it
to re-bind the default FBO after generating the texture cache.
If the default FBO had already been created, but the render-buffer was
out of sync with the window size, we would end up in the resize code
without the correct context current, and without the render-buffer's
owning FBO bound. This caused "Failed to make complete framebuffer
object 8cd7" warnings at runtime.
We now make the context current and bind the FBO, even though it might
already be bound and the context current from makeCurrent(), or when
initially creating the FBO. For the future we should move the whole
resize logic out of defaultFramebufferObject() and call it from
makeCurrent(), or possibly [EAGLView layoutSubviews]. That's a
higher impact change though, which we reserve for the 'dev' branch.
Change-Id: I50ea949c12a02ad1af6ec9fdc3215d5da85b324f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|\|
| |
| |
| | |
Change-Id: Ica003a10ede86914bbbb062a2dc277a2ce39a259
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The check in [QIOSOrientationListener orientationChanged] ensured we
never reported the two unsupported orientations through QPA, but we
were reporting back the orientation through QIOSScreen::orientation()
as well, and that didn't have a guard for -1. This resulted in crashes
in client code that assumed the range of QScreen::orientation() was
defined by the enum, such as the paintedwindow example.
The listener now ignores the two unsupported orientations, which leaves
us at the previous orientation. For the conversion function, we still
have to support all UIDeviceOrientations, so we fall back to portrait
for the two unsupported orientations. In the future we should consider
caching the previous value explicitly, or fall back to the interface
orientation.
Change-Id: Ic19d0ce86b4ddea250ea927d5e8664396b2b68fd
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Internally iOS double-buffers its rendering using copy instead of flipping,
so we reported that our context was single-buffered so that clients could
take advantage of the unchanged buffer. This failed when clients (such as
Qt itself) then assumed that calling swapBufferes() was not needed.
We now properly report that we're double-buffered, and we'll have to find
another way to report the way double-buffering works if that's still an
optimization we'd like to provide to clients.
Change-Id: Id2e4faa68ed3b837ad01d6f22b2927fc9c9769c2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I6a6a025410298cecd5f62abd08388a7379359af7
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
| |
| |
| |
| |
| |
| | |
The first call to resize() was a left-over from before we had retina-support.
Change-Id: I637e8d40f443f81fe7cfc367650bb28b917da2bc
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|\|
| |
| |
| | |
Change-Id: I2a54058b64ac69c78b4120fdaf09b96e025a4c6c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Setting mouseGrabEnabled means that the window should continue
to receive mouse events even when the mouse is not over the
application. This is not an issue on iOS, but the warning is
still annoying.
Change-Id: I0dd7c3828bcb1a51a4eae534aca1da5bfa258f03
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current implementation would never hit the Qt::Tool case, since
a tool is also a Qt::Popup. This patch fixes that by making the
logic more explicit.
Change-Id: I0e6898081a18289e1007c8a168b374740915b3ff
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: I971df06dd348d1da68578e04076a02e85866e141
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We create our QIOSViewController in didFinishLaunchingWithOptions,
and schedule a timer to run the user's main. If the device is
placed in landscape orientation at startup, we will receive a
willRotateToInterfaceOrientation message before the timer is
triggered to run the user's main, which means we do not yet
have a QApplication.
To fix this crash we exit early, but we might have to store the
new orientation for later, and make sure the initial QScreen is
then created with the correct orientation.
Change-Id: I0cc02f0d36b992d190736e98858dc7d002d595b7
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When registering m_touchDevice with QWindowSystemInterface, it
will also transfer ownership to it. It will eventually be
deleted in clenupDevicesList on qtouchdevice.cpp.
This patch will also stop the app from crashing when telling it
to quit.
Change-Id: I97070efdf16b4db7d076935fbec62e60f094a7df
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|\|
| |
| |
| | |
Change-Id: I059725e3b7d7ffd5a16a0931e6c17200917172b5
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Unless we enable those buffers for the FBO that backs the
backingstore, setting a clip region on an associated QPainter
will not work.
One apparent bug from this was the menubar. Without this patch
it appeared to never be drawn. The reason was that we ended up
drawing the menubar background over the whole menubar instead
of inside the clip region.
Change-Id: I25660cec6ce9e43fe4cd693127dca6afeb8dcf65
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
|
|\|
| |
| |
| | |
Change-Id: Icff019d74ae04c628a80f66aa478e4db40fae464
|
| |
| |
| |
| |
| | |
Change-Id: I920e7320e429006aef9433db3e942dc257dc72eb
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The former represents the physical device orientation, the latter the
UI orientation. We need to explicitly cast between them, as they are
different enums, but with compatible values for the subset we use.
Change-Id: I2926068802f35680cb6de5ced6dcf286014fdb2e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Having static QFont instance leads to a resources leaking, since QFontCache
is unable to clean-up font engines when the application exits.
Relates to QTBUG-25434
Change-Id: I71d91094de27c07ab2434c415e4c28b6acab3646
Reviewed-by: David Faure (KDE) <faure@kde.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
|
|/
|
|
|
|
|
|
|
| |
Instead of unconditionally linking to Foundation, UIKit, and QuartzCore,
we leave the dependencies for the iOS platform plugin, where the libs
are actually used.
Change-Id: Ie8cfad2c8230d1f1af6933b831e443fecb0c93f1
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
| |
UIApplicationDelegate's willFinishLaunchingWithOptions message was
introduced in 6.0. For now we don't need to distinguish the two, so
no need to use willFinishLaunchingWithOptions on iOS >= 6.0.
Change-Id: Ic6c2c9d2901def5a5500b186ed57fbe8b8c556d1
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|