aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickwindowmodule.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-05-051-2/+14
|\ | | | | | | Change-Id: I0e495f3d59f2a507aeb73c013e1d8ec0668313c4
| * Fix visibility of qml window in qquickwidgetMichal Klocek2020-04-241-2/+14
| | | | | | | | | | | | | | | | | | | | Add handling for the case where transient window is a offscreen window from qquickwidget. Fixes: QTBUG-82815 Change-Id: Ia121c8477afab8f69e28da4dbdd836f9c7243b2b Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Encapsulate QQmlContextDataUlf Hermann2020-03-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This class is not a private detail of QQmlContext. And it is incredibly hard to see who owns what in there. Let's add some civilization ... We enforce refcounting for QQmlContextData across the code base, with two exceptions: 1. QQmlContextPrivate may or may not own its QQmlContextData. 2. We may request a QQmlContextData owned by its parent QQmlContextData. For these two cases we keep flags in QQmlContextData and when the respective field (m_parent or m_publicContext) is reset, we release() once. Furthermore, QQmlContextData and QQmlGuardedContextData are moved to their own files, in order to de-spaghettify qqmlcontext_p.h and qqmlcontext.cpp. When the QQmlEngine is deleted, any QQmlComponents drop their object creators now, in order to release any context data held by those. Before, the context data would be deleted, but the object creators would retain the dangling pointer. [ChangeLog][QML][Important Behavior Changes] QQmlContext::baseUrl() does what the documentation says now: It prefers explicitly set baseUrls over compilation unit URLs. Only if no baseUrl is set, the CU's URL is returned. It used to prefer the CU's URL. Change-Id: Ieeb5dcb07b45d891526191321386d5443b8f5738 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* | Introduce new mechanism to manage palette functionality in QMLVitaly Fanaskov2020-03-161-19/+12
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Main goals of these changes: 1) Add an ability to work with disabled and inactive palettes from QML 2) Eliminate massive code duplication in qtquickcontrols2 module 3) Provide easily extensible architecture for this piece of functionality Architectural part. Palette It was decided to not change existing QPalette, but add thin wrappers around it to provide all required functionality. These wrappers are highly coupled with QPalette class because of using some enum values from it. There are two new classes QQuickPalette and QQuickColorGroup. QQuickPalette class inherits QQuickColorGroup class and represents Active/All color group. QQuickPalette also provides an access to three color groups: Active, Inactive, and Disabled. In order to access colors the special class QQuickPaletteColorProvider is used. This is a wrapper around QPalette that provides some convenience functions. Interface The private property "palette" should be exposed. Implementation All private parts of classes that implement QQuickAbstractPaletteProvider have to inherit QQuickPaletteProviderPrivateBase class. This template class implement all functionality: create palette, resolve dependencies, connect objects etc. This is important to mention that related data is lazily allocatable on demand only. Hence, there is no memory overhead for regular items. Change-Id: I911424b730451b1ad47f68fd8007953b66eddb28 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Move type declarations for QtQuick.Window* into imports/windowUlf Hermann2019-10-151-13/+1
| | | | | | | | | We want only one URI per library or plugin, so that we can centrally register the types. Change-Id: Ibc7305f102503ce672f8751771779102be44e014 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Specify parameters of type registration in class declarationsUlf Hermann2019-09-261-13/+4
| | | | | | | | | | | | | | | | | | | | | Using this technique we can automatically register all necessary revisions and minor versions of a type, using the metaobject system. This greatly reduces the potential for mistakes and resulting incompatibilities between versions of imports. We assume that for each type we need to register all revisions of its super types and its attached type, and that the revisions match. That is, if you import version X of type A, you will also get version X of its attached type and of any super types. As we previously didn't take these dependencies into account when manually registering the types, a number of extra revisions are now registered for some types. Potentially, we can now generate the qmltypes files at compile time, using moc. Change-Id: I7abb8a5c39f5e63ad1a0cb41a783f2c91909491b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Harmonize meta object revisions and minor versionsUlf Hermann2019-08-261-4/+4
| | | | | | | | | | In order to avoid complexity we want those to match. We can easily "rename" the meta object revisions as those are not public interfaces. Change-Id: I48e063d49758c7bacd9b7816bf5541cf67e07b0d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add the graphics api independent scenegraph portLaszlo Agocs2019-07-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Opt in via environment variables: QSG_RHI=1 -> enable using QRhi instead of GL QSG_RHI_BACKEND -> set to vulkan, metal, d3d11, gl to override the default (the default is d3d11 on Windows, metal on Mac, gl elsewhere) Or force a given rhi backend via the existing QQuickWindow::setSceneGraphBackend(). Otherwise the default behavior is the same as before, the rhi code path is never active by default. -no-opengl builds are supported in the sense that they work and default to the software backend. However, the rhi code path cannot currently be used in such builds, even though QRhi from qtbase is fully functional with Vulkan, D3D, or Metal even when qtbase was configured with -no-opengl. This cannot be utilized by Quick atm due to OpenGL usage being all over the place in the sources corresponding to the default backend, and those host the rhi code path as well. This will be cleaned up hopefully in Qt 6, with the removal all direct OpenGL usage. Other env.vars.: QSG_RHI_DEBUG_LAYER=1 -> enable D3D debug or Vulkan validation layer (assuming the system is set up for this) QSG_RHI_SHADEREFFECT_DEBUG=1 -> print stuff from ShaderEffect QSG_SAMPLES=1,2,4,... -> MSAA sample count (but QSurfaceFormat works too) QT_D3D_ADAPTER_INDEX=0,1,... -> D3D adapter index QT_VK_PHYSICAL_DEVICE_INDEX=0,1,... -> Vulkan physical device index QSG_RHI_UINT32_INDEX=1 -> always use uint index data (both merged/unmerged, convert when needed - with some rhi backends this is implicit) QSG_RENDER_LOOP -> to override the render loop as usual. The default with RHI is threaded for Metal, threaded for Vulkan on Windows, basic for Vulkan on Linux and Android (to be checked later), while the existing rules apply for OpenGL. Not supported when running with QRhi: - particles - compressed atlases (though this is transparent to the apps) - QSGRenderNode - QQuickRenderControl - QQuickFramebufferObject - certain QQuickWindow functionality that depends directly on OpenGL - anisotropic filtering for textures - native text may lack some gamma correction - QSGEngine applicability unclear - some QML profiler logs may be incorrect or irrelevant Change-Id: I7822e99ad79e342e4166275da6e9e66498d76521 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Register Window.transientParent, track user-code overridingShawn Rutledge2018-11-131-1/+5
| | | | | | | | | | | | | | | | | When QtQuick "magically" guesses the transient parent relationship from nesting of declarations, it calls QWindow::setTransientParent(), which has been public C++ API all along. Now there is a new transientParent property; the setter is QWindowPrivate::setTransientParent(), which sets a flag. If the flag tells us that user code (e.g. QML) has set the transientParent property, we assume the user is overriding the magic, and we can also allow user code to set the window visible immediately, rather than waiting for its transient parent to become visible. Task-number: QTBUG-67903 Task-number: QTBUG-52944 Change-Id: Ia4d303263d387931d2051b2a950694a48ad5e541 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Merge remote-tracking branch 'origin/5.10' into 5.11Liang Qi2018-02-121-4/+11
|\ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/imports/shapes/qquickshape.cpp src/imports/shapes/qquickshape_p_p.h src/qml/compiler/qqmlpropertycachecreator_p.h src/qml/jsruntime/qv4value_p.h src/quick/items/qquickloader_p.h tests/auto/qml/qqmlecmascript/tst_qqmlecmascript.cpp tools/qmlprofiler/qmlprofilerapplication.cpp Change-Id: Iafc66ae84bf78630ed72a986acb678e9d19e3a69
| * Merge remote-tracking branch 'origin/5.9' into 5.10Liang Qi2018-02-021-4/+11
| |\ | | | | | | | | | Change-Id: I41ca9120a470a905c2f5c168c1de4cf970fa0fff
| | * If Loader loads Window, set its transient parent to the Loader's windowShawn Rutledge2018-02-021-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes the Item { Loader { sourceComponent: Window { } } } case consistent with the Item { Window { } } case: the inner Window is transient for the outer Window. It works even if the Loader's Window has a visible: true declaration: in that case, until now, the Loader's Window would become visible at component creation time, before the outer Item became visible. So the test to check whether it had a transient parent did not work. We now change the delayed-visibility mechanism in QQuickWindowQmlImpl to wait for the parent Item to acquire a window of its own rather than waiting for the transient-parent-if-any to become visible. It should still take care of all the old cases too, e.g. in the Window { Window { } } case, the inner Window's QObject parent is actually the QQuickRootItem. (Amends 701255c76f671f100338a799f0194bf10e26c9d1) [ChangeLog][QtQuick][QQuickWindow] When a Window is declared inside another Item or Window, the window will not be created until the parent window is created. This allows it to have the correct transientParent and be managed as a transient window. Task-number: QTBUG-52944 Change-Id: Iaf4aafbd696f6e8dd0eec1d02db8bd181483bd07 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | | Merge "Merge remote-tracking branch 'origin/5.10' into dev" into ↵Shawn Rutledge2018-02-061-0/+2
|\| | | | | | | | | | | refs/staging/dev
| * | Merge remote-tracking branch 'origin/5.9' into 5.10Liang Qi2018-01-241-0/+2
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/qml/compiler/qv4codegen.cpp src/qml/compiler/qv4compileddata_p.h src/qml/debugger/qqmlprofiler_p.h src/qml/jsruntime/qv4engine.cpp src/qml/memory/qv4mm.cpp src/qml/qml/qqmlcomponent.cpp src/qml/qml/qqmlobjectcreator.cpp src/qml/qml/qqmlobjectcreator_p.h src/qml/types/qqmldelegatemodel.cpp src/quick/items/qquickitem_p.h src/quick/items/qquickwindow.cpp tests/auto/quick/touchmouse/BLACKLIST tests/benchmarks/qml/holistic/tst_holistic.cpp Change-Id: I520f349ab4b048dd337d9647113564fc257865c2
| | * Add new logging category qt.quick.window.transientShawn Rutledge2017-12-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to monitor the increasing number of places from which the transient parent relationship can be detected; and a debug operator for QQuickWindow so that these log messages are more useful. [ChangeLog][QtQuick][QQuickWindow] added logging category qt.quick.window.transient to check detection of transient windows declared inside other Items and Windows Change-Id: Ic899af648765fcdc59b8da7dd1f1bed20db300f2 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* | | Remove double indirection between QJSEngine and QV4::ExecutionEngineUlf Hermann2018-02-021-1/+1
|/ / | | | | | | | | | | | | | | As QJSEngine's handle() method is internal, we can redefine it to return a pointer to an ExecutionEngine. That makes many things easier. Change-Id: Ie3df99e0bad5f00ad4fe73182896cd135fa82994 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Merge remote-tracking branch 'origin/5.9' into devSimon Hausmann2017-07-281-2/+0
|\| | | | | | | Change-Id: I7d092cce33cb009d63e7b0df7c71183089dea53f
| * QQuickWindowQmlImpl: declare attached properties in the headerJ-P Nurmi2017-07-171-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | QQuickWindowQmlImpl is inherited by QQuickApplicationWindow in Qt Quick Controls 2, which must register revisions (qmlRegisterRevision) in base classes to make revisioned base class members available in AppWindow. The fact that QQuickWindowQmlImpl provides attached properties must be declared in the header so that qmlRegisterRevision<QQuickWindowQmlImpl> in Qt Quick Controls 2 does not lose the Window-attached properties. Task-number: QTBUG-61935 Change-Id: I634c8fe980b06279610953d9ded2c27d8627d5ea Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Add screen product informationPier Luigi Fiorini2017-05-231-0/+1
|/ | | | | | | | | | Add information such as manufacturer, model and serial number that is now available on QScreen to the Screen attached property. [ChangeLog][QtQuick][Screen] Add manufacturer, model and serial number. Change-Id: If8f33dffa5eff33111f93212249424b9092250b8 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Run includemocs in qtdeclarativeThiago Macieira2017-04-261-0/+2
| | | | | Change-Id: I84e363d735b443cb9beefffd14b8c023a37aa489 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Rename Window.targetScreen to screen, and pick up changes to the screenTor Arne Vestbø2017-02-111-16/+6
| | | | | | | | | | | The screen property can be used for both setting the initital screen, and for reading out the current screen, so 'targetScreen' was not an ideal name for this property. Change-Id: I1b617085b1e8e0e437355740be5d3cee9379c47f Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Make it possible to call grabToImage() on Window.contentItemOleg Yadrov2017-01-021-0/+3
| | | | | | | | | | Window.contentItem was not associated with any QQmlContext and QQmlEngine. A valid pointer to QQmlEngine is needed for callback function execution. Task-number: QTBUG-57175 Change-Id: Iab7730bfc8860521ff2e8c1631a11d0e1fe0cf94 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Merge remote-tracking branch 'origin/5.8' into devLiang Qi2016-10-181-4/+4
|\ | | | | | | | | | | | | | | | | | | Conflicts: src/qml/jsruntime/qv4variantobject.cpp src/qml/types/qquickworkerscript.cpp src/quick/scenegraph/util/qsgdefaultpainternode_p.h tools/qmljs/qmljs.cpp Change-Id: I876242714ec8c046238d8fd673a5ace2455b2b59
| * Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-10-041-4/+4
| |\ | | | | | | | | | Change-Id: I48764527fa1ab6d8d59c24552394459b1cdc58ee
| | * Fix crash with window-less QQuickItemsSimon Hausmann2016-09-301-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mark QQuickItem visual children directly in QQuickItem instead of relying on the item being a (grand) child of a window. [ChangeLog][QtQuick] Fix crash with QQuickItems created via JavaScript being garbage collected sometimes when they're not assigned to a window. This may happen even in qmlscene when between the creation of the root item and the assignment to the QQuickWindow the garbage collector runs. The previous approach of a persistent in QQuickView marking the visual item hierarchy relies on the existence of a view. The only thing left to do in the view and qml window implementation is enforcing the CppOwnership policy set on the content item in QQuickWindow by ensuring the presence of the JS wrapper, replacing the persistent with a weak value. This also introduces a new internal mechanism for QObject sub-classes to provide their own V4 JS wrapper types. Task-number: QTBUG-39888 Change-Id: Icd45a636a6d4e4528fc19165b13f4e1ca7967087 Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
* | | Enable making window-screen associations from QMLLaszlo Agocs2016-10-101-0/+25
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Qt Quick provides a Screen attached property to query information about the screen an item's window belongs to. This is a good start, but has two problems: it lacks some virtual desktop related info (e.g. the position in the virtual desktop) and it cannot be used in combination with the Window element in order to achieve a QML equivalent of QWindow::setScreen(). Therefore add the missing virtualX and virtualY properties and introduce Qt.application.screens. The latter is an equivalent to QGuiApplication::screens() and is a JS array the elements of which can be set as the value of the new Window.targetScreen property. This means that a call like window->setScreen(QGuiApplication::screens()[0]) translates to Window { targetScreen: Qt.application.screens[0]; ... } when using the Window type from QML. Screen addition or removal can be acted upon via onScreensChanged. QQuickScreenAttached has been split into two in order to allow reusing the QScreen wrapping queries for other purposes as well. Task-number: QTBUG-56115 Change-Id: I4b2fbd873315b40d0afe878da2fc50966c00e2e0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | Fix changing QML Window visibility in Component.onCompletedRobert Griebl2016-04-181-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Creating a transient QML Window with visible set to false and then trying to show() it in Component.onCompleted led to a race condition where the window would be shown for a brief moment and then hidden again to enforce the delayed initialization of the visible property. Fixed by tracking the value of the visible property regardless of the 'completed' state. The same problem was fixed for the visibility property. Task-number: QTBUG-52573 Change-Id: I2a2ed7f359b951cb9189a7a6628d1d0cc1445d73 Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
* | Updated license headersJani Heikkinen2016-01-191-14/+20
|/ | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: Ic36f1a0a1436fe6ac6eeca8c2375a79857e9cb12 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Speed up object creationSimon Hausmann2015-04-161-2/+2
| | | | | | | | Avoid copying url and file name twice into the context every time we instantiate an object. Change-Id: I1c76b80b9c44f95512af5899d760151f6dcd7bb5 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Update copyright headersJani Heikkinen2015-02-121-7/+7
| | | | | | | | | Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9 Reviewed-by: Iikka Eklund <iikka.eklund@theqtcompany.com>
* Let ApplicationWindow inherit QQuickWindowQmlImplJ-P Nurmi2015-01-241-107/+104
| | | | | | | | | Inheriting QQuickWindow would mean that ApplicationWindow would have to duplicate all that visibility and root item marker related code. Change-Id: I3b58631011a88d6a079c091db08215f2eef6df84 Reviewed-by: Alan Alpert <aalpert@blackberry.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
* Move data for objects in QtQuick into the Heap namespaceLars Knoll2014-11-111-1/+1
| | | | | Change-Id: Ic9d5946a8e60d235b8442b964dd1478363626441 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Merge remote-tracking branch 'origin/5.4' into devFrederik Gladhorn2014-10-091-4/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/quick/items/context2d/qquickcanvasitem.cpp src/quick/scenegraph/coreapi/qsgbatchrenderer.cpp src/quick/scenegraph/coreapi/qsgrenderer.cpp src/quick/scenegraph/qsgadaptationlayer.cpp src/quick/scenegraph/qsgrenderloop.cpp src/quick/scenegraph/qsgthreadedrenderloop.cpp src/quick/scenegraph/qsgwindowsrenderloop.cpp src/quick/scenegraph/util/qsgatlastexture.cpp src/quick/scenegraph/util/qsgtexture.cpp src/quick/util/qquickprofiler_p.h Change-Id: Ie274c3baf72a8a0711c87d67238d68e2b2887429
| * move QQuickWindowAttached to QQuickWindowQmlImplShawn Rutledge2014-09-241-4/+7
| | | | | | | | | | | | | | | | | | | | It causes problems to do qmlRegisterType on QQuickWindow if the attached property also refers to QQuickWindow. Task-number: QTBUG-40816 Task-number: QTBUG-41047 Change-Id: I7a6f75af52f65e2be022b97128702982bec7cbe8 Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
* | Merge remote-tracking branch 'origin/5.4' into devOswald Buddenhagen2014-09-111-19/+11
|\| | | | | | | | | | | | | | | | | Conflicts: src/quick/items/qquickpainteditem.h src/quick/items/qquickshadereffectsource.cpp src/quick/items/qquickshadereffectsource_p.h Change-Id: If98096443afe85fc4370cef971eace050006a61b
| * Update license headers and add new licensesJani Heikkinen2014-08-251-19/+11
| | | | | | | | | | | | | | | | | | - Renamed LICENSE.LGPL to LICENSE.LGPLv21 - Added LICENSE.LGPLv3 & LICENSE.GPLv2 - Removed LICENSE.GPL Change-Id: I84a565e2e0caa3b76bf291a7d188a57a4b00e1b0 Reviewed-by: Jani Heikkinen <jani.heikkinen@digia.com>
* | Add Q_DECL_OVERRIDEAlbert Astals Cid2014-08-141-2/+2
|/ | | | | Change-Id: I2e64950aef710f943c3bc50bc9bf8a1f7fb58d28 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
* Add Window attached property on ItemShawn Rutledge2014-08-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Start implement new Object creation patternLars Knoll2014-07-221-1/+1
| | | | | | | | | Create objects through a static create() method that returns a pointer to the objects Data. This will later on simplify breaking the direct connection between Object and Object::Data. Change-Id: Id8daa3c766429bc36f432868e1957846147c96b6 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Update qmltypes filesAlan Alpert2014-05-061-0/+1
| | | | | | | | | | | | | Additionally, fixes some revisioning errors which a manual inspection of the qmltypes files diffs revealed. -mipmapChanged signal is new -windowTitleChanged signal is new -Matrix4x4 made 5.3, but was revisioned for 5.4 Task-number: QTBUG-29806 Change-Id: I4cb8bca6ac6fe8040871734c88aabcd392c1d696 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
* Fix visual parent ownership with scenes that create windowsSimon Hausmann2014-03-281-1/+10
| | | | | | | | | | | | | | | | | | Commit 39540124dd0900e0c99dcda8c0ebdf4f3cea8d5e introduced the concept that a visual parent marks its children, by recursively marking the children of the root item in a QQuickView. This allowed for the removal of an ugly hack in QtQuick Controls. Unfortunately that fix is incomplete in the sense that it makes the incorrect assumption that a QQuickView is always used. The use-case in the bug report is to have child items inside a QtQuick.Window (a regular ApplicationWindow in fact). That window - implemented by QQuickWindowQmlImpl - also needs to mark its children, so this patch introduces the use of the same GC marking helper class (which now operates on a QQuickWindow instead of a QQuickViewPrivate). Task-number: QTBUG-37711 Change-Id: Id788e84dbb041ac8ba6ff23dc4ef56f6fe9e465a Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Behavior fix when creating QML windowsFabian Bumberger2014-03-191-1/+19
| | | | | | | | | | | | | | | | | | | | 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>
* Introduced a few more signals to QQuickWindow.Gunnar Sletta2014-02-251-0/+1
| | | | | | | | | | | | Also marked the new afterAnimation() signal as \since 5.3 and introduced proper revisioning on the new signals. [Changelog][QtQuick] Added QQuickWindow::afterSynchronizing(), openglContextCreated(), sceneGraphAboutToStop(). Useful for deeper integration with the rendering. Change-Id: I5532b310506c2432325595e55ef9307b8934abee Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
* Fix broken visibility property assignment after d0644b040eTor Arne Vestbø2013-12-051-1/+1
| | | | | | Task-number: QTBUG-35412 Change-Id: I09feca09030a2eb07aa1abebf65481d68b880c79 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Ensure that QML Windows respect the default platform window stateTor Arne Vestbø2013-11-301-1/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 'visible' property of a Window would be set on the baseclass QWindow like any other property during QML component creation, which would cause create() to be called and the platform window would be created. This left the 'visibility' of the QML window as Windowed, not respecting the platform defaults for how windows should be shown. The user would have to explicitly set "visibility: Window.AutomaticVisibility" for this default to apply, which doesn't make sense -- it should be the default. We solve this by deferring setVisible and setVisibility on the window until the component is complete and we have a full picture of its state. We then ask the platform for the default state based on the window flags (ensuring that eg "flags: Qt.Popup" will not result in maximized windows on iOS and Android), and apply the deferred visibility. The deferred visibility may still be 'false', but setting the window state makes sense anyways, so that a later "visible = true" will apply the default window state. Deferring platform window creation until the geometry has been potentially set from user code also has the benefit that the platform window can check the geometry and apply a default geometry if it's null. This was not possible when the 'visible' property was a regular property, as you could not know if the user's geometry changes would come after platform window creation. Task-number: QTBUG-35174 Change-Id: Icf3236187992048a85b2196c059f9b54699041a4 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com> Reviewed-by: Robin Burchell <robin+qt@viroteck.net> Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
* Set incubation controller when a Window{} is loaded via QQmlApplicationEngineAlan Alpert2013-06-071-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | This was the one convenience that was lost when transitioning templates from QQuickView + Item{} to QQmlApplicationEngine + Window{}. As the default window incubation controller was tied to the first window's frameSwapped, we could easily run into a situation where a secondary window required incubation while the first window was idle. This would then starve the incubation controller. Instead make it so that the renderloop emits "timeToIncubate" once it is done with a renderpass over all windows, so the incubator gets to run once and exactly once per vsync when animating. The incubator logic was also flawed in that it could post a lot of events to itself as a result of incubatingObjectCountChanged and thus starve system events while processing incubation requests. Now we start a timer and don't start it again until we have completed an incubation pass. Task-number: QTBUG-31203 Change-Id: Iea9e2c81efb46bb7875c70ccda0cdc4b3b3e58e7 Reviewed-by: Alan Alpert <aalpert@blackberry.com> Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
* Documentation and versioning for new Window propertiesShawn Rutledge2013-03-131-0/+2
| | | | | | | | Even some of the properties that existed in 5.0 were not documented. Change-Id: I25a14b9b19425a6c792d06bc41983e9abd1d17d0 Task-number: QTBUG-29807 Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
* Update copyright year in Digia's license headersSergio Ahumada2013-01-101-1/+1
| | | | | | Change-Id: I6c3bd7bebe3d62d1cfd0fa6334544c9db8398c76 Reviewed-by: Akseli Salovaara <akseli.salovaara@digia.com> Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
* Change copyrights from Nokia to DigiaIikka Eklund2012-09-231-25/+25
| | | | | | | Change copyrights and license headers from Nokia to Digia Change-Id: Ie7f5d49ed8235d7a7845ab68f99ad1c220e64d5c Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* QQuickCanvas renamesAlan Alpert2012-07-171-2/+2
| | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-09 17:42:51 +0000