date:20191107

Re: [Kicad-developers] macos dev environment

2019-11-07 Thread Adam Wolf

Merging them in is blocked on the "eliminate symlinked bundles" task.

I recently changed my employer and have less time for KiCad during the
transition but I hope to be back to normal soon.

Bt, if you want to tackle any of the open tickets, it'd be a great
helps. Let me know if you are interested and I can write up some help if
you want.

Adam


On Thu, Nov 7, 2019, 3:35 PM Jonatan Liljedahl  wrote:

> Ok, I got it working by changing CMAKE_INSTALL_PREFIX to an absolute
> path. So using "../bin" as it says in
>
> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_osx
> does not actually work.
>
> Perhaps it would be a good idea to merge the kicad-mac-builder patches
> instead of having to apply them each time? I know this was discussed
> before, regarding the mismatch between KiCad version info string for
> the macOS package, but I'm not sure what was decided.
>
> Cheers
>
> On Thu, Nov 7, 2019 at 10:07 PM Jonatan Liljedahl 
> wrote:
> >
> > Thanks. I managed to get it building directly in my kicad source dir
> > by pointing it to the custom wxWidgets etc that was built by
> > kicad-mac-builder. However, make install fails during fixup bundle
> > (see below). I have the patches from kicad-mac-builder applied. I've
> > attached my CMakeCache.txt.
> >
> > Install the project...
> > -- Install configuration: "Debug"
> > -- Removing existing application bundles...
> > -- Installing:
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/kicad.app/Contents/Frameworks/libkicad_3dsg.2.0.0.dylib
> > -- Installing:
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/kicad.app/Contents/Frameworks/libkicad_3dsg.dylib
> > -- Installing:
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app
> > -- Installing:
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents
> > -- Installing:
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/MacOS
> > -- Installing:
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/MacOS/eeschema
> > -- Installing:
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources
> > -- Installing:
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources/eeschema_doc.icns
> > -- Installing:
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources/eeschema.icns
> > -- Installing:
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Info.plist
> > -- fixup_bundle
> > --   app='../bin/eeschema.app/Contents/MacOS/eeschema'
> > --   libs=''
> > --   dirs=''
> > --   ignoreItems=''
> > -- fixup_bundle: preparing...
> > warning: target '../bin/eeschema.app/Contents/MacOS/eeschema' is not
> absolute...
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- warning: gp_resolved_file_type expects absolute full path for first
> > arg original_file
> > -- fixup_bundle: copying...
> > -- 1/24: *NOT* copying
> >
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/MacOS/eeschema'
> > -- 2/24: linking
> >
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau-3.0.0.4.0.dylib'
> > ->
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau-3.0.0.dylib'
> > -- 3/24: linking
> >
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau_gl-3.0.0.4.0.dylib'
> > ->
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau_gl-3.0.0.dylib'
> > -- 4/24: copying '/usr/local/opt/cairo/lib/libcairo.2.dylib'
> > -- 5/24: copying '/usr/local/opt/fontconfig/lib/libfontconfig.1.dylib'
> > -- 6/24: copying '/usr/local/opt/freetype/lib/libfreetype.6.dylib'
> > -- 7/24: linking
> >
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libGLEW.2.1.0.dylib'
> >

Re: [Kicad-developers] macos dev environment

2019-11-07 Thread Bernhard Stegmaier

At least the last time I tried you don’t need to do a “make install” and build 
the bundle if you want to test something during development.
Just run needed KiCad binary directly from the build folder…

I don’t know about CLion, but that worked for me using Qt Creator without 
problems.

The only thing to remember is that if you do a “make install” once, it won’t 
run from build folder any more.


Regards,
Bernhard

> On 7. Nov 2019, at 22:35, Jonatan Liljedahl  wrote:
> 
> Ok, I got it working by changing CMAKE_INSTALL_PREFIX to an absolute
> path. So using "../bin" as it says in
> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_osx
>  
> 
> does not actually work.
> 
> Perhaps it would be a good idea to merge the kicad-mac-builder patches
> instead of having to apply them each time? I know this was discussed
> before, regarding the mismatch between KiCad version info string for
> the macOS package, but I'm not sure what was decided.
> 
> Cheers
> 
> On Thu, Nov 7, 2019 at 10:07 PM Jonatan Liljedahl  > wrote:
>> 
>> Thanks. I managed to get it building directly in my kicad source dir
>> by pointing it to the custom wxWidgets etc that was built by
>> kicad-mac-builder. However, make install fails during fixup bundle
>> (see below). I have the patches from kicad-mac-builder applied. I've
>> attached my CMakeCache.txt.
>> 
>> Install the project...
>> -- Install configuration: "Debug"
>> -- Removing existing application bundles...
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/kicad.app/Contents/Frameworks/libkicad_3dsg.2.0.0.dylib
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/kicad.app/Contents/Frameworks/libkicad_3dsg.dylib
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/MacOS
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/MacOS/eeschema
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources/eeschema_doc.icns
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources/eeschema.icns
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Info.plist
>> -- fixup_bundle
>> --   app='../bin/eeschema.app/Contents/MacOS/eeschema'
>> --   libs=''
>> --   dirs=''
>> --   ignoreItems=''
>> -- fixup_bundle: preparing...
>> warning: target '../bin/eeschema.app/Contents/MacOS/eeschema' is not 
>> absolute...
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- fixup_bundle: copying...
>> -- 1/24: *NOT* copying
>> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/MacOS/eeschema'
>> -- 2/24: linking
>> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau-3.0.0.4.0.dylib'
>> -> 
>> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau-3.0.0.dylib'
>> -- 3/24: linking
>> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau_gl-3.0.0.4.0.dylib'
>> -> 
>> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau_gl-3.0.0.dylib'
>> -- 4/24: copying '/usr/local/opt/cairo/lib/libcairo.2.dylib'
>> -- 5/24: copying '/usr/local/opt/fontconfig/lib/libfontconfig.1.dylib'
>> -- 6/24: copying

Re: [Kicad-developers] macos dev environment

2019-11-07 Thread Jonatan Liljedahl

Ok, I got it working by changing CMAKE_INSTALL_PREFIX to an absolute
path. So using "../bin" as it says in
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_osx
does not actually work.

Perhaps it would be a good idea to merge the kicad-mac-builder patches
instead of having to apply them each time? I know this was discussed
before, regarding the mismatch between KiCad version info string for
the macOS package, but I'm not sure what was decided.

Cheers

On Thu, Nov 7, 2019 at 10:07 PM Jonatan Liljedahl  wrote:
>
> Thanks. I managed to get it building directly in my kicad source dir
> by pointing it to the custom wxWidgets etc that was built by
> kicad-mac-builder. However, make install fails during fixup bundle
> (see below). I have the patches from kicad-mac-builder applied. I've
> attached my CMakeCache.txt.
>
> Install the project...
> -- Install configuration: "Debug"
> -- Removing existing application bundles...
> -- Installing: 
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/kicad.app/Contents/Frameworks/libkicad_3dsg.2.0.0.dylib
> -- Installing: 
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/kicad.app/Contents/Frameworks/libkicad_3dsg.dylib
> -- Installing: 
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app
> -- Installing: 
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents
> -- Installing: 
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/MacOS
> -- Installing: 
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/MacOS/eeschema
> -- Installing: 
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources
> -- Installing: 
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources/eeschema_doc.icns
> -- Installing: 
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources/eeschema.icns
> -- Installing: 
> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Info.plist
> -- fixup_bundle
> --   app='../bin/eeschema.app/Contents/MacOS/eeschema'
> --   libs=''
> --   dirs=''
> --   ignoreItems=''
> -- fixup_bundle: preparing...
> warning: target '../bin/eeschema.app/Contents/MacOS/eeschema' is not 
> absolute...
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- warning: gp_resolved_file_type expects absolute full path for first
> arg original_file
> -- fixup_bundle: copying...
> -- 1/24: *NOT* copying
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/MacOS/eeschema'
> -- 2/24: linking
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau-3.0.0.4.0.dylib'
> -> 
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau-3.0.0.dylib'
> -- 3/24: linking
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau_gl-3.0.0.4.0.dylib'
> -> 
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau_gl-3.0.0.dylib'
> -- 4/24: copying '/usr/local/opt/cairo/lib/libcairo.2.dylib'
> -- 5/24: copying '/usr/local/opt/fontconfig/lib/libfontconfig.1.dylib'
> -- 6/24: copying '/usr/local/opt/freetype/lib/libfreetype.6.dylib'
> -- 7/24: linking
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libGLEW.2.1.0.dylib'
> -> 
> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libGLEW.2.1.dylib'
> -- 8/24: copying '/usr/local/opt/libpng/lib/libpng16.16.dylib'
> -- 9/24: copying '/usr/local/opt/pixman/lib/libpixman-1.0.dylib'
> -- 10/24: copying
> '/Users/lijon/Coding/kicad-mac-builder/build/wxwidgets-dest/lib/libwx_osx_cocoau-3.0.0.4.0.dylib'
> -- 11/24: copying
> '/Users/lijon/Coding/kicad-mac-builder/build/wxwidgets-dest/lib/libwx_osx_cocoau_gl-3.0.0.4.0.dylib'
> -- 12/24: copying '/usr/local/Cellar/glew/2.1.0/lib/libGLEW.2.1.0.dylib'
> -- fixup_bundle:

Re: [Kicad-developers] New lead developer announcement

2019-11-07 Thread Nick Østergaard

It is good to see Ian being recognized :) yaya

On Thu, 7 Nov 2019 at 21:55, Seth Hillbrand  wrote:

> On 11/7/19 12:14 PM, Wayne Stambaugh wrote:
>
> I am happy to announce that the KiCad project now has a new member of
> the lead development team.  Ian McInerney has accepted an invitation to
> become a member of the lead development team.  Ian's contributions have
> earned him this privilege and we are grateful for his efforts.  Please
> join me in congratulating Ian and welcoming in his new role.
>
> 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
>
> Congratulations, Ian!  And welcome!
>
> I'm really looking forward to working with you.
>
> Best-
> Seth
>
> --
> KiCad Services Corporation [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ <+12126039372>
> Davis, CA
> www.kipro-pcb.comi...@kipro-pcb.com
> https://twitter.com/KiProEDA 
> https://www.linkedin.com/company/kicad
> 
> ___
> 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] macos dev environment

2019-11-07 Thread Jonatan Liljedahl

Thanks. I managed to get it building directly in my kicad source dir
by pointing it to the custom wxWidgets etc that was built by
kicad-mac-builder. However, make install fails during fixup bundle
(see below). I have the patches from kicad-mac-builder applied. I've
attached my CMakeCache.txt.

Install the project...
-- Install configuration: "Debug"
-- Removing existing application bundles...
-- Installing: 
/Users/lijon/Coding/kicad/build/debug/../bin/../bin/kicad.app/Contents/Frameworks/libkicad_3dsg.2.0.0.dylib
-- Installing: 
/Users/lijon/Coding/kicad/build/debug/../bin/../bin/kicad.app/Contents/Frameworks/libkicad_3dsg.dylib
-- Installing: /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app
-- Installing: 
/Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents
-- Installing: 
/Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/MacOS
-- Installing: 
/Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/MacOS/eeschema
-- Installing: 
/Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources
-- Installing: 
/Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources/eeschema_doc.icns
-- Installing: 
/Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources/eeschema.icns
-- Installing: 
/Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Info.plist
-- fixup_bundle
--   app='../bin/eeschema.app/Contents/MacOS/eeschema'
--   libs=''
--   dirs=''
--   ignoreItems=''
-- fixup_bundle: preparing...
warning: target '../bin/eeschema.app/Contents/MacOS/eeschema' is not absolute...
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- warning: gp_resolved_file_type expects absolute full path for first
arg original_file
-- fixup_bundle: copying...
-- 1/24: *NOT* copying
'/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/MacOS/eeschema'
-- 2/24: linking
'/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau-3.0.0.4.0.dylib'
-> 
'/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau-3.0.0.dylib'
-- 3/24: linking
'/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau_gl-3.0.0.4.0.dylib'
-> 
'/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau_gl-3.0.0.dylib'
-- 4/24: copying '/usr/local/opt/cairo/lib/libcairo.2.dylib'
-- 5/24: copying '/usr/local/opt/fontconfig/lib/libfontconfig.1.dylib'
-- 6/24: copying '/usr/local/opt/freetype/lib/libfreetype.6.dylib'
-- 7/24: linking
'/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libGLEW.2.1.0.dylib'
-> 
'/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libGLEW.2.1.dylib'
-- 8/24: copying '/usr/local/opt/libpng/lib/libpng16.16.dylib'
-- 9/24: copying '/usr/local/opt/pixman/lib/libpixman-1.0.dylib'
-- 10/24: copying
'/Users/lijon/Coding/kicad-mac-builder/build/wxwidgets-dest/lib/libwx_osx_cocoau-3.0.0.4.0.dylib'
-- 11/24: copying
'/Users/lijon/Coding/kicad-mac-builder/build/wxwidgets-dest/lib/libwx_osx_cocoau_gl-3.0.0.4.0.dylib'
-- 12/24: copying '/usr/local/Cellar/glew/2.1.0/lib/libGLEW.2.1.0.dylib'
-- fixup_bundle: fixing...
-- 13/24: fixing up
'/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/MacOS/eeschema'
  exe_dotapp_dir/='../bin/eeschema.app/'
  item_substring='/Users/lijon/Coding/'
  
resolved_embedded_item='/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/MacOS/eeschema'

Install or copy the item into the bundle before calling fixup_bundle.
Or maybe there's a typo or incorrect path in one of the args to fixup_bundle?

CMake Error at 
/Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:861
(message):
  cannot fixup an item that is not in the bundle...
Call Stack (most recent call first):
  
/Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:989

Re: [Kicad-developers] New lead developer announcement

2019-11-07 Thread Seth Hillbrand


On 11/7/19 12:14 PM, Wayne Stambaugh wrote:

I am happy to announce that the KiCad project now has a new member of
the lead development team.  Ian McInerney has accepted an invitation to
become a member of the lead development team.  Ian's contributions have
earned him this privilege and we are grateful for his efforts.  Please
join me in congratulating Ian and welcoming in his new role.

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

Congratulations, Ian!  And welcome!

I'm really looking forward to working with you.

Best-
Seth

--
KiCad Services Corporation KiCad Services Corporation Logo
Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬ 
Davis, CA
www.kipro-pcb.com  i...@kipro-pcb.com 

https://twitter.com/KiProEDA  
https://www.linkedin.com/company/kicad 



___
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] [PATCH v3] [NEW] eeschema: Allow hierarchy navigator to stay open

2019-11-07 Thread franck . jullien

From: Franck Jullien 

User can now decide to keep the hierarchy navigator open while working
on a schematic. This behavior can be configured in
eeschema->preferences->eeschema->Editing options.

Signed-off-by: Franck Jullien 
---

v2: fix coding style
v3: fix memory leak after Wayne review

 eeschema/dialogs/panel_eeschema_settings.cpp  |  2 +
 .../dialogs/panel_eeschema_settings_base.cpp  |  2 +
 .../dialogs/panel_eeschema_settings_base.fbp  | 88 +
 .../dialogs/panel_eeschema_settings_base.h|  3 +-
 eeschema/eeschema_config.cpp  |  3 +
 eeschema/hierarch.cpp | 76 +++
 eeschema/hierarch.h   | 97 +++
 eeschema/sch_edit_frame.cpp   | 22 +
 eeschema/sch_edit_frame.h | 16 +++
 eeschema/tools/sch_editor_control.cpp |  5 +
 10 files changed, 248 insertions(+), 66 deletions(-)
 create mode 100644 eeschema/hierarch.h

diff --git a/eeschema/dialogs/panel_eeschema_settings.cpp 
b/eeschema/dialogs/panel_eeschema_settings.cpp
index d50b8a373..3ad650d18 100644
--- a/eeschema/dialogs/panel_eeschema_settings.cpp
+++ b/eeschema/dialogs/panel_eeschema_settings.cpp
@@ -46,6 +46,7 @@ bool PANEL_EESCHEMA_SETTINGS::TransferDataToWindow()
 
 m_checkHVOrientation->SetValue( m_frame->GetForceHVLines() );
 m_footprintPreview->SetValue( m_frame->GetShowFootprintPreviews() );
+m_navigatorStaysOpen->SetValue( m_frame->GetNavigatorStaysOpen() );
 
 m_checkAutoplaceFields->SetValue( m_frame->GetAutoplaceFields() );
 m_checkAutoplaceJustify->SetValue( m_frame->GetAutoplaceJustify() );
@@ -75,6 +76,7 @@ bool PANEL_EESCHEMA_SETTINGS::TransferDataFromWindow()
 
 m_frame->SetForceHVLines( m_checkHVOrientation->GetValue() );
 m_frame->SetShowFootprintPreviews( m_footprintPreview->GetValue() );
+m_frame->SetNavigatorStaysOpen( m_navigatorStaysOpen->GetValue() );
 
 m_frame->SetAutoplaceFields( m_checkAutoplaceFields->GetValue() );
 m_frame->SetAutoplaceJustify( m_checkAutoplaceJustify->GetValue() );
