[Kicad-developers] STEP Export

[Cirilo Bernardo]

The kicad-step feature branch now implements a STEP Export. The menu
item may need a new icon (I lazily reused the IDF icon). Any testing and
comments would be appreciated. The kicad2step utility which performs
the conversion is of course dependent on OCE and is only built when
KICAD_USE_OCE is defined. The "Export STEP" menu item is disabled
if the kicad2step executable is not found in the same directory as the
pcbnew executable.

https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce/+ref/kicad-step

- Cirilo
___
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] STEP Export

[Nick Østergaard]

Looks good, I will test it soon. But I noticed that it looks like you did
not use the copyright template copyright.h from the root of the source.

Den 19/09/2016 09.46 skrev "Cirilo Bernardo" :

> The kicad-step feature branch now implements a STEP Export. The menu
> item may need a new icon (I lazily reused the IDF icon). Any testing and
> comments would be appreciated. The kicad2step utility which performs
> the conversion is of course dependent on OCE and is only built when
> KICAD_USE_OCE is defined. The "Export STEP" menu item is disabled
> if the kicad2step executable is not found in the same directory as the
> pcbnew executable.
>
> https://code.launchpad.net/~cirilo-bernardo/kicad/+git/
> kicad-oce/+ref/kicad-step
>
> - Cirilo
>
>
> ___
> 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] Menu text consistency

[Fabrizio Tappero]

Hello guys,
would in be possible to know the status of this patch?

Regards
Fabrizio


On Mon, Jul 4, 2016 at 11:26 AM, Fabrizio Tappero
 wrote:
> Hi Simon,
> hum... I see. If we look at very cool tools like inkscape, they do
> have these types of icons (toggle icons) and the tooltip does still
> contain the verb Set.
>
> just my 2c
>
> cheers
> Fabrizio
>
>
> On Mon, Jul 4, 2016 at 10:55 AM, Simon Wells  wrote:
>> The problem with changing the units icon tooltips is they actually are
>> not only Set Units to blah they are also showing which one is selected
>> by which one is active
>>
>> On Mon, Jul 4, 2016 at 8:22 PM, Fabrizio Tappero
>>  wrote:
>>> Hello,
>>> the Part Library Editor top File Menu is
>>>
>>> File - Current Library
>>>
>>> Generally speaking I think it is missing the action verb and I would
>>> propose to change this entry in
>>>
>>> File - Set Current Library
>>>
>>> Following the same idea I would like to propose to change the
>>> following icon tool tips
>>>
>>> Units in inches => Set unit to in
>>> Units in millimeters => Set unit to mm
>>>
>>> The patch in attachment does that. It would be great if a native
>>> English speaking person could review and submit this patch.
>>>
>>> Regards
>>> Fabrizio
>>>
>>> ___
>>> 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][RFC] Footprint wizards

[Nick Østergaard]

I just tried to test this on windows, but with your patch applied it
does not seem to find the wizards...


I have them in %PROGRAMFILES%\KiCad\share\kicad\scripting\plugins

And run pcbnew directly from the bin dir. KiCad can find the wizards
just fine before your patch.

2016-09-18 16:26 GMT+02:00 Nick Østergaard :
> Hi Oliver
>
> The new checkbox works better i think. But thre is still some jumping
> around with it when it sort of "selected" by the cursor. Also it shows
> that small dashed box where there is usallly text for a checkbox it
> seems.
>
> This is on linux, I don't know if the same is seen on other platforms.
>
> 2016-09-15 14:55 GMT+02:00 Oliver Walters :
>> Ok, round two!
>>
>> 1. I have fixed the issue relating to comma-separated decimals.
>>
>> 2. Boolean values now use the wxGridCellBoolRenderer which means they always
>> display as checkboxes
>>
>> Here is an example of the boolean values rendering ->
>> http://oi65.tinypic.com/24pmp9d.jpg
>>
>> And an example of the multiple-choice parameter ->
>> http://oi67.tinypic.com/xkrvw5.jpg
>>
>> Finally, a screenshot of available parameter types ->
>> http://oi63.tinypic.com/2lne6gh.jpg
>>
>> I have attached the updated patch.
>>
>> LMK if there's anything else I need to do :)
>>
>> On Wed, Sep 14, 2016 at 10:09 PM, Oliver Walters
>>  wrote:
>>>
>>> Hi all,
>>>
>>> First time submitting a patch, so here goes
>>>
>>
>>
>>
>> ___
>> 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] SWIG binding

