[Interest] QRemoteObject inheritance

[Daesdemon]

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

Of course they aren't.
That doesn't seem evident to me, you can believe it :)

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


I understand the REP is to define an interface, but it is only useful 
when you have to  limit interface of your object.

In my case, remoted object are constructed for remoting, so properties i 
declare are to be exposed.

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.

If i would want to restrict the interface, i could already wrap the 
object in an other QObject interface (as REP) or to use REP if i could.

In my opinion, replicas should replicate the qobject not the last 
superior part of it. It forbids inheritance.

It would avoid a lot of Boilerplate in my case.


For informations, i didn't tried base slots until now but it seems they 
are'nt exposed neither.

So no way about a QObject inheritance to remote. Let's create all 
objects from scratch each time :)


You talked about different ways to modify that behaviour. Do you have 
one in mind for dynamic replicas ?

Cordially.

Daes



Le 22/05/2020 à 13:55, Stottlemyer, Brett (B.S.) a écrit :
> Hi Daes,
>
> On 5/21/20, 5:15 PM, "Interest on behalf of Daesdemon" <interest-bounces at qt-project.org on behalf of daesdemon at free.fr> wrote:
>      > Hello Qt people,
>      It seems that QObject properties of a base classe are not exposed to
>      Replicas of Derived class.
>
> Of course they aren't.
>      
>      This seems to me like a bug but i would like to have your thoughts about
>      that.
>
> Not really.  A class can have several levels of inheritance going back to QObject.  QObject itself has several has properties, signals and slots.  E.g., `objectName` and `objectNameChagned()`.  Qt Remote Objects, behind the scenes, creates a new QObject-based type on the replica side that has the API of the original class.  But including QObject API (properties, signals and slots) doesn't make sense.  I.e., you can change the replica's name independent of the source - they shouldn't be tied together, so that shouldn't be part of the API.  So if you have inheritance, but you don't want to move up the chain all the way to QObject, where do you stop?  By default, QtRO uses just the API of a single class.
>
> While there are several ways to modify this, the recommended approach is to create a .rep file describing the parts of the interface you want to use, and let repc generate the <Type>SourceAPI class [1] in a header.  You can then use whatever QObject you want as the source, but the templated `enableRemoting<...SourceAPI>()` call will expose the proscribed API over the Remote Objects network.
>   
> Regards,
> Brett
>
> [1] https://doc.qt.io/qt-5/qtremoteobjects-source.html#typeapi
>