[Development] As Qt contemplates its future..

[Konstantin Tokarev]

15.04.2017, 01:23, "Shawn Rutledge" <shawn.rutledge at qt.io>:
>>  On 13 Apr 2017, at 14:02, Randall O'Reilly <randy.oreilly at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin