You’ve got me half-convinced on collapsing the tabs. But there’s one last issue: running the footprints checks is much slower and so is turned off by default. We partially mitigate that by displaying “not run” in the Footprints tab. I suppose we could put the warning as a single item under a Footprints section, but then you can’t hide it.
I’d still miss quickly checking at different levels. But if we allowed setting an error/warning/info level for each error (or error class), then I could still quickly switch between errors and warnings. At what point are we over-building this, though? > On 25 Feb 2020, at 22:34, Jon Evans <j...@craftyjon.com> wrote: > > Coming from the point of view of using commercial tools, I don't really see > the three tabs as different categories. > An unconnected is a violation: it violates the implicit rule that all net > items must be connected. Generally, advanced tools allow you to override > this default rule. > For example, Altium's default rule for unrouted nets: > <image.png> > You could change the filter so that there are some areas where unrouted nets > are allowed, if you wanted to do your design this way. > > And, there are also clearance rules that fall in the category of "did you > mean ==" in that sometimes you actually know better than the checker (this is > especially true with the current state of what rules are possible to express > in KiCad, but will still be true even with a complex rules engine, in my > experience) > > The way I had been thinking about it is that if there is a type of rule that > you just don't want to see, you would just disable that rule in the project > DRC settings. > The tree would only ever show the hierarchy for violations that exist (i.e. > empty top level sections would be suppressed) so it would not be too > cluttered. > > -Jon > > On Tue, Feb 25, 2020 at 5:27 PM Jeff Young <j...@rokeby.ie > <mailto:j...@rokeby.ie>> wrote: > Now that it’s a tree we could do the 3 level hierarchy pretty easily. In > fact, I started to, but I found it really annoying with my small boards where > I usually only have a handful of errors. That’s when I had the filter > checkbox idea. > > I also thought about collapsing the 3 tabs. But they really are different: > an unconnected isn’t a violation (there’s no rule that it violates). > Similarly, the Footprint Warnings are more like C++’s “did you mean ==” > warning when you use a single “=” in an odd place: they as likely to be wrong > as right. > > I do like the right-click clear and ignore actions. And I think those are > fine to do at the 64-types granularity. But I don’t really want to do that > just to not show courtyard violations. > >> On 25 Feb 2020, at 20:53, Jon Evans <j...@craftyjon.com >> <mailto:j...@craftyjon.com>> wrote: >> >> Some mockup to give context to my earlier reply: >> You could right-click a given violation, and clear (one-time) or ignore >> (persistent) either that particular violation, or all violations of its >> class. >> You could also right-click the class header ("Clearance Violations") and >> clear all / ignore all. >> <image.png> >> >> >> On Tue, Feb 25, 2020 at 3:21 PM Jon Evans <j...@craftyjon.com >> <mailto:j...@craftyjon.com>> wrote: >> The idea I was kicking around was to build a 2-level tree, with the parents >> being these categories (in new drc branch): >> https://gitlab.com/kicad/code/kicad/-/blob/drc/pcbnew/drc/drc_violation.h#L31 >> >> <https://gitlab.com/kicad/code/kicad/-/blob/drc/pcbnew/drc/drc_violation.h#L31> >> I think there are much fewer than 64 error types that actually need to be >> displayed to the user in groups. I'm not sure the enum there has absolutely >> everything, but I do think it's close. >> >> I was planning on getting rid of the 3 tabs -- I don't think it makes sense >> to have the three tabs and also filters in the "violations" tab -- the other >> two tabs are just different types of violations. >> >> I am also not sure how much it makes sense to have checkboxes for >> showing/hiding violations. >> It seems like a better ultimate state would be: >> (a) being able to turn on/off all types of violations (and set their >> severity) >> (b) being able to clear or ignore certain violations or certain classes of >> violations in one go (I was thinking via a context menu on each violation >> and the tree header per violation class) >> >> -Jon >> >> On Tue, Feb 25, 2020 at 2:34 PM Jeff Young <j...@rokeby.ie >> <mailto:j...@rokeby.ie>> wrote: >> I’m looking at adding filtering to the DRC window. I’d like to use >> something similar to the HTML report panel where we’d have some checkboxes >> under the listbox: >> >> [ ] Show All [ ] Clearances [ ] Constraints [ ] Courtyards >> >> It would be nice and consistent to then have a Save button after that. But >> this would be a slight procedural change: >> 1) it would separate the reports by the 3 tabs: Violations, Unconnected, >> Footprint Warnings >> 2) you couldn’t set it and forget it: you’d have to click the Save button >> each time you wanted a report >> >> Thoughts? >> >> Note: yes, I did consider user-defined filtering. But we currently have 64 >> DRC error types, and I’m not sure users really want to wade through that >> list (nor do we want to have to reply to queries of the form “what does DRC >> error type XYZ include?” >> >> Note 2: regardless of that, feel free to comment on anything (including “we >> really must have user-defined filtering”). >> _______________________________________________ >> 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
