kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/27/2011 05:08 AM, Vladimir Uryvaev wrote:
> At Sunday 27 of November 2011 10:51:48 from Dick Hollenbeck:
>> Javier,
>>
>> I copy the KiCad developers mailing list too on this one.
>>
>> Here is a revision of the IO_MGR and PLUGIN support that we talked about. 
> Good start.
>
> My question is about PCB_FILE_T aFileType
>
> Is it really necessary? Pointer to particular IO-object could can act as a 
> filetype identifier, from which (using virtual members) any information can be 
> fetched. If it intended to use in switch, first switch canno be extended in 
> runtime, second, that switch could bereplaced by virtual call. Third, is it 
> really needed in loader? Loader could probe a file for its type and select 
> appropriate plugin automagically.
>
> So this function could be not needed as everywhere you pass PCB_FILE_T you can 
> pass PLUGIN*.
>
> static PLUGIN* FindPlugin( PCB_FILE_T aFileType );
>
>
> For PLUGIN, I think there could be its subclass, say IO_PLUGIN (or, more 
> specifically, PCB_IO_PLUGIN if it intended to be shareable between eesch and 
> pcb) as not any PLUGIN could be loader/saver.
>
> Its time to develop good design for loader, saver and plugin architecture.
>
> I think there could be at least three classes:
>
> class PLUGIN // base for all plugins
>
> class PCB_IO // base for board IO, this can be used for built-in IO
> {
>     virtual load();
>     virtual save();
>     virtual fileFormatName();
>     virtual fileNamePattern(); // for file type selection list constructor
> }
>
> class PCB_IO_PLUGIN: public PLUGIN, PCB_IO // pluggable IO module.
>
> So any code acting with IO could pass class PCB_IO object (which can be plugin 
> or built-in)

I believe you are thinking that a directory scan is done for DLL/DSOs, then they are each
loaded, queried and added to a collection.

Since we are dealing with the open source world, it will be mostly the case that we know
which plugins are available ahead of time, since they will be compiled with the project. 
This is where I got my direction.

Secondly, there are sadly problems in the objects of KiCad which make making a DLL/DSO
problematic, and this includes the fact that each object has its own Draw() member
function.  We do not want Draw() support down in a DLL/DSO plugin, where we only want to
load and save the objects, not draw them.  This means linking becomes a problem.

The existing load and save object specific member functions are also a problem with we
want to load and save these objects in the context of ANOTHER non-KICAD plugin such as
EAGLE.  (In contrast, I will defend a future choice to put an s-expression Format() member
function in each object for clipboard support.)

So in deference to the day when we have cleaner objects, I opted to put the plugins in our
main link image for now, and to focus on Load() and Save() using exceptions support, and
to strive for immediate plug-ability with respect to alternative file formats.

I think some of your ideas make sense for future enhancements, but I don't want to do more
than is needed at this time.  The future enhancements will affect few lines of code.

Dick