The HTML-CSS-JS pages rendered by QtWebkit differ only slightly from those rendered by Firefox/Chrome. So the GUIs will be as good as the CSS/JS behind it.
When i saw the example code, the first thing that is see is the use of globals:
from main import app
app.html
This is a reason i would never use a library like this. Flask has the same issue with globals. I think is a common problem that python developers have, because its so easy to create global singleton modules with state.
> htmlPy is a wrapper around PySide's QtWebKit library...
Based on my experience using Qt (via PyQt) this is kind of puzzling, and the very limited doc doesn't do much to unpuzzle me.
QtWebKit is basically a rendering engine wrapped as a Qt widget[0]. Where an entire app is based on a Qt main window, it can display HTML-encoded or Javascript-encoded content in a QWebView widget.
QtWebKit also offers the "WebKit bridge"[1] which "extends WebKit's JavaScript environment to access native objects represented as QObjects" and this permits creation of a "thin client" in which "the entire UI is driven by HTML, JavaScript and CSS." This sounds like what HtmlPy may be doing: using QtWebKit to make a "thin client", basically a minimal web browser window, in which the client code can use Javascript and HTML to display stuff.
If that's the case, a couple of points follow.
First, in that design, the only UI elements that will have the native OS's look and feel will be the outermost bits of the window. All widgets inside will have the look'n'feel designed by the app using CSS. Which may or may not be an issue.
More important, QtWebKit is deprecated and support for it ended with Qt5.4 [2]. Maintenance on QtWebKit has been slow to nonexistent since 2014 and my personal experience with it was that it had many bugs and frequently crashed my app displaying very ordinary web pages.
The replacement for QtWebKit is QtWebEngine [3][4] which is based on the Chromium web engine. Although QtWebEngine has several annoying omissions of QtWebKit features, it is in my experience much more reliable, and has on-going support.
However, I do not think there is as yet any equivalent in QtWebEngine to the "WebKit Bridge" mentioned above. The WebKit-to-WebEngine porting page[5] doesn't mention it, but does mention restrictions on Javascript execution compared to WebKit. So if indeed HtmlPy is depending on QtWebKit's "bridge", it is on a dead-end track for Qt support.
Where an entire app is based on a Qt main window, it can display HTML-encoded or Javascript-encoded content in a QWebView widget.
So it's another one of these "web everything" things... which in my experience seems more like "how to make your app consume 100x more memory and disk space that it should". What is with this aversion to native UIs that I've been seeing more of recently (and the tendency to invent controls that don't work anywhere near as well as the native ones)?
In regards to that, this also tends to encourage some very convoluted schemes like creating a local web server to serve the page for the GUI:
People are attracted to these solutions because they can build cross platform GUIs. Native UIs are great, no one is averse to them, people just don't want to write and maintain several different versions of the same thing in different languages.
As @fernly said, Qt is a cross-platform GUI library and htmlPy isn't bringing anything extra in that field.
htmlPy is meant for easy GUI development and integration with popular frameworks like Django for standalone app development. It adds to the memory usage of the application due to the use of QtWebkit.
If you are making a not-very-complex app and don't want to go to lot of trouble for making GUIs for standalone version, htmlPy is a great solution. But if your app is conservative about resources, doing lot of memory optimization or needs features which can't be done using HTML, probably best if you use native UI.
The irony is, Qt _IS_ a cross-platform GUI, where you build your UI once and it looks like Windows on Windows, Mac OS on Mac OS, and the look of whatever window manager on Linux.
The irony is, Qt _IS_ a cross-platform GUI, where you build your UI once and it looks like Windows on Windows, Mac OS on Mac OS, and the look of whatever window manager on Linux.
Looks like, yes. Behaves like, not really (at least on Windows.) The few Qt apps I have certainly do not feel as responsive as the native ones, despite (mostly) looking that way, so it is rather awkward. They're noticeably laggier even in simple operations like displaying a menu, or responding to window resizing/moving.
This library is just a wrapper on a rendering engine. It doesn't replace standard HTML/CSS. You can use it to create UIs for standalone applications using HTML/CSS, Bootstrap, jQuery and any other front-end libraries.
