summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/ios/qioswindow.h
Commit message (Collapse)AuthorAgeFilesLines
* iOS: Change show() to imply maximize, and showFullScreen() to hide status barTor Arne Vestbø2013-11-221-0/+2
| | | | | | | | | | | | Matches the Android behavior, and gives an easy and predictable way to show true fullscreen windows that is similar to how one would do it on a desktop platform. We keep the statusbar visibility in sync with the window state of the active window. Change-Id: Ia4b99e03f83e19f9ef56cc99b9d477cc6da4c734 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Use custom method to lay out windows instead of resizeMaximizedWindows()Tor Arne Vestbø2013-11-211-0/+4
| | | | | | | | | Since we guard against overriding the geometry in setGeometry() when a window has a window state, we need to use a custom method to lay out windows that calls applyGeometry() instead. Change-Id: I6508e6aac6746c024a6172f709b8339b35b40994 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Don't keep around reference to a single QIOSViewControllerTor Arne Vestbø2013-11-201-0/+1
| | | | | | | | We might have more of them in a multi-screen setup or when implementing support for modal windows using sub-viewcontrollers. Change-Id: Ibe98273a13af981fffe2704a2c05bfd9d3f3e9e0 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Tie QIOSContext FBOs to corresponding QPlatformWindow, not QWindowTor Arne Vestbø2013-11-141-1/+3
| | | | | | | | | | | | | | | | A QWindow may be created() and destroyed() multiple times in the lifetime of the window, each time resulting in a new platform window (QIOSWindow) being created. This QIOSWindow is backed by a new UIView each time, hence it needs a new FBO and renderbuffer-mapping, since the previous renderbuffer was mapped to the old UIView. This fixes a bug where a QWindow would not render after a destroy() unless it was resized (which triggered new FBO/renderbuffers). We need to inherit QObject so that we can watch the destroyed() signal. Change-Id: I93172dd6280b86b49755bf7abddf061d7e6b66f1 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Flesh out device-pixel-ratio handling in QIOSWindowTor Arne Vestbø2013-11-141-1/+0
| | | | | | | | | | We don't need to cache the device-pixel-ratio, as we can ask the UIView directly. We do need to set it though, as the default behavior of matching the screen scale does not apply for EAGL-backed views, but the ratio needs to match the current screen the view is on. Change-Id: I29e4a4fa4f4b767d86265ec899fb43a355b5c3a3 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Rename QIOSWindow's backing view from EAGLView to QUIViewTor Arne Vestbø2013-11-081-1/+3
| | | | | | | Matches the cocoa QNSView and highlights the relation to UIView. Change-Id: Idcdb17bff994c1e0aef099400c21915a7041e44c Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Rename m_requestedGeometry to m_normalGeometryTor Arne Vestbø2013-11-081-1/+1
| | | | | | | Matches the wording using in QWidget. Change-Id: Ifbb4e5ffa90b47a7c179cf9ec52cb46126d7bccc Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Remove unused QIOSWindow methods for getting effective width/heightTor Arne Vestbø2013-11-061-2/+0
| | | | | Change-Id: Ifdfd5881822bf56f2c8ab0742a0e257e2bd61533 Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
* iOS: don't send ended touch events to QPARichard Moe Gustavsen2013-05-071-7/+0
| | | | | | | | | | | | | | | | | | | 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>
* iOS: remove setMouse/keyboardGrabEnabled warningRichard Moe Gustavsen2013-04-261-0/+3
| | | | | | | | | | 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>
* iOS: add convenience functions for getting window typeRichard Moe Gustavsen2013-04-261-0/+3
| | | | | Change-Id: I971df06dd348d1da68578e04076a02e85866e141 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: QIOSWindow::setParent()Richard Moe Gustavsen2013-02-271-0/+1
| | | | | Change-Id: I1a413d898d10b55a4d0653eae719f5bd909a01ec Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: implement QIOSWindow::winId()Richard Moe Gustavsen2013-02-271-1/+1
| | | | | Change-Id: I3dd7accae43bcf7d4d6dfd8b272ab65d67bd935c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: avoid activating modally blocked windowsRichard Moe Gustavsen2013-02-271-0/+1
| | | | | | | | 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>
* iOS: add QIOSWindow::windowLevel() to simplify window stackingRichard Moe Gustavsen2013-02-271-1/+2
| | | | | | | | | | | 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>
* iOS: Implement touch events.Morten Johan Sørvig2013-02-271-0/+9
| | | | | | | | | | | | | | | 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>
* iOS: implement QPlatformWindow::requestActivateWindow()Richard Moe Gustavsen2013-02-271-0/+1
| | | | | | | | 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>
* iOS: implement QPlatformWindow::raise() and lower()Richard Moe Gustavsen2013-02-271-0/+5
| | | | | | | | | | | | | 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>
* iOS: Move handling of FBOs to QIOSContext instead of QIOSWindowTor Arne Vestbø2013-02-271-9/+2
| | | | | | | | | | | | | | | 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>
* iOS: add UIView category to get the QWindow it representsRichard Moe Gustavsen2013-02-271-0/+4
| | | | | | | | | | | | 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>
* iOS: make EAGLView private in QIOSWindowRichard Moe Gustavsen2013-02-271-27/+2
| | | | | | | | | | | 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>
* iOS: Retina display support.Morten Johan Sorvig2013-02-271-0/+2
| | | | | | | | 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>
* 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-05-08 02:50:03 +0000