I agree settings should be in a different dialog. I kind of think they should go in the main preferences window as another entry (there will be multiple "project level" preferences panes, so DRC/ERC setup could be part of that). That taxonomy of reporting level sounds good to me.
I put my thoughts on taxonomy in a doc here for comment: https://docs.google.com/document/d/1r6tveX475pcCU-Gmv1rKIWM4i8ATsQVoWgNTytc0Ctw/edit# -Jon On Wed, Feb 26, 2020 at 6:22 AM Jeff Young <j...@rokeby.ie> wrote: > OK, I’m coming around to the idea of a hybrid system (tabs + outline + > severity filtering). > > Jon, could you post your violation taxonomy here? > > On the settings front, I do actually think they belong in a different > dialog (a la Allegro). But we could have a right-button menu though that > takes you from an error to the preferences panel. > > The taxonomy I’d propose for the setting would be: > - error > - warning > - info > - ignore > > The first 3 allow filtering; the last one is Allegro’s “off”. > > > On 26 Feb 2020, at 00:34, Evan Shultz <evan.shu...@gmail.com> wrote: > > A few thoughts from the peanut gallery... > > I strongly agree with Jon here, as a power user of Allegro's Constraint > Manager. It simply _is_ complicated to navigate a full-featured design rule > system. There will (may?) not be a way of getting around that when a lot of > constraints have been added. Adding loads of tabs spreads things out which > hurts users who are really using the design rule system. It can be > overbearing at first, and making an easy on-ramp for novice users can be a > challenge, but I would hate to see a powerful design rules system that > doesn't work well for those who want to use it's capabilities. Allegro has > a dialog that turns each constraint on and off, which is totally separate > from setting up the values of each constraint. I personally think bringing > those two together would be helpful as they're tightly integrated. > > If knowing how Allegro does it, simply to get another perspective but > certainly not as an example of the "correct way" to do something in an ECAD > tool is helpful, just let me know. > > It could possibly be easier to manage if a simple graphic pops up for each > design rule showing a generic representation to what that constraint > pertains. Something like the Altium screenshot you showed above, Jon. Being > able to select a DRC marker and then get information about what's causing > it will help all users. Another helpful feature would be if two elements > could be selected and their constraints viewed, so that even if a DRC isn't > being generated the user can query the board. Lastly, some kind of report > would be useful to let a user search for net names and ref des and other > elements to see the design rules in the board, and if the report is > reasonably human-readable it might also suffice for an import/export design > rule file format. > > One way of perhaps using tabs would be to break the pieces of the design > rule system down into different areas: electrical (trace lengths, diff > pairs, etc.), copper (allowable vias, trace widths, etc.), spacing, > silkscreen (silk over pads, min silk line width, courtyards, etc.). That > might allow a tab for each area with a tree system for the constraints > within each area. A spacing matrix is a powerful visualization tool which > could also fit into a tab. > > One thing I haven't seen mentioned are the handling of groups of elements, > such as multiple traces which need their lengths matched or a net class > that contains multiple nets. How that is shown in the UI might require > another level since each of those groups must break out the elements within > it to help the user configure the groups and track down where a DRC is > being generated. > > On Tue, Feb 25, 2020 at 4:12 PM Eeli Kaikkonen <eeli.kaikko...@gmail.com> > wrote: > >> >> >> On Wed, Feb 26, 2020 at 1:29 AM Jon Evans <j...@craftyjon.com> wrote: >> >>> >>> The problem with tabs is that they can only expand so far before you >>> have to start scrolling (and so some tabs are not visible). >>> >>> Yes, that's why I thought a combination of tabs and a tree (or grid as >> you said) may be good. There's still free space for a tab or two. Indeed, >> post-v5 the footprint warnings have got their own. I have always thought >> that the messages about non-continous edge cut don't belong with the rest, >> so I would move them to their own tab. >> >> Eeli Kaikkonen >> _______________________________________________ >> 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
