kicad-developers team mailing list archive

[José Ignacio <jose.cyborg@xxxxxxxxx>]

I really like this idea for after 5 is out

On Sat, Feb 4, 2017 at 11:25 PM, John Beard <john.j.beard@xxxxxxxxx> wrote:

> Hi,
>
> I support the general idea of being able to turn off bits of the
> legacy canvas at will, in principle. However, I'm not sure how many
> people will actually bother to check if stuff behind an #ifdef is
> getting broken, and legacy stuff is quite vulnerable because of tight
> binding to large classes like PCB_EDIT_FRAME, etc. I think if you had
> this option on, you'd most get one of these options: 1) no-one uses it
> 2) everyone who does use it has to compile and test everything twice
> (leading to case 1) or 3) lots of people use it and don't fully check
> legacy works for every patch, and effort has to be expended
> maintaining and revising patches and requesting re-tests (this is
> already bad enough with platform-specific problems, we don't want to
> segment testing any further, I think).
>
> I would suggest that the legacy canvas remains as it is, but
> individual non-essential features of it that are available and solid
> in GAL get removed piece by piece. This way you get everyone and
> compiling and testing and _using_ the same code, and no-one loses a
> feature for want of a re-compile (they might need to switch canvases
> though). Additionally, legacy code complexity is drained down slowly
> and deliberately, a logically separate piece at a time, which helps
> locate refactoring opportunities and indentify legacy switch-off
> problem points sooner rather than later. Waiting for GAL-Day and
> nuking legacy fast would be more likely (IMO) to result in breakages
> and less careful consideration of how each separate piece can be
> tidied away into a GAL-only framework.
>
> Examples of "non-essential" features might be things like net
> highlighting, arrays tools and so on, and could even extend to things
> like the drawing tool and copy/paste over time, leaving only a hard
> core of very basic moving/view change functions and any remaining
> non-GAL features, which get drawn off over time. Any major breakage
> during this time (e.g. if the legacy track tool is removed and PNS
> breaks) is breakage that probably would still have happened during a
> firesale removal of legacy, but it will happen under controlled and
> more easily-revertable circumstances. The remaining "core" of legacy
> functionality, by the end of the process, should be dramatically
> smaller and more easily conceptualised, making it easier to finally
> remove it entirely.
>
> I'm not proposing a timeline, but if legacy is to be part of a stable
> release again, I would suggest that fewer features in it would drive
> use and testing of GAL tools, reduce user (especially newly-arrived
> Eagle users!) frustration with using legacy tools, and reduce bug
> surface area though reduction of legacy code volume, which is
> substantial, complex, and ultimately doomed anyway. It would also free
> code that is currently used by both GAL and legacy (e.g. many dialogs)
> to be able to evolve more freely when only the GAL calling code needs
> to be updated to support it, enabling faster response to bugs and
> feature requests on both stable and devel branches. It would also
> promote a lot of careful checking of legacy/GAL crossover code and
> refactorings, so it would hopefully be a good vehicle for code quality
> discussion too.
>
> I hope that makes as much sense as it did in my head!
>
> Cheers,
>
> John
>
> On Tue, Jan 31, 2017 at 11:22 PM, Chris Pavlina <pavlina.chris@xxxxxxxxx>
> wrote:
> > I think it's worth revisiting this. I know we're not ready to remove
> > legacy yet, but we're getting close. Starting to factor it out into a
> > switchable build option is a good way to make sure the transition is
> > smooth and help find anything that is still missing. Obviously the
> > default build option should be to keep legacy in, so users won't notice
> > anything.
> >
> > On Sat, Sep 17, 2016 at 10:59:45PM +1200, Simon Wells wrote:
> >> As legacy canvas in pcbnew is legacy is it worth conditional compiling
> >> all the code related and only used by legacy canvas based on a cmake
> >> option aka something like
> >>
> >> KICAD_BUILD_LEGACY_CANVAS with a default of ON, this will allow people
> >> who have no use for the legacy canvas as they have a truly functional
> >> opengl canvas to see in their usual workflow if anything is missing.
> >>
> >> I realise that wayne is waiting on a replacement non-gl dependent GAL
> >> canvas before removing legacy, but in the interim is it worth making
> >> it an option making less work later on when its time to remove it
> >>
> >> Simon
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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
>