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

2018-02-23 Thread Nick Østergaard 
Hi Miles,

I use archlinux and used this AUR package to install phoenix,
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=python-wxpython-phoenix

Then I applied your patch and added that header file to kicad as shown on
https://github.com/nickoe/kicad-source-mirror/compare/master...nickoe:diffs_for_phoenix

Then I think I just hit cmake; make

Nick

2018-02-22 11:16 GMT+01:00 miles mccoo :

> So I'd like to help out and take a look, but getting wxphoenix with gtk2
> is proving a bit challenging. I did manage to install something (albeit the
> wrong one) in the past.
>
> Nick, what command did you use to install?
>
>
> Miles
>
>
> I have a fresh virtual ubuntu 16.04 install.
>
> I think I ran my normal pkg installs.
>
> sudo apt-get -y install libwxgtk3.0-0v5 libglew-dev libcairo2-dev libbz2-dev 
> doxygen libssl-dev libboost-dev libboost-thread-dev libboost-context-dev 
> libboost-filesystem-dev libboost-iostreams-dev libboost-locale-dev 
> libboost-program-options-dev swig python-wxgtk3.0* git cmake libwxgtk3.0 
> libglm-dev libcurl3 libcurl3-dev python-dev
>
>
> I ran the installs recommended on the wxpython page
> sudo apt install  dpkg-dev build-essential libjpeg-dev libtiff-dev
> libsdl1.2-dev libgstreamer-plugins-base0.10-dev libnotify-dev freeglut3
> freeglut3-dev libsm-dev
>
> sudo apt-get -y install libwxgtk3.0-0v5 libglew-dev libcairo2-dev libbz2-dev 
> doxygen libssl-dev libboost-dev libboost-thread-dev libboost-context-dev 
> libboost-filesystem-dev libboost-iostreams-dev libboost-locale-dev 
> libboost-program-options-dev swig python-wxgtk3.0* git cmake libwxgtk3.0 
> libglm-dev libcurl3 libcurl3-dev python-dev
>
> I later removed wx with gtk3 which was somehow part of my standard installs
>
> sudo apt remove libwxgtk3.0
> sudo apt remove python-wxgtk3.0*
>
>
> sudo apt-get install libgtk2.0-dev
> sudo apt install libwebkitgtk-dev
>
> wget https://wxpython.org/Phoenix/snapshot-builds/wxPython-4.0.
> 2a1.dev3684+086967a.tar.gz
>
> sudo pip install --upgrade --pre -f wxPython-4.0.2a1.dev3684+086967a.tar.gz
> wxPython
>
>
> I get a bunch of spew including these:
>
> Configure options: ['--enable-unicode', '--with-gtk=3',
> '--with-opengl', '--enable-sound', '--enable-graphics_ctx',
> '--enable-mediactrl', '--enable-display', '--enable-geometry',
> '--enable-debug_flag', '--enable-optimise', '--disable-debugreport',
> '--enable-uiactionsim', '--with-sdl']
> /tmp/pip-build-W4npQK/wxPython/ext/wxWidgets/configure
> --enable-unicode --with-gtk=3 --with-opengl --enable-sound
> --enable-graphics_ctx --enable-mediactrl --enable-display --enable-geometry
> --enable-debug_flag --enable-optimise --disable-debugreport
> --enable-uiactionsim --with-sdl
>
>
>checking for GTK+ - version >= 3.0.0... Package gtk+-3.0 was not found
> in the pkg-config search path.
> Perhaps you should add the directory containing `gtk+-3.0.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'gtk+-3.0' found
> no
> *** Could not run GTK+ test program, checking why...
> *** The test program failed to compile or link. See the file
> config.log for the
> *** exact error that occured. This usually means GTK+ is incorrectly
> installed.
> configure: error:
> The development files for GTK+ were not found. For GTK+ 2, please
> ensure that pkg-config is in the path and that gtk+-2.0.pc is
> installed. For GTK+ 1.2 please check that gtk-config is in the path,
> and that the version is 1.2.3 or above. Also check that the
> libraries returned by 'pkg-config gtk+-2.0 --libs' or 'gtk-config
> --libs' are in the LD_LIBRARY_PATH or equivalent.
>
>
>
> pkg-config seems to be ok
> pkg-config gtk+-2.0 --libs
> -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo
> -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0
> -lglib-2.0 -lfontconfig -lfreetype
>
>
>
>
>
>
>
> On Fri, Feb 16, 2018 at 8:13 PM, Carsten Schoenert <
> c.schoen...@t-online.de> wrote:
>
>> Hello Wayne,
>>
>> as Nick has written about a different part in this thread ...
>>
>> Am 24.11.17 um 14:00 schrieb Wayne Stambaugh:
>> > I'm surprised there is no RFP for phoenix yet given that it will (has)
>> > become the replacement for wxpython.  wxpython is a dead code base as
>> > far as I know.  I certainly can create an RFP for phoenix but I am in no
>> > position to actually help with the packaging.
>>
>> Everybody can open up a RFP in Debian, so $somebody just needs to it. :-)
>>
>> But, in the between time a ITP (Intent To Package) was opened for
>> wxpython4.0 [1] some days ago. And since a few days a prepared binary
>> package set is waiting in NEW [2] to get processed by the FTP Masters.
>> So there is some light out there. ;)
>>
>> The upload was addressed into unstable so it should get into unstable
>> and a few days later into testings once it gets accepted.
>>
>> [1] https://bugs.debian.org/888554
>> [2] https://ftp-master.debian.org/new/wxpython4.0_4.0.1+dfsg-1.html

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

2018-02-22 Thread miles mccoo 
So I'd like to help out and take a look, but getting wxphoenix with gtk2 is
proving a bit challenging. I did manage to install something (albeit the
wrong one) in the past.

Nick, what command did you use to install?


Miles


I have a fresh virtual ubuntu 16.04 install.

I think I ran my normal pkg installs.

sudo apt-get -y install libwxgtk3.0-0v5 libglew-dev libcairo2-dev
libbz2-dev doxygen libssl-dev libboost-dev libboost-thread-dev
libboost-context-dev libboost-filesystem-dev libboost-iostreams-dev
libboost-locale-dev libboost-program-options-dev swig python-wxgtk3.0*
git cmake libwxgtk3.0 libglm-dev libcurl3 libcurl3-dev python-dev


I ran the installs recommended on the wxpython page
sudo apt install  dpkg-dev build-essential libjpeg-dev libtiff-dev
libsdl1.2-dev libgstreamer-plugins-base0.10-dev libnotify-dev freeglut3
freeglut3-dev libsm-dev

sudo apt-get -y install libwxgtk3.0-0v5 libglew-dev libcairo2-dev
libbz2-dev doxygen libssl-dev libboost-dev libboost-thread-dev
libboost-context-dev libboost-filesystem-dev libboost-iostreams-dev
libboost-locale-dev libboost-program-options-dev swig python-wxgtk3.0*
git cmake libwxgtk3.0 libglm-dev libcurl3 libcurl3-dev python-dev

I later removed wx with gtk3 which was somehow part of my standard installs

sudo apt remove libwxgtk3.0
sudo apt remove python-wxgtk3.0*


sudo apt-get install libgtk2.0-dev
sudo apt install libwebkitgtk-dev

wget
https://wxpython.org/Phoenix/snapshot-builds/wxPython-4.0.2a1.dev3684+086967a.tar.gz

sudo pip install --upgrade --pre -f wxPython-4.0.2a1.dev3684+086967a.tar.gz
wxPython


I get a bunch of spew including these:

Configure options: ['--enable-unicode', '--with-gtk=3',
'--with-opengl', '--enable-sound', '--enable-graphics_ctx',
'--enable-mediactrl', '--enable-display', '--enable-geometry',
'--enable-debug_flag', '--enable-optimise', '--disable-debugreport',
'--enable-uiactionsim', '--with-sdl']
/tmp/pip-build-W4npQK/wxPython/ext/wxWidgets/configure --enable-unicode
--with-gtk=3 --with-opengl --enable-sound --enable-graphics_ctx
--enable-mediactrl --enable-display --enable-geometry --enable-debug_flag
--enable-optimise --disable-debugreport --enable-uiactionsim --with-sdl


   checking for GTK+ - version >= 3.0.0... Package gtk+-3.0 was not found
in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-3.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gtk+-3.0' found
no
*** Could not run GTK+ test program, checking why...
*** The test program failed to compile or link. See the file config.log
for the
*** exact error that occured. This usually means GTK+ is incorrectly
installed.
configure: error:
The development files for GTK+ were not found. For GTK+ 2, please
ensure that pkg-config is in the path and that gtk+-2.0.pc is
installed. For GTK+ 1.2 please check that gtk-config is in the path,
and that the version is 1.2.3 or above. Also check that the
libraries returned by 'pkg-config gtk+-2.0 --libs' or 'gtk-config
--libs' are in the LD_LIBRARY_PATH or equivalent.



pkg-config seems to be ok
pkg-config gtk+-2.0 --libs
-lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo
-lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0
-lglib-2.0 -lfontconfig -lfreetype







On Fri, Feb 16, 2018 at 8:13 PM, Carsten Schoenert 
wrote:

> Hello Wayne,
>
> as Nick has written about a different part in this thread ...
>
> Am 24.11.17 um 14:00 schrieb Wayne Stambaugh:
> > I'm surprised there is no RFP for phoenix yet given that it will (has)
> > become the replacement for wxpython.  wxpython is a dead code base as
> > far as I know.  I certainly can create an RFP for phoenix but I am in no
> > position to actually help with the packaging.
>
> Everybody can open up a RFP in Debian, so $somebody just needs to it. :-)
>
> But, in the between time a ITP (Intent To Package) was opened for
> wxpython4.0 [1] some days ago. And since a few days a prepared binary
> package set is waiting in NEW [2] to get processed by the FTP Masters.
> So there is some light out there. ;)
>
> The upload was addressed into unstable so it should get into unstable
> and a few days later into testings once it gets accepted.
>
> [1] https://bugs.debian.org/888554
> [2] https://ftp-master.debian.org/new/wxpython4.0_4.0.1+dfsg-1.html
>
> --
> Regards
> Carsten Schoenert
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

2018-02-16 Thread Carsten Schoenert 
Hello Wayne,

as Nick has written about a different part in this thread ...

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

Everybody can open up a RFP in Debian, so $somebody just needs to it. :-)

But, in the between time a ITP (Intent To Package) was opened for
wxpython4.0 [1] some days ago. And since a few days a prepared binary
package set is waiting in NEW [2] to get processed by the FTP Masters.
So there is some light out there. ;)

The upload was addressed into unstable so it should get into unstable
and a few days later into testings once it gets accepted.

[1] https://bugs.debian.org/888554
[2] https://ftp-master.debian.org/new/wxpython4.0_4.0.1+dfsg-1.html

-- 
Regards
Carsten Schoenert

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

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

2018-02-16 Thread Nick Østergaard 
Hello Miles,

Since it seems that Phoenix has now been released I just tried to test
against it with your patch. But I get a build error related to sip.

[ 75%] Building CXX object pcbnew/CMakeFiles/pcbnew_kiface.dir/pcbnew.cpp.o
In file included from
/home/nickoe/kicad-source-mirror/pcbnew/swig/python_scripting.h:40:0,
 from /home/nickoe/kicad-source-mirror/pcbnew/pcbnew.cpp:32:
/home/nickoe/kicad-source-mirror/pcbnew/swig/wxpy_api.h:166:36: error:
expected ‘;’ at end of member declaration
 void* (*p_wxPyGetCppPtr)(sipSimpleWrapper* sipPyObj);
^
/home/nickoe/kicad-source-mirror/pcbnew/swig/wxpy_api.h:166:54: error:
expected ‘)’ before ‘*’ token
 void* (*p_wxPyGetCppPtr)(sipSimpleWrapper* sipPyObj);
  ^
/home/nickoe/kicad-source-mirror/pcbnew/swig/wxpy_api.h:266:28: warning:
inline variables are only available with -std=c++1z or -std=gnu++1z
 inline void* wxPyGetCppPtr(sipSimpleWrapper* sipPyObj)
^~~~
/home/nickoe/kicad-source-mirror/pcbnew/swig/wxpy_api.h:266:28: error:
‘sipSimpleWrapper’ was not declared in this scope
/home/nickoe/kicad-source-mirror/pcbnew/swig/wxpy_api.h:266:46: error:
‘sipPyObj’ was not declared in this scope
 inline void* wxPyGetCppPtr(sipSimpleWrapper* sipPyObj)
  ^~~~
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:120:
pcbnew/CMakeFiles/pcbnew_kiface.dir/pcbnew.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1571:
pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
make: *** [Makefile:152: all] Error 2


I am using wxpython Phoenix 4.0.1. And I copied the wxpy_api.h to
pcbnew/swig in the folder with python_scripting.h.

I pushed the changes to my github fork for comparison.
https://github.com/nickoe/kicad-source-mirror/compare/master...nickoe:diffs_for_phoenix


Nick

2017-11-23 21:32 GMT+01:00 miles mccoo :

> Thanks all, for the replies
>
> Thank you for merging my patch.
>
> I'm pleased to read that the Kicad takes the python interface seriously.
>
> Abstraction layer. I've considered writing one or at least submitting
> patches to move in that direction[1] but I got sidetracked trying to
> document what's already there. I will note that documenting the current
> python interface indirectly documents some of the c++ (which is also not
> the easiest to decipher) See this UML
> 
>  Many
> potential changes from the python viewpoint could be helpful on the c++
> side as well
>
> SWIG work appears to be safe. It seems the can exist together. (the
> possibility of a one or the other situation was very real in my mind.) Most
> of Kicad's API do not involve wx types and the ones that do should be
> passed back and forth as tuples anyway.
>
>
> Tomasz: I will take a close look at your suggestions. In particular, the
> wxpoint, vector2 stuff is inline with what I mentioned above.
>
> I've had other thoughts, like the ability to add commands implemented in
> python. This would involve the ability to add callbacks to onleftclick,
> onrightclick, add to menu... That's a big one though [2]
>
>
> Wayne: I did not try the scripts that come with kicad. I didn't try the
> footprint generator.
>
> I tried:
> gensvg
>  which
> generates as svg file from the layout of the currently loaded pcb.
> replicatelayout
> 
>  which
> replicates the placement of stuff based on sheet instances from the
> schematic. You place the devices of one instance of a sheet and the script
> moves the others to match. [3] I have a youtube demo here:
> https://youtu.be/m9LBR_q1Y0M
> neither uses anything in the GUI. The current version of replicate doesn't
> work, but with my patch that was just merged, I'll be able to push an
> update does work.
>
> I did try binding mouse and other canvas events. It's not on my github, so
> I'm attaching it.
>
> Not thorough in any way, but that it works at all felt like a success to
> me.
>
> Miles
>
>
>
> [1] like adding tyemaps for wxpoint and wxsize. Also, the different ways
> lists are represented. Some are indexable, some are iterators. There seem
> to be as many ways to represent a list as there are classes in pcbnew.
>
> [2] I am not a OOP fanboy; I hate how Java insists on a class for
> everything, but... I think it could make sense to "classify" the existing
> commands. Simple base class with empty methods for onleftclick,
> onrightclick, add to menu. Some of the switch statements in there, and the
> nested ifs, are scary. The code for the commands are so spread out. Also a
> big change, but I think it could be refactored in gradually. With such
> class based structure, exposing it in python would be easier.
>
> My

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

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

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

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

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

2017-11-24 Thread Maciej Sumiński 
Hi Miles,

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

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

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

Regards,
Orson

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




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

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

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

Cheers,

Wayne

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

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

2017-11-24 Thread miles mccoo 
in reply to Wayne's request to run the footprint wizard

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

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



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

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

Miles




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

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

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

2017-11-23 Thread Wayne Stambaugh 
On 11/23/2017 03:32 PM, miles mccoo wrote:
> Thanks all, for the replies
> 
> Thank you for merging my patch.
> 
> I'm pleased to read that the Kicad takes the python interface seriously.
> 
> Abstraction layer. I've considered writing one or at least submitting
> patches to move in that direction[1] but I got sidetracked trying to
> document what's already there. I will note that documenting the current
> python interface indirectly documents some of the c++ (which is also not
> the easiest to decipher) See this UML
> 
>  Many
> potential changes from the python viewpoint could be helpful on the c++
> side as well
> 
> SWIG work appears to be safe. It seems the can exist together. (the
> possibility of a one or the other situation was very real in my mind.)
> Most of Kicad's API do not involve wx types and the ones that do should
> be passed back and forth as tuples anyway.
> 
> 
> Tomasz: I will take a close look at your suggestions. In particular, the
> wxpoint, vector2 stuff is inline with what I mentioned above.
> 
> I've had other thoughts, like the ability to add commands implemented in
> python. This would involve the ability to add callbacks to onleftclick,
> onrightclick, add to menu... That's a big one though [2]
> 
> 
> Wayne: I did not try the scripts that come with kicad. I didn't try the
> footprint generator.

This is easy to test.  Open the footprint editor and click on the "New
Footprint using Footprint Wizard" button on the top toolbar.  This
wizard is a python script which is uses the wxPython UI code.  If this
works with phoenix, chances are pretty good that the rest of UI stuff
will as well.  Thank you for your efforts.  It would be nice to be ahead
of the curve instead of scrambling to keep up.

Cheers,

Wayne

> 
> I tried:
> gensvg
>  which
> generates as svg file from the layout of the currently loaded pcb.
> replicatelayout
> 
>  which
> replicates the placement of stuff based on sheet instances from the
> schematic. You place the devices of one instance of a sheet and the
> script moves the others to match. [3] I have a youtube demo
> here: https://youtu.be/m9LBR_q1Y0M
> neither uses anything in the GUI. The current version of replicate
> doesn't work, but with my patch that was just merged, I'll be able to
> push an update does work.
> 
> I did try binding mouse and other canvas events. It's not on my github,
> so I'm attaching it.
> 
> Not thorough in any way, but that it works at all felt like a success to me.
> 
> Miles
> 
> 
> 
> [1] like adding tyemaps for wxpoint and wxsize. Also, the different ways
> lists are represented. Some are indexable, some are iterators. There
> seem to be as many ways to represent a list as there are classes in pcbnew.
> 
> [2] I am not a OOP fanboy; I hate how Java insists on a class for
> everything, but... I think it could make sense to "classify" the
> existing commands. Simple base class with empty methods for onleftclick,
> onrightclick, add to menu. Some of the switch statements in there, and
> the nested ifs, are scary. The code for the commands are so spread out.
> Also a big change, but I think it could be refactored in gradually. With
> such class based structure, exposing it in python would be easier.
> 
> My experience in VLSI CAD is with a tool where the first implementation
> of any new command was done in TCL (yay, TCL). I didn't bother to use
> c++ unless there was a performance problem.
> 
> [3] this reminds me that I'd really like the ability to pass user
> defined properties from the schematic to the layout. eeschema already
> supports UDPs. If they could be saved in the netlist and then
> read/stored in pcbnew, that could be handy.
> 
> 
> On Thu, Nov 23, 2017 at 6:04 PM, Maciej Sumiński
> mailto:maciej.sumin...@cern.ch>> wrote:
> 
> Hi Miles,
> 
> On 11/23/2017 04:17 PM, miles mccoo wrote:
> > In a recent thread
> >  > on
> this list,
> > it was mentioned that kicad may need to drop support for SWIG/Python 
> due to
> > wx and wxPython limitations.
> >
> > Perhaps I misinterpreted what was said.
> > It's my perception that the kicad team doesn't see the value in a python
> > interface that I see
> >
> 
>  
> >.
> > Perhaps I'm wrong in that too
> 
> I might have not expressed myself clearly. I am aware of huge potential
> in scripting/plugin/extensions interfaces. Our problem is we do not
> provide a nic

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

2017-11-23 Thread Nick Østergaard 
I guess this is the same idea as with https://github.com/KiCad/kicad-python

2017-11-23 19:28 GMT+01:00 Greg Smith :

> "I was simply afraid that we
> may spent a lot of time petting the SWIG interface, which we will nuke
> it and start from scratch because of inevitable switch to Phoenix."
>
> I agree. I would suggest that the Python API is not quite stable enough to
> freeze the API. If we desire a stable interface/API, one could be written
> in Python itself. I am on the edge of implementing such an interface with
> KiCommand.
>
> KiCommand, in addition to being a command line interface, is a set of
> function calls that *could* be considered an API / Python class when
> complete.
>
> I have reviewed the Python API unit tests and found them to be lacking in
> coverage. I am duplicating those tests in KiCommand, and plan to extend the
> KiCommand tests, which could potentially be applied to the current Python
> API.
>
> If a stable API is desired, there should also be a set of unit tests
> verifying that functionality.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

2017-11-23 Thread Wayne Stambaugh 
On 11/23/2017 12:04 PM, Maciej Sumiński wrote:
> Hi Miles,
> 
> On 11/23/2017 04:17 PM, miles mccoo wrote:
>> In a recent thread
>>  on this list,
>> it was mentioned that kicad may need to drop support for SWIG/Python due to
>> wx and wxPython limitations.
>>
>> Perhaps I misinterpreted what was said.
>> It's my perception that the kicad team doesn't see the value in a python
>> interface that I see
>> .
>> Perhaps I'm wrong in that too
> 
> I might have not expressed myself clearly. I am aware of huge potential
> in scripting/plugin/extensions interfaces. Our problem is we do not
> provide a nice interface, we simply expose C++ guts. It means that the
> users get upset every time we modify a class they use. I do not write
> many Python scripts, but I worked with unstable APIs, so I can tell what
> kind of frustration they cause. We *need* an abstraction layer to keep
> both sides happy, so we can change the C++ methods and the users have
> Python interface they may rely on.
> 
> I never said we plan to drop Python support. I was simply afraid that we
> may spent a lot of time petting the SWIG interface, which we will nuke
> it and start from scratch because of inevitable switch to Phoenix. The
> only doubt I had is whether we can simply port our wxPython work to Phoenix.
> 
>> Anyway, I have a version of kicad working with wxPython 4.0 (AKA Phoenix)
>>
>> A more detailed summary can be read here on my blog
>> 
>> and
>> a diff file of my changes is here:
>> http://mmccoo.com/random/diffs_for_phoenix
> 
> This is very cool and appreciated, thank you! By reading your patch, I
> assume we can keep developing our SWIG files and at one point switch to
> Phoenix. If this is the case, then I think that work on a better Python
> interface using SWIG is very welcome, as it will be reused in the future.
> 
>> The short version: Kicad will probably want to wait to move to the Phoenix
>> version of wxPython.
> 
> True, I agree with Wayne - we need to wait until Phoenix is available in
> major Linux distros before we can even consider switching. Looking at
> your patch, I guess we could make KiCad compatible with both frameworks
> to assure smooth transition.

This would be a big win for the project if the python scripting code
could be ready to go when phoenix becomes widely available.  It would be
nice to be able to use python 3 instead of python 2.

> 
> Regards,
> Orson
> 
>> The main issue is that the Phoenix equivalent of wx/wxPython/wxPython.h
>> (called from pcbnew/swig/python_scripting.h) exists, but isn't in the
>> releases yet. See here
>> .
>>
>> Beyond that, I had some difficulties ensuring that the correct wx and
>> wxPython versions are installed and used[1]
>>
>> Once I did get it running, my kicad python scripts all work (save for the
>> things that broke since last time I updated kicad).
>>
>>
>>
>>
>>
>> Having said all that, I don't know that there is urgency to move to
>> Phoenix. AFAIK, wxPython 3.0 works fine with recent wxWidgets.
>>
>>
>> Hope it's helpful.
>> Miles
>>
>> PS - AFAIK, the patch that triggered mention of dumping python due to
>> wxPython still hasn't been denied or merged. :-)
>> https://lists.launchpad.net/kicad-developers/msg31700.html
>>
>>
>>
>>
>>
>> [1] on ubuntu, unstalling wxwidget package didn't remove the wxwidgets
>> libraries. It's quite possible that I was just confused and/or doing it
>> wrong.
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

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

2017-11-23 Thread Carsten Schoenert 
Am 23.11.2017 um 17:28 schrieb Wayne Stambaugh:
...
>> The short version: Kicad will probably want to wait to move to the
>> Phoenix version of wxPython.
> 
> Not until they are package in Debian stable.  This is my litmus test for
> availability of new dependencies.  I do not want kicad to be in the
> business of building dependencies.  We have already traveled down that
> road and it was not a fun journey.

Right now nobody has intended to do the packaging work for this new
version / fork.
If someone wants to step in I'm happily will helping to forward contacts
to the wxWidget maintainers.

https://qa.debian.org/developer.php?email=freewx-maint%40lists.alioth.debian.org

Or at least a packaging request (RFP) should someone file to show up
there is a interest for getting the package into the archive.

-- 
Regards
Carsten Schoenert

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

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

2017-11-23 Thread miles mccoo 
Thanks all, for the replies

Thank you for merging my patch.

I'm pleased to read that the Kicad takes the python interface seriously.

Abstraction layer. I've considered writing one or at least submitting
patches to move in that direction[1] but I got sidetracked trying to
document what's already there. I will note that documenting the current
python interface indirectly documents some of the c++ (which is also not
the easiest to decipher) See this UML

Many
potential changes from the python viewpoint could be helpful on the c++
side as well

SWIG work appears to be safe. It seems the can exist together. (the
possibility of a one or the other situation was very real in my mind.) Most
of Kicad's API do not involve wx types and the ones that do should be
passed back and forth as tuples anyway.


Tomasz: I will take a close look at your suggestions. In particular, the
wxpoint, vector2 stuff is inline with what I mentioned above.

I've had other thoughts, like the ability to add commands implemented in
python. This would involve the ability to add callbacks to onleftclick,
onrightclick, add to menu... That's a big one though [2]


Wayne: I did not try the scripts that come with kicad. I didn't try the
footprint generator.

I tried:
gensvg 
which
generates as svg file from the layout of the currently loaded pcb.
replicatelayout

which
replicates the placement of stuff based on sheet instances from the
schematic. You place the devices of one instance of a sheet and the script
moves the others to match. [3] I have a youtube demo here:
https://youtu.be/m9LBR_q1Y0M
neither uses anything in the GUI. The current version of replicate doesn't
work, but with my patch that was just merged, I'll be able to push an
update does work.

I did try binding mouse and other canvas events. It's not on my github, so
I'm attaching it.

Not thorough in any way, but that it works at all felt like a success to me.

Miles



[1] like adding tyemaps for wxpoint and wxsize. Also, the different ways
lists are represented. Some are indexable, some are iterators. There seem
to be as many ways to represent a list as there are classes in pcbnew.

[2] I am not a OOP fanboy; I hate how Java insists on a class for
everything, but... I think it could make sense to "classify" the existing
commands. Simple base class with empty methods for onleftclick,
onrightclick, add to menu. Some of the switch statements in there, and the
nested ifs, are scary. The code for the commands are so spread out. Also a
big change, but I think it could be refactored in gradually. With such
class based structure, exposing it in python would be easier.

My experience in VLSI CAD is with a tool where the first implementation of
any new command was done in TCL (yay, TCL). I didn't bother to use c++
unless there was a performance problem.

[3] this reminds me that I'd really like the ability to pass user defined
properties from the schematic to the layout. eeschema already supports
UDPs. If they could be saved in the netlist and then read/stored in pcbnew,
that could be handy.


On Thu, Nov 23, 2017 at 6:04 PM, Maciej Sumiński 
wrote:

> Hi Miles,
>
> On 11/23/2017 04:17 PM, miles mccoo wrote:
> > In a recent thread
> >  on this
> list,
> > it was mentioned that kicad may need to drop support for SWIG/Python due
> to
> > wx and wxPython limitations.
> >
> > Perhaps I misinterpreted what was said.
> > It's my perception that the kicad team doesn't see the value in a python
> > interface that I see
> >  most-important-feature-a-tool-can-have/>.
> > Perhaps I'm wrong in that too
>
> I might have not expressed myself clearly. I am aware of huge potential
> in scripting/plugin/extensions interfaces. Our problem is we do not
> provide a nice interface, we simply expose C++ guts. It means that the
> users get upset every time we modify a class they use. I do not write
> many Python scripts, but I worked with unstable APIs, so I can tell what
> kind of frustration they cause. We *need* an abstraction layer to keep
> both sides happy, so we can change the C++ methods and the users have
> Python interface they may rely on.
>
> I never said we plan to drop Python support. I was simply afraid that we
> may spent a lot of time petting the SWIG interface, which we will nuke
> it and start from scratch because of inevitable switch to Phoenix. The
> only doubt I had is whether we can simply port our wxPython work to
> Phoenix.
>
> > Anyway, I have a version of kicad working with wxPython 4.0 (AKA Phoenix)
> >
> > A more detailed summary can be read here on my blog
> >  moving-kicad-t

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

2017-11-23 Thread Greg Smith 
"I was simply afraid that we
may spent a lot of time petting the SWIG interface, which we will nuke
it and start from scratch because of inevitable switch to Phoenix."

I agree. I would suggest that the Python API is not quite stable enough to 
freeze the API. If we desire a stable interface/API, one could be written in 
Python itself. I am on the edge of implementing such an interface with 
KiCommand.

KiCommand, in addition to being a command line interface, is a set of function 
calls that *could* be considered an API / Python class when complete.

I have reviewed the Python API unit tests and found them to be lacking in 
coverage. I am duplicating those tests in KiCommand, and plan to extend the 
KiCommand tests, which could potentially be applied to the current Python API.

If a stable API is desired, there should also be a set of unit tests verifying 
that functionality.

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

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

2017-11-23 Thread Maciej Sumiński 
Hi Miles,

On 11/23/2017 04:17 PM, miles mccoo wrote:
> In a recent thread
>  on this list,
> it was mentioned that kicad may need to drop support for SWIG/Python due to
> wx and wxPython limitations.
> 
> Perhaps I misinterpreted what was said.
> It's my perception that the kicad team doesn't see the value in a python
> interface that I see
> .
> Perhaps I'm wrong in that too

I might have not expressed myself clearly. I am aware of huge potential
in scripting/plugin/extensions interfaces. Our problem is we do not
provide a nice interface, we simply expose C++ guts. It means that the
users get upset every time we modify a class they use. I do not write
many Python scripts, but I worked with unstable APIs, so I can tell what
kind of frustration they cause. We *need* an abstraction layer to keep
both sides happy, so we can change the C++ methods and the users have
Python interface they may rely on.

I never said we plan to drop Python support. I was simply afraid that we
may spent a lot of time petting the SWIG interface, which we will nuke
it and start from scratch because of inevitable switch to Phoenix. The
only doubt I had is whether we can simply port our wxPython work to Phoenix.

> Anyway, I have a version of kicad working with wxPython 4.0 (AKA Phoenix)
> 
> A more detailed summary can be read here on my blog
> 
> and
> a diff file of my changes is here:
> http://mmccoo.com/random/diffs_for_phoenix

This is very cool and appreciated, thank you! By reading your patch, I
assume we can keep developing our SWIG files and at one point switch to
Phoenix. If this is the case, then I think that work on a better Python
interface using SWIG is very welcome, as it will be reused in the future.

> The short version: Kicad will probably want to wait to move to the Phoenix
> version of wxPython.

True, I agree with Wayne - we need to wait until Phoenix is available in
major Linux distros before we can even consider switching. Looking at
your patch, I guess we could make KiCad compatible with both frameworks
to assure smooth transition.

Regards,
Orson

> The main issue is that the Phoenix equivalent of wx/wxPython/wxPython.h
> (called from pcbnew/swig/python_scripting.h) exists, but isn't in the
> releases yet. See here
> .
> 
> Beyond that, I had some difficulties ensuring that the correct wx and
> wxPython versions are installed and used[1]
> 
> Once I did get it running, my kicad python scripts all work (save for the
> things that broke since last time I updated kicad).
> 
> 
> 
> 
> 
> Having said all that, I don't know that there is urgency to move to
> Phoenix. AFAIK, wxPython 3.0 works fine with recent wxWidgets.
> 
> 
> Hope it's helpful.
> Miles
> 
> PS - AFAIK, the patch that triggered mention of dumping python due to
> wxPython still hasn't been denied or merged. :-)
> https://lists.launchpad.net/kicad-developers/msg31700.html
> 
> 
> 
> 
> 
> [1] on ubuntu, unstalling wxwidget package didn't remove the wxwidgets
> libraries. It's quite possible that I was just confused and/or doing it
> wrong.
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

2017-11-23 Thread Tomasz Wlostowski 
On 23/11/17 16:17, miles mccoo wrote:
> 
> PS - AFAIK, the patch that triggered mention of dumping python due to
> wxPython still hasn't been denied or merged. :-)
> https://lists.launchpad.net/kicad-developers/msg31700.html
> 
> 
Hi Miles,

I just committed your patch. Thanks for your contribution to Kicad.

Now, if you want to improve Kicad scripting support (and I guess you do
;-), there's a bunch of tasks to do right away:

- glue between wxPoint and VECTOR2I and swigging out SHAPE_POLY_SET, SEG
and VECTOR2<> classes (see
https://bugs.launchpad.net/kicad/+bug/1728611). In the longer term, we
plan to use
VECTOR2Is in non-GUI related code, but until the legacy canvas is
factored out we must live with both types mixed.

- expose GAL SELECTION/SELECTION_TOOL through a simple python interface,
e.g:

pcbnew.SelectItems( [ item/list of items ] )
pcbnew.UnselectItems( [ item/list of items ] )
pcbnew.GetSelection()
pcbnew.ClearSelection()

- expose COMMIT/BOARD_COMMIT classes to enable undo & view updates (as
requested by other Python devs on the Kicad Forum):

# modification of a via diameter and adding a track. "via" comes from
the existing BOARD object, track is a new item created by the script
commit = pcbnew.COMMIT()
# inform PCBnew that we're going to modify the via object
commit.Modify(via)
via.SetDiameter()
track = TRACK()
track.SetStart(...)
track.SetEnd(...)
# add a new item (track) to the commit
commit.Add(track)
# push the commit - this will update the board view, connectivity
(ratsnest), commit changes to the BOARD object and create an entry in
the undo buffer
commit.Push("Change a via and add a new track")


- add simple calls to enable/disable visible layers/items
(https://bugs.launchpad.net/kicad/+bug/1712233,
https://lists.launchpad.net/kicad-developers/msg30372.html)

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

2017-11-23 Thread Wayne Stambaugh 
On 11/23/2017 10:17 AM, miles mccoo wrote:
> 
> In a recent thread
>  on this
> list, it was mentioned that kicad may need to drop support for
> SWIG/Python due to wx and wxPython limitations.
> 
> Perhaps I misinterpreted what was said.
> It's my perception that the kicad team doesn't see the value in a python
> interface that I see
> .
> Perhaps I'm wrong in that too

We have no intention of removing python support.  The issue becomes is
will we have the manpower to convert over to Phoenix or will we keep the
current wxpython implementation.

> 
> Anyway, I have a version of kicad working with wxPython 4.0 (AKA Phoenix)
> 
> A more detailed summary can be read here on my blog
> 
>  and
> a diff file of my changes is
> here: http://mmccoo.com/random/diffs_for_phoenix
> 
> 
> The short version: Kicad will probably want to wait to move to the
> Phoenix version of wxPython.

Not until they are package in Debian stable.  This is my litmus test for
availability of new dependencies.  I do not want kicad to be in the
business of building dependencies.  We have already traveled down that
road and it was not a fun journey.

> 
> The main issue is that the Phoenix equivalent of wx/wxPython/wxPython.h
> (called from pcbnew/swig/python_scripting.h) exists, but isn't in the
> releases yet. See here
> .
> 
> Beyond that, I had some difficulties ensuring that the correct wx and
> wxPython versions are installed and used[1]
> 
> Once I did get it running, my kicad python scripts all work (save for
> the things that broke since last time I updated kicad). 

Do you scripts involve accessing the pcb in the current session of
pcbnew or include running the UI based python scripts (footprint
generator) included with Kicad?  I'm guessing phoenix will have no
effect on non-UI scripts.  If phoenix is working already with UI code,
then perhaps the switch will not be such an issue.

> 
> 
> 
> 
> 
> Having said all that, I don't know that there is urgency to move to
> Phoenix. AFAIK, wxPython 3.0 works fine with recent wxWidgets.
> 
> 
> Hope it's helpful.
> Miles
> 
> PS - AFAIK, the patch that triggered mention of dumping python due to
> wxPython still hasn't been denied or merged. :-)
> https://lists.launchpad.net/kicad-developers/msg31700.html
> 
> 
> 
> 
> 
> [1] on ubuntu, unstalling wxwidget package didn't remove the wxwidgets
> libraries. It's quite possible that I was just confused and/or doing it
> wrong. 
> 
> 
> 
> 
> ___
> 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] Getting kicad to work with wxPython Phoenix

2017-11-23 Thread miles mccoo 
In a recent thread
 on this list,
it was mentioned that kicad may need to drop support for SWIG/Python due to
wx and wxPython limitations.

Perhaps I misinterpreted what was said.
It's my perception that the kicad team doesn't see the value in a python
interface that I see
.
Perhaps I'm wrong in that too

Anyway, I have a version of kicad working with wxPython 4.0 (AKA Phoenix)

A more detailed summary can be read here on my blog

and
a diff file of my changes is here:
http://mmccoo.com/random/diffs_for_phoenix


The short version: Kicad will probably want to wait to move to the Phoenix
version of wxPython.

The main issue is that the Phoenix equivalent of wx/wxPython/wxPython.h
(called from pcbnew/swig/python_scripting.h) exists, but isn't in the
releases yet. See here
.

Beyond that, I had some difficulties ensuring that the correct wx and
wxPython versions are installed and used[1]

Once I did get it running, my kicad python scripts all work (save for the
things that broke since last time I updated kicad).





Having said all that, I don't know that there is urgency to move to
Phoenix. AFAIK, wxPython 3.0 works fine with recent wxWidgets.


Hope it's helpful.
Miles

PS - AFAIK, the patch that triggered mention of dumping python due to
wxPython still hasn't been denied or merged. :-)
https://lists.launchpad.net/kicad-developers/msg31700.html





[1] on ubuntu, unstalling wxwidget package didn't remove the wxwidgets
libraries. It's quite possible that I was just confused and/or doing it
wrong.
___
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