my 2 cents is this is not really a good idea. On 5 February 2017 at 18:47, José Ignacio <[email protected]> wrote: > 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 >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
