|
|
|
# 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). 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](http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/Documentation/development/road-map.md)
|
|
|
|
or [work
|
|
|
|
packages](https://www.ohwr.org/project/cern-kicad/wikis/WorkPackages)
|
|
|
|
proposed by us. 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:**
|
|
|
|
Move the library dependencies and their patches into a separate project
|
|
|
|
to developers to build and install them as required instead of requiring
|
|
|
|
them at build time. Give developers the flexibility to build and/or
|
|
|
|
install library dependencies as they see fit. Remove them from the KiCad
|
|
|
|
source code to reduce the build footprint.
|
|
|
|
|
|
|
|
*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.
|
|
|
|
|
|
|
|
### Platform Binary Installers
|
|
|
|
|
|
|
|
*Goal:**
|
|
|
|
Provide quality installers for all supported platforms.
|
|
|
|
|
|
|
|
*Task:**
|
|
|
|
Ease the process of KiCad installation under different operating
|
|
|
|
systems. Possible use of CPack to build platform specific installers as
|
|
|
|
long as they are of the same or better quality than the current
|
|
|
|
independent installers.
|
|
|
|
|
|
|
|
## Common Library
|
|
|
|
|
|
|
|
### Unified Rendering Framework
|
|
|
|
|
|
|
|
*Goal:**
|
|
|
|
Provide a single framework for developing new tools. Port existing tools
|
|
|
|
to the new framework and remove the legacy framework tools.
|
|
|
|
|
|
|
|
*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 don't 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 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 plugins to be provided that are external to the project such as
|
|
|
|
providing 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](https://blueprints.launchpad.net/kicad/+spec/pluggable-file-io)
|
|
|
|
for more information.
|
|
|
|
|
|
|
|
### Netlist comparator
|
|
|
|
|
|
|
|
Currently KiCad does not track atomic changes between subsequent updates
|
|
|
|
between schematics & PCB. We need a concept of an ECO (engineering
|
|
|
|
change of order) that describes a list of atomic changes between two
|
|
|
|
netlists. This will allow robust forward/backannotation between layout
|
|
|
|
editor and schematics editor and enable features like
|
|
|
|
pin/part/bus/differential pair swapping.
|
|
|
|
|
|
|
|
For instance, if the user modifies the value, footprint and swaps the
|
|
|
|
pins of an electrolytic capacitor, the ECO shall
|
|
|
|
contain 6 following atomic entries:
|
|
|
|
|
|
|
|
- ModifyValue (path: Top/unique\_id\_of\_component, old: 100uF, new:
|
|
|
|
10uF)
|
|
|
|
- ModifyFootprint (path: Top/unique\_id\_of\_component, old: RADIAL
|
|
|
|
5mm, new: CTE3216)
|
|
|
|
- DisconnectPin (path: Top/unique\_id\_of\_component, pin: 1)
|
|
|
|
- DisconnectPin (path: Top/unique\_id\_of\_component, pin: 2)
|
|
|
|
- ConnectPin (path: Top/unique\_id\_of\_component, pin: 1, net: net-a)
|
|
|
|
- ConnectPin (path: Top/unique\_id\_of\_component, pin: 2, net: net-b)
|
|
|
|
|
|
|
|
When updating a board or schematics, the list of changes is presented to
|
|
|
|
the user and he is given a choice which ones get committed,
|
|
|
|
just like in a revision control system. The same mechanism can be used
|
|
|
|
to diff netlists between different versions of schematics/PCB designs.
|
|
|
|
|