kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

That pretty much the way I see it.  Being able to configure the ratsnest
lines make life easier for very complex boards.

Wayne

On 2/13/19 7: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 certain nets stand out. For example, +5V might be red, +5V main buss might be red and extra thick (corresponding to the netclass specification for a power 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 <stambaughw@xxxxxxxxx> 
> Sent: February 13, 2019 8:33 AM
> To: Brian Piccioni <brian@xxxxxxxxxxxxxxxxxxxxx>
> Subject: 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 bug.
> 
> Cheers,
> 
> Wayne
> 
> On 2/13/2019 8:26 AM, Brian Piccioni wrote:
>> Wayne
>>
>> Is there something I should do to log this as a feature request?
>>
>> Thanks
>>
>> Brian
>>
>> -----Original Message-----
>> From: Wayne Stambaugh <stambaughw@xxxxxxxxx>
>> Sent: February 13, 2019 7:48 AM
>> To: Brian Piccioni <brian@xxxxxxxxxxxxxxxxxxxxx>; 'Jeff Young' 
>> <jeff@xxxxxxxxx>
>> Cc: 'KiCad Developers' <kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Subject: Re: [Kicad-developers] Version 6 development planning
>>
>> I'm fine with adding a ratsnest line thickness option.  I can sympathize with the old guy eyesight problem.
>>
>> On 2/12/2019 10:07 AM, Brian Piccioni wrote:
>>> For what it is worth, I would love to have the ability to change the 
>>> "thickness" of ratsnest wires. I find them almost invisible when 
>>> there are fewer of them, when they are short, or when the board is 
>>> mostly routed whatever color combination I choose.
>>>
>>> Probably an old guy thing, I know, but I can't find a negative to 
>>> having such an option.
>>>
>>> -----Original Message-----
>>> From: Kicad-developers
>>> <kicad-developers-bounces+brian=documenteddesigns.com@lists.launchpad.
>>> net>
>>> On Behalf Of Wayne Stambaugh
>>> Sent: February 12, 2019 9:21 AM
>>> To: Jeff Young <jeff@xxxxxxxxx>
>>> Cc: KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> Subject: Re: [Kicad-developers] Version 6 development planning
>>>
>>> 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 coloring feature.  Although when that might happen is anyone's guess.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 2/11/2019 6:44 PM, Jeff Young wrote:
>>>> 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 <stambaughw@xxxxxxxxx 
>>>>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>>>
>>>>> 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 small.  The one that might 
>>>>>> have conflicts is the escape-netnames one (which allows spaces, 
>>>>>> etc. in netnames).
>>>>>>
>>>>>> Cheers,
>>>>>> Jeff.
>>>>>>
>>>>>>
>>>>>>> On 9 Feb 2019, at 17:32, Wayne Stambaugh <stambaughw@xxxxxxxxx 
>>>>>>> <mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>>>>>
>>>>>>> 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 affects the schematic editor so if anyone has 
>>>>>>> any large change sets for any of the other editors ready to go, 
>>>>>>> now would be a good time to let everyone know so we don't step on 
>>>>>>> each
>>> other toes.
>>>>>>>
>>>>>>> The one thing that might cross all editors is object inspection. 
>>>>>>> Tom or Orson should be able to provide some insight as to what 
>>>>>>> impact this merge will have.
>>>>>>>
>>>>>>> On 2/9/19 10:17 AM, Jon Evans wrote:
>>>>>>>> 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 modern tool framework, since my code changes the 
>>>>>>>> behavior of some tools.
>>>>>>>> On the other hand, most of my code is "under the hood" so I 
>>>>>>>> don't really mind refactoring my stuff before merge in order to 
>>>>>>>> match whatever is the status quo.
>>>>>>>>
>>>>>>>> https://github.com/craftyjon/kicad/tree/bus_upgrades
>>>>>>>>
>>>>>>>> -Jon
>>>>>>>>
>>>>>>>> On Sat, Feb 9, 2019 at 6:45 AM John Beard 
>>>>>>>> <john.j.beard@xxxxxxxxx <mailto:john.j.beard@xxxxxxxxx>> wrote:
>>>>>>>>
>>>>>>>>    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 to ask
>>>>>>>>    about the plan for v6 development opening. As far as I am 
>>>>>>>> aware, we
>>>>>>>>    will need to juggle the following tasks:
>>>>>>>>
>>>>>>>>    1) Removal of legacy canvases and supporting code
>>>>>>>
>>>>>>> I'm assuming you are talking about the board and footprint editors.
>>>>>>> AFAIK, no one has any major footprint editor changes queued up so 
>>>>>>> this would probably be a safe place to start.  Once we determine 
>>>>>>> the extent of the queued board editor merges, we can coordinate 
>>>>>>> the removal of the board editor legacy canvas code.
>>>>>>>
>>>>>>>>    2) Further surgery on eeschema w.r.t. modern tool framework
>>>>>>>
>>>>>>> After we merge Jon's connectivity code, the new tool framework 
>>>>>>> coding can start.  I don't see this effecting any of the new 
>>>>>>> symbol or schematic file format work that I'm planning on doing.
>>>>>>> We should only focus on implementing replacements for the 
>>>>>>> existing
>>> framework initially.
>>>>>>> Once that is implemented and reasonably bug free, then we should 
>>>>>>> start working on on the fancy new features like object selection, 
>>>>>>> snapping, etc.
>>>>>>>
>>>>>>>>    3) New symbol format work (hopefully relatively 
>>>>>>>> self-contained in the
>>>>>>>>    plugin architecture)
>>>>>>>
>>>>>>> This should be pretty much self contained.  The goal will be to 
>>>>>>> get the existing file format functionality stable before we open 
>>>>>>> the flood gates for new features like pin/gate swapping, pin 
>>>>>>> functions,
>>> etc.
>>>>>>>
>>>>>>>>    4) Merging of various completed features from people who have 
>>>>>>>> them
>>>>>>>>    stored up since before v5 release
>>>>>>>
>>>>>>> If you have big change sets, please let everyone know so we can 
>>>>>>> coordinate this.  I'm sure I'm not fully aware of everything that 
>>>>>>> is queued up.
>>>>>>>
>>>>>>>>    5) Normal ongoing bug fixing and development in the 
>>>>>>>> background
>>>>>>>
>>>>>>> Let's make sure we remember to cherry-pick bug fixes to the 5.1 branch.
>>>>>>> I know this can be a pain as the development branch diverges from 5.1.
>>>>>>> I suspect v6 development is going to take a while given the 
>>>>>>> significance of the changes so we need to be diligent about 
>>>>>>> regular
>>>>>>> 5.1 bug fix releases.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Wayne
>>>>>>>
>>>>>>>>
>>>>>>>>    There order this happens in will be quite important - if the 
>>>>>>>> legacy
>>>>>>>>    removal/eeschema tooling happens first, the features might 
>>>>>>>> not merge
>>>>>>>>    cleanly, but at the same time, legacy brings its own ongoing 
>>>>>>>> technical
>>>>>>>>    debt. If we can set the order down before the v6 floodgates 
>>>>>>>> open, at
>>>>>>>>    least we can approach the incoming patches in a systematic way.
>>>>>>>>    Specifically, if a major legacy-based refactor is anticipated 
>>>>>>>> soon
>>>>>>>>    after v6 opens, people should expect major rebasing to be 
>>>>>>>> required for
>>>>>>>>    incoming features.
>>>>>>>>
>>>>>>>>    I don't really have any personal preference, as I don't have 
>>>>>>>> patches
>>>>>>>>    that are both urgent and impractical to rebase if needed.
>>>>>>>>
>>>>>>>>    Perhaps a cursory survey of the work people expect to merge 
>>>>>>>> after v6
>>>>>>>>    might be in order? Links to git branches, etc?
>>>>>>>>
>>>>>>>>    Cheers,
>>>>>>>>
>>>>>>>>    John
>>>>>>>>
>>>>>>>>    [1]: https://launchpad.net/kicad/+milestone/5.1.0
>>>>>>>>
>>>>>>>>    _______________________________________________
>>>>>>>>    Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>    Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>>>>    <mailto: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
>>>>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>>>> <mailto: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
>>>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>>> <mailto: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
>>>
>>
>