Getting Started with Kivy, Part 1

We're going to continue our exploration of bootstrapping your ability to do something actually useful with Python code by taking a look at two different application frameworks that can be used to build Python based applications. We'll take a look at Kivy in this post. Then we'll take a look at Qt in a later post.

Why would you care about an application framework?  Well, if your goal is to sit in a terminal editor and run Python code there, maybe you don't care.  But if you are interested in building applications that other non-developer non-technical-wizard people can actually use, then finding and using the right application framework is really going to be essential.

Yes, we could build everything used to construct your house by working directly with atoms. By combining atoms together, we can make the metal and wood parts you will need to construct your house. That seems like a lot of work you might be thinking. I'd rather just go to Home Depot and buy the metal struts and pieces of wood i need to get the job done quicker. Exactly.

Same thing for building a real world software application. Yes, you could build all of the individual widgets you want to use in your application from scratch. I actually did that when we wrote Deck in the early 90's. All of the user interface controls, all of the layout code, it was all build from scratch using atoms. Atoms being C code.

But the early 90's was a long time ago. There are a lot of really full featured application frameworks available today that represent many years of programming and debugging work by large groups of smart people. So rather than building a slider control from scratch, rather than building the widget layout code from scratch, you can just grab one from the framework api and focus on the real nuts and bolts of building your particular application.

This is true for C++, and this is true for Python as well. I mentioned Qt above, you can use it as an application framework for either these 2 languages. Kivy is focused on Python only.


Kivy is an open source project. When you are looking for a good application framework for your amazing new application idea, i think this is a very important criteria to consider. Why would i say that?

Well, let's consider the other option. What about using a proprietary application framework developed by a specific company. I mentioned Deck was written from scratch by working with software atoms. After Deck's success, we needed to get Deck2 out the door. We used a proprietary application framework developed and owned by Metrowerks, which was at the time the best compiler and IDE solution for developing Mac software.

So then a few years later, Apple basically cut Metrowerks and it's associated application framework off at the knees when they made their PowerPC to Intel chip switch for mac computers. The application framework we built our fabulously successful audio software application on top of was now basically dead int he water. No future development, no bug fixes, dead, dead, dead.

Why am i telling you this. Because you will live with the implications of whatever particular application framework you select for the rest of your product's lifespan. So the long term viability of the framework you select is a very important consideration.

Before Apple executed Metrowerks, Metrowerks and associated PowerPlant framework represented probably 90% of all shipping mac software. Afterwards, 0%. And that change happened very quickly.

The same thing happened to me years later with a different software company and a different widely successful software application. Qt in it's glory days was a product of a small and nimble software company called Trolltech. They were great, they were responsive, life was grand.

Then a huge company named Nokia bought them. Young people will say who? Now at the time, Nokia was probably the largest cell phone company in the world. very large company, dominated it's markets. So that was probably a really great thing for Qt development, right?

Nope, the exact opposite. Trolltech was absorbed into the large company that purchased them. And immediately went to shit. Support sucked. Mission drift began almost immediately as Qt desktop development ground to a halt and the focus switched to Qt on phones.

Then Nokia's share of world wide phone market dropped dramatically, and the Qt people were basically all laid off as they tried to cut costs.

Fortunately, Trolltech had positioned Qt from the beginning to be open source as well as commercial software. So Nokia Qt died a painful death, but the Qt framework lived on as an open source project. Some of the Trolltech/Nokia people associated with Qt development eventually ended up forming Digia which then morphed into the Qt Company. So once again, Qt is positioned as an open source framework that also includes a commercial component as well as an open source component.

Take away message. Think very carefully about the long term viability of the application framework you choose to develop your application with.  You are essentially marrying this framework, make sure it's someone you want to spend a lifetime with.

So what about Kivy. It's an open source Python application framework. It's designed for rapid development. It includes features for both desktop and tablet  and other multi-touch products. It's licensing term are very commercial product friendly.


Kivy's GUI interface components are based around the concept of Widgets. Widgets in Kivy are organized in trees. So your application has a root widget, and it has children who probably also have children.

Let's say you want to add a Button to a BoxLayout. Here's how you would program it.

layout = BoxLayout(padding=10)
button = Button(text='My beautiful button')
layout.add_widget(button)

So, the button is a child of the layout.


Kivy dispatches events to your application code. Events could be things like a key press, a mouse or multi-touch move, a timer waking up, etc.

If you are new to the concept of an event loop based application, your dear friend wikipedia can help you out here. It's a very common software design pattern.

In Kivy, you need to attach callback routines to an event. When the event is then dispatched, your callback routines will then be called.

Kivy has a mechanism called Properties that allows you to define and bind events. So let's say you have a custom button widget, and you want it to respond to user touch events. Here's how you could code that.

class CustomBtn(Widget):

     pressed = ListProperty([0, 0])

     def on_touch_down(self, touch):
         if self.collide_point(*touch.pos):
             self.pressed = touch.pos
             return True
         return super(CustomBtn, self).on_touch_down(touch)

     def on_pressed(self, instance, pos):
         print ('pressed at {pos}'.format(pos=pos))

You can then bind to a property of your custom button in the parent. So here, we are binding the on_pressed property of our custom button to the root widget that is it's parent.

class RootWidget(BoxLayout):

     def __init__(self, **kwargs):
         super(RootWidget, self).__init__(**kwargs)
         self.add_widget(Button(text='btn 1'))
         cb = CustomBtn()
         cb.bind(pressed=self.btn_pressed)
         self.add_widget(cb)
         self.add_widget(Button(text='btn 2'))

When you look at this code you might be thinking, what the hell is a kwarg. Kwargs are a dictionary of keyword arguments.  The ** allows us to pass any number of keyword arguments. A keyword argument is basically a dictionary. An example of a keyword argument is fun(foo=2,bar=7) . So it's how we pass information into the RootWidget when it initializes.

The getting started documentation on the Kivy site explains all of this in much better detail than i can do here. I'm really just trying to give you a feel for what Kivy is, and how it works as an application framework.


So, what have we learned. We talked about the importance of application frameworks for modern software development. We discussed a few important considerations you should be aware of when choosing one for your amazing new application. And we took a brief dive into the Kivy application framework for developing Python applications.

We'll talk about an alternative framework called Qt in a later post.

My previous Python post included a brief discussion about application deployment. Pay attention to this! Understanding how your application would or could (or could not) be deployed to potential users and customers is a huge issue you need to fully map out and understand before you dive into building and eventually distributing your custom application.