kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx>
> 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
>