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