Quick search

Google Summer of Code - 2014

Introduction

Kivy is a cross-platform, business friendly, GPU Accelerated open source Python library for rapid development of applications that make use of innovative user interfaces, such as multi-touch apps.

We are hoping to participate in Google Summer of Code 2014 under PSF. This page showcases some ideas for gsoc projects and corresponding guidelines for students contributing to the Kivy Framework.

Requirements

It is assumed that the incoming student meets some basic requirements as highlighted here:

  • Intermediate level familiarity with python
  • Comfortable with git and github (Kivy and its sister projects are all managed on github)
  • Comfortable with event driven programming.
  • Has suitable tools/environment for kivy or the sister project you are going to work on. For example to be able to work on pyobjus you would need access to an iOS device, mac with xcode and a developer license, to work on pyjnius you would need an android device, and to work on plyer you would need access to hardware for both platforms.

Additional desired skills may be listed with specific projects.

Familiarize yourself with the contributing guide http://kivy.org/docs/contribute.html We can help you get up to speed, however students demonstrating ability in advance will be given preference.

How to get setup

For Kivy Easiest way is to follow the installation instructions for the development version for your specific platform

http://kivy.org/docs/installation/installation.html#development-version

For the rest it’s usually sufficient to install the relevant project from git and add it to your PYTHONPATH.

eg.. for pyjnius:

git clone http://github.com/kivy/pyjnius
export PYTHONPATH=/path/to/pyjnius:$PYTHONPATH

Project Ideas

The mentors list is only of potential mentors for a particular project and not final.

Enhancements to Kivy

Inspector:

Description:
Redo or improve the inspector module to include the following features:
  • Use Python introspection to enhance current state of inspector.
  • Extend Inspectors debugging capabilities to the whole app.
  • Introduce automatic crash reporting.
  • Possibly launch debugger automatically when Kivy app crashes.
Reference:
Expected Outcome:
A fully functional Inspector module that facilitates debugging at any stage, including crash reports and a debugging console.
  • Mentors: Akshay Arora, Gabriel Pettier
  • Task level: Intermediate

Graphics Pipeline Enhancements:

Description:
We have a lot of ideas around the graphics pipeline:
  • Merging instructions
  • VBOs to reduce GL calls
  • Helpers to create shaders dynamically according to the current vertex format
  • Improving 3D support.
  • Add Bounding-Box calculation / selection on the tree only if requested
  • Unit tests to quantify the amount of improvements achieved.
Reference:
Expected Outcome:
Significant improvement in the graphics pipeline that can be quantfied by tests.
  • Mentors: Jacob Kovac, Mathieu Virbel
  • Task level: Intermediate/Advanced
  • Desired Skills: Familiarity with OpenGL ES and Cython, desire to learn about advanced rendering algorithms and solve difficult puzzles.

Embedded Support:

Description:
Add full support for major embedded platforms like Beagle Board and Raspberry Pi. Kivy already has partial support for RPi. It would be great to have support for other major embedded platforms.
This would involve:
  • Native Keyboard Provider.
  • Window provider for Beagle board using hooks to the driver for hardware acceleration inspiration can be taken from the rpi window provider https://github.com/kivy/kivy/blob/master/kivy/core/window/window_egl_rpi.py.
  • Ensuring at least one of the backends for each of the core providers work on the embedded hardware with acceptable performance. Namely: Text, Window, Audio, Video, Keyboard, Clipboard, and Image Providers
Reference:
Expected Outcome:
Full Working support for the embedded platforms. This would include support for at least one of the backends for each core providers mentioned above to achieve feature parity with other platforms.
  • Mentors: Gabriel Pettier, Mathieu Virbel
  • Requirements: Access to specific embedded hardware.
  • Task level: Intermediate/Advanced
  • Desired Skills: Familiarity with programming on the specific embedded hardware.

Enhancements to Mobile Platforms

Plyer:

Description:

Plyer is a platform-independant api to use features commonly found on various platforms, especially mobile ones, in Python. The idea is to provide a stable API to the user for accessing features of their desktop or mobile device.

The student would work on facades and implementation for Accelerometer, GPS, SMS, Contact etc., including porting facades from SL4A (Scripting Layer for Android) to Plyer for easy integration and compatibility.

Under the hood you’ll use PyJNIus and PyOBJus. This probably would also include improving PyObjus and PyJnius to handle interfaces that they can’t right now.

References:
Expected Outcome:
Platform independent api for accessing most platform specific features.
  • Mentors: Gabriel Pettier, Akshay Arora, Alexander Taylor, Ben Rousch.
  • Requirements: Access to Linux, Windows, OS X, iOS device, Android device.
  • Task level: Intermediate/Advanced.
  • Desired Skills: Familiarity with Pyjnius, PyObjus.

