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

[J-P Nurmi]

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().

--
J-P Nurmi