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>
Try to keep qiosglobal.h free from unnecessary includes, since its
typically included from many different locations.
Change-Id: I6638bcaef1189b3eee3dbd5f744c15f8f7858d71
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
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>
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>
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>
configure.prf checks if MAKEFILE_GENERATOR is set
to something it can work with. ios/default_pre.prf
unsets MAKEFILE_GENERATOR.
This breaks QtMultimedia at least. Add special case
for iOS to configure.prf and set QMAKE_MAKE to "make".
Change-Id: Ie8feaeefe4a932d735a0cd4c09e869ca1341aae5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
QScreen geometry and orientation is updated a bit after we
change geometry in QPlatformScreen, which this time was enough to
break availableGeometry. Since this function is for internal use, we
let it be based on internal data.
Change-Id: I7701b0a6043839c89c01e87242decb8a739d00f1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
We need to update primary orientation when the rotation starts, and
not when it ends, so that we are in sync with the resize that happens
to the backingstore upon layoutSubviews.
Change-Id: I466a2d135e6c15550c6207c9659871629d748b73
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
QInputContext expects us to report whenever the
input panel changes geometry. This patch implements
this.
Change-Id: I9162f0d48da6925274a7489c9bcb6adab9afae82
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
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>
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>
From the documentation for QAbstractEventDispatcher::flush(), this
function does only make sense for X11.
Change-Id: I7f445b67b283f60c9a30ac00837beb44e8205d8b
Reviewed-by: Morten Johan Sørvig <morten.sorvig@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 QScreen is created, we need to check if the application
is already in landscape.
Change-Id: I653c622154a5c23ec93e89ec3e80fefb6b1f1bdd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
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>
Qt expects the screen to change geometry when the "desktop" rotates.
On iOS, we interpret this as when the root view controller changes
orientation, since after all, this is the surface we place QWindows
on top of.
Change-Id: Ia00e68c8f9f0a65aefcc60518ee544fb260d4595
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Without a platform theme implementatin we were relying on
QCoreTextFontDatabase::defaultFont() to return the system font.
This didn't work because it reported the system font that iOS reports,
'.Helvetica Neue UI', which is a private font that does not get added
to our font database. The result was that we picked the first font in
the list of known fonts -- in this case 'Academy Engraved LET'.
We now implement QIOSTheme::font(), which takes precedence over the
font database's default font, and hard-code the system font to
'Helvetica', since Qt does not yet have the concept of private
system fonts.
Change-Id: I901cf9c2b662ea2795212376b84b8391be2efbbe
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
This change will add an initial implementation of the
QPlatformInputContext for dealing with the keyboard.
Change-Id: I29c1cfbbebb8456977b8a1db0e966973cd2c24a5
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 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>
This is an intermediate heuristic until we have a proper API in Qt to
deal with auto-rotation and orientation locking.
Change-Id: I433992fa1c18d1670987f79e405a4501b6e5d365
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
Treating the paint-device as a thing wrapper around the OpenGL paint engine
failed when the window was resized, as the paint engine would clip the
drawing to the old size. We need to update the size in beginPaint.
QBackingStore resize still behaves like before, and we emit a warning if
the user tries to resize the backing-store to some other size than the
window size, as that's not a supported use-case for our iOS backing store.
Change-Id: I1a0eeb65fa9db8b5538dc69963d6fc84be6e63f1
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>
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>
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>
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>
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>
We may need to qualify this setting for UC2, so that the user may still
create windows as sub-controls of a regular iOS user interface, but for
UC1 it makes sense.
Change-Id: I1a7019f901fabed8b5b9cbb18a929913780e6595
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
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>
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>
This causes painting errors. Use one lazily-created
device that is used for the lifetime of the backing
store.
Change-Id: Ib36b6f1d6c9f958304dc8403cf17e5d71136469a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
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>
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>
We need our own viewcontroller to better control which
orientations iOS can enter, and also ito be able to
stop auto-rotation.
We stop auto-rotation to happend by default, since this is
how Qt wants it (it is seen as the responsibility of the
application).
Change-Id: Id07a96e355396752fffd28984af528aeb0b7c3e3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
From the qpa docs, we only need to listen for device orientation
if orientationUpdateMask is non-zero
Change-Id: Id5e828cdff9a08794c8a029e11763cc037e1b959
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
QIOSScreen will use this to listen for orientation
changes from UIDevice.
Change-Id: I5a30f3808f8b9b885303608ce2fc1316c962898b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
This takes care of setting INSTALLS for us, so we can skip that.
Change-Id: I351cb9ec08b632fd9867d85e2c5fa59d8e5acc9d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
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>
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>
This will sadly not work as expected until we've found a way to kick
off the iOS event loop before QApplication is initialized, as UIScreen
does not seem to report the correct applicationFrame (taking the status
bar into account) until after the UIApplication has been set up by
UIApplicationMain().
Change-Id: I0eaa3b8bca4129d1c4183a202ad2ecd0d8bc52d0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
