kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Yes, that's what I am proposing.

On Fri, Feb 28, 2020 at 11:30 AM Jeff Young <jeff@xxxxxxxxx> 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 <jon@xxxxxxxxxxxxx> 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 <jeff@xxxxxxxxx> 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 <jeff@xxxxxxxxx> wrote:
>>
>> I was thinking Board Settings.  Some of them might be project-specific,
>> no?
>>
>> On 28 Feb 2020, at 02:34, Jon Evans <jon@xxxxxxxxxxxxx> 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 <jeff@xxxxxxxxx> 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.shultz@xxxxxxxxx> 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.kaikkonen@xxxxxxxxx>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 26, 2020 at 1:29 AM Jon Evans <jon@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>