kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/23/2014 1:49 PM, Carl Poirier wrote:
> 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

I'm always for well designed maintainable code.  I suppose you could
factor out any thing from IO_MGR that could be reused to create a 3D
model library plugin.  If not, you should take a careful look at how it
is designed.  I'm sure the design would work well for loading and saving
3D model libraries.  You should also look a Dick's delayed loading code.
 You cannot put 3D model files in the pretty footprint paths.  Otherwise
you will end up with a bunch invalid footprint file errors.  3D model
libraries will have to be in a separate folder(s) which makes sense if
you reuse the plugin design.

> 
> On Mon, Sep 22, 2014 at 6:56 PM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx
> <mailto:stambaughw@xxxxxxxxxxx>> wrote:
> 
>     On 9/22/2014 5:37 PM, Cirilo Bernardo wrote:
>     >> ________________________________
>     >> From: Carl Poirier <carl.poirier.2@xxxxxxxxx
>     <mailto:carl.poirier.2@xxxxxxxxx>>
>     >> To: Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx
>     <mailto:cirilo_bernardo@xxxxxxxxx>>
>     >> Cc: KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
> 
>