I STRONGLY NEED to know slot where signal is connected to.
-
I think you have been given enough pointers on how you might solve this. It seems to me, you are not willing to take any of them. In the end, you probably will end up having to patch Qt, and either distribute your own, patched version, or argue a convincing case to get your patch merged in Qt proper.
-
I already implemented
@class ConnectorRegister
{
public:
ConnectorRegister();
~ConnectorRegister();bool do_connect( QObject * sender, char * signal, QObject * receiver, char * slot, Qt::ConnectionType type = Qt::AutoConnection ); bool do_disconnect( QObject * sender, char * signal, QObject * receiver, char * slot ); bool are_connected( QObject *sender, char *signal, QObject *receiver, char *slot ); Connection where_connected( QObject* object, char * socket, bool sender ); Qt::ConnectionType get_type( QObject *sender, char *signal, QObject *receiver, char *slot );
private:
QList<Connection> connections;
};@with some extra functionality. For example it stores connections in it's destructor to file and restores them in constructor. And it is thread safe. This class is much better and more powerful than all discussed here. That means - I know what I'm talking about. The BEST solution will be if Qt will have ability get connection info legally from QtCore
-
Taking a different approach to this problem (probably too little, too late), if it is a user action that connects or disconnects the signals and slots, wouldn't it just be simpler to keep track of the connection or disconnection requests that the user has made, rather than rely on introspection of the connections themselves? Saving the requests would be trivial, and then to reconnect them later on, you just read in the requests and make them in the order they were saved.
-
I decided to make exactly that you are talking about. But this looks good only from beginning. This must be implemented very carefully but cannot solve all problems. If I would able get existing connections from Qt - then I'd not have these problems and code would be much more simple.
-
You can access the private stuff, but then you are not binary compatible. I know, there was already a discussion about that here on devnet.
If you include QObject_p.h you can cast and have access, but that's not officially.
And I don't think, the Trolls will add that to the API. Not only because one user likes to use it. And I personally don't know where this should be needed.
-
bq. If you include QObject_p.h you can cast and have access, but that’s not officially
No, I can't. QObjectPrivate* QObject::d_ptr is private.
And this would not be very useful. I analyzed Qt source code related to object connections. Internal data structures are adjusted to internal routines. They cannot be easy used in my code. Exactly new method and data structure needed to access connection info. That is why I turned to registering.
-
Believe me, it is possible to use the private data :-) It needs some tricks, but is possible...
e.g. you can use:
from QObject_p.h:
@
void Q_CORE_EXPORT qt_register_signal_spy_callbacks(const QSignalSpyCallbackSet &callback_set);
extern QSignalSpyCallbackSet Q_CORE_EXPORT qt_signal_spy_callback_set;
@ -
Now I recognize the topics I meant before:
"how can I observe a custom qobject’s slot":http://developer.qt.nokia.com/forums/viewthread/4916
"QSignalSpy Class Reference in the docs":http://developer.qt.nokia.com/doc/qt-4.7/qsignalspy.html -
I do not need "signal espionage". I need info about signals connections before any data will be send on them. Actually now I don't need even this. Untill I'll get any trouble with my current solution
bq. Believe me, it is possible to use the private data
If you mean creation of "twin" class with same data public then <reinterpret_cast> - it's a hack
I do not like such hacks...
-
Well, if you have a solution that works, I think that you're set. No functionality of the toolkit can be perfect for everyone, and there are always going to be restrictions (sometimes major, sometime minor) that you're going to have to work around. That's pretty much the nature of the beast.
Should you have trouble with your current solution, even though it's not the one you dream and hope for, I'm sure that you can get some good productive feedback regarding ways to cope with it. I don't think any of us here would turn a deaf ear toward you if you present your problems objectively and are willing to listen to reasonable responses.
But, the reality of things is that the solution you've been asking for (or, more properly, demanding) goes against one of the basic philosophies of Signals and Slots: the decoupling of caller and callee. And because of that, there's probably not going to be a lot that will happen from either the Trolls, or the community at large to change anything. With that said, there have been suggestions made as to how you can make the request formally, or propose code to be changed. Those mechanisms work when there is enough of a consensus or enough momentum from the community at large. Honestly, though, this isn't the forum for making those kinds of demands.
"Code less, create more" is a great philosophy and a driving factor for our tools. But, that doesn't release us, as developers, from our duty of writing sound, constructive code and from sometimes having to be extra innovative and creative. The basic building blocks are there, and it's up to us to utilize them in the most proper way to accomplish our specific tasks.
I hope that your solution you've ended up using turns out to be robust enough for you. Since you're in control of your code, you at least have the benefit of having some say in the degree of care that is given in maintaining the logic involved. Just stay on top of things, and document your code well.
We've all had situations where we've had to use solutions what weren't our first choice, but that's just part of the adventure that is software development. Good luck!
-
I strongly dislike duplication of features and data if this is not necessary to increase stability and robustness. Exactly duplicated connection info not only increases robustness - but decreases it instead.
I'm sure this story is not closed forever. Necessity of native extended connection info will appear more and more.
-
If you feel strongly enough about it then please file a merge request on gitorious and ask for it to be reviewed.
-
I've been trying to solve a performance issue with a project of mine, and I've been suspecting that I'm generating huge loads do to connections getting away from me so I found this thread.
Later I found:
http://qt-project.org/doc/qt-4.8/qobject.html#dumpObjectInfo
That appears to mention at least the possibility of displaying the requested data.The only down side to this is the output is only enabled in debug builds.
(yes thread necromancy, I didn't find any google hits pointing me to this solution so giving a solution in this thread feels good to me.)
-
You may want to have a look at the GammaRay tool written by some colleagues of mine at KDAB. It allows you to introspect all sorts of details about Qt applications including signal/slot connections but also higher level frameworks such as layouts, text documents, state machines etc. It can be found on git hub at https://github.com/KDAB/GammaRay
-
[quote author="ZapB" date="1348564437"]You may want to have a look at the GammaRay... It can be found on git hub at https://github.com/KDAB/GammaRay[/quote]
Wow this look absolutely awesome! Definitely worth the try!