diff --git a/eeschema/dialogs/panel_eeschema_settings_base.cpp 
b/eeschema/dialogs/panel_eeschema_settings_base.cpp
index 84c6470b1..7553170b0 100644
--- a/eeschema/dialogs/panel_eeschema_settings_base.cpp
+++ b/eeschema/dialogs/panel_eeschema_settings_base.cpp
@@ -124,6 +124,8 @@ PANEL_EESCHEMA_SETTINGS_BASE::PANEL_EESCHEMA_SETTINGS_BASE( 
wxWindow* parent, wx
m_footprintPreview = new wxCheckBox( this, wxID_ANY, _("Show footprint 
previews in symbol chooser"), wxDefaultPosition, wxDefaultSize, 0 );
bSizer9->Add( m_footprintPreview, 0, wxBOTTOM|wxLEFT|wxRIGHT, 5 );

+   m_navigatorStaysOpen = new wxCheckBox( this, wxID_ANY, _("Allow 
hierarchy navigator to stay open"), wxDefaultPosition, wxDefaultSize, 0 );
+   bSizer9->Add( m_navigatorStaysOpen, 0, wxBOTTOM|wxLEFT|wxRIGHT, 5 );

bLeftColumn->Add( bSizer9, 0, wxTOP|wxBOTTOM|wxRIGHT, 5 );

diff --git a/eeschema/dialogs/panel_eeschema_settings_base.fbp 
b/eeschema/dialogs/panel_eeschema_settings_base.fbp
index 6bc9b6da1..a8996f56f 100644
--- a/eeschema/dialogs/panel_eeschema_settings_base.fbp
+++ b/eeschema/dialogs/panel_eeschema_settings_base.fbp
@@ -1810,6 +1810,94 @@
 
 
 
+
+5
+wxALL
+0
+
+1
+1
+1
+1
+
+
+
+
+
+
+
+1
+0
+1
+1
+
+1
+0
+Dock
+0
+Left
+1
+
+1
+
+0
+0
+wxID_ANY
+Allow hierarchy 
navigator to stay open
+
+0
+

Re: [Kicad-developers] Symbol library code changes

2019-11-07 Thread Brian


From the peanut gallery:
I know 6.0 symbol library handling has many significant differences 
versus 5.x.  Eventually, if I want to keep myself at or near the 
bleeding edge, I'll have to port my ODBC stuff to the 6.0 way of doing 
things.  A couple questions:


1. Is there any documentation of the design, or is my best bet just 
studying the code?
2. I guess there will be some means for converting a 5.x symbol library 
to 6.0, yes?  Regardless of the actual storage mechanism (filesystem, 
ODBC, TCP over carrier pigeon), the format is just different (I remember 
something about switching to S-code), so there'll have to be some way to 
convert from the older SCH/LIB format to S-code, right?


Thanks,
-Brian Henning


On 11/7/19 2:30 PM, Wayne Stambaugh wrote:

Hey Seth,

On 11/7/19 12:22 PM, Seth Hillbrand wrote:

On 2019-11-06 12:34, Wayne Stambaugh wrote:

I finally finish up the initial attempt at simple inheritance for the
symbol library code.  The change is non-trivial and will likely have
some unexpected side affects that I missed.  I pushed the branch to my
personal repo[1] and I would like a few pair of extra eyes on it before
I merge it into master.  If you prefer, I can set up a merge request
from this branch in Launchpad.

The biggest user facing change is that the concept of aliases is gone
which means internally, the LIB_ALIAS object has been removed and all of
the information it managed was moved into LIB_PART.  This actually
simplified some of the UI code but made the LIB_MANAGER and LIB_PART
object code more complicated.  The symbol library editor works
significantly different now.  When you select a derived part (formerly a
LIB_ALIAS), it will show the parent symbol that it was derived from
darkened and all of the edit features disabled.  Until the new symbol
file format is done and writing to the legacy symbol file format is
deprecated, this restriction will have to remain in place.  The
properties editor no longer has an aliases panel and is limited to what
it can change in the derived or parent symbols depending on which symbol
is currently being edited.  I suspect this will be the biggest stumbling
block for existing users so if you can think of a better way to handle
this, I'm open to suggestion.  The other thing that I am concerned about
is symbol library editing.  There were a lot of LIB_MANAGER object
changes which I am not 100% confident in.

Just a couple of other internal changes to be aware of:

A flattened copy of the symbol is used in SCH_COMPONENT instead of
relying on the weak reference to the library symbol.  This way we don't
have to worry about the shared pointer disappearing and causing issues.
However, this will require that we be diligent about updating modified
symbol libraries in the schematic.  Otherwise, the schematic could
change the next time it is loaded.  I'm open to changing this back if we
think it's going to be an issue.

There is now a compare function for the LIB_PART object which can be
rather tricky.  I created a new test suite inside the current LIB_PART
test file so if you change anything, please run the test to ensure
nothing gets broken.  I also added a bunch of other new tests for the
LIB_PART object.

I added code to DIALOG_SHIM to allow the caller to reset the last dialog
size when hiding dialog control state changes between dialog instances.
We have some dialog windows that are not the correct default size
depending on which controls are shown so there is now a convenient way
to address this.

Please let me know if you find anything so I can get it fixed and merged
into master.  The next step is to convert the schematic internal units
from 1mil to 10nm.  Once that step is complete, I will knock out the new
symbol library format.  Thanks in advance for the help.

Cheers,

Wayne

[1]:https://code.launchpad.net/~stambaughw/kicad/+git/kicad-dev/+ref/lib-alias-merge



Hi Wayne-

I'm psyched to see this progress!  Congrats.  I'll have a chance to
fully test after next week but I wanted to get you the code read
feedback before then.

1) Compare function:
- It looks like rhs isn't checked for end() in the loop.  While size
gets checked ahead of time, we've had a couple cases where code gets
added between checks and loops in the past, so it's probably safer to
put the check in the loop.
- Same with the footprint check.  Ideally, these would be the same style
(iterators vs. dereference) but that's minor
- Do we expect these containers to remain sorted?

I'm not sure thats strictly necessary but I will take a look at it.


2) You have a few C-style casts in Flatten()>
3) The LIB_PART() copy constructor should take a const reference rather
than the existing one, that should remove the requirement of using
const_cast in Flatten()

Gaaa!  How did I miss that?


4) That ternary in GetNextDrawItem() is breaking my brain a bit.

This will only get worse with multiple inheritance.  Draw items from
each parent will have to be recused to create a final image of

Re: [Kicad-developers] New lead developer announcement

2019-11-07 Thread Alexander Shuklin

Congratulations, Ian!

Best regards,
Alex

___
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 lead developer announcement

2019-11-07 Thread Drew Van Zandt

Congrats Ian!


*Drew Van Zandt*


On Thu, Nov 7, 2019 at 3:31 PM Sylwester Kocjan  wrote:

> On 07/11/2019 21:14, Wayne Stambaugh wrote:
> > Ian's contributions have
> > earned him this privilege and we are grateful for his efforts.
>
> Congratulations :)
>
> Cheers,
> Sylwester
>
> ___
> 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 lead developer announcement

2019-11-07 Thread Sylwester Kocjan


On 07/11/2019 21:14, Wayne Stambaugh wrote:

Ian's contributions have
earned him this privilege and we are grateful for his efforts. 


Congratulations :)

Cheers,
Sylwester

___
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 lead developer announcement

2019-11-07 Thread Jon Evans

Congrats and welcome, Ian!

On Thu, Nov 7, 2019 at 3:17 PM Jeff Young  wrote:

> Woot!
>
> Congrats, Ian!
>
> Cheers,
> Jeff.
>
>
> > On 7 Nov 2019, at 20:14, Wayne Stambaugh  wrote:
> >
> > I am happy to announce that the KiCad project now has a new member of
> > the lead development team.  Ian McInerney has accepted an invitation to
> > become a member of the lead development team.  Ian's contributions have
> > earned him this privilege and we are grateful for his efforts.  Please
> > join me in congratulating Ian and welcoming in his new role.
> >
> > 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
>
>
> ___
> 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 lead developer announcement

2019-11-07 Thread Jeff Young

Woot!

Congrats, Ian!

Cheers,
Jeff.


> On 7 Nov 2019, at 20:14, Wayne Stambaugh  wrote:
> 
> I am happy to announce that the KiCad project now has a new member of
> the lead development team.  Ian McInerney has accepted an invitation to
> become a member of the lead development team.  Ian's contributions have
> earned him this privilege and we are grateful for his efforts.  Please
> join me in congratulating Ian and welcoming in his new role.
> 
> 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


___
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] New lead developer announcement

2019-11-07 Thread Wayne Stambaugh

I am happy to announce that the KiCad project now has a new member of
the lead development team.  Ian McInerney has accepted an invitation to
become a member of the lead development team.  Ian's contributions have
earned him this privilege and we are grateful for his efforts.  Please
join me in congratulating Ian and welcoming in his new role.

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] Symbol library code changes

2019-11-07 Thread Wayne Stambaugh

Hey Seth,

