Note: it turns out that setting background to Qt.transparent doesn't make sense. It worked simply because the types are incompatible and background got set to null. It's easier to simply set background to null to get the same result.
If I push-pop TestQml few times, I got QCoreApplication::postEvent: Unexpected null receiver during push (really during component.createObject() ) and app crashes. It seems that reason is that js garbage collector destroy previous instances of component , but something in C++ still have pointer to it (I suppose so because I have seen some methods with name like QV4::MemoryManager::runGC in call stack when I tried to debug this crash, but it happens rarely with active debugger and doesn't happen if I make push-pop sequence from code). I figure out that if I remove FileDialog, the app does not crash.
I understand that my code can be incorrect for Controls 2, but I haven't had any system notification about it, this code is result of migration from Controls 1 and it is work in general (when I don't use FileDialog), so I think this situation is should be at least described because figure out what causes this crash was not easy
My environment is Qt Creator 4.0.2, Qt 5.7.0, MinGW 32 bit, OS Win 8.1 64 bit, if you need some other information, please, I ready to answer, but maybe not very fast - I use qt only in my pet project now.
But in case when user need to change one/two properties: copy-pasting whole background Rectangle part from module with editing is kind of weird thing which brings issues.
Yes, it’s unfortunate that we can’t provide simple properties for customizing everything. After carefully analyzing what happened with Qt Quick Controls 1.x, we have made a conscious choice to keep things simple and avoid creating large amounts of styling related bindings. Even though a single binding doesn’t cost that much, it all adds up. Once we go that route, there’s no end to it. More and more styling attributes would be added until it becomes so heavy that it no longer runs on low-end hardware, again. Been there, done that. :) Therefore, now we provide simple style-specific theming mechanisms to change accent colors and such, and then expose the building blocks so that they can be entirely replaced when the default implementation is not satisfactory. We have a change in the pipeline that will setup the style name as a built-in file selector to make style-specific tweaks convenient.
@jpnurmi, by the way, what difference between dev and 5.7 branches, is it possible to use dev or 5.7 with Qt 5.6?
Qt 5.6 is just about to be released, so we haven’t been pushing any new features there anymore. We might push a fix or two to the upcoming 5.6.x patch releases, but we’ll be mostly focusing on getting the first official release in shape in the 5.7 branch. Normally all new features would be pushed to the dev branch. The 5.7 branch is already feature frozen and supposed to gain only stabilizing bug fixes, but tech preview modules have an exemption to continue the development a bit longer. Unfortunately, we can’t give any promise that the controls in 5.7 would stay compatible with the rest of Qt 5.6. It happens quite often that we have to change some internals in the modules we depend on, and then the controls will not necessary build with 5.6 anymore.