Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Nick Østergaard]

Alternatively save a changes log.  I don't know if this could be
problematic, but it is an idea. It is more subtle and does not require
a dialog in the end. Also it should only appear once for a schematic
if saved.

2015-04-26 0:40 GMT+02:00 Chris Pavlina :
> Thanks. I'll patch these bits soon. I'll have to try it on Windows and see
> how that dialog displays, it's fine here in Linux. Also, I'll get writing
> the documentation for it.
>
> Personally, I like the idea of having a summary at the end, as you might
> want to have an actual list of the components changed. Actually, I'd even
> prefer if it were in a format that could be put on the clipboard. Anyone
> else have a comment on that?
>
>
>
> On Sat, Apr 25, 2015 at 06:29:32PM -0400, Wayne Stambaugh wrote:
>>
>> Chris,
>>
>> I committed your patch in the product branch r5623.  Very nice work by
>> the way.  I have a few minor comments.
>>
>> * Most of the wxT() and _() macros are missing spaces between the braces
>> and the string.
>>
>> * The rescue dialog does not have a default button set so that you can
>> just hit enter to select the default action.  In this case it should be
>> the OK button.
>>
>> * I'm not sure we need a second dialog after the rescue dialog.  It
>> seems a bit like nagware to me.  If we decide to keep the rescue status
>> dialog, it needs to be fixed because it has to be expanded (at least on
>> windows) because it doesn't show anything other than the headers.  Try
>> using Fit() after populating the control before the dialog is shown.
>> There are examples of this in other kicad dialogs.
>>
>> * Everyone please test this thoroughly if you have any old schematics so
>> we can be sure it's robust enough for the stable release.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 4/12/2015 1:57 PM, Chris Pavlina wrote:
>>>
>>> And, because I'm excessively stupid today, here's a version of the patch
>>> that I didn't diff incorrectly.
>>>
>>> On Fri, Apr 10, 2015 at 07:15:00PM -0400, Wayne Stambaugh wrote:

 On 4/8/2015 8:48 PM, Chris Pavlina wrote:
>
> Any more devs have an opinion on this?


 I've already said it would be a good idea albeit a temporary one for the
 upcoming stable release.  I just saw another reply to a bug report about
 someones schematic being incorrect because the library components have
 changed.  Looking at the changes to the component libraries, it would be
 my guess that we will have a lot of upset users who have not upgrade
 from the previous stable release.  Does anyone else have any opinions
 about this?

>
> On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote:
>>
>> On 3/30/2015 1:58 PM, Chris Pavlina wrote:
>>>
>>>
>>> On Mar 30, 2015 1:49 PM, "Wayne Stambaugh" >> > wrote:


 Please fix your coding style issues.  I saw:

 if( foo ) bar;

 should be:

 if( foo )
 bar;

 Also, two blank lines between function definitions in cpp files.
>>>
>>>
>>> Oops, missed these bits of the style. Will fix by tomorrow.
>>>
 In the future, please do not create OnOk()/OnCancel() message
 handlers
 then call EndModal() in your dialogs.  This is broken by design.
 Your
 dialog may not always be modal.  It may be useful to create them as
 modeless or quasi-modal so calling EndModal() fail.  I know it is
 used
 in virtually every dialog in KiCad and it is fundamentally wrong.
 The
 wxWidgets developers were kind enough to create all the necessary
 plumbing to handle this.  Please read
 http://docs.wxwidgets.org/3.0/overview_validator.html and take
 look at
 common/dialogs/dialog_env_var_config.cpp for tips on transferring
 data
 to and from the controls using wxDialog.
>>>
>>>
>>> Oh, you'll have to forgive me, I'm a bit new to wx. Not just "in the
>>> future", I'll get this fixed as well. Last thing I want to do is add
>>> broken code to KiCad. Perhaps I'll help out and start working on
>>> fixing
>>> some of the existing ones too.
>>
>>
>> Thanks.  Don't worry about the existing ones until after the stable
>> release.  I want to keep focused on that until it's done.
>> Otherwise, we
>> will just keep making changes and never get the stable release out the
>> door.  I want to let everything stabilize and make sure we get all of
>> the bugs fixed.
>>
>>>
 [snip] I need your
 assurance that you will see it through to the stable release
 before I'm
 willing to give it my approval. I would also appreciate if you could
 update the Eeschema documentation at
 https://github.com/ciampix/kicad-doc or have someone document it for
 you.  What say the rest of yo

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Chris Pavlina]

Thanks. I'll patch these bits soon. I'll have to try it on Windows and see how 
that dialog displays, it's fine here in Linux. Also, I'll get writing the 
documentation for it.

Personally, I like the idea of having a summary at the end, as you might want 
to have an actual list of the components changed. Actually, I'd even prefer if 
it were in a format that could be put on the clipboard. Anyone else have a 
comment on that?


On Sat, Apr 25, 2015 at 06:29:32PM -0400, Wayne Stambaugh wrote:

Chris,

I committed your patch in the product branch r5623.  Very nice work by
the way.  I have a few minor comments.

* Most of the wxT() and _() macros are missing spaces between the braces
and the string.

* The rescue dialog does not have a default button set so that you can
just hit enter to select the default action.  In this case it should be
the OK button.

* I'm not sure we need a second dialog after the rescue dialog.  It
seems a bit like nagware to me.  If we decide to keep the rescue status
dialog, it needs to be fixed because it has to be expanded (at least on
windows) because it doesn't show anything other than the headers.  Try
using Fit() after populating the control before the dialog is shown.
There are examples of this in other kicad dialogs.

* Everyone please test this thoroughly if you have any old schematics so
we can be sure it's robust enough for the stable release.

Thanks,

Wayne

On 4/12/2015 1:57 PM, Chris Pavlina wrote:

And, because I'm excessively stupid today, here's a version of the patch
that I didn't diff incorrectly.

On Fri, Apr 10, 2015 at 07:15:00PM -0400, Wayne Stambaugh wrote:

On 4/8/2015 8:48 PM, Chris Pavlina wrote:

Any more devs have an opinion on this?


I've already said it would be a good idea albeit a temporary one for the
upcoming stable release.  I just saw another reply to a bug report about
someones schematic being incorrect because the library components have
changed.  Looking at the changes to the component libraries, it would be
my guess that we will have a lot of upset users who have not upgrade
from the previous stable release.  Does anyone else have any opinions
about this?



On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote:

On 3/30/2015 1:58 PM, Chris Pavlina wrote:


On Mar 30, 2015 1:49 PM, "Wayne Stambaugh" mailto:stambau...@gmail.com>> wrote:


Please fix your coding style issues.  I saw:

if( foo ) bar;

should be:

if( foo )
bar;

Also, two blank lines between function definitions in cpp files.


Oops, missed these bits of the style. Will fix by tomorrow.


In the future, please do not create OnOk()/OnCancel() message
handlers
then call EndModal() in your dialogs.  This is broken by design.
Your
dialog may not always be modal.  It may be useful to create them as
modeless or quasi-modal so calling EndModal() fail.  I know it is
used
in virtually every dialog in KiCad and it is fundamentally wrong.
The
wxWidgets developers were kind enough to create all the necessary
plumbing to handle this.  Please read
http://docs.wxwidgets.org/3.0/overview_validator.html and take
look at
common/dialogs/dialog_env_var_config.cpp for tips on transferring
data
to and from the controls using wxDialog.


Oh, you'll have to forgive me, I'm a bit new to wx. Not just "in the
future", I'll get this fixed as well. Last thing I want to do is add
broken code to KiCad. Perhaps I'll help out and start working on
fixing
some of the existing ones too.


Thanks.  Don't worry about the existing ones until after the stable
release.  I want to keep focused on that until it's done.
Otherwise, we
will just keep making changes and never get the stable release out the
door.  I want to let everything stabilize and make sure we get all of
the bugs fixed.




