Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread 'Stefan Weber' via KiCad Developers

thank you all for this fruitful discussion

Am 04.05.24 um 16:48 schrieb Jeff Young:

I'll work on the quick version as a start


:thumbsup:




--
You received this message because you are subscribed to the Google Groups "KiCad 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to devlist+unsubscr...@kicad.org.
To view this discussion on the web visit 
https://groups.google.com/a/kicad.org/d/msgid/devlist/0ddb4030-6ea3-464b-8e79-965f5781e428%40gmx.ch.


Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread Jeff Young
> I'll work on the quick version as a start

:thumbsup:


-- 
You received this message because you are subscribed to the Google Groups 
"KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to devlist+unsubscr...@kicad.org.
To view this discussion on the web visit 
https://groups.google.com/a/kicad.org/d/msgid/devlist/C9F4AC3F-0724-4EFD-A2EB-7F0D0D3504F1%40rokeby.ie.


Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread Jon Evans
I'll work on the quick version as a start

On Sat, May 4, 2024 at 10:36 AM Wayne Stambaugh  wrote:
>
> Until we have a more elegant solution such as Jon's info bar suggestion,
> we could do something similar for libraries by using an option in the
> library table entry.
>
> On 5/4/24 10:30 AM, 'Seth Hillbrand' via KiCad Developers wrote:
> > For importing boards, we could
> >
> > 1) Add a checkbox at the bottom of the import non-KiCad dialog that says
> > "Show import errors"
> >
> > and/or
> >
> > 2) Move the error reporter to a docked AUI window so that it doesn't
> > interrupt the workflow
> >
> > Seth
> > KiCad Services Corporation Logo
> > Seth Hillbrand
> > *Lead Developer*
> > +1-530-302-5483‬
> > Long Beach, CA
> > www.kipro-pcb.com  i...@kipro-pcb.com
> > 
> >
> >
> >
> > On Sat, May 4, 2024 at 7:24 AM Jon Evans  > > wrote:
> >
> > Following up, I think it's important to understand the places the
> > importer is used for my team (and probably others who use a mix of
> > tools)
> >
> > The importers are rarely used as a "one shot" tool to convert a
> > design permanently from a different CAD tool to KiCad. Instead, we
> > use the importers persistently. For example, we directly add
> > non-KiCad libraries to the table (which triggers parsing them in
> > many different places, as Seth mentioned). But, we also use KiCad as
> > a viewer for non-KiCad board and schematic files. We open these
> > files over and over again, and having that open process blocked by a
> > dialog is a real interruption.
> >
> > I would expect dialogs to only appear when a serious error has
> > happened that is not recoverable. Information that KiCad does not
> > support a certain feature from an external file is not even an
> > error, let alone a serious one.
> >
> > -Jon
> >
> >
> > On Sat, May 4, 2024, 10:20 Jon Evans  > > wrote:
> >
> > I agree that the information should be exposed somewhere. But I
> > think interrupting the load process with a dialog is a nag. It
> > gets in the way of using KiCad as an efficient way to view files
> > designed in other programs.
> >
> > On Sat, May 4, 2024, 09:52 Jeff Young  > > wrote:
> >
> > I don’t agree.  A nag dialog would be something that told
> > you we don’t have an editing feature that Altium supports,
> > not that we can’t express the same end result as we found in
> > the Altium file.
> >
> > There are certainly border-line cases.  Complaining about
> > not being able to import a datum dimension is a bit closer
> > to an editing feature.  But if it’s something like
> > pad-stacks, then I’m going to have to make changes somewhere
> > to get the design right.  So I’d rather know about those.
> >
> >  > On 4 May 2024, at 14:29, Jon Evans  > > wrote:
> >  >
> >  >> The only place we disagree is what to do in the meantime
> > for schematics and boards.
> >  >
> >  > Using wxLog to pop up dialogs reporting that KiCad does
> > not support
> >  > some feature of some other EDA tool is inappropriate in
> > my opinion.
> >  > It goes against the KiCad guideline of not showing nag
> > dialogs.  I
> >  > don't think boards/schematics are any different from
> > libraries in this
> >  > regard.
> >  >
> >  > On Sat, May 4, 2024 at 9:24 AM Jeff Young  > > wrote:
> >  >>
> >  >> We do report context info (at least line number and
> > offset) in some of the other importers.
> >  >>
> >  >> I agree that the system could be improved.
> >  >> And I agree that we have to do something about the
> > library importing.
> >  >>
> >  >> The only place we disagree is what to do in the meantime
> > for schematics and boards.
> >  >>
> >  >> Cheers,
> >  >> Jeff.
> >  >>
> >  >>> On 4 May 2024, at 13:04, Jon Evans  > > wrote:
> >  >>>
> >  >>> Jeff,
> >  >>>
> >  >>> In both cases I disagree that the current warning
> > system should
> >  >>> appear.  The warning system we have today is really not
> > that helpful,
> >  >>> and I don't want to bring it back the same way for
> > boards or for
> >  >>> libraries.
> >  >>> The advanced_config optio

Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread Wayne Stambaugh
Until we have a more elegant solution such as Jon's info bar suggestion, 
we could do something similar for libraries by using an option in the 
library table entry.


On 5/4/24 10:30 AM, 'Seth Hillbrand' via KiCad Developers wrote:

For importing boards, we could

1) Add a checkbox at the bottom of the import non-KiCad dialog that says 
"Show import errors"


and/or

2) Move the error reporter to a docked AUI window so that it doesn't 
interrupt the workflow


Seth
KiCad Services Corporation Logo
Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬
Long Beach, CA
www.kipro-pcb.com  i...@kipro-pcb.com 





On Sat, May 4, 2024 at 7:24 AM Jon Evans > wrote:


Following up, I think it's important to understand the places the
importer is used for my team (and probably others who use a mix of
tools)

The importers are rarely used as a "one shot" tool to convert a
design permanently from a different CAD tool to KiCad. Instead, we
use the importers persistently. For example, we directly add
non-KiCad libraries to the table (which triggers parsing them in
many different places, as Seth mentioned). But, we also use KiCad as
a viewer for non-KiCad board and schematic files. We open these
files over and over again, and having that open process blocked by a
dialog is a real interruption.

I would expect dialogs to only appear when a serious error has
happened that is not recoverable. Information that KiCad does not
support a certain feature from an external file is not even an
error, let alone a serious one.

-Jon


On Sat, May 4, 2024, 10:20 Jon Evans mailto:j...@craftyjon.com>> wrote:

I agree that the information should be exposed somewhere. But I
think interrupting the load process with a dialog is a nag. It
gets in the way of using KiCad as an efficient way to view files
designed in other programs.

On Sat, May 4, 2024, 09:52 Jeff Young mailto:j...@rokeby.ie>> wrote:

I don’t agree.  A nag dialog would be something that told
you we don’t have an editing feature that Altium supports,
not that we can’t express the same end result as we found in
the Altium file.

There are certainly border-line cases.  Complaining about
not being able to import a datum dimension is a bit closer
to an editing feature.  But if it’s something like
pad-stacks, then I’m going to have to make changes somewhere
to get the design right.  So I’d rather know about those.

 > On 4 May 2024, at 14:29, Jon Evans mailto:j...@craftyjon.com>> wrote:
 >
 >> The only place we disagree is what to do in the meantime
