Saving state of connections

[Chuk]

I have an app I'm working on which makes signal/slot connections by drag/dropping objects. To complicate things, it makes connections between plugins. This part works well now, but I can't figure out a way to save the state of connections. I somehow need a list of connections so I can save the parameters with QSettings. Anyone have an idea how I can do this?

The closest I can find is using connectNotify() which could create a list. But that means I would also have to use disconnectNotify(), and write lots more code in each plugin.

dumpObjectInfo() sounds close to what I want, but it sends it to debug output, and probably has a lot more info than I need.

[marcel]

QObject::metaObject() returns a pointer to its QMetaObject.

With QMetaObject (QMetaObject::method())you can get a list of signals and slots and also query the connections. You can find more in the documentation.

Regards

[Chuk]

With QMetaObject (QMetaObject::method())you can get a list of signals and slots and also query the connections. You can find more in the documentation.

I see how it gives info on signals and slots, but the documentation says nothing about connections.

Do you know of somewhere this is used? I'd like to look at some code using this.

[marcel]

Look in a generated moc in the implementation of a signal, and see how the slot gets called.

Regards

[Chuk]

Look in a generated moc

Well, that doesn't seem to help me. I'll need to generate the list myself either way, so I think I'll start with (dis)connectNotify(), as all the information should be available when thats called. It would speed up the saving procedure, but add some time to the loading procedures.

Thanks for the help, I may still end up following those suggestions. I'll see where it goes.

[marcel]

Well, that doesn't seem to help me. I'll need to generate the list myself either way, so I think I'll start with (dis)connectNotify(), as all the information should be available when thats called. It would speed up the saving procedure, but add some time to the loading procedures.

Thanks for the help, I may still end up following those suggestions. I'll see where it goes.

I think you will have to use your solution and keep a local connection list.

QObject uses two private classes to store connections: QConnection and QConnectionList.
These two are not accessible in any way.

Regards

[Chuk]

QObject uses two private classes to store connections: QConnection and QConnectionList.
These two are not accessible in any way.

They aren't even in the documentation. Otherwise I would try to subclass them.

[Chuk]

Well, connectNotify() doesn't seem to work for this. It's just a function, and sender() is not available. The closest useful thing is receivers(), but that only returns a count. I guess my approach now is to use my own connect() function, such as connectChannels() with the same parameters, have that function keep the list of connections made.

[marcel]

I guess my approach now is to use my own connect() function, such as connectChannels() with the same parameters, have that function keep the list of connections made.

But it is not the function that holds the connection list, it is a class - QObject.

[Michiel]

I don't think tricking the signal/slot system is the answer. I see two kinds of connections here. The theoretical higher-level connections between your plugins and the relatively lower-level Qt signal/slot connections.

Every drag/drop, I would save a stringifiable (meaning: able to be stringified) representation of the new higher-level connection as well as connect the signal and slot. You can save the higher-level connections in QSettings and upon restart, restore the signal/slot connections from that.

Even if it is a one-on-one mapping, it would be the more elegant solution.

[Chuk]

I don't think tricking the signal/slot system is the answer.

I'm not tricking it, I just moved the location of the call to connect(). Docs for connectNotify() say "Warning: This function violates the object-oriented principle of modularity." which seems more like tricking it.

Every drag/drop, I would save a stringifiable (meaning: able to be stringified) representation of the new higher-level connection as well as connect the signal and slot.

Thats exactly what I did. The following function is called for every drop, if accpeted, and is also used to restore connections.

QMultiMap<QString, QString> connections;
 
void Core::connectChannels(Channel* sender, Channel* receiver)
{
	connections.insert(sender->getModName() + "|" + sender->getName(), receiver->getModName() + "|" + receiver->getName());
 
	connect(sender, SIGNAL( Output(QString) ), receiver, SLOT( Input(QString) ));
}

QMultiMap<QString, QString> connections;

void Core::connectChannels(Channel* sender, Channel* receiver)
{
	connections.insert(sender->getModName() + "|" + sender->getName(), receiver->getModName() + "|" + receiver->getName());

	connect(sender, SIGNAL( Output(QString) ), receiver, SLOT( Input(QString) ));
}

To copy to clipboard, switch view to plain text mode 

This does require every object to have a unique name, but that doesn't seem unreasonable. To save the list, I just iterate through connections and pass the strings to QSettings(). To restore connections, I have search functions that return pointers to the channel by seraching on the ModName and Channel Name.

The Core class is what loads the plugins, and restores their state, and has the lists of objects that can be connected. So it seems like the best place to handle the connections.