Electron as GUI of Python Applications(fyears.org)
fyears.org
Electron as GUI of Python Applications
https://www.fyears.org/2015/06/electron-as-gui-of-python-apps.html
17 comments
but battle ships are tug boat problems: http://www.defense.gov/dodcmsshare/newsphoto/2000-12/001207-...
Man, I like Tkinter. (And you can make it not-ugly with just a little bit of work these days.) ;-)
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.
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.
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.
PyOtherSide exists and is maintained
https://github.com/thp/pyotherside
https://github.com/thp/pyotherside
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.
Maybe Brython would have been a better alternative than setting up a whole server...
http://www.brython.info/
http://www.brython.info/
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.
So compile Python as a Chrome plugin and use Pepper to communicate with DOM.
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... (HN discussion: https://news.ycombinator.com/item?id=9672520)
- 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... (HN discussion: https://news.ycombinator.com/item?id=9672520)
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
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
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_ModelThe 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)
To be precise the DOM is 2 apis, one for OO languages(Elements with a type hierarchy) ,the other for C like languages (nodes)
This is a pretty complicated explanation to give someone who called themselves a beginner.
An alternative to wrapping things in node might be to
use the chrome embedded bindings for python:
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.
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.
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.
"The only mature and real-world solution is QT"
That seems a little disingenuous. What about GTK with pygobject?
Qt is much more cross-platform than GTK. GTK doesn't work that well on MacOSX and I'm not sure about mobile platforms.
Does Electron run on mobile platforms?
GTK is crap on OSX and Windows compared to Qt. its just doesn't fit in as natively as Qt.
Yeah GTK is pretty terrible on any platform other than Linux. And it's not great there either.
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.
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.
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
[1] https://github.com/extrabacon/python-shell
When will the node.js madness end?
I wonder if Phantompy could be extended to work with Electron as well.
https://github.com/niwinz/phantompy
I often put together Flex interfaces that Xml-rpc called pyhon as my 'solution' to Python GUI programming.
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.
If that doesn't sound completely batshit insane to you, you have a problem. Or you're a Node.js developer.
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.
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.
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.
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]
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.
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 Perhaps not completely an insane idea to some :)
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 ...
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 ...
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