[Interest] QRemoteObject inheritance
Stottlemyer, Brett (B.S.)
bstottle at ford.com
Mon May 25 15:49:32 CEST 2020
Hi Daes,
On 5/24/20, 7:19 AM, "Daesdemon" <daesdemon at free.fr> wrote:
Hi Brett,
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.
Excellent. It opens up a lot of possibilities.
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 :)
One of those new possibilities ties in here. If you use repc to create the base class (Source or SimpleSource), it will have the Q_CLASSINFO() added to the class by repc. So you can create derived classes and then pass the derived class pointer to enableRemoting() call. That will get you the full API from the repc defined class up to the derived class. I didn't mention this before because I thought you weren't using repc because you had pre-existing QObject classes that didn't make sense to (re)create from repc.
MODEL and CLASS : do those keyword allow a hierarchy of object to be
exposed without more work ?
Correct. Although to be honest, the QAIM behavior isn't ideal. Since the model isn't local, even basic aspects, like the number of rows and whether a node has children, are asynchronous and answered by model updates.
And also, if you have some informations about that, are the cmake tools
ready for REPC ?
There's been cmake support for a long time. I know it works at a high level, but I still mostly use qmake.
Regards,
Brett
More information about the Interest
mailing list