<div dir="ltr"><div>I have compile it with VTK for x86, but does not give me much, since I end up with only i686 probe.</div><div><br></div>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). <div><br></div><div>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 :-(</div><div><br></div><div>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).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 3:04 PM, Jérôme Godbout <span dir="ltr"><<a href="mailto:jerome@bodycad.com" target="_blank">jerome@bodycad.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm trying to compile GammaRay, anybody manage to compile it in x64 under Windows?<div><br></div><div>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:</div><div><div>Error<span style="white-space:pre-wrap">     </span>19<span style="white-space:pre-wrap">      </span>error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'<span style="white-space:pre-wrap">       </span>...\build\tests\manual\x64\Release\wk2application.obj<span style="white-space:pre-wrap">   </span>1</div></div><div><br></div><div>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.</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 9:33 AM, Jérôme Godbout <span dir="ltr"><<a href="mailto:jerome@bodycad.com" target="_blank">jerome@bodycad.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div>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.</div><div><br></div><div>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.</div><div><br></div><div>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): </div><div><a href="https://github.com/KDAB/GammaRay/releases" target="_blank">https://github.com/KDAB/GammaRay/releases</a></div><div><ul><li>Support displaying of QQmlListProperty contents.</li><li>Fix invoking non-slot methods with arguments.</li><li>Expose signal/slot spy callback API to plug-ins.</li><li>Support for manually emitting signals, and improved method display.</li><li>Fix crash when target deletes a signal sender in a slot.</li></ul>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.</div><div><br></div><div>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.</div><div><br></div><div>On a side note, I agree a Qml would need a TreeView, would remove our dependencies on QWidgets for us.<br></div><div><br></div><div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 6:33 AM, Rutledge Shawn <span dir="ltr"><<a href="mailto:Shawn.Rutledge@theqtcompany.com" target="_blank">Shawn.Rutledge@theqtcompany.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
On 25 Jun 2015, at 21:41, Jérôme Godbout <<a href="mailto:jerome@bodycad.com" target="_blank">jerome@bodycad.com</a>> wrote:<br>
<br>
> There's GammaRay<br>
> <a href="http://www.kdab.com/kdab-products/gammaray/" rel="noreferrer" target="_blank">http://www.kdab.com/kdab-products/gammaray/</a><br>
> <a href="https://github.com/KDAB/GammaRay" rel="noreferrer" target="_blank">https://github.com/KDAB/GammaRay</a><br>
><br>
> 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.<br>
<br>
</span><a href="https://codereview.qt-project.org/#/c/44322/" rel="noreferrer" target="_blank">https://codereview.qt-project.org/#/c/44322/</a> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Maybe it’s not worth doing, now that GammaRay is working well enough?  What do you not like about GammaRay at this point?<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>