Le 30/07/2017 à 12:50, Joakim Asplund a écrit :
> Sorry for not getting back to you earlier.
>
> I did the changes back when BZR was being used and used the bzr/git gateway
> thing, but now my git-fu
> is not advanced enough to apply the changes easily to the copy I have checked
> out of git (th
Sorry for not getting back to you earlier.
I did the changes back when BZR was being used and used the bzr/git gateway
thing, but now my git-fu is not advanced enough to apply the changes easily
to the copy I have checked out of git (the commit hashes are different).
The attached patches are based
Joakim,
I was not aware that there were two different code paths for annotating
power symbols. I'm not sure why that is but your solution seems sound.
Would you please make your source tree available or provide a patch of
the changes so we can review it to see if makes sense to merge the
changes
I found previously that there are two different pieces of code that
annotates the power symbols. One is the normal annotation code. The other
uses a completely different numbering scheme and runs silently before DRC
and netlist generation and renumbers all power symbols on all open sheets.
This cau
Le 10/07/2017 à 20:51, Wayne Stambaugh a écrit :
> I'm not sure why power symbols would be re-annotated. Maybe JP could
> shed some light on this. It does seem odd that power symbols are
> annotated differently than non-power symbols.
There are 2 reasons:
* silently annotating power symbols (tha
I'm not sure why power symbols would be re-annotated. Maybe JP could
shed some light on this. It does seem odd that power symbols are
annotated differently than non-power symbols.
On 7/10/2017 2:06 PM, José Ignacio wrote:
> I've noticed another annoying churn in eeschema, when annotating the
> s
I've noticed another annoying churn in eeschema, when annotating the
schematics power flags get re-annotated even if they already had refs
assigned from before and the annotate command is not set to overwrite. I
don't know if it does it all the time but it does it fairly often in my
experience.
On
Forward compatibility is highly unlikely given our limited manpower.
There is a fundamental misunderstanding about net names. Pcbnew does
not have anything to do with naming them. Pcbnew on reads the net names
from the net list. The net names are generated by Eeschema and passed
to Pcbnew so th
The problem is that you can't make old kicad read the new format, unless a
patch gets backported.
On Mon, Jul 10, 2017 at 10:19 AM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:
> Could we not support reading both formats, but only write one format?
>
> - Kristoffer
>
>
> On 2017-07-10
Could we not support reading both formats, but only write one format?
- Kristoffer
On 2017-07-10 09:36, Maciej Sumiński wrote:
I think there is a lot of code that assumes consecutive net numbering.
Instead, we could simply save net names instead of net numbers and let
KiCad use net codes as con
I think there is a lot of code that assumes consecutive net numbering.
Instead, we could simply save net names instead of net numbers and let
KiCad use net codes as convenient. One significant problem is it would
cause the .kicad_pcb file format change, making it completely unreadable
by the curren
Good ideas! I would also like a better SCM behavior. Having the file
change as little as possible would be great for those things.
I will this and see what else you encounter :)
On 2017-07-01 04:49, hauptmech wrote:
We have a fairly complex board that needs to be done yesterday. We've
been e
We have a fairly complex board that needs to be done yesterday. We've
been experimenting with simultaneous editing of the pcb with moderate
success.
We are using git. Each person works in a different area of the board,
and we merge the results periodically.
Because of the time crunch, we a
13 matches
Mail list logo
