mirror of https://github.com/kivy/kivy.git
299 lines
12 KiB
ReStructuredText
299 lines
12 KiB
ReStructuredText
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:
|
|
- http://kivy.org/docs/api-kivy.modules.html
|
|
- http://kivy.org/docs/api-kivy.modules.inspector.html
|
|
|
|
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:
|
|
- http://kivy.org/docs/api-kivy.graphics.html
|
|
- http://www.khronos.org/opengles/
|
|
Expected Outcome:
|
|
Significant improvement in the graphics pipeline that can be quantified 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:
|
|
- https://github.com/kivy/kivy/blob/master/kivy/core/window/window_egl_rpi.py.
|
|
- http://kivy.org/docs/api-kivy.core.html
|
|
- http://kivy.org/docs/guide/architecture.html#architecture
|
|
- http://kivy.org/docs/guide/architecture.html#providers
|
|
|
|
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-independent 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:
|
|
- https://github.com/kivy/plyer
|
|
- https://github.com/kivy/pyjnius
|
|
- https://github.com/kivy/pyobjus
|
|
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:
|
|
- https://github.com/kivy/python-for-android
|
|
- https://github.com/kivy/kivy-ios
|
|
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:
|
|
- https://github.com/kivy/Buildozer
|
|
- https://github.com/kivy/buildozer/tree/master/buildozer/targets
|
|
Expected Outcome:
|
|
Running `buildozer 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.
|
|
- Performance testing. Looking at the difference between SDL2 and other providers
|
|
to ascertain whether 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.
|
|
|