[Interest] QML Inspector?

[Jérôme Godbout]

I could build and attach with a debug probe of Qt 5.3.0, it work, I can see
the QuickScene objects and modify properties. If I do some method invoke
with return value, I never get an answer, is there something special to do
to make it work? Should I enable the -qmljsdebugger=port: hook to get the
answer somehow?

After building, I end up with a debug probe only, is there a way to build a
release probe for GammaRay and would it work?

Connections are now shown, invoke seem to work, but the return value is
lost, a lot of loading. If I can run in in release build it would be good
enough for some usage.

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

> OK, got it to work in VS2013 x64 cross-compiling, seem like my -G flag was
> not register into the cmake command, du to a non printable character from
> utf-8 copy paste to ainsi (damn Windows console sometime). The reason why I
> end up with a solution and not the Makefiles as an output from the cmake.
>
> On Fri, Jun 26, 2015 at 4:35 PM, Jérôme Godbout <jerome at bodycad.com>
> wrote:
>
>> VS2013 x64 Native Tools Command Prompt
>>
>> On Fri, Jun 26, 2015 at 4:34 PM, Samuel Gaist <samuel.gaist at edeltech.ch>
>> wrote:
>>
>>> Hi,
>>>
>>> There's no such limitation, you can build it in 64bit.
>>>
>>> Did you start your build from a amd64 or x86_amd64 cross-compiling
>>> console ?
>>>
>>>
>>> On 26 juin 2015, at 21:04, 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?
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Interest mailing list
>>> > Interest at qt-project.org
>>> > http://lists.qt-project.org/mailman/listinfo/interest
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150629/117598b2/attachment.html>