On 11/7/19 12:22 PM, Seth Hillbrand wrote:
> On 2019-11-06 12:34, Wayne Stambaugh wrote:
>> I finally finish up the initial attempt at simple inheritance for the
>> symbol library code.  The change is non-trivial and will likely have
>> some unexpected side affects that I missed.  I pushed the branch to my
>> personal repo[1] and I would like a few pair of extra eyes on it before
>> I merge it into master.  If you prefer, I can set up a merge request
>> from this branch in Launchpad.
>>
>> The biggest user facing change is that the concept of aliases is gone
>> which means internally, the LIB_ALIAS object has been removed and all of
>> the information it managed was moved into LIB_PART.  This actually
>> simplified some of the UI code but made the LIB_MANAGER and LIB_PART
>> object code more complicated.  The symbol library editor works
>> significantly different now.  When you select a derived part (formerly a
>> LIB_ALIAS), it will show the parent symbol that it was derived from
>> darkened and all of the edit features disabled.  Until the new symbol
>> file format is done and writing to the legacy symbol file format is
>> deprecated, this restriction will have to remain in place.  The
>> properties editor no longer has an aliases panel and is limited to what
>> it can change in the derived or parent symbols depending on which symbol
>> is currently being edited.  I suspect this will be the biggest stumbling
>> block for existing users so if you can think of a better way to handle
>> this, I'm open to suggestion.  The other thing that I am concerned about
>> is symbol library editing.  There were a lot of LIB_MANAGER object
>> changes which I am not 100% confident in.
>>
>> Just a couple of other internal changes to be aware of:
>>
>> A flattened copy of the symbol is used in SCH_COMPONENT instead of
>> relying on the weak reference to the library symbol.  This way we don't
>> have to worry about the shared pointer disappearing and causing issues.
>> However, this will require that we be diligent about updating modified
>> symbol libraries in the schematic.  Otherwise, the schematic could
>> change the next time it is loaded.  I'm open to changing this back if we
>> think it's going to be an issue.
>>
>> There is now a compare function for the LIB_PART object which can be
>> rather tricky.  I created a new test suite inside the current LIB_PART
>> test file so if you change anything, please run the test to ensure
>> nothing gets broken.  I also added a bunch of other new tests for the
>> LIB_PART object.
>>
>> I added code to DIALOG_SHIM to allow the caller to reset the last dialog
>> size when hiding dialog control state changes between dialog instances.
>> We have some dialog windows that are not the correct default size
>> depending on which controls are shown so there is now a convenient way
>> to address this.
>>
>> Please let me know if you find anything so I can get it fixed and merged
>> into master.  The next step is to convert the schematic internal units
>> from 1mil to 10nm.  Once that step is complete, I will knock out the new
>> symbol library format.  Thanks in advance for the help.
>>
>> Cheers,
>>
>> Wayne
>>
>> [1]:https://code.launchpad.net/~stambaughw/kicad/+git/kicad-dev/+ref/lib-alias-merge
>>
>>
> 
> Hi Wayne-
> 
> I'm psyched to see this progress!  Congrats.  I'll have a chance to
> fully test after next week but I wanted to get you the code read
> feedback before then.
> 
> 1) Compare function:
> - It looks like rhs isn't checked for end() in the loop.  While size
> gets checked ahead of time, we've had a couple cases where code gets
> added between checks and loops in the past, so it's probably safer to
> put the check in the loop.
> - Same with the footprint check.  Ideally, these would be the same style
> (iterators vs. dereference) but that's minor
> - Do we expect these containers to remain sorted?

I'm not sure thats strictly necessary but I will take a look at it.

> 
> 2) You have a few C-style casts in Flatten()>
> 3) The LIB_PART() copy constructor should take a const reference rather
> than the existing one, that should remove the requirement of using
> const_cast in Flatten()

Gaaa!  How did I miss that?

> 
> 4) That ternary in GetNextDrawItem() is breaking my brain a bit.

This will only get worse with multiple inheritance.  Draw items from
each parent will have to be recused to create a final image of the symbol.

> 
> 5) In footprint_info.h, if we are returning the wxString itself (instead
> of the reference), it shouldn't be const.  (addendum: Also loadAliases())

Missed another one.

> 
> 6) sch_view.cpp has a couple c-style casts that can probably be
> compressed into our dyn_cast routine.
> 
> 7) DeleteSymbol mixes up it and it1 in the while() loop.

I'll take a look at it.

> 
> I can't wait to test it out!  On the usability issue for aliases, I
> suspect that this is a time limited constraint, so there shouldn't be
> large issues as people should

Re: [Kicad-developers] Symbol library code changes

2019-11-07 Thread Seth Hillbrand


On 2019-11-06 12:34, Wayne Stambaugh wrote:

I finally finish up the initial attempt at simple inheritance for the
symbol library code.  The change is non-trivial and will likely have
some unexpected side affects that I missed.  I pushed the branch to my
personal repo[1] and I would like a few pair of extra eyes on it before
I merge it into master.  If you prefer, I can set up a merge request
from this branch in Launchpad.

The biggest user facing change is that the concept of aliases is gone
which means internally, the LIB_ALIAS object has been removed and all 
of

the information it managed was moved into LIB_PART.  This actually
simplified some of the UI code but made the LIB_MANAGER and LIB_PART
object code more complicated.  The symbol library editor works
significantly different now.  When you select a derived part (formerly 
a

LIB_ALIAS), it will show the parent symbol that it was derived from
darkened and all of the edit features disabled.  Until the new symbol
file format is done and writing to the legacy symbol file format is
deprecated, this restriction will have to remain in place.  The
properties editor no longer has an aliases panel and is limited to what
it can change in the derived or parent symbols depending on which 
symbol
is currently being edited.  I suspect this will be the biggest 
stumbling

block for existing users so if you can think of a better way to handle
this, I'm open to suggestion.  The other thing that I am concerned 
about

is symbol library editing.  There were a lot of LIB_MANAGER object
changes which I am not 100% confident in.

Just a couple of other internal changes to be aware of:

A flattened copy of the symbol is used in SCH_COMPONENT instead of
relying on the weak reference to the library symbol.  This way we don't
have to worry about the shared pointer disappearing and causing issues.
However, this will require that we be diligent about updating modified
symbol libraries in the schematic.  Otherwise, the schematic could
change the next time it is loaded.  I'm open to changing this back if 
we

think it's going to be an issue.

There is now a compare function for the LIB_PART object which can be
rather tricky.  I created a new test suite inside the current LIB_PART
test file so if you change anything, please run the test to ensure
nothing gets broken.  I also added a bunch of other new tests for the
LIB_PART object.

I added code to DIALOG_SHIM to allow the caller to reset the last 
dialog

