[Qt-creator] Plea for help: Qt Quick Designer increasing unreliablility,

Fri Jul 4 20:40:46 CEST 2014

Hi,

>* for less annoying bugs, we mantain an internal "QtC Practices to Avoid Nasty Bugs" wiki, which should not > exist in the first place.

Can you share this wiki with us? And please continue to create bug reports for all issues you find.

>I've seen that, our own plugins crash at intermediate phases of development, its understandable. Can there be
> an option to see which plugin crashed at load? That would help a lot.

I fear this is more or less impossible. We are (usually) talking about C++ which can crash for many reasons.
We could add some "tool" that tries to remove imports until there are at least no immediate crashes, but I am not sure how reliable this would be.

> Interesting, can you elaborate on this? Would this still allow to create Video{} and those components? there > would be no reason to do that if they are not available anymore.
This means we would stop loading plugins which are not part of Qt Creator. This means you get "more" empty boxes like MouseArea but also most likely less crashes.

> I work at a place under a policy of no external hosting (like GitHub), however we use a in-house GitLab, i
> think i can talk to the team and provide a public access git repo.

Having access to some bugger project from you would really help a lot.

>Thank you very much for your patience and i welcome any comments, BTW, i will be at QtC DevDays again
> this year, maybe we can meet to discuss a bit or to show you some crashes (but i hope there is no more
> unstability by then :) )

I do not think I will attend DevDays in the US, but someone from our office most likely will.

Kind Regards,
Thomas Hartmann

________________________________
From: Ariel Molina [ariel at edis.mx]
Sent: 01 July 2014 23:08
To: Hartmann Thomas
Cc: qt-creator at qt-project.org
Subject: Re: [Qt-creator] Plea for help: Qt Quick Designer increasing unreliablility,

On Mon, Jun 30, 2014 at 10:51 AM, Hartmann Thomas <Thomas.Hartmann at digia.com<mailto:Thomas.Hartmann at digia.com>> wrote:

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.
I know and i have read a blog about a different workflow, im not asking for a puppet which runs full apps, i understand a fully puppeting a non-declarative application is cumbersome to say the least. At my group we have clearly understood that, and have manageable and reasonable workarounds, it does not bother us.

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.
Right, that's the point where issues begin to arise.

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.
Currently, the problem is custom components either crash the puppet or render it useless for several misterious (seemingly) reasons without giving too much information about what went wrong. This makes the Designer go from 'reasonably usable' to completely useless (no puppet means no QML designer at all).

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.
Before going further into solving the problem of imperative code (at least for us it is not a problem) i would like to make our point that a stable, and reasonable usable Designer is needed first. Adding complexity to an already unstable basecode might be undesirable. That's our point, of course, there might be different opinions.

Separating logic from the ui is a best practice anyway.
It is indeed, but i think stability to the current code is even more important at this moment. Specially i've read a lot of requests and wishlist from around forums, lists and bugs, many of them are:

  1.  To have a Designer, i think the basic (puppet) stability is implicit in here
  2.  To have traditional widgets (Qt Components fill this space).
  3.  Visual clues for Components.
     *   In general there is no guarantee that any refactored component (made with only Qt's basic blocks) is visually shown, this bug predates QtC releases, it comes and goes.
     *   Custom C++ components. There are proposals for mock ui's, but at least an item similar to what MouseArea does is really helpful and makes a huge advantage than pure code. One can imagine what's inside the box, but one cannot imagine precisely anchors, measures and x,y positions.
     *   Recently the switch to QRC-only pattern made huge headaches (QTCREATORBUG-12286) as it created a big inconsistency in user experience (among other problems).
  4.  General basic usability which might seem superficial but makes usage a pleasure instead of a constant struggle: drag-drops, correctly picking elements, designing basic properties, and even picking colors is troublesome (*).

* for less annoying bugs, we mantain an internal "QtC Practices to Avoid Nasty Bugs" wiki, which should not exist in the first place.

I've seen lots of additions, which are pretty good ideas, some of them like the new anchoring system details in master and alpha for colors are very nice. But, as Qt has from time to time, I think QtC Designer deserves a release where stability and consistency is bumped. The four points i mention are already implemented in QtC, just by stabilizing most of them, the UX would be greatly enhanced.

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.

See previous...

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.
I remember that, see point 3.2, just a blank box saves the day.

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.

I've seen that, our own plugins crash at intermediate phases of development, its understandable. Can there be an option to see which plugin crashed at load? That would help a lot.

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.
Interesting, can you elaborate on this? Would this still allow to create Video{} and those components? there would be no reason to do that if they are not available anymore.

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.
I remember reading about that in the bug tracker, it is very interesting and im eager to test it, but well, I still vote for a stable puppet.

> 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.
Qt Quick cannot ever reach all possible usage scenarios, adding basic components (like standard widgets) was a good idea, but trying to reach all scenarios is an impossible task. For example, we use a C++ engine to control hundreds of electronic valves to create computerized real water-falls. It used to work fine, then QTCREATORBUG-12460 appeared, and I found ListView crashes (not my component). Managed to create a totally simple mechanism to crash (no electronic valves code at all), but the bug was marked as not reproducible. The issue here was custom components, even a stub one was enought to generate a puppet crash. There are several other places where Qt cannot provide components, like mashup databases, custom backends, special hardware (avionics, medical, data miners, research, physics engines, ...). Custom components are simply the way to go, let the users implement their own stuff.

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.

I work at a place under a policy of no external hosting (like GitHub), however we use a in-house GitLab, i think i can talk to the team and provide a public access git repo.

Thank you very much for your patience and i welcome any comments, BTW, i will be at QtC DevDays again this year, maybe we can meet to discuss a bit or to show you some crashes (but i hope there is no more unstability by then :) )

Ariel

--
Ariel Molina R.

Oficina: +52 (222) 3723196
Movil: +521 2226 758874
http://edis.mx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20140704/0858854d/attachment.html>