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
Oops! Sorry about that.
On 9/28/2015 11:29 AM, jp charras wrote:
> Le 28/09/2015 16:23, Wayne Stambaugh a écrit :
>> Two comments:
>>
>> Do we really need to add the same information that is already displayed
>> in the DRC dialog message panel?
>>
>> If so, please use an HTML_MESSAGE_BOX to displ
Le 28/09/2015 16:23, Wayne Stambaugh a écrit :
> Two comments:
>
> Do we really need to add the same information that is already displayed
> in the DRC dialog message panel?
>
> If so, please use an HTML_MESSAGE_BOX to display the formatted error
> messages rather than stripping out the html form
Two comments:
Do we really need to add the same information that is already displayed
in the DRC dialog message panel?
If so, please use an HTML_MESSAGE_BOX to display the formatted error
messages rather than stripping out the html formatting.
On 9/28/2015 3:05 AM, s...@bredband.net wrote:
> Hi
After the stable release, please send me a patch to fix this. It
doesn't seem to be an issue so I would prefer not to risk pushing the
stable release out any further.
On 9/22/2015 11:55 AM, Simon Richter wrote:
> Hi,
>
> On 19.09.2015 23:05, Wayne Stambaugh wrote:
>
>> No such document but basi
On 9/15/2015 12:19 PM, Dan Walmsley wrote:
> Is this the right place to report problems with footprints.
>
> In "Capacitors_Elko_ThroughHole:Elko_vert_20x10mm_RM5"
>
> There is a + symbol that is in the silkscreen, and also in the copper layer.
This is definitely a bug in the footprint. Please
Message transféré
Sujet : Re: [Kicad-developers] Eeschema ERC should detect unmatched
local labels
Date : Mon, 28 Sep 2015 12:55:59 +0200
De : jp charras
Pour : Joseph Chen
Le 28/09/2015 09:40, Joseph Chen a écrit :
> On 09/25/2015 10:25 AM, jp charras wrote:
>> Le 25/09/201
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
On 09/25/2015 10:25 AM, jp charras wrote:
Le 25/09/2015 07:36, Joseph Chen a écrit :
Hi @JP,
Have you got a chance to review this submitted patch?
--JC
Yes, I had a look at the patch.
Currently, it creates to many false detections:
- It does not see the fact a local label is connected to a g
Hi
This can be confirmed in version (2015-09-28)
The error is due
to a swap of the parameters and wrong usage of wxFileName functions to
wxFileDialog at line 493 in eechema_config.cpp
Here is a patch fixing
the issue
bzr push lp:~stol/kicad/bug1450795 [1]
Using default
stacking branch /+
25 matches
Mail list logo
