Yes, that's what I am proposing. On Fri, Feb 28, 2020 at 11:30 AM Jeff Young <j...@rokeby.ie> wrote:
> 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> 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> 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> 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# >> >> -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