15.04.2017, 01:23, "Shawn Rutledge" <shawn.rutle...@qt.io>: >> On 13 Apr 2017, at 14:02, Randall O'Reilly <randy.orei...@colorado.edu> >> wrote: >> >> With the recent language explosion, there are now languages to fit >> everyone’s biases and aesthetics. > > This explosion is possible because of common language backends and VMs like > the JVM, CLR or LLVM. (Hacking gcc to add a new language would’ve been much > harder.) So, hopefully that means that you don’t have to champion Go itself > as the language of the century and plan on rewriting all of Qt in Go, right? > As long as you can generate LLVM-IR somehow from your favorite language at > this juncture, you share a foundation with plenty of other languages, so > maybe modules written in one could interoperate with modules written in > another? Depends on the ABI though. > > The Rust guys make the point that it’s necessary to rewrite lots of old stuff > in Rust in order to have all the security that it can guarantee. But with Go, > is there such a mandate? To me so far, Go seems incrementally better but not > quite a revolution; fine to try for new projects but maybe not worth the > effort of rewriting old code. And of course I’ve been around the block before > with this idea that such-and-such needs to be rewritten in such-and-such > new-hotness language. The next rewrite ends up more bloated and slow than the > last… that seems to be the rule. > > One big obstacle I’ve been seeing for years is the shortage of C++ API for > the QtQuick scene graph, and the difficulty of separating the scene graph to > be independent of QML. If you want to have one language for your application > (which isn’t QML, Javascript or C++) then you need scene graph bindings to at > least be possible. And the usual reason we give is that we don’t have public > API so that we remain free to change it. But it’s still an obstacle for > making bindings. IMO we’ve got to get to the point where at least the private > APIs are complete enough and reasonable enough to use, so you could maintain > a scene graph binding for another language alongside Qt, and iterate along > with it. Or else rewrite the scene graph, but that seems like needless work, > doesn’t it? You can search GitHub and find plenty of scene graphs, but how > many of them can do internationalized antialiased text using an atlas (not > pre-rendering whole words or lines with freetype), and how many of them do > batching like Qt's? > > Next, why does Go not use LLVM by default? Why do QML and V4 not use it, for > that matter? I was hoping we’d do it that way, but we didn’t. I think it > would have saved some work, and gained some interoperability, and a lot of > tooling possibilities.
Concerning QML/V4: this is a good idea actually. If QML is changed to use AOT compilation as the only mode, it might work very well. > >> This also means that there is an endless potential for language wars, which >> I’m sure nobody wants to rehash on this list. My point is just that Go >> represents a particular set of choices that I think is very compatible with >> a certain (possibly large) segment of the Qt user-base — those who favor >> clarity, simplicity, readability, over e.g., extreme performance >> optimization or having every different kind of possible language feature at >> one’s disposal (aka “language bloat”). As C++ is seemingly in a constant >> state of reinvention lately, and is now massively bloated and unwieldy in >> some people’s estimation, it might be an opportune moment to consider a >> “reboot” — a fresh new framework unburdened by all that cruft. My sense is >> that Go has made some really excellent (and hard) choices that benefit from >> all the different language experiments and experience (and especially the >> limitations of C++), and that one major thing holding it back is lack of a >> decent GUI framework, so that Qt could really make a big difference there. >> Furthermore, Qt itself has a kind of bloat problem of its own, having >> evolved in major ways over the years (Widgets vs. QML, scenegraphs, and now >> 3D), so it could possibly benefit from a fresh start / reboot as well. >> >> Perhaps building from the ground-up on a core scenegraph framework that can >> support 2D *and* 3D, > > and usually it would be pointed out that a 3D engine is terrible overkill for > 2D UIs. But now we’re coming out with that third choice anyway, Qt 3D Studio. > So maybe we’ll get there after all, and find out whether or not a 3D scene > graph is practical for ordinary everyday UIs. Of course if there ends up > being a good reason to have a true 3D UI in most everyday ordinary > applications, then the 3D scene graph is not overkill I guess. > >> with different back-end renderers (OpenGL ES etc), using e.g., SVG syntax >> to do the widget etc painting in a resolution-independent, style-based >> manner (no more high-dpi hassles — future proof resolution independence).. > > What I want in addition to purely scalable graphics is to do all the > rendering on the GPU: no more pre-chewing of all the vertices by the parent > CPU before feeding it to the little baby GPU cores. It would be worth > whatever upheaval is necessary to get there, IMO. And by the time we figure > out how, maybe we won’t have to worry about limited back ends like OpenGL ES > anymore. > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
