----- Original Message ----- > From: Wayne Stambaugh <[email protected]> > To: [email protected] > Cc: > Sent: Tuesday, September 23, 2014 8:56 AM > Subject: Re: [Kicad-developers] 3d models in .pretty repositories? > > On 9/22/2014 5:37 PM, Cirilo Bernardo wrote: >>> ________________________________ >>> From: Carl Poirier <[email protected]> >>> To: Cirilo Bernardo <[email protected]> >>> Cc: KiCad Developers <[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 >
It should be possible to plug in an abstraction layer somewhere to help without interfering with the existing IO_MGR, but it certainly requires a lot of thought and planning. I'll put it onto my list of things to look at. One thing's for sure: no quick hacks. I wouldn't touch the IO_MGR to implement 3d model loading either - that function simply doesn't belong there and would only make the code mode difficult to maintain. I'll have a look at the roadmap and revisit the IO_MGR plugin. I'm pretty sure there's a lot to be gained from refactoring some code to clean up many of the import/export routines; that's already on my list of things to do but I probably won't get around to it until the end of the year. - Cirilo _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