[snip] I need your
assurance that you will see it through to the stable release
before I'm
willing to give it my approval. I would also appreciate if you could
update the Eeschema documentation at
https://github.com/ciampix/kicad-doc or have someone document it for
you.  What say the rest of you?


Yup, plan was to see it through. I'll document it as well - just
let me
get these fixes implemented first.


You've got plenty of time.  The stable release goal is the late
June/early July time frame.




On 3/30/2015 11:43 AM, Chris Pavlina wrote:
> Well, seems I missed the freeze on this one, but I've got a patch,
might
> as well share. Works well for me - comments welcome, of course, and
> ideas for more testcases.
>
> At schematic load, or when the tool is selected from the menu, the
> schematic is analyzed for any problematic components. These are
where
> the component found in the cache has pins moved or changed from
the one
> found in the system libraries. When this happens, the following
dialog
> is displayed:
>
> https://db.tt/qIAesEQv
>
> The user can choose per symbol whether to keep the library
version or
> the cached version.  Any cached components selected for "rescue"
are
> renamed to "$componentname-RESCUE-$

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Wayne Stambaugh]

Chris,

I committed your patch in the product branch r5623.  Very nice work by
the way.  I have a few minor comments.

* Most of the wxT() and _() macros are missing spaces between the braces
and the string.

* The rescue dialog does not have a default button set so that you can
just hit enter to select the default action.  In this case it should be
the OK button.

* I'm not sure we need a second dialog after the rescue dialog.  It
seems a bit like nagware to me.  If we decide to keep the rescue status
dialog, it needs to be fixed because it has to be expanded (at least on
windows) because it doesn't show anything other than the headers.  Try
using Fit() after populating the control before the dialog is shown.
There are examples of this in other kicad dialogs.

* Everyone please test this thoroughly if you have any old schematics so
we can be sure it's robust enough for the stable release.

Thanks,

Wayne

On 4/12/2015 1:57 PM, Chris Pavlina wrote:
> And, because I'm excessively stupid today, here's a version of the patch
> that I didn't diff incorrectly.
> 
> On Fri, Apr 10, 2015 at 07:15:00PM -0400, Wayne Stambaugh wrote:
>> On 4/8/2015 8:48 PM, Chris Pavlina wrote:
>>> Any more devs have an opinion on this?
>>
>> I've already said it would be a good idea albeit a temporary one for the
>> upcoming stable release.  I just saw another reply to a bug report about
>> someones schematic being incorrect because the library components have
>> changed.  Looking at the changes to the component libraries, it would be
>> my guess that we will have a lot of upset users who have not upgrade
>> from the previous stable release.  Does anyone else have any opinions
>> about this?
>>
>>>
>>> On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote:
 On 3/30/2015 1:58 PM, Chris Pavlina wrote:
>
> On Mar 30, 2015 1:49 PM, "Wayne Stambaugh"  > wrote:
>>
>> Please fix your coding style issues.  I saw:
>>
>> if( foo ) bar;
>>
>> should be:
>>
>> if( foo )
>> bar;
>>
>> Also, two blank lines between function definitions in cpp files.
>
> Oops, missed these bits of the style. Will fix by tomorrow.
>
>> In the future, please do not create OnOk()/OnCancel() message
>> handlers
>> then call EndModal() in your dialogs.  This is broken by design. 
>> Your
>> dialog may not always be modal.  It may be useful to create them as
>> modeless or quasi-modal so calling EndModal() fail.  I know it is
>> used
>> in virtually every dialog in KiCad and it is fundamentally wrong. 
>> The
>> wxWidgets developers were kind enough to create all the necessary
>> plumbing to handle this.  Please read
>> http://docs.wxwidgets.org/3.0/overview_validator.html and take
>> look at
>> common/dialogs/dialog_env_var_config.cpp for tips on transferring
>> data
>> to and from the controls using wxDialog.
>
> Oh, you'll have to forgive me, I'm a bit new to wx. Not just "in the
> future", I'll get this fixed as well. Last thing I want to do is add
> broken code to KiCad. Perhaps I'll help out and start working on
> fixing
> some of the existing ones too.

 Thanks.  Don't worry about the existing ones until after the stable
 release.  I want to keep focused on that until it's done. 
 Otherwise, we
 will just keep making changes and never get the stable release out the
 door.  I want to let everything stabilize and make sure we get all of
 the bugs fixed.

>
>> [snip] I need your
>> assurance that you will see it through to the stable release
>> before I'm
>> willing to give it my approval. I would also appreciate if you could
>> update the Eeschema documentation at
>> https://github.com/ciampix/kicad-doc or have someone document it for
>> you.  What say the rest of you?
>
> Yup, plan was to see it through. I'll document it as well - just
> let me
> get these fixes implemented first.

 You've got plenty of time.  The stable release goal is the late
 June/early July time frame.

>
>> On 3/30/2015 11:43 AM, Chris Pavlina wrote:
>> > Well, seems I missed the freeze on this one, but I've got a patch,
>> might
>> > as well share. Works well for me - comments welcome, of course, and
>> > ideas for more testcases.
>> >
>> > At schematic load, or when the tool is selected from the menu, the
>> > schematic is analyzed for any problematic components. These are
>> where
>> > the component found in the cache has pins moved or changed from
>> the one
>> > found in the system libraries. When this happens, the following
>> dialog
>> > is displayed:
>> >
>> > https://db.tt/qIAesEQv
>> >
>> > The user can choose per symbol whether to keep the library
>> version or
>> > the cached version.  Any cached compon

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Wayne Stambaugh]

Never mind Chris.  I found rescue4b.patch which I believe is the latest
version.  My inbox is way too full.

On 4/25/2015 1:50 PM, Wayne Stambaugh wrote:
> Chris,
> 
> I'm in the process of testing your patch but I'm not sure this is the
> latest version.  Please let me know when you get a chance.
> 
> Thanks,
> 
> Wayne
> 
> On 3/30/2015 6:34 PM, Chris Pavlina wrote:
>> Okay, all fixed.
>>
>> On Mon, Mar 30, 2015 at 01:46:05PM -0400, Wayne Stambaugh wrote:
>>> Please fix your coding style issues.  I saw:
>>>
>>> [snip]
>>
>>
>> ___
>> 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
>>
> 


___
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] [patch?] Handling conflict between projname-cache.lib and an updated library

[Wayne Stambaugh]

Chris,

I'm in the process of testing your patch but I'm not sure this is the
latest version.  Please let me know when you get a chance.

Thanks,

Wayne

On 3/30/2015 6:34 PM, Chris Pavlina wrote:
> Okay, all fixed.
> 
> On Mon, Mar 30, 2015 at 01:46:05PM -0400, Wayne Stambaugh wrote:
>> Please fix your coding style issues.  I saw:
>>
>> [snip]
> 
> 
> ___
> 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
> 


___
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] [patch?] Handling conflict between projname-cache.lib and an updated library

[Nick Østergaard]

Hi Wayne et al.

I see Chris has been fixing the patch, and I would like to see this
accepted, because a lot of people on IRC are bitching about "the new
kicad" that "breaks" their schematics.

Could this please be considered to be merged again?

2015-04-12 23:38 GMT+02:00 Nick Østergaard :
> I just tested this again, after reporting some of the above, but now
> solved issues to Chris. Thanks for fixing so fast.
>
> 2015-04-12 19:57 GMT+02:00 Chris Pavlina :
>> And, because I'm excessively stupid today, here's a version of the patch
>> that I didn't diff incorrectly.
>>
>>
>> On Fri, Apr 10, 2015 at 07:15:00PM -0400, Wayne Stambaugh wrote:
>>>
>>> On 4/8/2015 8:48 PM, Chris Pavlina wrote:

 Any more devs have an opinion on this?
>>>
>>>
>>> I've already said it would be a good idea albeit a temporary one for the
>>> upcoming stable release.  I just saw another reply to a bug report about
>>> someones schematic being incorrect because the library components have
>>> changed.  Looking at the changes to the component libraries, it would be
>>> my guess that we will have a lot of upset users who have not upgrade
>>> from the previous stable release.  Does anyone else have any opinions
>>> about this?
>>>

 On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote:
