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.ch...@gmail.com> 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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp