[Gammaray-interest] Thoughts about the problem scanner

[Christian Gagneraud]

On Wed, 20 Mar 2019 at 09:41, Volker Krause <volker.krause at kdab.com> wrote:
> > IMHO, some models should contains these dynamic data in a more
> > processed way, eg AbstractConnectionsModel contains static data, while
> > SignalHistoryModel contains "raw" dynamic data, eg. start/end time (of
> > the connect/disconnect?). no start/stop at the event level (?!?), no
> > trigger counter, no accumulated process time, ...
> >
> > So Am I right that to get that started, i would first need to enhance
> > the SignalHistoryModel?
> > I don't see the point to do all the tracking/calculation in the GUI
> > part, or in another (new) class or I will end up duplicating code from
> > the signal history view.
>
> Yes, I don't think we have the data needed for this in the right form already.
>
> There's two sources of data available I think:
> - connections: Unlike in Qt4 we don't have hooks to be notified about
> connects/disconnects anymore, so we can only list connections on demand for a
> given object. That's what the xConnectionModel classes do, as well as the
> connection issue scanner. That's also the reason why we have no model
> available anymore with all existing connections.
> - signal emissions: For those we have very high level of detail hooks (begin/
> end signal emission, begin/end slot invocation), which is what the signal
> history model collects.

Thanks for the info, that's a pity we don't have hooks for connect/disconnect :(

> The signal history model is already quite expensive, you certainly don't want
> to transfer that entirely to the client just to sum up costs for example, so
> doing aggregation in there makes a lot of sense. A useful intermediate step to
> verify the data is all there might be to show emission data in the connections
> tab of an object.

I guess, what's expensive is the list of event, that keep growing,
right? And the fact that the object list never shrink as well?

As well, this history model only tracks signals, no slots, are you OK
if I add slot tracking too?


> However, If you primarily care about the connection structure rather than the
> emission data, producing a graphviz dot file with code similar to the
> connection issue scanner should already be doable, maybe with some filtering
> applied to hide non-connected objects to keep the result readable.

Yes, but this is server-side code. Ideally I would prefer to generate
it in the client/gui side...

Chris