Hi, it is quite sad to read that your experience is this bad.
A big issue with Qt Quick Designer is "managing expectations". The designer does load any .qml file and while it warns about certain features by default, those warnings can be turned off. But this does not mean the designer can work on any QML file. In the first place the designer is supposed to work with the items provided in the item library. This means standard Qt Quick items, layouts and QtQuick Controls. Also the features that are supported are the features that the designer does provide (anchoring, layouts, states...). While the designer does support bindings it ignores any imperative code in the edited document and some pure declarativeQML features like transformations are ignored. We do understand that once users leave the playing around stage, they start building their own components and the designer does support using custom components. But keep in mind that the possibilities of custom components are nearly endless and it is easy to write components which do not work well or at all in the designer. The most typical example is a component that does not react to a certain property change, but only evaluates this property once in Component.onCompleted. One option to manage expectations better is to introduce a separate file format for the designer. While opening normal .qml files would still be possible the hope is that this will help communicating the fact that we cannot support all of QML in a visual designer. Separating logic from the ui is a best practice anyway. This was discussed in detail in this blog post: http://blog.qt.digia.com/blog/2011/08/03/proposal-qt-quick-designer-workflow/ This does not solve the custom components issue, though. > I've been actively following QtC Quick Designer, since more than a year ago > it, along with the puppet > is really becoming less and less reliable as several regressions and horrible > bugs make it close to useless in real > life scenarios We did not do many changes regarding the puppet and Qt Quick did not change this much, either. My suspected main reason for your regressions is the fact that we "moved" the qml2puppet into Qt5 and the packages now come with a prebuild qml2puppet in qtbase/bin. Before we used a qmlpuppet that was part of Qt Creator and which only "supported" a couple of imports that shipped together with Qt Creator. This had the downside that many custom components did not render at all, because they used e.g. QtGraphicalEffecs. Using a qml2puppet inside Qt itself solved this problem, but introduced crashes caused by e.g. QtMultimedia. Before those plugins were never loaded and the components using the plugin were not rendered. Now we do load the plugins, but crash in some cases. And in a bigger project one crashing plugin that is indirectly included in most documents does mean nothing works anymore. What you can do now is to remove all problematic plugins (QtMultiemedia and Particles) from bin/qml in Qt Creator and define USE_ONLY_FALLBACK_PUPPET in your environment. For Qt 5.4 we work on a proper solution which provides mockup components for elements/imports that are problematic in the Qt Quick Designer. Instead of loading the original component, the designer will load a mock up component. > In real life one can expect to work with custom components, it's almost > impossible to do something complex > restricting to Rectangles and other Qt Quick-provided items. This is true and I think Qt Quick needs more powerful standard components. What would really help us from your side is a test suite that covers most of your use cases. If you could somewhere publish some projects that cover your use cases and the bugs you find,we can use those for testing. Kind Regards, Thomas Hartmann
_______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
