[Interest] QRemoteObject inheritance

[Daesdemon]

Hi Brett,

Thanks a lot for your time and explanations.

It is now clear about the design., and i understand the point. I had 
thoughts on problems you talked about when i believed QtRO was exposing 
the complete QObject interface by default.

I don't know why, but i even didn't think to use REP on the server 
side,only. That could obviouly changes a lot of thing as a boilerplate 
tool. It was an all or nothing in my head, even if i knew globally the 
way it works.

For a quick test i will try the 
Q_CLASSINFO(QCLASSINFO_REMOTEOBJECT_TYPE, <My Class Name>) then I'll 
change my design to test the SourceAPI usage. I will probably have new 
questions :)

And to celebrate that i will perhaps use the REPC, I saw about some 
relatively new REP keywords:

MODEL and CLASS : do those keyword allow a hierarchy of object to be 
exposed without more work ?

And also, if you have some informations about that, are the cmake tools 
ready for REPC ?

Thanks again.

Daes


Le 23/05/2020 à 17:04, Stottlemyer, Brett (B.S.) a écrit :
> Hi Daes,
>
> On 5/22/20, 12:41 PM, "Daesdemon" <daesdemon at free.fr> wrote:
>
>      Hi Brett,
>      
>      Thanks for your answer.
>      
>      My current project is completly based on dynamic Replica, i cannot use
>      Rep, and i am quite happy of the result. To simplify, i have only QML on
>      the client.
>      
>      Dynamic replicas + QML is just magic :)
>
> Agreed! With a lot of hard work (mostly on the QML side) __
>      
>      Your reasoning is also true for the final remoted Object that could have
>      some properties you don't want to remote, so why direct properties but
>      not inherited properties...?
>      
> Exactly! This is the problem the SourceAPI was designed to solve.  I am talking about an interface definition (via .rep) which is applied to both the _source_ and _replica_.  It is a contract, but if you use dynamic replicas, the source sends its interface.  So the contract is defined by which enableRemoting() call is used. If you generate the *SourceAPI* class in a *source* header, it affects and is applied on the enableRemoting() call, not the acquire() call.  As long as you don't use the Source or SimpleSource classes, just the SourceAPI class, the header file can just be included.  It applies to any QObject pointer, and will identify (in a similar way to what the "new style" compile-time connect() works) which properties, signals and slots to expose over the network _from any layer of the inheritance_.  Again, you don't need to derive your class from either Source or SimpleSource, and you can continue to use dynamic replicas on the acquire() side.
>
>      I understand the REP is to define an interface, but it is only useful
>      when you have to  limit interface of your object.
>
> I don't really see it that way.  I start with the interface, and let repc generate the boilerplate code for my source classes.  There's nothing that forces you to generate/use the replica-side headers.
>          
>      You talked about different ways to modify that behaviour. Do you have
>      one in mind for dynamic replicas ?
>      
> It doesn't matter which enableRemoting() method you use, you can always use dynamic replicas. If the generated SourceAPI doesn't work for some reason, the other option is to manually add
> `Q_CLASSINFO(QCLASSINFO_REMOTEOBJECT_TYPE, <My Class Name>)`
> to the QObject class definition of the _base_ class you want to start getting API from.  It will (or I guess should, this isn't extensively tested) expose all API elements from the class with the Q_CLASSINFO up to and including the passed in QObject class [1].
>
>      QObject has only minimal properties, signals and slots. I agree about
>      the use case of the objectName, but it seems only useful in a very
>      particular case: Having a nickname for an already named object.
>
> Answering this part out-of-order.  This is a design question, so let me give a bit of detail for why it was designed the way it was.  You seem to suggest that there are only a few API elements in the QObject class itself, so it wouldn't be a big deal to expose them in the QtRO network and just not use them. I believe there a several reasons this couldn't be allowed.
>
> First, there are technical issues integral to QObject behavior. What would deleteLater() on a replica do? As a slot, it wouldn't act on the replica, but would instead be handled by the source first and then propagated to all replicas. That clearly wouldn’t make sense.  Also, how would the `destroyed()` signal be interpreted?  Is it being propagated from the source?  Or the local replica?
>
> This touches on the 2nd reason, which is that Qt is clear that QObjects cannot be copied.  QtRO tries to be clear that it is creating a new object that _acts_ like the original, but is not a copy. Signal/slot connections are not shared, for instance.  Not including the QObject's interface is a way of trying to make that clear.
>
> I understand the question.  I hope this explanation makes it clear this wasn't a cavalier design decision to make QtRO harder to use...
>
> Regards,
> Brett
>
> [1] https://code.qt.io/cgit/qt/qtremoteobjects.git/tree/src/remoteobjects/qremoteobjectnode.cpp?h=5.14.2#n163
>