for schematics and boards.
 >
 > Using wxLog to pop up dialogs reporting that KiCad does
not support
 > some feature of some other EDA tool is inappropriate in
my opinion.
 > It goes against the KiCad guideline of not showing nag
dialogs.  I
 > don't think boards/schematics are any different from
libraries in this
 > regard.
 >
 > On Sat, May 4, 2024 at 9:24 AM Jeff Young mailto:j...@rokeby.ie>> wrote:
 >>
 >> We do report context info (at least line number and
offset) in some of the other importers.
 >>
 >> I agree that the system could be improved.
 >> And I agree that we have to do something about the
library importing.
 >>
 >> The only place we disagree is what to do in the meantime
for schematics and boards.
 >>
 >> Cheers,
 >> Jeff.
 >>
 >>> On 4 May 2024, at 13:04, Jon Evans mailto:j...@craftyjon.com>> wrote:
 >>>
 >>> Jeff,
 >>>
 >>> In both cases I disagree that the current warning
system should
 >>> appear.  The warning system we have today is really not
that helpful,
 >>> and I don't want to bring it back the same way for
boards or for
 >>> libraries.
 >>> The advanced_config option was something Seth and I
discussed as a
 >>> simple stopgap for V8 if we are looking at something
better for V9.
 >>>
 >>> A more helpful warning system:
 >>> - Would not use pop-up dialogs that block the UI to let
people know
 >>> that any warnings exist (instead would show up in the
info bar, the
 >>> same way our previous-format-version warning does)
 >>> - Would have a more rich system of logging, so that
people always get

Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread 'Seth Hillbrand' via KiCad Developers
I like it.  Works for me.

[image: KiCad Services Corporation Logo]
Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬
Long Beach, CA
www.kipro-pcb.comi...@kipro-pcb.com


On Sat, May 4, 2024 at 7:34 AM Jon Evans  wrote:

> I think a variant of (2) where we move the messages to a custom dialog and
> show an info at with a button to open the dialog would be faster (adding
> new AUI is going to be more complex IMO)
>
> (1) makes sense to me for 8.x
>
> On Sat, May 4, 2024, 10:30 'Seth Hillbrand' via KiCad Developers <
> devlist@kicad.org> wrote:
>
>> For importing boards, we could
>>
>> 1) Add a checkbox at the bottom of the import non-KiCad dialog that says
>> "Show import errors"
>>
>> and/or
>>
>> 2) Move the error reporter to a docked AUI window so that it doesn't
>> interrupt the workflow
>>
>> Seth
>> [image: KiCad Services Corporation Logo]
>> Seth Hillbrand
>> *Lead Developer*
>> +1-530-302-5483‬
>> Long Beach, CA
>> www.kipro-pcb.comi...@kipro-pcb.com
>>
>>
>> On Sat, May 4, 2024 at 7:24 AM Jon Evans  wrote:
>>
>>> Following up, I think it's important to understand the places the
>>> importer is used for my team (and probably others who use a mix of tools)
>>>
>>> The importers are rarely used as a "one shot" tool to convert a design
>>> permanently from a different CAD tool to KiCad. Instead, we use the
>>> importers persistently. For example, we directly add non-KiCad libraries to
>>> the table (which triggers parsing them in many different places, as Seth
>>> mentioned). But, we also use KiCad as a viewer for non-KiCad board and
>>> schematic files. We open these files over and over again, and having that
>>> open process blocked by a dialog is a real interruption.
>>>
>>> I would expect dialogs to only appear when a serious error has happened
>>> that is not recoverable. Information that KiCad does not support a certain
>>> feature from an external file is not even an error, let alone a serious
>>> one.
>>>
>>> -Jon
>>>
>>>
>>> On Sat, May 4, 2024, 10:20 Jon Evans  wrote:
>>>
 I agree that the information should be exposed somewhere. But I think
 interrupting the load process with a dialog is a nag. It gets in the way of
 using KiCad as an efficient way to view files designed in other programs.

 On Sat, May 4, 2024, 09:52 Jeff Young  wrote:

> I don’t agree.  A nag dialog would be something that told you we don’t
> have an editing feature that Altium supports, not that we can’t express 
> the
> same end result as we found in the Altium file.
>
> There are certainly border-line cases.  Complaining about not being
> able to import a datum dimension is a bit closer to an editing feature.
> But if it’s something like pad-stacks, then I’m going to have to make
> changes somewhere to get the design right.  So I’d rather know about 
> those.
>
> > On 4 May 2024, at 14:29, Jon Evans  wrote:
> >
> >> The only place we disagree is what to do in the meantime for
> schematics and boards.
> >
> > Using wxLog to pop up dialogs reporting that KiCad does not support
> > some feature of some other EDA tool is inappropriate in my opinion.
> > It goes against the KiCad guideline of not showing nag dialogs.  I
> > don't think boards/schematics are any different from libraries in
> this
> > regard.
> >
> > On Sat, May 4, 2024 at 9:24 AM Jeff Young  wrote:
> >>
> >> We do report context info (at least line number and offset) in some
> of the other importers.
> >>
> >> I agree that the system could be improved.
> >> And I agree that we have to do something about the library
> importing.
> >>
> >> The only place we disagree is what to do in the meantime for
> schematics and boards.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>> On 4 May 2024, at 13:04, Jon Evans  wrote:
> >>>
> >>> Jeff,
> >>>
> >>> In both cases I disagree that the current warning system should
> >>> appear.  The warning system we have today is really not that
> helpful,
> >>> and I don't want to bring it back the same way for boards or for
> >>> libraries.
> >>> The advanced_config option was something Seth and I discussed as a
> >>> simple stopgap for V8 if we are looking at something better for V9.
> >>>
> >>> A more helpful warning system:
> >>> - Would not use pop-up dialogs that block the UI to let people know
> >>> that any warnings exist (instead would show up in the info bar, the
> >>> same way our previous-format-version warning does)
> >>> - Would have a more rich system of logging, so that people always
> get
> >>> context about what part of their file had an issue
> >>>
> >>> I think if we want to show this info, we need a new kind of
> REPORTER
> >>> that can capture context rather than just a string, and a
> "post-import
> >>> report" dialog launched from the infoba

Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread Jon Evans
I think a variant of (2) where we move the messages to a custom dialog and
show an info at with a button to open the dialog would be faster (adding
new AUI is going to be more complex IMO)

(1) makes sense to me for 8.x

On Sat, May 4, 2024, 10:30 'Seth Hillbrand' via KiCad Developers <
devlist@kicad.org> wrote:

