[Interest] QML Inspector?

Fri Jun 26 22:47:13 CEST 2015

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/20150626/e6062ef3/attachment.html>