Those are interesting ideas. My reading is that Andrey and Wayne are actually proposing two different "linking" modes:
Andrey: linking Front and Back (i.e. checking Front pads also checks Back pads) Wayne: linking copper and render (i.e. checking F.Cu also checks Front pads) Am I right about your suggestion, Wayne? I think from my personal perspective as a user, I would expect by default Wayne's link to be on and Andrey's to be off. That is, by default if I turn off F.Cu I expect Front Pads to go away too, but there might be edge cases where I want to turn on F.Cu and turn off F.Pads or vice versa. -Jon On Sun, Feb 18, 2018 at 8:59 PM, Andrey Kuznetsov <kandre...@gmail.com> wrote: > Wayne, > Yep, that's what I meant, kind of like the Photoshop linked layers. > > I should have added that the link is only between two of the same > checkboxes that are front and bottom. Ie Front/Bottom Pads would have > linkage, a different linkage would be between F/B Text, and another for > etc... > > Please don't link multiple text/pads/vias/footprints together. I think > linking should only be between Front and Bottom of the same item type. > Maybe add a tiny horizontal separator between the pairs of Front and Bottom > rows: ie > Front Pads > Bottom Pads > ----------------- > Front Text > Bottom Text > ----------------- > etc > > On Sun, Feb 18, 2018 at 5:49 PM, Wayne Stambaugh <stambau...@gmail.com> > wrote: > >> I was thinking the same thing but rather than locked, I was thinking >> linked to the layer but the concept is the same. If they are linked, >> when the layer is turned off, so are the footprints on that layer. When >> they are unlinked, they are independent similar to the current behavior. >> I would default to linked since that is what most users would expect. >> >> On 02/18/2018 08:42 PM, Andrey Kuznetsov wrote: >> > Hi Jon, >> > >> > Make sure Andrews' patches are consistent with your commits, essentially >> > don't commit if it'll end up as a hodge podge of code that even though >> > it works is not coherent. >> > >> > I can see benefits to having control over showing front copper pads but >> > hiding bottom copper pads, so I would keep them separate. >> > If it's an annoyance to toggle both front and bottom copper checkboxes >> > for pads, maybe a LOCK is warranted such that in a locked position, a >> > toggle checkbox in either, toggles both checkboxes for front/bottom, and >> > an unlocked state keeps them independent. >> > >> > Thanks >> > >> > On Sun, Feb 18, 2018 at 4:37 PM, Jon Evans <j...@craftyjon.com >> > <mailto:j...@craftyjon.com>> wrote: >> > >> > I'm going to go to the user forum with these questions too, but >> > curious what the devs think about this: >> > >> > In my original RFC, I proposed eliminating the different between >> > "front" and "back" in the Render checkboxes. >> > I still think this makes sense for things like text and footprints, >> > but I'm having second thoughts about merging the "Pads Front" and >> > "Pads Back" >> > Right now we have pads set to a different color than other copper on >> > the front and back copper layers. >> > I guess some users probably like this and would get annoyed if we >> > removed the ability for pads to be a special color. >> > Will they get annoyed if we force them to set both the front and the >> > back pads to the same color? >> > >> > (to be honest, I am used to EDA tools that by default treat pads as >> > part of the copper layer and show them in the same color, so I don't >> > care about this feature) >> > >> > -Jon >> > >> > On Sun, Feb 18, 2018 at 7:09 PM, Jon Evans <j...@craftyjon.com >> > <mailto:j...@craftyjon.com>> wrote: >> > >> > Thanks Wayne and Jeff (and yes there are a lot of edge cases >> > here to sort out) >> > >> > Note that Andrzej Wolski already did propose some changes >> > related to this that might be good to merge as a first step. >> > I have only done limited testing on them so far but they do work >> > and resolve some of the problems: >> > >> > https://bugs.launchpad.net/kicad/+bug/1743890/comments/6 >> > <https://bugs.launchpad.net/kicad/+bug/1743890/comments/6> >> > https://lists.launchpad.net/kicad-developers/msg34009.html >> > <https://lists.launchpad.net/kicad-developers/msg34009.html> >> > >> > -Jon >> > >> > On Sun, Feb 18, 2018 at 6:53 PM, Jeff Young <j...@rokeby.ie >> > <mailto:j...@rokeby.ie>> wrote: >> > >> > Hi Jon, >> > >> > Sounds good to me too. A few edge-cases you might want to >> > watch out for: >> > >> > https://bugs.launchpad.net/kicad/+bug/1733894 >> > <https://bugs.launchpad.net/kicad/+bug/1733894> >> > https://bugs.launchpad.net/kicad/+bug/1744521 >> > <https://bugs.launchpad.net/kicad/+bug/1744521> >> > https://bugs.launchpad.net/kicad/+bug/1744730 >> > <https://bugs.launchpad.net/kicad/+bug/1744730> >> > >> > Cheers, >> > Jeff. >> > >> > >> >> On 18 Feb 2018, at 22:36, Wayne Stambaugh >> >> <stambau...@gmail.com <mailto:stambau...@gmail.com>> >> wrote: >> >> >> >> Hey Jon, >> >> >> >> I'm good with all of this. I would like to get this >> >> cleaned up before the stable release if possible since >> >> there are so many complaints and bug reports about it. >> >> >> >> Thanks, >> >> >> >> Wayne >> >> >> >> On 02/18/2018 03:00 PM, Jon Evans wrote: >> >>> Hi all, >> >>> Right now the behavior of the "Layer" and "Render" tabs >> >>> of the layers widget are confusing to users, resulting in >> >>> complaints on the forum and some bug reports: >> >>> https://bugs.launchpad.net/kicad/+bug/1748181 >> >>> <https://bugs.launchpad.net/kicad/+bug/1748181> >> >>> https://bugs.launchpad.net/kicad/+bug/1743890 >> >>> <https://bugs.launchpad.net/kicad/+bug/1743890> >> >>> I could take a crack at fixing this (before or after 5.0 >> >>> depending on what the complexity ends up being) but >> >>> before I write any code I wanted to propose how I think >> >>> it should work. >> >>> I think the visibility of any object should be the AND of >> >>> layer visibility and render visibility. >> >>> To get there: >> >>> 1) In the Render tab, get rid of the distinction between >> >>> front/back. For example "Pads Back" and "Pads Front" >> >>> becomes just "Pads" >> >>> 2) Change the visibility code so that an object is >> >>> visible if (a) the associated Render setting is turned on >> >>> for the type of object, and (b) at least one of the >> >>> layers the object is on is enabled in the Layers tab. >> >>> 3) (optionally) Rename "Render" to something more >> >>> friendly like "Items" or "Item Types" to make it more >> >>> clear to the user that this is where they can turn off >> >>> the display of various types of items as opposed to >> >>> various layerse >> >>> If this plan is OK, I will start working out the details >> >>> of how to get there. Right now the Render tab is >> >>> directly controlling the visibility of certain "GAL >> >>> Layers" but unfortunately the set of objects that appears >> >>> on one GAL layer is not always equal to the set of >> >>> objects that the user would expect to turn on and off, as >> >>> seen by the bug reports. So, there will have to be some >> >>> additional logic created to manage these settings beyond >> >>> just turning on and off layers in the GAL. >> >>> -Jon >> >>> _______________________________________________ >> >>> Mailing list: https://launchpad.net/~kicad-developers >> >>> <https://launchpad.net/~kicad-developers> >> >>> Post to : kicad-developers@lists.launchpad.net >> >>> <mailto:kicad-developers@lists.launchpad.net> >> >>> Unsubscribe : https://launchpad.net/~kicad-developers >> >>> <https://launchpad.net/~kicad-developers> >> >>> More help : https://help.launchpad.net/ListHelp >> >>> <https://help.launchpad.net/ListHelp> >> >> >> >> _______________________________________________ >> >> Mailing list: https://launchpad.net/~kicad-developers >> >> <https://launchpad.net/~kicad-developers> >> >> Post to : kicad-developers@lists.launchpad.net >> >> <mailto:kicad-developers@lists.launchpad.net> >> >> Unsubscribe : https://launchpad.net/~kicad-developers >> >> <https://launchpad.net/~kicad-developers> >> >> More help : https://help.launchpad.net/ListHelp >> >> <https://help.launchpad.net/ListHelp> >> > >> > >> > _______________________________________________ >> > Mailing list: https://launchpad.net/~kicad-developers >> > <https://launchpad.net/~kicad-developers> >> > Post to : kicad-developers@lists.launchpad.net >> > <mailto:kicad-developers@lists.launchpad.net> >> > Unsubscribe : https://launchpad.net/~kicad-developers >> > <https://launchpad.net/~kicad-developers> >> > More help : https://help.launchpad.net/ListHelp >> > <https://help.launchpad.net/ListHelp> >> > >> > >> > >> > >> > _______________________________________________ >> > Mailing list: https://launchpad.net/~kicad-developers >> > <https://launchpad.net/~kicad-developers> >> > Post to : kicad-developers@lists.launchpad.net >> > <mailto:kicad-developers@lists.launchpad.net> >> > Unsubscribe : https://launchpad.net/~kicad-developers >> > <https://launchpad.net/~kicad-developers> >> > More help : https://help.launchpad.net/ListHelp >> > <https://help.launchpad.net/ListHelp> >> > >> > >> > >> > >> > -- >> > Remember The Past, Live The Present, Change The Future >> > Those who look only to the past or the present are certain to miss the >> > future [JFK] >> > >> > kandre...@gmail.com <mailto:kandre...@gmail.com> >> > Live Long and Prosper, >> > Andrey >> > > > > -- > Remember The Past, Live The Present, Change The Future > Those who look only to the past or the present are certain to miss the > future [JFK] > > kandre...@gmail.com > Live Long and Prosper, > Andrey >
_______________________________________________ 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