size when hiding dialog control state changes between dialog instances.
We have some dialog windows that are not the correct default size
depending on which controls are shown so there is now a convenient way
to address this.

Please let me know if you find anything so I can get it fixed and 
merged

into master.  The next step is to convert the schematic internal units
from 1mil to 10nm.  Once that step is complete, I will knock out the 
new

symbol library format.  Thanks in advance for the help.

Cheers,

Wayne

[1]:https://code.launchpad.net/~stambaughw/kicad/+git/kicad-dev/+ref/lib-alias-merge



Hi Wayne-

I'm psyched to see this progress!  Congrats.  I'll have a chance to 
fully test after next week but I wanted to get you the code read 
feedback before then.


1) Compare function:
- It looks like rhs isn't checked for end() in the loop.  While size 
gets checked ahead of time, we've had a couple cases where code gets 
added between checks and loops in the past, so it's probably safer to 
put the check in the loop.
- Same with the footprint check.  Ideally, these would be the same style 
(iterators vs. dereference) but that's minor

- Do we expect these containers to remain sorted?

2) You have a few C-style casts in Flatten()

3) The LIB_PART() copy constructor should take a const reference rather 
than the existing one, that should remove the requirement of using 
const_cast in Flatten()


4) That ternary in GetNextDrawItem() is breaking my brain a bit.

5) In footprint_info.h, if we are returning the wxString itself (instead 
of the reference), it shouldn't be const.  (addendum: Also loadAliases())


6) sch_view.cpp has a couple c-style casts that can probably be 
compressed into our dyn_cast routine.


7) DeleteSymbol mixes up it and it1 in the while() loop.

I can't wait to test it out!  On the usability issue for aliases, I 
suspect that this is a time limited constraint, so there shouldn't be 
large issues as people should not be building aliased libraries with the 
master branch at this point.  We may want to clarify that in a list 
message.  Overall, I am very excited for the new formats.  Thanks again 
for taking on this huge job!


Best-
Seth

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More

Re: [Kicad-developers] macos dev environment

2019-11-07 Thread Adam Wolf

We're going to do that in the simple way, which is to copy rather than
symlink.  It costs a few megs, but that should be fine.

On Thu, Nov 7, 2019 at 9:12 AM Jon Evans  wrote:
>
> I also use CLion.  It's okay but not perfect.  It's been a while since I've 
> been compiling on my Mac but from what I recall, the most frustrating part is 
> the need to re-generate all of the application packages whenever anything is 
> touched (which is a slow and non-parallel process).
>
> It's possible that implementing one of the possible fixes for 
> https://bugs.launchpad.net/kicad/+bug/1826649 will also enable faster 
> incremental builds on MacOS
>
> -Jon
>
> On Thu, Nov 7, 2019 at 10:07 AM Adam Wolf  
> wrote:
>>
>> I use CLion, but I also would love to see kicad-mac-builder improved
>> to the point where it could do the right things for dev, as well.
>>
>> Adam
>>
>> On Thu, Nov 7, 2019 at 7:45 AM Jonatan Liljedahl  wrote:
>> >
>> > Are there any developers on macOS that would like to give me some
>> > hints on how to set up a good environment? Currently I'm using
>> > kicad-mac-builder, but it's not well suited for the kind of iterative
>> > rebuilding during development.
>> >
>> > 1. It applies the patches each time.
>> > 2. It resets the git repo each time.
>> > 3. It re-downloads all docs etc each time.
>> > 4. It does not rebuild the changed source files.
>> >
>> > So for now, I've just commented out the docs dependency and commands
>> > for applying the patches and resetting git, etc.
>> >
>> > But it still does not rebuild when I change some source file, so I need to 
>> > do:
>> >
>> > make -f CMakeFiles/Makefile2 CMakeFiles/kicad.dir/clean
>> >
>> > and rebuild, which probably takes more time than needed.
>> >
>> > --
>> > /Jonatan
>> > http://kymatica.com
>> >
>> > ___
>> > 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] macos dev environment

2019-11-07 Thread Jon Evans

I also use CLion.  It's okay but not perfect.  It's been a while since I've
been compiling on my Mac but from what I recall, the most frustrating part
is the need to re-generate all of the application packages whenever
anything is touched (which is a slow and non-parallel process).

It's possible that implementing one of the possible fixes for
https://bugs.launchpad.net/kicad/+bug/1826649 will also enable faster
incremental builds on MacOS

-Jon

On Thu, Nov 7, 2019 at 10:07 AM Adam Wolf 
wrote:

> I use CLion, but I also would love to see kicad-mac-builder improved
> to the point where it could do the right things for dev, as well.
>
> Adam
>
> On Thu, Nov 7, 2019 at 7:45 AM Jonatan Liljedahl 
> wrote:
> >
> > Are there any developers on macOS that would like to give me some
> > hints on how to set up a good environment? Currently I'm using
> > kicad-mac-builder, but it's not well suited for the kind of iterative
> > rebuilding during development.
> >
> > 1. It applies the patches each time.
> > 2. It resets the git repo each time.
> > 3. It re-downloads all docs etc each time.
> > 4. It does not rebuild the changed source files.
> >
> > So for now, I've just commented out the docs dependency and commands
> > for applying the patches and resetting git, etc.
> >
> > But it still does not rebuild when I change some source file, so I need
> to do:
> >
> > make -f CMakeFiles/Makefile2 CMakeFiles/kicad.dir/clean
> >
> > and rebuild, which probably takes more time than needed.
> >
> > --
> > /Jonatan
> > http://kymatica.com
> >
> > ___
> > 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] macos dev environment

2019-11-07 Thread Adam Wolf

I use CLion, but I also would love to see kicad-mac-builder improved
to the point where it could do the right things for dev, as well.

Adam

On Thu, Nov 7, 2019 at 7:45 AM Jonatan Liljedahl  wrote:
>
> Are there any developers on macOS that would like to give me some
> hints on how to set up a good environment? Currently I'm using
> kicad-mac-builder, but it's not well suited for the kind of iterative
> rebuilding during development.
>
> 1. It applies the patches each time.
> 2. It resets the git repo each time.
> 3. It re-downloads all docs etc each time.
> 4. It does not rebuild the changed source files.
>
> So for now, I've just commented out the docs dependency and commands
> for applying the patches and resetting git, etc.
>
> But it still does not rebuild when I change some source file, so I need to do:
>
> make -f CMakeFiles/Makefile2 CMakeFiles/kicad.dir/clean
>
> and rebuild, which probably takes more time than needed.
>
> --
> /Jonatan
> http://kymatica.com
>
> ___
> 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] Pcbnew drill sizes statistics & Project manager multiple selection options

2019-11-07 Thread jp charras

