[Development] QtRemoteObjects - POD types derive from QObject

[Roland Winklmeier]

Hi Brett,

thanks for your quick answer.

We have a patch for the initial version of documentation in progress.
> Should be out in the next week or two.
>

That sounds brilliant. I'm looking forward to it.


> > This contradicts the QObject policy to be entities and not copyable. I
> >was
> >even more surprised to see the usage of qRegisterMetaType with QObjects.
> >As already mentioned I have a lot value classes, which are already
> >registered
> >with the Qt metatype system, provide QDataStream operators.
> Registration and QDataStream operators are the key elements, otherwise
> QtRO has no way of passing the types over a socket.  They trick is that
> this code needs to be compiled into every process using these types.  It
> was added to repc to make this easier, but obviously repc creates the
> types then.  Not helpful in your case.  Repc will copy any initial
> #include statements, which should let you avoid use of POD types.
>

I think we have the same understanding of the POD type purpose. They are
mainly used as parameters or properties of a QObject.
What I don't understand is, why these POD types need to derive from
QObject. Maybe there is an important reason, hence the question.
The source objects clearly need to derive from QObject because they provide
signals and slots, but properties and parameters usually don't - at least I
haven't seen any QObject derived property in Qt's source code. Unless they
are meant to be used in a parent-child hierarchy: Object A is parent of
Object B and this hierarchy is replicated on the other side. Correct me if
I'm wrong but the QObject parent-child system is orthogonal to QObject
property system. It seems both systems are currently implemented in QtRO in
a mixed way. AFAIK copying around QObjects per value, is generally ok, but
not nice and not recommended.

I'll give a quick example of what I'm trying to achieve. Lets say we have a
source object which has several signals and slots. For the sake of the
example, I use a thermometer source giving me the temperature of a
connected device.

class CThermometer : public QObject
{
    Q_OBJECT
    Q_PROPERTY(float temperature READ temperature WRITE setTemperature
NOTIFY temperatureChanged)
public:
    explicit CThermometer(float temperature, QObject *parent = Q_NULLPTR) :
QObject(parent), _temperature(temperature) {}
    CThermometer(const CThermometer& other)
        : QObject()
    {
        QtRemoteObjects::copyStoredProperties(&other, this);
    }

    CThermometer &operator=(const CThermometer &other)
    {
        if (this != &other)
            QtRemoteObjects::copyStoredProperties(&other, this);
        return *this;
    }

    float temperature() const { return _temperature; }
    void setTemperature(int temperature) { if (temperature != _temperature)
{ _temperature = temperature; Q_EMIT temperatureChanged(); } }
Q_SIGNALS:
    void temperatureChanged(float temperature);
private:
    float _temperature;
};

Now I want to use a custom type for temperature. So instead of float
_temperature, I use CTemperature _temperature acting as the value type.
CTemperature is a plain custom C++ class, does have QDataStream operators
and is registered as QMetaType. If the temperature value changes
CThermometer will send a signal with the value as its parameter. The
property itself does not need nor have signals itself. So to me it looks
like, I shouldn't use the repc POD type, but rather include the header of
CTemperature. repc will handle it as any other basic type and the compiler
sorts out the rest. Is that correct?

In any case, I will try to implement a basic test with this scenario to see
if that works.

Regards,
Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150218/e18f8213/attachment.html>