
Show HN: HtmlPy – HTML5-CSS3-JavaScript Based GUI Library in Python - manamol296
http://amol-mandhane.github.io/htmlPy/
======
guiscreenshots
It looks like a lot of work and thought went into this library. I'd love to
give it a shot except that I have no idea what the output might look like.

~~~
manamol296
Output is pretty much same as HTML rendered by chrome. htmlPy just renders it
in a standalone application instead of browser window.

------
markdown
I'd like to dig into this, but for all I know, it could produce horrible GUIs.

Why isn't there even a single screenshot of a GUI made with this library?

~~~
manamol296
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.

I'll upload a few screenshots.

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

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

[0] [http://doc.qt.io/qt-5/qtwebkit-
index.html](http://doc.qt.io/qt-5/qtwebkit-index.html)

[1] [http://doc.qt.io/qt-5/qtwebkit-
bridge.html](http://doc.qt.io/qt-5/qtwebkit-bridge.html)

[2] [http://www.qt.io/qt5-4/](http://www.qt.io/qt5-4/)

[3] [http://doc.qt.io/qt-5/qtwebengine-
index.html](http://doc.qt.io/qt-5/qtwebengine-index.html)

[4] [http://doc.qt.io/qt-5/qtwebenginewidgets-
index.html](http://doc.qt.io/qt-5/qtwebenginewidgets-index.html)

[5] [http://doc.qt.io/qt-5/qtwebenginewidgets-
qtwebkitportingguid...](http://doc.qt.io/qt-5/qtwebenginewidgets-
qtwebkitportingguide.html)

~~~
userbinator
_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:

[https://news.ycombinator.com/item?id=8640520](https://news.ycombinator.com/item?id=8640520)

~~~
rco8786
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.

~~~
fernly
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.

~~~
userbinator
_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.

------
siquick
Can someone explain why this is useful over standard HTML/CSS or Bootstrap?
Feels like I'm missing the point...

~~~
zokier
It is somewhat comparable to Atoms Electron if you are familiar with that, but
instead of having node.js backend this one has pyside backend.