> For importing boards, we could
>
> 1) Add a checkbox at the bottom of the import non-KiCad dialog that says
> "Show import errors"
>
> and/or
>
> 2) Move the error reporter to a docked AUI window so that it doesn't
> interrupt the workflow
>
> Seth
> [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬
> Long Beach, CA
> www.kipro-pcb.comi...@kipro-pcb.com
>
>
> On Sat, May 4, 2024 at 7:24 AM Jon Evans  wrote:
>
>> Following up, I think it's important to understand the places the
>> importer is used for my team (and probably others who use a mix of tools)
>>
>> The importers are rarely used as a "one shot" tool to convert a design
>> permanently from a different CAD tool to KiCad. Instead, we use the
>> importers persistently. For example, we directly add non-KiCad libraries to
>> the table (which triggers parsing them in many different places, as Seth
>> mentioned). But, we also use KiCad as a viewer for non-KiCad board and
>> schematic files. We open these files over and over again, and having that
>> open process blocked by a dialog is a real interruption.
>>
>> I would expect dialogs to only appear when a serious error has happened
>> that is not recoverable. Information that KiCad does not support a certain
>> feature from an external file is not even an error, let alone a serious
>> one.
>>
>> -Jon
>>
>>
>> On Sat, May 4, 2024, 10:20 Jon Evans  wrote:
>>
>>> I agree that the information should be exposed somewhere. But I think
>>> interrupting the load process with a dialog is a nag. It gets in the way of
>>> using KiCad as an efficient way to view files designed in other programs.
>>>
>>> On Sat, May 4, 2024, 09:52 Jeff Young  wrote:
>>>
 I don’t agree.  A nag dialog would be something that told you we don’t
 have an editing feature that Altium supports, not that we can’t express the
 same end result as we found in the Altium file.

 There are certainly border-line cases.  Complaining about not being
 able to import a datum dimension is a bit closer to an editing feature.
 But if it’s something like pad-stacks, then I’m going to have to make
 changes somewhere to get the design right.  So I’d rather know about those.

 > On 4 May 2024, at 14:29, Jon Evans  wrote:
 >
 >> The only place we disagree is what to do in the meantime for
 schematics and boards.
 >
 > Using wxLog to pop up dialogs reporting that KiCad does not support
 > some feature of some other EDA tool is inappropriate in my opinion.
 > It goes against the KiCad guideline of not showing nag dialogs.  I
 > don't think boards/schematics are any different from libraries in this
 > regard.
 >
 > On Sat, May 4, 2024 at 9:24 AM Jeff Young  wrote:
 >>
 >> We do report context info (at least line number and offset) in some
 of the other importers.
 >>
 >> I agree that the system could be improved.
 >> And I agree that we have to do something about the library importing.
 >>
 >> The only place we disagree is what to do in the meantime for
 schematics and boards.
 >>
 >> Cheers,
 >> Jeff.
 >>
 >>> On 4 May 2024, at 13:04, Jon Evans  wrote:
 >>>
 >>> Jeff,
 >>>
 >>> In both cases I disagree that the current warning system should
 >>> appear.  The warning system we have today is really not that
 helpful,
 >>> and I don't want to bring it back the same way for boards or for
 >>> libraries.
 >>> The advanced_config option was something Seth and I discussed as a
 >>> simple stopgap for V8 if we are looking at something better for V9.
 >>>
 >>> A more helpful warning system:
 >>> - Would not use pop-up dialogs that block the UI to let people know
 >>> that any warnings exist (instead would show up in the info bar, the
 >>> same way our previous-format-version warning does)
 >>> - Would have a more rich system of logging, so that people always
 get
 >>> context about what part of their file had an issue
 >>>
 >>> I think if we want to show this info, we need a new kind of REPORTER
 >>> that can capture context rather than just a string, and a
 "post-import
 >>> report" dialog launched from the infobar.
 >>>
 >>> The library loader can keep track of these on a per-library basis so
 >>> that the infobar can be shown in the symbol/footprint editor after
 >>> launch.
 >>>
 >>> -Jon
 >>>
 >>> On Sat, May 4, 2024 at 4:53 AM Jeff Young  wrote:
 
  Presumably we can tell the difference (in the code) between a
 schematic or lay

Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread 'Seth Hillbrand' via KiCad Developers
For importing boards, we could

1) Add a checkbox at the bottom of the import non-KiCad dialog that says
"Show import errors"

and/or

2) Move the error reporter to a docked AUI window so that it doesn't
interrupt the workflow

Seth
[image: KiCad Services Corporation Logo]
Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬
Long Beach, CA
www.kipro-pcb.comi...@kipro-pcb.com


On Sat, May 4, 2024 at 7:24 AM Jon Evans  wrote:

> Following up, I think it's important to understand the places the importer
> is used for my team (and probably others who use a mix of tools)
>
> The importers are rarely used as a "one shot" tool to convert a design
> permanently from a different CAD tool to KiCad. Instead, we use the
> importers persistently. For example, we directly add non-KiCad libraries to
> the table (which triggers parsing them in many different places, as Seth
> mentioned). But, we also use KiCad as a viewer for non-KiCad board and
> schematic files. We open these files over and over again, and having that
> open process blocked by a dialog is a real interruption.
>
> I would expect dialogs to only appear when a serious error has happened
> that is not recoverable. Information that KiCad does not support a certain
> feature from an external file is not even an error, let alone a serious
> one.
>
> -Jon
>
>
> On Sat, May 4, 2024, 10:20 Jon Evans  wrote:
>
>> I agree that the information should be exposed somewhere. But I think
>> interrupting the load process with a dialog is a nag. It gets in the way of
>> using KiCad as an efficient way to view files designed in other programs.
>>
>> On Sat, May 4, 2024, 09:52 Jeff Young  wrote:
>>
>>> I don’t agree.  A nag dialog would be something that told you we don’t
>>> have an editing feature that Altium supports, not that we can’t express the
>>> same end result as we found in the Altium file.
>>>
>>> There are certainly border-line cases.  Complaining about not being able
>>> to import a datum dimension is a bit closer to an editing feature.  But if
>>> it’s something like pad-stacks, then I’m going to have to make changes
>>> somewhere to get the design right.  So I’d rather know about those.
>>>
>>> > On 4 May 2024, at 14:29, Jon Evans  wrote:
>>> >
>>> >> The only place we disagree is what to do in the meantime for
>>> schematics and boards.
>>> >
>>> > Using wxLog to pop up dialogs reporting that KiCad does not support
>>> > some feature of some other EDA tool is inappropriate in my opinion.
>>> > It goes against the KiCad guideline of not showing nag dialogs.  I
>>> > don't think boards/schematics are any different from libraries in this
>>> > regard.
>>> >
>>> > On Sat, May 4, 2024 at 9:24 AM Jeff Young  wrote:
>>> >>
>>> >> We do report context info (at least line number and offset) in some
>>> of the other importers.
>>> >>
>>> >> I agree that the system could be improved.
>>> >> And I agree that we have to do something about the library importing.
>>> >>
>>> >> The only place we disagree is what to do in the meantime for
>>> schematics and boards.
>>> >>
>>> >> Cheers,
>>> >> Jeff.
>>> >>
>>> >>> On 4 May 2024, at 13:04, Jon Evans  wrote:
>>> >>>
>>> >>> Jeff,
>>> >>>
>>> >>> In both cases I disagree that the current warning system should
>>> >>> appear.  The warning system we have today is really not that helpful,
>>> >>> and I don't want to bring it back the same way for boards or for
>>> >>> libraries.
>>> >>> The advanced_config option was something Seth and I discussed as a
>>> >>> simple stopgap for V8 if we are looking at something better for V9.
>>> >>>
>>> >>> A more helpful warning system:
>>> >>> - Would not use pop-up dialogs that block the UI to let people know
>>> >>> that any warnings exist (instead would show up in the info bar, the
>>> >>> same way our previous-format-version warning does)
>>> >>> - Would have a more rich system of logging, so that people always get
>>> >>> context about what part of their file had an issue
>>> >>>
>>> >>> I think if we want to show this info, we need a new kind of REPORTER
>>> >>> that can capture context rather than just a string, and a
>>> "post-import
>>> >>> report" dialog launched from the infobar.
>>> >>>
>>> >>> The library loader can keep track of these on a per-library basis so
>>> >>> that the infobar can be shown in the symbol/footprint editor after
>>> >>> launch.
>>> >>>
>>> >>> -Jon
>>> >>>
>>> >>> On Sat, May 4, 2024 at 4:53 AM Jeff Young  wrote:
>>> 
>>>  Presumably we can tell the difference (in the code) between a
>>> schematic or layout import and a library import?
>>> 
>>>  It would seem to me like a schematic or layout import should show
>>> the warnings (even without an advanced setting or the like).
>>> 
>>>  Personally I also think the library importer should show the
>>> warnings the very first time.  Maybe we could do that by setting a plugin
>>> option (m_warningsShown or something) after reading the library?  I think
>>> those are saved per-row in the l

Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread Jon Evans
Following up, I think it's important to understand the places the importer
is used for my team (and probably others who use a mix of tools)

