kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

On Mar 30, 2015 1:49 PM, "Wayne Stambaugh" <stambaughw@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp