| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation of QOpenGLContext sharing assumes that the
contexts form a tree and that leaf-nodes are destroyed before their
parents.
We build on this assumption and keep track of the default FBOs for
windows in the root context of the tree. This allows two shared
contexts to both makeCurrent() on the same window surface without
resulting in two FBOs being set up (which doesn't work on iOS due
to the CEAGLLayer already being tied to another render-buffer).
Change-Id: Ib9f8c597effe488480fe99e10846be22c257f490
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
While the user is touching the screen, postpone scrolling
until we get a touch release. Scrolling in the middle of
a touch sequence will change the coordinates under the
touch, and cause some artefacts.
Change-Id: I02ef420abaab780a459f014d4b4cfb75c8fbb725
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On iOS we have set the style hint 'SetFocusOnTouchRelease'. This is in
conflict with the 'hide keyboard' gesture, since a control can
try to regain focus (and open the keyboard) if the gesture ends
on top of it. So we need some extra work-around code to prevent this
from happening.
The correct way would probably be to cancel the touch sequence once
the gesture triggers, but this is not well implemented in Qt yet,
especially in combination with widgets and mouse synthesis.
Since usage of the gesture behaves really bad in some cases (e.g
if using the TextEdit example) we need to apply this for now.
Change-Id: Ib3327c0bd94d722b4c4793bc6d152d6d19810e4b
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you show/hide the keyboard quickly while we scroll the
screen, the scroll will appear to jump. The reason is that
the screen animation will start from where the model layer
is at, and not the presentation layer. So specify that
the animation should start from the current state of the
presentation layer.
Change-Id: I3db87ab11aab583eb50784b0c0a03a9a07c8b822
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you resign/become first responder several times
while the keyboard is animating (e.g changing focus between
focus objects while the keyboard is animating), iOS will
short-cut the whole animation, and jump directly to
keyboard end-state. For that reason, we always need to handle
keyboardRectChanged, and not bail out early. This is
fine, since the guard we had was really only meant for
keyboardWillShow/Hide in the first place.
Change-Id: I3a3d1e7061962286c538360029ed38410dc0f347
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no need to create a hidden window to get a surface on iOS, as
the platform supports FBOs. Note that defaultFramebufferObject() returns
0 in the case of offscreen surfaces, which is technically not a valid
FBO on iOS due to the indirect rendering, but binding and rendering
to the zero-FBO seems to be no-ops, so clients may safely call eg
glBindFramebuffer(GL_FRAMEBUFFER, ctx->defaultFramebufferObject())
to restore the default FBO after drawing to its own FBO.
Change-Id: I2e67f5d69c0698562052f5ac1df0bbfaa3337148
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Khronos documentation for glCheckFramebufferStatus recommends calling
the function to see if the framebuffer is complete prior to rendering.
We now give more info to clients that call makeCurrent(), by storing the
state of the default FBO and returning that, instead of always returning
true and leaving the clients vulnerable to calling OpenGL functions on a
non-complete FBO.
Change-Id: Ia99c21f811ac799b350f07e73b2ae4b173d71120
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
We need to send key events when the user hits enter, otherwise
there is no way to know when the user has 'confirmed' the
text he wrote. This is on par with how it's done for the
Android port.
Change-Id: I585d4198de24b0d251e5e0dd2956ce81b6483f82
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch there were no way for the user to hide
the keyboard on iPhone for multi-line edit fields unless
the app had a separate button added for it. And even that
would be problematic since we scroll the screen (and
perhaps the button) to track the cursor.
This patch implements a gesture that resembles the 'hide
keyboard' gesture that UIScrollView implements on iOS 7.
Note that if you start the gesture inside the edit field,
you will start selecting text as well. This will also cause
the cursor to move and the screen to scroll. After some
testing and failing, it seems like we need to live with such
artifacts until we do get around to do the only sensible thing;
fix up how we do text selection on touch platforms. Working
around it becomes just to messy.
Change-Id: I1c0d9c88ff1f5430587a49591f165b9708e5dc60
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
On iOS 7.1 [UIScreen screens] sometimes returns empty NSArray which
is against documentation and causes immediate application crash.
This workaround uses [UIScreen mainScreen] in case [UIScreen screens]
returns empty NSArray.
Task-number: QTBUG-37601
Change-Id: I9b341b9ca788b5fc81804489d2e0a3af84207168
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
When we scroll, the keyboard will change position relative
to QScreen, even if it appears to stay put. For that
reason we also need to update the keyboard rect after
doing a scroll.
Change-Id: I9bda2ab5b5e4970f488d3e69e44cf58e273f8fcd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
| |
This will implement support for copy/paste operations
inside, and between, applications.
Change-Id: I50031b89bdb07f106950dc90fb8b1accbd1191bb
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
| |
Change-Id: I0fd4e5e8d561826841cc78b26cd524ba01a8b689
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
For some reason, the [] access into NSDictionary causes
a crash on iOS 5. So instead use the API as listed in
the documentation: objectForKey.
Task-number: QTBUG-36532
Change-Id: I19fdf0f4ba1aebaf9477e2bd45040c389923605d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Qt documentation says that PortraitOrientation is rotated 90 degrees
clockwise relative to LandscapeOrientation. This means that the home
button should be on the right when held in LandscapeOrientation,
therefore, Qt::LandscapeOrientation == UIDeviceOrientationLandscapeLeft.
Without this patch, all QScreen mapping functions are broken.
Change-Id: I2c570cd0307b7fbd59c749d6574dcb258790cfbc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From before we would activate all QWindows that the user
tapped on, or setVisible were called on. This is wrong
since a QWindow does not have to be a top-level window.
For a non-alien widget application this would mean that
we would send activation events for all widgets that the
user tapped on all the time.
With this patch we do some extra checking before we
tell a QWindow to activate.
Change-Id: I1afe97e5384c36c67fee0bbd070d880bba7528a1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to activate a window on touchesBegan instead of
touchesEnded. The reason we used to do this on touchesEnded was
to delay activating a window in case the user started e.g a
flick. But delaying the activation can cause problems if the app
activates a different window on press. We will then cancel
this out on release since we then raise the pressed window instead.
This is e.g typical when opening popups, and will cause focus to
not be restored properly when later closing the popup again.
Change-Id: I709b2f2e2633c9dc85c2761b0b176cd23c2f6b36
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes focus object is updated after we get a
callback that the cursor rectangle has changed. And
there is no reason to keep a local reference to it.
Since we also send events to the qApp->focusObject from
UIView_textInput, we now end up more consistent.
Change-Id: I3976175aae4e3f346be9bc5b771ac0fdefc03ae6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
UITextView has a property for specifying which UIView the CGRects
you return should be aligned with. This makes a difference for
widgets when not using alien, since then the view that draws the
text will usually not be the same as the view that backs
the top level QWindow.
Change-Id: I240d63c98544c39308cd91465ee84351e7d7d1f4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
| |
No need to call textWillChange all the time if the text is
really not changing. And report that selectionWillChange
when Qt reports that it has changed.
Change-Id: I7bd9f540cd9302c37888926a6152b803cc871ccb
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
By returning the font used at the cursor position, the
correction pop-up will be resized to match the
point size, and the text marking will get correct
height.
Change-Id: I362579b793794835323bb9ceb5ddb4655526f392
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For legacy reasons, we send IM events to the focus
object directly instead of through QPA. To be consistent,
and to ensure that IM and key events end up at the same
object in the same order, we need to send key events
directly to the focus object as well.
We should consider fixing up QPA to support IM events
better, but this will do for now.
Change-Id: I8a18a1f7b7295e5c64a109fb98eee928fae06a0f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sending faked key events is not such a good idea, since:
1. We don't get key events on iOS, but text events
2. We cannot determine correct key code or modifiers, nor
do we want to fake modifer press/release etc.
3. Android uses IM for all text input
So it seems that the correct solution is to avoid sending
key events in the first place. This will also bring the iOS
port on par with the Android port.
Change-Id: Ibac1d335184e62eb4185cfd4218a0ec73dffb2c4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
| |
We don't have a separate enum just for spell checking in Qt, but
Qt::ImhNoPredicitiveText should cover it. So use it
to enable/disable both spell checking and auto completion.
Change-Id: I7ad661cb7d720988f13bc1ed940573006c0ce229
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
| |
This change will add support for input methods, word
completion, spell checking and related functionality.
Change-Id: I41d4de1cab521c679d414cfc7c1a2d0f9c1fcaaf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
| |
Change-Id: I62c588226b307d51f7f88b1cc0c1e00c0d0f14c6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
| |
Change-Id: Idc90d85859229d49b1deecc2472b330f0adb1ef8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation will stop scrolling the screen to reveal
the cursor if the input item changes transformation. This to not
interfere with flicking etc. This strategy turns out to be too
strict, as some qml apps/games can easily have small animations
applied (e.g qtquick cork board example) that moves or scales
the text areas (or their parents) upon focus.
So instead of relying on input item transformation, we now
scroll whenever the cursor changes position inside the input
item (in addition to orientation changes etc). We also
refactor scrollRootView into two functions, since we in
many cases know if the keyboard should scroll up or down
already when the call is made.
Change-Id: If5bf349139eed69823cfc8986bb4b32c93bdf91b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
| |
Might be useful to expose to QWindow in 5.3, but for now it's private
so it can be used by platform plugins.
Change-Id: Iad96d7e249a7b85695668f8d7e8918164ec67442
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
| |
Change-Id: If082be4b5c50cd5e1d5660bbe26136b9a0ee0352
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Processing the object file with ld strips away debug information for
the main() function, resulting in the debugger not being able to
break on specific lines of the function.
It also causes issues when externing sybols in main's object file.
We revert back to the approach of using the strings in-line in the
object file (which is why we keep the name the same length, 'qtmn').
Task-number: QTBUG-35553
Change-Id: I8b0acee36f48ecfefa2e4fd008a842365713d985
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
| |
Change-Id: Ib7dc8dcbeca7e85d97b8c7fb04d2cf42e5245298
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
| |
This will tell QtQuick.Dialogs not to use native windows for dialogs.
Change-Id: Ie2e5878b84a9597e1f730d2cb1ebe2f59be6bc75
Reviewed-by: Liang Qi <liang.qi@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In layoutSubviews we take the root viewcontroller position into account
when determening the new QWindow geometry, but we were missing this logic
in displayLayer, and would assert if the in-call statusbar was visible.
Since we don't really need the position of the window in displayLayer,
we change the assert to only check the size of the exposed area, which
is independent of the position of the root viewcontroller.
Change-Id: I774b8d9b075518e729f488a789b3a9e584c3f4d3
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
configure
mkspecs/macx-ios-clang/features/default_post.prf
tests/auto/widgets/widgets/qmenu/tst_qmenu.cpp
Change-Id: Iaba97eed2272bccf54289640b8197d40e22f7bf5
|
| |
| |
| |
| |
| | |
Change-Id: If237f08683290105413dc47923e23a496765bb22
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently there is no way to always hide the statusbar
on iOS other than showing a window in fullscreen. This
patch will check if the statusbar is (initially) hidden
from the Info.plist, and respect that in the application.
SubAttack is an example of an app that (because
of styling issues with MainWindow margins) manually
sets the geometry larger than fullsreen, and calls
showNormal(). In that case we still want the statusbar to be
hidden.
Change-Id: Ia365d14971978360d0b39621ff0f8f82f74b57e2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Going through the platform window failed when the parent wasn't created
yet. We can still get the window state of an yet-to-be-created top level
window.
Change-Id: Iaa61ddc50df037ac0bd2fd0884884c2bfce1dd9a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Qt defaults to creating a QWindow as offscreen surface
if QPlatformIntegration::createPlatformOffscreenSurface
returns 0. Using an offscreen surface is often done
in a background thread, which is problematic, since then
a QIOSWindow will also be created in a background thread.
According to Apple docs, working with a UIView from other
threads than the main thread should not be done. In our
case, we instead hit an assert in QApplication that
checks for the same.
As a quick fix for Qt 5.2, we remove the offending call that
causes the assert, since we anyway will call the same function
lazily when becoming first responder.
Task-number: QTBUG-35378
Change-Id: Id35462f99783a9748c688b163f6497de9bfff73e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The drag and drop event filters do not play nicely with touch events
or virtual keyboards.
Task-number: QTBUG-35348
Change-Id: Id4d079ae72882f48750d394f13e10700d60e4532
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It turns out we cannot rely on QGuiApplication::focusWindow() to
be non-zero at all times (e.g when pop-ups are closing etc).
So instead use m_focusView.qwindow which points to a
valid QWindow. This window is the same as QGuiApplication::focusWindow
most of the time, except when a focus window closes.
For those cases we get a new call to scrollRootView immediately
after with m_focusView updated to reflect the new focusWindow.
Task-number: QTBUG-35339
Change-Id: Icb3a8d3140af1f1904495a9289c8c26ab79e70f6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An application will sometimes crash if the keyboard
is told to hide while the application is about to
quit. This patch will ensure that we set m_qioswindow
(and [UIView qwindow]) to 0 when the window is destroyed.
We also check this pointer before telling QUIView to
resign first responder when closing the keyboard. The
latter will fix the crash.
Task-number: QTBUG-35356
Change-Id: I934088beb7e877c5b33d96225cb215a8ffd4dbb2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QIOSInputContext controls QUIViews first responder status
based on whether or not the keyboard should be open.
But since QGuiApplication updates focusObject before
focusWindow (when e.g a popup closes), we sometimes ended up
activating the old window upon a call to becomeFirstResponder.
This in turn led the application to hang because of
recursive dependencies in qioscontext when the focus window
changed.
So the solution for now is to avoid activating the window
when the view becomes first responder. This should be
fine since we now activate the window from
QIOSWindow::requestActivateWindow (ref: 6272a816d1)
Task-number: QTBUG-35340
Change-Id: I3068c14fec18d84d4b0b348a043c4c054e366c75
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a platform window is created from a QWindow without setting a valid
size or position on the QWindow, the platform window is expected to
apply sane defaults. We use the baseclass initialGeometry() function
for this, similar to other platform plugins.
The default geometry unless otherwise set and/or calculated based on
size hints is that of the screen's available geometry.
An improvement to this is to detect whenever we apply the screen
geometry, and also apply the appropriate window state, but that
needs more testing.
Change-Id: I02b12064ce6d55c04fe0cc2cd1d2816ca1113f40
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When sending expose events to Qt, Qt will ask us if we're exposed,
and we need to tell it that we're not, so that clients will not try
to makeCurrent on a CA layer that has a zero width and/or height.
Note that this only works because we flush expose events.
Change-Id: Idfbe03a2f35681084061376a3c650a8da027fda4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|/
|
|
|
|
| |
Change-Id: Iff44698dcc941ca244b476f0e6c6a993f2ad75f3
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
|
|
|
|
| |
Ideally we'd have a callback from iOS when this happens, so we can also
react to changes done outside of Qt, but willChangeStatusBarFrame and
friends do not seem to give us what we want.
Change-Id: I686ce7950395a83c4257372363c773a95c3935ed
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The user may use QDesktopServices::setUrlHandler() in combination with
the appropriate Info.plist keys (CFBundleURLTypes, CFBundleURLSchemes)
to react to URL requests from other applications.
This is among other things useful for handling OAuth authentication from
applications such as Dropbox. See:
https://www.dropbox.com/developers/core/start/ios
We protect against recursive URL opening, but an application may still
redirect a request to open a URL by opening another URL, eg a website.
Task-number: QTBUG-35201
Change-Id: I9f1d246206c5594b1b65bb11fa98c6bcdefc443e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
A window that was resized to the full screen size of the screen would
otherwise always stay in full screen, even if the window state was
maximized.
Change-Id: I4720f7b6ad1d85658ea96c6da0515693e8c827f3
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|