QMetaObject does not copy items in class container

VeaceslavM

Hello,
I have a very nasty problem and I hope somebody can help me.

In my program there is a class called ParallelWorkers, implemented by somebody else:
http://pastebin.com/s6CtNAw2 .h
http://pastebin.com/35cPd433 .cpp

The ParallelAdapter class will usually have 4 worker threads(FileWorkerInterface extends WorkerObject):

    qRegisterMetaType<FileActionImageInfoList>("FileActionImageInfoList");
    fileWorker = new ParallelAdapter<FileWorkerInterface>();
    while (!fileWorker->optimalWorkerCountReached())
    {
        fileWorker->add(new FileActionMngrFileWorker(this));
    }

and connection is done like this:

    connect(dbWorker, SIGNAL(writeMetadata(FileActionImageInfoList,MetadataHub*)),
            fileWorker, SLOT(writeMetadata(FileActionImageInfoList,MetadataHub*)), Qt::DirectConnection);

As you can see, the connection is done to ParallelAdapter and not to workers itself. WorkerObject does not have slot writeMetadata, but FileWorkerInterface has it. But ParallelAdapter will be able to find the correct slot and send the signal to it.

Now the problem: FileActionImageInfoList extends QList<ImageInfo>, and it contains ImageInfo objects when the signal is fired. But when it arrives in the slot, the FileActionImageInfoList is empty.

Extra info when I was debugging:
I tried to connect the signal from above to a simple slot, to see if problem is in metacall implementation or not and:

If the signal is connected to ParallelAdapter, the other slot is also having empty list
If the signal is not connected to ParallelAdapter, the other slot receives the FileActionImageInfoList with items...

Any help is appreciated... if you can spot any problems with ParallelAdapters or ParallelWorkers implementation...

SGaist

Hi and welcome to devnet,

You should check with the Digikam Team since that code comes from their repositories (or at least is based on it) They'll be more knowledgeable about it

VeaceslavM

Thank you for the answer, but I am in the digiKam team :))
And we face huge problems when porting from qt4 to qt5. This is one of issues that I face now, and I can't find anybody to help me :(

SGaist

If I've read things correctly, that class is some sort of emulated QObject that does multithread handling, and the code comes from Qt 4's generated moc code which probably has changed in Qt 5. That might be a starting point.

However, wouldn't KDE's ThreadWeaver be an alternative ?

VeaceslavM

We had pretty bad experience with ThreadWeaver. Also, after KF5, digiKam port is ridiculously difficult due to heavy KDE dependency and amount of stuff that was deprecated. Now, we replace it with qt implementation and only keep KDE functionality for integration with other services...

The class itself does the job, I could even change it a little to fit the current needs, but this approach gives the ultimate flexibility. I can not see other way of extending WorkerObject while being able to use different slots in different objects and make connections to ParallelAdapter.

The downside of this implementation is that it is based on some hacks...