
Electron as GUI of Python Applications - jp_sc
https://www.fyears.org/2015/06/electron-as-gui-of-python-apps.html
======
jarcane
Man, talk about throwing a battleship at a tugboat's problem.

This is why we get hot new editors that take a gig of RAM to do what a 40 year
old editor can do with a dozen megs.

If I were to touch a Python GUI app again, I'd probably just use Kivy.
[http://kivy.org/#home](http://kivy.org/#home)

~~~
robertely
but battle ships _are_ tug boat problems:
[http://www.defense.gov/dodcmsshare/newsphoto/2000-12/001207-...](http://www.defense.gov/dodcmsshare/newsphoto/2000-12/001207-N-2781V-501.jpg)

------
carapace
Man, I _like_ Tkinter. (And you can make it not-ugly with just a little bit of
work these days.) ;-)

~~~
rpcope1
I definitely second this. You know Tk/Tcl isn't super flashy, but it certainly
is snappy and gets work done well. Especially with add-ons like ttk, it's
possible to build very sophisticated GUIs and sizable applications. It may not
look like a shiny hipster application, but you can still build _quick_
applications with good UX that run on systems that are not overflowing with
resources.

Really I'm still amazed people write Tkinter off as quickly as they do, and
like to run it down, as it's often more performant, more available (it's
pretty much everywhere), and more Pythonic than other choices, and works great
when you're not trying to win a hipster design contest.

------
task_queue
PyOtherSide exists and is maintained

