gmabey

Hmm -- so, if you're deserializing (writing into) a new instance, and there haven't been any copies made of that instance yet, then it wouldn't get copied when non-const members...

Hmm -- how about QExplicitlySharedDataPointer? Glen On Sun, Dec 13, 2020 at 4:51 AM Alexey Edelev wrote: > I made short code revision at code today and remember one more...

I'm very glad to see that this feature has been added to a specific milestone! However, it's continuing to haunt me in my usage of qtprotobuf ... is there anything...

Ok, good -- so do you (at least initially) agree with these points? * Remove `QObject` inheritance from all objects, and "changed" signals * Separate "data" and "methods" classes *...

So, *none* of the basic "data" types are derived from `QObject`, so why should the protobuf classes? https://doc.qt.io/qt-5/qtqml-cppintegration-data.html Now, I do agree that `Q_ENUM`'s and `Q_PROPERTY`'s need to be supported,...

Hmm -- actually, I was *trying* to ask you to reconsider whether the signals are necessary or appropriate for a *data* class. The reason why I sent the link was...

Oh -- wait -- do you anticipate using the qtprotobuf-derived classes as a QML Component?? I only ever envisioned using them as a property within a Component ...

Preliminary side note: I think it's a lot easier to read these "reply" comments directly in the GitHub issue, instead of in the notification email ... > > Oh --...

I'm extremely curious to know what your thoughts and plans are for this suggestion. Like, if you don't agree, that's fine, but it affects some decisions that I need to...

I've taken a whack at this approach, but I got stuck trying to understand what was going on with the nested messages :-/ https://github.com/gmabey/qtprotobuf/tree/shareddata This is definitely a WIP, but...