Re: [Kicad-developers] Blueprint for layouts as parts
It seems that users are looking forward to the feature: http://groups.yahoo.com/neo/groups/kicad-users/conversations/messages/16647 Regards, Orson On 12/01/2013 06:59 PM, Martin Janitschke wrote: Heyho, I've created the blueprint [0] we've started to discuss in the Next Steps thread. Comments are welcome :). The blueprint partially supersedes [1] [2] due to the fact that Pcbnew will make it way easier to create panelized boards by hand and the overhead to create the schematics for the whole board is now minimal. (1. Add sub-sheets, assign the correct schematics, 2. select the correct boards in CvPcb, 3. move the boards next to each other (without the old hassle to select the whole board, move the already panelized boards out of the way before appending the next one...)). Bye, imp [0]: https://blueprints.launchpad.net/kicad/+spec/layouts-as-footprint [1]: https://blueprints.launchpad.net/kicad/+spec/add-panelize-to-pcbnew [2]: https://blueprints.launchpad.net/kicad/+spec/append-board ___ 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 ___ 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 scrip now fails - kicad-0.0.20131206/kicad-library does not exist.
Trying to use my debian build scrip (that used to work) and it fails with: -- Build files have been written to: /usr/src/kicad-0.0.20131206/build/kicad-doc mkdir -p /usr/src/kicad-0.0.20131206/build/kicad-library cd /usr/src/kicad-0.0.20131206/build/kicad-library cmake ../../kicad-library CMake Error: The source directory /usr/src/kicad-0.0.20131206/kicad-library does not exist. Looking back in this mailing list I see conversations about changing this - not sure which direction it went in? ( I think I should just comment out all the kicad-libarary stuff?) When I fetch the sources I have: bzr export $d/kicad lp:kicad/stable bzr export $d/kicad-doc lp:~kicad-developers/kicad/doc bzr export $d/kicad-library lp:~kicad-lib-committers/kicad/library .. for reference - I've attached the rules file that I'm using -- Karl Schmidt EMail k...@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Coordination does not run in my family, it stumbles. #!/usr/bin/make -f # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 # Make sure no svn parts inside the deb DH_ALWAYS_EXCLUDE=CVS:.svn export DH_ALWAYS_EXCLUDE # This has to be exported to make some magic below work. export DH_OPTIONS # .NOTPARALLEL: configure: configure-stamp configure-stamp: mkdir -p $(CURDIR)/build/kicad mkdir -p $(CURDIR)/build/bitmaps_png cd $(CURDIR)/build/kicad cmake \ -DKICAD_DEMOS=$(CURDIR)/debian/kicad-common/usr/share/doc/kicad/demos ../../kicad \ -DKICAD_SCRIPTING_MODULES=ON \ -DKICAD_TESTING_VERSION=ON \ -DKICAD_SCRIPTING=ON \ -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2.7 \ -DPYTHON_DEST:PATH=$(CURDIR)/debian/kicad/usr/lib/python2.7/dist-packages/pcbnew/ \ -DKICAD_SCRIPTING_WXPYTHON=ON -LA mkdir -p $(CURDIR)/build/kicad-doc cd $(CURDIR)/build/kicad-doc cmake ../../kicad-doc mkdir -p $(CURDIR)/build/kicad-library cd $(CURDIR)/build/kicad-library cmake ../../kicad-library touch $@ build: build-arch build-indep build-arch: build-arch-stamp build-arch-stamp: configure-stamp $(MAKE) -C $(CURDIR)/build/kicad touch $@ build-indep: build-indep-stamp build-indep-stamp: configure-stamp $(MAKE) -C $(CURDIR)/build/kicad-doc $(MAKE) -C $(CURDIR)/build/kicad-library touch $@ clean: clean-build dh_testdir dh_testroot rm -f build-arch-stamp build-indep-stamp configure-stamp # REMOVE AUTOMATICALLY GENERATED FILES rm -f kicad/pcbnew/dialog_freeroute_exchange_help_html.h \ kicad/eeschema/cmp_library_base.h \ kicad/eeschema/cmp_library_base.cpp dh_clean clean-build: rm -rf $(CURDIR)/build install: install-indep install-arch install-indep: dh_testdir dh_testroot dh_clean -k -i dh_installdirs -i dh_installdocs cd $(CURDIR)/build/kicad/demos cmake -P cmake_install.cmake cd $(CURDIR)/build/kicad-doc/internat cmake -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/kicad-common/usr -P cmake_install.cmake cd $(CURDIR)/build/kicad/template cmake -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/kicad-common/usr -P cmake_install.cmake cd $(CURDIR)/build/kicad-library cmake -DCOMPONENT=resources -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/kicad-common/usr -P cmake_install.cmake cd $(CURDIR)/build/kicad-doc cmake -DCOMPONENT=file_formats -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/kicad-common/usr -P cmake_install.cmake cd $(CURDIR)/build/kicad-doc cmake -DCOMPONENT=footprints_doc -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/kicad-common/usr -P cmake_install.cmake cd $(CURDIR)/build/kicad-doc cmake -DCOMPONENT=doc-de -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/kicad-doc-de/usr -P cmake_install.cmake cd $(CURDIR)/build/kicad-doc cmake -DCOMPONENT=help-de -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/kicad-doc-de/usr -P cmake_install.cmake cd $(CURDIR)/build/kicad-doc cmake -DCOMPONENT=doc-en -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/kicad-doc-en/usr -P cmake_install.cmake cd $(CURDIR)/build/kicad-doc cmake -DCOMPONENT=help-en -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/kicad-doc-en/usr -P cmake_install.cmake cd $(CURDIR)/build/kicad-doc cmake -DCOMPONENT=doc-es -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/kicad-doc-es/usr -P cmake_install.cmake cd $(CURDIR)/build/kicad-doc cmake -DCOMPONENT=help-es
Re: [Kicad-developers] build scrip now fails - kicad-0.0.20131206/kicad-library does not exist.
Hi Karl, The libraries have moved to Github, here https://github.com/KiCad. The old repo is still available, but it has been moved and renamed to library-read-onlyhttps://code.launchpad.net/~dickelbeck/kicad/library-read-only. Its use is discouraged, as it will eventually be removed. With the new Github plugin, you don't need to have the libraries installed locally anymore. They will be fetched from Github automatically when you ask for them. You just have to make sure the plugin is built, and that you use the right fp-lib-table, which can be found herehttps://github.com/KiCad/kicad-library/blob/master/template/fp-lib-table.for-github . Carl On Fri, Dec 6, 2013 at 5:05 PM, Karl Schmidt k...@xtronics.com wrote: Trying to use my debian build scrip (that used to work) and it fails with: -- Build files have been written to: /usr/src/kicad-0.0.20131206/ build/kicad-doc mkdir -p /usr/src/kicad-0.0.20131206/build/kicad-library cd /usr/src/kicad-0.0.20131206/build/kicad-library cmake ../../kicad-library CMake Error: The source directory /usr/src/kicad-0.0.20131206/kicad-library does not exist. Looking back in this mailing list I see conversations about changing this - not sure which direction it went in? ( I think I should just comment out all the kicad-libarary stuff?) When I fetch the sources I have: bzr export $d/kicad lp:kicad/stable bzr export $d/kicad-doc lp:~kicad-developers/kicad/doc bzr export $d/kicad-library lp:~kicad-lib-committers/kicad/library .. for reference - I've attached the rules file that I'm using -- Karl Schmidt EMail k...@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Coordination does not run in my family, it stumbles. ___ 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 ___ 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] wxAui improvements.
I have just committed a small change to the testing branch (r4529) to the Pcbnew footprint viewer that will allow the main toolbar to be dockable. I would like some feedback about how well saving and loading the window state between session works on various platforms before I start to do this to all of the KiCad application main frame windows. The wxAui stuff was put in place a few years ago with the intent that all of the fancy layout features would be enabled. Since that hasn't happened I thought I would start working on it incrementally rather than get carried away an create a lot of problems. When you have some spare time, please test it and let me know if there are any major issues. I don't have wxWidgets 3 on my Linux partition and no access to OSX so feedback from those users is very important since I cannot test those platforms. Thanks, 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
[Kicad-developers] Proposal: reorganize the components library
I'd like to propose a new format for components libraries. The summary
of the proposal is as follows:
* XML is used as the serialization format
* one directory per library
* one file per component
* boost::property_tree is used as internal, abstract data format. This
allows translating to/from multiple file formats at the point of load/save.
I'm volunteering to implement a new library parser/writer and convert
all existing libraries to the new format, if the proposal gets accepted.
We could potentially introduce something very similar to the Github
plugin for component libraries too, however this is not part of this
proposal.
The detailed proposal is as follows:
* A library in the new format would be defined as a collection of files
in a directory. A directory would contain:
+ A file with extension '.kicad_symlib', in which some library-wide
information is specified
+ A collection of files with extension '.kicad_sym', each of which
define one component. I think it's worth to merge the component symbol
and the docs into a single file because:
- Everything could be kept in a single place
- The number of files would be reduced
- The docs don't take much space anyway
* The .kicad_symlib file would not list the symbols contained in the
library. The library parser should list all files within the directory
and try to parse each file with appropriate extension.
* The file name would be derived from the component name.
* The format of the files would be XML. This has the following advantages:
+ The format would be at least somewhat self-documenting
+ The format would be easily extensible
+ The format would allow much better interoperability with other
software, as tool/library support for XML is in great shape.
* Indentation amount would be set as a policy to eliminate any problems
during merges to the repository. The same for newline locations. I
suggest two spaces and one tag per line respectively.
* XML namespaces won't be used since they are not useful in this
particular use-case, yet would make the files less convenient to parse
using certain libraries.
* boost::property_tree library would be used as a parser. It is already
used in the KiCad codebase.
* The saving and loading routines would be modified to accept a path
instead of a generic stream. CMP_LIBRARY::{Save,Load} and
{Save,Load}Docs would be merged each with their respective sibling.
* The users of CMP_LIBRARY::{Save,Load} would not know exact layout of
the library. Existing functionality that depends on the layout would be
moved to within CMP_LIBRARY. For example, a new method
CMP_LIBRARY::Backup would be introduced.
* At first, parsers of both formats would be implemented as member
functions of CMP_LIBRARY. Once everything is tested, we could create a
plugin interface.
* New {Load,Save} overloads that accept boost::property_tree would be
created for all LIB_* types that support serialization. Eventually,
write support for old format would be removed: the format would be
supported by translating it to boost::property_tree at a single,
centralized location (though bidirectional translation is possible too,
if needed). We could support lots of other formats this way.
What do the developers think about this proposal?
Regards,
Povilas
___
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] Proposal: reorganize the components library
I've already got a reply off-list that equivalent functionality is already developed (I couldn't find any discussions on the list until now unfortunately). It thus makes sense to scrap the proposal. Perhaps I can help whoever is working on the new library file format? Regards, Povilas ___ 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