[Torsten Hüter]

Hi Tom & Michael,

 

I'm using the scripting interface quite often and had never that much trouble with it.
The currently missing std::unique_ptr is not an argument, it is still possible to use it, see
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig

 

I'm quite sure that in the future almost any C++ 11 features will be supported by swig.
Pybind is - as you have written - generatorless, in my opinion this is exactly the downside.

You have to write wrappers yourself, while with swig you're simply including headers in the *.i files.

 

--

 

About the pythonish API:

Although this sounds good, I'm sceptical - simply because the very limited ressources of the KiCad developers,
something like this has to be regularly maintained. This means documentation too, both C++ and Python.

 

As Miguel has written, there is already some work by Piers Titus van der Torren, see
https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py

 

I've not used that, because I've found it easy enough to work with the swigged functions.
Even when internals are refactored, in most cases I've found it easy to adapt my scripts, this is only an issue between

the releases - even with an abstraction layer you don't know if something has to be changed.

 

Python helper functions would be nice, but I'd still like to have full access to as much as possible PCBNEW methods.

 

--

 

In my opinion the work should be invested elsewhere - for instance a launcher for python scripts is missing.
Sure there is a console, but ideally I'd like to press a button, a keystroke or similar to launch my script.

Also several functions are not yet wrapped, like the P&S router or the tool framework (working with selections etc.).

 

Thanks,
Torsten


 



> when activating python bindings on my msvc build with a few refactor
> commits applied, it came to my attention that SWIG simply does not
> support std::unique_ptr.
>
> With this message I want to ask what is the common view whether it is
> okay to have SWIG thumbscrew the project's source code, considering
> there are alternative generators, and generatorless libraries like
> pybind11. Of those alternatives I would *personally* prefer the latter,
> as it is no black box and the binding generation is part of the normal
> c++ source code.
> There's been a discussion on the irc channel regardings this and also
> the dependency on having wx exported as well. So I thought the logical
> consequence would be to broaden the audience and move the discussion here.

Hi Michael,

It may sound controversial, but I'd say using SWIG is a bad idea: we
expose for the people the internal APIs of pcbnew that we intend to
refactor in the near future. Any change to the BOARD storage model means
a change to the scripting API. IMHO we should have a more pythonish API
that hides all C++ stuff from the python side completely and is
independent from the changes in pcbnew's core.

Cheers,
Tom
 




___
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] Remove assert in pcbnew on osx with a debug build

[Maciej Sumiński]

Hi Simon,

Can you give more details about the assert? Perhaps it is a different
problem and should be solved in another way.

wxWidgets documentation[1] says it is necessary to create a wxPaintDC
object, even if it is not used. IIRC GAL worked on every platform even
when it has not created wxPaintDC object, but if the documentation says
it should be there, I would rather follow the advice.

Regards,
Orson

1. http://docs.wxwidgets.org/stable/classwx_paint_d_c.html

