kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

----- Original Message -----

> From: Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
> To: kicad-developers@xxxxxxxxxxxxxxxxxxx
> 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 <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
> 


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