The importers are rarely used as a "one shot" tool to convert a design
permanently from a different CAD tool to KiCad. Instead, we use the
importers persistently. For example, we directly add non-KiCad libraries to
the table (which triggers parsing them in many different places, as Seth
mentioned). But, we also use KiCad as a viewer for non-KiCad board and
schematic files. We open these files over and over again, and having that
open process blocked by a dialog is a real interruption.

I would expect dialogs to only appear when a serious error has happened
that is not recoverable. Information that KiCad does not support a certain
feature from an external file is not even an error, let alone a serious
one.

-Jon


On Sat, May 4, 2024, 10:20 Jon Evans  wrote:

> I agree that the information should be exposed somewhere. But I think
> interrupting the load process with a dialog is a nag. It gets in the way of
> using KiCad as an efficient way to view files designed in other programs.
>
> On Sat, May 4, 2024, 09:52 Jeff Young  wrote:
>
>> I don’t agree.  A nag dialog would be something that told you we don’t
>> have an editing feature that Altium supports, not that we can’t express the
>> same end result as we found in the Altium file.
>>
>> There are certainly border-line cases.  Complaining about not being able
>> to import a datum dimension is a bit closer to an editing feature.  But if
>> it’s something like pad-stacks, then I’m going to have to make changes
>> somewhere to get the design right.  So I’d rather know about those.
>>
>> > On 4 May 2024, at 14:29, Jon Evans  wrote:
>> >
>> >> The only place we disagree is what to do in the meantime for
>> schematics and boards.
>> >
>> > Using wxLog to pop up dialogs reporting that KiCad does not support
>> > some feature of some other EDA tool is inappropriate in my opinion.
>> > It goes against the KiCad guideline of not showing nag dialogs.  I
>> > don't think boards/schematics are any different from libraries in this
>> > regard.
>> >
>> > On Sat, May 4, 2024 at 9:24 AM Jeff Young  wrote:
>> >>
>> >> We do report context info (at least line number and offset) in some of
>> the other importers.
>> >>
>> >> I agree that the system could be improved.
>> >> And I agree that we have to do something about the library importing.
>> >>
>> >> The only place we disagree is what to do in the meantime for
>> schematics and boards.
>> >>
>> >> Cheers,
>> >> Jeff.
>> >>
>> >>> On 4 May 2024, at 13:04, Jon Evans  wrote:
>> >>>
>> >>> Jeff,
>> >>>
>> >>> In both cases I disagree that the current warning system should
>> >>> appear.  The warning system we have today is really not that helpful,
>> >>> and I don't want to bring it back the same way for boards or for
>> >>> libraries.
>> >>> The advanced_config option was something Seth and I discussed as a
>> >>> simple stopgap for V8 if we are looking at something better for V9.
>> >>>
>> >>> A more helpful warning system:
>> >>> - Would not use pop-up dialogs that block the UI to let people know
>> >>> that any warnings exist (instead would show up in the info bar, the
>> >>> same way our previous-format-version warning does)
>> >>> - Would have a more rich system of logging, so that people always get
>> >>> context about what part of their file had an issue
>> >>>
>> >>> I think if we want to show this info, we need a new kind of REPORTER
>> >>> that can capture context rather than just a string, and a "post-import
>> >>> report" dialog launched from the infobar.
>> >>>
>> >>> The library loader can keep track of these on a per-library basis so
>> >>> that the infobar can be shown in the symbol/footprint editor after
>> >>> launch.
>> >>>
>> >>> -Jon
>> >>>
>> >>> On Sat, May 4, 2024 at 4:53 AM Jeff Young  wrote:
>> 
>>  Presumably we can tell the difference (in the code) between a
>> schematic or layout import and a library import?
>> 
>>  It would seem to me like a schematic or layout import should show
>> the warnings (even without an advanced setting or the like).
>> 
>>  Personally I also think the library importer should show the
>> warnings the very first time.  Maybe we could do that by setting a plugin
>> option (m_warningsShown or something) after reading the library?  I think
>> those are saved per-row in the lib table, but I’m not 100% sure.
>> 
>>  Cheers,
>>  Jeff.
>> 
>> 
>>  On 4 May 2024, at 09:47, 'Stefan Weber' via KiCad Developers <
>> devlist@kicad.org> wrote:
>> 
>>  Hi,
>> 
>>  I recently started a discussion with @Jon Evans in my MR
>> https://gitlab.com/kicad/code/kicad/-/merge_requests/1935 regarding the
>> visibility of Altium importer warning & errors for not yet supported
>> schematic and layout features.
>> 
>>  Since commit
>> https://gitlab.com/kicad/code/kicad/-/commit/83be5ba63d82

Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread Jon Evans
I agree that the information should be exposed somewhere. But I think
interrupting the load process with a dialog is a nag. It gets in the way of
using KiCad as an efficient way to view files designed in other programs.

On Sat, May 4, 2024, 09:52 Jeff Young  wrote:

