... | ... | @@ -3,9 +3,10 @@ |
|
|
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.
|
|
|
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
|
... | ... | @@ -28,22 +29,26 @@ Tomasz Włostowski (tomasz.wlostowski@cern.ch) |
|
|
## 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.
|
|
|
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.
|
|
|
*Task:**
|
|
|
|
|
|
### Unit Testing
|
|
|
- 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
|
... | ... | @@ -53,31 +58,42 @@ capabilities. |
|
|
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
|
|
|
## 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
|
|
|
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.
|
|
|
|
|
|
### Unified Rendering Framework
|
|
|
## Software renderer for Graphics Abstraction Layer
|
|
|
|
|
|
*Goal:**
|
|
|
Provide a single framework for developing new tools. Port existing tools
|
|
|
to the new framework and remove the legacy framework tools.
|
|
|
KiCad sometime ago gained the [Graphics Abstraction
|
|
|
Layer](https://www.ohwr.org/project/cern-kicad/uploads/75b6351bcb623843446bd7068bc7f82f/view-spec.pdf), 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](https://code.launchpad.net/~orsonmmz/+junk/cairo_fast) 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 don't have a complete
|
|
|
OpenGL stack.
|
|
|
Port [wxDC](http://wiki.wxwidgets.org/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
|
|
|
|
... | ... | @@ -97,22 +113,21 @@ http://qt-project.org/doc/qt-4.8/images/designer-property-editor.png |
|
|
- 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.
|
|
|
- Create a tool to edit property name/type/value table.
|
|
|
|
|
|
### Dynamic Library Plugins
|
|
|
## 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.
|
|
|
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.
|
|
|
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.
|
... | ... | |