At present Preferences holds only app-wide settings. So if we went in this direction we’d want to do it en-masse.
> On 28 Feb 2020, at 14:48, Jon Evans <j...@craftyjon.com> wrote: > > I did mean Preferences but Board Setup would work as well. > I haven't thought about this *too* hard but (and this is kind of a tangent > from the original topic) I think it might be better to think about > consolidating as many preferences as possible (whether they are global or > project-specific) into subpanes of the Preferences panel. > > My thinking here: > > 1) One-stop-shop means it's easier to remember what dialog to open > 2) We could make the dialog searchable/filterable as is common in commercial > CAD/software dev tools with many preferences > 3) Seeing all things in one location can remind you what settings you may > want to modify for a new project > 4) I think we should implement more nice UI/UX around (a) storing default > settings for all new projects, and (b) importing certain types of settings > from other projects. As this should apply across multiple types of settings > (not just DRC), it seemed to me that it would be easier to have a consistent > UX if everything is inside the Preferences dialog. > > To expand on (4) for a bit, I had a vision of an "Import Settings" pane in > Preferences where you could pick a path to a different project. > We could read that project, see what kind of settings are stored in it, then > present a list of checkboxes of things for the user to import: > > [x] Board setup > [x] DRC settings > [x] Visibility and net color settings > [x] Other project-specific settings > [x] and so on > > But, like I said, this is somewhat of a tangent from the specific matter of > DRC settings -- they could always live in the Board Setup for now, and move > later if we decide to go in the direction I describe. > I do think that there should be no settings in the control dialog (other than > controlling reporting), but where they *do* live I don't feel as strongly > about :-) > > -Jon > > On Fri, Feb 28, 2020 at 6:27 AM Jeff Young <j...@rokeby.ie > <mailto:j...@rokeby.ie>> wrote: > Oops, probably didn’t read your email carefully enough. You also mentioned > project-level, so I assume you also mean Board Setup, not Preferences. > >> On 28 Feb 2020, at 11:26, Jeff Young <j...@rokeby.ie >> <mailto:j...@rokeby.ie>> wrote: >> >> I was thinking Board Settings. Some of them might be project-specific, no? >> >>> On 28 Feb 2020, at 02:34, Jon Evans <j...@craftyjon.com >>> <mailto:j...@craftyjon.com>> wrote: >>> >>> 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# >>> >>> <https://docs.google.com/document/d/1r6tveX475pcCU-Gmv1rKIWM4i8ATsQVoWgNTytc0Ctw/edit#> >>> >>> -Jon >>> >>> On Wed, Feb 26, 2020 at 6:22 AM Jeff Young <j...@rokeby.ie >>> <mailto: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 >>>> <mailto: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 >>>> <mailto:eeli.kaikko...@gmail.com>> wrote: >>>> >>>> >>>> On Wed, Feb 26, 2020 at 1:29 AM Jon Evans <j...@craftyjon.com >>>> <mailto: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 >>>> <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 Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