>
> On 3/30/2015 1:58 PM, Chris Pavlina wrote:
>>
>>
>> On Mar 30, 2015 1:49 PM, "Wayne Stambaugh" > > wrote:
>>>
>>>
>>> Please fix your coding style issues.  I saw:
>>>
>>> if( foo ) bar;
>>>
>>> should be:
>>>
>>> if( foo )
>>> bar;
>>>
>>> Also, two blank lines between function definitions in cpp files.
>>
>>
>> Oops, missed these bits of the style. Will fix by tomorrow.
>>
>>> In the future, please do not create OnOk()/OnCancel() message handlers
>>> then call EndModal() in your dialogs.  This is broken by design.  Your
>>> dialog may not always be modal.  It may be useful to create them as
>>> modeless or quasi-modal so calling EndModal() fail.  I know it is used
>>> in virtually every dialog in KiCad and it is fundamentally wrong.  The
>>> wxWidgets developers were kind enough to create all the necessary
>>> plumbing to handle this.  Please read
>>> http://docs.wxwidgets.org/3.0/overview_validator.html and take look at
>>> common/dialogs/dialog_env_var_config.cpp for tips on transferring data
>>> to and from the controls using wxDialog.
>>
>>
>> Oh, you'll have to forgive me, I'm a bit new to wx. Not just "in the
>> future", I'll get this fixed as well. Last thing I want to do is add
>> broken code to KiCad. Perhaps I'll help out and start working on fixing
>> some of the existing ones too.
>
>
> Thanks.  Don't worry about the existing ones until after the stable
> release.  I want to keep focused on that until it's done.  Otherwise, we
> will just keep making changes and never get the stable release out the
> door.  I want to let everything stabilize and make sure we get all of
> the bugs fixed.
>
>>
>>> [snip] I need your
>>> assurance that you will see it through to the stable release before
>>> I'm
>>> willing to give it my approval. I would also appreciate if you could
>>> update the Eeschema documentation at
>>> https://github.com/ciampix/kicad-doc or have someone document it for
>>> you.  What say the rest of you?
>>
>>
>> Yup, plan was to see it through. I'll document it as well - just let me
>> get these fixes implemented first.
>
>
> You've got plenty of time.  The stable release goal is the late
> June/early July time frame.
>
>>
>>> On 3/30/2015 11:43 AM, Chris Pavlina wrote:
>>> > Well, seems I missed the freeze on this one, but I've got a patch,
>>> might
>>> > as well share. Works well for me - comments welcome, of course, and
>>> > ideas for more testcases.
>>> >
>>> > At schematic load, or when the tool is selected from the menu, the
>>> > schematic is analyzed for any problematic components. These are
>>> > where
>>> > the component found in the cache has pins moved or changed from
>>> the one
>>> > found in the system libraries. When this happens, the following
>>> dialog
>>> > is displayed:
>>> >
>>> > https://db.tt/qIAesEQv
>>> >
>>> > The user can choose per symbol whether to keep the library version
>>> > or
>>> > the cached version.  Any cached components selected for "rescue" are
>>> > renamed to "$componentname-RESCUE-$projectname" and placed in a
>>> > "$projectname-rescue" library, which is added to the project at
>>> the top
>>> > of the library list.
>>> >
>>> > When the operation is complete, the user is presented with a nice
>>> > summary of the renames done.
>>> >
>>> > Aliases are a tricky c

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Nick Østergaard]

I just tested this again, after reporting some of the above, but now
solved issues to Chris. Thanks for fixing so fast.

2015-04-12 19:57 GMT+02:00 Chris Pavlina :
> And, because I'm excessively stupid today, here's a version of the patch
> that I didn't diff incorrectly.
>
>
> On Fri, Apr 10, 2015 at 07:15:00PM -0400, Wayne Stambaugh wrote:
>>
>> On 4/8/2015 8:48 PM, Chris Pavlina wrote:
>>>
>>> Any more devs have an opinion on this?
>>
>>
>> I've already said it would be a good idea albeit a temporary one for the
>> upcoming stable release.  I just saw another reply to a bug report about
>> someones schematic being incorrect because the library components have
>> changed.  Looking at the changes to the component libraries, it would be
>> my guess that we will have a lot of upset users who have not upgrade
>> from the previous stable release.  Does anyone else have any opinions
>> about this?
>>
>>>
>>> On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote:

 On 3/30/2015 1:58 PM, Chris Pavlina wrote:
>
>
> On Mar 30, 2015 1:49 PM, "Wayne Stambaugh"  > wrote:
>>
>>
>> Please fix your coding style issues.  I saw:
>>
>> if( foo ) bar;
>>
>> should be:
>>
>> if( foo )
>> bar;
>>
>> Also, two blank lines between function definitions in cpp files.
>
>
> Oops, missed these bits of the style. Will fix by tomorrow.
>
>> In the future, please do not create OnOk()/OnCancel() message handlers
>> then call EndModal() in your dialogs.  This is broken by design.  Your
>> dialog may not always be modal.  It may be useful to create them as
>> modeless or quasi-modal so calling EndModal() fail.  I know it is used
>> in virtually every dialog in KiCad and it is fundamentally wrong.  The
>> wxWidgets developers were kind enough to create all the necessary
>> plumbing to handle this.  Please read
>> http://docs.wxwidgets.org/3.0/overview_validator.html and take look at
>> common/dialogs/dialog_env_var_config.cpp for tips on transferring data
>> to and from the controls using wxDialog.
>
>
> Oh, you'll have to forgive me, I'm a bit new to wx. Not just "in the
> future", I'll get this fixed as well. Last thing I want to do is add
> broken code to KiCad. Perhaps I'll help out and start working on fixing
> some of the existing ones too.


 Thanks.  Don't worry about the existing ones until after the stable
 release.  I want to keep focused on that until it's done.  Otherwise, we
 will just keep making changes and never get the stable release out the
 door.  I want to let everything stabilize and make sure we get all of
 the bugs fixed.

>
>> [snip] I need your
>> assurance that you will see it through to the stable release before
>> I'm
>> willing to give it my approval. I would also appreciate if you could
>> update the Eeschema documentation at
>> https://github.com/ciampix/kicad-doc or have someone document it for
>> you.  What say the rest of you?
>
>
> Yup, plan was to see it through. I'll document it as well - just let me
> get these fixes implemented first.


 You've got plenty of time.  The stable release goal is the late
 June/early July time frame.

>
>> On 3/30/2015 11:43 AM, Chris Pavlina wrote:
>> > Well, seems I missed the freeze on this one, but I've got a patch,
>> might
>> > as well share. Works well for me - comments welcome, of course, and
>> > ideas for more testcases.
>> >
>> > At schematic load, or when the tool is selected from the menu, the
>> > schematic is analyzed for any problematic components. These are
>> > where
>> > the component found in the cache has pins moved or changed from
>> the one
>> > found in the system libraries. When this happens, the following
>> dialog
>> > is displayed:
>> >
>> > https://db.tt/qIAesEQv
>> >
>> > The user can choose per symbol whether to keep the library version
>> > or
>> > the cached version.  Any cached components selected for "rescue" are
>> > renamed to "$componentname-RESCUE-$projectname" and placed in a
>> > "$projectname-rescue" library, which is added to the project at
>> the top
>> > of the library list.
>> >
>> > When the operation is complete, the user is presented with a nice
>> > summary of the renames done.
>> >
>> > Aliases are a tricky case, because the cached and library components
>> > don't have to have the same alias list. The simplest way I found to
>> > handle this was to break apart aliases in the -rescue library: all
>> > components are stored as single parts with no aliases.
>> >
>> > For those who don't want their hands held, there is a "Never Show
>> Again"
>> > button.  The setting for this can be rever

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Nick Østergaard]

