[Development] QtRemoteObjects - POD types derive from QObject

[Stottlemyer, Brett (B.S.)]

On Monday, February 16, 2015 1:25 PM Roland Winklmeier wrote:
>a while ago the QtRemoteObjects project was started in the playground
>area. I
>had followed the  discussions closely, because I'm running a project
>which has a
>perfect use case for QtRemoteObjects. I haven't had much time to look
>into the
>details yet, but now I did.
>In the absence of documentation, I have several questions.
Hi Roland.

We have a patch for the initial version of documentation in progress.
Should be out in the next week or two.

>Quick background: the *.rep file format seem to support two types - POD
>and
>class.
>* Does POD types officially support composition? So can I define a POD
>type
>and use it as a member of a following POD/class? My tests seem to confirm
>my
>assumption, but I wanted to be sure.
Yes.  Since repc helps by auto generating the classes, and it can help
with the POD generation, including the necessary marshaling code and
registration.

The expected use case is when you want a simple structure for use as a
property or parameter for the Source/Replica object.

>* I was quite surprised to see POD types are deriving from QObject. I
>would
>expect it to be a non-QObject class. Is this a requirement for
>QtRemoteObjects
>or can I disable it? I have quite a lot classes which are not derived from
>QObject, because they are used in value semantics (actively copied,
>assigned
>etc).
This isn¹t tested significantly, but should work with the caveats below.

> This contradicts the QObject policy to be entities and not copyable. I
>was
>even more surprised to see the usage of qRegisterMetaType with QObjects.
>As already mentioned I have a lot value classes, which are already
>registered
>with the Qt metatype system, provide QDataStream operators.
Registration and QDataStream operators are the key elements, otherwise
QtRO has no way of passing the types over a socket.  They trick is that
this code needs to be compiled into every process using these types.  It
was added to repc to make this easier, but obviously repc creates the
types then.  Not helpful in your case.  Repc will copy any initial
#include statements, which should let you avoid use of POD types.

> So if subclassing
>QObject would not be a requirement, what would I need to add to handcraft
>the
>headers? I would bypass the repc tool completely and add the missing
>parts by
>hand.
This is fine as well.  If you don¹t use repc, you need to use dynamic
replicas.  The main constraint there is that you can¹t connect your
Replica to any slots until it is initialized, since it won¹t have a
metaobject to know what signals/slots/properties to provide.  You can also
set initial property values only if you use repc, if that is useful in
your case.  If you don¹t use repc, you need to handle the ³value² type
data stream and registration yourself, as mentioned above.

The actual Source object needs to derive from QObject, though.

>Btw. is there any kind of roadmap or design goal? Because I would love to
>see
>this in Qt and I'm curious what is still missing or what I still can
>expect.
>This would help me to evaluate whether I use it in my project or not.
It is still under active development, although things have been publicly
quiet for the last couple weeks.  I hope it finds its way into Qt at some
point, yet I must admit it doesn¹t yet meet the criteria (certainly docs
and additional CI tests). It is a matter of people expressing interest so
there is a clear value to making it part of Qt.

As for the roadmap, one specific item on the todo list is QAIM support.
We are bouncing other features around as well.  Please share if there are
features you think would be valuable.

Regards,
Brett

>