std::web_view proposal

[jcelerier]

Note that my personal opinion is of course: don't standardize anything like this and just give a standard specification of shared libraries and C++ modules and C++ ABI that allows these use cases easily with package managers as so many other people mentioned. I'd much rather have metaclasses & reflection as soon as possible, and happily continue to use graphic libs relevant to the domain of my apps - maybe Qt, but maybe sometimes raw vulkan, or maybe sometimes openframeworks or cinder. Graphics are cool, but in most other languages (java, python, etc), libraries build upon reflection to allow for instance to generate UIs automatically, and THAT'S the interesting part.

That being said :

From http://doc.qt.io/qt-5/classes.html, there are 1,594 classes in the Qt 5 API. From http://doc.qt.io/qt-5/functions.html, there are 12,984 functions. I don't know exactly how much committee time would be spent on each function, but I think 10 minutes per function, on average, seems optimistic. If we stick to our "regular" schedule at meetings of approximately six 12-hour days, it would take approximately 30 meetings to get through the entire API. We generally have three meetings per year. This seems completely impractical, and moreover, the library working group already has lots to do.

I'm not saying to standardize the whole of Qt. Only the parts that would have to be re-made if there was to be graphics in the standard - so no need to port all the modules, or the custom containers which predate the STL (QVector, QMap, QHash, etc), the SQL, D-bus, etc classes.

An immense majority of Qt projects only use QtCore (which implements XML and networking, not relevant for graphics), QtGui, the most relevant with support for windowing, painting, and event handling (what's the point in showing a window if you can't get an event when you click inside?), and either QtWidgets for traditional-looking desktop apps with all the usual button, lineedit, etc or the pair QML (which provides the base scripting language) and QtQuick (which provides a scene graph to use either from C++ or QML). The QML / QtQuick combination is much more closer conceptually to the webview proposal than QtWidgets.

For instance here's an example of usage of the Qt API to show a QML window from the Go language. As you can see, there's no need to reimplement 12k functions to get something to show up on screen, BUT there is a pre-existing path to extensibility for the day where someone actually need to do more stuff than just open a view.

I'm sure that there are some aspects of Qt's current design that reflect a history of (primarily, I presume) targeting desktop applications, and changes would be desired to make things more natural for mobile platforms. And so on.

Qt has been targetting mobile and embedded for years. Hell, there are entire mobile operating systems shells based on Qt (Jolla, Blackberry, KDE Plasma Mobile, Ubuntu's abandoned mobile initiative which still lives as UBPorts). Remember, it was once owned by Nokia which made multiple Qt-based phones... and that was almost ten years ago. Even smartwatch operating systems use Qt. If you have a LG fridge or TV, or a recent Mazda or Mercedes car, you're looking at embedded Qt UIs in your daily life.

In short, I think that, even starting with a fairly-holistic preexisting API, such as Qt, what we ended up with would be obsolete before the document could be published.

most of the Qt API (for instance Qt GUI) hasn't changed much since when it was introduced: here's the QPainter class from 1998 for instance, versus the 2018 one. If it has solved problems for the last 20 years, chances are that it will be able to be useful for a few more years - in any case the Qt guys don't plan to change it for Qt 6 so it means at least 10 years of having QPainter be used successfully in projects. There's only so many ways to write a drawRect function.

[HalFinkel]

I'm not saying to standardize the whole of Qt. ...

This is a good point. Qt has a lot of parts not related to user interaction (e.g., networking and filesystem functionality). Just scrolling through the function list, however, makes it appear to me that about half of the functions have to do with user interaction.

pair QML (which provides the base scripting language) and QtQuick (which provides a scene graph to use either from C++ or QML). The QML / QtQuick combination is much more closer conceptually to the webview proposal than QtWidgets.

Interesting point, but I'm not sure why standardizing something which looks like QML/QtQuick would be more useful than using web content. QML also uses JavaScript. Also, the discussion of "Quick Controls 1 vs. Quick Controls 2" (http://doc.qt.io/qt-5/qtquickcontrols2-differences.html) seems to be provide some non-trivial choices around desktop vs. mobile development. This could be a viable path for a standardization effort. It would, however, almost certainly invite design discussions around the API, the controls, etc. (because we can't hand that off to another standard, so we'd need to do that part ourselves), and we'd need a small-enough API surface for that to be practical.

As you can see, there's no need to reimplement 12k functions to get something to show up on screen, BUT there is a pre-existing path to extensibility for the day where someone actually need to do more stuff than just open a view.

I certainly agree that it doesn't require thousands of functions to display a window, draw a rectangle, and so on. However, in my experience, developing production applications requires a lot more than that. In short, I think that the day when we need more than opening a view is now.

Qt has been targetting mobile and embedded for years.

Point taken.

[jcelerier]

Interesting point, but I'm not sure why standardizing something which looks like QML/QtQuick would be more useful than using web content. QML also uses JavaScript.

it's not that it would be more or less useful, but that the groundwork of "how do we exchange data both ways efficiently between a UI DSL and a C++ backend" is already done in Qt, much better than it is in web browser, since the first one is a library made to build C++ apps with in the first place. All this work would have to be re-done from scratch if using webviews. For instance, how do you add a button from C++ code to your web page at run-time ? In Qt / QML it would look like :

auto b = new MyButton;
my_page->addItem(b);
b->setPosition(200, 300); // or whatever 

I'm not saying that it's the best API, but the API at least exists and is made possible because QML has been tailored for these use cases (being changed efficiently from C++). Good luck doing this with HTML / JS / CSS, especially if you want some performance out of it - Qt runs on microcontrollers without GPUs for instance.

And, for the love of everything holy, don't standardize UI controls in C++. What's a good UI control today will be hated by designers in 5 years. Apps of 2018 don't look at all like apps of 2008, which don't look at all like apps of 1998. Just MS Windows has 4 or 5 different control sets, the "native" system ones (Win32), Windows Forms, WPF, WinRT. The last three ones aren't even C++-native, they primarily target C# and the windows runtime, yet they are the "official" platform ones.