Re: [Kicad-developers] [PATCH] Eeschema automatic manage junctions

[Eldar Khayrullin]

The related issue
https://bugs.launchpad.net/kicad/+bug/1491052

В Среда, 22 ноя. 2017 в 11:07 П. П., Seth Hillbrand 
 написал:
Updated patchset for this proposal, rebased to master.  I've also 
updated the commit messages to match the CHANGE:/NEW: format and 
added one new bug from launchpad that this addresses.


-Seth

On Wed, Nov 8, 2017 at 3:59 AM, Nick Østergaard  
wrote:
For that specific issue with the junction drawing, there is a patch 
in the thread "[Kicad-developers] [PATCH] Draw junctions last"


2017-11-03 13:12 GMT+01:00 Jon Evans :
I looked at fixing this and some other related things, and decided 
to just wait for the GAL port. There will need to be huge 
refactoring of the eeschema draw code as part of that effort, so 
putting much effort into making the wxDC drawing better seems not 
worth it.


-Jon

On Nov 3, 2017 00:08, "Kevin Cozens"  wrote:

On 2017-11-02 06:31 PM, Seth Hillbrand wrote:
Please let me know if there are any additional issues or 
suggestions for improvement.


How difficult would it be to have junctions draw last on 
schematics? There is a minor negative visual effect when you have 
a component with one end joined to a wire by a junction and you 
replace the component.


When you replace the component the pin of the component is now 
seen extending through the round disc of the junction to the 
center of the junction. I prefer to always see just the full round 
disc of a junction mark even if I have replaced a component since 
placing the junction.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that 
distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's 
why we're

| powerful!"
#include  | --Chris Hardwick


___
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] emails in about box

[Oliver Walters]

+1

On 25 Nov 2017 16:15, "Chris Pavlina"  wrote:

> Hi,
>
> Can we please have a (hopefully short) discussion on the presence of
> developer email addresses in the About box? I don't want or need mine
> there. People can find it if they really want to, but I see no need to
> advertise myself in the about box as if I'm inviting people to contact
> me personally. I don't want them to.
>
> I'd remove it myself, but I didn't put it there either, so I'm sure
> it'll find its way back if we don't address this.
>
> --
> Chris
>
> ___
> 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

[Kicad-developers] emails in about box

[Chris Pavlina]

Hi,

Can we please have a (hopefully short) discussion on the presence of
developer email addresses in the About box? I don't want or need mine
there. People can find it if they really want to, but I see no need to
advertise myself in the about box as if I'm inviting people to contact
me personally. I don't want them to.

I'd remove it myself, but I didn't put it there either, so I'm sure
it'll find its way back if we don't address this.

-- 
Chris

___
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] terms clarification

[Andy Peters]

> On Nov 22, 2017, at 7:53 AM, Wayne Stambaugh  wrote:
> 
> On 11/22/2017 08:42 AM, jp charras wrote:
>> Le 22/11/2017 à 14:28, Marco Ciampa a écrit :
>>> On Wed, Nov 22, 2017 at 08:14:02AM -0500, Wayne Stambaugh wrote:
 The devs discussed this some time ago and the general consensus is that
 symbol is the preferred term.  I've already started converting the UI
 strings to use the term symbol.  I'm sure there are UI strings that I
 missed.  If you find them, please let me know so I can correct them.
 
>>> 
>>> I think that then there is some term confusion here ...
>>> 
>>> #: eeschema/menubar.cpp:462
>>> msgid ""
>>> "Edit components to symbols library links to switch to an other library 
>>> link "
>>> "(library IDs)"
>>> 
>>> This obviously is not "symbol to symbol link" ...
>>> 
>>> I really think that we should stick with the terms "footprint" and
>>> "symbol" only, and get rid of all the "component", "part", "module" and
>>> such altogether...
>>> 
>>> TIA
>> 
>> Sure 'This obviously is not symbol to symbol link",
>> but what is the meaning of "symbol to symbol link"
>> 
>> Symbols live in symbol libraries, and components in schematic files, at 
>> least for this menu.
>> And currently a symbol does not live in a schematic,
>> and a component has a link (lib id) to the symbol it uses in the schematic.
> 
> I think the terminology should be "library symbol" and "schematic
> symbol".  Both exist but schematic symbols have no graphic items other
> than fields.  The actual graphical representation of the symbol itself
> is a link to a symbol in a library.

From a user’s perspective, at least for Mario’s original question:

“Component” and “part” are synonymous. At least, this is the consensus over at 
the kicad.info user forum.

That consensus extends to: A component is a symbol which has an associated 
footprint. This implies that CvPCB is not used, and a component in a symbol 
library has a valid entry in its Footprint field. When you place a component 
onto the schematic, it contains everything necessary to use it in the layout.

If the symbol in the library has an empty footprint field, it is just a symbol. 
A user may create a symbol so something might be included in the BOM. A symbol 
might be created for use with SPICE. The power symbols are just that, symbols.

A “fully atomic part” is a symbol with a footprint and some kind of part number 
information to make it unique. That is, an OPA551PA symbol will have its 
footprint field filled in with DIP8_300 (or some other 8-pin DIP package) and a 
custom Part Number field is added and is filled in with something useful for 
the user.

All that said, whatever nomenclature ends up being chosen should be documented 
so everyone understands what is meant by each term.



___
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] Tweaks to about dialog

[Simon Wells]

The other option is change all the “credits tabs” in the about dialog into 
something similar to what freecad uses, then it would just be a text file to 
update thats included in the distribution and is MUCH easier to update, and can 
use multiple files (including one in the package set to include people from 
there

> On 25/11/2017, at 10:01 AM, Oliver Walters  
> wrote:
> 
> Can we have a link to a page on the website where we have a long form list? 
> Updating a binary file with a fluid list of contributors seems hokey. 
> 
> The 3D models for example are now script generated using Maurice's tools but 
> contributed by various people. 
> 
> On 25 Nov 2017 06:37, "Simon Wells"  > wrote:
> Well if you want to keep that panel it should represent all those people who 
> have provided artistry to kicad, as such for those non programmers maybe 
> there needs to be a script or similar that someone can just put their name in 
> and it will spit out a patch that can be submitted to the mailing list
> 
> 
> 
> > On 25/11/2017, at 3:44 AM, Wayne Stambaugh  > > wrote:
> >
> > Oliver,
> >
> > I would rather not remove the artists panel from the about dialog.  I
> > know some of those folks haven't contributed recently but many of them
> > contributed a lot of bitmaps and icons over the years so they deserve
> > credit for the efforts.  The remaining changes are fine.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 11/23/2017 08:31 AM, Oliver Walters wrote:
> >> As mentioned in previous thread, I have made some slight changes to the
> >> About dialog.
> >>
> >> 1. Wording / link tweaks
> >> 2. Removed references to outdated links (now better served from the
> >> kicad-pcb.org   >> > site)
> >> 3. Removed "artists" tab - very outdated, 3D models are now community
> >> contributed
> >>
> >> I have also added myself as a developer credit - if this is an
> >> acceptable indulgence.
> >>
> >> Patch attached.
> >>
> >> Regards,
> >>
> >>
> >> ___
> >> 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] Migrating old designs best practice

[hauptmech]

On 25/11/17 02:14, Wayne Stambaugh wrote:

This is *the* fatal flaw with the cache library.  User's assume it is
stale symbols or a temporary copy.  It is not.  It is a snapshot of the
current library symbols linked to the symbols in the schematic.  It gets
refreshed every time the schematic is saved.  Once you delete this file
or keep an out of date copy using cvs, all bets are off.  It is only a
matter of time before one of your symbol libraries changes or gets
removed and you will end up with a broken schematic.  The rescue code
depends on the cache being up to date in order preserve you schematic.
If the cache is not current, the rescuing cannot be guaranteed.


