[Interest] QRemoteObject inheritance

[Stottlemyer, Brett (B.S.)]

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