kicad-developers team mailing list archive

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

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