| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
When setting a new window state. Otherwise we set the geometry based on
the old screen properties, and then rely on the properties causing
another window layout, which may not always happen. We also need to
explicitly update the screen properties when the statusbar changes
visibility, as there are no callbacks from iOS that consistently gives
us that information.
Change-Id: I1c3328aa3f34d294bc7db8884e611d205fd2c761
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
| |
Change-Id: I0098cc4d51ca600ba48baa15ed9c16e56529b947
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Configure QUIView text input traits from IM hints
returned by the focus object when the view becomes
first responder. This will affect the layout of the
virtual keyboard.
Change-Id: Ib140ba69d01cc747f3ac3cdd70dd2e7daede26b0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
| |
CGRect and CGPoint consist of CGFloat variables. So
we should convert to QRectF and QPointF rather than
QRect and QPoint.
Change-Id: I76f180e4064f54d5810c49b88fdbbcd914bdb686
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
| |
This change will let QIOSInputContext scroll the root
view when the virtual keyboard is open, so that the input cursor
is not obscured.
Change-Id: If0758f4bf04c2b8e554e0196451154def7e3cb86
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
| |
Change-Id: I85dda6fc0c6d2d11709b8bcdc0de6c0cef42d40f
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Having it disabled caused issues with our backing-store implementation,
which assumes that the backing store is retained, but for us is backed
by a GL context.
Change-Id: I18d05e226c7cf949adcd3b71801ffd845fa6d83d
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QWidget::show_sys() assumes synchronous geometry behavior by trying to
resize both the platform window and the backing store if the widget's
view of what the geometry is doesn't match the platform window's.
The problem with that is that it's the widget which is not up to date,
not the window, as the widget is not waiting for resize events before
applying any resize logic. Instead of trying to fix widgets, we throw
our hands in the air and give QtWidgets the synchronous behavior it
assumes from the platform.
Change-Id: I1b9241b9b13df661dc7f41c4cb8ecd02f5572256
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
When setting the geometry on our UIView, or when reporting it back to Qt
in our layoutSubviews callback, we need to take into account that the
root viewcontroller may be not be positioned at 0,0 in the screen's
window. Even when using the wantsFullScreenLayout property of the view
controller this may be the case on iOS7 when the in-call status-bar is
visible.
Change-Id: I0ca706c1c9aff8ba4f3b4ccdf83dba713bd5c9c2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Geometry changes may come from Qt itself, or spontaneously from the windowing
system. In both cases we deal with them through the layoutSubviews callback,
which we now ensure gets called after we set a new geometry on the UIView
frame, by using the setNeedsLayout message.
We take care to persist the requested geometry from Qt immediately in our
setGeometry() function, so that subsequent calls to QWindow::geometry()
will report back the requested geometry. Clients can however not rely
on this geometry until they've received a corresponding resize event,
which we trigger from layoutSubviews.
Since the new geometry reported in layoutSubviews may be different from
what the user requested, we ensure to pass on both the new and the "old"
geometry, so that Qt will send the appropriate resize and move events.
Instead of building expose events on top of the existing layout
mechanism provided by iOS, we hook into the more logical point,
which is the display-phase. Since a EAGL view normally doesn't
need to "display" anything this takes a few overrides on UIView.
Once we have the hooks we need, we can distinguish between a QWindow
backing needing layout, and needing displaying.
Finally, we flush both the resize and expose events, as that's what
iOS expects of us when asking us to layout or display. The result
is that Qt is able to synchronously resize subwindows and prepare
new GL rendering for the next frame.
Change-Id: I4c03e3db3fe886163284ba1a342699e217e88cbb
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It breaks down when the view-controller is fullscreen and we want to
take statusbar height into account as well. Unfortunately we can't
use constraints either, as it's iOS6+.
The approach of managing the geometry manually is closer to what
Android does as well.
Change-Id: Ib521ba0f50b110c440ab68aacef5a524d5d41154
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
| |
As tested and assumed by tst_QWindow::isActive().
Change-Id: I8d09263ce0acc9c3390a70b4089396257197a1be
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Change-Id: I4aa1a354ca14864bd9898ebd331871d7b32d3ae0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
We report our swap-behavior as QSurfaceFormat::DoubleBuffer, which means
there's no point in using retained backing. This was a left-over from
when we reported single-buffered swaps, which didn't work to well as
clients would wrongly assume swap was not needed at all.
Change-Id: Id26df2f8b282892c720d48cfe85eb9e010f1500d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QWindow::setParent() is documented to imply that the geometry of the
window is in the parent's coordinate system and that the window is
clipped to the parent.
Instead of always enabling clipping of subviews for our UIView subclass
we dynamically detect if we have QWindow children and enable/disable it
on the fly.
Change-Id: If83de94c55cbd19de401ab835e86bb7be5999d71
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
The default UIWindow may not be the only UIWindow around in a multi
screen setup.
Change-Id: Ia7243190321a1416e577634bf5e010dd67d482e6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the EAGLView view changes its layout, it must send the expose event
along with the geometry change. It is important to notify the render loop
of the scene graph that the windows's geometry has changed. The render loop
is waiting for the WM_Expose event and updates the scene's window size accordingly.
See QSGRenderThread::event for reference.
Without this notification, the geometry of window is updated, but the scene is rendered
incorrectly, for example when the orientation of screen changes.
Change-Id: If102014313de455cb1f44d772b478d2feae6dacf
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
| |
Keeps the internal state of QtGui sane when it comes to which buttons
are active, etc.
Change-Id: Ic63e74d2546469e085ec46b74f4cf159dd409b07
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
| |
Change-Id: I0d345d07fe62a8c7844333bf1eed9be6d6fa432f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
| |
Matches the cocoa QNSView and highlights the relation to UIView.
Change-Id: Idcdb17bff994c1e0aef099400c21915a7041e44c
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
| |
Matches the wording using in QWidget.
Change-Id: Ifbb4e5ffa90b47a7c179cf9ec52cb46126d7bccc
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We did not do this from before. Instead we would activate
the window when it's view became first responder. And this
would happen when the input panel was told to open.
That behavior is a fragile, since other layers higher
up (qml) would not open the input panel unless the window
was active, which also makes sense. A classic chicken and
egg problem.
So to play more along with how Qt is expected to work, we
change behavior to instead activate the window directly
when requested to do so (which also includes when the user
touches the window directly). This will also work better
for "keyboard" events like Key_VolumeUp, once implemented.
The down side is that Qt will give focus to widgets/items
(and as such, open the keyboard) whenever you touch the
window. But that is easier to fix, and will be dealt with
in later patches.
Change-Id: I9bbeb0205e7ea3c5079100c07e40ddb1c60b476b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
|
|
|
|
| |
Change-Id: Ifdfd5881822bf56f2c8ab0742a0e257e2bd61533
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
|
|
|
|
|
|
|
| |
UIViews can return nil when calling qwindow, so we must check before
trying to use the QWindow handle.
Change-Id: I72e9ddc58ebe10a3e7ea511f2356650402ba23f4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems that 130ee40b broke touch handling for
non-alien QWindows. For those cases, a QWindow that is a
child of another QWindow will get its own UIView to
back it up. The current code did not take this into
account when calculating the global coordinates of
touch events. Instead we need to search for the
top level QWindow it might be inside before we find the
view that acts as the "desktop" for it.
Change-Id: Ie3c19bf86c92fa3f247a0764116830e91b8322d2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of deactivating the window when we resign first
responder status, we now leave it focused, and
tell it to clear its focus object instead.
This will work better with the rest of Qt, which expects
a window to have focus when its in front.
Change-Id: I6fcc232467af306b791a834f4843bfd2786b206f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This patch simplifies the implementation of touch events to use a
views superview for calculating global touch coordinates rather than
the screen. This removes the need for taking orientation
into account, and will also play better along in a mixed environment.
This will also fix touch events reported for inverted orientations.
Change-Id: I0c8fd8745a1f65f0f4a97447a5676a38165ed032
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: I971df06dd348d1da68578e04076a02e85866e141
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: I1a413d898d10b55a4d0653eae719f5bd909a01ec
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|