Packaging and distributing your app sounds simple in principle. It’s just software. But in practice, it’s quite challenging.
I’ve been working on a Python module called Sofi that generates user interfaces. It can deliver a desktop feel while using standard single-page web technologies. For flexibility, I designed it to work through two methods of distribution: in-browser and executable.
Running in the browser, it functions much like a normal webpage. You can load it by opening a file, or launch it from your shell. I also built an executable that runs as a packaged app, independent and without external requirements.
Over time, as I hacked at code in Atom — my editor of choice these days — I remembered that Atom is actually a browser. It uses Node.js as a back end, and the Electron framework for its user interface.This inspired me to start poking at Electron’s internals, hoping to find examples and best practices on how they solved desktop packaging.Continue reading
Zero-to-Debugging in 15 mins
You don’t realize the value of a debugger until you’re stuck working on a hard-to-visualize problem. But once you fire up a development environment with decent debugging capabilities, you’ll never look back.
Want to know where you’re at in code execution? What’s taking so long? Just pause it and check.
Wonder what value is assigned to that variable? Mouse over it.
Want to skip a bunch of code and continue running from a different section? Go for it.
print(variable_name) is just not enough to give you an idea of what’s going on with your project. This is when a good debugger can help you figuring things out.
Time to Bootstrap your D3, pick up that Python and hop on the Autobahn
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.
In the first part of this series, we discussed a few existing modules that give us tools for building interfaces. I promised to come back with some ideas on how I would attempt to solve the situation, and this post is intended to cover aspects of my initial design.
However, first I need to discuss one more point on existing modules. In case you’re not aware, PyCon 2016 happened a few wks ago in Portland, and amongst the many wonderful talks, keynotes and open spaces, there was one in particular that is relevant to the topic of our discussion here: Russell Keith Magee’s talk on BeeWare and the work he’s done to solve the same problem. I highly recommend you take a look and help out with his projects if you can. It’s definitely a bold and brave solution that’s highly complex, but he already has it at a usable state and deserves massive props for going down that path. The Podcast.__init__ guys also have a great interview with him going over the details.Continue reading
Thoughts on the future of Python and graphical interfaces
Staring at my coworkers, already knowing the inevitability of the situation, my eyes roll as the argument starts anew:
“I told you I can write that code twice as fast, in half as many lines and they’ll be cleaner and more readable than yours will ever be! Python is awesome!” — said the one guy.
“Whatever you say, you’ll never be able to make a UI that’s half as good as this. It won’t look pretty and no one will want to use it!” — replied the other — “Probably can’t even make it run on Windows” — he mumbled to himself while walking away.
Some years ago this was a regular exchange between coworkers, and while they were mostly messing around, there was still an element of truth to it. Regardless of its capabilities, Python was mostly known as a “scripting” language — not really for graphical interfaces — and the world was still looking for a native OS feel in their GUI applications, which was not really accessible from Python without a lot of work.Continue reading