I don't think it's necessarily a flaw. And your description above is 
indeed a cache. That's not a bad thing. I recall that I left it out of 
version control because I wanted to make sure fixes to my symbols were 
always propagated to the design. In the repo I'm referencing for this 
discussion I had 10 project files all using the same local library. I 
didn't want to have to manually update each schematic to propagate 
changes. Deleting untracked files was what I did instead. At the time no 
one was making breaking changes to system installed symbols, so the 
system libs were stable for this workflow.


I'm trying think of the least effort way to migrate an old design in 
these circumstances.


Can we have the rescue code fail if no cache file is found? That at 
least lets the user know they are in uncharted territory. Then if a lot 
of users come complaining you will know if it is worth doing a bit more 
in the rescue code.


If the cache is not available during rescue you can load a copy of the 
libraries that were current at the schematic save date and either 
re-cache them or rescue them directly. But this is only worth doing if a 
significant number of users are affected.



___
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] Math expression support for pad editor.

[Maciej Suminski]

Great, I have just pushed the patches to the master branch. Michael,
thank you very much. Footprint creation will be a pleasure now.

Cheers,
Orson

On 11/24/2017 05:27 PM, Wayne Stambaugh wrote:
> I'm fine with merging it if it meets with your approval.  I plan
> announcing the freeze on Sunday so use your best judgment.
> 
> Cheers,
> 
> Wayne
> 
> On 11/24/2017 11:18 AM, Maciej Sumiński wrote:
>> I patched NumericEvaluator to use the system locale to pick the right
>> decimal separator character. I have tested it on Windows and Linux, no
>> issues found. In my opinion it is ready to be merged and could be a nice
>> bonus for v5. Sincerely, I love this feature, so I might be a bit biased.
>>
>> Cheers,
>> Orson
>>
>> On 11/24/2017 10:35 AM, Maciej Sumiński wrote:
>>> Thank you Michael, I have just updated the files and pushed to my
>>> branch. I am about to test the code on Windows and check for decimal
>>> separator character issues.
>>>
>>> Cheers,
>>> Orson
>>>
>>> On 11/24/2017 09:04 AM, Michael Geselbracht wrote:
 Hi,
 I have added some comments and examples to the code. The archive also
 contains a simple main() function (in main.cpp) and a Makefile in order to
 test the parser.
 The lemon parser generator is required to be installed and the macro
 "TEST_MODE" in numeric_evaluator.cpp  needs to be set to 1.

 There is also a bugfix in "newString()". Without it an empty input string
 results in an invalid output string.

  - Michael

 On Thu, Nov 23, 2017 at 11:01 PM, Michael Geselbracht <
 mgeselbrac...@gmail.com> wrote:

> Hi Russell,
>
> the class can handle variables in two ways:
> NumericEvaluator eval;
> 1. Assignment within expressions: eval.process("x=1; y=5");
> 2. Assignment from c++ code: eval.setVar("posx", -3.4);
>
> So it would be up to the dialog to add a variable to an eval object
> within a "focus lost" or "value changed" event.
> In case of (2) the variable "posx" could be used in following expressions.
> But this would require a shared eval object for all text boxes. Like one
> object for each dialog.
>
>  - Michael
>
>
> On Thu, Nov 23, 2017 at 9:02 PM, Russell Oliver 
> wrote:
>
>> Hi All,
>>
>> Just a query for Michael: can your parser be modified to include
>> references to dialog variables, ie while writing an expression for y axis
>> position, using the label posx or something would refer to the value
>> currently within that text box?
>>
>> Kind Regards
>> Russell
>>
>>
>> On 24 Nov 2017 06:54, "jp charras"  wrote:
>>
>> Le 23/11/2017 à 20:45, Michael Geselbracht a écrit :
>>> Hi,
>>> I have replaced the useless file info comments by a GPLv3 header  in
>> order to make my "libeval" code
>>> license-wise compatible to the Kicad project.
>>>
>>>  - Michael
>>>
>>>
>>
>> Thanks Michael,
>>
>> Could you add a bit of comments?
>> Currently God and you know the meaning of the code.
>> One day, only God will know the meaning of this code.
>>
>> Thanks.
>>
>>
>> --
>> Jean-Pierre CHARRAS
>>
>> ___
>> 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
>>>
>>
>>
>>
>>
>> ___
>> 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://h

Re: [Kicad-developers] Tweaks to about dialog

[Oliver Walters]

Can we have a link to a page on the website where we have a long form list?
Updating a binary file with a fluid list of contributors seems hokey.

The 3D models for example are now script generated using Maurice's tools
but contributed by various people.

On 25 Nov 2017 06:37, "Simon Wells"  wrote:

Well if you want to keep that panel it should represent all those people
who have provided artistry to kicad, as such for those non programmers
maybe there needs to be a script or similar that someone can just put their
name in and it will spit out a patch that can be submitted to the mailing
list



> On 25/11/2017, at 3:44 AM, Wayne Stambaugh  wrote:
>
> Oliver,
>
> I would rather not remove the artists panel from the about dialog.  I
> know some of those folks haven't contributed recently but many of them
> contributed a lot of bitmaps and icons over the years so they deserve
> credit for the efforts.  The remaining changes are fine.
>
> Cheers,
>
> Wayne
>
> On 11/23/2017 08:31 AM, Oliver Walters wrote:
>> As mentioned in previous thread, I have made some slight changes to the
>> About dialog.
>>
>> 1. Wording / link tweaks
>> 2. Removed references to outdated links (now better served from the
>> kicad-pcb.org  site)
>> 3. Removed "artists" tab - very outdated, 3D models are now community
>> contributed
>>
>> I have also added myself as a developer credit - if this is an
>> acceptable indulgence.
>>
>> Patch attached.
>>
>> Regards,
>>
>>
>> ___
>> 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] Migrating old designs best practice

[hauptmech]

On 25/11/17 03:26, Rene Pöschl wrote:

On 24/11/17 12:38, hauptmech wrote:

On 24 Nov 2017 10:52 pm, "Rene Pöschl"  wrote:

On 24/11/17 04:47, hauptmech wrote:


I can confirm unconnected wires. It may be worth noting that I did not
preserve the -cache.lib file when I archived the design.

I also had an issue with an old asymmetric diode footprint having its
anode and cathode reversed when I used it in a new design. If pin
numbers in the library got swapped around, then now I know why.

For myself, I would much rather that the old library parts get loaded
with my old design instead of trying to convert old parts to new parts.
Is it unreasonable to do that? Load the design with the old parts and
then do the rescue/migration rename? That way the old parts go into the
-rescue.lib file unchanged except for a name modification. Including 
the

old parts lib (perhaps concatenated into one file) does not seem too
difficult.

If the symbols are still unchanged in the library then you would not 
need

the cache lib. (The migration would simply point to the full name of the
symbol including the library name. Unless i understand the process 
wrong.)


The cache lib is necessary if the symbol in the library does change 
or is
deleted. If you also delete the cache lib, from where should KiCad 
get the

information how your old symbol(s) looked like? (The symbol data is not
stored inside the schematic files. It is only stored in the cache lib.)

These are not my symbols, they are kicad library symbols, for which i 
would

hope for either stability or a migration path.


So we can never ever change symbols?

It is not the responsibility of the library team to ensure that you 
archive your projects correctly.


(Also the lib is a git repo. So if you know when you made your project 
you can check out that old version of the lib.) 


Of course you can change symbols, though the peculiarities of the symbol 
data (lack of GUID's, use of pin location to determine schematic 
connectivity) along with the legacy of kicad being around a while means 
that the impact of changes might be hard to follow.


