kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

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 <jon@xxxxxxxxxxxxx> 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 <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>> 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 <jon@xxxxxxxxxxxxx <mailto:jon@xxxxxxxxxxxxx>> 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 <jon@xxxxxxxxxxxxx <mailto:jon@xxxxxxxxxxxxx>> 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 <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>