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(). -- J-P Nurmi _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development