[Interest] QML Inspector?

Jérôme Godbout jerome at bodycad.com
Fri Jun 26 22:34:03 CEST 2015

I have compile it with VTK for x86, but does not give me much, since I end
up with only i686 probe.

I used to be able to compile it with nmake and the generated makefiles (I
still have the 2.1 version installed on my machine compile against the Qt
5.2 x64).

Now with the Visual studio .sln generated from the cmake.exe "NMake
Makefiles" .. command, I cannot compile a x64 version. Anyone know if the
makefiles can still be generated, maybe I could compile it the old way
again? Seem like they change the cmake behavior, didn't update the doc, and
only x86 config is available into the generated solution. And cannot just
add the x64 platform :-(

P.S.: you can add building GammaRay in the thing that I don't like about
it. Under Linux must be fine, but it's a pain under Windows (sadly I do not
always choose the platform I have to work with).

On Fri, Jun 26, 2015 at 3:04 PM, Jérôme Godbout <jerome at bodycad.com> wrote:

> I'm trying to compile GammaRay, anybody manage to compile it in x64 under
> Windows?
> I manage to compile VTK and set the proper env (VTK_DIR) against Qt 5 x64.
> I couldn't compile Graphiz in x64 (complaining about missing
> header textspan.h, manually give it to him, still cannot compile it in x64,
> the solution doesn't work in VS2012). Even without Graphiz, the solution
> output by GammaRay cmake doesn't have any x64 into. Even if I add the
> configuration for x64, I still end up with many erros:
> Error 19 error LNK1112: module machine type 'x64' conflicts with target
> machine type 'X86' ...\build\tests\manual\x64\Release\wk2application.obj 1
> I guess we are only suppose to compile GammaRay in 32 bits. Can we compile
> it in x86 with Qt 5 x86 and run it to debug Qt 5 x64 after properly? We
> only have a 64 bits version of ours app, we drop 32 bits support last years.
> On Fri, Jun 26, 2015 at 9:33 AM, Jérôme Godbout <jerome at bodycad.com>
> wrote:
>> Hi,
>> thanks all for your inputs, there's a few thing I was not aware of. For
>> the visualizer, I see little benefit in my use case in desktop, probably
>> more useful for embedded platform project which I think still have a real
>> world purpose.
>> As for GammaRay, it's slow down our application too much, we are doing 3D
>> CAD application with Qml (we have 3D scene render into texture and many
>> many objects into our Qml Tree, since the 3D objects are part of it as
>> children to our 3D viewport, yeah it's weird usage but make our application
>> very flexible). We tested GammaRay around summer years 2014 if I remember
>> correctly (2.1.0 I guess). It does the object inspection well, can edit,
>> invoke and emit was not working so well at the time, maybe they fixed it by
>> now. Singleton are not supported. But mainly, it make our application run
>> like it's in debug which is way too slow to our liking. Not sure if their
>> was any improvement on this, but for day to day work, it was not cutting it
>> at the time.
>> From the change log since my last eval (available here for those who are
>> looking for it, should realy put a link on the main page to this):
>> https://github.com/KDAB/GammaRay/releases
>>    - Support displaying of QQmlListProperty contents.
>>    - Fix invoking non-slot methods with arguments.
>>    - Expose signal/slot spy callback API to plug-ins.
>>    - Support for manually emitting signals, and improved method display.
>>    - Fix crash when target deletes a signal sender in a slot.
>> Seem like I should give it another spin. Our in house tool is doing this
>> without much slow down and can even perform invoke/emit/inspect/edit/regex
>> search on object based on ptr/name/id/type and clickable to navigate
>> through childs/parent. Wish we could license it open source, but I doubt we
>> could do that here :-(  Seem like maybe GammaRay have evolved enough so we
>> can ditch in-house implementation, will let the list known how it did go as
>> soon as I can have time to test the latest release.
>> I'm looking forward for that QtCreator items inspector, would love to see
>> it spin off of QtCreator and becoming a component on it's own, that would
>> help many people who are using other IDE. I was not aware of this one,
>> thanks for the info.
>> On a side note, I agree a Qml would need a TreeView, would remove our
>> dependencies on QWidgets for us.
>> On Fri, Jun 26, 2015 at 6:33 AM, Rutledge Shawn <
>> Shawn.Rutledge at theqtcompany.com> wrote:
>>> On 25 Jun 2015, at 21:41, Jérôme Godbout <jerome at bodycad.com> wrote:
>>> > There's GammaRay
>>> > http://www.kdab.com/kdab-products/gammaray/
>>> > https://github.com/KDAB/GammaRay
>>> >
>>> > It's not 100% efficient, but better then nothing. We end up doing our
>>> own debugger command line to search and inspect object along a TreeView
>>> from QWidgets to see/edit properties, pointer value, invoke methods and
>>> emit signal. I would love to see one build for Qml build-in, we could stop
>>> maintain ours.
>>> https://codereview.qt-project.org/#/c/44322/ is a patch for qmlscene
>>> which I’ve been occasionally developing and using for a long time (2012 or
>>> so).  Earlier versions looked at the object hierarchy (the QObject
>>> parent/child relationship), whereas now it looks at the top-level Item’s
>>> childItems().  Each way has its advantages… There is a QAIM model and a
>>> QTreeView to view the items and a few properties, and a “dump” button to
>>> get the rest.
>>> However it’s not desirable to have a dependency on widgets in a QML
>>> tool.  (Although maybe having it in qmlscene wouldn’t be so bad, because we
>>> are trying to deprecate qmlscene anyway.)  And it crashes sometimes,
>>> because the tree does not automatically remove objects when they are
>>> destroyed, so it can end up trying to get properties from dead objects.
>>> I’m sure that’s fixable if the desire continues to have such a tool.  Maybe
>>> it could even be dynamically loaded by the qml tool, instead of being
>>> linked in.  And I’d want it to be able to discover all of an application’s
>>> windows.  And I’d like to have it show the scene graph nodes which each
>>> Item is responsible for, and the z stacking order.
>>> Ideally maybe we should have a TreeView which can directly use any
>>> object hierarchy as the model, without needing a QAIM.  But of course such
>>> a tree would have to avoid inspecting itself.
>>> Maybe it’s not worth doing, now that GammaRay is working well enough?
>>> What do you not like about GammaRay at this point?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150626/40278a25/attachment.html>

More information about the Interest mailing list