On 09/18/2016 06:32 AM, Simon Wells wrote:
> ---
>  common/draw_panel_gal.cpp | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/common/draw_panel_gal.cpp b/common/draw_panel_gal.cpp
> index fd48d83..2616490 100644
> --- a/common/draw_panel_gal.cpp
> +++ b/common/draw_panel_gal.cpp
> @@ -156,7 +156,9 @@ void EDA_DRAW_PANEL_GAL::SetFocus()
>  void EDA_DRAW_PANEL_GAL::onPaint( wxPaintEvent& WXUNUSED( aEvent ) )
>  {
>  // This is required even though dc is not used otherwise.
> +#ifndef __WXMAC__
>  wxPaintDC dc(this);
> +#endif
>  
>  m_pendingRefresh = false;
>  
> 




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

[Kicad-developers] Gerber Plot last options.[INFO]

[jp charras]

Hi All,

I just pushed in 2016-09-19 revision 6edee2a an option in Plot Gerber dialog to 
include advanced
aperture and net attributes.
This option is not yet activated by default, because net attributes are not yet 
fully fixed by
Ucamco, in Gerber file format specifications.
To activate it, see dialog_plot.cpp, line 43, and uncomment line 44.

When activated, you can see a new option in Gerber plot dialog to include 
advanced X2 netlist
attributes.

If activated, the Gerber files contains some metadata, related to netlist info 
and aperture attributes.
When available, Gerbview can highlight a full net or a full set of items 
related to a gived
footprint or a given aperture attribute.
(Use right click on a Gerber item (line or flashed item) to access the context 
menu)

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

Re: [Kicad-developers] [PATCH] Remove assert in pcbnew on osx with a debug build

[jp charras]

Le 19/09/2016 à 13:53, Maciej Sumiński a écrit :
> Hi Simon,
> 
> Can you give more details about the assert? Perhaps it is a different
> problem and should be solved in another way.
> 
> wxWidgets documentation[1] says it is necessary to create a wxPaintDC
> object, even if it is not used. IIRC GAL worked on every platform even
> when it has not created wxPaintDC object, but if the documentation says
> it should be there, I would rather follow the advice.
> 
> Regards,
> Orson
> 

It is true, but it could be a old info in wxWidgets, not yet updated, and not 
true in a wxGLCanvas
wxPaintEvent.

Just for info, I also saw this assert during tests on Ubuntu, with wxWidgets 
compiled with GTK3
(working only in GAL mode, because the "legacy" canvas does not work with GTK3).


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

Re: [Kicad-developers] [PATCH] Remove assert in pcbnew on osx with a debug build

[Maciej Sumiński]

Ok, I see. I have just removed the wxPaintDC object for all platforms,
as anyway GAL worked fine without it. If there are any drawing related
problems, let me know and we will look for another solution.

Regards,
Orson

On 09/19/2016 02:25 PM, Simon Wells wrote:
> Hi Orson,
> 
> i get one of the attached on GAL load (i hit cancel to supress further
> dialogs) and one
> 
> ../src/src/osx/carbon/dcclient.cpp(195): assert
> "window->MacGetCGContextRef() != NULL" failed in wxPaintDCImpl():
> using wxPaintDC without being in a native paint event
> 
> on console on every redraw (even just moving the mouse around)
> 
> although these are only visible in debug mode they drive me nuts when
> doing a lot of restarts to debug something
> 
> thanks
> 
> Simon
> 
> 
> 
> On Mon, Sep 19, 2016 at 11:53 PM, Maciej Sumiński
>  wrote:
>> Hi Simon,
>>
>> Can you give more details about the assert? Perhaps it is a different
>> problem and should be solved in another way.
>>
>> wxWidgets documentation[1] says it is necessary to create a wxPaintDC
>> object, even if it is not used. IIRC GAL worked on every platform even
>> when it has not created wxPaintDC object, but if the documentation says
>> it should be there, I would rather follow the advice.
>>
>> Regards,
>> Orson
>>
>> 1. http://docs.wxwidgets.org/stable/classwx_paint_d_c.html
>>
>> On 09/18/2016 06:32 AM, Simon Wells wrote:
>>> ---
>>>  common/draw_panel_gal.cpp | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/common/draw_panel_gal.cpp b/common/draw_panel_gal.cpp
>>> index fd48d83..2616490 100644
>>> --- a/common/draw_panel_gal.cpp
>>> +++ b/common/draw_panel_gal.cpp
>>> @@ -156,7 +156,9 @@ void EDA_DRAW_PANEL_GAL::SetFocus()
>>>  void EDA_DRAW_PANEL_GAL::onPaint( wxPaintEvent& WXUNUSED( aEvent ) )
>>>  {
>>>  // This is required even though dc is not used otherwise.
>>> +#ifndef __WXMAC__
>>>  wxPaintDC dc(this);
>>> +#endif
>>>
>>>  m_pendingRefresh = false;
>>>
>>>
>>
>>




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] SWIG binding

[Wayne Stambaugh]

I'm going to make an executive decision here so this doesn't drag on.
In short, swig stays.  Any other python bindings would either be on top
of or along side current swig bindings.  Swig is a valid tool for
generating scripting language bindings.  Lots of other projects use it
with great success so it can't be all bad.  We already have a large
investment of time in the current swig bindings along with lots of
project and user scripts that use them.  I do not want to discard that
investment of time and effort.  If anyone feels so inclined to write
some other python interface, there cannot be namespace clashes with the
current python bindings.

On 9/19/2016 5:49 AM, "Torsten Hüter" wrote:
> Hi Tom & Michael,
>  
> I'm using the scripting interface quite often and had never that much
> trouble with it.
> The currently missing std::unique_ptr is not an argument, it is still
> possible to use it, see
> http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
>  
> I'm quite sure that in the future almost any C++ 11 features will be
> supported by swig.
> Pybind is - as you have written - generatorless, in my opinion this is
> exactly the downside.
> You have to write wrappers yourself, while with swig you're simply
> including headers in the *.i files.
>  
> --
>  
> About the pythonish API:
> Although this sounds good, I'm sceptical - simply because the very
> limited ressources of the KiCad developers,
> something like this has to be regularly maintained. This means
> documentation too, both C++ and Python.
>  
> As Miguel has written, there is already some work by Piers Titus van der
> Torren, see
> https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py
>  
> I've not used that, because I've found it easy enough to work with the
> swigged functions.
> Even when internals are refactored, in most cases I've found it easy to
> adapt my scripts, this is only an issue between
> the releases - even with an abstraction layer you don't know if
> something has to be changed.
>  
> Python helper functions would be nice, but I'd still like to have full
> access to as much as possible PCBNEW methods.
>  
> --
>  
> In my opinion the work should be invested elsewhere - for instance a
> launcher for python scripts is missing.
> Sure there is a console, but ideally I'd like to press a button, a
> keystroke or similar to launch my script.
> Also several functions are not yet wrapped, like the P&S router or the
> tool framework (working with selections etc.).
>  
> Thanks,
> Torsten
>  
>> when activating python bindings on my msvc build with a few refactor
>> commits applied, it came to my attention that SWIG simply does not
>> support std::unique_ptr.
>>
>> With this message I want to ask what is the common view whether it is
>> okay to have SWIG thumbscrew the project's source code, considering
>> there are alternative generators, and generatorless libraries like
>> pybind11. Of those alternatives I would *personally* prefer the latter,
>> as it is no black box and the binding generation is part of the normal
>> c++ source code.
>> There's been a discussion on the irc channel regardings this and also
>> the dependency on having wx exported as well. So I thought the logical
>> consequence would be to broaden the audience and move the discussion here.
> 
> Hi Michael,
> 
> It may sound controversial, but I'd say using SWIG is a bad idea: we
> expose for the people the internal APIs of pcbnew that we intend to
> refactor in the near future. Any change to the BOARD storage model means
> a change to the scripting API. IMHO we should have a more pythonish API
> that hides all C++ stuff from the python side completely and is
> independent from the changes in pcbnew's core.
> 
> Cheers,
> Tom
>  
> 
> 
> ___
> 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] msys2 ngspice-git package.