I do know when I made the project (and I already have a copy of the 
correct libs). Can you elaborate on how this works? Assuming I check out 
the correct version of the lib, how do I tell kicad to use that version 
instead of the system installed version?












___
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] Tweaks to about dialog

[Simon Wells]

Well if you want to keep that panel it should represent all those people who 
have provided artistry to kicad, as such for those non programmers maybe there 
needs to be a script or similar that someone can just put their name in and it 
will spit out a patch that can be submitted to the mailing list



> On 25/11/2017, at 3:44 AM, Wayne Stambaugh  wrote:
> 
> Oliver,
> 
> I would rather not remove the artists panel from the about dialog.  I
> know some of those folks haven't contributed recently but many of them
> contributed a lot of bitmaps and icons over the years so they deserve
> credit for the efforts.  The remaining changes are fine.
> 
> Cheers,
> 
> Wayne
> 
> On 11/23/2017 08:31 AM, Oliver Walters wrote:
>> As mentioned in previous thread, I have made some slight changes to the
>> About dialog.
>> 
>> 1. Wording / link tweaks
>> 2. Removed references to outdated links (now better served from the
>> kicad-pcb.org  site)
>> 3. Removed "artists" tab - very outdated, 3D models are now community
>> contributed
>> 
>> I have also added myself as a developer credit - if this is an
>> acceptable indulgence.
>> 
>> Patch attached.
>> 
>> Regards,
>> 
>> 
>> ___
>> 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] New feature notifications

[Wayne Stambaugh]

Looks good to me!  Thanks for taking care of this.

Cheers,

Wayne

On 11/24/2017 11:14 AM, Maciej Sumiński wrote:
> To have a concrete text that we can discuss, I propose an update to the
> Contribute->Developers page with the attached patch. What do you think?
> 
> Cheers,
> Orson
> 
> On 11/22/2017 04:21 PM, Wayne Stambaugh wrote:
>> On 11/22/2017 10:16 AM, Maciej Sumiński wrote:
>>> On 11/22/2017 03:55 PM, Wayne Stambaugh wrote:
 On 11/22/2017 08:55 AM, Maciej Sumiński wrote:
> On 11/22/2017 02:48 PM, Marco Ciampa wrote:
> [snip]
>> Please please please,
>>
>> when some new feature is accepted (code merged in master branch), either
>> write it in the dev (master) branch of the documentation or somewhere to
>> enable doc writers to describe the new feature... (wiki? txt in the
>> source code? Bug Report?)
>>
>> I think that a simple description in a bug report is the easiest way to
>> assure that new features get correctly described in the docs.
>> Parsing dev ml messages for these "hints" is IMHO unmanageable...
>>
>> TIA
>>
>
> Hi Marco,
>
> I thought we are supposed to use tags in commit messages (NEW, CHANGE)
> [1]. I can create a bug report in the documentation repository, if this
> is the preferred way. If so, then I suppose it should be made a policy.

 You are and you did.  Nice job!  The real question is how does this
 information make it from the source repo commit messages to doc devs so
 the docs can be updated accordingly?
>>>
>>> For example:
>>>
>>>   git log --grep="CHANGE[D]\?:\|REMOVE[D]\?:\|NEW:"
>>>
>>> I can turn it into an alias and add it to the same files that handles
>>> 'git fixes' command. You can also extend the query with a date or a
>>> commit hash. This way, once you enable the git alias configuration you
>>> may type:
>>>
>>>   git changelog --since="1 Jan 2017"
>>>
>>> or
>>>
>>>   git changelog 527c6f001
>>
>> Sorry about the miscommunication .  I am aware of how to extract the
>> information from git but I meant how does this information get to the
>> doc devs?  Are we expecting doc devs to periodically check the source
>> repo or do we want to do something more sophisticated like sending a
>> notice to the doc dev mailing list when a change is committed that
>> requires changes to the docs?  I'm not saying this is what I want and
>> I'm OK with whatever we decide, I'm just asking the question.
>>
>>>
>
> I am afraid it might be hard to follow for occasional patch submitters,
> should it be the committer responsible for creating a bug report?
>
> Regards,
> Orson
>
> 1. https://git.launchpad.net/kicad/commit/?id=527c6f0014b03
>
>
>
> ___
> 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
>>
> 

___
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] Math expression support for pad editor.

[Wayne Stambaugh]

I'm fine with merging it if it meets with your approval.  I plan
announcing the freeze on Sunday so use your best judgment.

Cheers,

Wayne

On 11/24/2017 11:18 AM, Maciej Sumiński wrote:
> I patched NumericEvaluator to use the system locale to pick the right
> decimal separator character. I have tested it on Windows and Linux, no
> issues found. In my opinion it is ready to be merged and could be a nice
> bonus for v5. Sincerely, I love this feature, so I might be a bit biased.
> 
> Cheers,
> Orson
> 
> On 11/24/2017 10:35 AM, Maciej Sumiński wrote:
>> Thank you Michael, I have just updated the files and pushed to my
>> branch. I am about to test the code on Windows and check for decimal
>> separator character issues.
>>
>> Cheers,
>> Orson
>>
>> On 11/24/2017 09:04 AM, Michael Geselbracht wrote:
>>> Hi,
>>> I have added some comments and examples to the code. The archive also
>>> contains a simple main() function (in main.cpp) and a Makefile in order to
>>> test the parser.
>>> The lemon parser generator is required to be installed and the macro
>>> "TEST_MODE" in numeric_evaluator.cpp  needs to be set to 1.
>>>
>>> There is also a bugfix in "newString()". Without it an empty input string
>>> results in an invalid output string.
>>>
>>>  - Michael
>>>
>>> On Thu, Nov 23, 2017 at 11:01 PM, Michael Geselbracht <
>>> mgeselbrac...@gmail.com> wrote:
>>>
 Hi Russell,

 the class can handle variables in two ways:
 NumericEvaluator eval;
 1. Assignment within expressions: eval.process("x=1; y=5");
 2. Assignment from c++ code: eval.setVar("posx", -3.4);

 So it would be up to the dialog to add a variable to an eval object
 within a "focus lost" or "value changed" event.
 In case of (2) the variable "posx" could be used in following expressions.
 But this would require a shared eval object for all text boxes. Like one
 object for each dialog.

  - Michael


 On Thu, Nov 23, 2017 at 9:02 PM, Russell Oliver 
 wrote:

> Hi All,
>
> Just a query for Michael: can your parser be modified to include
> references to dialog variables, ie while writing an expression for y axis
> position, using the label posx or something would refer to the value
> currently within that text box?
>
> Kind Regards
> Russell
>
>
> On 24 Nov 2017 06:54, "jp charras"  wrote:
>
> Le 23/11/2017 à 20:45, Michael Geselbracht a écrit :
>> Hi,
>> I have replaced the useless file info comments by a GPLv3 header  in
> order to make my "libeval" code
>> license-wise compatible to the Kicad project.
>>
>>  - Michael
>>
>>
>
> Thanks Michael,
>
> Could you add a bit of comments?
> Currently God and you know the meaning of the code.
> One day, only God will know the meaning of this code.
>
> Thanks.
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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
>>
> 
> 
> 
> 
> ___
> 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] [FEATURE] Eeschema Line Styles

[Seth Hillbrand]

Hi Chris, Eldar-

I looked at the drop-down button option and, as far as I can tell, this is
possible but non-trivial in wx.  As Wayne is freezing this weekend, I'll
look at ways of specifying current draw styles for 6.x dev branch.

-S

On Fri, Nov 17, 2017 at 11:25 PM, eldar.khayrullin  wrote:

