kicad-developers team mailing list archive

[Simon Wells <swel024@xxxxxxxxx>]

my 2 cents is this is not really a good idea.

On 5 February 2017 at 18:47, José Ignacio <jose.cyborg@xxxxxxxxx> wrote:
> 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
>
>
>
> _______________________________________________
> 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
>