[Wayne Stambaugh]

On 9/19/2016 1:04 AM, Nick Østergaard wrote:
> Spiced windows builds are not yet performed, mostly because I saw those
> issies with it and it seemed like someone were trying to make a ngspice
> pkgbuild.

Orson made the original ngspice pkgbuild for the latest stable release
of ngspice but the issue was found after the fact.  I just hacked up a
version of it to clone from the ngspice git repo.

> 
> But now, I guess we can start to enable it.

Thanks Nick.  It would be nice to get as much testing on this as
possible before the next stable release.  Windows users represent a
large portion of our user base so that's a lot of extra testers.

> 
> 
> Den 19/09/2016 02.23 skrev "Wayne Stambaugh"  >:
> 
> I just submitted a pull request[1] for a new ngspice-git package for the
> msys2 project so you can build the latest version of ngspice from the
> head of the project git repo.  This will allow you to build a version of
> ngspice that resolves the know simulation issues in the current stable
> release of ngspice.  I also grab the latest documentation in pdf format
> from the ngspice website since AFAIK you cannot build the latex
> documentation from source on msys2.  If you can't wait for the msys2
> project to accept the pull request, you can grab the PKGBUILD file from
> the ngspice-git-package branch of my fork [2] of the mingw packages.
> Are we enabling spice on windows nightly builds yet?  I haven't had time
> to look.  If not, this should make life easier.
> 
> [1]: https://github.com/Alexpux/MINGW-packages/pull/1720
> 
> [2]:
> https://github.com/stambaughw/MINGW-packages/tree/ngspice-git-package 
> 
> 
> ___
> 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] SWIG binding