> I don’t agree.  A nag dialog would be something that told you we don’t
> have an editing feature that Altium supports, not that we can’t express the
> same end result as we found in the Altium file.
>
> There are certainly border-line cases.  Complaining about not being able
> to import a datum dimension is a bit closer to an editing feature.  But if
> it’s something like pad-stacks, then I’m going to have to make changes
> somewhere to get the design right.  So I’d rather know about those.
>
> > On 4 May 2024, at 14:29, Jon Evans  wrote:
> >
> >> The only place we disagree is what to do in the meantime for schematics
> and boards.
> >
> > Using wxLog to pop up dialogs reporting that KiCad does not support
> > some feature of some other EDA tool is inappropriate in my opinion.
> > It goes against the KiCad guideline of not showing nag dialogs.  I
> > don't think boards/schematics are any different from libraries in this
> > regard.
> >
> > On Sat, May 4, 2024 at 9:24 AM Jeff Young  wrote:
> >>
> >> We do report context info (at least line number and offset) in some of
> the other importers.
> >>
> >> I agree that the system could be improved.
> >> And I agree that we have to do something about the library importing.
> >>
> >> The only place we disagree is what to do in the meantime for schematics
> and boards.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>> On 4 May 2024, at 13:04, Jon Evans  wrote:
> >>>
> >>> Jeff,
> >>>
> >>> In both cases I disagree that the current warning system should
> >>> appear.  The warning system we have today is really not that helpful,
> >>> and I don't want to bring it back the same way for boards or for
> >>> libraries.
> >>> The advanced_config option was something Seth and I discussed as a
> >>> simple stopgap for V8 if we are looking at something better for V9.
> >>>
> >>> A more helpful warning system:
> >>> - Would not use pop-up dialogs that block the UI to let people know
> >>> that any warnings exist (instead would show up in the info bar, the
> >>> same way our previous-format-version warning does)
> >>> - Would have a more rich system of logging, so that people always get
> >>> context about what part of their file had an issue
> >>>
> >>> I think if we want to show this info, we need a new kind of REPORTER
> >>> that can capture context rather than just a string, and a "post-import
> >>> report" dialog launched from the infobar.
> >>>
> >>> The library loader can keep track of these on a per-library basis so
> >>> that the infobar can be shown in the symbol/footprint editor after
> >>> launch.
> >>>
> >>> -Jon
> >>>
> >>> On Sat, May 4, 2024 at 4:53 AM Jeff Young  wrote:
> 
>  Presumably we can tell the difference (in the code) between a
> schematic or layout import and a library import?
> 
>  It would seem to me like a schematic or layout import should show the
> warnings (even without an advanced setting or the like).
> 
>  Personally I also think the library importer should show the warnings
> the very first time.  Maybe we could do that by setting a plugin option
> (m_warningsShown or something) after reading the library?  I think those
> are saved per-row in the lib table, but I’m not 100% sure.
> 
>  Cheers,
>  Jeff.
> 
> 
>  On 4 May 2024, at 09:47, 'Stefan Weber' via KiCad Developers <
> devlist@kicad.org> wrote:
> 
>  Hi,
> 
>  I recently started a discussion with @Jon Evans in my MR
> https://gitlab.com/kicad/code/kicad/-/merge_requests/1935 regarding the
> visibility of Altium importer warning & errors for not yet supported
> schematic and layout features.
> 
>  Since commit
> https://gitlab.com/kicad/code/kicad/-/commit/83be5ba63d82e237b8944ee6ee7c639215b14027
> the Kicad Altium Importer does no longer shows warning & errors for not yet
> supported schematic and layout features in release builds.
> 
>  As Jon mentioned this was implemented to get rid of those annoying
> warnings which pop-up every time you use an Altium library which contains a
> not yet supported schematic and layout features. This I absolutely
> understand.
> 
>  I also do not expect that importing data from other EDA tools will be
> 100% accurate. But as the importer already knows it's limits I personally
> would like to have the possibility to get those warnings and errors back
> when I am importing an Altium schematic or layout.
> 
>  Jon mentioned:
> 
>  "I would be fine with adding some new way to show these optionally,
> in a less obtrusive way."
> 
>  "We try to avoid settings wherever possible. It is best to come up
> with a solution that can be enabled for everyone, meaning that people who
> want the inform

Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread 'Seth Hillbrand' via KiCad Developers
For board imports, I agree with the desire to know what is missing.  The
current report is not helpful in this regard because it tells you that
something is missing without enough context to do anything about it.

For library imports, this needs something completely different.  Especially
as we generally try to load libraries in the background.  A lot of work (as
you know) went into making the load process as short as possible.  This is
broken when we need to then find/close the pop up nag dialog.  For example,
footprint libraries are loaded in multiple places (Footprint editor,
footprint chooser, symbol chooser, footprint viewer).  If I'm trying to
place a new resistor in the schematic editor, I don't want to deal with the
dialog box about a missing padstack in an MCU.

Maybe we could attach the information to the library element itself, so
that when it is used, you can view compatibility information.

Seth


[image: KiCad Services Corporation Logo]
Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬
Long Beach, CA
www.kipro-pcb.comi...@kipro-pcb.com


On Sat, May 4, 2024 at 6:52 AM Jeff Young  wrote:

> I don’t agree.  A nag dialog would be something that told you we don’t
> have an editing feature that Altium supports, not that we can’t express the
> same end result as we found in the Altium file.
>
> There are certainly border-line cases.  Complaining about not being able
> to import a datum dimension is a bit closer to an editing feature.  But if
> it’s something like pad-stacks, then I’m going to have to make changes
> somewhere to get the design right.  So I’d rather know about those.
>
> > On 4 May 2024, at 14:29, Jon Evans  wrote:
> >
> >> The only place we disagree is what to do in the meantime for schematics
> and boards.
> >
> > Using wxLog to pop up dialogs reporting that KiCad does not support
> > some feature of some other EDA tool is inappropriate in my opinion.
> > It goes against the KiCad guideline of not showing nag dialogs.  I
> > don't think boards/schematics are any different from libraries in this
> > regard.
> >
> > On Sat, May 4, 2024 at 9:24 AM Jeff Young  wrote:
> >>
> >> We do report context info (at least line number and offset) in some of
> the other importers.
> >>
> >> I agree that the system could be improved.
> >> And I agree that we have to do something about the library importing.
> >>
> >> The only place we disagree is what to do in the meantime for schematics
> and boards.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>> On 4 May 2024, at 13:04, Jon Evans  wrote:
> >>>
> >>> Jeff,
> >>>
> >>> In both cases I disagree that the current warning system should
> >>> appear.  The warning system we have today is really not that helpful,
> >>> and I don't want to bring it back the same way for boards or for
> >>> libraries.
> >>> The advanced_config option was something Seth and I discussed as a
> >>> simple stopgap for V8 if we are looking at something better for V9.
> >>>
> >>> A more helpful warning system:
> >>> - Would not use pop-up dialogs that block the UI to let people know
> >>> that any warnings exist (instead would show up in the info bar, the
> >>> same way our previous-format-version warning does)
> >>> - Would have a more rich system of logging, so that people always get
> >>> context about what part of their file had an issue
> >>>
> >>> I think if we want to show this info, we need a new kind of REPORTER
> >>> that can capture context rather than just a string, and a "post-import
> >>> report" dialog launched from the infobar.
> >>>
> >>> The library loader can keep track of these on a per-library basis so
> >>> that the infobar can be shown in the symbol/footprint editor after
> >>> launch.
> >>>
> >>> -Jon
> >>>
> >>> On Sat, May 4, 2024 at 4:53 AM Jeff Young  wrote:
> 
>  Presumably we can tell the difference (in the code) between a
> schematic or layout import and a library import?
> 
>  It would seem to me like a schematic or layout import should show the
> warnings (even without an advanced setting or the like).
> 
>  Personally I also think the library importer should show the warnings
> the very first time.  Maybe we could do that by setting a plugin option
> (m_warningsShown or something) after reading the library?  I think those
> are saved per-row in the lib table, but I’m not 100% sure.
> 
>  Cheers,
>  Jeff.
> 
> 
>  On 4 May 2024, at 09:47, 'Stefan Weber' via KiCad Developers <
> devlist@kicad.org> wrote:
> 
>  Hi,
> 
>  I recently started a discussion with @Jon Evans in my MR
> https://gitlab.com/kicad/code/kicad/-/merge_requests/1935 regarding the
> visibility of Altium importer warning & errors for not yet supported
> schematic and layout features.
> 
>  Since commit
> https://gitlab.com/kicad/code/kicad/-/commit/83be5ba63d82e237b8944ee6ee7c639215b14027
> the Kicad Altium Importer does no longer shows warning & errors for not yet
> supported schematic and layout features in relea

Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread Jeff Young
I don’t agree.  A nag dialog would be something that told you we don’t have an 
editing feature that Altium supports, not that we can’t express the same end 
result as we found in the Altium file.

