> -----Original Message----- > From: J-P Nurmi <jpnu...@gmail.com> > Sent: Wednesday, 31 October 2018 12:41 PM > To: Mitch Curtis <mitch.cur...@qt.io> > Cc: development@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.cur...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
