| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: I2bfb4ee4840086dcd3ec85c2ee7e8769e76d2700
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>
|
|
|
|
|
| |
Change-Id: Ia6c955f2c5bcde8e41d5908bfb8fd52bd449b3ec
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
|
|
|
|
|
| |
Change-Id: Idd65ad9cbb77114466c5b69a799b98a7fee5068f
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>
|