[Michael Steinberg]

Hello Wayne, Torsten & All,


Am 19.09.2016 um 15:17 schrieb Wayne Stambaugh:

I'm going to make an executive decision here so this doesn't drag on.
In short, swig stays.  Any other python bindings would either be on top
of or along side current swig bindings.  Swig is a valid tool for
generating scripting language bindings.  Lots of other projects use it
with great success so it can't be all bad.  We already have a large
investment of time in the current swig bindings along with lots of
project and user scripts that use them.  I do not want to discard that
investment of time and effort.  If anyone feels so inclined to write
some other python interface, there cannot be namespace clashes with the
current python bindings.

On 9/19/2016 5:49 AM, "Torsten Hüter" wrote:

Hi Tom & Michael,
  
I'm using the scripting interface quite often and had never that much

trouble with it.
The currently missing std::unique_ptr is not an argument, it is still
possible to use it, see
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
  
I'm quite sure that in the future almost any C++ 11 features will be

supported by swig.
Pybind is - as you have written - generatorless, in my opinion this is
exactly the downside.
You have to write wrappers yourself, while with swig you're simply
including headers in the *.i files.
  


I'm fine with staying with SWIG (See I also added it in the points of 
possible options twice). But still I'm left with contradicting 
statements about the stability of the blobs the current SWIG headers 
spit out. While Wayne's main point is that we cannot break existing 
scripts, Thorsten says that is no problem at all. If refactoring and 
exporting it like usual is no problem, then I have nothing left to 
argument about, because the initial problem I was addressing was 
non-existant to begin with (I'd like that, because it means no work!). 
If that is not the case, just saying SWIG stays is fixing the 
technicality, but not the specified API concerns imho.


Michael

___
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] SWIG binding

[Wayne Stambaugh]

