Re: [Kicad-developers] Announcement - Decision needed
On Sat, Sep 20, 2014 at 02:39:50PM +0200, Kerusey Karyu wrote: By the way. My friend ask me: Why don't you use a Compiled HTML Help (CHM) system? I saw a Linux client for that... CHM has to die :D I'd keep the HTML files -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Build failed in Jenkins: kicad-qa #347
See http://ci.kicad-pcb.org/job/kicad-qa/347/changes Changes: [jean-pierre charras] Minor fixes: specctra export: skip malformed circles (having a radius = 0) in board outline creation, which can crash 3d-viewer or vrml export. dialog_fp_lib_table: remember during a session the last open table (global or local). drawing_tool: fix compil warning Update demos. -- Started by an SCM change Building in workspace http://ci.kicad-pcb.org/job/kicad-qa/ws/ $ bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ info result: bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ returned 0. Command output: 5142 stambau...@verizon.net-20140919235832-6zu6t8pt83hqkk8k stderr: [kicad-qa] $ bzr pull --overwrite lp:kicad You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See bzr help launchpad-login. http://bazaar.launchpad.net/~kicad-product-committers/kicad/product is permanently redirected to http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See bzr help launchpad-login. M demos/interf_u/interf_u-cache.lib M demos/interf_u/interf_u.cmp M demos/interf_u/interf_u.kicad_pcb M demos/interf_u/interf_u.net M demos/interf_u/interf_u.pro M demos/interf_u/interf_u.sch M demos/pic_programmer/fp-lib-table R demos/pic_programmer/libs/footprints.pretty/ = demos/pic_programmer/libs/pic_programmer_fp.pretty/ -D demos/pic_programmer/libs/footprints.pretty/textool_40.kicad_mod M demos/pic_programmer/pic_programmer.cmp M demos/pic_programmer/pic_programmer.kicad_pcb M demos/pic_programmer/pic_programmer.net M demos/pic_programmer/pic_programmer.pro M demos/pic_programmer/pic_programmer.sch M demos/pic_programmer/pic_sockets.sch M eeschema/menubar.cpp M pcbnew/dialogs/dialog_fp_lib_table.cpp M pcbnew/dialogs/dialog_fp_lib_table_base.cpp M pcbnew/dialogs/dialog_fp_lib_table_base.fbp M pcbnew/dialogs/dialog_fp_lib_table_base.h M pcbnew/specctra_export.cpp M pcbnew/tools/drawing_tool.cpp All changes applied successfully. Now on revision 5143. [kicad-qa] $ bzr revert $ bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ info result: bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ returned 0. Command output: 5143 jp.char...@wanadoo.fr-20140922075106-jm0vkm398ns0xaxh stderr: [kicad-qa] $ bzr log -v -r revid:stambau...@verizon.net-20140919235832-6zu6t8pt83hqkk8k..revid:jp.char...@wanadoo.fr-20140922075106-jm0vkm398ns0xaxh --long --show-ids Getting local revision... $ bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ info result: bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ returned 0. Command output: 5143 jp.char...@wanadoo.fr-20140922075106-jm0vkm398ns0xaxh stderr: RevisionState revno:5143 revid:jp.char...@wanadoo.fr-20140922075106-jm0vkm398ns0xaxh [kicad-qa] $ /bin/sh -xe /tmp/hudson6908454243359980924.sh + OPTS=' -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON' + '[' -d build ']' + cd build + /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON -- Check for installed OpenGL -- found -- Found Glew: /usr/lib64/libGLEW.so -- Check for installed GLEW -- found -- Check for installed Cairo -- found -- Check for installed wxWidgets -- found -- Check for installed Python Interpreter -- found -- Python module install path: /usr/lib/python2.6/site-packages -- Bazaar version control system version found. -- Kicad Bazaar build version: (2014-09-22 BZR 5143) -- Configuring done -- Generating done -- Build files have been written to: http://ci.kicad-pcb.org/job/kicad-qa/ws/build + rm -f pcbnew/scripting/pcbnewPYTHON_wrap.cxx.o + rm -f pcbnew/scripting/pcbnewPYTHON_wrap.cxx + make -j4 _pcbnew [ 0%] [ 0%] Built target lib-dependencies [ 1%] Built target idf3 Built target boost [ 3%] [ 3%] Built target lib_dxf Generating headers containing GLSL source code Headers are up-to-date [ 3%] Built target shader_headers [ 50%] Built target bitmaps [ 50%] Built target polygon [ 50%] Built target avhttp [ 51%] Built target 3d-viewer [ 53%] Built target pcad2kicadpcb [ 56%] Built target gal [ 56%] Built target github_plugin Scanning dependencies of target common [ 56%] Building CXX object common/CMakeFiles/common.dir/build_version.cpp.o Scanning dependencies of target pcbcommon [ 56%] Building CXX object common/CMakeFiles/pcbcommon.dir/__/pcbnew/specctra_export.cpp.o Linking CXX static library libcommon.a [ 67%] Built target common Linking CXX static library libpcbcommon.a [ 73%] Built target pcbcommon [ 76%] Built target pnsrouter [ 76%] [ 76%] Swig source Generating pcbnew_wrap.cxx, pcbnew.py
Re: [Kicad-developers] [Kicad-lib-committers] Fwd: question about SMD_Packages
On Sat, Sep 20, 2014 at 11:58:48AM -0400, Carl Poirier wrote: Hi folks, We have some great contributions here prepared by Michal Stec. He's generating SMD packages appropriate for the convention, however we were unsure how to make the silkscreen for QFN packages. If it's done the same as TQFP, it yields, for the pin one indication, a bar so short it's going to be difficult to see. We thus tried to find something else. Please have a look at the two screenshots below. The first one has a more visible mark, but I'm unsure if there are QFN packages with pins in the reverse order, in which case we can't tell from the silkscreen. Any comments? I have attached the file. QFN (and 'internal pin' components, in general) have the pin 1 indication done *interrupting* the outer silk outline near the pin site -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Blind/buried via creation in PS router [PATCH]
On 22.09.2014 02:16, Andrew Zonenberg wrote: Looks like the issue I mentioned previously is indeed a bug. The attached patch fixes it and provides full support for blind/buried/microvias in GAL. Hi Andrew, Thanks for the patch, We'll merge it with my changes improving layer switching and push to the master branch towards end of the week. Cheers, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Jenkins build is back to normal : kicad-qa #348
See http://ci.kicad-pcb.org/job/kicad-qa/348/changes ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Announcement - Decision needed
On 9/20/2014 7:36 PM, Marco Ciampa wrote: On Sat, Sep 20, 2014 at 02:39:50PM +0200, Kerusey Karyu wrote: All the Polish help docs has been ported/converted to HTML format and committed. Now you have to decide to keep, archive or remove their PDF editions and ODF sources. Please, don't for now, be patient. I am tryng to convert all ODF docs in a more manageable format. The HTML format IMHO should be obtained by automatic compilation like other useful formats for the documentation. I agree with Marco on this. I don't think HTML is a good native format for creating documentation. By the way. My friend ask me: Why don't you use a Compiled HTML Help (CHM) system? I saw a Linux client for that... You correctly said compiled. If you compile something you must have somewhere some sort of source. Using that source you can, easily and in a maintainabile manner, manage automatically the format conversion. Nowadays, documentation is rarely directly written in HTML. Usually docs are created automatically by conversion from another more standard and/or manageable format like SGML, XML-DOCBOOK, Markdown, Asciidoc, Rest or the like, and then converted automatically (and correctly) into HTML, odt, pdf, CHM, rtf, LaTex or even epub. This is how I prefer to see it done as long as the tools are available on all platforms supported by kicad. And, as a bonus track you gain an easy manageable and maintainable method for handling multilanguage doc translations With such a method it is straitforward to obtain and update all translated docs that are changed in the source reference language and format and propagate such changes into all languages sources. As a bonus track you can take a look at English KiCad Manager doc using my style sheet. https://github.com/keruseykaryu/kicad-kerusey-doc-html/tree/master/doc/help/en That could be reused, so it will not be a waste of time. Likewyse the translation sources, with a little bit of effort of cut paste... but please wait because I do not want you to waste time into unneeded conversions. Many thanks! ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Stackups and via design rules
After a discussion with Nick Oestergard on IRC, I've come to the conclusion that we really need to sit back and think about how design rules for vias and stackups are handled. As of right now, we have three kinds of vias: 1) Through-board via. These penetrate the entire board and can connect any layers in between. 2) Microvia. These can only go from an outer layer to the adjacent internal layer. 3) Blind/buried via. These go from any layer to any other layer, and can connect anything in between. We currently have two sets of design rules: 1) Drilled vias. There is a global minimum, netclass default size, and a list of custom sizes. This applies to both through and blind/buried vias. 2) Microvias. There is a global minimum, netclass default size, but no support for custom sizes. Unfortunately, this doesn't accurately reflect the realities of PCB manufacture. Mechanical drills can be done through the entire stack at any point during manufacture (including before all layers have been laminated), and laser drills can be done from any layer to the next one down (including before all layers have been laminated). Furthermore, minimum diameters of drills are typically limited by aspect ratio concerns. In other words, the less depth a drill has to penetrate, the smaller the hole can be. To illustrate my point, I've attached a cross section of a typical 6-layer HDI stackup (similar, but not identical, to one that I used on a project for work recently). There are quite a few different kinds of vias: 1) Buried mechanical drills from layer 3 to 4, through the board core before any prepregs are applied. These can be slightly smaller than through-board mechanical drills since the stack is thinner. 2) Buried laser drills from layer 2 to 3, the first level of prepreg, before the outer layer is laminated. These can be very tiny since they're only penetrating one layer. 3) Blind laser drills from layer 1 to 2, the second level of prepreg, after the stack is fully laminated. These can be just as small as the buried laser drills. 4) Mechanical drills through the entire board after the stack is fully laminated. These are the largest since they have to penetrate the entire stack. 5) Laser drills on the back side (4-5 or 5-6) are not allowed at all since this requires an extra process step, increases cost, and I only had fine-pitch BGAs on the front side of the board. Kicad's current model cannot handle this case well. I could use microvias from 1-2, but the 2-3 vias need to be blind/buried, which uses the global through-board drill design rule. This means that I need to set the global drill minimum to something tiny like 6 mils, which would implicitly allow a 6 mil through-board mechanical drill (something few fabs can manufacture at all, and certainly not for a reasonable price). I also would need to enable blind/buried vias globally, which would allow me to do a 4-5 or 5-6 laser via accidentally and not catch it until I exported CAM files for manufacture. I think what we really need to do is define a more complete stackup editor that specifies layer thicknesses (for future impedance control/current capacity calculations etc), dielectric constants, and allows a list of layer pairs and via sizes to be defined. Does anyone have input into how this should work? I'm pretty busy but would like to at least get a non-functional mockup of the UI prototyped soon. For extra fun in the longer term, integrate with the PCB calculator so you can design design rules for target impedances. For example: Layer | Width | Spacing | Type | Z0 target | Z0 actual | F_Cu | 0.15 | | Single | 50.00 | 48.95 | F_Cu | 0.25 | 0.125 | Diff | 100.00| 101.32| In1_Cu | 0.125 | | Single | 50.00 | 51.24 | Then just select 50 ohm single from the track width dropdown and the correct size for the current layer will be used automatically. -- Andrew Zonenberg PhD student, security group Computer Science Department Rensselaer Polytechnic Institute http://colossus.cs.rpi.edu/~azonenberg/ signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3d models in .pretty repositories?
Carl, I agree 100% with you. The 3D model of the package should be tied to the shape library. The only concern is the size of the 3D model file, and the fact that some users will never use the 3D capability. I have no idea on what mechanism will allow to include the 3D shape unless the format used is text based, so it could be then part of the part itself. I know IGES is text based, but I do not know what is the format of the current files (wings?) Just my $0.02 Jean-Paul AC9GH On Sep 22, 2014, at 2:03 PM, Carl Poirier carl.poirie...@gmail.com wrote: Hi folks, Is there any reason to have the 3d models in the kicad-library repository? They are tied to footprints actuall ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] bug 1371656: zero diameter circles
In the bug report 1371656 there are several problems shown. One problem which affects pcbnew, 3Dviewer, Specctra export, VRML export, and IDF export (maybe others which I haven't checked) is zero diameter circles. Apparently they can be created but naturally we cannot delete them because we can't see them. I did not look to see if it is possible to create zero radius arcs as well. In bug 1371656 the zero diameter circle was to the left of the rectangular board margin and also on the Edge.Cuts layer; this resulted in 3Dviewer not rendering a board, IDF export producing a bad outline, and the VRML export segfaults due to another unrelated bug (I will fix VRML export when I have time). I haven't checked but I suspect Specctra will also get the bounds wrong; after all it is the Specctra routine which is used by 3Dviewer to create the outline. - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3d models in .pretty repositories?
From: Carl Poirier carl.poirie...@gmail.com To: KiCad Developers kicad-developers@lists.launchpad.net Sent: Tuesday, September 23, 2014 4:03 AM Subject: [Kicad-developers] 3d models in .pretty repositories? Hi folks, Is there any reason to have the 3d models in the kicad-library repository? They are tied to footprints actually, so why no putting them alongside? I think it would make for a much cleaner library. Also, when retrieving a footprint from github automatically, it could pull the model as well. If it makes sense, is anyone familiar enough with the github plugin to chime in and give an insight on the work that would need to be done? I had commented on the 3d models many months ago. I do not believe they should be in the .pretty directories since they will only pollute; I think they should be in their own top level directory and separate from the .pretty and schematic symbol files since many people don't want 3D models. At the moment the github plugin only serves the footprints; it has absolutely nothing to do with 3D models. There is code there which can be used to retrieve generic files via git/github but any proposal for retrieval of files from the network has to be carefully thought out. - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
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. On Mon, Sep 22, 2014 at 4:49 PM, Cirilo Bernardo cirilo_berna...@yahoo.com wrote: From: Carl Poirier carl.poirie...@gmail.com To: KiCad Developers kicad-developers@lists.launchpad.net Sent: Tuesday, September 23, 2014 4:03 AM Subject: [Kicad-developers] 3d models in .pretty repositories? Hi folks, Is there any reason to have the 3d models in the kicad-library repository? They are tied to footprints actually, so why no putting them alongside? I think it would make for a much cleaner library. Also, when retrieving a footprint from github automatically, it could pull the model as well. If it makes sense, is anyone familiar enough with the github plugin to chime in and give an insight on the work that would need to be done? I had commented on the 3d models many months ago. I do not believe they should be in the .pretty directories since they will only pollute; I think they should be in their own top level directory and separate from the .pretty and schematic symbol files since many people don't want 3D models. At the moment the github plugin only serves the footprints; it has absolutely nothing to do with 3D models. There is code there which can be used to retrieve generic files via git/github but any proposal for retrieval of files from the network has to be carefully thought out. - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3d models in .pretty repositories?
From: Carl Poirier carl.poirie...@gmail.com To: Cirilo Bernardo cirilo_berna...@yahoo.com Cc: KiCad Developers kicad-developers@lists.launchpad.net 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 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3d models in .pretty repositories?
On 9/22/2014 5:37 PM, Cirilo Bernardo wrote: From: Carl Poirier carl.poirie...@gmail.com To: Cirilo Bernardo cirilo_berna...@yahoo.com Cc: KiCad Developers kicad-developers@lists.launchpad.net 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3d models in .pretty repositories?
- Original Message - From: Wayne Stambaugh stambau...@verizon.net To: kicad-developers@lists.launchpad.net 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.poirie...@gmail.com To: Cirilo Bernardo cirilo_berna...@yahoo.com Cc: KiCad Developers kicad-developers@lists.launchpad.net 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 : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
