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 <[email protected] > <mailto:[email protected]>> wrote: > > On 9/22/2014 5:37 PM, Cirilo Bernardo wrote: > >> ________________________________ > >> From: Carl Poirier <[email protected] > <mailto:[email protected]>> > >> To: Cirilo Bernardo <[email protected] > <mailto:[email protected]>> > >> Cc: KiCad Developers <[email protected] > <mailto:[email protected]>> > >> 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 : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
