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

[Ariel Molina]

On Mon, Jun 30, 2014 at 10:51 AM, Hartmann Thomas <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.
      1. 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.
      2. 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.
      3. 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/20140701/472a5f80/attachment.html>