> The same feature request how Chris suggested.
>
>
>
> Отправлено с устройства Samsung.
>
>  Исходное сообщение 
> От: Chris Pavlina 
> Дата: 18.11.17 3:44 (GMT+03:00)
> Кому: Seth Hillbrand 
> Копия: KiCad Developers 
> Тема: Re: [Kicad-developers] [FEATURE] Eeschema Line Styles
>
> Nice! I've wanted this for ages, thank you so much!
>
> Can I make a minor feature request? It'd be really nice if I could set
> the color and style before placing lines, so I can place arbitrarily
> many without having to change the style for each segment. Some editors
> do this by adding a style dropdown to the toolbar button (and displaying
> the selected style on the button). I can't remember how hard wx makes it
> to add dropdowns to toolbar buttons, but this sounds like a nice way to
> do it.
>
> --
> Chris
>
> On Fri, Nov 10, 2017 at 06:50:26PM +, Seth Hillbrand wrote:
> > One of the Eeschema features that has been requested for a while is
> > customizable graphic line styles that allow greater differentiation in
> > schematic documentation.  c.f.
> > https://bugs.launchpad.net/kicad/+bug/594059
> > https://bugs.launchpad.net/kicad/+bug/1405026
> >
> > The limitation has been not wanting to change the existing schematic
> format.
> >
> > I propose a way around this while implementing the desired feature.
> > Specifically, the attached patch allows the user to customize graphic
> lines
> > (schematic wires are disallowed), with the extra wire data being stored
> at
> > the end of the wire line.  This change should be transparent to the
> > existing schematic format as the trailing characters are ignored in the
> > legacy file reader.  Thus customization will be ignored if you are
> sharing
> > files between versions.
> >
> > Second, to avoid large, useless diffs in versioning storage, the patch
> does
> > not store any additional formatting data unless it has been changed from
> > the default.
> >
> > I'm attaching an image showing the line edit dialog as well as the patch
> > implementing this.  Please let me know if there are any questions or
> > suggestions for improvement.
> >
> > Best-
> > Seth
>
>
> ___
> 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] Math expression support for pad editor.

[Maciej Sumiński]

I patched NumericEvaluator to use the system locale to pick the right
decimal separator character. I have tested it on Windows and Linux, no
issues found. In my opinion it is ready to be merged and could be a nice
bonus for v5. Sincerely, I love this feature, so I might be a bit biased.

Cheers,
Orson

On 11/24/2017 10:35 AM, Maciej Sumiński wrote:
> Thank you Michael, I have just updated the files and pushed to my
> branch. I am about to test the code on Windows and check for decimal
> separator character issues.
> 
> Cheers,
> Orson
> 
> On 11/24/2017 09:04 AM, Michael Geselbracht wrote:
>> Hi,
>> I have added some comments and examples to the code. The archive also
>> contains a simple main() function (in main.cpp) and a Makefile in order to
>> test the parser.
>> The lemon parser generator is required to be installed and the macro
>> "TEST_MODE" in numeric_evaluator.cpp  needs to be set to 1.
>>
>> There is also a bugfix in "newString()". Without it an empty input string
>> results in an invalid output string.
>>
>>  - Michael
>>
>> On Thu, Nov 23, 2017 at 11:01 PM, Michael Geselbracht <
>> mgeselbrac...@gmail.com> wrote:
>>
>>> Hi Russell,
>>>
>>> the class can handle variables in two ways:
>>> NumericEvaluator eval;
>>> 1. Assignment within expressions: eval.process("x=1; y=5");
>>> 2. Assignment from c++ code: eval.setVar("posx", -3.4);
>>>
>>> So it would be up to the dialog to add a variable to an eval object
>>> within a "focus lost" or "value changed" event.
>>> In case of (2) the variable "posx" could be used in following expressions.
>>> But this would require a shared eval object for all text boxes. Like one
>>> object for each dialog.
>>>
>>>  - Michael
>>>
>>>
>>> On Thu, Nov 23, 2017 at 9:02 PM, Russell Oliver 
>>> wrote:
>>>
 Hi All,

 Just a query for Michael: can your parser be modified to include
 references to dialog variables, ie while writing an expression for y axis
 position, using the label posx or something would refer to the value
 currently within that text box?

 Kind Regards
 Russell


 On 24 Nov 2017 06:54, "jp charras"  wrote:

 Le 23/11/2017 à 20:45, Michael Geselbracht a écrit :
> Hi,
> I have replaced the useless file info comments by a GPLv3 header  in
 order to make my "libeval" code
> license-wise compatible to the Kicad project.
>
>  - Michael
>
>

 Thanks Michael,

 Could you add a bit of comments?
 Currently God and you know the meaning of the code.
 One day, only God will know the meaning of this code.

 Thanks.


 --
 Jean-Pierre CHARRAS

 ___
 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] New feature notifications

[Maciej Sumiński]

To have a concrete text that we can discuss, I propose an update to the
Contribute->Developers page with the attached patch. What do you think?

Cheers,
Orson

On 11/22/2017 04:21 PM, Wayne Stambaugh wrote:
> On 11/22/2017 10:16 AM, Maciej Sumiński wrote:
>> On 11/22/2017 03:55 PM, Wayne Stambaugh wrote:
>>> On 11/22/2017 08:55 AM, Maciej Sumiński wrote:
 On 11/22/2017 02:48 PM, Marco Ciampa wrote:
 [snip]
> Please please please,
>
> when some new feature is accepted (code merged in master branch), either
> write it in the dev (master) branch of the documentation or somewhere to
> enable doc writers to describe the new feature... (wiki? txt in the
> source code? Bug Report?)
>
> I think that a simple description in a bug report is the easiest way to
> assure that new features get correctly described in the docs.
> Parsing dev ml messages for these "hints" is IMHO unmanageable...
>
> TIA
>

 Hi Marco,

 I thought we are supposed to use tags in commit messages (NEW, CHANGE)
 [1]. I can create a bug report in the documentation repository, if this
 is the preferred way. If so, then I suppose it should be made a policy.
>>>
>>> You are and you did.  Nice job!  The real question is how does this
>>> information make it from the source repo commit messages to doc devs so
>>> the docs can be updated accordingly?
>>
>> For example:
>>
>>   git log --grep="CHANGE[D]\?:\|REMOVE[D]\?:\|NEW:"
>>
>> I can turn it into an alias and add it to the same files that handles
>> 'git fixes' command. You can also extend the query with a date or a
>> commit hash. This way, once you enable the git alias configuration you
>> may type:
>>
>>   git changelog --since="1 Jan 2017"
>>
>> or
>>
>>   git changelog 527c6f001
> 
> Sorry about the miscommunication .  I am aware of how to extract the
> information from git but I meant how does this information get to the
> doc devs?  Are we expecting doc devs to periodically check the source
> repo or do we want to do something more sophisticated like sending a
> notice to the doc dev mailing list when a change is committed that
> requires changes to the docs?  I'm not saying this is what I want and
> I'm OK with whatever we decide, I'm just asking the question.
> 
>>

 I am afraid it might be hard to follow for occasional patch submitters,
 should it be the committer responsible for creating a bug report?

 Regards,
 Orson

 1. https://git.launchpad.net/kicad/commit/?id=527c6f0014b03



 ___
 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
> 

From dde8e2364cf18e343153b2d77359713c13b29082 Mon Sep 17 00:00:00 2001
From: Maciej Suminski 
Date: Fri, 24 Nov 2017 17:07:12 +0100
Subject: [PATCH] contribute/developers: describe changelog tags

---
 content/contribute/developers.adoc | 37 +
 1 file changed, 37 insertions(+)

