Or instead of trying to change how the ratsnests are displayed because they
are laying on top of each other, instead have the user hover over the
overlapping of nets and a popup appears showing what nets there are kind of
like a magnifying glass, would probably be better if this magnifying glass
is
On Wed, Feb 13, 2019 at 08:25:01AM -0800, Evan Shultz wrote:
> As nothing more than an example, here is another tool facing the same
> issue. I've colored one net's ratsnest green (others are still blue) and
> you can see pins at orthogonal locations to each other get a zig (or is
> that a zag?) so
buss, for example).
>
> Of course, perhaps that is what you meant but I thought I'd put it out there.
>
> Brian
>
> -Original Message-
> From: Wayne Stambaugh
> Sent: February 13, 2019 8:33 AM
> To: Brian Piccioni
> Subject: Re: [Kicad-developers] V
On 2/13/19 7:35 PM, Andy Peters wrote:
>
>
>> On Feb 13, 2019, at 5:06 PM, Brian Piccioni
>> wrote:
>>
>> Wayne
>>
>> On reflection it occurred to me that being able to vary the width of a
>> ratsnest by net (or perhaps netclass) may provide additional utility to
>> being able to vary colou
> On Feb 13, 2019, at 5:06 PM, Brian Piccioni
> wrote:
>
> Wayne
>
> On reflection it occurred to me that being able to vary the width of a
> ratsnest by net (or perhaps netclass) may provide additional utility to being
> able to vary colour by net.
>
> Like bolding of text, it would make
bject: Re: [Kicad-developers] Version 6 development planning
Brian,
Thanks, but you don't need to do anything. There is already a roadmap entry
for changing the color of ratsnest lines per net so adding line thickness to
that proposal makes more sense than creating a separate wish list bu
As nothing more than an example, here is another tool facing the same
issue. I've colored one net's ratsnest green (others are still blue) and
you can see pins at orthogonal locations to each other get a zig (or is
that a zag?) so the individual pins on the net can still be easily
identified.
[imag
On Wed, Feb 13, 2019 at 2:28 PM Jeff Young wrote:
>
> >> I'm also not
> >> completely sure curved air wires will be necessary once we implement the
> >> coloring feature.
>
> I wonder if this is a digital vs. discrete thing? With transistors in
> particular, I often find several ratsnest lines g
rom: Kicad-developers
> >
> > On Behalf Of Wayne Stambaugh
> > Sent: February 12, 2019 9:21 AM
> > To: Jeff Young
> > Cc: KiCad Developers
> > Subject: Re: [Kicad-developers] Version 6 development planning
> >
> > This is a new feature which should be
>> I'm also not
>> completely sure curved air wires will be necessary once we implement the
>> coloring feature.
I wonder if this is a digital vs. discrete thing? With transistors in
particular, I often find several ratsnest lines going directly over the 3 pins,
and having no idea which one con
gt; From: Kicad-developers
>
> On Behalf Of Wayne Stambaugh
> Sent: February 12, 2019 9:21 AM
> To: Jeff Young
> Cc: KiCad Developers
> Subject: Re: [Kicad-developers] Version 6 development planning
>
> This is a new feature which should be merged during v6. I still haven't
now, but I can't find a negative to having
such an option.
-Original Message-
From: Kicad-developers
On Behalf Of Wayne Stambaugh
Sent: February 12, 2019 9:21 AM
To: Jeff Young
Cc: KiCad Developers
Subject: Re: [Kicad-developers] Version 6 development planning
This is a new feature
This is a new feature which should be merged during v6. I still haven't
gotten around to reviewing and testing the curved ratsnest changes. I
would like to take a look at the changes before we merge them. I'm also
not completely sure curved air wires will be necessary once we implement
the color
Oh, and we should merge the airline-route (curved) ratsnest stuff early too,
since the author has been waiting a long time.
Cheers,
Jeff.
> On 9 Feb 2019, at 20:35, Wayne Stambaugh wrote:
>
> This might cause issues with Jon's work so we should let Jon merge his
> code first since I'm sure hi
This might cause issues with Jon's work so we should let Jon merge his
code first since I'm sure his changes are far more significant and then
you will have to rebase against his changes. Hopefully it wont be too
painful.
On 2/9/19 1:00 PM, Jeff Young wrote:
> Most of my 6.0 branch changesets are
We definitely should plan this out carefully to avoid a bunch merge
conflicts. Please consider carefully making large change sets to
prevent big merge conflicts. Jon's connectivity changes have been done
for quite some time and I want to get them merged as soon as branch 5.1.
Obviously this only
Figuring this out is a good idea. Thanks for suggesting it, John!
My branch contains upgrades to the connectivity and netlisting system in
eeschema.
I have been resolving conflicts from time to time as I am able.
It may be a good idea to get it merged before too much work goes into
eeschema moder
Hi,
I have a few questions about the plan of action for the start of the
v6 development window. I feel that since the 5.1.0 bug list[1] is
dwindling, there are probably a few people around who are just waiting
for a green light on v6.
So that they can organise any pending patches better, I'd like
18 matches
Mail list logo
