Make sure that the user cannot activate a window
that is modally shaddowed.
Change-Id: Ib92be319d017460bbc1ef63ad7556cb4758dfa6c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
When adding modal windows into the mix, raiseOrLower became
even more messy to write. So do it the usual way instead, and
add a windowLevel variable to each QIOSWindow that we
can sort on. The code becomes more readable, and we can handle
more window types correctly.
Change-Id: I348352473a7d8cf9909c17c1b074b2fe3fab9819
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Track touch events during the standard [Began -> Moved
-> Ended] event sequence based on the UITouch pointer
which stays constant.
Enable multiTouch on Qt's UIView.
Mouse events should now be automatically created
from (unhanded) touch events by QGuiApplication.
Reviewed by: Ada Sørvig (fingerpaint app approved)
Change-Id: I2aeb48c962c697d8b8337f8ceab062070c2a4240
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Dispite the name, 'requestActivateWindow' means raise and transfer
focus to the window.
Change-Id: Ib97321ed7ec8da90e924ff8155a95896c12160c9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Probably not going to be the most used functions on iOS, but
implemented to support old widget apps out of the box. The
implementation stacks both staysOnTop and popup windows on
the same level for simplicity, since iOS does not have a
concept of z-ordering UIViews (UILayer has z-order, but layers
belong in a different hierarchy, and cannot be used in this
respect).
Change-Id: Idd68e5ceea7d4eaeb3066486c47400930cebb1b0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
The lifetime of an FBO is tied to its context, so letting each window
manage its own FBO failed when the window tried to delete the FBO
at destruction time without the proper context being current, or
even available anymore.
We solve this by moving all handling of FBOs to the context itself,
which is fine as we're exposing the necessary bits from the window
to allocate storage based on its layer.
Change-Id: I8c7c96cf63d6b667527c816f10ac2f4ff6a05e0c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Adding a simple way to get the QWindow pointer from any UIView
makes writing code where you only have UIView pointers a bit easier.
Perhaps we should also investigate if it is worthwhile to make
this category public to the application, to further enhance
working in a mixed environment.
Change-Id: Ic263003dc7683a8d976024cbbbc2558e8472a790
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Not the biggest gain, but since all the members of EAGLView are
declared private, we might as well move the whole interface into
the source file. We can then make the members public without
caring about interface readability. We will make use of this in
a following patch.
Change-Id: I144fb5748573ca6faf257d72597907b5c17b1e05
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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 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 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>
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>
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>
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>
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>
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>
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>
The plugin has been renamed from uikit to ios.
Other than that, the plugin will now build, but do nothing. Most of
the Qt4 code is preserved, with a rough translation
into the Qt5 qpa API. A lot of code has simply been commented
out so far, and most lacking at the moment is the event dispatcher
which will need to be rewritten, and the opengl paint device
implementation. But it should suffice as a starting ground.
Also: The plugin will currently not automatically build when
building Qt, this needs to be enabled from configure first.
Change-Id: I0d229a453a8477618e06554655bffc5505203b44
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Richard Moe Gustavsen
Morten Johan Sørvig
Tor Arne Vestbø