I just tried the rescue3.patch, and it works without segfaulting. Also
I think the functionality of it is nice.

2015-04-11 2:59 GMT+02:00 Chris Pavlina :
> Okay, here's a fixed version.
>
>
> On Fri, Apr 10, 2015 at 07:15:00PM -0400, Wayne Stambaugh wrote:
>>
>> On 4/8/2015 8:48 PM, Chris Pavlina wrote:
>>>
>>> Any more devs have an opinion on this?
>>
>>
>> I've already said it would be a good idea albeit a temporary one for the
>> upcoming stable release.  I just saw another reply to a bug report about
>> someones schematic being incorrect because the library components have
>> changed.  Looking at the changes to the component libraries, it would be
>> my guess that we will have a lot of upset users who have not upgrade
>> from the previous stable release.  Does anyone else have any opinions
>> about this?
>>
>>>
>>> On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote:

 On 3/30/2015 1:58 PM, Chris Pavlina wrote:
>
>
> On Mar 30, 2015 1:49 PM, "Wayne Stambaugh"  > wrote:
>>
>>
>> Please fix your coding style issues.  I saw:
>>
>> if( foo ) bar;
>>
>> should be:
>>
>> if( foo )
>> bar;
>>
>> Also, two blank lines between function definitions in cpp files.
>
>
> Oops, missed these bits of the style. Will fix by tomorrow.
>
>> In the future, please do not create OnOk()/OnCancel() message handlers
>> then call EndModal() in your dialogs.  This is broken by design.  Your
>> dialog may not always be modal.  It may be useful to create them as
>> modeless or quasi-modal so calling EndModal() fail.  I know it is used
>> in virtually every dialog in KiCad and it is fundamentally wrong.  The
>> wxWidgets developers were kind enough to create all the necessary
>> plumbing to handle this.  Please read
>> http://docs.wxwidgets.org/3.0/overview_validator.html and take look at
>> common/dialogs/dialog_env_var_config.cpp for tips on transferring data
>> to and from the controls using wxDialog.
>
>
> Oh, you'll have to forgive me, I'm a bit new to wx. Not just "in the
> future", I'll get this fixed as well. Last thing I want to do is add
> broken code to KiCad. Perhaps I'll help out and start working on fixing
> some of the existing ones too.


 Thanks.  Don't worry about the existing ones until after the stable
 release.  I want to keep focused on that until it's done.  Otherwise, we
 will just keep making changes and never get the stable release out the
 door.  I want to let everything stabilize and make sure we get all of
 the bugs fixed.

>
>> [snip] I need your
>> assurance that you will see it through to the stable release before
>> I'm
>> willing to give it my approval. I would also appreciate if you could
>> update the Eeschema documentation at
>> https://github.com/ciampix/kicad-doc or have someone document it for
>> you.  What say the rest of you?
>
>
> Yup, plan was to see it through. I'll document it as well - just let me
> get these fixes implemented first.


 You've got plenty of time.  The stable release goal is the late
 June/early July time frame.

>
>> On 3/30/2015 11:43 AM, Chris Pavlina wrote:
>> > Well, seems I missed the freeze on this one, but I've got a patch,
>> might
>> > as well share. Works well for me - comments welcome, of course, and
>> > ideas for more testcases.
>> >
>> > At schematic load, or when the tool is selected from the menu, the
>> > schematic is analyzed for any problematic components. These are
>> > where
>> > the component found in the cache has pins moved or changed from
>> the one
>> > found in the system libraries. When this happens, the following
>> dialog
>> > is displayed:
>> >
>> > https://db.tt/qIAesEQv
>> >
>> > The user can choose per symbol whether to keep the library version
>> > or
>> > the cached version.  Any cached components selected for "rescue" are
>> > renamed to "$componentname-RESCUE-$projectname" and placed in a
>> > "$projectname-rescue" library, which is added to the project at
>> the top
>> > of the library list.
>> >
>> > When the operation is complete, the user is presented with a nice
>> > summary of the renames done.
>> >
>> > Aliases are a tricky case, because the cached and library components
>> > don't have to have the same alias list. The simplest way I found to
>> > handle this was to break apart aliases in the -rescue library: all
>> > components are stored as single parts with no aliases.
>> >
>> > For those who don't want their hands held, there is a "Never Show
>> Again"
>> > button.  The setting for this can be reverted by a checkbox in
>> Component
>> > Libraries if done by mistake.
>> >

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Chris Pavlina]

I should add that Nick found a bug that I am working on fixing at this moment - 
stopped working after a certain revision when something was changed - so anyone 
who wants to try it, either wait for me to track down what changed or apply the 
patch to a revision from around the time I submitted it. I've got git-bisect 
compiles running in the background as I type.


On Fri, Apr 10, 2015 at 07:15:00PM -0400, Wayne Stambaugh wrote:

On 4/8/2015 8:48 PM, Chris Pavlina wrote:

Any more devs have an opinion on this?


I've already said it would be a good idea albeit a temporary one for the
upcoming stable release.  I just saw another reply to a bug report about
someones schematic being incorrect because the library components have
changed.  Looking at the changes to the component libraries, it would be
my guess that we will have a lot of upset users who have not upgrade
from the previous stable release.  Does anyone else have any opinions
about this?



On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote:

On 3/30/2015 1:58 PM, Chris Pavlina wrote:


On Mar 30, 2015 1:49 PM, "Wayne Stambaugh" mailto:stambau...@gmail.com>> wrote:


Please fix your coding style issues.  I saw:

if( foo ) bar;

should be:

if( foo )
bar;

Also, two blank lines between function definitions in cpp files.


Oops, missed these bits of the style. Will fix by tomorrow.


In the future, please do not create OnOk()/OnCancel() message handlers
then call EndModal() in your dialogs.  This is broken by design.  Your
dialog may not always be modal.  It may be useful to create them as
modeless or quasi-modal so calling EndModal() fail.  I know it is used
in virtually every dialog in KiCad and it is fundamentally wrong.  The
wxWidgets developers were kind enough to create all the necessary
plumbing to handle this.  Please read
http://docs.wxwidgets.org/3.0/overview_validator.html and take look at
common/dialogs/dialog_env_var_config.cpp for tips on transferring data
to and from the controls using wxDialog.


Oh, you'll have to forgive me, I'm a bit new to wx. Not just "in the
future", I'll get this fixed as well. Last thing I want to do is add
broken code to KiCad. Perhaps I'll help out and start working on fixing
some of the existing ones too.


Thanks.  Don't worry about the existing ones until after the stable
release.  I want to keep focused on that until it's done.  Otherwise, we
will just keep making changes and never get the stable release out the
door.  I want to let everything stabilize and make sure we get all of
the bugs fixed.




[snip] I need your
assurance that you will see it through to the stable release before I'm
willing to give it my approval. I would also appreciate if you could
update the Eeschema documentation at
https://github.com/ciampix/kicad-doc or have someone document it for
you.  What say the rest of you?


Yup, plan was to see it through. I'll document it as well - just let me
get these fixes implemented first.


You've got plenty of time.  The stable release goal is the late
June/early July time frame.




On 3/30/2015 11:43 AM, Chris Pavlina wrote:
> Well, seems I missed the freeze on this one, but I've got a patch,
might
> as well share. Works well for me - comments welcome, of course, and
> ideas for more testcases.
>
> At schematic load, or when the tool is selected from the menu, the
> schematic is analyzed for any problematic components. These are where
> the component found in the cache has pins moved or changed from
the one
> found in the system libraries. When this happens, the following
dialog
> is displayed:
>
> https://db.tt/qIAesEQv
>
> The user can choose per symbol whether to keep the library version or
> the cached version.  Any cached components selected for "rescue" are
> renamed to "$componentname-RESCUE-$projectname" and placed in a
> "$projectname-rescue" library, which is added to the project at
the top
> of the library list.
>
> When the operation is complete, the user is presented with a nice
> summary of the renames done.
>
> Aliases are a tricky case, because the cached and library components
> don't have to have the same alias list. The simplest way I found to
> handle this was to break apart aliases in the -rescue library: all
> components are stored as single parts with no aliases.
>
> For those who don't want their hands held, there is a "Never Show
Again"
> button.  The setting for this can be reverted by a checkbox in
Component
> Libraries if done by mistake.
>
> --
> Chris
>
> On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote:
>> On 3/23/2015 1:16 PM, Chris Pavlina wrote:
>>> On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote:
 On 3/23/2015 12:12 PM, Chris Pavlina wrote:
