Re: [Kicad-developers] unable to compile masrer HEAD
On 2/23/20 6:36 PM, Jon Evans wrote: https://gitlab.com/kicad/code/kicad/-/merge_requests/113 @Sergey -- are you able to build with BUILD_GITHUB_PLUGIN=ON for now? Yes, I am. Hope you'll fix BUILD_GITHUB_PLUGIN=OFF soon. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] unable to compile masrer HEAD
clean build with build settings KICAD_SCRIPTING=OFF KICAD_SCRIPTING_MODULES=OFF KICAD_SCRIPTING_PYTHON3=OFF KICAD_SCRIPTING_WXPYTHON=OFF KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF KICAD_SCRIPTING_ACTION_MENU=OFF BUILD_GITHUB_PLUGIN=OFF KICAD_USE_OCE=OFF KICAD_USE_OCC=OFF KICAD_SPICE=ON was ok month ago. Today I got dialog_about.cpp:(.text+0x234e): undefined reference to `KICAD_CURL_EASY::KICAD_CURL_EASY()' what am I doing wrong? -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Ratsnest options
On 14.06.2019 2:06, Reece R. Pollack wrote: Jon, May I suggest making the net and net class listings two different tabs? I'd rather not have to scroll past a few hundred nets to get to the net class listing. Or two scroll areas on the same tab, though I think separate tabs would be better. Or, possibly, represent list as a tree view (classes->nets) with ability to expand/collapse every netclass? Are nets hierarchical by the time they get to Pcbnew, or have they been flattened to a single namespace? -Reece On 6/13/19 4:05 PM, Jon Evans wrote: I will let you know once it's a bit farther along. There will be a live filter (fuzzy matching) to make it easier to find things. On Thu, Jun 13, 2019 at 4:04 PM Reece Pollack <mailto:re...@his.com>> wrote: Jon, that looks great! How well does that model work when there are hundreds of nets rather than six? -Reece *From: *"Jon Evans" mailto:j...@craftyjon.com>> *To: *"reece" mailto:re...@his.com>> *Cc: *"KiCad Developers" mailto:kicad-developers@lists.launchpad.net>> *Sent: *Thursday, June 13, 2019 2:07:07 PM *Subject: *Re: [Kicad-developers] Ratsnest options It's coming, Reece! (obvious disclaimer: this is a mockup and doesn't represent final UI, etc etc) image.png On Thu, Jun 13, 2019 at 2:03 PM Reece Pollack mailto:re...@his.com>> wrote: For myself, I see no value to having the Ratsnest on/off in the View menu or in Preferences. Having it in the left toolbar as well as the Layers widget is duplicative but convenient. What would seriously reduce my use of the Ratsnest show/hide function is the ability to limit what nets appear in the ratsnest. I'd guess about 1/4th to 1/3rd of the ratsnest in my designs is GND. These eventually get connected to internal planes through vias, and seeing these airwires all over the place is just visual noise. Other big offenders are the various power nets (+3V3, +1V2, etc.) which I'd often prefer to hide. Eagle supports showing/hiding nets by name via the command line, and KiCad needs a similar capability. I seem to recall this being on the roadmap though I could be mistaken. Thinking it through a bit more, it might be more valuable to allow hiding/showing by net class rather than by name. This would make it easier to navigate in a GUI as there would be fewer net classes than nets, and this would group similar nets together. -Reece ___ 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 -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Atomic Libraries Proposal
Hi Seth.
On 24.05.2019 16:13, Seth Hillbrand wrote:
Am 2019-05-24 02:36, schrieb Sergey A. Borshch:
Major limitation is that your proposal still does not provide mapping
between symbol pins and footprints pins, so user has to keep separate
footprints for, say, sot23 bipolar, FET, Zenner and IC which differ in
pins names only.
Hi Sergey-
Can you say more about why you would need a separate footprint for different pin
names? I don't quite understand that point.
Bipolar transistors has at least two common pins assignments, so you has to have
at least two symbols with pins numbered {1, 2, 3} and {2 1 3} or at least two
footprints with pins numbered {E, C, B} and {E, B, C}.
If your component has some pins connected together as, say, 78Lxx in SOIC8
package and you want to have same symbol for 78Lxx in all packages, you has to
keep separate SOIC8 footprint with pins 1,2,2,4,5,2,2,8.
ACCEL EDA has pins mapping (including common pins across units, gates and pins
equivalence) in 1995, it's curious that Kicad has no such feature 25 years later.
--
Regards,
Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia
___
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] Atomic Libraries Proposal
On 23.05.2019 22:41, Seth Hillbrand wrote: The major limitations of the specification are: ... - The atomic library does not contain symbol or footprint data It's not a limitation, i's a great benefit - you can use same single footprint/symbol file to many components and fix it in one place without need to remember which other components use same symbol/footprint Major limitation is that your proposal still does not provide mapping between symbol pins and footprints pins, so user has to keep separate footprints for, say, sot23 bipolar, FET, Zenner and IC which differ in pins names only. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] [eeschema/question] use mouse position instead of custom position for selecting objects?
On 22.03.2019 01:41, Tomasz Wlostowski wrote: Is there a chance there's a regression in V5/V5.1? If so, I'm willing to fix this. Does it need to be a regression to be fixed? -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Netlist generation for pins with no-connects
On 05.06.2018 16:54, Jon Evans wrote: it seems a bit like there ought to be a better way to support those needs Indeed. but I understand and will maintain that behavior. Can you also try to fix bug 1704083 caused by assigning different net names to unconnected instances of shared pins in every gate (unit). On Tue, Jun 5, 2018 at 2:50 AM, jp charras <mailto:jp.char...@wanadoo.fr>> wrote: Le 05/06/2018 à 04:38, Jon Evans a écrit : > Hi all, > > In the current netlisting algorithm, pins with no-connects sometimes appear in the netlist, with > auto-generated names like Net-(U1-Pad1). > > This seems to not always happen, but I haven't investigated why yet, since I'm approaching > netlisting from a different direction with my new connectivity algorithm. In my algorithm, a pin > with a no-connect attached will never generate an entry in the netlist. > > Is there some reason we should be including these pins on the netlist? It seems like if they are > marked as no-connects and don't actually connect to anything, we shouldn't be forwarding them to the > layout. > > -Jon > We *should* forward them to the layout. This is the best way to detect if the footprint has missing pads (incorrect footprint choice) -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers> Post to : kicad-developers@lists.launchpad.net <mailto:kicad-developers@lists.launchpad.net> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers> More help : https://help.launchpad.net/ListHelp <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 -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Indeterministic netlist export for multiunit components
On 18.05.2018 11:14, Maciej Sumiński wrote: Hi, Recently I have found out that the netlist exporter uses an algorithm that for multiunit components uses non empty field values from the last processed unit [1]. The problem is that the processing order depends on the order of the units in the item list, so completely random. I want to remind that there is another bug in netlist generator related to units processing order: https://bugs.launchpad.net/bugs/1704083 Instead, I propose we try to get all field values from the first available unit (e.g. unit A), and resort to other units only if there are any fields left empty. > To give an example of what can go wrong with such approach: recently I generated BOM and assembly documentation, where unit A had 'Mounted' field set to 'No'. I was surprised to find out that in the generated output it has been marked as mounted, as the unit B had 'Yes' set for the field. I would qualify it as a bug, but I seek your input before I proceed with pushing my changes. See my proposal in the attached patch. I think there no need in Artificial Intelligence while generating netlist from incorrect schematics, but all fields in component units must be consistent instead. I mean that changing in schematics editor any field in one unit must also change same field in other units with same RefDes. Automatic annotation must take into account all fields values and assign different RefDes to units which differs with fields values. One more proposal - manual RefDes change shoud not be allowed with appropriate warning if unit(s) with new RefDes already exist in schematics and belongs to another component type or has different fields value(s). It would be best helpful if warning message will show that units belongs to different component types or which field value differs if component type is the same. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] rc2
On 03.04.2018 01:42, Wayne Stambaugh wrote: Are there any other outstanding issues we need to fix before rc2 is tagged? https://bugs.launchpad.net/kicad/+bug/1678849 Today is one year since bug reported: opening eeschema in standalone mode ignores page layout description file setting. Changing any preference stored in project file causes page layout description file setting to get lost from project. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] [PATCH] Don't draw invisible pins in component chooser
On 07.02.2018 17:14, Wayne Stambaugh wrote: Hey Orson, Thanks for the response. I agree with your concern about hidden pins but they are hidden in the schematic editor so I'm not sure it makes sense to show them. It may be confusing to users when they see the hidden pins in the symbol chooser and then they mysteriously disappear when they place them in the schematic editor. Proposal: do not show hidden pins in component chooser, but write "This symbol has invisible pins" in eye-pain red somewhere below symbol image. Optionally show "Details" button, which opens dialog or expands some area with all hidden pins info: pin numbers, net names, numbers an names of visible pins at same locations etc. Developers know what the invisible pins denote but is this clear to most users? I comfortable either way, I'm just trying to get a handle on this from a typical user's point of view. Anyone else have a strong opinion on this? Cheers, Wayne On 2/7/2018 8:29 AM, Maciej Sumiński wrote: Hi Wayne, No, I have not reviewed the patch. I had some doubts about potential problems caused by invisible pins creating hidden connections. If user is neither aware of their presence when selecting a symbol, nor will notice them after they are placed on a schematic sheet then he may end up accidentally connecting them to some wires. IIRC we do not have an ERC test to check against such case, so I was not sure if it is a safe change. Cheers, Orson On 02/07/2018 02:21 PM, Wayne Stambaugh wrote: Orson, Did you ever respond to Jon about this? I guess the question is whether or not to show invisible pins in the component chooser. Cheers, Wayne On 1/15/2018 9:31 PM, Jon Evans wrote: Hi Orson, patch is attached again, hopefully it goes through this time. Thanks, Jon On Mon, Jan 15, 2018 at 4:24 AM, Rene Pöschl mailto:poesc...@gmail.com>> wrote: On 15/01/18 10:00, Maciej Sumiński wrote: Perhaps we should have an ERC rule that warns about invisible pins being connected to a wire, any thoughts? Invisible pins are used for three distinct applications. The first one is to remove clutter by hiding pins that should not be connected. ERC will complain if you connect such pins if they have the electrical type "Not connected". The second application is to create "power labels". A invisible power input pin is handled as a global label. These pins are meant to be connected. The third application is again to remove clutter by stacking pins. Here you have one visible pin and several other invisible pins at the same location. (Normally all these pins have the same name and electrical type. With the exception of power input pins, power output pins and output pins.) Such pins are again meant to be connected. This means a ERC rule that complains about connecting hidden pins will create too many false positives. Having a lot of false positives means users will start to ignore ERC output. It might be a good idea to have a symbol checker that complains if invisible pins are used differently than i described above. In other words: complain for invisible pins if they are not part of a stack or of types NC or power input. ___ Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers> Post to : kicad-developers@lists.launchpad.net <mailto:kicad-developers@lists.launchpad.net> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers> More help : https://help.launchpad.net/ListHelp <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 ___ 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 -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI lt
Re: [Kicad-developers] Run-time expression eval in text fields
On 17.01.2018 20:49, Jeff Young wrote: Hi Wayne, But even for 6, does this issue warrant it? Having an expression evaluator would remove the need. First, I vote for %R and %V to be consistent with footprints. Secondary, it's not that simple as it seems. Sometimes I change RefDes on schematics by double-click on field and entering new value. If it will be a substituted text field, RefDes of that particular unit must change accordinary after tex field editing done. (Mind you, it would still be overkill for this issue if the expression evaluator didn’t have other uses. That was the reason for my query.) Cheers, Jeff. On 17 Jan 2018, at 18:31, Wayne Stambaugh wrote: Jeff, Adding separate field locations for each symbol unit requires a symbol library file format change which is going to happen after v5 is released. Please do not change any of this code because it will just get replaced when this occurs. Cheers, Wayne On 1/17/2018 12:27 PM, Jeff Young wrote: There’s a bug[1] that complains that the user can’t reposition a reference or value differently for different units that might be different sizes. (You can do this on the eeschema canvas, but not in the library, so you have to do it each time you use one of the units.) It occurred to me that one could accomplish this using existing stuff if we had a (very simple) evaluator for text fields at runtime. They could then add a text field to their units (marked shared-between-units or not as required), and set the value to something like “%REF” or “%VALUE”. The expression evaluator could even be as simple as doing those two replacements, or maybe looking up any field value or something. Anyway, I’m not sure this issue warrants it, but if it had other uses it might be worth doing (whereas adding separate REF and VALUE fields per unit and giving them shared-between-units flags, etc., would be more work than this bug probably warrants). Thoughts? [1] https://bugs.launchpad.net/kicad/+bug/1334502 ___ 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 -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Python: time_t needs mapping; tentative patch
On 28.11.2017 14:55, Wayne Stambaugh wrote: On 11/28/2017 4:01 AM, Maciej Sumiński wrote: I suppose the most elegant solution would be to change time_t in KiCad source code to uint64_t. This leaves no ambiguity and should be easy to handle with swig. Time stamps are only saved and loaded as 32 bit values so I'm not sure unint64_t makes sense. Is it a good time to resolve ambiguity and introduce new typedef or class "timestamp_t"? -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] GAL canvas behavior.
On 21.07.2017 11:26, Lorenzo Marcantonio wrote:
It seems to me that most of the features (that I use, at least) from legacy are
fine on GAL.
I didn't find next features I often use in "route tracks" mode:
1) Delete last segment while placing track ("Backspace" key in Legacy)
2) Move segment node ("M" key in legacy)
--
Regards,
Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia
___
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] netlist inconsistency
As noone responded in three days I filled bug report about wrong netlist generation: https://bugs.launchpad.net/kicad/+bug/1704083 On 10.07.2017 11:27, Sergey A. Borshch wrote: Hello developers. I found that netlist generation has changed last year or so. My two years old project got connection errors after re-generating and re-loading netlist. This project was successfully (without any errors) created and routed two years ago. The problem is in multi-gate components, which has some pins common to two or more gates. It can be two buffers with common Enable pin, four diodes with common anode pin or (in my case) MCU with all GPIOs shown in one gate while same pins acting as USART I/Os shown in another. Two years ago all wires connected to those common pins in different gates had the same net name e.g. was connected together as it takes place on PCB - all routes to same pin had same net name. I suppose this behaviour was correct one. Today's kicad netlist generator assigns separate net to every pin occurrence in gates. And at netlist loading phase only first pin occurrence is taken into account while all other connections to same pin in other gates _silently_ ignored, e.g. pin connection depends on gate numbering in package or even gates location on schematics sheet and it's edit order in time. I think this behavour is not the correct one. Any complaints? I'll try to show it using four Zenner diodes in sot23-5 package (ESDA6v1-SC5) has common anode on pin 2 and cathodes on pins 1,3,4,5. Here is component description from netlist: (libpart (lib discrete) (part ESDAxx-SC5-V) (fields (field (name Reference) VD) (field (name Value) ESDAxx-SC5-V) (field (name Footprint) TSOP-5)) (pins (pin (num 1) (name K) (type passive)) (pin (num 2) (name A) (type passive)) (pin (num 3) (name K) (type passive)) (pin (num 4) (name K) (type passive)) (pin (num 5) (name K) (type passive) Here is netlist generated from simple schematics (four zenner gates with GND power component connected to pin 2 on gate C, see attachment sch1): (nets (net (code 1) (name GND) (node (ref VD1) (pin 2))) (net (code 2) (name "Net-(VD1-Pad1)") (node (ref VD1) (pin 1))) (net (code 3) (name "Net-(VD1-Pad2)") (node (ref VD1) (pin 2))) (net (code 4) (name "Net-(VD1-Pad3)") (node (ref VD1) (pin 3))) (net (code 5) (name "Net-(VD1-Pad2)") (node (ref VD1) (pin 2))) (net (code 6) (name "Net-(VD1-Pad4)") (node (ref VD1) (pin 4))) (net (code 7) (name "Net-(VD1-Pad2)") (node (ref VD1) (pin 2))) (net (code 8) (name "Net-(VD1-Pad5)") (node (ref VD1) (pin 5) As you can see, there is four nets (code 1, 3, 5, 7) belongs to VD1 pin 2. After this netlist loading into PCB pin 2 will be connected to GND net. Here is netlist generated from previous schematics with pin 2 on gates A and B connected together (attachment sch2): (nets (net (code 1) (name "Net-(VD1-Pad2)") (node (ref VD1) (pin 2)) (node (ref VD1) (pin 2))) (net (code 2) (name "Net-(VD1-Pad1)") (node (ref VD1) (pin 1))) (net (code 3) (name "Net-(VD1-Pad3)") (node (ref VD1) (pin 3))) (net (code 4) (name GND) (node (ref VD1) (pin 2))) (net (code 5) (name "Net-(VD1-Pad4)") (node (ref VD1) (pin 4))) (net (code 6) (name "Net-(VD1-Pad2)") (node (ref VD1) (pin 2))) (net (code 7) (name "Net-(VD1-Pad5)") (node (ref VD1) (pin 5) As you can see, there is three nets (code 1, 4, 6) belongs to VD1 pin 2 and after this netlist loading into PCB pin 2 will be connected to net "Net-(VD1-Pad2)" and connection to GND will be dropped silently. Which one behaviour is correct from developers point of view? Should I fill bug report to revert netlist generation to old behaviour or should I fill feature request to generate error message (and rise DRC error) if two unnamed nets connected to same pin in different gates and one of the connection will be dropped at netlist loading? -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] netlist inconsistency
Hello developers. I found that netlist generation has changed last year or so. My two years old project got connection errors after re-generating and re-loading netlist. This project was successfully (without any errors) created and routed two years ago. The problem is in multi-gate components, which has some pins common to two or more gates. It can be two buffers with common Enable pin, four diodes with common anode pin or (in my case) MCU with all GPIOs shown in one gate while same pins acting as USART I/Os shown in another. Two years ago all wires connected to those common pins in different gates had the same net name e.g. was connected together as it takes place on PCB - all routes to same pin had same net name. I suppose this behaviour was correct one. Today's kicad netlist generator assigns separate net to every pin occurrence in gates. And at netlist loading phase only first pin occurrence is taken into account while all other connections to same pin in other gates _silently_ ignored, e.g. pin connection depends on gate numbering in package or even gates location on schematics sheet and it's edit order in time. I think this behavour is not the correct one. Any complaints? I'll try to show it using four Zenner diodes in sot23-5 package (ESDA6v1-SC5) has common anode on pin 2 and cathodes on pins 1,3,4,5. Here is component description from netlist: (libpart (lib discrete) (part ESDAxx-SC5-V) (fields (field (name Reference) VD) (field (name Value) ESDAxx-SC5-V) (field (name Footprint) TSOP-5)) (pins (pin (num 1) (name K) (type passive)) (pin (num 2) (name A) (type passive)) (pin (num 3) (name K) (type passive)) (pin (num 4) (name K) (type passive)) (pin (num 5) (name K) (type passive) Here is netlist generated from simple schematics (four zenner gates with GND power component connected to pin 2 on gate C, see attachment sch1): (nets (net (code 1) (name GND) (node (ref VD1) (pin 2))) (net (code 2) (name "Net-(VD1-Pad1)") (node (ref VD1) (pin 1))) (net (code 3) (name "Net-(VD1-Pad2)") (node (ref VD1) (pin 2))) (net (code 4) (name "Net-(VD1-Pad3)") (node (ref VD1) (pin 3))) (net (code 5) (name "Net-(VD1-Pad2)") (node (ref VD1) (pin 2))) (net (code 6) (name "Net-(VD1-Pad4)") (node (ref VD1) (pin 4))) (net (code 7) (name "Net-(VD1-Pad2)") (node (ref VD1) (pin 2))) (net (code 8) (name "Net-(VD1-Pad5)") (node (ref VD1) (pin 5) As you can see, there is four nets (code 1, 3, 5, 7) belongs to VD1 pin 2. After this netlist loading into PCB pin 2 will be connected to GND net. Here is netlist generated from previous schematics with pin 2 on gates A and B connected together (attachment sch2): (nets (net (code 1) (name "Net-(VD1-Pad2)") (node (ref VD1) (pin 2)) (node (ref VD1) (pin 2))) (net (code 2) (name "Net-(VD1-Pad1)") (node (ref VD1) (pin 1))) (net (code 3) (name "Net-(VD1-Pad3)") (node (ref VD1) (pin 3))) (net (code 4) (name GND) (node (ref VD1) (pin 2))) (net (code 5) (name "Net-(VD1-Pad4)") (node (ref VD1) (pin 4))) (net (code 6) (name "Net-(VD1-Pad2)") (node (ref VD1) (pin 2))) (net (code 7) (name "Net-(VD1-Pad5)") (node (ref VD1) (pin 5) As you can see, there is three nets (code 1, 4, 6) belongs to VD1 pin 2 and after this netlist loading into PCB pin 2 will be connected to net "Net-(VD1-Pad2)" and connection to GND will be dropped silently. Which one behaviour is correct from developers point of view? Should I fill bug report to revert netlist generation to old behaviour or should I fill feature request to generate error message (and rise DRC error) if two unnamed nets connected to same pin in different gates and one of the connection will be dropped at netlist loading? -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Patch: Open Datasheet in Project Dir
On 31.05.2017 10:57, Cheng Sheng wrote:
So is there any conclusion on this patch like it will be accepted or rejected or
needs some improvement?
Sergey, are you a patch reviewer who can commit to the repo, or I need to add
someone explicitly? Thanks.
No, I'm just a user who wanted to share it's point of view.
Regards,
Cheng
On May 29, 2017 12:33 PM, "Cheng Sheng" <mailto:jeru.sh...@gmail.com>> wrote:
On 29 May 2017 at 09:40, Sergey A. Borshch mailto:sb...@users.sourceforge.net>> wrote:
On 28.05.2017 23:49, Cheng Sheng wrote:
I myself prefer storing all files specific to the project within the
project directory, including datasheets, components, adjusted
footprints and scripts. This way makes things easier when I copy the
project around. After all, I don't mind disk space waste on a few
duplicated datasheets; they don't take much space.
Ok, what is your workflow? You choose component, pick it from library
into schematics and then manually copy it's datasheet (from where?) into
the project folder to make it available from schematics?
I'm not a professional on electronics so I don't (want/bother to) maintain a
centralized collection of datasheets. Instead, when I select components, I
do parametric search on digikey/mouser/whatever, then check datasheets on
the website, download to project dir if chosen.
I have my library and my project both under version control system, so I
use latest, exactly the same (with all latest error fixes) library and
latest, most actual datasheets in every project. But I always can easily
revert library repository to state it was when project was finished.
I admire your patience and professionalism. I see your spirit to reuse as
many things as possible. Shared library has its reuse benefit. Of course,
also has its downsides. Eg., I don't necessarily remember how the shared
libraries are setup one year after I finish a project or after I move to a
new machine. So I prefer each project to be as self-containing as possible.
Of course, putting everything inside the project also has its downsides,
maybe even more than your proposed shared library approach. But I suppose
this is just personal preferences. Unless there's a strong reason why my
personal preference is terrible (that it is worse than a "standard approach"
in ALL aspects) or by following this preference my patch makes the software
terrible, it shouldn't be forbidden, right?
There is "Archive library" option in eeschema File menu, which extract
from library all components used in project. It can be extended to
extract datasheets as well if it doesn't do it right now.
hm... Am I missing some compile options? I don't see such an option in
eevschema. Instead, only an "Archive Current Project" item in the project
window.
Anyway, even if datasheet extraction is added to "Archive library", you'll
still need a way to open a relative datasheet unless the archiving leaves an
absolute path (which seems unlikely the case, by guessing).
If the direction of move by the patch makes some other workflow
styles harder to optimize in the future, please let me know. I don't
mind alternative proposals that can fulfill more workflow types.
What I wrote is just a "shortest-path" I can see based on my own
workflow.
Regards,
Cheng
On 28 May 2017 at 20:53, Ingo Kletti mailto:ikle...@htwg-konstanz.de> <mailto:ikle...@htwg-konstanz.de
<mailto:ikle...@htwg-konstanz.de>>> wrote:
Am 28.05.2017 um 18:47 schrieb Sergey A. Borshch:
On 28.05.2017 14:35, Cheng Sheng wrote:
So I made a patch to resolve the path before it is
passed to
"wxLaunchDefaultBrowser()". If it looks like a URL or
is an absolute
path, doesn't do anything; but if it is a relative
path, append
"${KIPRJMOD}" to it.
Are you storing all datasheets in every project? I think
it's better to
keep one copy per library, so path must be relative to
library location.
Don't know about the OP, but from past experience it is wise to
store the
datasheet for the different components tpgether with the
project files. That
way you always have the specs available that your design is
based on.
Re: [Kicad-developers] Patch: Open Datasheet in Project Dir
On 28.05.2017 23:49, Cheng Sheng wrote:
I myself prefer storing all files specific to the project within the project
directory, including datasheets, components, adjusted footprints and scripts.
This way makes things easier when I copy the project around. After all, I don't
mind disk space waste on a few duplicated datasheets; they don't take much space.
Ok, what is your workflow? You choose component, pick it from library into
schematics and then manually copy it's datasheet (from where?) into the project
folder to make it available from schematics?
I have my library and my project both under version control system, so I use
latest, exactly the same (with all latest error fixes) library and latest, most
actual datasheets in every project. But I always can easily revert library
repository to state it was when project was finished.
There is "Archive library" option in eeschema File menu, which extract from
library all components used in project. It can be extended to extract datasheets
as well if it doesn't do it right now.
If the direction of move by the patch makes some other workflow styles harder to
optimize in the future, please let me know. I don't mind alternative proposals
that can fulfill more workflow types. What I wrote is just a "shortest-path" I
can see based on my own workflow.
Regards,
Cheng
On 28 May 2017 at 20:53, Ingo Kletti <mailto:ikle...@htwg-konstanz.de>> wrote:
Am 28.05.2017 um 18:47 schrieb Sergey A. Borshch:
On 28.05.2017 14:35, Cheng Sheng wrote:
So I made a patch to resolve the path before it is passed to
"wxLaunchDefaultBrowser()". If it looks like a URL or is an absolute
path, doesn't do anything; but if it is a relative path, append
"${KIPRJMOD}" to it.
Are you storing all datasheets in every project? I think it's better to
keep one copy per library, so path must be relative to library location.
Don't know about the OP, but from past experience it is wise to store the
datasheet for the different components tpgether with the project files. That
way you always have the specs available that your design is based on.
So a relative path makes sense depending on the use case and workflow.
Regards,
Ingo
--
Regards,
Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia
___
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] Patch: Open Datasheet in Project Dir
On 28.05.2017 14:35, Cheng Sheng wrote:
So I made a patch to resolve the path before it is passed to
"wxLaunchDefaultBrowser()". If it looks like a URL or is an absolute path,
doesn't do anything; but if it is a relative path, append "${KIPRJMOD}" to it.
Are you storing all datasheets in every project? I think it's better to keep one
copy per library, so path must be relative to library location.
--
Regards,
Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia
___
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] PATCH: Fix default line widths for non-mm units in DXF import
On 26.05.2017 05:10, Cirilo Bernardo wrote: Fortunately there are not many lines that need to be changed and they all follow the same formula. Isn't it a good chance to wrap this formula into (inline) function? Next programmer can be not so pedant as you to find all formula occurrences solving next bug. This can make sources a little bit more clean. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] [RFC] Strange libedit behaviour
On 07.03.2017 15:07, Oliver Walters wrote: As an extra note to Example B in the above comment, deleting a pin also deletes any pins in other units (for multi-unit symbols) that are in the same location. This bug appears again and again every year or two. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] [PATCH] Assertion in pcbnew/dialogs/dialog_select_net_from_list.cpp
On 28.02.2017 10:33, Julius Schmidt wrote: I know about %zu, but this is wx Printf, not C99 printf. Does it also support %zu? Yes, it does: http://docs.wxwidgets.org/3.1/classwx_string.html#a9588b7f2684b9a6a924dc3746a2b2f8d --- quote: Note This function will use a safe version of vsprintf() (usually called vsnprintf()) whenever available to always allocate the buffer of correct size. Unfortunately, this function is not available on all platforms and the dangerous vsprintf() will be used then which may lead to buffer overflows. --- so it use C99 (vs(n))printf itself and must have %zu "from the box". Do we use it anywhere else? Is it a reason to do it wrong way here? On Tue, 28 Feb 2017, Sergey A. Borshch wrote: On 28.02.2017 01:54, Julius Schmidt wrote: This patch fixes a format string assertion. ... -txt.Printf( wxT( "%u" ), net->m_PadInNetList.size() ); +txt.Printf( wxT( "%u" ), (unsigned) net->m_PadInNetList.size() ); std::vector::size() returns size_t type. Why should you typecast variable type instead of fixing format specifier to be consistent with actual variable type? There is %zu format specifier designed specially for size_t type since C99. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] [PATCH] Assertion in pcbnew/dialogs/dialog_select_net_from_list.cpp
On 28.02.2017 01:54, Julius Schmidt wrote: This patch fixes a format string assertion. ... -txt.Printf( wxT( "%u" ), net->m_PadInNetList.size() ); +txt.Printf( wxT( "%u" ), (unsigned) net->m_PadInNetList.size() ); std::vector::size() returns size_t type. Why should you typecast variable type instead of fixing format specifier to be consistent with actual variable type? There is %zu format specifier designed specially for size_t type since C99. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] New eeschema file format
On 03.08.2016 05:12, Werner Almesberger wrote: Chris Pavlina wrote: Very good point about the start/end points. eeschema doesn't currently support that - it can't fill enclosed regions that are enclosed by multiple graphical objects - but this would ensure it could in the future with minimal changes. Okay - I'm for using start/end instead of angles, then. I'd still like to get rid of the redundant info, though. You can't entirely win this :-) If you use center, start, and end point, one could still diverge. In fped, I solved this as follows: I have center, start point (defining radius and angle), and end point (defining angle). No matter where the end point is, its distance from the center is (and has to be) ignored. How about two variants to define arcs: 1) Center point, start angle, end angle 2) start point, end point, radius. Both of them completely describe arcs, both of them has no diverge, both of them are usable in particular situation. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] PATCH: 3D resolver
On 20.04.2016 12:24, Cirilo Bernardo wrote: 2. ENV VARs paths defined by the shell take precedence over what is defined within KiCad; this is consistent with typical UNIX use: ENV_VAR=something pcbnew test.kicad_pcb Are you sure you understand UNIX precedence right? If you call some shell script instead of pcbnew in your example and this script define its own variable ENV_VAR with value "something_2", this local variable takes precedence over global ENV_VAR and over ENV_VAR with value "something" supplied in command line. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Circle dimensions
On 11.04.2016 21:06, Simon Wells wrote: If both are wanted there probably is not point as while its simpler with just radii its relatively easy to use radii with points. but i don't really want to complicate the ui with options. Sorry for my bad English, probably I described not clear enough. No options, just two fields: one for radius, second for point coordinates. User can change any of them and second will be calculated automatically. Are you able to give me an example of where point coordinates will be useful? I hope they are useful for someone who wrote the current code. All my charts has diameter dimensions drawn, so it quite annoying for me to convert diameter (radius) from chart to point coordinates. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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 file relative paths
On 12.04.2016 09:18, Cirilo Bernardo wrote: Hi folks, The current behavior of the 3D filename resolver is to use an absolute path in instances where a specified path is not a descendant of a path within the aliased paths list ... the resolver will assign a path relative to the Current Project Directory rather than an absolute path in cases where the file path cannot be shortened via the use of an alias. why relative to Current Project Directory and not to footprint directory? -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Circle dimensions
On 11.04.2016 20:08, Simon Wells wrote: Currently a Circle is dimensioned with - Center X - Center Y - Point on Circle X - Point on Circle Y is there a reason for doing it this way as having just Center and Radius would be simpler for entry. It can be nice to have both options, allowing user to edit point coordinates or radius. It can be nice also to have the ability to define arcs by center, radius and two angles. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Thanks to whoever done this :D
On 30.07.2015 16:10, Wayne Stambaugh wrote: If you or anyone else happens to find any other dialogs without a default button, please report them as soon as possible so they can be fixed for the stable release. OpenGL canvas, Dimension properties edit dialog. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] problem with modal component viewer and other modal dialogs
On 30.07.2015 18:37, yann jautard wrote:> so window pops up in a different display. Pretty unfriendly. > > Same thing happens for some dialogs in eeschema. > > I'm working on linux+KDE, I'm not sure the behaviour is the same on other systems. Same behaviour with multiple displays in linux+Cinnamon -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Printing broken again?
On 29.04.2015 11:02, jp charras wrote: Le 29/04/2015 09:34, Sergey A. Borshch a écrit : On 28.04.2015 16:53, jp charras wrote: Le 28/04/2015 15:43, Sergey A. Borshch a écrit : Hi everyone. Someone broke printing again. bzr rev. 5596 prints ok, while today bzr rev. 5628 print arcs in wrong direction(?). See attached screenshots. AFAIK, there is no changes in printing/drawing code since 5596 . Hmmm. After removing build directory and rebuilding all works as desired again. Strange. Sorry for disturbance. Besides there is no arc in screen-shots Ok, "arcs, approximated by polylines". Again, there is no arc, and therefore no "arcs, approximated by polylines". I don't know how it implemented, I just saw that "rounded" parts of characters was broken. You do not give any info on your system, wxWidgets info and printer. Developers do not have a crystal ball. Yes, I know, apologize. It was wx 3.1 and Linux "Print to File" printer. Your issue looks like print issues a very long time ago, on Linux, when wxWidgets used a very poor resolution in printing (72 ppi) Can you rebuild the rev 5596 with the *same Linux version and dev tools* as rev 5628 , to see if it is currently working and if something has changed between between them. I did it before my first letter. After my previous build of rev. 5596 I did "bzr up" and "make" yesterday, nothing more. Linux version, compiler, wx, etc was not changed since i built rev. 5596. That's why I thought it was a bug introduced in some of intermediate revision. Today, after removing build directory and rebuilding from scratch bug is gone, so now I understand that problem was on my side. (You can compile kicad using the Debug mode, to have more message info during printing) Kicad sets the printing resolution to medium quality, but does not handle the exact printing resolution itself, this is the system (wxWidgets+drivers) -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Printing broken again?
On 28.04.2015 16:53, jp charras wrote: Le 28/04/2015 15:43, Sergey A. Borshch a écrit : Hi everyone. Someone broke printing again. bzr rev. 5596 prints ok, while today bzr rev. 5628 print arcs in wrong direction(?). See attached screenshots. AFAIK, there is no changes in printing/drawing code since 5596 . Hmmm. After removing build directory and rebuilding all works as desired again. Strange. Sorry for disturbance. Besides there is no arc in screen-shots Ok, "arcs, approximated by polylines". -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Printing broken again?
Hi everyone. Someone broke printing again. bzr rev. 5596 prints ok, while today bzr rev. 5628 print arcs in wrong direction(?). See attached screenshots. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Printing
On 26.03.2015 15:14, jp charras wrote: Le 26/03/2015 13:36, Sergey A. Borshch a écrit : I am pretty sure this component was not build with libedit. (Arcs have bugs). Can you confirm that? No, I can't confirm yet. This component was published on one russian forum, but I forwarded your question to author and will forward his answer to you as soon as possible. He said that his colleague built this component with (possibly early version of) libedit. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Printing
On 26.03.2015 15:14, jp charras wrote: Le 26/03/2015 13:36, Sergey A. Borshch a écrit : I am pretty sure this component was not build with libedit. (Arcs have bugs). Can you confirm that? No, I can't confirm yet. This component was published on one russian forum, but I forwarded your question to author and will forward his answer to you as soon as possible. And yes, I see circles with radius 0, which are cause troubles (removing them restores normal printing). But, if there is a bug in library file, why error message was not printed during file loading? No error messages should mean "file is correct", isn't it? ;) That means program has (first) bug, which allows to load incorrect input file. On the other hand, "print preview" is "What You see is what you get", but I got not the same picture I saw, so it means it's not the only bug in component, but also a (second) bug in software. I reported this "test pattern" trying to help found and fix them. Correct me if I'm wrong. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Printing
Hi Maciej, On 25.03.2015 19:35, Maciej Sumiński wrote: Hi Sergey, Thank you for the report, screenshots were very helpful. Could you try the latest revision? (5536 & up) As I wrote, printing on my schematics and pcb works great now. But one man reported that transformer from attached library brakes printing - it's pins not printed and sheet title block(!) disappears as soon as this transformer inserted into schematics. Print preview shows all Ok. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia EESchema-LIBRARY Version 2.3 #encoding utf-8 # # B66413 # DEF B66413 TU 0 40 Y N 1 F N F0 "TU" 275 50 60 H V C CNN F1 "B66413" 325 -675 60 H V C CNN F2 "" 1035 110 60 H I C CNN F3 "" 835 -520 60 H I C CNN DRAW A 150 -400 50 901 -901 0 1 0 N 150 -450 150 -350 A 150 -300 50 901 -901 0 1 0 N 150 -350 150 -250 A 150 -200 50 901 -901 0 1 0 f 150 -250 150 -150 A 400 -400 50 901 -901 0 1 0 N 400 -350 400 -450 A 400 -300 50 901 -901 0 1 0 N 400 -250 400 -350 A 400 -200 50 901 -901 0 1 0 N 400 -150 400 -250 A 400 -100 50 901 -901 0 1 0 N 400 -50 400 -150 C 150 -400 0 0 1 0 N C 150 -400 6 0 1 0 N C 150 -400 10 0 1 0 N C 400 -100 0 0 1 0 N C 400 -100 6 0 1 0 N C 400 -100 10 0 1 0 N P 2 0 1 0 250 -50 250 -450 N P 2 0 1 0 300 -50 300 -450 N A 150 -100 50 901 -901 1 1 0 N 150 -150 150 -50 X 1 1 -50 -50 200 R 50 50 1 1 P X 2 2 -50 -450 200 R 50 50 1 1 P X 7 7 600 -450 200 L 50 50 1 1 P X 8 8 600 -50 200 L 50 50 1 1 P ENDDRAW ENDDEF # #End Library___ 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] Printing
On 25.03.2015 19:35, Maciej Sumiński wrote: Hi Sergey, Thank you for the report, screenshots were very helpful. Could you try the latest revision? (5536 & up) Excellent. Now it works without any visible issues. Thank You once more. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Printing
On 25.03.2015 13:02, Maciej Sumiński wrote: I have just pushed a patch that should resolve the printing issues. I did my best to test it with Windows and Linux, but it would be great if you could try it in your system too. Printing preview is quite accurate, so if you do not have a printer - it might be the way to check the result. Great work. Really great. First time I see printing on linux working. Thank you very much. The only one issue I found is that full circles in schematics and all other elements in surrounding rectangle are spread out. See attached program screenshot (Kicad.png) and two pieces of printed pdf. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Text substitution in footprint fields - any progress?
On 04.03.2015 16:42, Lorenzo Marcantonio wrote: On Wed, Mar 04, 2015 at 04:32:23PM +0200, Sergey A. Borshch wrote: As far as I remember Lorenzo anounced his implementation of text substitution of %R and %V patterns with RefDes and Value fields content. Is Seems like it dosn't works for me (today buld). See attached screenshots. Can you tell what am I doing wrong? I see $R not %R :D Damn! Thank you very much. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Text substitution in footprint fields - any progress?
Hello everybody. As far as I remember Lorenzo anounced his implementation of text substitution of %R and %V patterns with RefDes and Value fields content. Is there any progress in merging this feature into product branch? This feature could be very useful (really necessary) within assembly layers. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Default environment variables.
On 03.02.2015 23:01, Wayne Stambaugh wrote:
I finally committed the default environment variables code so you should
now be able to remove any system or user scope environment variables.
The following are the default paths:
KISYSMOD on windows and linux:
${KICAD_INSTALL_PREFIX}/share/kicad/modules
KISYSMOD on OSX:
/Library/Application Support/kicad/modules
KISYS3DMOD on windows and linux:
${KICAD_INSTALL_PREFIX}/share/kicad/modules/packages3d
Would not it be better ${KISYSMOD}/packages3d ?
KISYSMOD on OSX:
/Library/Application Support/kicad/modules/packages3d
The same: ${KISYSMOD}/packages3d
--
Regards,
Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia
___
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] eeschema freeze BZR5378
On 19.01.2015 14:44, jp charras wrote: It is not curious, libraries are loaded when starting Kicad. Therefore when changes are made outside KiCad, they are not seen. Editing libs outside Kicad is possible, but this is not an usual way of work. It's curious, because footprints in pcbedit not loaded when starting KiCad and can be modified without restarting pcbedt. What's the big difference between schematic and layout _libraries_? It's really curious why the same actions (move and copy block for example) looks totaly differnet in eeschema and pcbedit. Why the same code not reused, why not to use power of inheritance? -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] [RFC] proposal of adjusted netlist dialog
Sorry, I've lost first message in topic from Mark, so I paste my one as reply to this one. Mark, while you are deep inside this dialog source code, is it possible to add a checkbox "do not show this dialog again, just silently generate netlist file after clicking to icon on toolbar"? Dialog still must be shown from main menu but not from toolbar after checking this checkbox. Working on project I really _need_ this dialog first time only, all next hundred times until route is done I use this dialog to press "Generate" button only. On 22.10.2014 11:07, A. V. Dolganoff wrote: As a user, the new one makes more sense to me, you've my vote. On Wed, Oct 22, 2014 at 4:02 AM, Mark Roszko mailto:mark.ros...@gmail.com>> wrote: Hello, So I've been going through the UI to make it nicer. The netlist dialog right now is a bit odd. These marked up images show why, basically the functionality is grouped oddly on the dialog. http://i.imgur.com/0JK0d3g.png http://i.imgur.com/OrfrH14.png My proposal is this new arrangement: http://i.imgur.com/sek8ebW.png http://i.imgur.com/izeCybB.png Main change: wxNotebook turned into a wxSimplebook. A separate dropdown added to control the netlist formats to allow putting the add/remove buttons on the same line. A dropdown is nicer because in the end we are only selecting a single plugin to generate a netlist with anyway and this is more representative of the functionality. Thoughts? Code wise I've already done it but feedback is nice :D -- Mark ___ 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 Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Config file relocation (new patch)
On 03.09.2014 06:29, Moses McKnight wrote:
Hopefully this is the final patch.
As far as here is a talk about home directory pollution with kicad files - Is it
desired that lock files are created in home directory with strange name - full
path to file being edited with slashes ('/') replaced with underscores('_')
(e.g. _home__projects_proj1_hardware_schematic.sch.lock when opening file
/home//projects/proj1/hardware/schematic.sch)?
What's the function of this lock file? Shouldn't it be placed in project
folder behind the file being edited?
Another question about ~/eeschema-, ~/pcbnew- and similar files.
Shouldn't it be placed in ~/.kicad or /var/lock as almost all other programs do?
If those files are placed not in /var/lock, what's the purpose of username in
file names if files are created inside that user home directory?
--
Regards,
Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia
___
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] Title block date in pcbnew
On 02.05.2013 10:45, Lorenzo Marcantonio wrote: On Thu, May 02, 2013 at 10:40:50AM +0300, Sergey A. Borshch wrote: I was complaining about date change because it was often the only change in file after just opening/closing file without any modifications! I remember it in .sch and *-cache.lib files. The only thing I wanted is to save date only if file is really changed. Fully agree with that. That's the reason why I said it's 'difficult' to detect when the file is actually modified. Pressing "Save" icon is a good mark. I was talking about date change without pressing "Save" icon at all (possibly because of autosave?). I fully agree, that editable date field is a great solution. Second, internal "last save timestamp" record in file can be useful also, but is not a mandatory. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Title block date in pcbnew
On 01.05.2013 20:18, Lorenzo Marcantonio wrote: Also the vcs users wouldn't have to complain (I don't see the problem if a date changes in a versioned file... maybe they don't like it). I was complaining about date change because it was often the only change in file after just opening/closing file without any modifications! I remember it in .sch and *-cache.lib files. The only thing I wanted is to save date only if file is really changed. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Was: page selection dialog, everybody please comment
I'd like to have feedback from everyone on these opinions. I fully agree with Lorenzo, I really need Top Assembly and Bot Assembly layers, as well as more user layers (and user grids too). But that's doesn't matter because all we could get as a result of discussion is a Dick's cry about money. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] patch: pcbnew, hide text anchors while printing
On 11.03.2013 21:34, jp charras wrote: Le 11/03/2013 15:05, Sergey A. Borshch a écrit : This patch hides text anchors while printing board in pcbnew. Every time I print board silkscreen in pcbnew first page always goes to trashcan because of points in the center of reference designators and other texts. Who needs text anchors on printed paper? Thanks. patch added in rev 3995. It's curiously, but seems you apply patch manually line-by-line? Because changes appears in FOOTPRINT_EDIT_FRAME::PrintPage (where anchors can be usable) and not in PCB_EDIT_FRAME::PrintPage, where they are desired to be. Should you re-apply the patch correctly? -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] patch: pcbnew printing "Fit to page" scale fix
Oos, sorry, mistype in patch. Correct patch attached.
On 11.03.2013 16:17, Sergey A. Borshch wrote:
This patch makes scale option "fit to page" do the same as in all other programs
worldwide - produce biggest image that still fits to page.
Pcbnew generates 1:1-scaled centered image instead.
--
Regards,
Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia
=== modified file 'pcbnew/printout_controler.cpp'
--- pcbnew/printout_controler.cpp 2013-02-12 17:41:13 +
+++ pcbnew/printout_controler.cpp 2013-03-10 21:38:01 +
@@ -194,7 +194,9 @@
if( m_PrintParams.m_PrintScale == 0 )// fit in page
{
-userscale = 1.0;
+double scaleX = m_Parent->GetPageSizeIU().x /
boardBoundingBox.GetWidth();
+double scaleY = m_Parent->GetPageSizeIU().y /
boardBoundingBox.GetWidth();
+userscale = scaleX < scaleY ? scaleX : scaleY;
}
___
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] patch: pcbnew. fix memory leak in printing dialog
If user tries to generate print preview with no layer selected, *preview object
not destroyed and memory leaks.
--
Regards,
Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia
=== modified file 'pcbnew/dialogs/dialog_print_using_printer.cpp'
--- pcbnew/dialogs/dialog_print_using_printer.cpp 2012-11-29 01:50:58
+
+++ pcbnew/dialogs/dialog_print_using_printer.cpp 2013-03-11 00:32:29
+
@@ -449,6 +452,7 @@
if( s_Parameters.m_PrintMaskLayer == 0 )
{
DisplayError( this, _( "No layer selected" ) );
+delete preview;
return;
}
___
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] patch: pcbnew printing "Fit to page" scale fix
This patch makes scale option "fit to page" do the same as in all other programs
worldwide - produce biggest image that still fits to page.
Pcbnew generates 1:1-scaled centered image instead.
--
Regards,
Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia
=== modified file 'pcbnew/printout_controler.cpp'
--- pcbnew/printout_controler.cpp 2013-02-12 17:41:13 +
+++ pcbnew/printout_controler.cpp 2013-03-10 21:38:01 +
@@ -194,7 +194,9 @@
if( m_PrintParams.m_PrintScale == 0 )// fit in page
{
-userscale = 1.0;
+double scaleX = m_Parent->GetPageSizeIU().x /
boardBoundingBox.GetWidth();
+double scaleY = m_Parent->GetPageSizeIU().x /
boardBoundingBox.GetWidth();
+userscale = scaleX < scaleY ? scaleX : scaleY;
}
___
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] pcbnew patch: store user selection "single page" in print dialog
This path saves "single page" user choice in pcbnew printing dialog in the same
way as all other controls in this dialog stored.
--
Regards,
Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia
=== modified file 'pcbnew/pcbplot.h'
--- pcbnew/pcbplot.h2012-11-19 16:19:38 +
+++ pcbnew/pcbplot.h2013-03-11 00:16:19 +
@@ -29,6 +29,7 @@
#define OPTKEY_PRINT_PAGE_FRAME wxT( "PrintPageFrame" )
#define OPTKEY_PRINT_MONOCHROME_MODE wxT( "PrintMonochrome" )
#define OPTKEY_PRINT_PADS_DRILL wxT( "PrintPadsDrillOpt" )
+#define OPTKEY_PRINT_PAGE_PER_LAYER wxT( "PrintSinglePage" )
#define OPTKEY_PLOT_X_FINESCALE_ADJ wxT( "PlotXFineScaleAdj" )
#define OPTKEY_PLOT_Y_FINESCALE_ADJ wxT( "PlotYFineScaleAdj" )
#define CONFIG_PS_FINEWIDTH_ADJ wxT( "PSPlotFineWidthAdj" )
=== modified file 'pcbnew/dialogs/dialog_print_using_printer.cpp'
--- pcbnew/dialogs/dialog_print_using_printer.cpp 2012-11-29 01:50:58
+
+++ pcbnew/dialogs/dialog_print_using_printer.cpp 2013-03-11 00:32:29
+
@@ -215,6 +215,7 @@
m_config->Read( OPTKEY_PRINT_PADS_DRILL, &tmp,
PRINT_PARAMETERS::SMALL_DRILL_SHAPE );
s_Parameters.m_DrillShapeOpt = (PRINT_PARAMETERS::DrillShapeOptT) tmp;
+m_config->Read( OPTKEY_PRINT_PAGE_PER_LAYER,
&s_Parameters.m_OptionPrintPage, 1);
// Test for a reasonnable scale value. Set to 1 if problem
if( s_Parameters.m_XScaleAdjust < MIN_SCALE ||
s_Parameters.m_YScaleAdjust < MIN_SCALE ||
@@ -275,6 +276,8 @@
m_FineAdjustXscaleOpt->Enable(enable);
if( m_FineAdjustYscaleOpt )
m_FineAdjustYscaleOpt->Enable(enable);
+
+m_PagesOption->SetSelection(s_Parameters.m_OptionPrintPage);
}
@@ -321,6 +324,7 @@
m_config->Write( OPTKEY_PRINT_PAGE_FRAME,
s_Parameters.m_Print_Sheet_Ref);
m_config->Write( OPTKEY_PRINT_MONOCHROME_MODE,
s_Parameters.m_Print_Black_and_White);
m_config->Write( OPTKEY_PRINT_PADS_DRILL, (long)
s_Parameters.m_DrillShapeOpt );
+m_config->Write( OPTKEY_PRINT_PAGE_PER_LAYER,
s_Parameters.m_OptionPrintPage );
wxString layerKey;
for( int layer = 0; layer < NB_LAYERS; ++layer )
{
___
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] patch: pcbnew, hide text anchors while printing
This patch hides text anchors while printing board in pcbnew. Every time I print board silkscreen in pcbnew first page always goes to trashcan because of points in the center of reference designators and other texts. Who needs text anchors on printed paper? -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia === modified file 'pcbnew/print_board_functions.cpp' --- pcbnew/print_board_functions.cpp2013-01-13 00:04:00 + +++ pcbnew/print_board_functions.cpp2013-03-09 02:19:53 + @@ -180,6 +180,8 @@ m_DisplayPadNum = DisplayOpt.DisplayPadNum = false; bool nctmp = GetBoard()->IsElementVisible( NO_CONNECTS_VISIBLE ); GetBoard()->SetElementVisibility( NO_CONNECTS_VISIBLE, false ); +bool anchorsTmp = GetBoard()->IsElementVisible( ANCHOR_VISIBLE ); +GetBoard()->SetElementVisibility( ANCHOR_VISIBLE, false ); DisplayOpt.DisplayPadIsol= false; m_DisplayModEdge = DisplayOpt.DisplayModEdge= FILLED; m_DisplayModText = DisplayOpt.DisplayModText= FILLED; @@ -325,6 +327,7 @@ m_DisplayModEdge = DisplayOpt.DisplayModEdge; m_DisplayModText = DisplayOpt.DisplayModText; GetBoard()->SetElementVisibility(NO_CONNECTS_VISIBLE, nctmp); +GetBoard()->SetElementVisibility(ANCHOR_VISIBLE, anchorsTmp); } ___ 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] pcbnew fix: project file location
Hello everybody.
If pcbnew launched with .brd as cmd-line argument (just filename,
without absolute path), attempting to load file from current directory, pcbnew
loads settings from kicad.pro in the templates directory instead of
.pro in the current directory.
It happens because pcbnew creates wxFileConfig with .pro as
local_file constructor argument. According to wxFileConfig documentation it
means that config file location will be transformed to ~/..pro
which is not exist, and after failing to read values from this wrong location
pcbnew falls back to loading default settings from kicad.pro
In the same launching eeschema correctly detects config file name as
/.pro
Attached path fixes bug by converting .pro to
/.pro in the same way as eeschema does.
--
Regards,
Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia
=== modified file 'pcbnew/pcbnew_config.cpp'
--- pcbnew/pcbnew_config.cpp2013-02-02 17:39:59 +
+++ pcbnew/pcbnew_config.cpp2013-03-08 21:48:19 +
@@ -237,6 +237,9 @@
{
wxFileName fn = aProjectFileName;
+if( fn.IsRelative() )
+fn.MakeAbsolute();
+
if( fn.GetExt() != ProjectFileExtension )
fn.SetExt( ProjectFileExtension );
___
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] sorting pins in .lib files
On 23.02.2012 23:18, Dick Hollenbeck wrote: >> >> Unfortunately, when a hand modified component is re-imported into the >> library editor, and saved, most of previous efforts to sort pins are >> void, which makes the .lib file difficult to read back. >> > > Of course, a person could want the pins sorted by spatial location, or not want them > sorted at all, keeping order of entry. > Actually sort key and order doesn't matter. Problem is that lines in KiCAD files are intermixed after load-and-save (even without any modification by user in KiCAD itself). It makes using of version control systems less useful. Same about storing modules in library - why modified module moved into the end of library file? Diff utility can't find particular change after that. And why this behavior is different in schematic and modules libraries (in schematic library elements, thanks God, are sorted)? Why new module appended to the file while it's name inserted into $INDEX section in alphabetical order? Is seems like instead of code re-using developers re-invent new wheel for any particular piece of code. If KiCAD files could keep their lines order after load-modify-save, Laurent problem will be solved automatically - he can sort lined in any preferable order once. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] Concerns about clearing disagreements before committing.
On 25.11.2011 23:30, Lorenzo Marcantonio wrote: Isn't a std::set a little overweight for the layer mask? IIRC it's usually implemented as a btree (red-black trees in g++), and there is one for each pad at least in the board! A bitmasked int is a bit vector, which is a lot more efficient both in size and space. Also a bitmask is the very essence of a padstack (even if we do not handle them explicitly). Use C++ power instead of wrangle. Just hide layer mask implementation inside class, and afterward you could easy play with different implementations without refactoring all source code. You could compare speed, size and other issues using real code, not only assumptions. You could start from easiest (faster to write) implementation (e.g. std:set), and begin to experiment with optimization (e.g. bit vector or something else) when all necessary functionality already achieved. All changes will be localized in one single class. - Actually the only things that can be on more than one layer are pads and vias! Am I wrong? I'm not sure, but, possibly, some sort of barriers? -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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 - New Layers
On 13.09.2011 0:01, hauptmech wrote: What do you guys think about me adding 2 layers: Assembly_Front& Assembly_Back? It would hold graphical information useful for assembly drawings and part layout. I vote "yes" using both my hands. And much better if user could create arbitrary number of non-signal layers and pair them if necessary. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] New schematic file format.
On 29.03.2011 21:57, Wayne Stambaugh wrote: 2) Include meta-data type information such as file creation date, last modified date, file format version, etc. similar to the first line in the old file format? Yes, but avoid to change this information if file wasn't actually edited. In old file format information changes if file was opened just for viewing or printing and it confuses version control system - now I have to check what actually was changed in file and revert such "header-line updates" to avoid meaningless commits. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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