There are certainly border-line cases.  Complaining about not being able to 
import a datum dimension is a bit closer to an editing feature.  But if it’s 
something like pad-stacks, then I’m going to have to make changes somewhere to 
get the design right.  So I’d rather know about those.

> On 4 May 2024, at 14:29, Jon Evans  wrote:
> 
>> The only place we disagree is what to do in the meantime for schematics and 
>> boards.
> 
> Using wxLog to pop up dialogs reporting that KiCad does not support
> some feature of some other EDA tool is inappropriate in my opinion.
> It goes against the KiCad guideline of not showing nag dialogs.  I
> don't think boards/schematics are any different from libraries in this
> regard.
> 
> On Sat, May 4, 2024 at 9:24 AM Jeff Young  wrote:
>> 
>> We do report context info (at least line number and offset) in some of the 
>> other importers.
>> 
>> I agree that the system could be improved.
>> And I agree that we have to do something about the library importing.
>> 
>> The only place we disagree is what to do in the meantime for schematics and 
>> boards.
>> 
>> Cheers,
>> Jeff.
>> 
>>> On 4 May 2024, at 13:04, Jon Evans  wrote:
>>> 
>>> Jeff,
>>> 
>>> In both cases I disagree that the current warning system should
>>> appear.  The warning system we have today is really not that helpful,
>>> and I don't want to bring it back the same way for boards or for
>>> libraries.
>>> The advanced_config option was something Seth and I discussed as a
>>> simple stopgap for V8 if we are looking at something better for V9.
>>> 
>>> A more helpful warning system:
>>> - Would not use pop-up dialogs that block the UI to let people know
>>> that any warnings exist (instead would show up in the info bar, the
>>> same way our previous-format-version warning does)
>>> - Would have a more rich system of logging, so that people always get
>>> context about what part of their file had an issue
>>> 
>>> I think if we want to show this info, we need a new kind of REPORTER
>>> that can capture context rather than just a string, and a "post-import
>>> report" dialog launched from the infobar.
>>> 
>>> The library loader can keep track of these on a per-library basis so
>>> that the infobar can be shown in the symbol/footprint editor after
>>> launch.
>>> 
>>> -Jon
>>> 
>>> On Sat, May 4, 2024 at 4:53 AM Jeff Young  wrote:
 
 Presumably we can tell the difference (in the code) between a schematic or 
 layout import and a library import?
 
 It would seem to me like a schematic or layout import should show the 
 warnings (even without an advanced setting or the like).
 
 Personally I also think the library importer should show the warnings the 
 very first time.  Maybe we could do that by setting a plugin option 
 (m_warningsShown or something) after reading the library?  I think those 
 are saved per-row in the lib table, but I’m not 100% sure.
 
 Cheers,
 Jeff.
 
 
 On 4 May 2024, at 09:47, 'Stefan Weber' via KiCad Developers 
  wrote:
 
 Hi,
 
 I recently started a discussion with @Jon Evans in my MR 
 https://gitlab.com/kicad/code/kicad/-/merge_requests/1935 regarding the 
 visibility of Altium importer warning & errors for not yet supported 
 schematic and layout features.
 
 Since commit 
 https://gitlab.com/kicad/code/kicad/-/commit/83be5ba63d82e237b8944ee6ee7c639215b14027
  the Kicad Altium Importer does no longer shows warning & errors for not 
 yet supported schematic and layout features in release builds.
 
 As Jon mentioned this was implemented to get rid of those annoying 
 warnings which pop-up every time you use an Altium library which contains 
 a not yet supported schematic and layout features. This I absolutely 
 understand.
 
 I also do not expect that importing data from other EDA tools will be 100% 
 accurate. But as the importer already knows it's limits I personally would 
 like to have the possibility to get those warnings and errors back when I 
 am importing an Altium schematic or layout.
 
 Jon mentioned:
 
 "I would be fine with adding some new way to show these optionally, in a 
 less obtrusive way."
 
 "We try to avoid settings wherever possible. It is best to come up with a 
 solution that can be enabled for everyone, meaning that people who want 
 the information can get it in a way that does not slow down people who 
 don't want the information.
 One option would be to create a "post-import report" that can optionally 
 be launched from an infobar notification, for example."
 
 "One pretty simple option would be an advanced_config flag that changes 
 the behavior o

Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread Jon Evans
> The only place we disagree is what to do in the meantime for schematics and 
> boards.

Using wxLog to pop up dialogs reporting that KiCad does not support
some feature of some other EDA tool is inappropriate in my opinion.
It goes against the KiCad guideline of not showing nag dialogs.  I
don't think boards/schematics are any different from libraries in this
regard.

On Sat, May 4, 2024 at 9:24 AM Jeff Young  wrote:
>
> We do report context info (at least line number and offset) in some of the 
> other importers.
>
> I agree that the system could be improved.
> And I agree that we have to do something about the library importing.
>
> The only place we disagree is what to do in the meantime for schematics and 
> boards.
>
> Cheers,
> Jeff.
>
> > On 4 May 2024, at 13:04, Jon Evans  wrote:
> >
> > Jeff,
> >
> > In both cases I disagree that the current warning system should
> > appear.  The warning system we have today is really not that helpful,
> > and I don't want to bring it back the same way for boards or for
> > libraries.
> > The advanced_config option was something Seth and I discussed as a
> > simple stopgap for V8 if we are looking at something better for V9.
> >
> > A more helpful warning system:
> > - Would not use pop-up dialogs that block the UI to let people know
> > that any warnings exist (instead would show up in the info bar, the
> > same way our previous-format-version warning does)
> > - Would have a more rich system of logging, so that people always get
> > context about what part of their file had an issue
> >
> > I think if we want to show this info, we need a new kind of REPORTER
> > that can capture context rather than just a string, and a "post-import
> > report" dialog launched from the infobar.
> >
> > The library loader can keep track of these on a per-library basis so
> > that the infobar can be shown in the symbol/footprint editor after
> > launch.
> >
> > -Jon
> >
> > On Sat, May 4, 2024 at 4:53 AM Jeff Young  wrote:
> >>
> >> Presumably we can tell the difference (in the code) between a schematic or 
> >> layout import and a library import?
> >>
> >> It would seem to me like a schematic or layout import should show the 
> >> warnings (even without an advanced setting or the like).
> >>
> >> Personally I also think the library importer should show the warnings the 
> >> very first time.  Maybe we could do that by setting a plugin option 
> >> (m_warningsShown or something) after reading the library?  I think those 
> >> are saved per-row in the lib table, but I’m not 100% sure.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>
> >> On 4 May 2024, at 09:47, 'Stefan Weber' via KiCad Developers 
> >>  wrote:
> >>
> >> Hi,
> >>
> >> I recently started a discussion with @Jon Evans in my MR 
> >> https://gitlab.com/kicad/code/kicad/-/merge_requests/1935 regarding the 
> >> visibility of Altium importer warning & errors for not yet supported 
> >> schematic and layout features.
> >>
> >> Since commit 
> >> https://gitlab.com/kicad/code/kicad/-/commit/83be5ba63d82e237b8944ee6ee7c639215b14027
> >>  the Kicad Altium Importer does no longer shows warning & errors for not 
> >> yet supported schematic and layout features in release builds.
> >>
> >> As Jon mentioned this was implemented to get rid of those annoying 
> >> warnings which pop-up every time you use an Altium library which contains 
> >> a not yet supported schematic and layout features. This I absolutely 
> >> understand.
> >>
> >> I also do not expect that importing data from other EDA tools will be 100% 
> >> accurate. But as the importer already knows it's limits I personally would 
> >> like to have the possibility to get those warnings and errors back when I 
> >> am importing an Altium schematic or layout.
> >>
> >> Jon mentioned:
> >>
> >> "I would be fine with adding some new way to show these optionally, in a 
> >> less obtrusive way."
> >>
> >> "We try to avoid settings wherever possible. It is best to come up with a 
> >> solution that can be enabled for everyone, meaning that people who want 
> >> the information can get it in a way that does not slow down people who 
> >> don't want the information.
> >> One option would be to create a "post-import report" that can optionally 
> >> be launched from an infobar notification, for example."
> >>
> >> "One pretty simple option would be an advanced_config flag that changes 
> >> the behavior of the WXLOG_REPORTER to use logging calls that are present 
> >> in release builds"
> >>
> >> I am curious what's the opinion of others.
> >>
> >> Best regards,
> >> Stefan
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups 
> >> "KiCad Developers" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an 
> >> email to devlist+unsubscr...@kicad.org.
> >> To view this discussion on the web visit 
> >> https://groups.google.com/a/kicad.org/d/msgid/devlist/f49a2c0b-5a6f-4ed9-a40d-20f2a385d0een%40kicad.org.
> >>
> >>
> >> -

Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread Jeff Young
We do report context info (at least line number and offset) in some of the 
other importers.