diff --git a/content/contribute/developers.adoc b/content/contribute/developers.adoc
index 4986c12..d9ed3ea 100644
--- a/content/contribute/developers.adoc
+++ b/content/contribute/developers.adoc
@@ -176,6 +176,43 @@ Afterwards you may mark commits using 'git fixes' command:
 git commit -a -m "Fixed a memleak"
 git fixes 12345678
 
+ Changelog tags 
+
+To facilitate following the code changes, please include a changelog tag to
+indicate modifications observable by the users. There are three types of
+changelog tags:
+
+- `NEW` to denote a new feature
+- `CHANGED` to indicate a modification of an existing feature
+- `REMOVED` to inform about removal of an existing feature
+
+There is no need to add changelog tags for commits that do not modify the way
+users interact with the software, such as code refactoring.
+
+When a commit with changelog tags is pushed, the committer should create a new
+issue in the link:https://github.com/KiCad/kicad-doc/iss

Re: [Kicad-developers] Getting kicad to work with wxPython Phoenix

[Wayne Stambaugh]

wxwidgets does not work well (at all?) when build with gtk3.  If your
custom build of phoenix and/or wxwidgets was built against gtk3, you are
going to issues.  Until the wx project resolves it's gtk3 issues, kicad
must be built with wx built with gtk2.

On 11/24/2017 04:19 AM, miles mccoo wrote:
> 
> 
> in reply to Wayne's request to run the footprint wizard
> 
> I run the footprint wizard; it seems to run fine.
> when I press the 3D view button, I get a popup complaining about not
> finding the wx gtk2 library
>   "10:14:11: libwx_gtk2u_core-3.0.so.0: cannot open shared object file:
> No such file or directory
>    10:14:11: libwx_gtk2u_core-3.0.so.0: cannot open shared object file:
> No such file or directory"
> 
> which is odd because I have the gtk3 version of wx on my system.
> 
> 
> 
> In the second half of the video below, I point out that after modifying
> module locations in python, the GAL screen doesn't seem to update, even
> with the refresh command from the menu. 
> 
> After I recorded the video, I found that switching to legacy canvas and
> then back to GAL, seems to trigger the needed redraw. How to I initiate
> this redraw from python? (or even c. I could update the swig stuff to
> call it in the refresh method available to python). Previously, I'd just
> worked in legacy but that's acting weird for me.
> 
> Miles
> 
> 
> 
> 
> On Thu, Nov 23, 2017 at 10:44 PM, Nick Østergaard  > wrote:
> 
> I guess this is the same idea as with
> https://github.com/KiCad/kicad-python
> 
> 
> 2017-11-23 19:28 GMT+01:00 Greg Smith  >:
> 
> "I was simply afraid that we
> may spent a lot of time petting the SWIG interface, which we
> will nuke
> it and start from scratch because of inevitable switch to Phoenix."
> 
> I agree. I would suggest that the Python API is not quite stable
> enough to freeze the API. If we desire a stable interface/API,
> one could be written in Python itself. I am on the edge of
> implementing such an interface with KiCommand.
> 
> KiCommand, in addition to being a command line interface, is a
> set of function calls that *could* be considered an API / Python
> class when complete.
> 
> I have reviewed the Python API unit tests and found them to be
> lacking in coverage. I am duplicating those tests in KiCommand,
> and plan to extend the KiCommand tests, which could potentially
> be applied to the current Python API.
> 
> If a stable API is desired, there should also be a set of unit
> tests verifying that functionality.
> 
> ___
> 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] Eeschema automatic manage junctions

[Maciej Sumiński]

Hi Seth,

I tested the branch and I consider it a significant improvement to the
way junctions are handled. I confirm it fixes the four bugs mentioned in
patch 0011, apart from a single case when a parallel component is
dragged out. In this case junctions are not still not auto deleted (see
[1], the rightmost picture "Junction is not auto deleted"), but at least
the overlapping wires are merged. It is not a big deal IMHO, especially
the patch set fixes a lot of other issues.

It has not been stated explicitly, but I thought we will use
NEW/REMOVE/CHANGE tags for listing changes that are perceived by the
user. Therefore:

  CHANGE: DeleteItem removes junctions that are no longer needed.

informs the user about an improvement, but:

  CHANGE: DeleteItemsInList shares the code for DeleteItem.

seems to be too detailed and does not need to be reflected in the user
documentation.

What do you think? I will try to come up with a short paragraph that can
be added to the website to make things clear.

Regards,
Orson

1.
https://launchpadlibrarian.net/213748651/KICAD%20-%20BUG%20REPORT%20-%20EESCHEMA%20-%20SOME%20DRAG%20ISSUES.jpg

On 11/22/2017 09:07 PM, Seth Hillbrand wrote:
> Updated patchset for this proposal, rebased to master.  I've also updated
> the commit messages to match the CHANGE:/NEW: format and added one new bug
> from launchpad that this addresses.
> 
> -Seth
> 
> On Wed, Nov 8, 2017 at 3:59 AM, Nick Østergaard  wrote:
> 
>> For that specific issue with the junction drawing, there is a patch in the
>> thread "[Kicad-developers] [PATCH] Draw junctions last"
>>
>> 2017-11-03 13:12 GMT+01:00 Jon Evans :
>>
>>> I looked at fixing this and some other related things, and decided to
>>> just wait for the GAL port. There will need to be huge refactoring of the
>>> eeschema draw code as part of that effort, so putting much effort into
>>> making the wxDC drawing better seems not worth it.
>>>
>>> -Jon
>>>
>>> On Nov 3, 2017 00:08, "Kevin Cozens"  wrote:
>>>
>>> On 2017-11-02 06:31 PM, Seth Hillbrand wrote:
>>>
 Please let me know if there are any additional issues or suggestions for
 improvement.

>>>
>>> How difficult would it be to have junctions draw last on schematics?
>>> There is a minor negative visual effect when you have a component with one
>>> end joined to a wire by a junction and you replace the component.
>>>
>>> When you replace the component the pin of the component is now seen
>>> extending through the round disc of the junction to the center of the
>>> junction. I prefer to always see just the full round disc of a junction
>>> mark even if I have replaced a component since placing the junction.
>>>
>>> --
>>> Cheers!
>>>
>>> Kevin.
>>>
>>> http://www.ve3syb.ca/   |"Nerds make the shiny things that
>>> distract
>>> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why
>>> we're
>>> | powerful!"
>>> #include  | --Chris Hardwick
>>>
>>>
>>> ___
>>> 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
> 





signature.asc
Description: OpenPGP digital signature
___
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] Tweaks to about dialog

[Wayne Stambaugh]

Oliver,

I would rather not remove the artists panel from the about dialog.  I
know some of those folks haven't contributed recently but many of them
contributed a lot of bitmaps and icons over the years so they deserve
credit for the efforts.  The remaining changes are fine.

Cheers,

Wayne

On 11/23/2017 08:31 AM, Oliver Walters wrote:
> As mentioned in previous thread, I have made some slight changes to the
> About dialog.
> 
> 1. Wording / link tweaks
> 2. Removed references to outdated links (now better served from the
> kicad-pcb.org  site)
> 3. Removed "artists" tab - very outdated, 3D models are now community
> contributed
> 
> I have also added myself as a developer credit - if this is an
> acceptable indulgence.
> 
> Patch attached.
> 
> Regards,
> 
> 
> ___
> 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] Migrating old designs best practice

[Rene Pöschl]

On 24/11/17 12:38, hauptmech wrote:

On 24 Nov 2017 10:52 pm, "Rene Pöschl"  wrote:

On 24/11/17 04:47, hauptmech wrote:


I can confirm unconnected wires. It may be worth noting that I did not
preserve the -cache.lib file when I archived the design.

I also had an issue with an old asymmetric diode footprint having its
anode and cathode reversed when I used it in a new design. If pin
numbers in the library got swapped around, then now I know why.

