summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/ios/qioswindow.mm
Commit message (Collapse)AuthorAgeFilesLines
* iOS: Activate window on touchesEnded instead of touchesBeganRichard Moe Gustavsen2013-08-221-6/+8
| | | | | | | | | | | | | Since we await giving focus to a focus object until a press release, it also makes sense to await activating a window until a press release, since they both have to do with focus. By doing so, the input panel now stays open if the user selects a line edit in one window when a line edit in another window still has focus. We also avoid activating a window in case of a touch cancel (e.g as a result of the user flicking or triggering a gesture). Change-Id: Ic00c4be69c257fceb10ce2d5a81cb490ea93710f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: activate window when input panel opensRichard Moe Gustavsen2013-06-251-1/+17
| | | | | | | | | | | | | | When a window is active in Qt, it means that is has keyboard focus. And on iOS, we only want a window to be rendered with keyboard focus when the input panel is open. Therefore we choose to call QWindowSystemInterface::handleWindowActivated() as a response to the input panel opening or closing, rather than from QPlatformWindow::requestActivateWindow(). And becoming or resigning first responder is that same as showing or hiding the input panel. Change-Id: I33b1bad769bec1fdd7c6ae4119b4b445da2f930f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: take orientation into account when reporting touch positionsRichard Moe Gustavsen2013-05-271-3/+6
| | | | | | | | | | This implementation will look at the orientation of the main screen to convert the touch coordinates. This will most likely change in future work, where we might look at a views view controller instead to decide orientation etc. Change-Id: Ic7875c5ecc4f21538f82a4f0467350bdf8ecc0b0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: don't activate non-toplevel windowsRichard Moe Gustavsen2013-05-241-1/+1
| | | | | | | | | | | | | | Parts of the code seems to assume that all QWindows are top-level windows. This will be false when not using alien, as then, each widget will be wrapped inside a QWidgetWindow. In that case, we should not tell QPA to activate the "window". This bug caused focus handling (and text input) to fall apart for e.g graphicsview when using a QGLWidget as viewport. Change-Id: I579db7a84d718973e02e96ed535fe6e25baf4bd5 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: fix bug when reporting the screen position of touch eventsRichard Moe Gustavsen2013-05-201-8/+8
| | | | | | | | | | | | | | | | | The way we reported screen position (and normalized position) for touch events was just wrong. The old implementation did not take into account that a view could be anything else than a direct child of the window, which fails for many cases (e.g when using QGLWidgets). Nor did it take into account the status bar, which made it hard to push small buttons since the touch would always be slightly offset. This patch calculates the screen pos by converting the touch pos to window pos, and then subtract the application frame (that contains the size of the status bar). Change-Id: Ib7f5f6dcea3a611e1ed75d57fb4a4718564752f0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: don't send ended touch events to QPARichard Moe Gustavsen2013-05-071-68/+35
| | | | | | | | | | | | | | | | | | | 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: stack true popup windows ontop of tool windowsRichard Moe Gustavsen2013-04-261-1/+3
| | | | | | | | | The current implementation would never hit the Qt::Tool case, since a tool is also a Qt::Popup. This patch fixes that by making the logic more explicit. Change-Id: I0e6898081a18289e1007c8a168b374740915b3ff Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: add convenience functions for getting window typeRichard Moe Gustavsen2013-04-261-2/+2
| | | | | Change-Id: I971df06dd348d1da68578e04076a02e85866e141 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: use an explicit pointer to qiosViewControllerRichard Moe Gustavsen2013-04-191-2/+2
| | | | | | | | | | | | | As it stood, we always relied on the root view controller being a QIOSViewController if isQtApplication() returned true. For mixed application, this might not always be true as native code can choose to replace the root view controller at times, or even rip it out, and place it as a child of another (e.g UISplitViewController). This change will give an extra protection against that. Change-Id: I0cb85796a8b82f9037c32f9e85e04e1dc7aad8e2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: Handle UIDeviceOrientation vs UIInterfaceOrientationTor Arne Vestbø2013-04-041-1/+1
| | | | | | | | | | The former represents the physical device orientation, the latter the UI orientation. We need to explicitly cast between them, as they are different enums, but with compatible values for the subset we use. Change-Id: I2926068802f35680cb6de5ced6dcf286014fdb2e Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Set touch point position in screen coords.Morten Johan Sørvig2013-02-271-4/+7
| | | | | | | | Previously the position was set in window coordinates, which would break for non-fullscreen windows. Change-Id: Iefa2f590c6d62b09fc3e7fe60a882c1acd33e029 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: QIOSWindow::setParent()Richard Moe Gustavsen2013-02-271-3/+11
| | | | | Change-Id: I1a413d898d10b55a4d0653eae719f5bd909a01ec Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: avoid activating modally blocked windowsRichard Moe Gustavsen2013-02-271-1/+18
| | | | | | | | 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-10/+32
| | | | | | | | | | | 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-11/+95
| | | | | | | | | | | | | | | 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: let first responder follow the view of the focus windowRichard Moe Gustavsen2013-02-271-0/+5
| | | | | | | | | | This to ensure that the keyboard does not close prematurly. This can happen if the user opens up the keyboard while typing inside one window, then switch window, continue typing while the other window gets deleted. Change-Id: I5cfb1673ccbe4d5aaa14167b7aa53451031089a1 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: implement QPlatformWindow::requestActivateWindow()Richard Moe Gustavsen2013-02-271-7/+13
| | | | | | | | 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: raise windows that becomes visibleRichard Moe Gustavsen2013-02-271-1/+9
| | | | | | | | When a QWindow becomes visible, it should move to front and be active. Change-Id: Icab12c6031c0cc8d791e4f8cc49b9c2d5c73100d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: implement QPlatformWindow::raise() and lower()Richard Moe Gustavsen2013-02-271-1/+31
| | | | | | | | | | | | | 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: transfer focus to the window touchedRichard Moe Gustavsen2013-02-271-0/+5
| | | | | | | | | Since our QWindows are UIViews rather than UIWindows, we need to implement window activation manually. This patch will ensure that the window touched by the user also gets keyboard focus. Change-Id: I9390c5c8e50a4b066cd1320a2a044e02f2a9f75d 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-59/+6
| | | | | | | | | | | | | | | 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: Fix style nitpicksTor Arne Vestbø2013-02-271-2/+2
| | | | | Change-Id: I670567f1793b5548393a3b315650bf34a0a3880e Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
* iOS: make QWindow views hidden by defaultRichard Moe Gustavsen2013-02-271-0/+3
| | | | | | | | | Qt will tell us when the window should be visible. Showing all windows by default makes e.g the desktop widget visible as well, which causes problems with activation of windows. Change-Id: Ibf2283bc5f009df7ff23126f4dd04ec898141720 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: activate next window when active window hidesRichard Moe Gustavsen2013-02-271-1/+15
| | | | | | | | | | Since the OS does not handle window management for us, we need to handle this ourselves. So when a QWindow is closed or hidden, we transfer activation to the top-most visible window. This will fix application unresponsive after closing a dialog. Change-Id: I83f836ebafa71edca5ab5ae3a2bdba7cd1decbc1 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: add UIView category to get the QWindow it representsRichard Moe Gustavsen2013-02-271-0/+11
| | | | | | | | | | | | 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-1/+23
| | | | | | | | | | | 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: add convenience function to get to the root QIOSViewControllerRichard Moe Gustavsen2013-02-271-1/+1
| | | | | | | | | | | | | | | It seems that we need to access our view controller from many places, and the syntax to do so is tricky to remember. So lets just add it to our global functions, with the added bonus of a using a little cache. Note: many of these functions could be made inline, but since one concern of the plugin will be the end size of the app, I prefer to trade size for speed at this point. We can always change this later. Change-Id: I578ea9ae8218d23d635b7728a930763ca53c4eaa Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: add global function 'isQtApplication'Richard Moe Gustavsen2013-02-271-1/+1
| | | | | | | | | | Several places in the code we need to check if the plugin is running as a cross-platform Qt application or inside a native app. So we refactor this function to qiosglobal so we can access it from everywhere. Change-Id: I78db0dcde71b7d281868ce304867c8f876caef2a Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: refactor general convenience functions into new file 'qiosglobal'Richard Moe Gustavsen2013-02-271-10/+1
| | | | | | | | Some functions are needed across several files and classes. Lets place them in a common file for all to use. Change-Id: I5f9b578f948d66d10e57a835b80b5c493e07fb4c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: Retina display support.Morten Johan Sorvig2013-02-271-3/+18
| | | | | | | | 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: refactor QIOSOrientationListener into QIOSScreenRichard Moe Gustavsen2013-02-271-2/+1
| | | | | | | | | | | | 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>
* iOS: implement in QIOSWindow::setVisibleRichard Moe Gustavsen2013-02-271-0/+6
| | | | | | | | | 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: remove the view from the view hierarchy upon destructionRichard Moe Gustavsen2013-02-271-0/+1
| | | | | | | | | | 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>
* iOS: Update GL render buffers when the accociated window is resizedTor Arne Vestbø2013-02-271-35/+47
| | | | | | | | 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-3/+6
| | | | | | | | | | | | | 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: let fullscreen geometry take orientation into accountRichard Moe Gustavsen2013-02-271-3/+6
| | | | | | | | | 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>
* iOS: when in fullscreen, autoresize the view when the device rotatesRichard Moe Gustavsen2013-02-271-0/+2
| | | | | | | | | 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>
* iOS: one 'transform' warning per window is sufficientRichard Moe Gustavsen2013-02-271-5/+0
| | | | | | | | | 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>
* iOS: when in fullscreen, dont respond to geometry changesRichard Moe Gustavsen2013-02-271-20/+14
| | | | | | | | | | 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: Set initial window state on window creationTor Arne Vestbø2013-02-271-0/+2
| | | | | | | | | | 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>
* iOS: Remove requestWindowOrientation from QIOSWindowTor Arne Vestbø2013-02-271-16/+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: use 'self' rather than 'super' pointer in initWithQIOSWindowRichard Moe Gustavsen2013-02-271-1/+1
| | | | | | | | 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>
* iOS: implement requestWindowOrientationRichard Moe Gustavsen2013-02-271-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | 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/+9
| | | | | Change-Id: I2bfb4ee4840086dcd3ec85c2ee7e8769e76d2700 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: Ensure UIApplicationMain is started before QApplication by wrapping main()Tor Arne Vestbø2013-02-271-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* iOS: Implement QPlatformWindow::setWindowState()Tor Arne Vestbø2013-02-271-0/+18
| | | | | | | | | | | | | 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-1/+42
| | | | | | | | | | | | | | | | | | | | 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: Pass QWindow geometry to initWithFrame on window creationTor Arne Vestbø2013-02-271-4/+9
| | | | | | | | 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>
* iOS: send mouse events (from touch events) from EAGLViewRichard Moe Gustavsen2013-02-271-11/+10
| | | | | Change-Id: Ia6c955f2c5bcde8e41d5908bfb8fd52bd449b3ec Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: create top-level UIWindow and UIViewControllerRichard Moe Gustavsen2013-02-271-0/+6
| | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 13:30:12 +0000