kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

I think the main refactoring issue which must be considered in
adding the IGES exporter to KiCad is a plugin scheme for adding
Import/Export functions. For the Import/Export cases I have the
following notes:

Current Import/Export cases + a few future cases:
            IMPORT  EXPORT  DESCRIPTION/COMMENTS
Specctra    yes     yes     Data for autorouters + autorouter results;
                            these are necessarily different formats even
                            though they are all Specctra data.
DXF         yes     yes     Line drawings for outlines and other uses.
                            At the moment there is an IMPORT function
                            and a PLOT function rather than IMPORT/EXPORT.
GenCAD      no      yes     Data for PCB automated testing and assembly
VRML        no      yes     Visual model of the PCB
IDF         no*     yes     Simple extrusion models for PCB and components
                            + keepout and placement data.
IGES        no      yes     3D solid assembly model for PCB and components;
                            standard file format accepted by all
                            professional MCAD software.
STEP**      no      yes     3D solid assembly model for PCB and components;
                            STEP AP203 and AP214 are supported by all
                            professional MCAD software. STEP is the
                            successor to IGES.

* = import is possible but not implemented
** = STEP is desirable, in fact necessary in the long term in order for
     KiCad to be adopted by more commercial users.

The Import/Export functions include a variety of features with
very different intentions. It may be best to have a unified plugin
interface for all of these so that items can be easily added to the
Import/Export menus. The various cases are described below:

1. Specctra: The input and output files are naturally very different
since one is the input to autorouters and the other is the result
of autorouters. In this instance 2 plugins can be created with one
providing only an 'Import' and the other providing only an 'Export'.

2. DXF: The import function places glyphs on the selected layer; the
equivalent of an export function is the 'plot' function with DXF
selected as the output format. This can be addressed in 2 ways:
(a) a plugin only implements the "import" function and the plot
remains completely independent, or (b) the plugin implements both
an import and export and when 'export' is selected the plot dialog
is invoked. (I prefer 'a' for simplicity.)

3. GenCAD: the plugin will only provide an Export function

4. VRML: the plugin will only provide an Export function

5. IDF: the plugin will only provide the current Export function
   but it is possible to create an Import function if required.

6. IGES: the plugin will only provide an Export function

7. STEP: (future plans) the plugin will only provide an Export

This refactoring can be a fairly straightforward implementation
of an Import/Export interface similar to the current io_mgr.
The chief differences are in the actual GUI which must be
presented since in many cases some human interaction is required.
For this I would propose that the import/export plugin manager
should invoke a "FileImport" or "FileExport" method to instantiate
the GUI; the plugin itself may invoke a method in the manager to
instantiate a file selector within a pane of the GUI so we can
have a consistent appearance to the file selector.

I see no great barriers to the implementation once the plugin
framework has been created and after suitable testing the changes
can be applied as one big merge request. One big question is:
do we want a true plugin scheme which permits the loading of
shared libraries providing the import/export functions or
do we just want an API to make it easier to add static modules
which provide Import or Export functions?

As for the 3D model selection I think the current method can
be left as it is and each new 3D model type simply requires its
file extension to be added to a list. The IDF code will need some
cleaning up so that it uses inches for the offset values; if
we were to allow the user to select the unit for the offsets
that would require a change to the file format. I don't see any
need for drastic changes unless someone wants a feature such as
a live view of the object being added and a reference frame so
the user can tell if the orientation and scaling are correct.
I still also favor using an external orientation data file in
addition to the controls found in the 3D model selection dialog;
using such a file would allow a user to set the preferred
orientation only once and then within the 3D dialog the user
will only need to provide an appropriate Z offset if the
component requires multiple models (IC socket + IC).

Any comments/suggestions?

- Cirilo