8 ms·

Electron as GUI of Python Applications

63 points by jp_sc 11y ago

rch 11y ago
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.
msabourin 11y ago
"The only mature and real-world solution is QT" That seems a little disingenuous. What about GTK with pygobject?
- albertzeyer 11y ago
  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 11y ago
    Does Electron run on mobile platforms?
- rhodysurf 11y ago
  GTK is crap on OSX and Windows compared to Qt. its just doesn't fit in as natively as Qt.
- IshKebab 11y ago
  Yeah GTK is pretty terrible on any platform other than Linux. And it's not great there either.
giancarlostoro 11y ago
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.
moonchrome 11y ago
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 11y ago
  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-HTML https://www.tbray.org/ongoing/When/201x/2015/06/05/End-of-HT... (HN discussion: https://news.ycombinator.com/item?id=9672520 https://news.ycombinator.com/item?id=9672520)
  - mixmastamyk 11y ago
    It's a (poorly designed) API, usually written in js, that allows you to read and modify a markup document on the fly: https://en.wikipedia.org/wiki/Document_Object_Model
  - dcre 11y ago
    The other commenter is right, but I'll break it down a bit further. There are actually two related ways of using the word DOM. Usage 1: the set of rules (API) for manipulating a document HTML is a way of writing down a webpage so you can send it over the internet to the browser. The browser then reads in the HTML and uses it to build the "actual" webpage in memory. Different browsers may represent the webpage in different ways internally, but they try to provide a common set of rules and methods for interacting with and manipulating it. That common set of rules and methods is the Document Object Model. These rules include things like the way forms work or the kinds of properties input boxes are allowed to have (such as placeholder text, a current state, etc.). Well, a "common set of rules and methods for interacting with something" is exactly what an API is. This is why the other commenter can correctly say that the DOM is "an API ... that allows you to read and modify a markup document." Usage 2: the document itself HOWEVER, while "DOM" technically refers to the API for manipulating a thing (the markup document), people most often use the word to refer to the document itself. This makes sense, since you never interact with the browser's internal representation of the document, you only interact with its public interface, and so gradually you come to think of the interface as the thing itself. This double usage is why it's confusing to put the DOM on the same level as HTML, CSS, and JS. Technically it may be true that it's a separate and parallel technology, but since the document itself is built by reading in HTML and CSS, and then can be modified through JS, it's probably easier to think of it as one level above them (or below or whatever). Edit: to reply to your questions more specifically: - SAX/DOM: ignore this, it's arcane and not relevant - schema for data exchange: no, that's exactly what HTML is — a format for sending data between computers. the DOM has more to do with how they represent that data to themselves after they receive it - web tech vs. native UI: if you're trying to understand the DOM, don't worry about the UI of the browser, just worry about the web page itself
jszymborski 11y ago
Maybe Brython would have been a better alternative than setting up a whole server... http://www.brython.info/ http://www.brython.info/
task_queue 11y ago
PyOtherSide exists and is maintained https://github.com/thp/pyotherside https://github.com/thp/pyotherside
seletz 11y ago
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 11y ago
  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.
DevPad 11y ago
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 ...
kyrre 11y ago
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
carapace 11y ago
Man, I like Tkinter. (And you can make it not-ugly with just a little bit of work these days.) ;-)
- bsharitt 11y ago
  I don't know about other platforms, but on most modern systems, doesn't it just take on the current GTK+ theme? python/tk apps seem find to me most of the time.
- rpcope1 11y ago
  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.
Marazan 11y ago
I often put together Flex interfaces that Xml-rpc called pyhon as my 'solution' to Python GUI programming.
jarcane 11y ago
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 11y ago
  but battle ships are tug boat problems: http://www.defense.gov/dodcmsshare/newsphoto/2000-12/001207-N-2781V-501.jpg http://www.defense.gov/dodcmsshare/newsphoto/2000-12/001207-...
IshKebab 11y ago
When will the node.js madness end?
pikzen 11y ago
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 11y ago
  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 11y ago
    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.
    - deleted 11y ago
      [deleted]
    - rpcope1 11y ago
      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.
risingganymede 11y ago
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.
mkramlich 11y ago
articles like this give me mixed feelings. Python is one of the best languages to use. GUIs are, in general, one of the worst UI types, clearly inferior to CLIs and web UIs -- in the general case.
Fudgel 11y ago
I wonder if Phantompy could be extended to work with Electron as well. https://github.com/niwinz/phantompy https://github.com/niwinz/phantompy