On 9/19/2016 9:52 AM, Michael Steinberg wrote:
> Hello Wayne, Torsten & All,
> 
> 
> Am 19.09.2016 um 15:17 schrieb Wayne Stambaugh:
>> I'm going to make an executive decision here so this doesn't drag on.
>> In short, swig stays.  Any other python bindings would either be on top
>> of or along side current swig bindings.  Swig is a valid tool for
>> generating scripting language bindings.  Lots of other projects use it
>> with great success so it can't be all bad.  We already have a large
>> investment of time in the current swig bindings along with lots of
>> project and user scripts that use them.  I do not want to discard that
>> investment of time and effort.  If anyone feels so inclined to write
>> some other python interface, there cannot be namespace clashes with the
>> current python bindings.
>>
>> On 9/19/2016 5:49 AM, "Torsten Hüter" wrote:
>>> Hi Tom & Michael,
>>>   I'm using the scripting interface quite often and had never that much
>>> trouble with it.
>>> The currently missing std::unique_ptr is not an argument, it is still
>>> possible to use it, see
>>> http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
>>>
>>>   I'm quite sure that in the future almost any C++ 11 features will be
>>> supported by swig.
>>> Pybind is - as you have written - generatorless, in my opinion this is
>>> exactly the downside.
>>> You have to write wrappers yourself, while with swig you're simply
>>> including headers in the *.i files.
>>>   
> 
> I'm fine with staying with SWIG (See I also added it in the points of
> possible options twice). But still I'm left with contradicting
> statements about the stability of the blobs the current SWIG headers
> spit out. While Wayne's main point is that we cannot break existing
> scripts, Thorsten says that is no problem at all. If refactoring and
> exporting it like usual is no problem, then I have nothing left to
> argument about, because the initial problem I was addressing was
> non-existant to begin with (I'd like that, because it means no work!).
> If that is not the case, just saying SWIG stays is fixing the
> technicality, but not the specified API concerns imho.
> 
> Michael
> 

I'm not suggesting that we will always have absolute api stability.  I'm
not sure that is even realistic.  I can't think of a project of any
significance that's been around for any length of time who's api didn't
break something at some point.  Yes, event the C language had it's
moments way back when.  There may be occasions when we have to break
existing behavior.  However, most of the low level objects in pcbnew
have not changed significantly over the last few years.  We've added new
functions to the api but we haven't made major changes to the existing
api.  I don't remember anyone ever complaining about this but I may have
missed it.

___
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] Menu text consistency

[Wayne Stambaugh]

Typically the English would be "Set units to inches".  Other than that,
I don't have any issues with this patch.  It would be nice if you could
use git format-patch to create a new patch since we are now using git.

On 9/19/2016 4:22 AM, Fabrizio Tappero wrote:
> Hello guys,
> would in be possible to know the status of this patch?
> 
> Regards
> Fabrizio
> 
> 
> On Mon, Jul 4, 2016 at 11:26 AM, Fabrizio Tappero
>  wrote:
>> Hi Simon,
>> hum... I see. If we look at very cool tools like inkscape, they do
>> have these types of icons (toggle icons) and the tooltip does still
>> contain the verb Set.
>>
>> just my 2c
>>
>> cheers
>> Fabrizio
>>
>>
>> On Mon, Jul 4, 2016 at 10:55 AM, Simon Wells  wrote:
>>> The problem with changing the units icon tooltips is they actually are
>>> not only Set Units to blah they are also showing which one is selected
>>> by which one is active
>>>
>>> On Mon, Jul 4, 2016 at 8:22 PM, Fabrizio Tappero
>>>  wrote:
 Hello,
 the Part Library Editor top File Menu is

 File - Current Library

 Generally speaking I think it is missing the action verb and I would
 propose to change this entry in

 File - Set Current Library

 Following the same idea I would like to propose to change the
 following icon tool tips

 Units in inches => Set unit to in
 Units in millimeters => Set unit to mm

 The patch in attachment does that. It would be great if a native
 English speaking person could review and submit this patch.

 Regards
 Fabrizio

 ___
 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

[Kicad-developers] RFC: coroutine/context causing issues

[Simon Wells]

As was bought up in irc today coroutine/context is causing issue(s) on
osx relating to the add text to pcb as seen in
https://bugs.launchpad.net/kicad/+bug/1547282

After spending way too long over the weekend debugging this issue it
seems that JSC which is apparently related to webkit is trying to do
garbage collection, and to do that it needs to walk the stack.

this causes issues with the coroutines/contexts and the stacks it creates.

in this case the following options are possible