For myself, I would much rather that the old library parts get loaded
with my old design instead of trying to convert old parts to new parts.
Is it unreasonable to do that? Load the design with the old parts and
then do the rescue/migration rename? That way the old parts go into the
-rescue.lib file unchanged except for a name modification. Including the
old parts lib (perhaps concatenated into one file) does not seem too
difficult.


If the symbols are still unchanged in the library then you would not need
the cache lib. (The migration would simply point to the full name of the
symbol including the library name. Unless i understand the process wrong.)

The cache lib is necessary if the symbol in the library does change or is
deleted. If you also delete the cache lib, from where should KiCad get the
information how your old symbol(s) looked like? (The symbol data is not
stored inside the schematic files. It is only stored in the cache lib.)

These are not my symbols, they are kicad library symbols, for which i would
hope for either stability or a migration path.


So we can never ever change symbols?

It is not the responsibility of the library team to ensure that you 
archive your projects correctly.


(Also the lib is a git repo. So if you know when you made your project 
you can check out that old version of the lib.)



___
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] Getting kicad to work with wxPython Phoenix

[Maciej Sumiński]

Hi Miles,

On 11/24/2017 10:19 AM, miles mccoo wrote:
> in reply to Wayne's request to run the footprint wizard
> 
> I run the footprint wizard; it seems to run fine.
> when I press the 3D view button, I get a popup complaining about not
> finding the wx gtk2 library
>   "10:14:11: libwx_gtk2u_core-3.0.so.0: cannot open shared object file: No
> such file or directory
>10:14:11: libwx_gtk2u_core-3.0.so.0: cannot open shared object file: No
> such file or directory"
> 
> which is odd because I have the gtk3 version of wx on my system.
> 
> 
> 
> In the second half of the video below, I point out that after modifying
> module locations in python, the GAL screen doesn't seem to update, even
> with the refresh command from the menu.
> 
> After I recorded the video, I found that switching to legacy canvas and
> then back to GAL, seems to trigger the needed redraw. How to I initiate
> this redraw from python? (or even c. I could update the swig stuff to call
> it in the refresh method available to python). Previously, I'd just worked
> in legacy but that's acting weird for me.

There is a difference between the legacy and GAL way of drawing. In the
legacy canvas everything is redrawn on every screen refresh. To boost
performance in GAL, most of graphics data is stored in the video memory
and is only updated upon request. After an item is modified, you need to
call KIGFX::VIEW::Update() to refresh the graphics data.

There are more data structures that require updates (e.g. ratsnest). To
avoid tedious repetition there is a class called BOARD_COMMIT that
notifies all interested parties and additionally creates an undo entry.
Tom has already suggested that this class needs to be available in the
Python interface.

Regards,
Orson

> Miles
> 
> 
> 
> 
> On Thu, Nov 23, 2017 at 10:44 PM, Nick Østergaard  wrote:
> 
>> I guess this is the same idea as with https://github.com/KiCad/
>> kicad-python
>>
>> 2017-11-23 19:28 GMT+01:00 Greg Smith :
>>
>>> "I was simply afraid that we
>>> may spent a lot of time petting the SWIG interface, which we will nuke
>>> it and start from scratch because of inevitable switch to Phoenix."
>>>
>>> I agree. I would suggest that the Python API is not quite stable enough
>>> to freeze the API. If we desire a stable interface/API, one could be
>>> written in Python itself. I am on the edge of implementing such an
>>> interface with KiCommand.
>>>
>>> KiCommand, in addition to being a command line interface, is a set of
>>> function calls that *could* be considered an API / Python class when
>>> complete.
>>>
>>> I have reviewed the Python API unit tests and found them to be lacking in
>>> coverage. I am duplicating those tests in KiCommand, and plan to extend the
>>> KiCommand tests, which could potentially be applied to the current Python
>>> API.
>>>
>>> If a stable API is desired, there should also be a set of unit tests
>>> verifying that functionality.
>>>
>>> ___
>>> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] Migrating old designs best practice

[Wayne Stambaugh]

This is *the* fatal flaw with the cache library.  User's assume it is
stale symbols or a temporary copy.  It is not.  It is a snapshot of the
current library symbols linked to the symbols in the schematic.  It gets
refreshed every time the schematic is saved.  Once you delete this file
or keep an out of date copy using cvs, all bets are off.  It is only a
matter of time before one of your symbol libraries changes or gets
removed and you will end up with a broken schematic.  The rescue code
depends on the cache being up to date in order preserve you schematic.
If the cache is not current, the rescuing cannot be guaranteed.

On 11/24/2017 06:38 AM, hauptmech wrote:
> One the one hand, yes, if there is a cache file you can take advantage
> of the fact that it is a stale copy of the old parts.
> 
> On the other hand, since caches are, by definition, temporary copies of
> data, they don't get versioned or archived in my projects. (The kicad
> libraries, and binaries, were though).
> 
> On 24 Nov 2017 10:21 pm, "Nick Østergaard"  > wrote:
> 
> This would haven been resolved if you kept the cache lib, IIRC.
> 
> Den 24. nov. 2017 4.48 AM skrev "hauptmech"  >:
> 
> I can confirm unconnected wires. It may be worth noting that I
> did not preserve the -cache.lib file when I archived the design.
> 
> I also had an issue with an old asymmetric diode footprint
> having its anode and cathode reversed when I used it in a new
> design. If pin numbers in the library got swapped around, then
> now I know why.
> 
> For myself, I would much rather that the old library parts get
> loaded with my old design instead of trying to convert old parts
> to new parts. Is it unreasonable to do that? Load the design
> with the old parts and then do the rescue/migration rename? That
> way the old parts go into the -rescue.lib file unchanged except
> for a name modification. Including the old parts lib (perhaps
> concatenated into one file) does not seem too difficult.
> 
> 
> 
> 
> 
> On 24/11/17 10:09, Wayne Stambaugh wrote:
> 
> I stand corrected.  I just looked and pin numbers are checked by
> position so swapped pins should get rescued.  What isn't
> rescued is pins
> that changed length which is a bit surprising since that
> would possibly
> leave unconnected wires.  I'm not sure why it was done this
> way but I
> guess I'll have to do some testing before the stable 5
> release to see if
> it needs to be fixed.
> 
> On 11/23/2017 11:12 AM, Nick Østergaard wrote:
> 
> Maybe I am mistaken then.
> 
> 2017-11-23 13:21 GMT+01:00 Wayne Stambaugh
> mailto:stambau...@gmail.com>
>  >>:
> 
>      On 11/22/2017 11:02 PM, hauptmech wrote:
>      > When opening an old design I noticed that the C
> and R symbol pin nodes
>      > changed position (I'm guessing other symbols as
> well), breaking the
>      > schematic. Did the people who changed these
> symbols have a plan for
>      > migrating old designs? Is the 'rescue' supposed
> to handle this?
>      >
> 
>      AFAIK, the rescuer does not handle this case.  I'm
> not even sure if it
>      could.  That's something someone would have to take
> a look at.
> 
>      ___
>      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] Getting kicad to work with wxPython Phoenix

[Wayne Stambaugh]

On 11/23/2017 03:44 PM, Carsten Schoenert wrote:
> Am 23.11.2017 um 17:28 schrieb Wayne Stambaugh:
> ...
>>> The short version: Kicad will probably want to wait to move to the
>>> Phoenix version of wxPython.
>>
>> Not until they are package in Debian stable.  This is my litmus test for
>> availability of new dependencies.  I do not want kicad to be in the
>> business of building dependencies.  We have already traveled down that
>> road and it was not a fun journey.
> 
> Right now nobody has intended to do the packaging work for this new
> version / fork.
> If someone wants to step in I'm happily will helping to forward contacts
> to the wxWidget maintainers.
> 
> https://qa.debian.org/developer.php?email=freewx-maint%40lists.alioth.debian.org
> 
> Or at least a packaging request (RFP) should someone file to show up
> there is a interest for getting the package into the archive.
> 