63 points by jp_sc 11y ago

rch 11y ago

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.

msabourin 11y ago

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

albertzeyer 11y ago
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 11y ago
  Does Electron run on mobile platforms?
rhodysurf 11y ago
GTK is crap on OSX and Windows compared to Qt. its just doesn't fit in as natively as Qt.
IshKebab 11y ago
Yeah GTK is pretty terrible on any platform other than Linux. And it's not great there either.

giancarlostoro 11y ago

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.

moonchrome 11y ago

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 11y ago
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-HTML https://www.tbray.org/ongoing/When/201x/2015/06/05/End-of-HT... (HN discussion: https://news.ycombinator.com/item?id=9672520 https://news.ycombinator.com/item?id=9672520)
- mixmastamyk 11y ago
  It's a (poorly designed) API, usually written in js, that allows you to read and modify a markup document on the fly: https://en.wikipedia.org/wiki/Document_Object_Model
- dcre 11y ago
  The other commenter is right, but I'll break it down a bit further. There are actually two related ways of using the word DOM. Usage 1: the set of rules (API) for manipulating a document HTML is a way of writing down a webpage so you can send it over the internet to the browser. The browser then reads in the HTML and uses it to build the "actual" webpage in memory. Different browsers may represent the webpage in different ways internally, but they try to provide a common set of rules and methods for interacting with and manipulating it. That common set of rules and methods is the Document Object Model. These rules include things like the way forms work or the kinds of properties input boxes are allowed to have (such as placeholder text, a current state, etc.). Well, a "common set of rules and methods for interacting with something" is exactly what an API is. This is why the other commenter can correctly say that the DOM is "an API ... that allows you to read and modify a markup document." Usage 2: the document itself HOWEVER, while "DOM" technically refers to the API for manipulating a thing (the markup document), people most often use the word to refer to the document itself. This makes sense, since you never interact with the browser's internal representation of the document, you only interact with its public interface, and so gradually you come to think of the interface as the thing itself. This double usage is why it's confusing to put the DOM on the same level as HTML, CSS, and JS. Technically it may be true that it's a separate and parallel technology, but since the document itself is built by reading in HTML and CSS, and then can be modified through JS, it's probably easier to think of it as one level above them (or below or whatever). Edit: to reply to your questions more specifically: - SAX/DOM: ignore this, it's arcane and not relevant - schema for data exchange: no, that's exactly what HTML is — a format for sending data between computers. the DOM has more to do with how they represent that data to themselves after they receive it - web tech vs. native UI: if you're trying to understand the DOM, don't worry about the UI of the browser, just worry about the web page itself

jszymborski 11y ago

Maybe Brython would have been a better alternative than setting up a whole server... http://www.brython.info/ http://www.brython.info/

task_queue 11y ago

PyOtherSide exists and is maintained https://github.com/thp/pyotherside https://github.com/thp/pyotherside

seletz 11y ago

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 11y ago
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.

DevPad 11y ago

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

kyrre 11y ago

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

carapace 11y ago

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

bsharitt 11y ago
I don't know about other platforms, but on most modern systems, doesn't it just take on the current GTK+ theme? python/tk apps seem find to me most of the time.
rpcope1 11y ago
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.

Marazan 11y ago

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

jarcane 11y ago

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 11y ago
but battle ships are tug boat problems: http://www.defense.gov/dodcmsshare/newsphoto/2000-12/001207-N-2781V-501.jpg http://www.defense.gov/dodcmsshare/newsphoto/2000-12/001207-...

IshKebab 11y ago

When will the node.js madness end?

pikzen 11y ago

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 11y ago
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 11y ago
  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.
  - deleted 11y ago
    [deleted]
  - rpcope1 11y ago
    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.

risingganymede 11y ago

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.

mkramlich 11y ago

articles like this give me mixed feelings. Python is one of the best languages to use. GUIs are, in general, one of the worst UI types, clearly inferior to CLIs and web UIs -- in the general case.

Fudgel 11y ago

I wonder if Phantompy could be extended to work with Electron as well. https://github.com/niwinz/phantompy https://github.com/niwinz/phantompy