> I like your idea - I proposed it myself, but it was not well
> received ;)
> [[snip]]

 Please see the discussion here on why this will not work.

 https://bugs.launchpad.net/kicad/+bug/1435338

 I see no point in replacing one bu

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Wayne Stambaugh]

On 4/8/2015 8:48 PM, Chris Pavlina wrote:
> Any more devs have an opinion on this?

I've already said it would be a good idea albeit a temporary one for the
upcoming stable release.  I just saw another reply to a bug report about
someones schematic being incorrect because the library components have
changed.  Looking at the changes to the component libraries, it would be
my guess that we will have a lot of upset users who have not upgrade
from the previous stable release.  Does anyone else have any opinions
about this?

> 
> On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote:
>> On 3/30/2015 1:58 PM, Chris Pavlina wrote:
>>>
>>> On Mar 30, 2015 1:49 PM, "Wayne Stambaugh" >> > wrote:

 Please fix your coding style issues.  I saw:

 if( foo ) bar;

 should be:

 if( foo )
 bar;

 Also, two blank lines between function definitions in cpp files.
>>>
>>> Oops, missed these bits of the style. Will fix by tomorrow.
>>>
 In the future, please do not create OnOk()/OnCancel() message handlers
 then call EndModal() in your dialogs.  This is broken by design.  Your
 dialog may not always be modal.  It may be useful to create them as
 modeless or quasi-modal so calling EndModal() fail.  I know it is used
 in virtually every dialog in KiCad and it is fundamentally wrong.  The
 wxWidgets developers were kind enough to create all the necessary
 plumbing to handle this.  Please read
 http://docs.wxwidgets.org/3.0/overview_validator.html and take look at
 common/dialogs/dialog_env_var_config.cpp for tips on transferring data
 to and from the controls using wxDialog.
>>>
>>> Oh, you'll have to forgive me, I'm a bit new to wx. Not just "in the
>>> future", I'll get this fixed as well. Last thing I want to do is add
>>> broken code to KiCad. Perhaps I'll help out and start working on fixing
>>> some of the existing ones too.
>>
>> Thanks.  Don't worry about the existing ones until after the stable
>> release.  I want to keep focused on that until it's done.  Otherwise, we
>> will just keep making changes and never get the stable release out the
>> door.  I want to let everything stabilize and make sure we get all of
>> the bugs fixed.
>>
>>>
 [snip] I need your
 assurance that you will see it through to the stable release before I'm
 willing to give it my approval. I would also appreciate if you could
 update the Eeschema documentation at
 https://github.com/ciampix/kicad-doc or have someone document it for
 you.  What say the rest of you?
>>>
>>> Yup, plan was to see it through. I'll document it as well - just let me
>>> get these fixes implemented first.
>>
>> You've got plenty of time.  The stable release goal is the late
>> June/early July time frame.
>>
>>>
 On 3/30/2015 11:43 AM, Chris Pavlina wrote:
 > Well, seems I missed the freeze on this one, but I've got a patch,
 might
 > as well share. Works well for me - comments welcome, of course, and
 > ideas for more testcases.
 >
 > At schematic load, or when the tool is selected from the menu, the
 > schematic is analyzed for any problematic components. These are where
 > the component found in the cache has pins moved or changed from
 the one
 > found in the system libraries. When this happens, the following
 dialog
 > is displayed:
 >
 > https://db.tt/qIAesEQv
 >
 > The user can choose per symbol whether to keep the library version or
 > the cached version.  Any cached components selected for "rescue" are
 > renamed to "$componentname-RESCUE-$projectname" and placed in a
 > "$projectname-rescue" library, which is added to the project at
 the top
 > of the library list.
 >
 > When the operation is complete, the user is presented with a nice
 > summary of the renames done.
 >
 > Aliases are a tricky case, because the cached and library components
 > don't have to have the same alias list. The simplest way I found to
 > handle this was to break apart aliases in the -rescue library: all
 > components are stored as single parts with no aliases.
 >
 > For those who don't want their hands held, there is a "Never Show
 Again"
 > button.  The setting for this can be reverted by a checkbox in
 Component
 > Libraries if done by mistake.
 >
 > --
 > Chris
 >
 > On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote:
 >> On 3/23/2015 1:16 PM, Chris Pavlina wrote:
 >>> On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote:
  On 3/23/2015 12:12 PM, Chris Pavlina wrote:
 > I like your idea - I proposed it myself, but it was not well
 > received ;)
 > [[snip]]
 
  Please see the discussion here on why this will not work.
 
  https://bugs.launchpad.net/kicad/+bug/1435338
 
 >

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Nick Østergaard]

FYI https://forum.kicad.info/t/disruptive-change-coming-to-schematics/727/8

2015-04-09 2:48 GMT+02:00 Chris Pavlina :
> Any more devs have an opinion on this?
>
>
> On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote:
>>
>> On 3/30/2015 1:58 PM, Chris Pavlina wrote:
>>>
>>>
>>> On Mar 30, 2015 1:49 PM, "Wayne Stambaugh" >> > wrote:


 Please fix your coding style issues.  I saw:

 if( foo ) bar;

 should be:

 if( foo )
 bar;

 Also, two blank lines between function definitions in cpp files.
>>>
>>>
>>> Oops, missed these bits of the style. Will fix by tomorrow.
>>>
 In the future, please do not create OnOk()/OnCancel() message handlers
 then call EndModal() in your dialogs.  This is broken by design.  Your
 dialog may not always be modal.  It may be useful to create them as
 modeless or quasi-modal so calling EndModal() fail.  I know it is used
 in virtually every dialog in KiCad and it is fundamentally wrong.  The
 wxWidgets developers were kind enough to create all the necessary
 plumbing to handle this.  Please read
 http://docs.wxwidgets.org/3.0/overview_validator.html and take look at
 common/dialogs/dialog_env_var_config.cpp for tips on transferring data
 to and from the controls using wxDialog.
>>>
>>>
>>> Oh, you'll have to forgive me, I'm a bit new to wx. Not just "in the
>>> future", I'll get this fixed as well. Last thing I want to do is add
>>> broken code to KiCad. Perhaps I'll help out and start working on fixing
>>> some of the existing ones too.
>>
>>
>> Thanks.  Don't worry about the existing ones until after the stable
>> release.  I want to keep focused on that until it's done.  Otherwise, we
>> will just keep making changes and never get the stable release out the
>> door.  I want to let everything stabilize and make sure we get all of
>> the bugs fixed.
>>
>>>
 [snip] I need your
 assurance that you will see it through to the stable release before I'm
 willing to give it my approval. I would also appreciate if you could
 update the Eeschema documentation at
 https://github.com/ciampix/kicad-doc or have someone document it for
 you.  What say the rest of you?
