[Interest] QCborValue and Qt types

[Konstantin Shegunov]

Thanks for the heads up.

On Sat, Dec 1, 2018 at 7:43 PM Thiago Macieira <thiago.macieira at intel.com>
wrote:

> Yes and no. See the attached draft spec (tag numbers are outdated) for a
> few
> types I had been thinking of and already have an implementation for. Which
> also reminds me I needed to send them to the CBOR IETF group for review.
>

Looked them up, they seem fine to me. Hopefully the IETF agree.


> I was thinking of sticking at first to QtCore types, so QImage will not be
> included. I'm not even sure how we could add support for types in other
> libraries; possibly you'll need to register a serialisation and
> deserialisation function like qRegisterStreamOperators does.
>

Yes, this is how I imagined it initially. I suspect this is how it's done
currently for registered meta types?


> And also note that we'll never get actual matching to Qt types. Like in
> the
> attached geometry proposal, there's one type for size, not one for size
> and
> one for size-float. This is important if you look at classes that are
> identical but of different generations, like QVector4D and QQuaternion, or
> worse functionally identical ones like QPixmap, QBitmap and QImage. We
> won't
> get a standard tag that distinguishes them, since that distinction is not
> useful outside of Qt. I'm open to ideas on how we can address that.
>

Yes, I didn't think of that, but it makes sense. I suppose it should be
treated on a case-by-case basis. For the former I'd say something like
"geometry transformation" could be used, i.e. a catch-all for the
quaternions and/or matrices.
For the latter it's harder to judge, but probably it would be necessary to
use some kind of device-independent pixel format. If data encoding can be
used (e.g. png/jpeg) all the better, but even raw pixels should serve fine.
Granted this means that QPixmap and QBitmap may need to be converted to
QImage and vice versa, but I really see no clever way around it, at least
off the top of my head. That is unless it's acceptable to encode
meta-information like bit depth and such in the data stream, then maybe
some small optimization could be possible. Probably this'd mean that the
user will need to "know" beforehand what exact kind of object was put in
the cbor document, but without a schema I'd say that's probably to be
expected.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181202/fb593a8a/attachment.html>