Le 06/11/2019 à 23:18, Mikołaj Wielgus a écrit :
> Hello,
> 
> I have submitted two patches on Launchpad some time ago. I would like to
> ask for feedback.
> 
> Links:
> https://bugs.launchpad.net/kicad/+bug/1841144
> https://bugs.launchpad.net/kicad/+bug/1016464
> 
> Best Regards,
> Mikołaj Wielgus

Hi Mikołaj,

First, thanks for your contribution.

I had a look into your patches.

I do not seen big problems, but I suggest a few enhancements:
-  Project manager multiple selection options:
When deleting a list of files, a confirmation is asked for each file.
Only one confirmation is enough.
When deleting a list of files, a instance of the editor is opened for
each file.
All editors are able to open more than one file, so I suggest only one
instance of the editor opening all files.

- Pcbnew drill sizes statistics:
It display pads with no holes. The filter to select pads:
if( pad->GetAttribute() != PAD_ATTRIB_SMD )
is incorrect
(other pads can have no hole).
the filter must test only the hole size.
A minor cosmetic issue:
The columns sizes are too small:
When sorting a column, the column label is not readable (see X size
column in attached files).

They are minor issues.
Can you fix them.

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

Re: [Kicad-developers] SIM_PLOT_TYPE

2019-11-07 Thread Jonatan Liljedahl

Indeed, it seems that in all cases the actual spice vector used for
the X axis will be "frequency", which as far as I can tell is always
log. Perhaps it would make sense to just replace SPT_LOG_FREQUENCY and
SPT_LIN_FREQUENCY with a single SPT_FREQUENCY enum?

I'm not sure how plotting linear frequency works in ngspice, is this
done with some command that alters the "frequency" vector (which would
then propagate to KiCad), or is it handled in the plot command?

Cheers

On Thu, Nov 7, 2019 at 2:13 AM Ian McInerney  wrote:
>
> I would guess that is a mistake. It seems that the intention is to eventually 
> have both linear and log scaling, so they would need to be different. Right 
> now though it looks like log scaling isn't handled differently (a search for 
> SPT_LOG_FREQUENCY returns a TODO comment and an if check that is also for the 
> SPT_LIN_FREQUENCY).
>
> -Ian
>
> On Wed, Nov 6, 2019 at 9:24 PM Jonatan Liljedahl  wrote:
>>
>> in sim_types.h:
>>
>> //> Possible plot types
>> enum SIM_PLOT_TYPE {
>> // Y axis
>> SPT_VOLTAGE = 0x01,
>> SPT_CURRENT = 0x02,
>> SPT_AC_PHASE= 0x04,
>> SPT_AC_MAG  = 0x08,
>>
>> // X axis
>> SPT_TIME= 0x10,
>> SPT_LIN_FREQUENCY   = 0x20,
>> SPT_LOG_FREQUENCY   = 0x20,
>> SPT_SWEEP   = 0x40
>> };
>>
>> Is it by purpose that the lin/log freq flags have the same value?
>>
>> --
>> /Jonatan
>> http://kymatica.com
>>
>> ___
>> 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



-- 
/Jonatan
http://kymatica.com

___
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] macos dev environment

2019-11-07 Thread Jonatan Liljedahl

Are there any developers on macOS that would like to give me some
hints on how to set up a good environment? Currently I'm using
kicad-mac-builder, but it's not well suited for the kind of iterative
rebuilding during development.

1. It applies the patches each time.
2. It resets the git repo each time.
3. It re-downloads all docs etc each time.
4. It does not rebuild the changed source files.

So for now, I've just commented out the docs dependency and commands
for applying the patches and resetting git, etc.

But it still does not rebuild when I change some source file, so I need to do:

make -f CMakeFiles/Makefile2 CMakeFiles/kicad.dir/clean

and rebuild, which probably takes more time than needed.

-- 
/Jonatan
http://kymatica.com

___
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] Pcbnew drill sizes statistics & Project manager multiple selection options

2019-11-07 Thread Wayne Stambaugh

Hi Mikołaj,

I apologize for the delay but all of the lead developers are very busy
at the moment.  We appreciate your patience and will try to get around
to reviewing your patches as soon as possible.  Hopefully it wont be too
much longer.  If one of the members of the lead dev team has a few spare
cycles, please take the time to help Mikołaj out.  If not, I should be
able to get to it early next week.

Cheers,

Wayne

On 11/6/19 5:18 PM, Mikołaj Wielgus wrote:
> Hello,
> 
> I have submitted two patches on Launchpad some time ago. I would like to
> ask for feedback.
> 
> Links:
> https://bugs.launchpad.net/kicad/+bug/1841144
> https://bugs.launchpad.net/kicad/+bug/1016464
> 
> Best Regards,
> Mikołaj Wielgus
> 
> ___
> 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] Back annotate references from PCB

2019-11-07 Thread Alexander Shuklin

Hi,
is it alright to answer anybody in one letter?
First of all, don't take amiss if I keep silence for a day, as I have
2 little children and at the best case I have couple of hours a day on
my own.

On Wed, 6 Nov 2019 at 16:27, Wayne Stambaugh  wrote:
> Complex schematic hierarchies (using the same schematic more than once in a 
> design) always trips up new developers.
Can you please explain a bit more? I know that you can use
hierarchical sheets, so there will be more than one sch files in the
schematic. And there's also "multi-symbols" which have few eeschema
symbols but one footprint. I'm not quite understand what means "using
the same schematic more than once in a design", as every symbol has
unique ID. Is it something else I'm not aware of?
> You'll want to take a close look at KIWAY::ExpressMail() and 
> KIWAY_PLAYER::KiwayMailIn()
Ok, I'll look at that. I think I've seen that in footprints back annotation.
> This is unfortunate.  Being able to work directly with on of the lead 
> developers would have made this task a lot easier to understand.  You are 
> always free to reach out for help on this mailing list.
Thanks for that. Actually now i think to join FOSDEM, but I need visa
and I'm not sure yet.
> Asking first prevents you from working on something that someone else may 
> already be working on and writing code that would be immediately rejected
Actually I already made that mistake, when made board statistics
dialog. It was accepted, but I felt myself really stupid.
> Good luck and thank you for your interest in contributing to KiCad.
Thanks! I will try hard to match coding and git polices.

On Wed, 6 Nov 2019 at 17:24, Jon Evans  wrote:
> Eeschema now keeps its internal net state up to date continuously, but I 
> didn't work on any continuous syncing to PcbNew.  The way it works in 
> Eeschema, the graphical schematic is still the driving source of truth; the 
> netlist does not drive the schematic.
Am I right in general idea: Eeschema creates netlist which updates
continuously. And PCB updates through eeschema by "uppdate PCB from
schematic" tool. It isn't planned to do that automatically and
continuously, is it?

