Cristian Medina
Could deep learning model a #python to power your #dockerized #gaming AI while you cruise within the confines of subspace? That's what we're here to find out!
1 hr ago
The project is a great start as-is.
Darth MooMoo
1
If you look through the project issues, there’s a number of them marked as tasks. They have short descriptions as to what’s needed. They are mostly simple things that just need to get done.
Most of the work is to provide more ui widgets that match up with what Bootstrap has available, and maybe some reorganizing of the modules to make things more pluggable.
The backend that manages the sockets should be fine for now, but there may be some changes to the protocol in order to support other things beyond Bootstrap.
I also need docs and more testing, so any help is appreciated.
Next Story ― A Python ate my GUI ― Part 3: Implementation
Currently Reading - A Python ate my GUI ― Part 3: Implementation
Cristian Medina
Could deep learning model a #python to power your #dockerized #gaming AI while you cruise within the confines of subspace? That's what we're here to find out!
Aug 15 5 min read
Photo credit: Sebastian Niedlich (Grabthar) via Foter.com A Python ate my GUI ― Part 3: Implementation Time to Bootstrap your D3, pick up that Python and hop on theAutobahn
If you aren’t aware of my earlier posts, check outPart 1 andPart 2 of this series so that you get some context for this ongoing exercise.
Since I started thinking about and working on these posts, I’ve also been developing the ideas on GitHub as a side project I called sofi.
tryexceptpass/sofi
Contribute to sofi development by creating an account on GitHub. github.com
Sofi is a Python 3 package that serves as the starter implementation of the design discussed in Part 2: a system that will generate the necessary HTMLandjavascript code typically needed to produce a single-page application and serve it up through WebSockets (not an HTTP server).
The webpage functions as a dumb user interface layer on top of your python code by exposing a simple command and event system that allows for communications back and forth with the python logic. The UI itself is generated using Bootstrap components, and enabled by D3.js for processing events and DOM changes, as well as for future integration with charting mechanisms.
Why did I dothis?I specifically wanted to understand and do more things with WebSockets. I like the technology and believe that it can enhance ― possibly even replace ― some of the RESTful interfaces that I build or maintain on a regular basis.
At the same time, I’ve been looking for an excuse to use asyncio and some of the more recent python 3 features, and found that the autobahn websocket module is built on top of it.
On another note, as discussed in a previous post, I’m also lazy! and tired of re-implementing web interfaces in languages that I would prefer not to use.
However, most importantly, I wanted to dive a little deeper into the implications of writing your own command / event protocol to enable GUI interactions, as I intend to use something similar in a different kind of project (which is a subject for another time).
How does itwork?The basic concept is fairly simple: statically serve an html file that references a minimal javascript library setup so that when the page loads, it automatically connects to the websocket server, updates the page DOM with whatever is needed and registers any relevant event subscriptions.
These DOM updates or event subscriptions are received as commands through the websocket, with enough information to specify the element selectors that are then passed onto D3 to perform the changes.
Whenever an event is triggered, it gets relayed back through the same socket. This includes page events (like click) as well as any control events necessary to establish the workflow (like init, load or close).
This socket protocol gives us the flexibility to host the static html anywhere we want and run the websockets themselves in some other place, while supporting communication with any operating system and any modern web browser (including Android and iOS).
To ease development of the user interface, common Bootstrap widgets are wrapped into python classes that allow for easy compositing through basic built-ins like __str__. Every widget object provides the basic set of methods necessary for generating the html that describes it, but also exposes the identifier, class, style and attributes fields to allow for further customization.
While these widgets give you a mechanism for rapidly prototyping an interface, they are not necessary and can be replaced with a simple string representing any HTML that you’d like to send up to the web page.
In order to allow for threaded processing of incoming events, any callback functions are expected as asyncio coroutines, otherwise the code would be unresponsive as long events are being processed.
Currently, the application as a whole is executed from a shell, where python automatically opens the default browser and points it to the static html starter file, with no need to run a webserver. However, it’s totally possible to start it and separately navigate to the html file from an already running browser.
Execution ends when the browser tab is closed and an event is sent back through the websocket to be handled appropriately, though I still need to improve that code to gracefully manage disconnects and coroutines.
What can youmake?Anything, of course! Kidding aside though, the system is pretty open to tie into any python program. At the moment you’ll be limited by the number of widgets available to represent your interface, and things are more verbose than I’d like, but all of that will eventually settle down.
The sample.py file in the main directory is a bit of a widget showcase that dynamically updates over time. It also has a click handler configured for the Primary button which will print out a message wi