kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

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)

-- 

--- KeyFP: DC07 D4C3 BB33 E596 CF5E  CEF9 D4E3 B618 65BA 2B61