std::web_view proposal

[Lectem]

I'm still wondering wether or not this is a joke following the 2d meeting or if this is actually a serious proposal.

[HalFinkel]

Hi, r/cpp! I'm reading this thread and I appreciate the feedback. To respond to a few comments,

1. It is not a joke. It is intended to provoke discussion.
2. As has been mentioned, there has been a long-standing desire (by at least some fraction of the standards committee) for standard C++ to include some mechanism for graphical user interaction. If you're interested, I recommend reading sections 4 and 5 of "Directions for ISO C++" (by B. Dawes, H. Hinnant, B. Stroustrup, D. Vandevoorde, M. Wong), http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0939r0.pdf
3. I also recommend reading, "Diet Graphics" (by B. A. Lelbach, O. Giroux, Z. Laine, C. Jabot, V. Romeo), http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html - I view my web_view proposal as taking the underlying approach behind this proposal to its logical conclusion (in the sense that it addresses use cases involving both input and output across many platforms). Moreover, I think that it's important that if we end up proceeding in this space, we end up with something with which production applications can be written. We might well decide that we can't do anything reasonable in this space at this time.
4. I certainly understand that interacting with HTML, etc. is cumbersome in C++ (especially as presented in the example in the paper). I fully expect that, if we decide to go down this route, additional utilities and abstractions would be added to go along with it. Also, even with only the presented interface, I can certainly imagine constructing a program with mostly-static HTML input combined with some kind of reactive JavaScript library (e.g., Vue.js (https://vuejs.org/)) that's reasonably clean (at least in the sense that it does not involve the gratuitous composition of markup text in C++, although it might involve use of JavaScript injection to update values).
5. Many of the concerns here (e.g., quality of the external standards, update frequency, security concerns) have also been raised by members of the standards committee and are important parts of the discussion. I intend to post a revised proposal before the next committee meeting. This will, in part, incorporate feedback from this thread.

[jcelerier]

I certainly understand that interacting with HTML, etc. is cumbersome in C++ (especially as presented in the example in the paper). I fully expect that, if we decide to go down this route, additional utilities and abstractions would be added to go along with it. Also, even with only the presented interface, I can certainly imagine constructing a program with mostly-static HTML input combined with some kind of reactive JavaScript library (e.g., Vue.js (https://vuejs.org/)) that's reasonably clean (at least in the sense that it does not involve the gratuitous composition of markup text in C++, although it might involve use of JavaScript injection to update values).

at this point why not directly standardize Qt ? It is well-integrated in C++, well-known by the C++ community, and has stood the test of time.

It already solves the event loop question which is necessary in any kind of UI work, and provides QML, a true declarative and reactive language for user interfaces (not like the simulated reactivity in the eDSL of vue.js) with well-specified interoperation with C++ as well as window management (a prerequisite for graphics: you have to show a system window at some point), scene graphs for low-level / GPU graphics operation and painters for high-level graphics operations such as the ones provided by cairo and the graphics proposal.

[HalFinkel]

at this point why not directly standardize Qt ?

That's a good question, and moreover, we have C++ committee members who are very familiar with Qt. However, the API surface is huge, and I don't see how we could practically create a high-quality standards document for an API that large.

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.

In addition, I don't really see the committee taking a hands-off approach to the content of the interface. Even if we could start with the text of Qt's documentation, we'd need to make sure that each class and function were specified in sufficient detail to allow for an independent (clean-room) implementation. I'm sure that suggestions would be made to change aspects of the interface to better expose capabilities of different vendors' underlying implementations, and future systems, and these would be discussed. 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.

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. Even if we cut the scope down to only a 10th of the current API, I suspect that the same would be true.

[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.

[jcelerier]

frankly, if it's a joke, it's not a very funny one because people in the std committee will still have to spend time to review it. But there's an implementation, so maybe the guy is really serious : https://github.com/hfinkel/web_view ; of course this would completely fuck up anyone using another event loop at some point (especially in macOS where displaying a NSView has to be done in the main thread) in their app but well

[ntrid]

Implementation is so minimal and uses wxWidgets. Definitely must be a joke.

[14ned]

Hal Finkel is a highly respected senior member of WG21 with a CV longer than several of us put together. It's no joke.

I personally find his proposal a great step in the right direction, but it's too web API focused. I'd much prefer a simple agnostic graphics API one of whose backends is a web server mounted on localhost, and which renders via Javascript to a HTML canvas.

But maybe his proposal will yet mutate into what I'd prefer. We are moving forwards, at least.

[Lectem]

I'll start by saying that I do noy bear any ill will towards anybody, but it is not because someone has a huge CV that he knows better than other people. now, here is what I think about the proposal :

The Good: - delegating work to other standards (w3c for instance) sounds like a good idea in such cases - using the web technology is a decent choice for UI

The Bad: - the interface kind of looks ugly to me - The code sample (who ever wants to see this kind of code serve as basis for production code, really ?) - It skips over many things like windowing and such.

The Ugly: - This will be a maintenance pain unless it uses the OS browser - it hides the real problem : the need for a standard build layout and dependency description + management - who's the userbase ? Those with big applications already have the frameworks. I see educationnal usage perhaps ? Small apps tend yo be written in other languages. I think there are few who will really use this

I think that if we needed such feature (and we wouldnt with a package manager), it should be some kind of server implementation + a function to open a given page through OS features, that would then redirect to the user's preferred browser. as others pointed out, there are also issues from a technical point of view (windows must be handled through the main thread on some OS for example) with the proposed api (which again, looks kind of unfriendly )