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
