Re: [Development] Json support for QtCore
On Sun, Dec 11, 2011 at 8:31 AM, Robin Burchell robin...@viroteck.netwrote: hi, On Sat, Dec 10, 2011 at 10:32 PM, lars.kn...@nokia.com wrote: I've benchmarked parsing speed and compared to the qjson (http://qjson.sourceforge.net/). It's around 7 times faster for the test.json file included in the project (the test case used in qjson as well). I'd be interested to see how your parser fares compared to girish's work (existing benchmark results, somewhat outdated probably, found at http://git.forwardbias.in/?p=qjsonparser.git;a=commit;h=180f3a1ea85adbea4d77e50ff3be3e75af918252 ) - those results at least look a lot better than 7 times faster, but they are also probably different test data. But, parser aside: in general terms, I do think I agree that converting to/from QVariant as an API isn' all that nice, so your approach is a nice alternative. I do think I'd like to see QDataStream operators on QJsonDocument, btw. sending json documents in binary form to/from files or sockets would be useful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development A side chat about the stream operation. I have made a tiny project / class to help to convert a non-QObject based class to QVariantMap , and vice versa easily . So that it could be converted to JSON/XML/YAML by just taking a further step. http://www.qtcentre.org/threads/46315-QtMapStream-serialization-of-object-class-to-QVariantMap ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Json support for QtCore
Op 11-12-2011 15:55, lars.kn...@nokia.com schreef: The binary representation is optimized for fast reading. The binary format is relatively compact and stores the whole object in one blob. Is this a standard binary format of JSON, or something of your own devise? It's something I wrote. I wanted it to be something that you can simply mmap from a file and use without ever having to parse anything to make saving and restoring of json objects as cheap as possible. The problem with bson is that it's a streaming format that still requires parsing and as such was unsuitable for some of the use cases I have. I think I am missing something here. What is the use of this? I mean, if it is not JSON, then it is just some random binary format, right? How does that help with parsing and providing JSON when you are communicating with a webservice, for instance? I mean, it is cool to have a file format that is able to contain a lot of standard stuff and be quick about it, but I don't really see the connection with JSON, and calling it a binary format of JSON is confusing to me. However, like I said, I guess I am missing something here. Could you explain what the relationship is between this binary format and the JSON format, and how it helps parsing creating JSON? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Json support for QtCore
On Sun, Dec 11, 2011 at 5:33 PM, Andre Somers an...@familiesomers.nl wrote: However, like I said, I guess I am missing something here. Could you explain what the relationship is between this binary format and the JSON format, and how it helps parsing creating JSON? You're missing the bit where the binary format is not the only representation. JSON can be parsed into it, it's stored like this in memory, and it can be serialised back to it (obviously), but it can also be serialised back to JSON. Or QVariant. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
Stephen Kelly said: On Wednesday, November 09, 2011 13:54:37 Thiago Macieira wrote: On Friday, 28 de October de 2011 12:38:38 lars.kn...@nokia.com wrote: We've been moving this lib quite a bit already. If we move it again, I'd prefer it would end up at it's final location. The move was done before we had the decision to keep QtCore independent of V8 and to separate the QJS* classes and the QML engine into it's own module. With the above decision it might make sense to move V8, the QJS* classes and the QML engine all into the same shared library. Kent Aaron, any thoughts? Since they don't seem to have an opinion, can we please move it to top-level inside qt5.git? I've just caught a bad commit in my tree that updates the commit link to v8 and I'm trying to fix it with an interactive rebase. Bump. This is a recurring problem with newcomers trying to build qtbase. They don't know to do the git submodule magic or use -no-v8, so the build fails. I think this can be easily mitigated by having qmake check if the sources exist, rather than simply assuming that they do. e.g. http://codereview.qt-project.org/10934 . ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to create new Qt modules or tools
Laszlo Papp said: 1) Build and software testing service Is there a build and software testing service provided for projects in the Qt Playground repositories ? I have not seen any mentionings about that so far. and it is an important question in my case, for instance. I have been using CDash [1] for projects under the KDE umbrella. It is possible as long as I use cmake as a build system in my project. I think such a build and software testing service along with the publishing of the build results would increase the QA of those playground projects. I know there are such QA services for final modules. I was just curious if those tools, providing the relevant services, are available to Qt Playground projects or not. If not, are there some other options ? It would be really nice if playground projects could get such an attention. I am not willing to propose it for all the projects there because I do not know the capacity, but at least for projects and maintainers there who are interested in this matter. Security is a potential issue for providing the same test resources used for the main Qt modules to be also used against playground modules. These test machines are Internet-connected[1], and arbitrary code can be set up to run on them; lowering the barrier for getting this arbitrary code onto the machines of course increases the security risk. http://my.cdash.org/ It would be interesting to know for example how Kitware handled this issue for the above, or if it was explicitly decided to accept the risk (which may well be a valid approach, given that the process includes a trusted maintainer signing off on the new playground project). [1] perhaps not forever - I'm describing the way things are and not necessarily the way they should be :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt platform and theme plugins
On Dec 9, 2011, at 9:00 PM, ext Charley Bay wrote: From the description, this appears to be an effort to establish a common API or approach for *both* Qt5Widgets and QML2+? That's what I'd be most excited about (one approach). Selfishly, I'm mostly focused on QML 2+ in Qt5+, even we'll have legacy widget styling needs at some level after migrating to Qt5, (we're currently using Qt stylesheets). This sums it up pretty well: A common API for platform integration that widgets, QML (and QtWebkit?) can use. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