1) get JSC to be smarter (see
https://bugs.webkit.org/show_bug.cgi?id=65399 ) which pretty much
kills that option

2) create yet another patch for wxwidgets that on osx at least makes
wxTE_RICH or wxTE_RICH2 flags instead of assuming wxTE_MULTILINE is
rich see: http://docs.wxwidgets.org/trunk/classwx_text_ctrl.html )
as this would be a breaking change i am not sure it would make it into
any wxwidgets 3 version, and ideally it would be nice if most if not
all of the current wx patches were unnecessary for 3.2

3) context changes, as suggested by decimad (don't have his real name
in front of me) to have that modal dialog run off the main context

4) as commented on very briefly by wayne replace boost::context with events

I have pushed this to the list so there is a long-term record.

___
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] msys2 ngspice-git package.

[Wayne Stambaugh]

The msys2 project rejected my ngspice-git package build pull request
[1].  Apparently they don't want another git flavor of an existing
package and would prefer that the existing ngspice package be patched.
I honestly don't blame them.  Since I'm not sure which patch fixes
ngspice and I've spent way more time on this than I wanted to, I'm
deferring this issue to Orson since he made the decision to make ngspice
a build dependency.  I'll leave my ngspice-git-package branch on my
github clone of the mingw packages[2] for devs to experiment with the
latest ngspice code if they feel the need.  Given that this seems to be
an ongoing issue, I may create a new policy that if you add a new build
dependency you cannot commit it to the product repo until it works
across all platform without having to build from source.  Choose your
dependencies wisely.

[1]:
https://github.com/Alexpux/MINGW-packages/pull/1720#issuecomment-248019326
[2]: https://github.com/stambaughw/MINGW-packages/tree/ngspice-git-package

On 9/19/2016 9:22 AM, Wayne Stambaugh wrote:
> On 9/19/2016 1:04 AM, Nick Østergaard wrote:
>> Spiced windows builds are not yet performed, mostly because I saw those
>> issies with it and it seemed like someone were trying to make a ngspice
>> pkgbuild.
> 
> Orson made the original ngspice pkgbuild for the latest stable release
> of ngspice but the issue was found after the fact.  I just hacked up a
> version of it to clone from the ngspice git repo.
> 
>>
>> But now, I guess we can start to enable it.
> 
> Thanks Nick.  It would be nice to get as much testing on this as
> possible before the next stable release.  Windows users represent a
> large portion of our user base so that's a lot of extra testers.
> 
>>
>>
>> Den 19/09/2016 02.23 skrev "Wayne Stambaugh" > >:
>>
>> I just submitted a pull request[1] for a new ngspice-git package for the
>> msys2 project so you can build the latest version of ngspice from the
>> head of the project git repo.  This will allow you to build a version of
>> ngspice that resolves the know simulation issues in the current stable
>> release of ngspice.  I also grab the latest documentation in pdf format
>> from the ngspice website since AFAIK you cannot build the latex
>> documentation from source on msys2.  If you can't wait for the msys2
>> project to accept the pull request, you can grab the PKGBUILD file from
>> the ngspice-git-package branch of my fork [2] of the mingw packages.
>> Are we enabling spice on windows nightly builds yet?  I haven't had time
>> to look.  If not, this should make life easier.
>>
>> [1]: https://github.com/Alexpux/MINGW-packages/pull/1720
>> 
>> [2]:
>> https://github.com/stambaughw/MINGW-packages/tree/ngspice-git-package 
>> 
>>
>> ___
>> 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] strange behavior in simulation

[Cirilo Bernardo]

Hi folks,

 When I run the kicad process in the background via:

eeschema rectifier.sch &

then when I run the SPICE simulator I get the message:

[1]+  Stopped kicad rectifier.pro

If I put the process into the foreground everything runs fine.
Is there any particular reason why the simulator refuses to
run as a background process? This behavior just seems
very strange and unnecessary to me.

- Cirilo

___
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