[https://github.com/thp/pyotherside](https://github.com/thp/pyotherside)

------
risingganymede
As the post claims, PySide is a dead project. But PyOtherSide isn't. And,
being a Qt frontend, it works really well with most platforms. It would be
interesting to see how Electron stacks up against this.

------
jszymborski
Maybe Brython would have been a better alternative than setting up a whole
server...

[http://www.brython.info/](http://www.brython.info/)

------
moonchrome
This seems like a backwards approach - if you want to write Python for
Electron you should probably wrap Pepper API in Python, AFAIK Electron
supports Pepper plugins because it supports Flash.

So compile Python as a Chrome plugin and use Pepper to communicate with DOM.

~~~
fizixer
noob/off-topic: I've seen people use the word DOM multiple times and I don't
have an idea of what they mean.

\- I know from past that DOM vs SAX were two ways to read/write XML. Not sure
if that is related.

\- Recently I came across a reading that said a website is four things (or a
web is made of four key technologies, or something like that): HTML, CSS, JS,
and DOM. I know the first three are frontend but what does it mean to put DOM
at the same level as the others?

\- Does DOM in this context have anything to do with, so to speak, schema or
format of interchange between webservices?

\- It might make things more confusing to consider that browsers like Firefox
are built using web-technologies, instead of native UI frameworks/libraries.

Care to comment anyone?

EDIT 1: found the HTML/CSS/JS/DOM reference: "HTML is Done"
[https://www.tbray.org/ongoing/When/201x/2015/06/05/End-of-
HT...](https://www.tbray.org/ongoing/When/201x/2015/06/05/End-of-HTML) (HN
discussion:
[https://news.ycombinator.com/item?id=9672520](https://news.ycombinator.com/item?id=9672520))

~~~
aikah
The DOM is exactly that, an API to interact with nodes of a XML like document.
XML and HTML are obviously different but the underlying structure isn't. You
have different levels of DOM, usually only level one is implemented in most
XML libraries. SAX is evented which means you don't have to read the whole XML
document to be able to interact with it.

To be precise the DOM is 2 apis, one for OO languages(Elements with a type
hierarchy) ,the other for C like languages (nodes)

~~~
dcre
This is a pretty complicated explanation to give someone who called themselves
a beginner.

------
seletz
An alternative to wrapping things in node might be to use the chrome embedded
bindings for python:

[https://code.google.com/p/cefpython/](https://code.google.com/p/cefpython/)

This has the advantage to not have to start a web server -- just make python
objects visible directly in JS.

~~~
seletz
Well, on a second look: cefpython currently requires the user to pass in a UI
window. That's apparently quite easy to do on windows using pywin32, but
nevertheless -- It's maybe quite hefty -- one might as well use QT, then.

------
msabourin
"The only mature and real-world solution is QT" That seems a little
disingenuous. What about GTK with pygobject?

~~~
albertzeyer
Qt is much more cross-platform than GTK. GTK doesn't work that well on MacOSX
and I'm not sure about mobile platforms.

~~~
Touche
Does Electron run on mobile platforms?

------
rch
It seems like building around uwsgi, for example, might be easier than
interfacing over zmq; and the approach of of using electron to interface with
a standalone Python web server is difficult to distinguish from simply opening
a browser.

------
giancarlostoro
This is what I was hoping Atom would be more like when they released the text-
editor. This takes some of the load from the DOM itself. However, I wouldn't
limit it just to Python, but anything that can run a web server. There's text
editors written in Go who could benefit from having Atom Shell on top of them
as one example. There's plenty of use cases out there.

------
kyrre
I experimented with this by using python-shell [1], but it in the end it just
felt too hacky, and it decided it was best to embrace js instead.

[1] [https://github.com/extrabacon/python-
shell](https://github.com/extrabacon/python-shell)

------
IshKebab
When will the node.js madness end?

------
Fudgel
I wonder if Phantompy could be extended to work with Electron as well.
[https://github.com/niwinz/phantompy](https://github.com/niwinz/phantompy)

------
Marazan
I often put together Flex interfaces that Xml-rpc called pyhon as my
'solution' to Python GUI programming.

------
pikzen
So you're running a Chrome window on top of V8/Node.js, and at the same time
starting up a WSGI server just to serve your Python application in that
browser window.

If that doesn't sound completely batshit insane to you, you have a problem. Or
you're a Node.js developer.

~~~
rpcope1
Yeah, I agree. I think this throws a lot of the major advantages of GUI
programming in Python out the window, starting with the back end really needs
to be stateless with electron, where as with Tkinter/Qt/WxWidgets the
interface is much simpler, and the application can be stateful (which makes
life so much easier most of the time).

It might be time to give Tk/Tcl a facelift, refresh PySide, or build another
good GUI toolkit, but using a browser seems like a really poor solution.

~~~
elcritch
I have an MS in CS and am now working in a science lab. Most scientists (much
less grad students!) are not professional programmers. As such I'm working on
moving my GUI code from PyQT to html5 based UI's because it simplifies what
non-professionals need to learn. By capitalizing on advances in html they can
learn some html/js and use it in reports, for UI's, and sharing data, instead
of learning Python and QT, while trying to figure out formatting documents in
latex or word, and creating their code Matlab or C or Python and then
outpatient plots.

Electron and html5 have a ways to go, but the synergy that can be gained will
be well worth the effort, IMHO. Using a browser for quickly sharing research
and making basic UI's to interact with computations actually fits rather
nicely into the vision Tim Berners-Lee had when created html for browsing
information at CERN.

As far as statefullness, GUIs really would be better off moving away from
implicit state to ReactJS functional style approaches.

~~~
rpcope1
I'm not sure I agree much at all, but I take issue with your last statement.
Why on earth would I ever want to move to anything remotely like ReactJS when
I'm building a single user application? You must carry state information, and
in that case _explicitly_ having state is both often conceptually simpler,
easier to modify/debug, and require far less code than using something
literally insane like using js + DOM.

~~~
elcritch
It's good to have varying opinions. I'm unsure what you're considering
positive about state. Synchronizing state among multiple widgets in QT for
example is a pain and quickly becomes become fragile. To help deal with this,
QT 5 introduced a JavaScript based reactive programming framework before
ReactJS was popular. See
[https://en.m.wikipedia.org/wiki/QML#Property_bindings](https://en.m.wikipedia.org/wiki/QML#Property_bindings)
Perhaps not completely an insane idea to some :)

------
DevPad
For me it's not the best approach with server/html.

By design too many points of failure for desktop app, too many wrappers. The
gist is clear: it works, it's easier and faster to do, but ...