I'm surprised there is no RFP for phoenix yet given that it will (has)
become the replacement for wxpython.  wxpython is a dead code base as
far as I know.  I certainly can create an RFP for phoenix but I am in no
position to actually help with the packaging.

Cheers,

Wayne

___
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] Migrating old designs best practice

[Nick Østergaard]

But still, you are required to save the cache file if you want portability.
The decision to use the word cache was probably not so good, because it
makes people think they should not back it up. But this is how it works, so
pull it out of your ignorefile.

Lets be pleased that the new schematic format will embed the footprints
like we are used to in the kicad_pcb file.

2017-11-24 12:28 GMT+01:00 hauptmech :

> One the one hand, yes, if there is a cache file you can take advantage of
> the fact that it is a stale copy of the old parts.
>
> On the other hand, since caches are, by definition, temporary copies of
> data, they don't get versioned or archived in my projects. (The kicad
> libraries, and binaries, were though).
>
>
>
> On 24 Nov 2017 10:21 pm, "Nick Østergaard"  wrote:
>
> This would haven been resolved if you kept the cache lib, IIRC.
>
> Den 24. nov. 2017 4.48 AM skrev "hauptmech" :
>
>> I can confirm unconnected wires. It may be worth noting that I did not
>> preserve the -cache.lib file when I archived the design.
>>
>> I also had an issue with an old asymmetric diode footprint having its
>> anode and cathode reversed when I used it in a new design. If pin numbers
>> in the library got swapped around, then now I know why.
>>
>> For myself, I would much rather that the old library parts get loaded
>> with my old design instead of trying to convert old parts to new parts. Is
>> it unreasonable to do that? Load the design with the old parts and then do
>> the rescue/migration rename? That way the old parts go into the -rescue.lib
>> file unchanged except for a name modification. Including the old parts lib
>> (perhaps concatenated into one file) does not seem too difficult.
>>
>>
>>
>>
>>
>> On 24/11/17 10:09, Wayne Stambaugh wrote:
>>
>>> I stand corrected.  I just looked and pin numbers are checked by
>>> position so swapped pins should get rescued.  What isn't rescued is pins
>>> that changed length which is a bit surprising since that would possibly
>>> leave unconnected wires.  I'm not sure why it was done this way but I
>>> guess I'll have to do some testing before the stable 5 release to see if
>>> it needs to be fixed.
>>>
>>> On 11/23/2017 11:12 AM, Nick Østergaard wrote:
>>>
 Maybe I am mistaken then.

 2017-11-23 13:21 GMT+01:00 Wayne Stambaugh >>> >:

  On 11/22/2017 11:02 PM, hauptmech wrote:
  > When opening an old design I noticed that the C and R symbol pin
 nodes
  > changed position (I'm guessing other symbols as well), breaking
 the
  > schematic. Did the people who changed these symbols have a plan
 for
  > migrating old designs? Is the 'rescue' supposed to handle this?
  >

  AFAIK, the rescuer does not handle this case.  I'm not even sure
 if it
  could.  That's something someone would have to take a look at.

  ___
  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] Migrating old designs best practice

[hauptmech]

One the one hand, yes, if there is a cache file you can take advantage of
the fact that it is a stale copy of the old parts.

On the other hand, since caches are, by definition, temporary copies of
data, they don't get versioned or archived in my projects. (The kicad
libraries, and binaries, were though).

On 24 Nov 2017 10:21 pm, "Nick Østergaard"  wrote:

> This would haven been resolved if you kept the cache lib, IIRC.
>
> Den 24. nov. 2017 4.48 AM skrev "hauptmech" :
>
>> I can confirm unconnected wires. It may be worth noting that I did not
>> preserve the -cache.lib file when I archived the design.
>>
>> I also had an issue with an old asymmetric diode footprint having its
>> anode and cathode reversed when I used it in a new design. If pin numbers
>> in the library got swapped around, then now I know why.
>>
>> For myself, I would much rather that the old library parts get loaded
>> with my old design instead of trying to convert old parts to new parts. Is
>> it unreasonable to do that? Load the design with the old parts and then do
>> the rescue/migration rename? That way the old parts go into the -rescue.lib
>> file unchanged except for a name modification. Including the old parts lib
>> (perhaps concatenated into one file) does not seem too difficult.
>>
>>
>>
>>
>>
>> On 24/11/17 10:09, Wayne Stambaugh wrote:
>>
>>> I stand corrected.  I just looked and pin numbers are checked by
>>> position so swapped pins should get rescued.  What isn't rescued is pins
>>> that changed length which is a bit surprising since that would possibly
>>> leave unconnected wires.  I'm not sure why it was done this way but I
>>> guess I'll have to do some testing before the stable 5 release to see if
>>> it needs to be fixed.
>>>
>>> On 11/23/2017 11:12 AM, Nick Østergaard wrote:
>>>
 Maybe I am mistaken then.

 2017-11-23 13:21 GMT+01:00 Wayne Stambaugh >>> >:

  On 11/22/2017 11:02 PM, hauptmech wrote:
  > When opening an old design I noticed that the C and R symbol pin
 nodes
  > changed position (I'm guessing other symbols as well), breaking
 the
  > schematic. Did the people who changed these symbols have a plan
 for
  > migrating old designs? Is the 'rescue' supposed to handle this?
  >

  AFAIK, the rescuer does not handle this case.  I'm not even sure
 if it
  could.  That's something someone would have to take a look at.

  ___
  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] Migrating old designs best practice

[hauptmech]

On 24 Nov 2017 10:52 pm, "Rene Pöschl"  wrote:

On 24/11/17 04:47, hauptmech wrote:

> I can confirm unconnected wires. It may be worth noting that I did not
> preserve the -cache.lib file when I archived the design.
>
> I also had an issue with an old asymmetric diode footprint having its
> anode and cathode reversed when I used it in a new design. If pin
> numbers in the library got swapped around, then now I know why.
>
> For myself, I would much rather that the old library parts get loaded
> with my old design instead of trying to convert old parts to new parts.
> Is it unreasonable to do that? Load the design with the old parts and
> then do the rescue/migration rename? That way the old parts go into the
> -rescue.lib file unchanged except for a name modification. Including the
> old parts lib (perhaps concatenated into one file) does not seem too
> difficult.
>

If the symbols are still unchanged in the library then you would not need
the cache lib. (The migration would simply point to the full name of the
symbol including the library name. Unless i understand the process wrong.)

The cache lib is necessary if the symbol in the library does change or is
deleted. If you also delete the cache lib, from where should KiCad get the
information how your old symbol(s) looked like? (The symbol data is not
stored inside the schematic files. It is only stored in the cache lib.)

These are not my symbols, they are kicad library symbols, for which i would
hope for either stability or a migration path.






___
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] support "disable autopan" with gal canvas

[Maciej Sumiński]

Thank you Julius, I have just pushed your patch to the master branch. I
added the 'Fixes:' line to the commit message.

Regards,
Orson

On 11/23/2017 11:07 PM, Julius Schmidt wrote:
> This patch adds support for the "disable autopan" feature to the gal
> canvas.
> 
> I'm not entirely sure this is the best way to do it, there is already an
> "autopan setting" but it is actually used to indicate whether the
> current tool uses autopan.
> 
> fixes https://bugs.launchpad.net/kicad/+bug/1670712
> 
> 
> ___
> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] Migrating old designs best practice

[Rene Pöschl]

