How do you display a signal/slot graph ?

Maxime Chambonnet

cf. https://github.com/doxygen/doxygen/issues/7505

I would like to see in such graph :

classes as vertices
members emitting signals as edge start
signals as directed edges
slots as edge end

At this point I am thinking doxygen -> (needs doxygen work afaik) xml -> xlst -> pgmodeler rendering (the initial need is for PgModeler circle complete...).

Related needs :
https://www.qtcentre.org/threads/10460-Signal-and-slot-connection-graph
https://stackoverflow.com/questions/4296464/visualize-qt-signals-and-slots
https://ilyasivkov.wordpress.com/2015/03/08/signal-slot-diagram-using-doxygen-and-xslt/
https://github.com/robertknight/Qt-Inspector/issues/20
(KDAB Gammaray is not suitable here.)

Chris Kawa

I'm not sure I understand. Do you want that statically or at a point in runtime? You do know that connections are dynamic and change over the course of program run? It's not possible statically. Just looking for connect statements in the source code is not anywhere near enough.

Maxime Chambonnet

I want it statically, Gammaray already does the dynamic part.
It looks definitely possible to me, notwithstanding instances, to reason over abstractions. Making this graph needs parsing the signal and slot definitions, the connect statements, the members in which the emits are done. Lambda slots are the corner case, and members where the connect happens could be displayed as receivers.

Chris Kawa

@Maxime-Chambonnet said in How do you display a signal/slot graph ?:

Making this graph needs parsing the signal and slot definitions, the connect statements, the members in which the emits are done

That's the thing - those are dynamic and impossible to know statically.

auto signal_name = get_string_from_some_database()
auto slot name = get_string_from_internet();
auto src = get_object_from_db_as_QObject();
auto dst = get_object_from_dynamically_loaded_lib_as_QObject();

connect(src, signal_name, dst, slot_name);

What graph and for what class would you generate here?

Even if you could get an information like that (which you simply can't statically) what's the worth? You have a 100 buttons in your app and one is connected to one of a 100 checkboxes. What would a line QPushButton ----> QCheckbox tell you about that app? Absolutely nothing. You don't know which button to which checkbox and at what time. It's useless.

Maxime Chambonnet

You are right that, beyond what I thought to be a corner case, there is a wall of the impossible for static analysis.

There is still a need, echoed by the various demands up there, by developers to get a better understanding, with high-level illustrations, of their applications.
I face communications for my part that are pretty intertwined, and I could use visual debugging.

I will bet that, in a Pareto way, a majority of code bases have signalling that can be analyzed statically.
A QPushButton ----> QCheckbox line is most likely noise indeed, and yet you can often grab class name if any, widget name or object name, at compile time and why not squeeze a tiny bit of interesting information.
One can think of heuristics to get rid of the noise, because they search and rightfully expect to find valuable intel in such graphs.

Chris Kawa

@Maxime-Chambonnet You might disagree, but I'd guess for an average-sized application you could get maybe 60% of the information statically, some of which would be false positives and a signal to noise ratio of about 1:100.

The only place I could see this useful is if you have an app with just single instance of each class and all connections declared obviously in the code and living throughout the entire span of the runtime. That's like no application I've seen in my career beyond some basic tutorials and hello world ones.
I mean even simple stuff like QMetaObject::connectSlotsByName can't be seen through this way.

and yet you can often grab class name if any, widget name or object name, at compile time and why not squeeze a tiny bit of interesting information.

If you're at runtime you can just put a breakpoint and inspect all the connections of that instance. What benefit would a line on a class graph give you? You already have that information and a lot more, a context of it, objects involved and a point in time.

Maxime Chambonnet

I won't disagree because I haven't this experience.
This is not really about breakpoints, more about time sequences, and akin to how you can loose hair over race conditions.
I experimented with Valgrind and Gammaray all day. If gammaray provided a handy way to spot signal chains, well a signal graph, between user-defined sets of objects, rewind/replay them, with much more and better structured information, with glimmers of emitter member + receiver slot... I would not even consider static analysis.
I guess I'll look at better understanding / improving gammaray then :), thanks.

wrosecrans

This post is deleted!