[Interest] QRemoteObject inheritance

[Daesdemon]

Hi Brett,

Thanks for those details, it will help me to start the tests in the 
right direction.

	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.

Yes that is currently what i have: hierarchy of classes created specially for remoting, from a hierarchy of back-end classes non-exposed.
So that would require a bit of refactoring, but it deserves at least a try, if that make my code simplier.
        
	    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.
Yes, i am aware about the remote model limitation, but it has merits to easily expose an existing model.
Currently i am constructing dynamically models client side from Replicas data, but it requires obviously a lot of extra-coding, but in fact, i am more interested by the CLASS keyword, that could help me to create hierarchy of remoteobjects quite easily.
I suppose it enableRemote on the property Object automatically.

		 And also, if you have some information 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.

Yes, sorry i found it:
https://doc.qt.io/qt-5/qtremoteobjects-cmake-qt5-generate-repc.html

qt5_generate_repc(SOURCES simpleswitch.rep 
SOURCE)add_executable(directconnectserver ${SOURCES})

Thanks a lot for your advice.

Daes


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20200528/cb3c2d42/attachment.html>