Re: [Kicad-developers] DRC reports

[Jon Evans]

Yes, that's what I am proposing.

On Fri, Feb 28, 2020 at 11:30 AM Jeff Young  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  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  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  wrote:
>>
>> I was thinking Board Settings.  Some of them might be project-specific,
>> no?
>>
>> On 28 Feb 2020, at 02:34, Jon Evans  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  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  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 

Re: [Kicad-developers] DRC reports

[Jeff Young]

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  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  > 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 > > wrote:
>> 
>> I was thinking Board Settings.  Some of them might be project-specific, no?
>> 
>>> On 28 Feb 2020, at 02:34, Jon Evans >> > 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 >> > 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 >>> > 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 

Re: [Kicad-developers] DRC reports

[Jon Evans]

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  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  wrote:
>
> I was thinking Board Settings.  Some of them might be project-specific, no?
>
> On 28 Feb 2020, at 02:34, Jon Evans  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  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  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 

Re: [Kicad-developers] Who has access to confidential issues?

[jp charras]

Le 28/02/2020 à 14:03, Seth Hillbrand a écrit :
> On 2020-02-28 04:59, Eeli Kaikkonen wrote:
> 
>> On Fri, Feb 28, 2020 at 1:55 PM jp charras > > wrote:
>>
>> Unfortunately, issue 3955 does not exist on Gitlab: latest is 3954.
>>
>>
>> -- 
>> Jean-Pierre CHARRAS
>>
>>  
>> That issue exists but is confidential. I have access to it ( I'm a 
>> maintainer in the bugsquad group) . But don't the developers have access to 
>> confidential issues? Obviously it shouldn't be so.
>  
> Developers have access.  But they do need to be logged into GitLab to see the 
> confidential issues.  @JP, @Tom, please let me know if you are and still 
> can't see the issue.
>  
> -S
> 
> 
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
> 

Yes, once logged I have access to this bug report.

-- 
Jean-Pierre CHARRAS

___
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

Re: [Kicad-developers] Who has access to confidential issues?

[Seth Hillbrand]

On 2020-02-28 04:59, Eeli Kaikkonen wrote:

> On Fri, Feb 28, 2020 at 1:55 PM jp charras  wrote: 
> 
>> Unfortunately, issue 3955 does not exist on Gitlab: latest is 3954.
>> 
>> -- 
>> Jean-Pierre CHARRAS
> 
> That issue exists but is confidential. I have access to it ( I'm a maintainer 
> in the bugsquad group) . But don't the developers have access to confidential 
> issues? Obviously it shouldn't be so.

Developers have access.  But they do need to be logged into GitLab to
see the confidential issues.  @JP, @Tom, please let me know if you are
and still can't see the issue. 

-S 

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372___
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

[Kicad-developers] Who has access to confidential issues?

[Eeli Kaikkonen]

On Fri, Feb 28, 2020 at 1:55 PM jp charras  wrote:

> Unfortunately, issue 3955 does not exist on Gitlab: latest is 3954.
>
>
> --
> Jean-Pierre CHARRAS
>
>
That issue exists but is confidential. I have access to it ( I'm a
maintainer in the bugsquad group) . But don't the developers have access to
confidential issues? Obviously it shouldn't be so.

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

Re: [Kicad-developers] pcbnew extremly slow

[Tomasz Wlostowski]

On 28/02/2020 13:00, BERTRAND Joël wrote:
> jp charras a écrit :
>> Le 28/02/2020 à 12:46, BERTRAND Joël a écrit :
>>> BERTRAND Joël a écrit :
 Seth Hillbrand a écrit :

> Hi Joël-
>
> Please open an issue report at
> https://gitlab.com/kicad/code/kicad/issues and attach the project.
>

 Done.
 https://gitlab.com/kicad/code/kicad/issues/3955
>>>
>>> I have simplified my schematic (I have deleted bus labels and grouped
>>> some subcircuits to reduce sheets by 4), result is the same.
>>>
>>
>> Calculation time is closely related to pad count, not sheet count.
>>
>> Unfortunately, issue 3955 does not exist on Gitlab: latest is 3954.
> 
>   Issue 3955 exists but was created with confidential flag. But I can
> send to you my project. My design should contains 25344 pads for sensor
> itself and maybe 1000 pads more for driver.
> 
Hi Joel,

Can you share the design with me on gitlab?

Regards,
Tom

___
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

Re: [Kicad-developers] pcbnew extremly slow

[BERTRAND Joël]

jp charras a écrit :
> Le 28/02/2020 à 12:46, BERTRAND Joël a écrit :
>> BERTRAND Joël a écrit :
>>> Seth Hillbrand a écrit :
>>>
 Hi Joël-

 Please open an issue report at
 https://gitlab.com/kicad/code/kicad/issues and attach the project.

>>>
>>> Done.
>>> https://gitlab.com/kicad/code/kicad/issues/3955
>>
>>  I have simplified my schematic (I have deleted bus labels and grouped
>> some subcircuits to reduce sheets by 4), result is the same.
>>
> 
> Calculation time is closely related to pad count, not sheet count.
> 
> Unfortunately, issue 3955 does not exist on Gitlab: latest is 3954.

Issue 3955 exists but was created with confidential flag. But I can
send to you my project. My design should contains 25344 pads for sensor
itself and maybe 1000 pads more for driver.

Best regards,

JB

___
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

Re: [Kicad-developers] pcbnew extremly slow

[jp charras]

Le 28/02/2020 à 12:46, BERTRAND Joël a écrit :
> BERTRAND Joël a écrit :
>> Seth Hillbrand a écrit :
>>
>>> Hi Joël-
>>>
>>> Please open an issue report at
>>> https://gitlab.com/kicad/code/kicad/issues and attach the project.
>>>
>>
>> Done.
>> https://gitlab.com/kicad/code/kicad/issues/3955
> 
>   I have simplified my schematic (I have deleted bus labels and grouped
> some subcircuits to reduce sheets by 4), result is the same.
> 

Calculation time is closely related to pad count, not sheet count.

Unfortunately, issue 3955 does not exist on Gitlab: latest is 3954.


-- 
Jean-Pierre CHARRAS

___
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

Re: [Kicad-developers] pcbnew extremly slow

[BERTRAND Joël]

BERTRAND Joël a écrit :
> Seth Hillbrand a écrit :
> 
>> Hi Joël-
>>
>> Please open an issue report at
>> https://gitlab.com/kicad/code/kicad/issues and attach the project.
>>
> 
> Done.
> https://gitlab.com/kicad/code/kicad/issues/3955

I have simplified my schematic (I have deleted bus labels and grouped
some subcircuits to reduce sheets by 4), result is the same.

___
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

Re: [Kicad-developers] DRC reports

[Jeff Young]

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  wrote:
> 
> I was thinking Board Settings.  Some of them might be project-specific, no?
> 
>> On 28 Feb 2020, at 02:34, Jon Evans > > 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 > > 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 >> > 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 >> > wrote:
>>> 
>>> 
>>> On Wed, Feb 26, 2020 at 1:29 AM Jon Evans >> > 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 

Re: [Kicad-developers] DRC reports

[Jeff Young]

I was thinking Board Settings.  Some of them might be project-specific, no?

> On 28 Feb 2020, at 02:34, Jon Evans  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  > 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 > > 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 > > wrote:
>> 
>> 
>> On Wed, Feb 26, 2020 at 1:29 AM Jon Evans > > 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 
>>