I agree that the system could be improved.
And I agree that we have to do something about the library importing.

The only place we disagree is what to do in the meantime for schematics and 
boards.

Cheers,
Jeff.

> On 4 May 2024, at 13:04, Jon Evans  wrote:
> 
> Jeff,
> 
> In both cases I disagree that the current warning system should
> appear.  The warning system we have today is really not that helpful,
> and I don't want to bring it back the same way for boards or for
> libraries.
> The advanced_config option was something Seth and I discussed as a
> simple stopgap for V8 if we are looking at something better for V9.
> 
> A more helpful warning system:
> - Would not use pop-up dialogs that block the UI to let people know
> that any warnings exist (instead would show up in the info bar, the
> same way our previous-format-version warning does)
> - Would have a more rich system of logging, so that people always get
> context about what part of their file had an issue
> 
> I think if we want to show this info, we need a new kind of REPORTER
> that can capture context rather than just a string, and a "post-import
> report" dialog launched from the infobar.
> 
> The library loader can keep track of these on a per-library basis so
> that the infobar can be shown in the symbol/footprint editor after
> launch.
> 
> -Jon
> 
> On Sat, May 4, 2024 at 4:53 AM Jeff Young  wrote:
>> 
>> Presumably we can tell the difference (in the code) between a schematic or 
>> layout import and a library import?
>> 
>> It would seem to me like a schematic or layout import should show the 
>> warnings (even without an advanced setting or the like).
>> 
>> Personally I also think the library importer should show the warnings the 
>> very first time.  Maybe we could do that by setting a plugin option 
>> (m_warningsShown or something) after reading the library?  I think those are 
>> saved per-row in the lib table, but I’m not 100% sure.
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>> On 4 May 2024, at 09:47, 'Stefan Weber' via KiCad Developers 
>>  wrote:
>> 
>> Hi,
>> 
>> I recently started a discussion with @Jon Evans in my MR 
>> https://gitlab.com/kicad/code/kicad/-/merge_requests/1935 regarding the 
>> visibility of Altium importer warning & errors for not yet supported 
>> schematic and layout features.
>> 
>> Since commit 
>> https://gitlab.com/kicad/code/kicad/-/commit/83be5ba63d82e237b8944ee6ee7c639215b14027
>>  the Kicad Altium Importer does no longer shows warning & errors for not yet 
>> supported schematic and layout features in release builds.
>> 
>> As Jon mentioned this was implemented to get rid of those annoying warnings 
>> which pop-up every time you use an Altium library which contains a not yet 
>> supported schematic and layout features. This I absolutely understand.
>> 
>> I also do not expect that importing data from other EDA tools will be 100% 
>> accurate. But as the importer already knows it's limits I personally would 
>> like to have the possibility to get those warnings and errors back when I am 
>> importing an Altium schematic or layout.
>> 
>> Jon mentioned:
>> 
>> "I would be fine with adding some new way to show these optionally, in a 
>> less obtrusive way."
>> 
>> "We try to avoid settings wherever possible. It is best to come up with a 
>> solution that can be enabled for everyone, meaning that people who want the 
>> information can get it in a way that does not slow down people who don't 
>> want the information.
>> One option would be to create a "post-import report" that can optionally be 
>> launched from an infobar notification, for example."
>> 
>> "One pretty simple option would be an advanced_config flag that changes the 
>> behavior of the WXLOG_REPORTER to use logging calls that are present in 
>> release builds"
>> 
>> I am curious what's the opinion of others.
>> 
>> Best regards,
>> Stefan
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "KiCad Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to devlist+unsubscr...@kicad.org.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/kicad.org/d/msgid/devlist/f49a2c0b-5a6f-4ed9-a40d-20f2a385d0een%40kicad.org.
>> 
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "KiCad Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to devlist+unsubscr...@kicad.org.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/kicad.org/d/msgid/devlist/2533D70F-B95B-4548-97C7-335F4F9944CF%40rokeby.ie.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "KiCad Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to devlist+unsubscr...@kicad.org.
> To view

Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread Jon Evans
Jeff,

In both cases I disagree that the current warning system should
appear.  The warning system we have today is really not that helpful,
and I don't want to bring it back the same way for boards or for
libraries.
The advanced_config option was something Seth and I discussed as a
simple stopgap for V8 if we are looking at something better for V9.

A more helpful warning system:
- Would not use pop-up dialogs that block the UI to let people know
that any warnings exist (instead would show up in the info bar, the
same way our previous-format-version warning does)
- Would have a more rich system of logging, so that people always get
context about what part of their file had an issue

I think if we want to show this info, we need a new kind of REPORTER
that can capture context rather than just a string, and a "post-import
report" dialog launched from the infobar.

The library loader can keep track of these on a per-library basis so
that the infobar can be shown in the symbol/footprint editor after
launch.

-Jon