>>>
>>>
>>> Yup, plan was to see it through. I'll document it as well - just let me
>>> get these fixes implemented first.
>>
>>
>> You've got plenty of time.  The stable release goal is the late
>> June/early July time frame.
>>
>>>
 On 3/30/2015 11:43 AM, Chris Pavlina wrote:
 > Well, seems I missed the freeze on this one, but I've got a patch,
 > might
 > as well share. Works well for me - comments welcome, of course, and
 > ideas for more testcases.
 >
 > At schematic load, or when the tool is selected from the menu, the
 > schematic is analyzed for any problematic components. These are where
 > the component found in the cache has pins moved or changed from the
 > one
 > found in the system libraries. When this happens, the following dialog
 > is displayed:
 >
 > https://db.tt/qIAesEQv
 >
 > The user can choose per symbol whether to keep the library version or
 > the cached version.  Any cached components selected for "rescue" are
 > renamed to "$componentname-RESCUE-$projectname" and placed in a
 > "$projectname-rescue" library, which is added to the project at the
 > top
 > of the library list.
 >
 > When the operation is complete, the user is presented with a nice
 > summary of the renames done.
 >
 > Aliases are a tricky case, because the cached and library components
 > don't have to have the same alias list. The simplest way I found to
 > handle this was to break apart aliases in the -rescue library: all
 > components are stored as single parts with no aliases.
 >
 > For those who don't want their hands held, there is a "Never Show
 > Again"
 > button.  The setting for this can be reverted by a checkbox in
 > Component
 > Libraries if done by mistake.
 >
 > --
 > Chris
 >
 > On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote:
 >> On 3/23/2015 1:16 PM, Chris Pavlina wrote:
 >>> On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote:
  On 3/23/2015 12:12 PM, Chris Pavlina wrote:
 > I like your idea - I proposed it myself, but it was not well
 > received ;)
 > [[snip]]
 
  Please see the discussion here on why this will not work.
 
  https://bugs.launchpad.net/kicad/+bug/1435338
 
  I see no point in replacing one bug with another bug that doesn't
  fix
  the underlying problem.
 >>>
 >>> Haha, just kidding, I know :)
 >>>
  Rather than just copy the cache file, rename all of the footprints
  in
  the copied library with a prefix or suffix, i.e. 74LS00

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Chris Pavlina]

Any more devs have an opinion on this?

On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote:

On 3/30/2015 1:58 PM, Chris Pavlina wrote:


On Mar 30, 2015 1:49 PM, "Wayne Stambaugh" mailto:stambau...@gmail.com>> wrote:


Please fix your coding style issues.  I saw:

if( foo ) bar;

should be:

if( foo )
bar;

Also, two blank lines between function definitions in cpp files.


Oops, missed these bits of the style. Will fix by tomorrow.


In the future, please do not create OnOk()/OnCancel() message handlers
then call EndModal() in your dialogs.  This is broken by design.  Your
dialog may not always be modal.  It may be useful to create them as
modeless or quasi-modal so calling EndModal() fail.  I know it is used
in virtually every dialog in KiCad and it is fundamentally wrong.  The
wxWidgets developers were kind enough to create all the necessary
plumbing to handle this.  Please read
http://docs.wxwidgets.org/3.0/overview_validator.html and take look at
common/dialogs/dialog_env_var_config.cpp for tips on transferring data
to and from the controls using wxDialog.


Oh, you'll have to forgive me, I'm a bit new to wx. Not just "in the
future", I'll get this fixed as well. Last thing I want to do is add
broken code to KiCad. Perhaps I'll help out and start working on fixing
some of the existing ones too.


Thanks.  Don't worry about the existing ones until after the stable
release.  I want to keep focused on that until it's done.  Otherwise, we
will just keep making changes and never get the stable release out the
door.  I want to let everything stabilize and make sure we get all of
the bugs fixed.




[snip] I need your
assurance that you will see it through to the stable release before I'm
willing to give it my approval. I would also appreciate if you could
update the Eeschema documentation at
https://github.com/ciampix/kicad-doc or have someone document it for
you.  What say the rest of you?


Yup, plan was to see it through. I'll document it as well - just let me
get these fixes implemented first.


You've got plenty of time.  The stable release goal is the late
June/early July time frame.




On 3/30/2015 11:43 AM, Chris Pavlina wrote:
> Well, seems I missed the freeze on this one, but I've got a patch, might
> as well share. Works well for me - comments welcome, of course, and
> ideas for more testcases.
>
> At schematic load, or when the tool is selected from the menu, the
> schematic is analyzed for any problematic components. These are where
> the component found in the cache has pins moved or changed from the one
> found in the system libraries. When this happens, the following dialog
> is displayed:
>
> https://db.tt/qIAesEQv
>
> The user can choose per symbol whether to keep the library version or
> the cached version.  Any cached components selected for "rescue" are
> renamed to "$componentname-RESCUE-$projectname" and placed in a
> "$projectname-rescue" library, which is added to the project at the top
> of the library list.
>
> When the operation is complete, the user is presented with a nice
> summary of the renames done.
>
> Aliases are a tricky case, because the cached and library components
> don't have to have the same alias list. The simplest way I found to
> handle this was to break apart aliases in the -rescue library: all
> components are stored as single parts with no aliases.
>
> For those who don't want their hands held, there is a "Never Show Again"
> button.  The setting for this can be reverted by a checkbox in Component
> Libraries if done by mistake.
>
> --
> Chris
>
> On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote:
>> On 3/23/2015 1:16 PM, Chris Pavlina wrote:
>>> On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote:
 On 3/23/2015 12:12 PM, Chris Pavlina wrote:
> I like your idea - I proposed it myself, but it was not well
> received ;)
> [[snip]]

 Please see the discussion here on why this will not work.

 https://bugs.launchpad.net/kicad/+bug/1435338

 I see no point in replacing one bug with another bug that doesn't fix
 the underlying problem.
>>>
>>> Haha, just kidding, I know :)
>>>
 Rather than just copy the cache file, rename all of the footprints in
 the copied library with a prefix or suffix, i.e. 74LS00 in the cache
 becomes 74LS00_SCH in the new library.  Then rename all the

components

 in the schematic accordingly if the user chooses the new library
 option.
 This way there will be little chance of conflicting component

names and

 the library search order is less likely to be an issue.  This

gives you

 the best of both worlds.  You keep your existing components in the
 schematic and you can still use the updated components from the your
 libraries if you so choose.  Obviously this still wont fix the

library

 search ordering issue but it would be a more robust solution.
>>>
>>> Actually, I quite like this idea.
>>
>> I know it

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Wayne Stambaugh]

On 3/30/2015 1:58 PM, Chris Pavlina wrote:
> 
> On Mar 30, 2015 1:49 PM, "Wayne Stambaugh"  > wrote:
>>
>> Please fix your coding style issues.  I saw:
>>
>> if( foo ) bar;
>>
>> should be:
>>
>> if( foo )
>> bar;
>>
>> Also, two blank lines between function definitions in cpp files.
> 
> Oops, missed these bits of the style. Will fix by tomorrow.
> 
>> In the future, please do not create OnOk()/OnCancel() message handlers
>> then call EndModal() in your dialogs.  This is broken by design.  Your
>> dialog may not always be modal.  It may be useful to create them as
>> modeless or quasi-modal so calling EndModal() fail.  I know it is used
>> in virtually every dialog in KiCad and it is fundamentally wrong.  The
>> wxWidgets developers were kind enough to create all the necessary
>> plumbing to handle this.  Please read
>> http://docs.wxwidgets.org/3.0/overview_validator.html and take look at
>> common/dialogs/dialog_env_var_config.cpp for tips on transferring data
>> to and from the controls using wxDialog.
> 
> Oh, you'll have to forgive me, I'm a bit new to wx. Not just "in the
> future", I'll get this fixed as well. Last thing I want to do is add
> broken code to KiCad. Perhaps I'll help out and start working on fixing
> some of the existing ones too.

Thanks.  Don't worry about the existing ones until after the stable
release.  I want to keep focused on that until it's done.  Otherwise, we
will just keep making changes and never get the stable release out the
door.  I want to let everything stabilize and make sure we get all of
the bugs fixed.

> 
>> [snip] I need your
>> assurance that you will see it through to the stable release before I'm
>> willing to give it my approval. I would also appreciate if you could
>> update the Eeschema documentation at
>> https://github.com/ciampix/kicad-doc or have someone document it for
>> you.  What say the rest of you?
> 
> Yup, plan was to see it through. I'll document it as well - just let me
> get these fixes implemented first.

