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 the wxWidgets library and the CMake build
system is an advantage. We offer help, so you are not left alone with a
problem. Our help will take the form of design and implementation
advice, as well as code reviews.
Working on an open source project gives you a much richer experience
than any solo project. In addition to improving your programming skills,
you will learn how to cooperate and develop software in an organised
way, which is a vital skill in any large programming project. This can
be a great start for your career. Then you can point a future employer
to your repository holding 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 big community say "thank you" for your
efforts.
The projects mentioned below are taken from the official KiCad road
map.
If you have another idea for a project, let us know. If you are feeling
adventurous, you can also have a look at our list of work
packages for KiCad.
Contact us:
Javier Serrano
Maciej Sumiński
Tomasz Włostowski
Create Separate Build Dependency Project
Goal:*
KiCad build scripts contain references to software libraries that may be
built together with KiCad if the user asks for it. The libraries and
their patches should be moved into a separate project. That will allow
to build and install them as required instead of demanding them at
compile 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 built 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 the 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 after every new
commit.
Software Renderer for Graphics Abstraction Layer
Goal:*
KiCad has recently gained the Graphics Abstraction
Layer, that helps
to separate display routines from data model and algorithms (think of
the Model-View-Component design pattern). There are OpenGL and Cairo
based rendering backends available. The first one takes advantage of
hardware acceleration, but there is a necessity for a software renderer
if a video card has no 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 a system
in Qt Designer, known as 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.