← Back to team overview

kicad-developers team mailing list archive

Re: [PATCH] Schematic Cleanup: Split lines at junctions

 

fn-delete

On Fri, May 20, 2016 at 10:47 AM, Thor-Arne <lp@xxxxxxxxxxxxx> wrote:
> It should be listed on the hot-key list.
> Perhaps some other key is used.
>
> From: Duane Johnson
> Sent: Friday, May 20, 2016 12:36 AM
> To: Thor-Arne
> Subject: Re: [Kicad-developers] [PATCH] Schematic Cleanup: Split lines at
> junctions
>
>
> I didn't know about this behavior. On the Mac, there is no backspace key.
>
> On May 19, 2016 4:25 PM, "Thor-Arne" <lp@xxxxxxxxxxxxx> wrote:
>>
>> This delete-wire behavior has been available in KiCad for as long as I've
>> been using it, which is some time before the 2013-stable release.
>>
>> Delete wire is on the delete button. and delete segment is on the
>> backspace key.
>>
>> Please do NOT change the behavior of the delete buton, it is used all the
>> time.
>>
>> -----Original Message----- From: Chris Pavlina
>> Sent: Friday, May 20, 2016 12:10 AM
>> To: Simon Richter
>> Cc: kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Kicad-developers] [PATCH] Schematic Cleanup: Split lines at
>> junctions
>>
>> I like the behavior of this patch, it seems a lot closer to how I'd expect
>> deleting wires to work. :)
>>
>> On Thu, May 19, 2016 at 08:49:09PM +0200, Simon Richter wrote:
>>>
>>> Hi jp,
>>>
>>> On 19.05.2016 19:44, jp charras wrote:
>>>
>>> > It could be worth to *clearly* explain in your patches what bug you
>>> > want > to fix, or what enhancement
>>> > you are adding.
>>>
>>> Good point.
>>>
>>> The last batch has two goals:
>>>
>>> 1. fix a long-standing annoyance that deleting a line segment will
>>> delete the entire length of wire, even when I want to delete only a
>>> short piece. http://psi5.com/~geier/wires.ogv shows what I mean.
>>>
>>> 2. prepare for net ties -- these need to split nets, so having code in
>>> place to split wires at certain points will have nice synergy effects.
>>>
>>> For the most part, I've been posting these as a heads-up and RFC; if the
>>> benefit is obvious, it's fine to apply them, but I'm not unhappy if they
>>> aren't applied immediately, because I'm more interested in things that
>>> are obviously wrong or that I've overlooked, and my patch stack is
>>> rebased on top of the current state every time I update anyway.
>>>
>>> "Serious" patch submissions start with a [PATCH 00/nn] mail that doesn't
>>> contain a patch and explains the rationale fully, and have longer
>>> descriptions in each separate patch (and incidentally, it'd be nice to
>>> keep those somehow).
>>>
>>>    Simon
>>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>


Follow ups

References