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 [[email protected]]
Sent: 01 July 2014 23:08
To: Hartmann Thomas
Cc: [email protected]
Subject: Re: [Qt-creator] Plea for help: Qt Quick Designer increasing
unreliablility,
On Mon, Jun 30, 2014 at 10:51 AM, Hartmann Thomas
<[email protected]<mailto:[email protected]>> 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
_______________________________________________
Qt-creator mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/qt-creator
