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-boun...@qt-project.org on behalf of daesde...@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
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
