KDAB Working On Embedding Servo Web Engine Within Qt

[lowflyer]

Creating a QML app that uses a web engine... I'll end up with an app that uses two web engines.

[anda_skoa]

Creating a QML app that uses a web engine... I'll end up with an app that uses two web engines.

How so?
Where would the second web engine come from?

Do you mean creating an app that uses both Qt's Web View and this new one?

[novideo]

How so?
Where would the second web engine come from?

Do you mean creating an app that uses both Qt's Web View and this new one?

I think they mean the engine that parses the QML.

[anda_skoa]

I think they mean the engine that parses the QML.

Since that is not a web engine they must have meant something else

[lowflyer]

How so?
Where would the second web engine come from?

Do you mean creating an app that uses both Qt's Web View and this new one?

QML is the Qt company's new "declarative language". KDE recently makes heavy use of it. It is based on web technologies (CSS, Javasrcipt etc.). So, you create a Qt application that uses QML - *gotcha* - you have an application that has a web engine! Even without using Qt Web View or something.

[anda_skoa]

QML is the Qt company's new "declarative language".

I know, I have been using it for at least a decade.

It is based on web technologies (CSS, Javasrcipt etc.).

Nope

The QML engine creates a tree of instances of QObject based classes.

If those classes don't have any GUI dependencies then the application does not have one either. Let alone a web stack.
If those classes are QWidget derived, then it is just like any other Qt widget application, it just has created the widget tree differently.
If those classes are QQuickItem derived, then the application has a dependency on Qt hardware accelerated render infrastructure.

So, you create a Qt application that uses QML - *gotcha* - you have an application that has a web engine! Even without using Qt Web View or something.

Nope.
Only if the QML code refers to a type that uses a web engine, e.g. the Qt Web View.

[cj.wijtmans]

The QML engine creates a tree of instances of QObject based classes.

That is basically how HTML and DOM works too. so he was kind of correct even if inaccurate. Geuss what, you can have a web engine without a front end too. That is how you crawl the internet.

[skierpage]

QML is the Qt company's new "declarative language". KDE recently makes heavy use of it. It is based on web technologies (CSS, Javasrcipt etc.). So, you create a Qt application that uses QML - *gotcha* - you have an application that has a web engine! Even without using Qt Web View or something.

Sort of. There are similar UI toolkits like Dioxus in Rust that AIUI build a DOM tree of HTML-like elements and style them with CSS without necessarily running in a browser. There's a project for Dioxus to use the Stylo engine from Servo to parse CSS and use wgpu that came out of Mozilla to render the nodes. Embed an HTML view, compile your app to WASM and we're in Inception/Xzibit "Yo Dawg, I herd you like web, so I put a web in your UI so you can HTML+CSS while you HTML+CSS."

Happy 35rh birthday, WWW! Sir Timbl's ideas continue to influence the rest of software development.

[lowflyer]

I know, I have been using it for at least a decade.

... my heartfelt condolences.

Nope

So, you are saying the following is not a mixture of Javascript and CSS ...

import QtQuick

Rectangle {
    id: page
    width: 320; height: 480
    color: "lightgray"

   Text {
      id: helloText
      text: "Hello world!"
      y: 30
      anchors.horizontalCenter: page.horizontalCenter
      font.pointSize: 24; font.bold: true
   }
}​

... and that it's not necessary to start the engine before it does anything?

QQmlApplicationEngine engine("main.qml");​

Hint: if there is CSS and Javascript text somewhere in the application code, there must be a component somewhere that can read and interpret it.

The QML engine creates a tree of instances of QObject based classes.

A tree of object instances is exactly what every web engine does.

If those classes don't have any GUI dependencies then the application does not have one either. Let alone a web stack.

If a web engine misses a web stack it still remains a "web engine". The QQmlApplicationEngine is still running - even without a GUI.

If those classes are QWidget derived, then it is just like any other Qt widget application, it just has created the widget tree differently.

Nope.
It's a web engine that holds a widget tree. It's not the same like a "normal" QWidget based application. A performance comparision will reveal it.

If those classes are QQuickItem derived, then the application has a dependency on Qt hardware accelerated render infrastructure.

Nope.
Force Direct3D's software rasterizer (WARP) by setting the environment variable QSG_RHI_PREFER_SOFTWARE_RENDERER to 1

Nope.
Only if the QML code refers to a type that uses a web engine, e.g. the Qt Web View.

... then you'll get another web engine on top of the ones you already have.

[anda_skoa]

... my heartfelt condolences.

None necessary, it is very nice to work with.
Even QtQuick is quite usable these days.

So, you are saying the following is not a mixture of Javascript and CSS ...

import QtQuick

Rectangle {
id: page
width: 320; height: 480
color: "lightgray"

Text {
id: helloText
text: "Hello world!"
y: 30
anchors.horizontalCenter: page.horizontalCenter
font.pointSize: 24; font.bold: true
}
}​

Yes, correct.
There is not a single line of CSS or JavaScript in there.

The build chain can even generate C++ code for pretty much everything in that file if the project setup has been configured correctly.

Hint: if there is CSS and Javascript text somewhere in the application code, there must be a component somewhere that can read and interpret it.

Yes, obviously.
Luckily none of that appears in the code above.
While JavaScript might appear in QML, you will never see any CSS.

A tree of object instances is exactly what every web engine does.

The QML engine creates a tree of QObject based classes not HTML elements.

Not only are these different types, the QML type system is essentially fully defined by the application developer.
Any QObject derived class can be registered with the QML type system as long as it is default constructible.

in most cases the developer will make use of modules, predefined sets of types, e.g. QtQuick.

All UI frameworks work on trees of objects, very few use a web engine for that.

It's a web engine that holds a widget tree. It's not the same like a "normal" QWidget based application.

Of course it is. The result of loading the QML file is a QWidget tree if the registered types a QWidget.
For example when using DeclarativeWidgets as the QML type module.

A performance comparision will reveal it.

You mean loading time?

Because at runtime all painting, layouting and event handling will be done by the respective widgets and thus with the same code paths as an application with a hardcoded widget tree.

Nope.
Force Direct3D's software rasterizer (WARP) by setting the environment variable QSG_RHI_PREFER_SOFTWARE_RENDERER to 1

Wow, so you are saying if you force a software renderer then it is no longer hardware acceleretated?
Who would have thought!?

Obviously I was referring to the default configuration.

... then you'll get another web engine on top of the ones you already have.

You will only have the one you've just instantiated.