Re: [Kicad-developers] Some schematics library structure ideas
Several years ago (20110412) on this list, I attempted to start a discussion on this topic with Dick, but gained no traction at that time. In hopes of providing some context in reconciling the physical vs. logical representations and associated nomenclature, here's a repost of the main text of my original message: -- I have some thoughts that might be relevant to this discussion. I frequently find myself dealing with parts that come in multiple variants and with multiple packages available, such asmicrocontrollers. These ICs are good examples of where some additional flexibility would be desirable. I'll use the STM32F100 as an example. They are available in 4 different packages (LQFP48, LQFP64, TFBGA64,and LQFP100), 4 different memory configurations, and 2 levels of peripheral support. It would be tedious and error-prone to have to create separate parts for each valid configuration, and frequently the choice of which package or variant isn't decided until layout has begun. In many cases, pin functions can be swapped or remapped to ease layout, and many peripherals have their functions overloaded on the pins. For me, it would be ideal to treat each interface or peripheral as a sub-part and connect signals to functions rather than to pads; DRC could then warn if you attempt to use a pin for more than one function. To provide disambiguation for the necessary functionality, I suggest a nomenclature that allows separation of the functional view of the part from the physical view. The terms that I have been using are: *part - the abstract representation *symbol - a schematic representation *device - a physical device representation *component - a particular device as placed on a board *package - the package type for a device *footprint - the board layout to accept a device *pin - a unique electrical connection to a device *pad - the physical pad where a pin connects to the board through a solder joint *pinout - the mapping from pins to pads for a given device *function - an abstract representation of functionality or connectivity *type - the logical representation of a physical interface *signal - a specific electrical representation of functionality or connectivity *block - a related set of functions grouped together *bus - a consistent collection of signals for interconnecting blocks *configuration - a mapping of functions to pins Using these terms, we could assign an arbitrary number of functions to a pin, map pins to pads for any available package, easily allow pins to be swapped (PC3 for PB2) as well as entire function blocks (I2C1 for I2C2). For example, something like the following structure (with details omitted): --snip-- (Lengthy example omitted, please see the archives for the full text) Obviously, some of this has been been decided and codified in the intervening time, but I think the basic distinctions are still valid. Without addressing the interplay between physical and logical design, it will be nearly impossible to specify physical requirements for DRC relating to a given set of pins based on their function, not physical location on the package. I2C busses and Analog Input signals require very different design rules, but may be available on the same physical pins on a micro-controller. As for utilizing different symbols for the same part, think about all of the ways an op-amp can be used in a circuit, and the specific symbols used in each case in an analog signal processing chain. ~~~Chris Giorgi~~~ On Thu, Jan 15, 2015 at 9:14 AM, Andy Peters de...@latke.net wrote: On Jan 14, 2015, at 7:46 PM, Fat-Zer fatz...@gmail.com wrote: Sorry about accidental send previous message. 2015-01-14 18:53 GMT+03:00 Andy Peters de...@latke.net: 2. Different images of the same schematic component. There are already such variants for some common components like CP, also there are small variants for some components. Who cares about a symbol variant? Pick the one you prefer and use it. yep, but for user can be able to easily chose it, kicad library should provide them out of the box... And I propouse a way to store them in library more straightforward IMO. I guess I don't see the point. How many components have different symbols? Perhaps passives, where resistors can either be a rectangle or the v^v^v^v we all know and love? In both such cases we can keep information about the component in single symbol. Also as a bonus we can easily support both IEC and US symbols and use it in some other cases. Why? I think that a lot of advanced users will choose one symbol type and leave it at that, and not go the route of switching between one symbol variant and another. yep, but it's a suggestion in case of open hardware environment. It may be usefull in case you are reusing somebody's else workarounds. but it's not a first goal, just a suggestion for a bit more distant future... By the word, I'm not really
Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)
My 2c: let the parser ignore unknown/incompatible s-expressions and warn the user when they are encountered. On 14 January 2015 at 22:24, Martijn Kuipers martijn.kuip...@gmail.com wrote: On 14 Jan 2015, at 21:07, Cirilo Bernardo cirilo.berna...@gmail.com wrote: On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski tomasz.wlostow...@cern.ch wrote: On 13.01.2015 20:11, Wayne Stambaugh wrote: This is a tricky issue that has been discussed before. The general consensus in the past has been not to support forward compatibility. It increases maintenance and complexity of the file parser for a minimal net gain to the user. My preference is to force users that want to bleed on the edge to use nightly builds rather than try to maintain any forward file compatibility. [snip] OK, how about this: - No extra version tokens (fits point A) - Warning instead of error on unrecognized tokens (point C - no big changes needed in the parser) - If the opened file is produced by a newer version of Kicad, issue a big warning when the user attempts to save it, that certain features will be lost (points B and D - if somebody complains we can always tell him he was warned). AFAIK this is what most commercial software does. Cheers, Tom Except for Acrobat Reader, all the other software I use simply tells me it cannot load the new file. In a corporate environment and especially on large projects no one wants to take the risk that someone obliterated some data. Let's say Person A sends Person B a file with data missing - what can Person B possibly do with that now? Person B was never aware of the warning that Person A ignored and the software is not psychic so it cannot say hey, the last time you worked on this file it was Version X.Z, not X.Y. The problem gets worse and more difficult to detect as the project gets more complex. People need to understand the limitations of their tools and work with that. As I said before people can negotiate what version they need and if necessary build/install to support a specific project. Otherwise why use file versions at all if we're essentially only using it to tell if there are newer features and essentially ignore it and write corrupted data anyway? I would be very happy with backward compatibility, especially if it would allow us to safe the file in the older format. This way, not everybody in the team needs to have the same version to be able to work. Of course, if someone saves it in the new format, then I would not expect an older kicad to be able to read it. Wayne could even decide that every format-change implies a version number increment, so we can tell the user to install kicad newer than version x.y I also think, this is not something that will happen every day, so we should not overdesign this. Forward compatibility for a EDA tool is not something I would advice, as there are just to many things that can go wrong. If it makes things simples, an external file-format converter would also be fine. Just my 2 cents, Martijn - 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 ___ 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
Re: [Kicad-developers] The library tables wizard
Le 07/01/2015 23:38, Miguel Ángel Ajo a écrit : Hi Jean Pierre, just an idea for your wizard work: https://api.github.com/orgs/KiCad/repos You could save the need to work with the HTML viewer and pagination problems using the above API endpoint, all the KiCad project repositories are listed into it in json format. Best regards, Miguel Ángel Ajo Your advices are always golden. I added some enhancements to the fp lib table wizard: a button to import and display the full list of these .pretty libs on github (using this URL). * if the current select plugin is the github plugin, one can select some of these libraries and add them to the current table. * if the current select plugin is the kicad plugin, one can select some of these libraries and download them to make a local copy (which is the usual way of work) in corresponding .pretty folders. They can added later to the table after they are downloaded. Testers are welcome -- Jean-Pierre CHARRAS ___ 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] [Branch ~kicad-product-committers/kicad/product] Rev 5370: More work on fp lib table wizard: add a button to import the full list of .pretty libs on github.
Jean Pierre, amazing work, that was fast! Compiling, I want to see it in action :) Miguel Ángel Ajo On Thursday, 15 de January de 2015 at 21:03, nore...@launchpad.net wrote: revno: 5370 committer: jean-pierre charras jp.char...@wanadoo.fr (mailto:jp.char...@wanadoo.fr) branch nick: kicad timestamp: Thu 2015-01-15 21:01:53 +0100 message: More work on fp lib table wizard: add a button to import the full list of .pretty libs on github. * if the current select plugin is the github plugin, one can select some of these libraries and add them to the table * if the current select plugin is the kicad plugin, one can select some of these libraries and download them to make alocal copy. They can added to the table after they are downloaded. added: pcbnew/github/github_getliblist.cpp pcbnew/github/github_getliblist.h modified: common/common.cpp common/drawtxt.cpp common/eda_text.cpp common/html_messagebox.cpp cvpcb/dialogs/dialog_config_equfiles.cpp cvpcb/dialogs/dialog_config_equfiles.h cvpcb/dialogs/dialog_config_equfiles_base.cpp cvpcb/dialogs/dialog_config_equfiles_base.fbp cvpcb/dialogs/dialog_config_equfiles_base.h eeschema/sch_text.cpp include/common.h pcbnew/board_items_to_polygon_shape_transform.cpp pcbnew/dialogs/wizard_add_fplib.cpp pcbnew/dialogs/wizard_add_fplib.h pcbnew/dialogs/wizard_add_fplib_base.cpp pcbnew/dialogs/wizard_add_fplib_base.fbp pcbnew/dialogs/wizard_add_fplib_base.h pcbnew/exporters/export_vrml.cpp pcbnew/github/CMakeLists.txt pcbnew/github/github_plugin.cpp pcbnew/plot_brditems_plotter.cpp The size of the diff (1650 lines) is larger than your specified limit of 1000 lines -- lp:kicad https://code.launchpad.net/~kicad-product-committers/kicad/product You are subscribed to branch lp:kicad. To unsubscribe from this branch go to https://code.launchpad.net/~kicad-product-committers/kicad/product/+edit-subscription ___ 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] The library tables wizard
Hi Jean-Pierre To me it seems like you have a double semicolor on pcbnew/github/github_getliblist.cpp 104wxString urlPrefix = wxT( https://; ) + repo.GetServer() + wxT( / );; Aslo I geth the following error when trying to fetch. The problem is the two slashes before repos. I could not figure out where those two slashes come from, therefore I have not attached a patch. https GET command failed Cannot get/download json data from: 'https://api.github.com/orgs/KiCad//repos?per_page=99page=1' Reason: 'Not found' 2015-01-15 21:26 GMT+01:00 Miguel Ángel Ajo majop...@redhat.com: As I said on the other email, awesome :-) I’m glad my advice made any sense. And I like your idea of being able to make a local copy via the KiCad plugin, that’s very nice. Miguel Ángel Ajo On Thursday, 15 de January de 2015 at 21:10, jp charras wrote: Le 07/01/2015 23:38, Miguel Ángel Ajo a écrit : Hi Jean Pierre, just an idea for your wizard work: https://api.github.com/orgs/KiCad/repos You could save the need to work with the HTML viewer and pagination problems using the above API endpoint, all the KiCad project repositories are listed into it in json format. Best regards, Miguel Ángel Ajo Your advices are always golden. I added some enhancements to the fp lib table wizard: a button to import and display the full list of these .pretty libs on github (using this URL). * if the current select plugin is the github plugin, one can select some of these libraries and add them to the current table. * if the current select plugin is the kicad plugin, one can select some of these libraries and download them to make a local copy (which is the usual way of work) in corresponding .pretty folders. They can added later to the table after they are downloaded. Testers are welcome -- Jean-Pierre CHARRAS ___ 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 ___ 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] file version compatibility (optional tokens in s-expression files)
I was talking about Altium in my previous email, and I believe the points you made are quite reasonable (in favor and against). I also didn’t know about the measures of not saving the unchanged defaults, which are quite neat. What about a flag in the loader parameters, disabled by default, but which could be used via scripting for extreme situations (recovery of broken files?). Dumping warnings to stdout should be ok. Miguel Ángel Ajo On Thursday, 15 de January de 2015 at 21:37, Kaspar Emanuel wrote: My 2c: let the parser ignore unknown/incompatible s-expressions and warn the user when they are encountered. On 14 January 2015 at 22:24, Martijn Kuipers martijn.kuip...@gmail.com (mailto:martijn.kuip...@gmail.com) wrote: On 14 Jan 2015, at 21:07, Cirilo Bernardo cirilo.berna...@gmail.com (mailto:cirilo.berna...@gmail.com) wrote: On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski tomasz.wlostow...@cern.ch (mailto:tomasz.wlostow...@cern.ch) wrote: On 13.01.2015 20:11, Wayne Stambaugh wrote: This is a tricky issue that has been discussed before. The general consensus in the past has been not to support forward compatibility. It increases maintenance and complexity of the file parser for a minimal net gain to the user. My preference is to force users that want to bleed on the edge to use nightly builds rather than try to maintain any forward file compatibility. [snip] OK, how about this: - No extra version tokens (fits point A) - Warning instead of error on unrecognized tokens (point C - no big changes needed in the parser) - If the opened file is produced by a newer version of Kicad, issue a big warning when the user attempts to save it, that certain features will be lost (points B and D - if somebody complains we can always tell him he was warned). AFAIK this is what most commercial software does. Cheers, Tom Except for Acrobat Reader, all the other software I use simply tells me it cannot load the new file. In a corporate environment and especially on large projects no one wants to take the risk that someone obliterated some data. Let's say Person A sends Person B a file with data missing - what can Person B possibly do with that now? Person B was never aware of the warning that Person A ignored and the software is not psychic so it cannot say hey, the last time you worked on this file it was Version X.Z, not X.Y. The problem gets worse and more difficult to detect as the project gets more complex. People need to understand the limitations of their tools and work with that. As I said before people can negotiate what version they need and if necessary build/install to support a specific project. Otherwise why use file versions at all if we're essentially only using it to tell if there are newer features and essentially ignore it and write corrupted data anyway? I would be very happy with backward compatibility, especially if it would allow us to safe the file in the older format. This way, not everybody in the team needs to have the same version to be able to work. Of course, if someone saves it in the new format, then I would not expect an older kicad to be able to read it. Wayne could even decide that every format-change implies a version number increment, so we can tell the user to install kicad newer than version x.y I also think, this is not something that will happen every day, so we should not overdesign this. Forward compatibility for a EDA tool is not something I would advice, as there are just to many things that can go wrong. If it makes things simples, an external file-format converter would also be fine. Just my 2 cents, Martijn - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto: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 (mailto: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 (mailto: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 :
Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)
On 15.01.2015 23:40, Miguel Ángel Ajo wrote: I was talking about Altium in my previous email, and I believe the points you made are quite reasonable (in favor and against). Hi Miguel, Fully agree here. I also didn’t know about the measures of not saving the unchanged defaults, which are quite neat. Me neither. Did anybody propose to *not* save settings that are considered default by the current version? What if these defaults need to be changed (for whatever reason)? What about a flag in the loader parameters, disabled by default, but which could be used via scripting for extreme situations (recovery of broken files?). Dumping warnings to stdout should be ok. Fine for me. Cheers, Tom Miguel Ángel Ajo On Thursday, 15 de January de 2015 at 21:37, Kaspar Emanuel wrote: My 2c: let the parser ignore unknown/incompatible s-expressions and warn the user when they are encountered. On 14 January 2015 at 22:24, Martijn Kuipers martijn.kuip...@gmail.com (mailto:martijn.kuip...@gmail.com) wrote: On 14 Jan 2015, at 21:07, Cirilo Bernardo cirilo.berna...@gmail.com (mailto:cirilo.berna...@gmail.com) wrote: On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski tomasz.wlostow...@cern.ch (mailto:tomasz.wlostow...@cern.ch) wrote: On 13.01.2015 20:11, Wayne Stambaugh wrote: This is a tricky issue that has been discussed before. The general consensus in the past has been not to support forward compatibility. It increases maintenance and complexity of the file parser for a minimal net gain to the user. My preference is to force users that want to bleed on the edge to use nightly builds rather than try to maintain any forward file compatibility. [snip] OK, how about this: - No extra version tokens (fits point A) - Warning instead of error on unrecognized tokens (point C - no big changes needed in the parser) - If the opened file is produced by a newer version of Kicad, issue a big warning when the user attempts to save it, that certain features will be lost (points B and D - if somebody complains we can always tell him he was warned). AFAIK this is what most commercial software does. Cheers, Tom Except for Acrobat Reader, all the other software I use simply tells me it cannot load the new file. In a corporate environment and especially on large projects no one wants to take the risk that someone obliterated some data. Let's say Person A sends Person B a file with data missing - what can Person B possibly do with that now? Person B was never aware of the warning that Person A ignored and the software is not psychic so it cannot say hey, the last time you worked on this file it was Version X.Z, not X.Y. The problem gets worse and more difficult to detect as the project gets more complex. People need to understand the limitations of their tools and work with that. As I said before people can negotiate what version they need and if necessary build/install to support a specific project. Otherwise why use file versions at all if we're essentially only using it to tell if there are newer features and essentially ignore it and write corrupted data anyway? I would be very happy with backward compatibility, especially if it would allow us to safe the file in the older format. This way, not everybody in the team needs to have the same version to be able to work. Of course, if someone saves it in the new format, then I would not expect an older kicad to be able to read it. Wayne could even decide that every format-change implies a version number increment, so we can tell the user to install kicad newer than version x.y I also think, this is not something that will happen every day, so we should not overdesign this. Forward compatibility for a EDA tool is not something I would advice, as there are just to many things that can go wrong. If it makes things simples, an external file-format converter would also be fine. Just my 2 cents, Martijn - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto: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 (mailto: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 (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] two minor fixes
First patch fixes the Save library file as dialog which had the library extension instead of library extension wildcard used. Second patch fixes a null termination in eeschema/cross-probing.cpp. The char array line is in block scope and is never preinitialized to all 0s. There's also no guarantee for strncpy to actually copy null if size of bytes to read == buffer size passed. We need to set the last byte of line to NULL after strncpy as insurance. From 794636c7ff10ea98edd55b98457988196b66b3c6 Mon Sep 17 00:00:00 2001 From: Mark Roszko mark.ros...@gmail.com Date: Fri, 16 Jan 2015 00:43:11 -0500 Subject: [PATCH 1/2] Use the wildcard file extension in the library editor save as dialog --- eeschema/libedit.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eeschema/libedit.cpp b/eeschema/libedit.cpp index f9ed007..f474736 100644 --- a/eeschema/libedit.cpp +++ b/eeschema/libedit.cpp @@ -335,7 +335,7 @@ bool LIB_EDIT_FRAME::SaveActiveLibrary( bool newFile ) default_path = search-LastVisitedPath(); wxFileDialog dlg( this, _( Part Library Name: ), default_path, - wxEmptyString, SchematicLibraryFileExtension, + wxEmptyString, SchematicLibraryFileWildcard, wxFD_SAVE | wxFD_OVERWRITE_PROMPT ); if( dlg.ShowModal() == wxID_CANCEL ) -- 1.9.1 From 6ae28bfa50cc3588b1bdf99d4fc4d9e3c510190f Mon Sep 17 00:00:00 2001 From: Mark Roszko mark.ros...@gmail.com Date: Fri, 16 Jan 2015 01:24:29 -0500 Subject: [PATCH 2/2] Ensure null termination of c string after using strncpy because the line buffer is not preinitialized --- eeschema/cross-probing.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/eeschema/cross-probing.cpp b/eeschema/cross-probing.cpp index 59697b5..c22d546 100644 --- a/eeschema/cross-probing.cpp +++ b/eeschema/cross-probing.cpp @@ -62,6 +62,7 @@ void SCH_EDIT_FRAME::ExecuteRemoteCommand( const char* cmdline ) char line[1024]; strncpy( line, cmdline, sizeof(line) - 1 ); + line[ sizeof(line) - 1 ] = '\0'; char* idcmd = strtok( line, \n\r ); char* text = strtok( NULL, \\n\r ); -- 1.9.1 ___ 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] Boomerang with locale dependent entries in .kicad_pcb
2015-01-16 3:19 GMT+01:00 LordBlick lordbl...@gmail.com: In response to a message written on 16.01.2015, 01:38, from LordBlick: I just discovered that for some reason Pcbnew does not display complete zones in just designed project. Looking into project file: (layers - (0 Gorna jumper) - (31 Dolna signal) I find it strange that you have translated layer names here. I think that was banned/removed when Dick made the support for more layers. What KiCad did you originally create the file in? (32 B.Adhes user) (33 F.Adhes user) (34 B.Paste user) (35 F.Paste user) (36 B.SilkS user) (37 F.SilkS user) (38 B.Mask user) (39 F.Mask user) (40 Dwgs.User user) (41 Cmts.User user) (44 Edge.Cuts user) ) And then in pycrust: pcbnew.BOARD_GetStandardLayerName(0) u'F.Cu' pcbnew.BOARD_GetStandardLayerName(31) u'B.Cu' What can I do with this mess in file ? Same name are in Areas/Zone, which is IMHO incorrectly. translations are good in user interface, not in project files… Never mind, just test attachment. BTW. I've found, that in GAL mode additional intermediate points between area and subareas are displayed, which seems to be incorrect. See attached image. That does ineed look stange. Seems to me like zones are connected with an edge. ___ 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] The library tables wizard
Ahh, I just found the place. I have attached a patch that removed the extra slash and the extra semicolon. This interface looks much nicer to choose from instead of the browser window. :) Also, on the same dialog/form as the Github Libs List the button called Add FP Library entry does nothing. 2015-01-15 22:50 GMT+01:00 Nick Østergaard oe.n...@gmail.com: Hi Jean-Pierre To me it seems like you have a double semicolor on pcbnew/github/github_getliblist.cpp 104wxString urlPrefix = wxT( https://; ) + repo.GetServer() + wxT( / );; Aslo I geth the following error when trying to fetch. The problem is the two slashes before repos. I could not figure out where those two slashes come from, therefore I have not attached a patch. https GET command failed Cannot get/download json data from: 'https://api.github.com/orgs/KiCad//repos?per_page=99page=1' Reason: 'Not found' 2015-01-15 21:26 GMT+01:00 Miguel Ángel Ajo majop...@redhat.com: As I said on the other email, awesome :-) I’m glad my advice made any sense. And I like your idea of being able to make a local copy via the KiCad plugin, that’s very nice. Miguel Ángel Ajo On Thursday, 15 de January de 2015 at 21:10, jp charras wrote: Le 07/01/2015 23:38, Miguel Ángel Ajo a écrit : Hi Jean Pierre, just an idea for your wizard work: https://api.github.com/orgs/KiCad/repos You could save the need to work with the HTML viewer and pagination problems using the above API endpoint, all the KiCad project repositories are listed into it in json format. Best regards, Miguel Ángel Ajo Your advices are always golden. I added some enhancements to the fp lib table wizard: a button to import and display the full list of these .pretty libs on github (using this URL). * if the current select plugin is the github plugin, one can select some of these libraries and add them to the current table. * if the current select plugin is the kicad plugin, one can select some of these libraries and download them to make a local copy (which is the usual way of work) in corresponding .pretty folders. They can added later to the table after they are downloaded. Testers are welcome -- Jean-Pierre CHARRAS ___ 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 fp-tab-wiz-slash.patch Description: plain/text ___ 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] Boomerang with locale dependent entries in .kicad_pcb
I just discovered that for some reason Pcbnew does not display complete zones in just designed project. Looking into project file: (layers - (0 Gorna jumper) - (31 Dolna signal) (32 B.Adhes user) (33 F.Adhes user) (34 B.Paste user) (35 F.Paste user) (36 B.SilkS user) (37 F.SilkS user) (38 B.Mask user) (39 F.Mask user) (40 Dwgs.User user) (41 Cmts.User user) (44 Edge.Cuts user) ) And then in pycrust: pcbnew.BOARD_GetStandardLayerName(0) u'F.Cu' pcbnew.BOARD_GetStandardLayerName(31) u'B.Cu' What can I do with this mess in file ? Same name are in Areas/Zone, which is IMHO incorrectly. translations are good in user interface, not in project files… -- Best Regards, LordBlick ___ 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] Boomerang with locale dependent entries in .kicad_pcb
In response to a message written on 16.01.2015, 01:38, from LordBlick: I just discovered that for some reason Pcbnew does not display complete zones in just designed project. Looking into project file: (layers - (0 Gorna jumper) - (31 Dolna signal) (32 B.Adhes user) (33 F.Adhes user) (34 B.Paste user) (35 F.Paste user) (36 B.SilkS user) (37 F.SilkS user) (38 B.Mask user) (39 F.Mask user) (40 Dwgs.User user) (41 Cmts.User user) (44 Edge.Cuts user) ) And then in pycrust: pcbnew.BOARD_GetStandardLayerName(0) u'F.Cu' pcbnew.BOARD_GetStandardLayerName(31) u'B.Cu' What can I do with this mess in file ? Same name are in Areas/Zone, which is IMHO incorrectly. translations are good in user interface, not in project files… Never mind, just test attachment. BTW. I've found, that in GAL mode additional intermediate points between area and subareas are displayed, which seems to be incorrect. See attached image. -- Best Regards, LordBlick (kicad_pcb (version 4) (host pcbnew (2014-jul-16 BZR unknown)-BZR5369) (general (links 75) (no_connects 39) (area 24.510999 25.018999 146.177001 109.347001) (thickness 1.6002) (drawings 7) (tracks 75) (zones 0) (modules 39) (nets 31) ) (page A4) (title_block (title Vacum fitness device additional outputs) (date 11 sep 2013) (rev 1) (company LTTech.com.pl) ) (layers (0 Top jumper) (31 Bottom signal) (32 B.Adhes user) (33 F.Adhes user) (34 B.Paste user) (35 F.Paste user) (36 B.SilkS user) (37 F.SilkS user) (38 B.Mask user) (39 F.Mask user) (40 Dwgs.User user) (41 Cmts.User user) (44 Edge.Cuts user) ) (setup (last_trace_width 0.762) (user_trace_width 0.635) (user_trace_width 0.762) (user_trace_width 0.762) (user_trace_width 1.016) (user_trace_width 1.016) (user_trace_width 1.27) (user_trace_width 1.778) (user_trace_width 2.032) (user_trace_width 2.286) (user_trace_width 2.54) (user_trace_width 3.048) (user_trace_width 3.81) (trace_clearance 0.03048) (zone_clearance 0.254) (zone_45_only no) (trace_min 0.2032) (segment_width 0.127) (edge_width 0.127) (via_size 1.524) (via_drill 0.8128) (via_min_size 0.889) (via_min_drill 0.508) (user_via 1.397 0.8128) (user_via 1.397 0.8128) (uvia_size 0.508) (uvia_drill 0.127) (uvias_allowed no) (uvia_min_size 0.508) (uvia_min_drill 0.127) (pcb_text_width 0.3048) (pcb_text_size 1.524 2.032) (mod_edge_width 0.254) (mod_text_size 1.524 1.524) (mod_text_width 0.3048) (pad_size 0.762 1.524) (pad_drill 0) (pad_to_mask_clearance 0.127) (aux_axis_origin 25.4 25.4) (grid_origin 25.4 25.4) (visible_elements FF7F) (pcbplotparams (layerselection 0x00064_8000) (usegerberextensions true) (excludeedgelayer true) (linewidth 0.15) (plotframeref false) (viasonmask false) (mode 1) (useauxorigin true) (hpglpennumber 1) (hpglpenspeed 20) (hpglpendiameter 15) (hpglpenoverlay 0) (psnegative false) (psa4output false) (plotreference true) (plotvalue true) (plotinvisibletext false) (padsonsilk false) (subtractmaskfromsilk true) (outputformat 1) (mirror false) (drillshape 0) (scaleselection 1) (outputdirectory gerberAndDrill/)) ) (net 0 ) (net 1 /12V) (net 2 /BP) (net 3 /GND) (net 4 /HVD) (net 5 /HVS) (net 6 /OI1-A) (net 7 /OI1-K) (net 8 /SNB-C) (net 9 /V5) (net 10 5V) (net 11 /UV1) (net 12 /UV2) (net 13 /UV3) (net 14 /UV4) (net 15 /UV5) (net 16 /UV6) (net 17 /UV7) (net 18 /V12) (net 19 /V5I) (net 20 /V12I) (net 21 GND) (net 22 HVD) (net 23 V5I) (net 24 TPD) (net 25 EN) (net 26 /V3I) (net 27 V12I) (net 28 /V5B) (net 29 /431-G) (net 30 /BP_TinyII) (net_class Default To jest domyślna klasa połączeń. (clearance 0.03048) (trace_width 0.508) (via_dia 1.524) (via_drill 0.8128) (uvia_dia 0.508) (uvia_drill 0.127) (add_net /12V) (add_net /431-G) (add_net /BP) (add_net /BP_TinyII) (add_net /HVS) (add_net /OI1-A) (add_net /OI1-K) (add_net /SNB-C) (add_net /UV1) (add_net /UV2) (add_net /UV3) (add_net /UV4) (add_net /UV5) (add_net /UV6) (add_net /UV7) (add_net /V12) (add_net /V3I) (add_net /V5) (add_net /V5B) (add_net 5V) (add_net EN) (add_net GND) (add_net HVD) (add_net TPD) (add_net V12I) (add_net V5I) ) (net_class TinyLine (clearance 0.03048) (trace_width 0.254) (via_dia 1.016) (via_drill 0.508) (uvia_dia 0.508) (uvia_drill 0.127) ) (module Pad-5.0D3.2 locked (layer Top) (tedit 548F7C3B) (tstamp 54783ED4) (at 129.8956 34.671 90) (descr One
