From the documentation for QAbstractEventDispatcher::flush(), this
function does only make sense for X11.
Change-Id: I7f445b67b283f60c9a30ac00837beb44e8205d8b
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Scale the OpenGL paint device size and physical dpi
by the device pixel ratio.
Change-Id: I8b576f23129aafc47371795151c548663e94ad52
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
When QScreen is created, we need to check if the application
is already in landscape.
Change-Id: I653c622154a5c23ec93e89ec3e80fefb6b1f1bdd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Clean up a bit. The orientation conversion functions belongs to
QIOSScreen more than QIOSOrientationListener. And rename them in
the same go to follow toQRect/fromQRect standard.
The orientation listener itself is tightly coupled to QIOSScreen, and
does not make much sense on its own, so move it into QIOSScreen to
follow the same patteren already implemented for QIOSInputContext.
Change-Id: I8b6b4d08a42349b4232749d59d46748297083536
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Qt expects the screen to change geometry when the "desktop" rotates.
On iOS, we interpret this as when the root view controller changes
orientation, since after all, this is the surface we place QWindows
on top of.
Change-Id: Ia00e68c8f9f0a65aefcc60518ee544fb260d4595
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Without a platform theme implementatin we were relying on
QCoreTextFontDatabase::defaultFont() to return the system font.
This didn't work because it reported the system font that iOS reports,
'.Helvetica Neue UI', which is a private font that does not get added
to our font database. The result was that we picked the first font in
the list of known fonts -- in this case 'Academy Engraved LET'.
We now implement QIOSTheme::font(), which takes precedence over the
font database's default font, and hard-code the system font to
'Helvetica', since Qt does not yet have the concept of private
system fonts.
Change-Id: I901cf9c2b662ea2795212376b84b8391be2efbbe
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
This change will add an initial implementation of the
QPlatformInputContext for dealing with the keyboard.
Change-Id: I29c1cfbbebb8456977b8a1db0e966973cd2c24a5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
When QWindow is told to show/hide, we need to show/hide the
backing UIView as well, otherwise the window will still be
visible on screen.
Change-Id: I806fdd8bb4afacbbc1c9c7381ba0a31195ee04ac
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
We need to remove the view that backs QWindow when the window
is destroyed. Otherwise the view will still be visible on screen,
but now with a dangling QWindow pointer. This fixes a crash that
happens when closing dialogs.
Change-Id: I9053c83c6db80a39f4f71a63993cc7ae73fc4196
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
This is an intermediate heuristic until we have a proper API in Qt to
deal with auto-rotation and orientation locking.
Change-Id: I433992fa1c18d1670987f79e405a4501b6e5d365
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
We keep track of the with and height of the FBO's buffers, and update
their storage if the window size has changed since last time.
Change-Id: I97788b69e7067a5b5b9f28e8498cf1bc5d2cf6ea
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Treating the paint-device as a thing wrapper around the OpenGL paint engine
failed when the window was resized, as the paint engine would clip the
drawing to the old size. We need to update the size in beginPaint.
QBackingStore resize still behaves like before, and we emit a warning if
the user tries to resize the backing-store to some other size than the
window size, as that's not a supported use-case for our iOS backing store.
Change-Id: I1a0eeb65fa9db8b5538dc69963d6fc84be6e63f1
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
It turns out that QWindow::geometry needs to be updated manually
by the platform plugin, and not indirectly trough
QWindowSystemInterface::handleGeometryChange as first assumed.
We now always report the _actual_ geometry of the UIView (which
also takes the status bar into account) to QWindow, and remember
the _requested_ geometry of the window to use whenever the state
of the window changes.
Change-Id: Iea940173d26fb6af701234379cae914215dae984
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Since UIScreen is orientation agnostic, we need to look at the
view of the top level view controller instead to determine
available geometry.
Change-Id: I3789ab7972a9970e46fbc8af81f2b7199e5ca5d1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Tell the view that backs QWindow to autoresize itself when
the superview (view of the root view controller) changes size.
This will typically happen when the device changes orientation.
Change-Id: Ib7c4dff9112d57f60012d3f0837677e09088bcaf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
The layoutSubviews function will be called when the geometry
changes, and we will catch the transform issue there for
both UC1 and UC2
Change-Id: I29578bbc5b3091c86fbe69c7095ff280a64be458
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
When QWindow is told to be in fullscreen, we should not
respond to geometry changes. Instead we should bookkeep
the requested geometry and set it when/if the window
enters Qt::WindowNoState later.
Change-Id: Ieaf4756b2a966212c8e1738af9df175a58786a75
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
We may need to qualify this setting for UC2, so that the user may still
create windows as sub-controls of a regular iOS user interface, but for
UC1 it makes sense.
Change-Id: I1a7019f901fabed8b5b9cbb18a929913780e6595
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
When showing a QWindow the window state is set first, and then the window
is made visible. The latter is the step that creates the platform window,
so we need to pick up the already set window state in our constructor
and respect that.
Change-Id: I54fe6c4ebcd3c9504614d2d48bd21f0d76adf3b7
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
The API is scheduled to be removed in qtbase in time for Qt 5.0.
Change-Id: Ie34d6cb79fcd81b0ce02892529e3e7184ddfa096
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
This causes painting errors. Use one lazily-created
device that is used for the lifetime of the backing
store.
Change-Id: Ib36b6f1d6c9f958304dc8403cf17e5d71136469a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
If we use super, our own initWithFrame override will never be
called.
Change-Id: I606beb653239cdfc46f41db4ec0791dfa5d4edea
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
The application is normally supposed to rotate the content on its
own, but can call requestWindowOrientation to ask the window
manager to do it instead. This way of integrating orientation with
the OS is fragile, because:
1. In some cases, you cannot stop the OS from rotating at all
(tablets).
2. It would be more safe to inform the window manager up-front
which orientations it could rotate into, rather that relying
on a function you call call to force this later on.
3. When the QML application starts, its a bit late to inform
the platform plugin that it supports e.g landscape. If the
OS is in landscape already, the plugin must still assume that
the app operates in portrait (doing rotating on its own) until
requestWindowOrientation is called. This might cause the app
to first start up in portrait, just to rotate into landscape.
On iOS, it seems like we can handle the first two cases. The third
need some more investigation. We should anyway investigate if we
need some adjustment to the Qt API.
Change-Id: I50638b78d469ab70820a787de86a2f1981470786
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
We need our own viewcontroller to better control which
orientations iOS can enter, and also ito be able to
stop auto-rotation.
We stop auto-rotation to happend by default, since this is
how Qt wants it (it is seen as the responsibility of the
application).
Change-Id: Id07a96e355396752fffd28984af528aeb0b7c3e3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
From the qpa docs, we only need to listen for device orientation
if orientationUpdateMask is non-zero
Change-Id: Id5e828cdff9a08794c8a029e11763cc037e1b959
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
QIOSScreen will use this to listen for orientation
changes from UIDevice.
Change-Id: I5a30f3808f8b9b885303608ce2fc1316c962898b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
This takes care of setting INSTALLS for us, so we can skip that.
Change-Id: I351cb9ec08b632fd9867d85e2c5fa59d8e5acc9d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
In both maximized and fullscreen modes we assume that we can use the
availableGeometry() of the QScreen, but of course this depends on us
showing or hiding the statusbar first, as well as QScreen actually
returning the right availableGeometry when the statusbar is shown.
The latter is not the case right now, as we initialize QScreen before
UIApplication has been set up and UIScreen has had a chance to init
itself based on the precense of a statusbar or not.
Change-Id: Id44dee3550f7135ffe2852b377bb6c7b6d522d68
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
The best way to pick up geometry changes of the UIView seems to be to override
layoutSubviews(), but that will only be called if the size of the UIView
changes, not when the position (center) changes. This means that the position
reflected by the QWindow will not always be in sync with the position of the
native UIView. Fortunately the position of a QWindow is not used for anything
critical in Qt itself.
Another issue is that the frame property of a UIView is only valid if the
transform of the UIView is set to the identity transform. We try to catch
cases where this is not the case, and warn the user about this. We could
in theory react to changes in the UIView geometry by only updating the
size, since this is also reflected through the bounds property of the
UIView. This is left for when we know more about how these things
interact in practice.
Change-Id: I079162c059d377a77569fe3974e261d2e0671fd5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
This will sadly not work as expected until we've found a way to kick
off the iOS event loop before QApplication is initialized, as UIScreen
does not seem to report the correct applicationFrame (taking the status
bar into account) until after the UIApplication has been set up by
UIApplicationMain().
Change-Id: I0eaa3b8bca4129d1c4183a202ad2ecd0d8bc52d0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
No need to implement this one, the standard implementation
creates a raster pixmap.
Change-Id: I9bb25188bd95159d76e760b2be6870e0bede7b56
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Since the plugin will always be linked in statically, we add this
necessary registration code into the plugin itself rather than
putting this burden onto the client application.
Change-Id: I8691d8080e41bdf0644bb960b5c7102e79a0f0d5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Allows the optimal pattern of setting the geometry of the QWindow
before showing (and hence creating) it.
Change-Id: I29206b5d9a70df0b01e8df8f7df8f35cced51121
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Convenient to aid debugging during development of the platform plugin.
Change-Id: Id429ca95e0452385ee8def1fe4a1bb7de175ba3e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Rough implementation to support stand-alone processEvent calls. We
probably need to revisit this code to fix corner-cases later on.
Change-Id: I72d5639dab599b4d0017aaa52b922f4185a50337
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
With this patch you can now expect the following code to work:
QEventLoop l;
QTimer::singleShot(1000, &l, SLOT(quit()));
l.exec();
Change-Id: Ic73e37affaadf8a859787d84ac02c15621ac7a29
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Create a UIWIndow with a view controller and a view
where we can reparent our QIOSWindow views inside.
Change-Id: Ic90707d3ebe1af970a3aa2aa0f8c0f4be192456a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
We build on top of the QPlatformOpenGLContext implementation to get
automatic support for QBackingStore-based painting. Since the OpenGL
renderer does not clear the backingstore between frames, we actually
also get support for partial updates, and we get the benefit of an
accelerated paint engine for Qt Quick 1 without setting a GLWidget
as the viewport, which would cause issues such as an extra QWindow.
This patch also removes the dependency to QtOpenGL and QtWidgets, which
were leftovers from the Qt4 platform plugin. In Qt5 the needed GL bits
are in QtGui.
Change-Id: Id9b736bfb2e4aec56c0fa9f5b7b4d8bff8e3d1dc
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
The iOS platform GL context is an EAGLContext, which is wrapped by
the new class QIOSContext. The class takes care of makeCurrent()
and swapBuffers(), but defers framebuffer management to the
corresponding QIOSWindow.
At the moment only a single framebuffer is created, and changing the
geometry of the QWindow does not trigger any sort of invalidation of
the buffers.
The implementation assumes OpenGL ES2.x support. Though strictly
speaking we could support ES1 for QtGui, it serves little purpose
as Qt Quick 2 requires ES2.
This patch also disabled touch event synthesization until we have
figured out where we will maintain the connection to UIWindow.
QPlatformOpenGLContext::getProcAddress() for getting extensions is
implemented by using dlsym() to look up the symbol. This should not
present any issues for App Store deployment, like dlopen() would.
Change-Id: I166f800f3ecc0d180133c590465371ac1642b0ec
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Implement the remaining timer functions in the event dispatcher
Change-Id: Ie323962c898a2ee95ea60a8ca63b93cbd4544fd1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
