Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QMetaObject does not copy items in class container
Forum Updated to NodeBB v4.3 + New Features

QMetaObject does not copy items in class container

Scheduled Pinned Locked Moved General and Desktop
5 Posts 2 Posters 1.1k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • V Offline
    V Offline
    VeaceslavM
    wrote on last edited by
    #1

    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:

    1. If the signal is connected to ParallelAdapter, the other slot is also having empty list
    2. 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...

    1 Reply Last reply
    0
    • SGaistS Offline
      SGaistS Offline
      SGaist
      Lifetime Qt Champion
      wrote on last edited by
      #2

      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

      Interested in AI ? www.idiap.ch
      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      0
      • V Offline
        V Offline
        VeaceslavM
        wrote on last edited by
        #3

        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 :(

        1 Reply Last reply
        0
        • SGaistS Offline
          SGaistS Offline
          SGaist
          Lifetime Qt Champion
          wrote on last edited by
          #4

          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 ?

          Interested in AI ? www.idiap.ch
          Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

          1 Reply Last reply
          0
          • V Offline
            V Offline
            VeaceslavM
            wrote on last edited by
            #5

            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...

            1 Reply Last reply
            0

            • Login

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • Users
            • Groups
            • Search
            • Get Qt Extensions
            • Unsolved