Enhancements to Toolchain

Python-for-iOS:

Description:
An iOS interface for building a app for the app store based on the idea of Python for Android, https://github.com/kivy/python-for-android
Current state:
Kivy iOS achieves this but in a more restricted monolith manner. We’d like to replace it with a more modular tool that is more extensible.
References:
Expected Outcome:
A new, modular and extendable toolchain.
  • Mentors: Thomas Hansen, Mathieu Virbel
  • Requirements: Access to iOS, Android device along with a developer license.
  • Task level: Intermediate/Advanced
  • Desired Skills: Familiarity with xcode, objc. Cross-platform compilation skills are heavily required.

Buildozer:

Description:

Buildozer is a Python tool for creating application packages easily. The goal is to have one “buildozer.spec” file in your app directory, describing your application requirements and settings such as title, icon, included modules etc. Buildozer will use that spec to create a package for Android, iOS, Windows, OS X and/or Linux.

Buildozer currently supports packaging for Android via the python-for-android project, and for iOS via the kivy-ios project. This project would involve extending this support to other package formats and operating systems, e.g. RPM, DEB, DMG, EXE. You will need to write new buildozer target code to support these formats.

This project would also involve optimizations to the final package formats, e.g. introspect the python files, extract all the symbols (global variables / functions / class / class methods), mark all the necessary symbols (whitelist) and generate a stripped version of all the python files without the unnecessary symbols.

References:
Expected Outcome:
Running buildoer deb debug or buildozer deb release should result in a .deb package that can be directly be used to install on the target machine, or the equivalent for other package and binary formats.
  • Mentors: Gabriel Pettier, Akshay Arora, Alexander Taylor, Ben Rousch
  • Requirements: Access to linux, Windows, OS X, iOS, Android.
  • Task level: Intermediate

SDL2 Backends:

Description:

SDL2 backend providers for Kivy, including porting the mobile toolchains to SDL2. Part of the work is already done. What left is mostly

  • Hashing out distribution mechanisms for the lib.
  • Porting mobile backends for ios and android to SDL2. Partial work on this has already been going on.
  • Unit tests for the new sdl2 backends making sure apps work the same on SDL2 as on other backends.
  • Performace testing. Looking at the difference between SDL2 and other providers to ascertain wether sdl2 could be used as the default provider giving it priority
References:
https://github.com/kivy/kivy/tree/sdl2-support
Expected Outcome:
Completing the existing and adding new SDL2 core providers and support for using sdl2 on mobiles.
  • Mentors: Akshay Arora, Jacob Kovac, Mathieu Virbel
  • Requirements: Access to Linux, Windows, OS X, iOS, Android.
  • Task level: Intermediate/Advanced

Anything Else ?

  • Let your imagination run wild, and show what Kivy is capable of!

How to Contact devs

Ask your questions on the Kivy users forums http://kivy.org/#forum

Or send a mail at kivy-users@googlegroups.com

Make sure to Join kivy-dev user group too @ https://groups.google.com/forum/#!forum/kivy-dev

You can also try to contact us on IRC (online chat), To get the irc handles of the devs mentioned above visit http://kivy.org/#aboutus

but make sure to read the IRC rules before connecting. http://webchat.freenode.net/?nick=kvuser_GSOC_.&channels=kivy&uio=d4

How to be a good student

If you want to participate as a student and want to maximize your chances of being accepted, start talking to us today and try fixing some smaller problems to get used to our workflow. If we know you can work well with us, that’d be a big plus.

Here’s a checklist:

  • Make sure to read through the website and at least skim the documentation.
  • Look at the source code.
  • Read our contribution guidelines.
  • Pick an idea that you think is interesting from the ideas list or come up with your own idea.
  • Do some research yourself. GSoC is not about us teaching you something and you getting paid for that. It is about you trying to achieve agreed upon goals by yourself with our support. The main driving force in this should be, obviously, yourself. Many students pop up and ask what they should do. Well, we don’t know because we know neither your interests nor your skills. Show us you’re serious about it and take the initiative.
  • Write a draft proposal about what you want to do. Include what you understand the current state is (very roughly), what you would like to improve, how, etc.
  • Discuss that proposal with us in a timely manner. Get feedback.
  • Be patient! Especially on IRC. We will try to get to you if we’re available. If not, send an email and just wait. Most questions are already answered in the docs or somewhere else and can be found with some research. If your questions don’t reflect that you’ve actually thought through what you’re asking, it might not be well received.