You've got plenty of time.  The stable release goal is the late
June/early July time frame.

> 
>> On 3/30/2015 11:43 AM, Chris Pavlina wrote:
>> > Well, seems I missed the freeze on this one, but I've got a patch, might
>> > as well share. Works well for me - comments welcome, of course, and
>> > ideas for more testcases.
>> >
>> > At schematic load, or when the tool is selected from the menu, the
>> > schematic is analyzed for any problematic components. These are where
>> > the component found in the cache has pins moved or changed from the one
>> > found in the system libraries. When this happens, the following dialog
>> > is displayed:
>> >
>> > https://db.tt/qIAesEQv
>> >
>> > The user can choose per symbol whether to keep the library version or
>> > the cached version.  Any cached components selected for "rescue" are
>> > renamed to "$componentname-RESCUE-$projectname" and placed in a
>> > "$projectname-rescue" library, which is added to the project at the top
>> > of the library list.
>> >
>> > When the operation is complete, the user is presented with a nice
>> > summary of the renames done.
>> >
>> > Aliases are a tricky case, because the cached and library components
>> > don't have to have the same alias list. The simplest way I found to
>> > handle this was to break apart aliases in the -rescue library: all
>> > components are stored as single parts with no aliases.
>> >
>> > For those who don't want their hands held, there is a "Never Show Again"
>> > button.  The setting for this can be reverted by a checkbox in Component
>> > Libraries if done by mistake.
>> >
>> > --
>> > Chris
>> >
>> > On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote:
>> >> On 3/23/2015 1:16 PM, Chris Pavlina wrote:
>> >>> On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote:
>>  On 3/23/2015 12:12 PM, Chris Pavlina wrote:
>> > I like your idea - I proposed it myself, but it was not well
>> > received ;)
>> > [[snip]]
>> 
>>  Please see the discussion here on why this will not work.
>> 
>>  https://bugs.launchpad.net/kicad/+bug/1435338
>> 
>>  I see no point in replacing one bug with another bug that doesn't fix
>>  the underlying problem.
>> >>>
>> >>> Haha, just kidding, I know :)
>> >>>
>>  Rather than just copy the cache file, rename all of the footprints in
>>  the copied library with a prefix or suffix, i.e. 74LS00 in the cache
>>  becomes 74LS00_SCH in the new library.  Then rename all the
> components
>>  in the schematic accordingly if the user chooses the new library
>>  option.
>>  This way there will be little chance of conflicting component
> names and
>>  the library search order is less likely to be an issue.  This
> gives you
>>  the best of both worlds.  You keep your existing components in the
>>  schematic and you can still use the updated components from the your
>>  libraries if you so choos

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Chris Pavlina]

On Mar 30, 2015 1:49 PM, "Wayne Stambaugh"  wrote:
>
> Please fix your coding style issues.  I saw:
>
> if( foo ) bar;
>
> should be:
>
> if( foo )
> bar;
>
> Also, two blank lines between function definitions in cpp files.

Oops, missed these bits of the style. Will fix by tomorrow.

> In the future, please do not create OnOk()/OnCancel() message handlers
> then call EndModal() in your dialogs.  This is broken by design.  Your
> dialog may not always be modal.  It may be useful to create them as
> modeless or quasi-modal so calling EndModal() fail.  I know it is used
> in virtually every dialog in KiCad and it is fundamentally wrong.  The
> wxWidgets developers were kind enough to create all the necessary
> plumbing to handle this.  Please read
> http://docs.wxwidgets.org/3.0/overview_validator.html and take look at
> common/dialogs/dialog_env_var_config.cpp for tips on transferring data
> to and from the controls using wxDialog.

Oh, you'll have to forgive me, I'm a bit new to wx. Not just "in the
future", I'll get this fixed as well. Last thing I want to do is add broken
code to KiCad. Perhaps I'll help out and start working on fixing some of
the existing ones too.

> [snip] I need your
> assurance that you will see it through to the stable release before I'm
> willing to give it my approval. I would also appreciate if you could
> update the Eeschema documentation at
> https://github.com/ciampix/kicad-doc or have someone document it for
> you.  What say the rest of you?

Yup, plan was to see it through. I'll document it as well - just let me get
these fixes implemented first.

> On 3/30/2015 11:43 AM, Chris Pavlina wrote:
> > Well, seems I missed the freeze on this one, but I've got a patch, might
> > as well share. Works well for me - comments welcome, of course, and
> > ideas for more testcases.
> >
> > At schematic load, or when the tool is selected from the menu, the
> > schematic is analyzed for any problematic components. These are where
> > the component found in the cache has pins moved or changed from the one
> > found in the system libraries. When this happens, the following dialog
> > is displayed:
> >
> > https://db.tt/qIAesEQv
> >
> > The user can choose per symbol whether to keep the library version or
> > the cached version.  Any cached components selected for "rescue" are
> > renamed to "$componentname-RESCUE-$projectname" and placed in a
> > "$projectname-rescue" library, which is added to the project at the top
> > of the library list.
> >
> > When the operation is complete, the user is presented with a nice
> > summary of the renames done.
> >
> > Aliases are a tricky case, because the cached and library components
> > don't have to have the same alias list. The simplest way I found to
> > handle this was to break apart aliases in the -rescue library: all
> > components are stored as single parts with no aliases.
> >
> > For those who don't want their hands held, there is a "Never Show Again"
> > button.  The setting for this can be reverted by a checkbox in Component
> > Libraries if done by mistake.
> >
> > --
> > Chris
> >
> > On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote:
> >> On 3/23/2015 1:16 PM, Chris Pavlina wrote:
> >>> On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote:
>  On 3/23/2015 12:12 PM, Chris Pavlina wrote:
> > I like your idea - I proposed it myself, but it was not well
> > received ;)
> > [[snip]]
> 
>  Please see the discussion here on why this will not work.
> 
>  https://bugs.launchpad.net/kicad/+bug/1435338
> 
>  I see no point in replacing one bug with another bug that doesn't fix
>  the underlying problem.
> >>>
> >>> Haha, just kidding, I know :)
> >>>
>  Rather than just copy the cache file, rename all of the footprints in
>  the copied library with a prefix or suffix, i.e. 74LS00 in the cache
>  becomes 74LS00_SCH in the new library.  Then rename all the
components
>  in the schematic accordingly if the user chooses the new library
>  option.
>  This way there will be little chance of conflicting component names
and
>  the library search order is less likely to be an issue.  This gives
you
>  the best of both worlds.  You keep your existing components in the
>  schematic and you can still use the updated components from the your
>  libraries if you so choose.  Obviously this still wont fix the
library
>  search ordering issue but it would be a more robust solution.
> >>>
> >>> Actually, I quite like this idea.
> >>
> >> I know it's more work but it solves the component name clash issues and
> >> the user will still be able to use their normal libraries.
> >>
> >>>
> >>> ___
> >>> 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.n

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Wayne Stambaugh]

Please fix your coding style issues.  I saw:

if( foo ) bar;

should be:

if( foo )
bar;

Also, two blank lines between function definitions in cpp files.

In the future, please do not create OnOk()/OnCancel() message handlers
then call EndModal() in your dialogs.  This is broken by design.  Your
dialog may not always be modal.  It may be useful to create them as
modeless or quasi-modal so calling EndModal() fail.  I know it is used
in virtually every dialog in KiCad and it is fundamentally wrong.  The
wxWidgets developers were kind enough to create all the necessary
plumbing to handle this.  Please read
http://docs.wxwidgets.org/3.0/overview_validator.html and take look at
common/dialogs/dialog_env_var_config.cpp for tips on transferring data
to and from the controls using wxDialog.

Now that we are in feature freeze, this will require approval of the
development team before it can be committed.  I think it's a good idea
for users who have stuck with the old stable version to have this when
their component libraries get updated to have this feature.  I need your
assurance that you will see it through to the stable release before I'm
willing to give it my approval.  I would also appreciate if you could
update the Eeschema documentation at
https://github.com/ciampix/kicad-doc or have someone document it for
you.  What say the rest of you?

