Patch committed in product branch r6241. FYI, you editor left behind
some white space that I cleaned up.
Thanks,
Wayne
On 10/2/2015 12:25 PM, Bernhard Stegmaier wrote:
> Hi,
>
> as promised, patch for OS X attached…
>
> Fix scripting paths on OS X. Use
> * /Contents/SharedSupport/scripting/p
Hi,as promised, patch for OS X attached…Fix scripting paths on OS X. Use * /Contents/SharedSupport/scripting/plugins and* $(KICAD_PATH)/scripting/plugins (for compatibility reasons only, this path is added per default in kicadplugin.i for all platforms)to load python scripting plugins from.I check
It looks like the OS X builder will be back up and running, with the new
docs improvements and translation git repo, tonight.
Next is to do some tests with some CMAKE things per Wayne for the slow
drawing, and then I'll start tackling the Python stuff.
(One advantage is that you will have mostly
I committed your patch in r6236 with the revised plugin path. Thanks
for the patch. This should work on both linux and windows. I'm not
sure if it will work with the kicad-winbuilder or the if the windows
installer will need to be changed.
On 10/1/2015 2:43 PM, Brian Sidebotham wrote:
> Shall I
I found a slight problem with it. I changed the install path of the
plugins from ${CMAKE_INSTALL_PATH}/bin/scripting/plugins to
${CMAKE_INSTALL_PREFIX}/share/kicad/scripting/plugins so this:
path_frag = Pgm().GetExecutablePath() + wxT( "../scripting/plugins" );
doesn't work. I'm in the process
Shall I apply the one-liner to get python footprint wizards working on Linux?
On 30 September 2015 at 23:57, Brian Sidebotham
wrote:
> On 30 September 2015 at 21:19, Wayne Stambaugh wrote:
>> I just committed a fix so at least the python plugins will get installed
>> in share/kicad/scripting whi
On 30 September 2015 at 21:19, Wayne Stambaugh wrote:
> I just committed a fix so at least the python plugins will get installed
> in share/kicad/scripting which seems to work properly on msys2/mingw64
> builds. I'll test it on Linux when I get a chance. I'm going to pass
> on the python scripti
I just committed a fix so at least the python plugins will get installed
in share/kicad/scripting which seems to work properly on msys2/mingw64
builds. I'll test it on Linux when I get a chance. I'm going to pass
on the python scripting example folder unless someone can confirm that
all of the ex
Le 30/09/2015 14:30, Wayne Stambaugh a écrit :
> Thanks for the update. I'll leave the python examples uninstalled until
> we can confirm that they are not broken. I don't think it's all that
> important for the stable release. Users can always look at the python
> plugins to get an idea of how
So what exactly are we going to do?
We need to fix up the CMake files and the real search paths. What
should the paths be?
2015-09-30 15:51 GMT+02:00 Wayne Stambaugh :
> The contents of the pcbnew/scritping/plugins folder will be installed
> which contains the scripts you are describing. It cu
The contents of the pcbnew/scritping/plugins folder will be installed
which contains the scripts you are describing. It currently is not
installed on windows or linux. Ironically it is install on osx. I'm
not sure how that happened. The contents of pcbnew/scripting/examples
will not be installe
Hi Wayne,
please reconsider to leave the python wizard installed
The wizard is giving:
BGA, DIP/SIP, QFP, Circular array and BarCode just out of the box.
May be they are improvable (exposed pad, thermal vias etc), but at this
state they are fully usable (without any crash or prob) and much faste
Thanks for the update. I'll leave the python examples uninstalled until
we can confirm that they are not broken. I don't think it's all that
important for the stable release. Users can always look at the python
plugins to get an idea of how the python scripting works.
On 9/30/2015 3:59 AM, Migu
On 9/30/2015 2:50 AM, jp charras wrote:
> Le 30/09/2015 01:25, Wayne Stambaugh a écrit :
>> JP,
>>
>> Your name is on the initial commit for qfn_wizard.py. I don't have time
>> to figure out these patches should be included. Do these patches make
>> sense? Let me know so I can make a decision o
I agree with JP here, QFP and QFN may be separate wizards. If there are common
parts, feel free to use inheritance from a common base to reuse code.
About naming: footprint generators sound better, or whatever, at that time I
was following an industry leader on naming it..., but I agree footpri
Le 30/09/2015 01:25, Wayne Stambaugh a écrit :
> JP,
>
> Your name is on the initial commit for qfn_wizard.py. I don't have time
> to figure out these patches should be included. Do these patches make
> sense? Let me know so I can make a decision on whether or not to commit
> them.
>
> Thanks,
JP,
Your name is on the initial commit for qfn_wizard.py. I don't have time
to figure out these patches should be included. Do these patches make
sense? Let me know so I can make a decision on whether or not to commit
them.
Thanks,
Wayne
On 9/29/2015 3:26 PM, nats wrote:
> Hi,
> I did a code
I did the same solution with thermal pads at the end of August
http://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg15033.html
but the problem with thermal pads is that python APIs do not let you
have pads without Front Silk and Front and Bottom Solder Mask
that is not acceptable
Hi,
I did a code for QFN handling via/thermal pad/solderpaste.
I think inductiveload (on IRC) merged it cleanly with the QFP generator.
I post it here, maybe there are some interesting part in it.
https://github.com/natsfr/kicad-components/blob/master/python_plugins/qfn_wizard.py
Le 29/09/2015 1
> On 29 Sep 2015, at 10:49, Brian Sidebotham wrote:
>
> See the comments about stdout not being open for python:
> https://github.com/KiCad/kicad-source-mirror/blob/master/scripting/kicadplugins.i#L43
>
> Just open a new file to direct stdout to temporarily while you're
> debugging/testing:
> h
In response to a message written on 29.09.2015, 17:17, from Nick Østergaard:
Not nessesarely, what is in bin is supposed to be executed. I am sure you cam
find both python, bash, and perl scripts in bin on your system.
If consistently stick to that comparison, I also have not „scripting” subfolde
Thanks!
On Tue, Sep 29, 2015 at 10:59 AM, Bernhard Stegmaier <
stegma...@sw-systems.de> wrote:
> Thanks a lot, found it now!
> And I don’t believe it… it even seems to work without any problems (well,
> just created the default QFP and changed pads from oval to rectangular…).
>
> I’ll post a patc
Hi,
there is also a patch for wizard plugins to make the QFN/QFP with
exposed pad and paste pads...
http://www.mail-archive.com/kicad-developers%40lists.launchpad.net/msg15109.html
at the moment has not been committed...
On 29/09/2015 17.59, Bernhard Stegmaier wrote:
Thanks a lot, found it n
Thanks a lot, found it now!
And I don’t believe it… it even seems to work without any problems (well, just
created the default QFP and changed pads from oval to rectangular…).
I’ll post a patch for OS X in the next couple of days to make paths
consistently pointing to *only* the one “scripting/p
It is not well documented, I guess partly becaue the plugins was never
found on a default installation.
But see http://docs.kicad-pcb.org/en/images/Modedit_top_toolbar.png
this is in the footprint editor.
It is the 7th icon from the left. The chip package with a small paper
on it. Although the ic
Den 29/09/2015 16.02 skrev "LordBlick" :
>
> In response to a message written on 29.09.2015, 15:19, from Brian
Sidebotham:
>>
>> These are simply files installed that the PCBNEW makes use of[…]
>
> In the future, scripts can be used not only for pcbnew.I think the
logical order
> for expanding the
In response to a message written on 29.09.2015, 15:19, from Brian Sidebotham:
These are simply files installed that the PCBNEW makes use of[…]
In the future, scripts can be used not only for pcbnew.I think the logical order
for expanding the project should be implemented and maintained as early
On 29 September 2015 at 14:03, LordBlick wrote:
> In response to a message written on 29.09.2015, 10:46, from Brian
> Sidebotham:
>>
>> For Windows, we can package the contents of
>> kicad-source/pcbnew/scripting/plugins into the bin/scripting/plugins
>> directory and it'll work for 4.0.0 as-is.
>
In response to a message written on 29.09.2015, 10:46, from Brian Sidebotham:
For Windows, we can package the contents of
kicad-source/pcbnew/scripting/plugins into the bin/scripting/plugins
directory and it'll work for 4.0.0 as-is.
It's a complete mess, or something is binary or a script.
--
Be
On 28 September 2015 at 22:10, Bernhard Stegmaier
wrote:
> And maybe a dumb question, but… how do I get some debugging output from
> kicadplugins.i?
> Will a simple Python print() show something? Where?
>
> Regards,
> Bernhard
See the comments about stdout not being open for python:
https://gith
On 28 September 2015 at 11:36, Miguel Angel Ajo wrote:
> Hmm, that's a good point, I guess we should install them to
>
> $KICAD_PATH/scripting/plugins
>
> as it's the standard place where kicad will try to load them from [1]
>
> [1]
> https://github.com/KiCad/kicad-source-mirror/blob/master/script
In response to a message written on 28.09.2015, 22:37, from Wayne Stambaugh:
On 9/28/2015 2:56 PM, LordBlick wrote:
In response to a message written on 28.09.2015, 20:31, from Wayne
Stambaugh:
Maybe we should put the python scripts in share/kicad/scripting/python
+1
${KICAD_PATH}/scripting/pl
And maybe a dumb question, but… how do I get some debugging output from
kicadplugins.i?
Will a simple Python print() show something? Where?
Regards,
Bernhard
> On 28 Sep 2015, at 23:01, Bernhard Stegmaier wrote:
>
> OK.
> I’ll play around a bit with it on the weekend.
> If it is really only ab
OK.
I’ll play around a bit with it on the weekend.
If it is really only about adding the system (== application bundle) path to
kicadplugins.i, it could be quite easy.
The path itself is just a matter of definition… but for the sake of
consistency, it IMHO should use a pattern similar to the oth
I'm not sure about the appropriate path on osx. Even on osx, the python
scripts only get installed when the python scripting build is enabled so
Adam must be building the python scripting on osx.
Looking at kicadplugins.i, it definitely will not find the system
install path for the plugin python
> On 28 Sep 2015, at 22:37, Wayne Stambaugh wrote:
>
> On 9/28/2015 2:56 PM, LordBlick wrote:
>> In response to a message written on 28.09.2015, 20:31, from Wayne
>> Stambaugh:
>>> Maybe we should put the python scripts in share/kicad/scripting/python
>> +1
>> ${KICAD_PATH}/scripting/plugins
On 9/28/2015 2:56 PM, LordBlick wrote:
> In response to a message written on 28.09.2015, 20:31, from Wayne
> Stambaugh:
>> Maybe we should put the python scripts in share/kicad/scripting/python
> +1
> ${KICAD_PATH}/scripting/plugins
> ${HOME}/.kicad_plugins
> ${HOME}/.kicad/scripting/pl
Where should I find it?
I thought I read somewhen it should be somewhere under Tools->…?
I just checked Adams last build and I only see "Tools->Scripting Console”,
nothing else.
The python files seem to be contained in the application bundle, although at a
place that doesn’t seem to match anythi
You should still be able build the Python scripting on OSX. Don't
enable KICAD_SCRIPTING_WXPYTHON.
On 9/28/2015 4:02 PM, Nick Østergaard wrote:
> The python based footprint wizards does not use the python console...
>
> 2015-09-28 21:50 GMT+02:00 Bernhard Stegmaier :
>> Hi,
>>
>> I guess the pat
The python based footprint wizards does not use the python console...
2015-09-28 21:50 GMT+02:00 Bernhard Stegmaier :
> Hi,
>
> I guess the paths defined in this kicadplugins.i are also pretty useless for
> OS X:
> * This will never reach the Bundle>/Contents/SharedSupport/plugins/ folder where
Hi,
I guess the paths defined in this kicadplugins.i are also pretty useless for OS
X:
* This will never reach the /Contents/SharedSupport/plugins/
folder where the shipped plugins will probably go into
* It should add probably some $HOME/Library/Application Support/kicad/plugins
folder for use
In response to a message written on 28.09.2015, 20:31, from Wayne Stambaugh:
Maybe we should put the python scripts in share/kicad/scripting/python
+1
${KICAD_PATH}/scripting/plugins
${HOME}/.kicad_plugins
${HOME}/.kicad/scripting/plugins
Also with minimum, add ${HOME}/.local/share/kicad/scrip
I'm OK with installing the xsl files in share/kicad/xsl but it will
break existing custom BOM configurations so I'm sure there will be some
user grumbling.
Maybe we should put the python scripts in share/kicad/scripting/python
in case we add other scripting languages in the future. From what I
un
Yes, and this is exactly why I ask these questions.
I personally don't think that scripting examples needs to be
installed. But of course we can do that.
But I still think we should make the xsl "plugins" not just a plugins
folder. I propose to install the python wizards
share/kicad/plugins/scrip
I just discovered the python plugins are not installed on any platform
but apple. It appears that the cmake install directive for the python
plugin files got moved inside the conditional apple configure code. I
will fix this but it still doesn't solve the path problem. Using
${KICAD_PATH}/script
From the kicadplugins.i file tha Ajo linked it is in theese dirs on linux:
${KICAD_PATH}/scripting/plugins
${HOME}/.kicad_plugins
${HOME}/.kicad/scripting/plugins
KICAD_PATH is not internally defined in kicad, it seems.
In principle it is installed in something called KICAD_DATA on cmake,
which
There is no $KICAD_PATH in the cmake configuration files. There is
CMAKE_INSTALL_PREFIX that defaults to the appropriate platform path for
using `make install`. This can be changed when configuring cmake if
your not happy with the default. Relative to CMAKE_INSTALL_PATH, what
is the sub-director
Hmm, that's a good point, I guess we should install them to
$KICAD_PATH/scripting/plugins
as it's the standard place where kicad will try to load them from [1]
[1]
https://github.com/KiCad/kicad-source-mirror/blob/master/scripting/kicadplugins.i#L85
Nick Østergaard wrote:
Hi
What is the pl
In response to a message written on 27.09.2015, 12:31, from Nick Østergaard:
What is the plan for the python footprint wizrards [1]?
I was trying to figure out how they were supposed to be installed, as
it looks now, it seems that they are not installed by cmake [3]. I see
that the eeschema bom
Hi
What is the plan for the python footprint wizrards [1]?
I was trying to figure out how they were supposed to be installed, as
it looks now, it seems that they are not installed by cmake [3]. I see
that the eeschema bom pluings (the xsl files [2]) are intalled with
cmake, but that [1] is not, a
50 matches
Mail list logo
