[Development] State of QtDeclarative (noob question)

[Holger Hans Peter Freyther]

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?



> That one's actually broken. Whoops. QTBUG-23328 has been filed, thanks for 
> bringing this up.

Is this something one could detect automatically?


> 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).

What do you think?