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