kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

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 <mailto: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 <mailto: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 <mailto: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# <https://docs.google.com/document/d/1r6tveX475pcCU-Gmv1rKIWM4i8ATsQVoWgNTytc0Ctw/edit#>
>>> 
>>> -Jon
>>> 
>>> On Wed, Feb 26, 2020 at 6:22 AM Jeff Young <jeff@xxxxxxxxx <mailto: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 <mailto: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 <mailto:eeli.kaikkonen@xxxxxxxxx>> wrote:
>>>> 
>>>> 
>>>> On Wed, Feb 26, 2020 at 1:29 AM Jon Evans <jon@xxxxxxxxxxxxx <mailto: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 <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>
>>>> _______________________________________________
>>>> 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>
>>> 
>>> _______________________________________________
>>> 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>
>> 
>