summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/ios/qioswindow.h
Commit message (Collapse)AuthorAgeFilesLines
* iOS: implement in QIOSWindow::setVisibleRichard Moe Gustavsen2013-02-271-0/+1
| | | | | | | | | 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>
* iOS: Update GL render buffers when the accociated window is resizedTor Arne Vestbø2013-02-271-0/+9
| | | | | | | | 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>
* iOS: update QPlatformWindow::geometry() when UIView changes sizeRichard Moe Gustavsen2013-02-271-0/+1
| | | | | | | | | | | | | 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>
* iOS: when in fullscreen, dont respond to geometry changesRichard Moe Gustavsen2013-02-271-1/+0
| | | | | | | | | | 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>
* iOS: Remove requestWindowOrientation from QIOSWindowTor Arne Vestbø2013-02-271-1/+0
| | | | | | | 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>
* iOS: implement requestWindowOrientationRichard Moe Gustavsen2013-02-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* iOS: handle content orientation feedback from applicationRichard Moe Gustavsen2013-02-271-0/+1
| | | | | Change-Id: I2bfb4ee4840086dcd3ec85c2ee7e8769e76d2700 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: Implement QPlatformWindow::setWindowState()Tor Arne Vestbø2013-02-271-0/+2
| | | | | | | | | | | | | 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>
* iOS: Implement QIOSWindow::setGeometry() and pick up UIView geometry changesTor Arne Vestbø2013-02-271-0/+1
| | | | | | | | | | | | | | | | | | | | 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>
* iOS: send mouse events (from touch events) from EAGLViewRichard Moe Gustavsen2013-02-271-0/+3
| | | | | Change-Id: Ia6c955f2c5bcde8e41d5908bfb8fd52bd449b3ec Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: Implement QPlatformOpenGLContextTor Arne Vestbø2013-02-271-69/+28
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* iOS: Change member variable style to be consistent with Qt's de facto standardTor Arne Vestbø2013-02-271-13/+13
| | | | | Change-Id: Idd65ad9cbb77114466c5b69a799b98a7fee5068f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: copy brute-force port of Qt4 uikit plugin into Qt5.Richard Moe Gustavsen2013-02-261-0/+135
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-26 23:19:30 +0000