kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

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: 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> 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> 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> 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
>> 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> 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
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>