kicad-developers team mailing list archive

[Carl Poirier <carl.poirier.2@xxxxxxxxx>]

Hi,

Thanks all for your input. Wayne, if the I/O is abstracted and well
maintainable, as you mentioned, would you support this? If no, what are the
reasons?

Carl

On Mon, Sep 22, 2014 at 6:56 PM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
wrote:

> On 9/22/2014 5:37 PM, Cirilo Bernardo wrote:
> >> ________________________________
> >> From: Carl Poirier <carl.poirier.2@xxxxxxxxx>
> >> To: Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>
> >> Cc: KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >> Sent: Tuesday, September 23, 2014 7:23 AM
> >> Subject: Re: [Kicad-developers] 3d models in .pretty repositories?
> >>
> >>
> >>
> >> 3D models could be retrieved only as needed, like footprints. I don't
> see how this would be more polluting than in kicad-library which is
> installed locally.
> >>
> >>
> >> I know the github plugin serves only footprints. That's why I wonder
> how hard it would be to adapt it.
> >>
> >
> >
> > The issue is how to adapt things so that they are useful and not make
> the code
> > unmaintainable. If 3D models are to be retrieved from the network then
> this
> > will touch the 3Dviewer, VRML exporter, and in the future the IDF
> exporter; no
> > one wants to maintain network related code in all these tools.
> > So first of all we need to abstract things so that at least these 3 tools
> > are not really aware that they are performing a network access - so I
> would
> > look into abstracting the file loading operation and investigate if it is
> > possible to do this for the current footprint code as well as the VRML
> and IDF
> > code. To speed up operation it would be good to create local copies as
> data is
> > downloaded and this local cache must be checked before downloading a
> model on
> > the network - once again this can be done via a file loading abstraction.
> > It would also be good to check md5 hashes of the data and allow the
> users to
> > update a model if desired.
> >
> > This file loading abstraction might also serve eeschema in the future for
> > accessing schematic symbol files. I think that doing a good job of
> implementing
> > 3d model downloads via the net is not a small job. Although a quick hack
> will
> > not be that difficult I don't believe it would be maintainable either,
> especially
> > not as tools using 3d models are added in the future; I don't think
> anyone
> > wants to create yet another refactoring job.
> >
> > - Cirilo
>
> I do not support the idea of saving models in pretty libraries.  I also
> reject the idea of using PCB_IO for loading 3D models.  I do support the
> idea of abstracting out any useful low level code from the IO_MGR object
> to create an I/O architecture for 3D models or any other place where it
> makes sense.  3D model I/O and footprint library I/O are not
> interchangeable and I do not want the 3D I/O polluting the footprint I/O
> code.  I know that Tom has proposed a plug in model that may serve this
> purpose as well.  I don't know if he has made any progress on this front.
>
> At some point the IO_MGR concept will be used for schematics and
> component libraries.  I believe I added this development road map
>
> Wayne
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>