On 24/11/17 04:47, hauptmech wrote:

I can confirm unconnected wires. It may be worth noting that I did not
preserve the -cache.lib file when I archived the design.

I also had an issue with an old asymmetric diode footprint having its
anode and cathode reversed when I used it in a new design. If pin
numbers in the library got swapped around, then now I know why.

For myself, I would much rather that the old library parts get loaded
with my old design instead of trying to convert old parts to new parts.
Is it unreasonable to do that? Load the design with the old parts and
then do the rescue/migration rename? That way the old parts go into the
-rescue.lib file unchanged except for a name modification. Including the
old parts lib (perhaps concatenated into one file) does not seem too
difficult.


If the symbols are still unchanged in the library then you would not 
need the cache lib. (The migration would simply point to the full name 
of the symbol including the library name. Unless i understand the 
process wrong.)


The cache lib is necessary if the symbol in the library does change or 
is deleted. If you also delete the cache lib, from where should KiCad 
get the information how your old symbol(s) looked like? (The symbol data 
is not stored inside the schematic files. It is only stored in the cache 
lib.)




___
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] Math expression support for pad editor.

[Maciej Sumiński]

Thank you Michael, I have just updated the files and pushed to my
branch. I am about to test the code on Windows and check for decimal
separator character issues.

Cheers,
Orson

On 11/24/2017 09:04 AM, Michael Geselbracht wrote:
> Hi,
> I have added some comments and examples to the code. The archive also
> contains a simple main() function (in main.cpp) and a Makefile in order to
> test the parser.
> The lemon parser generator is required to be installed and the macro
> "TEST_MODE" in numeric_evaluator.cpp  needs to be set to 1.
> 
> There is also a bugfix in "newString()". Without it an empty input string
> results in an invalid output string.
> 
>  - Michael
> 
> On Thu, Nov 23, 2017 at 11:01 PM, Michael Geselbracht <
> mgeselbrac...@gmail.com> wrote:
> 
>> Hi Russell,
>>
>> the class can handle variables in two ways:
>> NumericEvaluator eval;
>> 1. Assignment within expressions: eval.process("x=1; y=5");
>> 2. Assignment from c++ code: eval.setVar("posx", -3.4);
>>
>> So it would be up to the dialog to add a variable to an eval object
>> within a "focus lost" or "value changed" event.
>> In case of (2) the variable "posx" could be used in following expressions.
>> But this would require a shared eval object for all text boxes. Like one
>> object for each dialog.
>>
>>  - Michael
>>
>>
>> On Thu, Nov 23, 2017 at 9:02 PM, Russell Oliver 
>> wrote:
>>
>>> Hi All,
>>>
>>> Just a query for Michael: can your parser be modified to include
>>> references to dialog variables, ie while writing an expression for y axis
>>> position, using the label posx or something would refer to the value
>>> currently within that text box?
>>>
>>> Kind Regards
>>> Russell
>>>
>>>
>>> On 24 Nov 2017 06:54, "jp charras"  wrote:
>>>
>>> Le 23/11/2017 à 20:45, Michael Geselbracht a écrit :
 Hi,
 I have replaced the useless file info comments by a GPLv3 header  in
>>> order to make my "libeval" code
 license-wise compatible to the Kicad project.

  - Michael


>>>
>>> Thanks Michael,
>>>
>>> Could you add a bit of comments?
>>> Currently God and you know the meaning of the code.
>>> One day, only God will know the meaning of this code.
>>>
>>> Thanks.
>>>
>>>
>>> --
>>> Jean-Pierre CHARRAS
>>>
>>> ___
>>> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] Migrating old designs best practice

[Nick Østergaard]

This would haven been resolved if you kept the cache lib, IIRC.

Den 24. nov. 2017 4.48 AM skrev "hauptmech" :

> I can confirm unconnected wires. It may be worth noting that I did not
> preserve the -cache.lib file when I archived the design.
>
> I also had an issue with an old asymmetric diode footprint having its
> anode and cathode reversed when I used it in a new design. If pin numbers
> in the library got swapped around, then now I know why.
>
> For myself, I would much rather that the old library parts get loaded with
> my old design instead of trying to convert old parts to new parts. Is it
> unreasonable to do that? Load the design with the old parts and then do the
> rescue/migration rename? That way the old parts go into the -rescue.lib
> file unchanged except for a name modification. Including the old parts lib
> (perhaps concatenated into one file) does not seem too difficult.
>
>
>
>
>
> On 24/11/17 10:09, Wayne Stambaugh wrote:
>
>> I stand corrected.  I just looked and pin numbers are checked by
>> position so swapped pins should get rescued.  What isn't rescued is pins
>> that changed length which is a bit surprising since that would possibly
>> leave unconnected wires.  I'm not sure why it was done this way but I
>> guess I'll have to do some testing before the stable 5 release to see if
>> it needs to be fixed.
>>
>> On 11/23/2017 11:12 AM, Nick Østergaard wrote:
>>
>>> Maybe I am mistaken then.
>>>
>>> 2017-11-23 13:21 GMT+01:00 Wayne Stambaugh >> >:
>>>
>>>  On 11/22/2017 11:02 PM, hauptmech wrote:
>>>  > When opening an old design I noticed that the C and R symbol pin
>>> nodes
>>>  > changed position (I'm guessing other symbols as well), breaking
>>> the
>>>  > schematic. Did the people who changed these symbols have a plan
>>> for
>>>  > migrating old designs? Is the 'rescue' supposed to handle this?
>>>  >
>>>
>>>  AFAIK, the rescuer does not handle this case.  I'm not even sure if
>>> it
>>>  could.  That's something someone would have to take a look at.
>>>
>>>  ___
>>>  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] Getting kicad to work with wxPython Phoenix

[miles mccoo]

in reply to Wayne's request to run the footprint wizard

I run the footprint wizard; it seems to run fine.
when I press the 3D view button, I get a popup complaining about not
finding the wx gtk2 library
  "10:14:11: libwx_gtk2u_core-3.0.so.0: cannot open shared object file: No
such file or directory
   10:14:11: libwx_gtk2u_core-3.0.so.0: cannot open shared object file: No
such file or directory"

which is odd because I have the gtk3 version of wx on my system.



In the second half of the video below, I point out that after modifying
module locations in python, the GAL screen doesn't seem to update, even
with the refresh command from the menu.

After I recorded the video, I found that switching to legacy canvas and
then back to GAL, seems to trigger the needed redraw. How to I initiate
this redraw from python? (or even c. I could update the swig stuff to call
it in the refresh method available to python). Previously, I'd just worked
in legacy but that's acting weird for me.

Miles




On Thu, Nov 23, 2017 at 10:44 PM, Nick Østergaard  wrote:

> I guess this is the same idea as with https://github.com/KiCad/
> kicad-python
>
> 2017-11-23 19:28 GMT+01:00 Greg Smith :
>
>> "I was simply afraid that we
>> may spent a lot of time petting the SWIG interface, which we will nuke
>> it and start from scratch because of inevitable switch to Phoenix."
>>
>> I agree. I would suggest that the Python API is not quite stable enough
>> to freeze the API. If we desire a stable interface/API, one could be
>> written in Python itself. I am on the edge of implementing such an
>> interface with KiCommand.
>>
>> KiCommand, in addition to being a command line interface, is a set of
>> function calls that *could* be considered an API / Python class when
>> complete.
>>
>> I have reviewed the Python API unit tests and found them to be lacking in
>> coverage. I am duplicating those tests in KiCommand, and plan to extend the
>> KiCommand tests, which could potentially be applied to the current Python
>> API.
>>
>> If a stable API is desired, there should also be a set of unit tests
>> verifying that functionality.
>>
>> ___
>> 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