kicad-developers team mailing list archive

[John Beard <john.j.beard@xxxxxxxxx>]

Hi Wayne,

Ratsnest thickness and scroll config can be added as advanced config,
and proper UI introduced after 5.1 (and backported to 5.1.1 if
wanted?).

Cheers,

John

On Wed, Feb 13, 2019 at 12:50 PM Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>
> 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
> >
>
> _______________________________________________
> 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