kicad-developers team mailing list archive
Mailing list archive
Re: Was: request for comments on work package list, is now: IO_MGR
At Sunday 27 of November 2011 10:51:48 from Dick Hollenbeck:
> 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.
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
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 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
--- KeyFP: DC07 D4C3 BB33 E596 CF5E CEF9 D4E3 B618 65BA 2B61