I really like this idea for after 5 is out On Sat, Feb 4, 2017 at 11:25 PM, John Beard <[email protected]> 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 <[email protected]> > 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 : [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 >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