On Wed, 6 Nov 2019 at 17:56, Brian Piccioni  wrote:
> My utility is up on GitHub as a standalone app. I learned enough c++ and 
> wxWidgets so porting it to Kicad should be useful.
I've seen your app, and bug report. And actually I try to jump in
because I use geometrical renumber of components as well)))
> Replacing my homebrew parsing of PCB, Schematic, and netlist files to calls 
> to internal Kicad functions/methods in the respective apps;
> Once this is done I’ll use Kiway to communicate the changes between eeSchema 
> and PCBNew.
Have you already start to create communication between eeschema and
pcbnew? If not, don't you mind if I'll start with that first? From my
point of view, that's a worst part in this question today. For example
you can renumber modules in pcbnew even by python scripts, but you
have no any tool to change schematic after that. And by the way it's
not only about renumber of all components. Somebody would like to
change some references in pcbnew by hand at push that data back to
schematics.
>In the final version, if I understand correctly, in V6 changes to the PCB will 
>be back-annotated to the schematic in order to support pin and  gate swapping. 
>So updating the PCB will immediately incorporate the changes to the schematic. 
>I haven’t seen any discussions of how this will be done but clearly if the 
>prototype as described above works it will be trivial to support the V6 common 
>database.
Hm... I haven't think about that... I'm not sure if pin swapping will
interact with back-annotation tool. I wouldn't say that, but if
somebody has comments and thoughts about that, it would be greatly
appreciated.

As far as I see now, It should be some tool a bit similar to "Update
PCB from schematic", which will utilize KiWay functions to send data
between PCBnew and eeschema..

___
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] simulation: allow entering signals (spice vectors) by name

2019-11-07 Thread Jonatan Liljedahl

Hi,

Here's an updated patch with fixed commit message. Also I removed some
unrelated UI tweaks in sim_plot_frame that accidentally was part of
the previous patch. This patch applies to both 5.1 and master.

Cheers

On Thu, Nov 7, 2019 at 12:04 AM Kymatica  wrote:
>
> Oh, this was for 5.1.
> I’ll look into rebasing on master tomorrow! Sleepy time here in Sweden...
>
> /Jonatan
>
> > 6 nov. 2019 kl. 23:57 skrev Wayne Stambaugh :
> >
> > This patch does not apply cleanly against master using `git am`.  Did
> > you forget to rebase against the master branch before creating your patch?
> >
> > Wayne
> >
> >> On 11/6/19 5:48 PM, Jonatan Liljedahl wrote:
> >> Ok, now I think I've followed the policies correctly, here's the updated 
> >> patch.
> >>
> >> Cheers
> >>
> >>> On Wed, Nov 6, 2019 at 10:33 PM Wayne Stambaugh  
> >>> wrote:
> >>>
> >>> Hi Jonathon,
> >>>
> >>> I tested your original patch on the 5.1 branch and it seems to work as
> >>> advertised.  It would be nice if there was a way to query ngspice for a
> >>> list of vectors rather than using just the net list to populate add
> >>> signals dialog.  Maybe Holger can weigh in on this.
> >>>
> >>> Before you submit your updated patch, please fix your code formatting to
> >>> follow the KiCad Coding Policy[1] and your commit message to follow the
> >>> KiCad Commit Message[2] policy.  There is a git commit hook[3] to help
> >>> you with coding policy issues.  I saw some K curly brace placement in
> >>> your patch.
> >>>
> >>> Thanks,
> >>>
> >>> Wayne
> >>>
> >>> [1]:
> >>> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html
> >>> [2]: http://docs.kicad-pcb.org/doxygen/commit_messages.html
> >>> [3]:
> >>> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html#tools
> >>>
> >>> On 11/6/19 4:06 PM, Jonatan Liljedahl wrote:
>  This patch does not implement all of pt 4 in that bug report, it only
>  allows adding plots of vectors by name, including vectors created by
>  LET statements in a spice text block in the schematic (which are not
>  listed in the signals list, since that list is based on the net names,
>  not the existing spice vectors).
> 
>  However, I just realized that there's a problem with my patch, it only
>  works for V, not I. I'll take a look and update my patch.
> 
>  On Wed, Nov 6, 2019 at 9:08 PM Sylwester Kocjan  wrote:
> >
> > Hi Jonatan,
> >
> > On 06/11/2019 13:29, Jonatan Liljedahl wrote:
> >> useful for plotting calculated vectors ("let AB=V(a)*V(b)"),
> >> see for example
> >> https://forum.kicad.info/t/ac-analysis-of-op-amp-loop-gain-and-phase/19661/6
> >>
> >
> > Just small remark to limit entropy in bug reports: it looks like you
> > have implemented pt. 4 from:
> >
> > https://bugs.launchpad.net/kicad/+bug/1814188
> >
> > Maybe it's worth to update that bug report if it will be merged.
> >
> > Best regards,
> > Sylwester
> >
> > ___
> > 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



-- 
/Jonatan
http://kymatica.com


0001-Eeschema-simulation-allow-adding-signals-by-name-lik.patch
Description: Binary data
___
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] macos dev environment

Re: [Kicad-developers] macos dev environment

Re: [Kicad-developers] macos dev environment

Re: [Kicad-developers] New lead developer announcement

Re: [Kicad-developers] macos dev environment

Re: [Kicad-developers] New lead developer announcement

[Kicad-developers] [PATCH v3] [NEW] eeschema: Allow hierarchy navigator to stay open

Re: [Kicad-developers] Symbol library code changes

Re: [Kicad-developers] New lead developer announcement

Re: [Kicad-developers] New lead developer announcement

Re: [Kicad-developers] New lead developer announcement

Re: [Kicad-developers] New lead developer announcement

Re: [Kicad-developers] New lead developer announcement

[Kicad-developers] New lead developer announcement

Re: [Kicad-developers] Symbol library code changes

Re: [Kicad-developers] Symbol library code changes

Re: [Kicad-developers] macos dev environment

Re: [Kicad-developers] macos dev environment

Re: [Kicad-developers] macos dev environment

Re: [Kicad-developers] [PATCH] Pcbnew drill sizes statistics & Project manager multiple selection options

Re: [Kicad-developers] SIM_PLOT_TYPE

[Kicad-developers] macos dev environment

Re: [Kicad-developers] [PATCH] Pcbnew drill sizes statistics & Project manager multiple selection options

Re: [Kicad-developers] Back annotate references from PCB

Re: [Kicad-developers] [PATCH] simulation: allow entering signals (spice vectors) by name

25 matches

Site Navigation

Mail list logo

Footer information