On Sat, May 4, 2024 at 4:53 AM Jeff Young  wrote:
>
> Presumably we can tell the difference (in the code) between a schematic or 
> layout import and a library import?
>
> It would seem to me like a schematic or layout import should show the 
> warnings (even without an advanced setting or the like).
>
> Personally I also think the library importer should show the warnings the 
> very first time.  Maybe we could do that by setting a plugin option 
> (m_warningsShown or something) after reading the library?  I think those are 
> saved per-row in the lib table, but I’m not 100% sure.
>
> Cheers,
> Jeff.
>
>
> On 4 May 2024, at 09:47, 'Stefan Weber' via KiCad Developers 
>  wrote:
>
> Hi,
>
> I recently started a discussion with @Jon Evans in my MR 
> https://gitlab.com/kicad/code/kicad/-/merge_requests/1935 regarding the 
> visibility of Altium importer warning & errors for not yet supported 
> schematic and layout features.
>
> Since commit 
> https://gitlab.com/kicad/code/kicad/-/commit/83be5ba63d82e237b8944ee6ee7c639215b14027
>  the Kicad Altium Importer does no longer shows warning & errors for not yet 
> supported schematic and layout features in release builds.
>
> As Jon mentioned this was implemented to get rid of those annoying warnings 
> which pop-up every time you use an Altium library which contains a not yet 
> supported schematic and layout features. This I absolutely understand.
>
> I also do not expect that importing data from other EDA tools will be 100% 
> accurate. But as the importer already knows it's limits I personally would 
> like to have the possibility to get those warnings and errors back when I am 
> importing an Altium schematic or layout.
>
> Jon mentioned:
>
> "I would be fine with adding some new way to show these optionally, in a less 
> obtrusive way."
>
> "We try to avoid settings wherever possible. It is best to come up with a 
> solution that can be enabled for everyone, meaning that people who want the 
> information can get it in a way that does not slow down people who don't want 
> the information.
> One option would be to create a "post-import report" that can optionally be 
> launched from an infobar notification, for example."
>
> "One pretty simple option would be an advanced_config flag that changes the 
> behavior of the WXLOG_REPORTER to use logging calls that are present in 
> release builds"
>
> I am curious what's the opinion of others.
>
> Best regards,
> Stefan
>
> --
> You received this message because you are subscribed to the Google Groups 
> "KiCad Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to devlist+unsubscr...@kicad.org.
> To view this discussion on the web visit 
> https://groups.google.com/a/kicad.org/d/msgid/devlist/f49a2c0b-5a6f-4ed9-a40d-20f2a385d0een%40kicad.org.
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "KiCad Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to devlist+unsubscr...@kicad.org.
> To view this discussion on the web visit 
> https://groups.google.com/a/kicad.org/d/msgid/devlist/2533D70F-B95B-4548-97C7-335F4F9944CF%40rokeby.ie.

-- 
You received this message because you are subscribed to the Google Groups 
"KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to devlist+unsubscr...@kicad.org.
To view this discussion on the web visit 
https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCDQhM7pm0-c14hFm8qf-YqpmEq5L8NynBoxCv3V1XLkRg%40mail.gmail.com.


Re: [kicad] Altium Importer REPORTER for logging

2024-05-04 Thread Jeff Young
Presumably we can tell the difference (in the code) between a schematic or 
layout import and a library import?

It would seem to me like a schematic or layout import should show the warnings 
(even without an advanced setting or the like).

Personally I also think the library importer should show the warnings the very 
first time.  Maybe we could do that by setting a plugin option (m_warningsShown 
or something) after reading the library?  I think those are saved per-row in 
the lib table, but I’m not 100% sure.

Cheers,
Jeff.


> On 4 May 2024, at 09:47, 'Stefan Weber' via KiCad Developers 
>  wrote:
> 
> Hi,
> 
> I recently started a discussion with @Jon Evans in my MR 
> https://gitlab.com/kicad/code/kicad/-/merge_requests/1935 regarding the 
> visibility of Altium importer warning & errors for not yet supported 
> schematic and layout features.
> 
> Since commit 
> https://gitlab.com/kicad/code/kicad/-/commit/83be5ba63d82e237b8944ee6ee7c639215b14027
>  the Kicad Altium Importer does no longer shows warning & errors for not yet 
> supported schematic and layout features in release builds.
> 
> As Jon mentioned this was implemented to get rid of those annoying warnings 
> which pop-up every time you use an Altium library which contains a not yet 
> supported schematic and layout features. This I absolutely understand.
> 
> I also do not expect that importing data from other EDA tools will be 100% 
> accurate. But as the importer already knows it's limits I personally would 
> like to have the possibility to get those warnings and errors back when I am 
> importing an Altium schematic or layout.
> 
> Jon mentioned: 
> 
> "I would be fine with adding some new way to show these optionally, in a less 
> obtrusive way."
> 
> "We try to avoid settings wherever possible. It is best to come up with a 
> solution that can be enabled for everyone, meaning that people who want the 
> information can get it in a way that does not slow down people who don't want 
> the information.
> One option would be to create a "post-import report" that can optionally be 
> launched from an infobar notification, for example."
> 
> "One pretty simple option would be an advanced_config flag that changes the 
> behavior of the WXLOG_REPORTER to use logging calls that are present in 
> release builds"
> 
> I am curious what's the opinion of others.
> 
> Best regards,
> Stefan
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "KiCad Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to devlist+unsubscr...@kicad.org .
> To view this discussion on the web visit 
> https://groups.google.com/a/kicad.org/d/msgid/devlist/f49a2c0b-5a6f-4ed9-a40d-20f2a385d0een%40kicad.org
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to devlist+unsubscr...@kicad.org.
To view this discussion on the web visit 
https://groups.google.com/a/kicad.org/d/msgid/devlist/2533D70F-B95B-4548-97C7-335F4F9944CF%40rokeby.ie.


[kicad] Altium Importer REPORTER for logging

2024-05-04 Thread 'Stefan Weber' via KiCad Developers
Hi,

I recently started a discussion with @Jon Evans in my MR 
https://gitlab.com/kicad/code/kicad/-/merge_requests/1935 regarding the 
visibility of Altium importer warning & errors for not yet supported 
schematic and layout features.

Since commit 
https://gitlab.com/kicad/code/kicad/-/commit/83be5ba63d82e237b8944ee6ee7c639215b14027
 
the Kicad Altium Importer does no longer shows warning & errors for not yet 
supported schematic and layout features in release builds.

As Jon mentioned this was implemented to get rid of those annoying warnings 
which pop-up every time you use an Altium library which contains a not yet 
supported schematic and layout features. This I absolutely understand.

I also do not expect that importing data from other EDA tools will be 100% 
accurate. But as the importer already knows it's limits I personally would 
like to have the possibility to get those warnings and errors back when I 
am importing an Altium schematic or layout.

Jon mentioned: 

"I would be fine with adding some new way to show these optionally, in a 
less obtrusive way."

"We try to avoid settings wherever possible. It is best to come up with a 
solution that can be enabled for everyone, meaning that people who want the 
information can get it in a way that does not slow down people who don't 
want the information.
One option would be to create a "post-import report" that can optionally be 
launched from an infobar notification, for example."

"One pretty simple option would be an advanced_config flag that changes the 
behavior of the WXLOG_REPORTER to use logging calls that are present in 
release builds"

I am curious what's the opinion of others.

Best regards,
Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to devlist+unsubscr...@kicad.org.
To view this discussion on the web visit 
https://groups.google.com/a/kicad.org/d/msgid/devlist/f49a2c0b-5a6f-4ed9-a40d-20f2a385d0een%40kicad.org.