Hi, On Wednesday, 6 March 2019 17:59:24 CET Christian Gagneraud wrote: > A few quick random thoughts, sorry for the "dump" style. > > First thing first: > Have you seen the PR "ObjectInspector: Add thread affinity checker" > (https://github.com/KDAB/GammaRay/pull/538/)? > What do you think? Do you like it? Could we add more scanners like that?
Yes, more checks like that make sense IMHO. The problem reporter is a fairly new development, there is still a lot more potential in it I think (as mentioned in your second point too). You should have gotten an email from Allen to pave the way for getting this integrated. > Second: > Wouldn't it be nice to run the problem scanner in an automated way? > The idea would be to use gammaray as an automated dynamic-analyzer (as > oppose to, eg, clang static analyser). > To achieve that it would be nice to run an app under gammaray control, > and tell gammaray to run the "scan for problems", report on stdout (or > in a file), and then call QCoreApplication::quit(). > What i have in mind is to use that in a test/validation process, > manual or automated. > For example, We use blocking PR, if your PR doesn't pass some > buildtime/runtime test, the PR cannot be merged. This could be used, > for example, to check that no cross-thread signal/slot connections are > introduced in a project (prevention is better than cure) I like the idea, I'd not block PRs on it yet though, considering the current false positive rates ;-) Practically this would probably need some kind of command line client to trigger the scans and print the result for consumption by a CI system. A bit of work, but shouldn't be particularly hard I think, we should have all the pieces for that. > Third: > I've been thinking about adding a new feature to the signal inspector. > The ability to export a dot file that graph all the signal/slot > connections b/w a set of objects. > The idea would be to add a new action to the signal menu. From there > the user select s the objects of interest, and then the graph is > generated as a graphviz dot file. > The graph would contains all connections b/w the set of objects, plus > the objects that have a first degree connections with the original > set. > Ideally the graph would contains these information (might be optional): > - QObject thread affinity (using graphviz cluster [1]) > - connection type (eg, using style or color) > - signal/slot names The signal inspector is indeed another area where we don't leverage all possibilities yet IMHO. The signal tracing data is more detailed than what we display there, we could gain quite a bit with better visualization and filtering capabilities I think, especially when combined with knowledge about connections. A graph-based visualization of signal or binding cascades would indeed be awesome, possibly also with weighting edges by how often they trigger or how long they took to process :) Regards, Volker
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gammaray-interest mailing list Gammaray-interest@mail.kdab.com https://mail.kdab.com/mailman/listinfo/gammaray-interest
