kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

I had originally thought that was the idea with the 4.x series, but I might be
wrong.

On Wed, May 04, 2016 at 11:10:46AM -0600, Duane Johnson wrote:
> Might it be worth making a specific (intermediate) release whose purpose is
> to make it the last support for "legacy" canvas?
> 
> On Wed, May 4, 2016 at 9:19 AM, Chris Pavlina <pavlina.chris@xxxxxxxxx>
> wrote:
> 
> > While I understand your point, and I think I agree with it (though I'm
> > almost
> > on the fence), I wonder if I should explain - I think the argument for
> > removing
> > legacy sooner rather than later is that by removing the crutch of "eh, we
> > can
> > just use legacy for that for now", we will encourage development of
> > replacement
> > GAL features as well as reallocate useful developer time to them, and that
> > perhaps the temporary incompatibility with some systems and small handful
> > of
> > missing features is worth the trouble on the development branch --- those
> > who
> > require the missing features or compatiblity can use Stable for important
> > projects.
> >
> > Not entirely sure how much I agree with that, and how many users such an
> > action
> > would piss off. But I think it is a point worth being considered at least.
> > Temporary inconveniences on the devel branch aren't world-ending, tbh.
> >
> > On Wed, May 04, 2016 at 11:02:40AM -0400, Wayne Stambaugh wrote:
> > > Removing the legacy canvas cannot be done until there is an acceptable
> > > solution for users who do not have usable opengl on their systems.  The
> > > Cairo canvas is not usable even on the fastest system I've have access
> > > to.  Until either Cairo gets a significant speed boost, opengl becomes
> > > usable on all platforms, or we port wxDC to GAL, it will have to stay.
> > >
> > > On 5/3/2016 6:51 PM, José Ignacio wrote:
> > > > What about simply removing the legacy canvas preemptively from the
> > > > development branch? gal-only is pretty usable by now and it might
> > > > reduce development workload for new features.
> > > >
> > > > On Tue, May 3, 2016 at 7:52 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
> > wrote:
> > > >> On 5/2/2016 4:54 PM, Chris Pavlina wrote:
> > > >>> I'd like to start having a look at how I can organize the
> > preferences for
> > > >>> pcbnew, having mostly finished in eeschema. (A few things remain to
> > be tweaked
> > > >>> and will probably be done at the same time as pcbnew, to keep things
> > in sync).
> > > >>>
> > > >>> The problem of legacy preferences vs GAL preferences needs to be
> > addressed. How
> > > >>> do we want to handle that? At this point, I'm not sure what the
> > timeline is for
> > > >>> actual removal of legacy - should I wait until we do that?
> > > >>
> > > >> This is most likely going to be a while so you wont be able to remove
> > > >> the legacy canvas settings until we completely remove the legacy
> > canvas
> > > >> from the source.
> > > >>
> > > >>>
> > > >>> If not, I want to try to merge options as much as possible. There
> > are some
> > > >>> things that are duplicated between the two, which I'd like to fix.
> > But the
> > > >>> bigger question is: how should we present to the user things that
> > are only
> > > >>> available in one or the other?
> > > >>>
> > > >>> I could simply make sections on the preferences pages: "Legacy
> > canvas only",
> > > >>> "OpenGL or Cairo canvas only". That's ugly and makes me cringe, but
> > I can't
> > > >>> think of anything better. Two separate, parallel preferences systems
> > like we
> > > >>> have right now just won't do. Thoughts?
> > > >>
> > > >> Even though separating the settings is probably going to be ugly, it's
> > > >> the most prudent way to go in terms of effort.  If they are organized
> > > >> this way, it should be fairly easy to remove them when we finally get
> > > >> around to dumping the legacy canvas.
> > > >>
> > > >>>
> > > >>> _______________________________________________
> > > >>> 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
> >