[Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString

[Mitch Curtis]

> -----Original Message-----
> From: J-P Nurmi <jpnurmi at gmail.com>
> Sent: Wednesday, 31 October 2018 12:41 PM
> To: Mitch Curtis <mitch.curtis at qt.io>
> Cc: development at qt-project.org
> Subject: Re: [Development] Serialising UI state in QML via QSettings and
> JSON: QByteArray vs QString
> 
> On Wed, Oct 31, 2018 at 8:25 AM Mitch Curtis <mitch.curtis at qt.io> wrote:
> > > Pass the state as a base64 string. Where does it turn to a byte
> > > array if
> > > Qt.btoa() returns a string?
> >
> > As of the previous patch set, saveState() returned a QByteArray, so the
> user starts off with a byte array. If I somehow manage to make Qt.atob() and
> Qt.btoa() accept and return a byte array (it wouldn't make sense to accept a
> byte array and return a string), this prevents writing such state to JSON due
> to its lack of support for byte arrays.
> >
> > The only way to serialise SplitView's state to JSON if we changed these
> functions to use byte arrays would be to go through each value in the
> QVariantMap that is exposed to QML for it to set the UI state (QJsonObject
> can't be exposed to QML) and check if it's a byte array and then convert it to
> a Base64 string. That seems very hacky for users.
> >
> > > > What do you think about the proposed solution of saveState()
> > > > returning a
> > > Base64 QString?
> > >
> > > -1 :)
> >
> > Can you explain why? It's a negligible difference in binary vs text for the
> amount of data we're talking about.
> 
> What you do inside saveState() and restoreState() is your business.
> Whether you use JSON, CBOR, QDataStream, or something else, doesn't
> really matter. But I don't see any compelling reason to deviate from the
> "standard" QByteArray-based save/restoreState() pattern used in Qt
> Widgets, including QSplitter. Don't let a silly bug in Qt.btoa() drive the API
> design. If you want to store a binary blob in JSON, base64 is probably a good
> option, but why enforce it for those who don't need it? For C++ users,
> QByteArray provides the tools to encode and decode base64. Since base64 is
> ASCII, you can safely convert to QString and store it in JSON. In QML, you are
> supposed to be able to do the very same with Qt.atob(), Qt.btoa(), and
> toString().

Looking closer into the code and tests, it seems that they are indeed completely broken, and somehow nobody ever noticed or complained:

http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/qml/v8/qqmlbuiltinfunctions.cpp?id=4a886753a75c7c4d66f1fa9cab5a6c5a03240df3#n992
http://code.qt.io/cgit/qt/qtdeclarative.git/tree/tests/auto/qml/qqmlqt/tst_qqmlqt.cpp?id=4a886753a75c7c4d66f1fa9cab5a6c5a03240df3#n937
http://code.qt.io/cgit/qt/qtdeclarative.git/tree/tests/auto/qml/qqmlqt/data/atob.qml?id=4a886753a75c7c4d66f1fa9cab5a6c5a03240df3
http://code.qt.io/cgit/qt/qtdeclarative.git/tree/tests/auto/qml/qqmlqt/data/btoa.qml?id=4a886753a75c7c4d66f1fa9cab5a6c5a03240df3

I'll look into fixing them and then go back to using QByteArray in the API.

> --
> J-P Nurmi