Re: [Kicad-developers] Preferences rework - pcbnew
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 > 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 > > 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@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 > > > > ___ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : h
Re: [Kicad-developers] Preferences rework - pcbnew
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 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 > 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@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 > > ___ > 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
Re: [Kicad-developers] Preferences rework - pcbnew
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 > > 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@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 ___ 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
Re: [Kicad-developers] Preferences rework - pcbnew
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 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@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
Re: [Kicad-developers] Preferences rework - pcbnew
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 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@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
Re: [Kicad-developers] Preferences rework - pcbnew
I can imagine it, but I thought it was necessary to mention the idea. This task would be easier if we could just get rid of the legacy canvas. But that probably can't happen immediately, as we all know. 2016-05-03 17:13 GMT+02:00 Chris Pavlina : > Oh god no. Can you imagine the bug reports from people who can't find > settings? > > http://i3.kym-cdn.com/photos/images/newsfeed/000/727/910/577.gif > > On Tue, May 03, 2016 at 04:41:20PM +0200, Nick Østergaard wrote: >> Maybe just show or enable the settings if the appropriate canvas is active? >> >> 2016-05-03 14:52 GMT+02:00 Wayne Stambaugh : >> > 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@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 ___ 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
Re: [Kicad-developers] Preferences rework - pcbnew
Oh god no. Can you imagine the bug reports from people who can't find settings? http://i3.kym-cdn.com/photos/images/newsfeed/000/727/910/577.gif On Tue, May 03, 2016 at 04:41:20PM +0200, Nick Østergaard wrote: > Maybe just show or enable the settings if the appropriate canvas is active? > > 2016-05-03 14:52 GMT+02:00 Wayne Stambaugh : > > 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@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 ___ 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
Re: [Kicad-developers] Preferences rework - pcbnew
Maybe just show or enable the settings if the appropriate canvas is active? 2016-05-03 14:52 GMT+02:00 Wayne Stambaugh : > 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@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
Re: [Kicad-developers] Preferences rework - pcbnew
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@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
[Kicad-developers] Preferences rework - pcbnew
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? 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? ___ 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
