Projects for students
We encourage students to choose any of the projects listed below. All of
them require intermediate C** programming skills and basics of Git or
Bazaar (KiCad is officially handled by Bazaar, but we use Git
internally). Acquaintance with wxWidgets library or CMake build system
is seen as an extra advantage. We are going to offer help, so you are
not left alone with a problem. It includes advices on design and
implementation and code reviews.
Working with an open source project gives you much richer experience
than any solo project. Besides improving programming skills, you will
learn how to cooperate and develop software in organised way, which is
vital to any programming project. That is a great start for your career
- you may simply point a future employer to your repository that
contains code that serves a good purpose to thousands of users in the
world. Not to mention the feeling of pride and satisfaction when people
in a community say "thank you" for your efforts.
Projects mentioned below are taken from the official KiCad road map. If you have another idea for a project - let us know.
Contact us:
Javier Serrano (javier.serrano@cern.ch)
Maciej Sumiński (maciej.suminski@cern.ch)
Tomasz Włostowski (tomasz.wlostowski@cern.ch)
Build tools*
Create Separate Build Dependency Project
Goal:*
KiCad build scripts contain references to software libraries that may be
built together with KiCad if the user ask for it. The libraries and
their patches should be moved into a separate project. That will allow
developers and users to build and install them as required instead of
requiring them at build time. Besides that, it gives developers the
flexibility to build and/or install library dependencies as they see
fit. KiCad source code will reduce the build footprint once they are
removed.
Task:*
- Create a separate project to build all external dependency libraries that are currently build from source (Boost, OpenSSL, etc).
- Use CMake to create a package configuration file for each library so the KiCad find package can pull in header paths, library dependencies, compile flags, and link flags to build KiCad.
- Use CMake find_package to pull external dependencies.
- Remove all build from source dependencies for KiCad source code.
Unit Testing
Goal:*
Improve the quality of KiCad and ensure changes do not break existing
capabilities.
Task:*
Explore the possibility of including a C** unit test framework in
addition to the existing Python framework. Create robust enough test
coverage to determine if code changes break any core functionality.
These tests are going to be run either by an automated build system or a
developer.
Platform Binary Installers
Goal:*
Provide quality installers for all supported platforms.
Task:*
Ease the process of KiCad installation under different operating
systems. Determine if CPack is an appropriate solution to the problem.
If it is not the case, then there is a need for another automated
installer creation system. Think of possibility of building Linux
packages (.deb/.rpm) using a script. That is a step to provide nightly
builds to testers, so they are not forced to build KiCad every new
commit.
Software renderer for Graphics Abstraction Layer
Goal:*
KiCad sometime ago gained the Graphics Abstraction
Layer, that help
to separate display routines from model and algorithms (think of
Model-View-Component design pattern). There are OpenGL and Cairo based
rendering backends. The first one takes an advantage of hardware
acceleration, but there is a necessity for software renderer if a video
card is incapable of OpenGL support. The Cairo based renderer serves
that purpose, but it is too slow - we need either to speed it up (some
groundwork is
already done) or use another library.
Task:*
Port wxDC to GAL or get Cairo
rendering to nearly the performance of the current wxDC rendering, so
that we have a single framework to develop new tools and we can continue
to support systems that do not have a complete OpenGL stack.
Object Properties and Introspection
Goal:*
Provide an object introspection system using properties. The expected
result is a properties dialog capable of modification of common traits
for a group of selected items. You may find an example of such system in
Qt Designer Property Editor.
http://qt-project.org/doc/qt-4.8/images/designer-property-editor.png
Picture 1. Qt Designer Property Editor
Task:*
- Select existing or develop property system.
- Add definable properties to base objects.
- Create introspection framework for manipulating object properties.
- Serialization of properties to and from files and/or other I/O structures.
- Create a tool to edit property name/type/value table.
Dynamic Library Plugins
Goal:*
Create a base library plugin for handling external file I/O. This will
allow to have external plugins without increasing dependencies in the
project. To give an example we may gain solid model file support (STEP,
IGES, etc.) using OpenCascade without making it a project dependency.
Task:*
Create a plugin class to handle dynamically registered plugins for
loading and saving using various file formats. This object should be
flexible enough to be extended for handling all file plugin types
including schematic, board, footprint library, component library, etc.
See blueprint on
Launchpad
for more information.