maybe focusing the generation perspective on the tech involved can help with moving this forward - as much as I'd like to contribute to a sane linux desktop in general (and LXQt is definetely the most promising one atm), theres no way I go back to write c++ based 'old school' UI-code anymore. I think for writing UIs you really want the flexibility of a declarative approach - haven't kept up with QML lately but v1 wasn't that great, same with gtk.Builder. people are not shipping a bloated copy of chromium in their apps without reason: we got so used to the power these monsters of layout engines offer, that people think its worth it! even though there still is no decent set of UI-widgets/components for the browser .. (something that can compete with QT or GTK with accessibility etc build in)
things are moving fast in the app-centric world right now, and while this has its downsides, it also populizes ideas that really do make things better - declarative layout, the functional (reactive) approach to ui-programming, using a network capable (rest-) interface between front- and backend and sane sandboxing. a desktop environment that offers a runtime for these kind of apps has the potential to bring back some developers to the linux desktop - KDE imho not only shines in regard to the Frameworks and KWin, their efforts in using QML as the basis for the whole desktop could lead to a more hackable experience for a new generation of developers in general.
bottom line: while electron really is an ugly hack atm, this approach to write cross desktop apps offers a developer experience that is superior in many ways and something that QT should really keep on moving forward: high quality ui-components and functional QML based frontend code combined with language agnostic backend code (c++ for resource heavy stuff, python et al for everything else)
The major difference between QML and the UI approaches from Oracle, Apple, Google and Microsoft for their layout engines, is using a JavaScript variant instead of XML, but the spirit is the same.
Comments
maybe focusing the generation perspective on the tech involved can help with moving this forward - as much as I'd like to contribute to a sane linux desktop in general (and LXQt is definetely the most promising one atm), theres no way I go back to write c++ based 'old school' UI-code anymore. I think for writing UIs you really want the flexibility of a declarative approach - haven't kept up with QML lately but v1 wasn't that great, same with gtk.Builder. people are not shipping a bloated copy of chromium in their apps without reason: we got so used to the power these monsters of layout engines offer, that people think its worth it! even though there still is no decent set of UI-widgets/components for the browser .. (something that can compete with QT or GTK with accessibility etc build in)
things are moving fast in the app-centric world right now, and while this has its downsides, it also populizes ideas that really do make things better - declarative layout, the functional (reactive) approach to ui-programming, using a network capable (rest-) interface between front- and backend and sane sandboxing. a desktop environment that offers a runtime for these kind of apps has the potential to bring back some developers to the linux desktop - KDE imho not only shines in regard to the Frameworks and KWin, their efforts in using QML as the basis for the whole desktop could lead to a more hackable experience for a new generation of developers in general.
bottom line: while electron really is an ugly hack atm, this approach to write cross desktop apps offers a developer experience that is superior in many ways and something that QT should really keep on moving forward: high quality ui-components and functional QML based frontend code combined with language agnostic backend code (c++ for resource heavy stuff, python et al for everything else)
The major difference between QML and the UI approaches from Oracle, Apple, Google and Microsoft for their layout engines, is using a JavaScript variant instead of XML, but the spirit is the same.