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 <[email protected]> > Sent: February 13, 2019 8:33 AM > To: Brian Piccioni <[email protected]> > 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 <[email protected]> >> Sent: February 13, 2019 7:48 AM >> To: Brian Piccioni <[email protected]>; 'Jeff Young' >> <[email protected]> >> Cc: 'KiCad Developers' <[email protected]> >> 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 <[email protected]> >>> Cc: KiCad Developers <[email protected]> >>> 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 <[email protected] >>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected]>> 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 >>>>>>>> <[email protected] <mailto:[email protected]>> 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 : [email protected] >>>>>>>> <mailto:[email protected]> >>>>>>>> <mailto:[email protected]> >>>>>>>> <mailto:[email protected]> >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>> Post to : [email protected] >>>>>>>> <mailto:[email protected]> >>>>>>>> <mailto:[email protected]> >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>> Post to : [email protected] >>>>>>> <mailto:[email protected]> >>>>>>> <mailto:[email protected]> >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>> More help : https://help.launchpad.net/ListHelp >>>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
