| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
[ChangeLog][QtQuick] Added Window.width and Window.height attached
properties
Change-Id: I3ef590a0d3e6fa660ed88992d5ae843deb09c7bc
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
|
| |
|
|
|
|
|
|
|
| |
This is essential to the Qt Quick Controls for implementing floating
text selection handle popups.
Change-Id: Ibae65110a5db6d65dacd197fef3ad567d11342dc
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An Item sometimes needs to know a few things about the window
in which it is being displayed; this attached property can expose
them without needing to go up the heirarchy to find the window.
Instead of adding the QQuickWindow pointer as a property on Item
as in 8f49f50a169db85401eb37daf4fe3a0fc3280603, having an attached
property means that it will not be found by introspection; and
it solves the problem that Window is in the QtQuick.Window module:
you must import the module to use the attached property, instead
of having access to a pointer whose type might not be defined
if you didn't import it. The Window attached property is created
on-demand (so the memory cost adds up if you use it in too many
places); the tradeoff is that it can exist even when the item
is not yet being shown in a window, so bindings at startup work.
The API is purposely incomplete compared to that in QQuickWindow
so that we can introduce what is needed in a controlled fasion
over time. For now we know of use cases for visibility, active
and activeFocusItem.
[ChangeLog][QtQuick][Window] Added Item.Window attached property
Change-Id: I649404cbd1383326678aa2144f790b2f2542dbbc
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's uncertain why 4fc0df58b8458052a818e3e970a97457882808e6 added
the call to sendPostedEvents(0, QEvent::DeferredDelete) but now we can
see that it easily results in the destructor calling itself, and
therefore double-deleting its own d_ptr. removePostedEvents seems
safer to ensure that the window cannot be doubly deleted, in spite
of the qdoc warning that "You should never need to call this function."
Task-number: QTBUG-33436
Change-Id: I4873ebe179dde551407eba1f6baac5f03ca7f177
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a QML window is created it is set visible after the QQuickWindowQmlImpl component is complete.
This works fine for a single window, but because componentCompleted is called first for the last
created windows, the behavior is not as the user might expect (and different compared to
version 2.0 of the QML Window API). One of the results is e.g. that a window which is created
as a child object in QML will have a lower z-Order than the parent. On some platforms (e.g. BlackBerry)
an even bigger problem arises because the first created window acts as a container for
the whole application and is always shown fullscreen. On other platforms (Linux) the initial window
position and the window focus ares not set correctly.
This patch postpones showing windows until the "transientParent" is visible.
[Changelog][QtQuick] Making a QtQuick Window visible is postponed till its transient parent is visible
Task-number: QTBUG-37440
Change-Id: I09a94ff038c066a5d3298c6c103dafde50bef1fa
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
|
| |
|
|
|
|
|
| |
Change-Id: If18b460a8773e5cac597c02c51836b79711c20f4
Done-with: Matthew Vogt <matthew.vogt@jollamobile.com>
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It was possible for a hover event to be sent to a QQuickItem that has
already been scheduled to be deleted (through deleteLater()). This
lead to an access on an already-freed object when the leave event
is generated. This change ensures that the item is part of a scene
before generating the hover enter event.
Task-number: QTBUG-32771
Change-Id: I69adb6bbd0ae52c70a6bda4e6c918b7671549a4c
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
An application can implement onClosing() and set
closeEvent.accepted = false to delay the closing (for example to
prompt the user to save changes). Depends on change
I9abed47fca02a002b78727f98d678a824854adfc in qtbase.
Task-number: QTBUG-31019
Change-Id: Icfd4a03ecef3621bdbbee2e2c3157b897a9b6524
Reviewed-by: Alan Alpert (Personal) <416365416c@gmail.com>
|
| |
|
|
|
|
|
|
| |
Autotest is included.
Change-Id: I0f8614b502f1e51cab5612fee283c929e078108b
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
Reviewed-by: Liang Qi <liang.qi@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To advance animations in line with vsync, we used a dedicated event
from the rendering thread which we fired immediately after sync. This
is a bit elaborate as we know in Gui when sync is complete and we can
just animate there and then.
This means we can remove all animation logic from the rendering
thread, making it simpler.
I also updated the syncAndRender pass so that it does not render
anything if the scene graph reported no changes during the
sync pass. This will prevent non-visual animations and property
updates from triggering render passes which will save quite a
few cycles.
Change-Id: I62bb5484f0673f99abe726fca5a9b424f6b0a317
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change starts using the superior implementation of the scene graph
render loop which has been worked on in the scenegraph-playground
project for a while. It uses a far more straightforward locking/sync
paradigm compared to the existing one and is less deadlock and error
prone. It also enables the scene graph thread to run on its own when
the GUI thread is blocked, enabling threaded animations.
This changes also introduces a naming change inside Qt Quick from
"Window Manager" -> "Render Loop" as that fits better to what the
code does.
Change-Id: I1c2170ee04fcbef79660bd7dae6cace647cdb276
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
|
| |
|
|
|
| |
Change-Id: I11a28e203c978e5675b088a5bb999c34b46f80da
Reviewed-by: aavit <qt_aavit@ovi.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow a module's qmldir to contain a module directive, which when
present specifies 'strict mode' import processing. In strict mode,
type registrations are only permitted into the namespace identified
in the qmldir file's module directive. In addition, any type
registrations to that namespace originating from other modules are
treated as error conditions.
Task-number: QTBUG-26551
Change-Id: I081bde2d3b83d3f28524440177fb2cd1ccee34ad
Reviewed-by: Chris Adams <christopher.adams@nokia.com>
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
|
|
|
QQuickCanvas is now called QQuickWindow
QQuickCanvas::rootItem is now QQuickWindow::contentItem
QQuickItem::canvas is now QQuickItem::window
QQuickItem::ItemChangeData::canvas is also renamed window
QQuickCanvas::grabFrameBuffer is now QQuickWindow::grabWindow
The functions related to the color property have dropped the clear from
their names.
The first three changes have interim compatibility measures in place to
ease the transition.
Change-Id: Id34e29546a22a74a7ae2ad90ee3a8def6fc541d2
Reviewed-by: Martin Jones <martin.jones@nokia.com>
|
