kicad-developers team mailing list archive

["Brian Piccioni" <brian@xxxxxxxxxxxxxxxxxxxxx>]

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