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 <jer...@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 <jer...@bodycad.com> > wrote: > >> VS2013 x64 Native Tools Command Prompt >> >> On Fri, Jun 26, 2015 at 4:34 PM, Samuel Gaist <samuel.ga...@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 <jer...@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 <jer...@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.rutle...@theqtcompany.com> wrote: >>> > >>> > On 25 Jun 2015, at 21:41, Jérôme Godbout <jer...@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@qt-project.org >>> > http://lists.qt-project.org/mailman/listinfo/interest >>> >>> >> >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