On 3/30/2015 11:43 AM, Chris Pavlina wrote:
> Well, seems I missed the freeze on this one, but I've got a patch, might
> as well share. Works well for me - comments welcome, of course, and
> ideas for more testcases.
> 
> At schematic load, or when the tool is selected from the menu, the
> schematic is analyzed for any problematic components. These are where
> the component found in the cache has pins moved or changed from the one
> found in the system libraries. When this happens, the following dialog
> is displayed:
> 
> https://db.tt/qIAesEQv
> 
> The user can choose per symbol whether to keep the library version or
> the cached version.  Any cached components selected for "rescue" are
> renamed to "$componentname-RESCUE-$projectname" and placed in a
> "$projectname-rescue" library, which is added to the project at the top
> of the library list.
> 
> When the operation is complete, the user is presented with a nice
> summary of the renames done.
> 
> Aliases are a tricky case, because the cached and library components
> don't have to have the same alias list. The simplest way I found to
> handle this was to break apart aliases in the -rescue library: all
> components are stored as single parts with no aliases.
> 
> For those who don't want their hands held, there is a "Never Show Again"
> button.  The setting for this can be reverted by a checkbox in Component
> Libraries if done by mistake.
> 
> -- 
> Chris
> 
> On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote:
>> On 3/23/2015 1:16 PM, Chris Pavlina wrote:
>>> On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote:
 On 3/23/2015 12:12 PM, Chris Pavlina wrote:
> I like your idea - I proposed it myself, but it was not well
> received ;)
> [[snip]]

 Please see the discussion here on why this will not work.

 https://bugs.launchpad.net/kicad/+bug/1435338

 I see no point in replacing one bug with another bug that doesn't fix
 the underlying problem.
>>>
>>> Haha, just kidding, I know :)
>>>
 Rather than just copy the cache file, rename all of the footprints in
 the copied library with a prefix or suffix, i.e. 74LS00 in the cache
 becomes 74LS00_SCH in the new library.  Then rename all the components
 in the schematic accordingly if the user chooses the new library
 option.
 This way there will be little chance of conflicting component names and
 the library search order is less likely to be an issue.  This gives you
 the best of both worlds.  You keep your existing components in the
 schematic and you can still use the updated components from the your
 libraries if you so choose.  Obviously this still wont fix the library
 search ordering issue but it would be a more robust solution.
>>>
>>> Actually, I quite like this idea.
>>
>> I know it's more work but it solves the component name clash issues and
>> the user will still be able to use their normal libraries.
>>
>>>
>>> ___
>>> 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
>>
>> ___
>> 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
> 
> 
> ___
> Mailing list: https://launchpad.net/~kic

Re: [Kicad-developers] [patch?] Handling conflict between projname-cache.lib and an updated library

[Chris Pavlina]

Well, that was kind of the point - a stopgap for now, to keep the 
current way the symbols were handled from confusing people too much. I 
planned for it to become obsolete :D


On Mon, Mar 30, 2015 at 05:55:34PM +0200, Tomasz Wlostowski wrote:

On 30.03.2015 17:43, Chris Pavlina wrote:

[snip]


Hi Chris,

Nice patch, although with its current purpose, it will become obsolete
in the future, as the new schematic file format Wayne's working on will
add the possibility to cache the schematic symbols within .kicad_sch
files (just like the footprint copies are stored in .kicad_pcb files now).

Nonetheless, your tool (after some minor refactoring) could make a nice
library to SCH symbol updater (or sch->library symbol extractor), a
feature present in most good EDA tools ;)

Tom



--
Chris

On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote:

On 3/23/2015 1:16 PM, Chris Pavlina wrote:

On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote:

On 3/23/2015 12:12 PM, Chris Pavlina wrote:

I like your idea - I proposed it myself, but it was not well
received ;)
[[snip]]


Please see the discussion here on why this will not work.

https://bugs.launchpad.net/kicad/+bug/1435338

I see no point in replacing one bug with another bug that doesn't fix
the underlying problem.


Haha, just kidding, I know :)


Rather than just copy the cache file, rename all of the footprints in
the copied library with a prefix or suffix, i.e. 74LS00 in the cache
becomes 74LS00_SCH in the new library.  Then rename all the components
in the schematic accordingly if the user chooses the new library
option.
This way there will be little chance of conflicting component names and
the library search order is less likely to be an issue.  This gives you
the best of both worlds.  You keep your existing components in the
schematic and you can still use the updated components from the your
libraries if you so choose.  Obviously this still wont fix the library
search ordering issue but it would be a more robust solution.


Actually, I quite like this idea.


I know it's more work but it solves the component name clash issues and
the user will still be able to use their normal libraries.



___
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


___
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



___
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





___
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] [patch?] Handling conflict between projname-cache.lib and an updated library

[Tomasz Wlostowski]

On 30.03.2015 17:43, Chris Pavlina wrote:
> Well, seems I missed the freeze on this one, but I've got a patch, might
> as well share. Works well for me - comments welcome, of course, and
> ideas for more testcases.
> 
> At schematic load, or when the tool is selected from the menu, the
> schematic is analyzed for any problematic components. These are where
> the component found in the cache has pins moved or changed from the one
> found in the system libraries. When this happens, the following dialog
> is displayed:
> 
> https://db.tt/qIAesEQv
> 
> The user can choose per symbol whether to keep the library version or
> the cached version.  Any cached components selected for "rescue" are
> renamed to "$componentname-RESCUE-$projectname" and placed in a
> "$projectname-rescue" library, which is added to the project at the top
> of the library list.
> 
> When the operation is complete, the user is presented with a nice
> summary of the renames done.
> 
> Aliases are a tricky case, because the cached and library components
> don't have to have the same alias list. The simplest way I found to
> handle this was to break apart aliases in the -rescue library: all
> components are stored as single parts with no aliases.
> 
> For those who don't want their hands held, there is a "Never Show Again"
> button.  The setting for this can be reverted by a checkbox in Component
> Libraries if done by mistake.

Hi Chris,

Nice patch, although with its current purpose, it will become obsolete
in the future, as the new schematic file format Wayne's working on will
add the possibility to cache the schematic symbols within .kicad_sch
files (just like the footprint copies are stored in .kicad_pcb files now).

Nonetheless, your tool (after some minor refactoring) could make a nice
library to SCH symbol updater (or sch->library symbol extractor), a
feature present in most good EDA tools ;)

Tom

> 
> -- 
> Chris
> 
> On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote:
>> On 3/23/2015 1:16 PM, Chris Pavlina wrote:
>>> On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote:
 On 3/23/2015 12:12 PM, Chris Pavlina wrote:
> I like your idea - I proposed it myself, but it was not well
> received ;)
> [[snip]]

 Please see the discussion here on why this will not work.

 https://bugs.launchpad.net/kicad/+bug/1435338

 I see no point in replacing one bug with another bug that doesn't fix
 the underlying problem.
>>>
>>> Haha, just kidding, I know :)
>>>
 Rather than just copy the cache file, rename all of the footprints in
 the copied library with a prefix or suffix, i.e. 74LS00 in the cache
 becomes 74LS00_SCH in the new library.  Then rename all the components
 in the schematic accordingly if the user chooses the new library
 option.
 This way there will be little chance of conflicting component names and
 the library search order is less likely to be an issue.  This gives you
 the best of both worlds.  You keep your existing components in the
 schematic and you can still use the updated components from the your
 libraries if you so choose.  Obviously this still wont fix the library
 search ordering issue but it would be a more robust solution.
>>>
>>> Actually, I quite like this idea.
>>
>> I know it's more work but it solves the component name clash issues and
>> the user will still be able to use their normal libraries.
>>
>>>
>>> ___
>>> 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
>>
>> ___
>> 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
> 
> 
> ___
> 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
> 


___
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