[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