This will be the end state (more or less) when V6 is ready.
On Wed, Mar 4, 2020, 04:12 yann jautard wrote:
>
> Le 03/03/2020 à 21:55, Wayne Stambaugh a écrit :
> >
> > I'm just wondering about the impact to CVS users of adding them to the
> > project file. I'm not sure if it's an issue or not.
Le 03/03/2020 à 21:55, Wayne Stambaugh a écrit :
I'm just wondering about the impact to CVS users of adding them to the
project file. I'm not sure if it's an issue or not.
Just my two cents on this : from a user point of view, wich use git for
kicad projects, I think it would be better to
Current implementation:
1) persists only the exclusions
2) persists them in the project file as a { error_code, main_item_desc,
main_item_uuid, aux_item_desc, aux_item_uuid } tuple
We can easily break them out if the project file is migrated to multiple JSON
files for 6.0.
Should have somethin
On 3/3/20 3:59 PM, Jon Evans wrote:
> Are you talking about temporary churn to project files?
> In my opinion, I think during the 6.0 development cycle it's okay as
> long as we stabilize by the time we cut a RC.
Churn. But given that it only effects nightly builds, I can live with it.
>
> Agai
Are you talking about temporary churn to project files?
In my opinion, I think during the 6.0 development cycle it's okay as long
as we stabilize by the time we cut a RC.
Again, in my opinion we should only persist the "ignore" rules, not every
marker, and if we take that approach, people won't be
On 3/3/20 8:59 AM, Jon Evans wrote:
> Hi Jeff,
>
> There are several ways to do persistence. It sounds like you are
> planning to implement it as "save the state of all DRC markers", which
> is one way.
> Another way would be to just save the exceptions (aka waived
> violations), so closing and o
The current implementation has checkboxes below the list: [ ] All, [ ]
Errors, [ ] Warnings, [ ] Exclusions.
If you check Exclusions you’ll see them in the main list, but greyed out.
(Strikethrough would have been better, but alas there’s wxWidgets in the way
again.)
> On 3 Mar 2020, at 1
My original UX proposal was to have them in an "ignored" group at the
bottom of the list, collapsed by default but still visible so that things
can be "unignored" without too much trouble.
On Tue, Mar 3, 2020 at 10:20 AM Nhat Khai wrote:
> Instead of persisted:
> 1) Can it has a expiration day,
Hi Jeff,
There are several ways to do persistence. It sounds like you are planning
to implement it as "save the state of all DRC markers", which is one way.
Another way would be to just save the exceptions (aka waived violations),
so closing and opening a board would not return the markers to vie
On 3/3/20 5:04 AM, Jeff Young wrote:
> Part of the 6.0 DRC architecture is marker persistence. This will allow you
> to work your way through a large set of DRC violations, flagging those that
> have already been checked as exceptions or some-such.
>
> Two questions:
>
> 1) Store markers in
Hi Henrik,
> On 3 Mar 2020, at 13:33, Henrik Hansen wrote:
>
> 1) As long as files with markers can be easily shared between people it is
> good.
>
> Why isn't "bloated diff" a problem for storing the markers in the project
> files?
I don’t think people diff their project files, but I know s
1) As long as files with markers can be easily shared between people it is
good.
Why isn't "bloated diff" a problem for storing the markers in the project
files?
Would it make sense to have an option to not store the markers?
2) The second scenario of marking a specific error is the least surpri
Part of the 6.0 DRC architecture is marker persistence. This will allow you to
work your way through a large set of DRC violations, flagging those that have
already been checked as exceptions or some-such.
Two questions:
1) Store markers in board file or project file?
Board file is much easie
13 matches
Mail list logo
