Re: [Kicad-developers] A few run-time problems on kicad-git build on Slackware64-current Linux
Your issues in (1) are by design. Whether that design is correct or not is another story. I actually removed that behavior on Windows because Microsoft has a stable api to determine top level window for focus. Linux does not and GDK used to be but with the fragmented x11/wayland mess, they removed the api call support to determine top level window. And removing the focus calls instead are going to lead a rabbit hole of things not working like hotkeys. On Thu, Nov 5, 2020 at 9:14 PM Tom Crane wrote: > On Thu, 5 Nov 2020, Nick Østergaard wrote: > > Thanks again for the quick follow-up. > > > Did you install wxpython (phoenix) with pip? > No. > > > you have some python stuff in ~/.local. > > I have uploaded the modified SlackBuild scripts I used to build both the > Slackware wxGTK3 package (wxWidgets/Phoenix) and the wxPython4 package at > https://www.mklab.rhul.ac.uk/~tom/kicad/SlackBuild/ in case the problem > lies with either. > > > > > Maybe just try to clear that out completely, or explicitly > set PYTHONPATH to the site-packages path of your install location? > > Just tried removing ~/.local and then, > > export PYTHONPATH=/usr/lib64/python3.8/site-packages/ > > In both cases the scripting console error remains the same. > > Thanks > Tom. > > > > > > On Thu, 5 Nov 2020 at 20:51, Tom Crane > wrote: > > Thanks for the quick response. In the past I have been bitten by > old > > libraries in non-standard places derailing other application > builds but > > can't see anything obviously amiss here. > > > > My $LD_LIBRARY_PATH EV is empty. I checked where ldconfig looks > and could > > not see anything incriminating outside the standard install > locations for > > Slackware distros (/usr/lib64 & /lib64). See > > https://www.mklab.rhul.ac.uk/~tom/kicad/ldconfig-p.txt for the > O/P of > > 'ldconfig -p'. > > > > I also tried stracing open* calls in pcbnew. See > > https://www.mklab.rhul.ac.uk/~tom/kicad/strace-pcbnew2.lis. > Again nothing > > jumped out as problematic. All calls to Python related files seem > to > > reference python v.3.8 ones as expected. > > > > The build scripts I am using are release version 'SlackBuild' > scripts I've > > hacked to use the git development code. See > > https://www.mklab.rhul.ac.uk/~tom/kicad/SlackBuild/. The > tom_build.sh > > script calls the main build script kicad-git.SlackBuild. > > > > Thanks > > Tom > > > > On Thu, 5 Nov 2020, Nick Østergaard wrote: > > > > > Are you using a build script? If so please link it. > > > Also check if you partially installed in multiple locations, > sucha as where ldconfig looks and echo LD_LIBRARY_PATH from your runtime > env. > > > > > > Nicl > > > > > > tor. 5. nov. 2020 16.26 skrev Tom Crane < > tpcki...@mklab.ph.rhul.ac.uk>: > > > I have been using recent builds for the past few weeks. > They are usable > > > but I have a couple of outstanding problems which I'm not > sure how to > > > diagnose/fix. > > > > > > (1) I have strange behaviours with open Kicad application > windows. For > > > example I have a Kicad project, eeschema and pcbnew > windows open on a > > > single display. If I let the mouse pointer move from the > project window to > > > the eeschema or pcbnew window then input focus immediately > transfers to > > > the eeschema or pcbnew window. This is without touching > any mouse > > > buttons. > > > > > > Similarly moving the mouse pointer back to the project > window has no > > > effect (as it should) but moving it between the eeschema > and pcbnew > > > windows transfers input focus as soon as it enters the > other window. > > > > > > There is a similar effect when moving between unrelated > (eg. an xterm) > > > windows and either eeschema or pcbnew. Here the eeschema > or pcbnew window > > > does not receive input focus (which remains with the xterm > as it should) > > > but the eeschema or pcbnew window does move up the window > 'stack'. eg. if > > > I have an eeschema windows partially covered by a pcbnew > window, partially > > > covered by an xterm window which has input focus, then > moving the mouse > > > pointer from the xterm to an uncovered section of the > eeschema window will > > > cause it to move up the stack and fully cover the pcbnew > window. > > > > > > I get this behaviour with both accelerated and standard > graphics set. > > > > > > The above behaviours were observed with the KDE desktop. > I get similar > > > behaviour with my usual window manager (fvwm95) except > that the window > > > focus never switches. > > > > >
Re: [Kicad-developers] Torrent downloads
Hi Nick, Is there anything else I can help with here? I see 5.1.8 update is released already. On Thu, Oct 1, 2020 at 3:48 AM Andrew Lutsenko wrote: > Oh, I did verify that, sorry I wasn't clear. It definitely works. > > On Thu, Oct 1, 2020, 02:00 Nick Østergaard wrote: > >> I was implicitly hoping you could explicitly verify for me that using the >> OSDN url would support range requests. :) >> >> tor. 1. okt. 2020 09.09 skrev Andrew Lutsenko : >> >>> Yes, it does. I think it will work with any http server supporting range >>> requests. >>> You can have multiple webseed urls in the torrent as well, just pass >>> --urlList flag multiple times. >>> >>> On Wed, Sep 30, 2020 at 11:28 PM Nick Østergaard >>> wrote: >>> Does it also work with the OSDN mirror? tor. 1. okt. 2020 02.42 skrev Andrew Lutsenko : > Hi all, > > I recall we had this discussion before about providing torrent files > for release downloads to reduce the slowdown related to rush traffic. it > didn't go far mainly because of resources needed to maintain separate > torrent seeding infrastructure. > > I recently discovered that p2p torrent protocol supports webseeding, a > feature that allows torrent clients to download chunks of files from > standard http/ftp servers. It's implemented by most major torrent client > software. This way the file is initially seeded by the http server but as > more and more peers get the data the swarm takes over most of the traffic > load. > > I tried it out and it works nicely with kicad's existing http download > resources so there is no need to have separate infra for torrents! > > Would you be open to adding this? > All that is needed is put .torrent files either on kicad website or > even better, on the https://kicad-downloads.s3.cern.ch/ server next > to the installers and add a link to them. > > I've generated torrents with webseed information for 5.1.7 here: > https://forum.kicad.info/t/torrents-for-kicad-stable-version-5-1-7-win-and-osx/16609/14?u=qu1ck > > To do it yourself in the future is trivial, here is the bash script I > used to create the files: > > for f in *.exe ; do > create-torrent "$f" -o $f.torrent --urlList > https://kicad-downloads.s3.cern.ch/windows/stable/ > done > for f in *.dmg ; do > create-torrent "$f" -o $f.torrent --urlList > https://kicad-downloads.s3.cern.ch/osx/stable/ > done > > It depends on create-torrent utility that you can get by running "npm > install -g create-torrent" > > I can also make a merge request on the kicad website if someone will > upload the torrent files to the s3 server. > > Regards, > Andrew > ___ > 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] A few run-time problems on kicad-git build on Slackware64-current Linux
On Thu, 5 Nov 2020, Nick Østergaard wrote: Thanks again for the quick follow-up. Did you install wxpython (phoenix) with pip? No. you have some python stuff in ~/.local. I have uploaded the modified SlackBuild scripts I used to build both the Slackware wxGTK3 package (wxWidgets/Phoenix) and the wxPython4 package at https://www.mklab.rhul.ac.uk/~tom/kicad/SlackBuild/ in case the problem lies with either. Maybe just try to clear that out completely, or explicitly set PYTHONPATH to the site-packages path of your install location? Just tried removing ~/.local and then, export PYTHONPATH=/usr/lib64/python3.8/site-packages/ In both cases the scripting console error remains the same. Thanks Tom. On Thu, 5 Nov 2020 at 20:51, Tom Crane wrote: Thanks for the quick response. In the past I have been bitten by old libraries in non-standard places derailing other application builds but can't see anything obviously amiss here. My $LD_LIBRARY_PATH EV is empty. I checked where ldconfig looks and could not see anything incriminating outside the standard install locations for Slackware distros (/usr/lib64 & /lib64). See https://www.mklab.rhul.ac.uk/~tom/kicad/ldconfig-p.txt for the O/P of 'ldconfig -p'. I also tried stracing open* calls in pcbnew. See https://www.mklab.rhul.ac.uk/~tom/kicad/strace-pcbnew2.lis. Again nothing jumped out as problematic. All calls to Python related files seem to reference python v.3.8 ones as expected. The build scripts I am using are release version 'SlackBuild' scripts I've hacked to use the git development code. See https://www.mklab.rhul.ac.uk/~tom/kicad/SlackBuild/. The tom_build.sh script calls the main build script kicad-git.SlackBuild. Thanks Tom On Thu, 5 Nov 2020, Nick Østergaard wrote: > Are you using a build script? If so please link it. > Also check if you partially installed in multiple locations, sucha as where ldconfig looks and echo LD_LIBRARY_PATH from your runtime env. > > Nicl > > tor. 5. nov. 2020 16.26 skrev Tom Crane : > I have been using recent builds for the past few weeks. They are usable > but I have a couple of outstanding problems which I'm not sure how to > diagnose/fix. > > (1) I have strange behaviours with open Kicad application windows. For > example I have a Kicad project, eeschema and pcbnew windows open on a > single display. If I let the mouse pointer move from the project window to > the eeschema or pcbnew window then input focus immediately transfers to > the eeschema or pcbnew window. This is without touching any mouse > buttons. > > Similarly moving the mouse pointer back to the project window has no > effect (as it should) but moving it between the eeschema and pcbnew > windows transfers input focus as soon as it enters the other window. > > There is a similar effect when moving between unrelated (eg. an xterm) > windows and either eeschema or pcbnew. Here the eeschema or pcbnew window > does not receive input focus (which remains with the xterm as it should) > but the eeschema or pcbnew window does move up the window 'stack'. eg. if > I have an eeschema windows partially covered by a pcbnew window, partially > covered by an xterm window which has input focus, then moving the mouse > pointer from the xterm to an uncovered section of the eeschema window will > cause it to move up the stack and fully cover the pcbnew window. > > I get this behaviour with both accelerated and standard graphics set. > > The above behaviours were observed with the KDE desktop. I get similar > behaviour with my usual window manager (fvwm95) except that the window > focus never switches. > > I also find that when invoking the DRC check that the DRC Control Window > disappears immediately after popping-up and has to be 're-acquired' by > clicking the pcbnew tab on the fvwm95 taskbar. I suspect this is another > facet of these window problems. > > I don't get this behaviour with any other applications but Kicad is the > only wxWidgets/wxPython based one I currently use and so the problem could > there at the library level rather than within Kicad on my > distro/Kicad+dependencies build. > > None of this is a show-stopper but it is irritating. > > Any ideas? > > > (2) I am unable to use any Kicad scripts. Clicking on pcbnew --> Tools > --> scripting console I get the
Re: [Kicad-developers] A few run-time problems on kicad-git build on Slackware64-current Linux
Did you install wxpython (phoenix) with pip? you have some python stuff in ~/.local. Maybe just try to clear that out completely, or explicitly set PYTHONPATH to the site-packages path of your install location? On Thu, 5 Nov 2020 at 20:51, Tom Crane wrote: > Thanks for the quick response. In the past I have been bitten by old > libraries in non-standard places derailing other application builds but > can't see anything obviously amiss here. > > My $LD_LIBRARY_PATH EV is empty. I checked where ldconfig looks and could > not see anything incriminating outside the standard install locations for > Slackware distros (/usr/lib64 & /lib64). See > https://www.mklab.rhul.ac.uk/~tom/kicad/ldconfig-p.txt for the O/P of > 'ldconfig -p'. > > I also tried stracing open* calls in pcbnew. See > https://www.mklab.rhul.ac.uk/~tom/kicad/strace-pcbnew2.lis. Again > nothing > jumped out as problematic. All calls to Python related files seem to > reference python v.3.8 ones as expected. > > The build scripts I am using are release version 'SlackBuild' scripts I've > hacked to use the git development code. See > https://www.mklab.rhul.ac.uk/~tom/kicad/SlackBuild/. The tom_build.sh > script calls the main build script kicad-git.SlackBuild. > > Thanks > Tom > > On Thu, 5 Nov 2020, Nick Østergaard wrote: > > > Are you using a build script? If so please link it. > > Also check if you partially installed in multiple locations, sucha as > where ldconfig looks and echo LD_LIBRARY_PATH from your runtime env. > > > > Nicl > > > > tor. 5. nov. 2020 16.26 skrev Tom Crane : > > I have been using recent builds for the past few weeks. They are > usable > > but I have a couple of outstanding problems which I'm not sure how > to > > diagnose/fix. > > > > (1) I have strange behaviours with open Kicad application windows. > For > > example I have a Kicad project, eeschema and pcbnew windows open > on a > > single display. If I let the mouse pointer move from the project > window to > > the eeschema or pcbnew window then input focus immediately > transfers to > > the eeschema or pcbnew window. This is without touching any mouse > > buttons. > > > > Similarly moving the mouse pointer back to the project window has > no > > effect (as it should) but moving it between the eeschema and pcbnew > > windows transfers input focus as soon as it enters the other > window. > > > > There is a similar effect when moving between unrelated (eg. an > xterm) > > windows and either eeschema or pcbnew. Here the eeschema or > pcbnew window > > does not receive input focus (which remains with the xterm as it > should) > > but the eeschema or pcbnew window does move up the window > 'stack'. eg. if > > I have an eeschema windows partially covered by a pcbnew window, > partially > > covered by an xterm window which has input focus, then moving the > mouse > > pointer from the xterm to an uncovered section of the eeschema > window will > > cause it to move up the stack and fully cover the pcbnew window. > > > > I get this behaviour with both accelerated and standard graphics > set. > > > > The above behaviours were observed with the KDE desktop. I get > similar > > behaviour with my usual window manager (fvwm95) except that the > window > > focus never switches. > > > > I also find that when invoking the DRC check that the DRC Control > Window > > disappears immediately after popping-up and has to be > 're-acquired' by > > clicking the pcbnew tab on the fvwm95 taskbar. I suspect this is > another > > facet of these window problems. > > > > I don't get this behaviour with any other applications but Kicad > is the > > only wxWidgets/wxPython based one I currently use and so the > problem could > > there at the library level rather than within Kicad on my > > distro/Kicad+dependencies build. > > > > None of this is a show-stopper but it is irritating. > > > > Any ideas? > > > > > > (2) I am unable to use any Kicad scripts. Clicking on pcbnew --> > Tools > > --> scripting console I get the "Error: unable to create Python > Console" > > pop-up and the following on the console, > > > > Traceback (most recent call last): > > File "", line 1, in > > File "/usr/share/kicad/scripting/kicad_pyshell/__init__.py", > line 17, in > > > >import wx > > File "/usr/lib64/python3.8/site-packages/wx/__init__.py", line > 12, in > > > >__version__ = wx.__version__.VERSION_STRING > > AttributeError: partially initialized module 'wx' has no attribute > > '__version__' (most likely due to a circular import) > > > > > > I built kicad with Python3 support (see below) so it should be > using that > > and not Python2 (for which I don't have a wxWidgets build) but I >
Re: [Kicad-developers] A few run-time problems on kicad-git build on Slackware64-current Linux
Thanks for the quick response. In the past I have been bitten by old libraries in non-standard places derailing other application builds but can't see anything obviously amiss here. My $LD_LIBRARY_PATH EV is empty. I checked where ldconfig looks and could not see anything incriminating outside the standard install locations for Slackware distros (/usr/lib64 & /lib64). See https://www.mklab.rhul.ac.uk/~tom/kicad/ldconfig-p.txt for the O/P of 'ldconfig -p'. I also tried stracing open* calls in pcbnew. See https://www.mklab.rhul.ac.uk/~tom/kicad/strace-pcbnew2.lis. Again nothing jumped out as problematic. All calls to Python related files seem to reference python v.3.8 ones as expected. The build scripts I am using are release version 'SlackBuild' scripts I've hacked to use the git development code. See https://www.mklab.rhul.ac.uk/~tom/kicad/SlackBuild/. The tom_build.sh script calls the main build script kicad-git.SlackBuild. Thanks Tom On Thu, 5 Nov 2020, Nick Østergaard wrote: Are you using a build script? If so please link it. Also check if you partially installed in multiple locations, sucha as where ldconfig looks and echo LD_LIBRARY_PATH from your runtime env. Nicl tor. 5. nov. 2020 16.26 skrev Tom Crane : I have been using recent builds for the past few weeks. They are usable but I have a couple of outstanding problems which I'm not sure how to diagnose/fix. (1) I have strange behaviours with open Kicad application windows. For example I have a Kicad project, eeschema and pcbnew windows open on a single display. If I let the mouse pointer move from the project window to the eeschema or pcbnew window then input focus immediately transfers to the eeschema or pcbnew window. This is without touching any mouse buttons. Similarly moving the mouse pointer back to the project window has no effect (as it should) but moving it between the eeschema and pcbnew windows transfers input focus as soon as it enters the other window. There is a similar effect when moving between unrelated (eg. an xterm) windows and either eeschema or pcbnew. Here the eeschema or pcbnew window does not receive input focus (which remains with the xterm as it should) but the eeschema or pcbnew window does move up the window 'stack'. eg. if I have an eeschema windows partially covered by a pcbnew window, partially covered by an xterm window which has input focus, then moving the mouse pointer from the xterm to an uncovered section of the eeschema window will cause it to move up the stack and fully cover the pcbnew window. I get this behaviour with both accelerated and standard graphics set. The above behaviours were observed with the KDE desktop. I get similar behaviour with my usual window manager (fvwm95) except that the window focus never switches. I also find that when invoking the DRC check that the DRC Control Window disappears immediately after popping-up and has to be 're-acquired' by clicking the pcbnew tab on the fvwm95 taskbar. I suspect this is another facet of these window problems. I don't get this behaviour with any other applications but Kicad is the only wxWidgets/wxPython based one I currently use and so the problem could there at the library level rather than within Kicad on my distro/Kicad+dependencies build. None of this is a show-stopper but it is irritating. Any ideas? (2) I am unable to use any Kicad scripts. Clicking on pcbnew --> Tools --> scripting console I get the "Error: unable to create Python Console" pop-up and the following on the console, Traceback (most recent call last): File "", line 1, in File "/usr/share/kicad/scripting/kicad_pyshell/__init__.py", line 17, in import wx File "/usr/lib64/python3.8/site-packages/wx/__init__.py", line 12, in __version__ = wx.__version__.VERSION_STRING AttributeError: partially initialized module 'wx' has no attribute '__version__' (most likely due to a circular import) I built kicad with Python3 support (see below) so it should be using that and not Python2 (for which I don't have a wxWidgets build) but I suspect it might still be calling Python2. Any ideas? Many thanks Tom Crane Build details: Application: KiCad Version: (5.99.0-6755-g3b10d1583), release build Libraries: wxWidgets 3.1.4 libcurl/7.70.0 OpenSSL/1.1.1h zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0 Platform: Linux 5.4.6-mklab x86_64, 64 bit, Little endian, wxGTK, , Build Info: Date: Nov 2 2020 16:07:07 wxWidgets: 3.1.4 (wchar_t,wx containers) GTK+ 3.24 Boost:
Re: [Kicad-developers] A few run-time problems on kicad-git build on Slackware64-current Linux
Are you using a build script? If so please link it. Also check if you partially installed in multiple locations, sucha as where ldconfig looks and echo LD_LIBRARY_PATH from your runtime env. Nicl tor. 5. nov. 2020 16.26 skrev Tom Crane : > I have been using recent builds for the past few weeks. They are usable > but I have a couple of outstanding problems which I'm not sure how to > diagnose/fix. > > (1) I have strange behaviours with open Kicad application windows. For > example I have a Kicad project, eeschema and pcbnew windows open on a > single display. If I let the mouse pointer move from the project window to > the eeschema or pcbnew window then input focus immediately transfers to > the eeschema or pcbnew window. This is without touching any mouse > buttons. > > Similarly moving the mouse pointer back to the project window has no > effect (as it should) but moving it between the eeschema and pcbnew > windows transfers input focus as soon as it enters the other window. > > There is a similar effect when moving between unrelated (eg. an xterm) > windows and either eeschema or pcbnew. Here the eeschema or pcbnew window > does not receive input focus (which remains with the xterm as it should) > but the eeschema or pcbnew window does move up the window 'stack'. eg. if > I have an eeschema windows partially covered by a pcbnew window, partially > covered by an xterm window which has input focus, then moving the mouse > pointer from the xterm to an uncovered section of the eeschema window will > cause it to move up the stack and fully cover the pcbnew window. > > I get this behaviour with both accelerated and standard graphics set. > > The above behaviours were observed with the KDE desktop. I get similar > behaviour with my usual window manager (fvwm95) except that the window > focus never switches. > > I also find that when invoking the DRC check that the DRC Control Window > disappears immediately after popping-up and has to be 're-acquired' by > clicking the pcbnew tab on the fvwm95 taskbar. I suspect this is another > facet of these window problems. > > I don't get this behaviour with any other applications but Kicad is the > only wxWidgets/wxPython based one I currently use and so the problem could > there at the library level rather than within Kicad on my > distro/Kicad+dependencies build. > > None of this is a show-stopper but it is irritating. > > Any ideas? > > > (2) I am unable to use any Kicad scripts. Clicking on pcbnew --> Tools > --> scripting console I get the "Error: unable to create Python Console" > pop-up and the following on the console, > > Traceback (most recent call last): >File "", line 1, in >File "/usr/share/kicad/scripting/kicad_pyshell/__init__.py", line 17, > in > > import wx >File "/usr/lib64/python3.8/site-packages/wx/__init__.py", line 12, in > > __version__ = wx.__version__.VERSION_STRING > AttributeError: partially initialized module 'wx' has no attribute > '__version__' (most likely due to a circular import) > > > I built kicad with Python3 support (see below) so it should be using that > and not Python2 (for which I don't have a wxWidgets build) but I suspect > it might still be calling Python2. > > Any ideas? > > Many thanks > Tom Crane > > Build details: > > Application: KiCad > Version: (5.99.0-6755-g3b10d1583), release build > Libraries: > wxWidgets 3.1.4 > libcurl/7.70.0 OpenSSL/1.1.1h zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 > libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0 > Platform: Linux 5.4.6-mklab x86_64, 64 bit, Little endian, wxGTK, , > Build Info: > Date: Nov 2 2020 16:07:07 > wxWidgets: 3.1.4 (wchar_t,wx containers) GTK+ 3.24 > Boost: 1.74.0 > OCE: 6.9.1 > Curl: 7.72.0 > ngspice: 30 > Compiler: GCC 9.3.0 with C++ ABI 1013 > Build settings: > KICAD_SCRIPTING=ON > KICAD_SCRIPTING_MODULES=ON > KICAD_SCRIPTING_PYTHON3=ON > KICAD_SCRIPTING_WXPYTHON=ON > KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON > KICAD_SCRIPTING_ACTION_MENU=ON > KICAD_USE_OCE=ON > KICAD_SPICE=ON > > ___ > 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] A few run-time problems on kicad-git build on Slackware64-current Linux
I have been using recent builds for the past few weeks. They are usable but I have a couple of outstanding problems which I'm not sure how to diagnose/fix. (1) I have strange behaviours with open Kicad application windows. For example I have a Kicad project, eeschema and pcbnew windows open on a single display. If I let the mouse pointer move from the project window to the eeschema or pcbnew window then input focus immediately transfers to the eeschema or pcbnew window. This is without touching any mouse buttons. Similarly moving the mouse pointer back to the project window has no effect (as it should) but moving it between the eeschema and pcbnew windows transfers input focus as soon as it enters the other window. There is a similar effect when moving between unrelated (eg. an xterm) windows and either eeschema or pcbnew. Here the eeschema or pcbnew window does not receive input focus (which remains with the xterm as it should) but the eeschema or pcbnew window does move up the window 'stack'. eg. if I have an eeschema windows partially covered by a pcbnew window, partially covered by an xterm window which has input focus, then moving the mouse pointer from the xterm to an uncovered section of the eeschema window will cause it to move up the stack and fully cover the pcbnew window. I get this behaviour with both accelerated and standard graphics set. The above behaviours were observed with the KDE desktop. I get similar behaviour with my usual window manager (fvwm95) except that the window focus never switches. I also find that when invoking the DRC check that the DRC Control Window disappears immediately after popping-up and has to be 're-acquired' by clicking the pcbnew tab on the fvwm95 taskbar. I suspect this is another facet of these window problems. I don't get this behaviour with any other applications but Kicad is the only wxWidgets/wxPython based one I currently use and so the problem could there at the library level rather than within Kicad on my distro/Kicad+dependencies build. None of this is a show-stopper but it is irritating. Any ideas? (2) I am unable to use any Kicad scripts. Clicking on pcbnew --> Tools --> scripting console I get the "Error: unable to create Python Console" pop-up and the following on the console, Traceback (most recent call last): File "", line 1, in File "/usr/share/kicad/scripting/kicad_pyshell/__init__.py", line 17, in import wx File "/usr/lib64/python3.8/site-packages/wx/__init__.py", line 12, in __version__ = wx.__version__.VERSION_STRING AttributeError: partially initialized module 'wx' has no attribute '__version__' (most likely due to a circular import) I built kicad with Python3 support (see below) so it should be using that and not Python2 (for which I don't have a wxWidgets build) but I suspect it might still be calling Python2. Any ideas? Many thanks Tom Crane Build details: Application: KiCad Version: (5.99.0-6755-g3b10d1583), release build Libraries: wxWidgets 3.1.4 libcurl/7.70.0 OpenSSL/1.1.1h zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0 Platform: Linux 5.4.6-mklab x86_64, 64 bit, Little endian, wxGTK, , Build Info: Date: Nov 2 2020 16:07:07 wxWidgets: 3.1.4 (wchar_t,wx containers) GTK+ 3.24 Boost: 1.74.0 OCE: 6.9.1 Curl: 7.72.0 ngspice: 30 Compiler: GCC 9.3.0 with C++ ABI 1013 Build settings: KICAD_SCRIPTING=ON KICAD_SCRIPTING_MODULES=ON KICAD_SCRIPTING_PYTHON3=ON KICAD_SCRIPTING_WXPYTHON=ON KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON KICAD_SCRIPTING_ACTION_MENU=ON KICAD_USE_OCE=ON KICAD_SPICE=ON ___ 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
