On Sun, Dec 2, 2018 at 9:45 PM Thiago Macieira <***@intel.com>
wrote:
> Again "yes and no". QtCore knows a little about the existence of QtGui and
> QtWidgets, so qvariant.cpp and qmetatype.cpp have provisions to store the
> hooks for the operations on types from those libraries. It's messy code
> and
> has been a source of problems. For example, if v1 is a QtCore type and v2
> is a
> QtGui type, v1 == v2 might be true but v2 == v1 might not. Messy. JÄdrzej
> mentioned once he has a nice idea on how to fix it but couldn't fit it in
> the
> margins of his diary.
>
He did address the mailing list with a repository containing a
proof-of-concept of sorts for how the meta-type system may be
(re)implemented in the future. I admit I haven't given it a thorough
review, but it at a glance(!) looks okay.
But if we do support CBOR serialisation and deserialisation of types from
> QtGui, internally QCborValue would have a couple of callbacks for QtGui to
> post-process a decoded CBOR tag + payload.
>
That would probably be needed. Serializing only the types from QtCore would
constrain the usage of CBOR (in Qt) significantly, I think.
Note also that the vast majority of standardiseable types from QtGui are
> also
> types which we're discussing to move from QtGui to a non-GUI library.
> Previously I objected to having them in QtCore with the rationale that
> "QtCore
> is not the kitchen sink", but I'm open to new arguments.
>
I don't have anything of real substance to add to that. Perhaps only a
simple "outsider's view" - QtCore does seem to have gained quite a lot of
fat over the years, and moving yet more things into it will make it even
plumper, so I do understand your reluctance. But perhaps it's then prudent
to consider trimming it up by moving the non-core stuff into a separate
module which would be exactly the "kitchen sink", i.e. we need that around
but we don't need these classes very often. Unfortunately that'd require
some kind of "usage statistic" on what's used often and what not, which
isn't available to my knowledge. But even then if that's solved (in some
fashion) the question remains, what are the "core" classes, and what
classes are not, i.e. they're utilities and support that can be moved into
another binary. The distinction isn't always perfectly clear. Of course
adding yet another binary to deploy is also not to be taken lightly ... :|
That leaves the non-standardiseable ones, like QCursor, QTextFormat or
> QPen.
> And yet we'd like to transmit them over CBOR. The only question is how.
> One
> simple way is to reserve a metatype for "Qt 5 type" (or Qt 6), whose
> payload
> is an array consisting of an integer (the metatype ID) and a binary
> payload.
> That binary payload may be the same as QDataStream currently carries, or
> an
> improvement thereof. But if we're going to do this, we will need to be
> better
> at documenting the different payloads.
> Or we just reserve a tag for "QDataStream", consisting of version number
> and
> binary payload.
>
That'd be the "easy" way out, I guess. However it'd be really much better
if sensible data can be transmitted without resorting to QDataStream. You
yourself have said that QDataStream is portable and reliable as long as a
Qt application talks to a Qt application, but in some cases it _could_
(speculating here) be beneficial to have the data of a cursor (i.e a shape)
or QPen (i.e. width, color, cap, etc.) be available as separate entities to
a non-Qt application, and in a way that the hypothetical non-Qt application
can read it.
I think this is a good opportunity for us and the larger IoT community to
> discuss how to best transport such data. Compressing as JPEG or PNG may be
> good and well, but so is just plain transmitting of RGB/RGBA or YUV or
> YCbCr
> data. Imagine a fingerprint scanner device that wants to transmit its
> reading
> and let's say it's a 96x256 grayscale pixmap[1]. The device may not have
> sufficient processing power to compress the image as PNG, but 24576 bytes
> may
> be totally doable, even if it takes 26 UDP packets (960 payload bytes per
> 1024-byte datagram).
>
Yes, indeed this is what I had in mind. For a large image between desktop
applications it's definitely good to have some kind of compression
(preferably a good one) of the pixel data, but on the other hand that logic
falls apart if you're sending rather small datasets, or your device
couldn't handle the CPU requirements.
On Mon, Dec 3, 2018 at 4:59 PM Jason H <***@gmx.com> wrote:
> Kinda wondering why you just don't use QVariant and a QDataStream? You're
> just encoding as text, and if you need to use images, there's no current
> encoding (AFAIK) for pixel data in CBOR, so you can't interop with anything
> else anyway...
>
> I found CBOR limiting and not worth it. I was very interested in the
> promise/premise of CBOR, but I went QVariant+QDS and was glad I did.
>
Hi Jason,
Thanks for the input, I do appreciate it. I was just evaluating the
possibilities, more than committing to it. I have done my fair share of
network programming, and indeed QDS works just fine. It may be required to
have the server opened to non-Qt applications in the (more distant) future
however, so QDS fails in that regard. I can't make the clients match their
understanding to the QDS' versions and encodings, so that's why I was
inquiring of what's possible and what not.