[Development] State of QtDeclarative (noob question)

[Alan Alpert]

On Sat, 24 Dec 2011 00:39:51 ext Holger Hans Peter Freyther wrote:
> On 12/23/2011 02:31 AM, Alan Alpert wrote:
> > On Fri, 23 Dec 2011 10:20:56 ext Holger Hans Peter Freyther wrote:
> >> Hi,
> 
> Hi,
> 
> thanks for responding.
> 
> > Works fine for me. Note that it needs to be built (qmake && make) because
> > it includes a plugin, and since this isn't being tested except for
> > in-source builds at the moment install paths may be broken for shadow
> > builds.
> 
> Oh well, that is really saddening. The install prefix should be the same
> for in-source/shadow build as it comes from the qmake/qtbase? How exactly
> does it break? Why doesn't qmlscene complain about the failing import?

It should. A failing import leads to an error message printed to the console. 
It would break (if it does, alas even I haven't tested all build 
configurations yet) at failing to load the FileDialog import, because it is 
missing a plugin.

> > That one's actually broken. Whoops. QTBUG-23328 has been filed, thanks
> > for bringing this up.
> 
> Is this something one could detect automatically?

Runtime errors? Not that I'm aware of. The auto-tests can only verify that 
examples successfully launch. They can't attempt to play snake (although 
perhaps we should have some humans do that from time to time ;) ). But when 
people notice it, they can file a bug report and someone will fix it. Same 
with the minehunt problem you mention later, now that people are aware of it 
then it can be fixed. If only my job was to play minehunt, samegame and snake 
every day... among the other games in the examples of course.

> > It is a known issue that sometimes graphics drivers don't have vsync
> > enabled by default. In this case, it will render as fast as possible,
> > usually giving 1000s of FPS and 100% CPU usage. On my machine (ubuntu
> > 10.04 with nvida drivers), I was able to fix this by toggling 'sync to
> > vblank' in the nvidia- settings applications.
> 
> Can this be detected somehow? I think I ended up in this issue as on one
> suspend/resume cycle the GPU hang and the X11/intel driver disabled
> acceleration. I don't ask for a workaround like limiting the FPS but just
> to detect an unrealistic/broken driver behavior. I am looking at this from
> two point of views: Users and Qt Integrators. In both cases it would be
> nice to detect such a problem in one way or another.
> 
> >> So I tried to go back to qmlviewer to at least have some quick1 display
> >> and besides the warning about QGuiApplication/QApplication it would be
> >> nice if qmlviewer would warn when someone tries to import QtQuick 2.0.
> > 
> > It does, the warning message is "QDeclarativeView only supports loading
> > of root objects that derive from QGraphicsObject". Perhaps not the
> > clearest message if you haven't written C++ QML elements now that I
> > think about it...
> 
> qmlviewer might have been started through the desktop environment so even a
> good console error message does not immediately draw any attention.
> 
> So it appears that my first and last point are mainly about how to deal
> with failing imports. People might write plugins don't link with
> -Wl,--no-undefined and the import fails.. it would be nice to have a
> reasonable error message, and maybe a proper indication on screen (e.g.
> qmlviewer).

There is an error message printed to the console. As a development tool, it 
has so far been sufficient for qmlviewer to print warnings and errors to the 
console. If you're writing an application you shouldn't use qmlviewer (and 
you'll need to check for optional imports yourself).

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks