Re: [Kicad-developers] wxWidgets Event Tables or Bind and lambdas

On 7/12/2019 8:46 AM, Simon Richter wrote: > Hi, > > My layout would be > > m_footprintListBox->Bind( wxEVT_RIGHT_DOWN, > [this]( wxMouseEvent& ) > { > this->PopupMenu( this->m_footprintContextMenu ); > } ); I like the way this looks compared to the other f

Re: [Kicad-developers] wxWidgets Event Tables or Bind and lambdas

Ian, I would prefer that we not mix event handling styles unless there is a good reason such as dynamically binding/unbinding for adding temporary event handling. For new code, I'm fine with either method with the caveat that all of the Bind calls be defined in the same function rather than sprea

Re: [Kicad-developers] wxWidgets Event Tables or Bind and lambdas

On 2019-07-12 08:29, Jeff Young wrote: These are currently reasonably common in the code: 1) m_footprintListBox->Bind( wxEVT_RIGHT_DOWN, [this]( wxMouseEvent& ) { this->PopupMenu( this->m_footprintContextMenu ); } ); 2) m_footprintListBox->Bind( wxEVT_RIGHT_DOWN, [this]( wxMouseEvent& ) {

Re: [Kicad-developers] wxWidgets Event Tables or Bind and lambdas

Hi, > I prefer the way Simon has it formatted, since the lambda follows the > general function formatting guidelines. I am indifferent to the grouping of > arguments around it though, and the clang-format script would seem to > prefer doing it this way: > function( arg1, arg2, arg3, arg4, arg5, >

Re: [Kicad-developers] wxWidgets Event Tables or Bind and lambdas

I prefer the way Simon has it formatted, since the lambda follows the general function formatting guidelines. I am indifferent to the grouping of arguments around it though, and the clang-format script would seem to prefer doing it this way: function( arg1, arg2, arg3, arg4, arg5, arg6, ar

Re: [Kicad-developers] wxWidgets Event Tables or Bind and lambdas

Hi, My layout would be m_footprintListBox->Bind( wxEVT_RIGHT_DOWN, [this]( wxMouseEvent& ) { this->PopupMenu( this->m_footprintContextMenu ); } ); Rationale: - it follows the "indent twice for round parentheses" rule - the lambda begins on the first char

Re: [Kicad-developers] wxWidgets Event Tables or Bind and lambdas

These are currently reasonably common in the code: 1) m_footprintListBox->Bind( wxEVT_RIGHT_DOWN, [this]( wxMouseEvent& ) { this->PopupMenu( this->m_footprintContextMenu ); } ); 2) m_footprintListBox->Bind( wxEVT_RIGHT_DOWN, [this]( wxMouseEvent& ) {

Re: [Kicad-developers] wxWidgets Event Tables or Bind and lambdas

The higher SNR was one reason why I was thinking of switching the handlers over to them, since then we don't need the separate function declaration/function body, and it also makes it clearer what the actions do. For instance this is one that I have added during my work on cvpcb for the context men

Re: [Kicad-developers] wxWidgets Event Tables or Bind and lambdas

We already have a lot of classes which use both. FWIW, the wxWidgets folks encourage Bind. As for lamdas, I think they’re pretty rare (for this use) in the code at present. But they do appear to result in a higher signal-to-noise ratio for very short handlers. While we’re on the subject, we h

Re: [Kicad-developers] wxWidgets Event Tables or Bind and lambdas

Hi, On Fri, Jul 12, 2019 at 11:11:21AM +0200, Ian McInerney wrote: > Other windows seem to use the Bind method with lambda functions for these > small functions, and I have used them as well for some new bindings for the > actionization when needed. My main question is, is it acceptable to also >

Re: [Kicad-developers] wxWidgets

On 3/29/2018 10:27 AM, Jeff Young wrote: > In this case we kind of need it as we don’t want to display a bunch of > never-used field data columns, but everyone’s definition of “never-used” is > likely to be different. If you have time, by all means implement this feature for windows and linux us

Re: [Kicad-developers] wxWidgets

In this case we kind of need it as we don’t want to display a bunch of never-used field data columns, but everyone’s definition of “never-used” is likely to be different. But I certainly agree in principle. > On 29 Mar 2018, at 15:17, Wayne Stambaugh wrote: > > Also, please keep in mind that

Re: [Kicad-developers] wxWidgets

Also, please keep in mind that one of the objectives of wxwidgets is to stick with the stock look and behavior of platform controls as much as possible. Users on windows and linux will not expect this behavior even though it might be a nice feature on macos. On 3/29/2018 9:32 AM, Jon Evans wrote:

Re: [Kicad-developers] wxWidgets

I think we should measure the amount of time we spend fixing or extending wxWidgets vs. doing anything else. I'm not proposing that we should be doing anything else in particular at this time, but I think it would be good data to have. -Jon On Thu, Mar 29, 2018 at 8:55 AM, Jeff Young wrote: > R

Re: [Kicad-developers] wxwidgets fork progress

Yes, this needs to be fixed. On 02/12/2018 07:04 PM, Michael Kavanagh wrote: I think the docs need to be updated to reflect these changes: http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_osx Cheers, Michael On 31 January 2018 at 15:24, Wayne Stambaugh

Re: [Kicad-developers] wxwidgets fork progress

I think the docs need to be updated to reflect these changes: http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_osx Cheers, Michael On 31 January 2018 at 15:24, Wayne Stambaugh wrote: > OK, these patches have be reduced to historical footnotes. Thanks > everyo

Re: [Kicad-developers] wxwidgets fork progress

OK, these patches have be reduced to historical footnotes. Thanks everyone for the feedback. Cheers, Wayne On 1/30/2018 5:04 PM, Adam Wolf wrote: > You can remove the boost patches. They are only of historical > concern, and they'll live in Git for any future archaeologist who > cares. > > Ad

Re: [Kicad-developers] wxwidgets fork progress

You can remove the boost patches. They are only of historical concern, and they'll live in Git for any future archaeologist who cares. Adam On Tue, Jan 30, 2018 at 3:20 PM, Jeff Young wrote: > Yeah, I didn’t patch my boost either. (I can’t remember if I MacPorts’d it > or Homebrew’d it, but I

Re: [Kicad-developers] wxwidgets fork progress

Yeah, I didn’t patch my boost either. (I can’t remember if I MacPorts’d it or Homebrew’d it, but I didn’t do anything beyond that.) > On 30 Jan 2018, at 21:13, Bernhard Stegmaier wrote: > > Wayne, > > I don’t think so. > > I use a stock MacPorts boost since long before you removed boost fro

Re: [Kicad-developers] wxwidgets fork progress

Wayne, I don’t think so. I use a stock MacPorts boost since long before you removed boost from KiCad build. This might not be representative, but I didn’t see any problems. I had a quick look into Adams build scripts and I didn’t see that he is building his own boost (with the patches) somewhe

Re: [Kicad-developers] wxwidgets fork progress

Bernhard, What about the macos boost and context patches? Do we still need to keep them? Thanks, Wayne On 1/29/2018 1:23 PM, Bernhard Stegmaier wrote: > Wayne, > > yes, from my side you can delete them. > Even if deleted they are in git anyway, so we can restore them if really > needed. > I’l

Re: [Kicad-developers] wxwidgets fork progress

That patch may be needed to build on older macOS versions and older targets. I am not worried about removing it--it hasn't been in builds for a long time. Good work Bernhard. Adam On Jan 29, 2018 12:11 PM, "Bernhard Stegmaier" wrote: > The full original soname patch seems to fix the issue in

Re: [Kicad-developers] wxwidgets fork progress

Wayne, yes, from my side you can delete them. Even if deleted they are in git anyway, so we can restore them if really needed. I’ll try to change documentation ASAP. Regards, Bernhard > On 29. Jan 2018, at 19:15, Wayne Stambaugh wrote: > > Bernhard, > > Am I safe deleting the macos patches f

Re: [Kicad-developers] wxwidgets fork progress

Bernhard, Am I safe deleting the macos patches from the source repo or do I need to hold off until the dust has settle on the new wx repo? Thanks, Wayne On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote: > The full original soname patch seems to fix the issue in my builds (I > did apply only half

Re: [Kicad-developers] wxwidgets fork progress

The full original soname patch seems to fix the issue in my builds (I did apply only half of it to our fork because of the comments in wxWidgets trac). I pushed it to the fork. The next build should pick it up automatically and be good again… sorry for not having checked this before. I also did

Re: [Kicad-developers] wxwidgets fork progress

Just a short status… I just tried the compile_wx.sh script and it generally seems to be fine. But, I can see that obviously the wxPython installer duplicates libs instead of symlinking them. Maybe the original soname patch we had is needed for that one to work correctly. I’ll check… Regards, Be

Re: [Kicad-developers] wxwidgets fork progress

I think I see it now. I can probably fix this tonight. Thanks! Adam On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier" wrote: > Quick look into the build… seems to pull in wrong wxWidgets libs. > The build in question includes some 3.0.0 wxWidgets libraries which I > guess come from wxPython downl

Re: [Kicad-developers] wxwidgets fork progress

Quick look into the build… seems to pull in wrong wxWidgets libs. The build in question includes some 3.0.0 wxWidgets libraries which I guess come from wxPython download. The fork should create 3.0.4 libraries... > On 29. Jan 2018, at 00:05, Bernhard Stegmaier wrote: > > I just had a quick look

Re: [Kicad-developers] wxwidgets fork progress

I just had a quick look and it looks fine. Also my first guess is that maybe something got messed up in the folder hierarchy when copying wxPython/wxWidgets together, so that e.g. here WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \ some wrong wxWidgets (not the one of the for

Re: [Kicad-developers] wxwidgets fork progress

Yeah. The previous build script downloaded a wxpython tarball, which included wxwidgets. All my update did was move the wxpython subdirectory into a git checkout of the wxwidgets tree, and build that way. One quick thing would be to just do a diff between the wxwidgets included with wxpython 3.0

Re: [Kicad-developers] wxwidgets fork progress

Sure. I’ll have a look tomorrow and try to build wxWidgets/wxPython the same way the script does. > On 28. Jan 2018, at 23:44, Nick Østergaard wrote: > > You don't need to revert it. I can just choose the latest workin hash in the > jenkins job. I would rather we fix it somehow. :) > > @Bernh

Re: [Kicad-developers] wxwidgets fork progress

That seems to be the same error as when the former so-name patch was not applied and original wxWidgets build stuff rewrites library names. The bundle is corrupt then, because the bundling code fails to create symlinks and copies libs instead multiple times. If you can send me where to find the

Re: [Kicad-developers] wxwidgets fork progress

You don't need to revert it. I can just choose the latest workin hash in the jenkins job. I would rather we fix it somehow. :) @Bernhard, the build scripts in question are https://github.com/wayneandlayne/KiCadMacOSPackaging Maybe you can have a got at it? 2018-01-28 23:41 GMT+01:00 Nick Østerga

Re: [Kicad-developers] wxwidgets fork progress

Which bug? Bernhard > On 28. Jan 2018, at 23:14, Adam Wolf wrote: > > I was able to get the wxwidgets stuff switched over but there's a bug in the > big tracker saying it didn't work. I will continue to look into it as I can. > I should be over this illness by the end of this week, it look

Re: [Kicad-developers] wxwidgets fork progress

I assume this is the bug you are talking about: https://bugs.launchpad.net/kicad/+bug/1745868 2018-01-28 23:14 GMT+01:00 Adam Wolf : > I was able to get the wxwidgets stuff switched over but there's a bug in > the big tracker saying it didn't work. I will continue to look into it as > I can. I

Re: [Kicad-developers] "wxWidgets Debug Alert" in pcbnew.py

Le 13/03/2017 à 16:01, Martin Schreiber a écrit : > Hi, > kicad-4.0.6-x86_64.exe, installed on Windows 7, shows the attached error > message with the attached > script. Is it a KiCad bug? If yes, is there a workaround? > > Thanks, Martin > You should call pctl.OpenPlotfile() after a valid board

Re: [Kicad-developers] wxWidgets vs boost utilities

Le 07/06/2015 10:51, Cirilo Bernardo a écrit : > When I wrote the idf2igs tool/test program I modified the IDF code to use > boost to > (a) manipulate filenames and > (b) manipulate time > > I made the modifications since the IGES code already uses boost_filesystem > and I didn't want to pull in w

Re: [Kicad-developers] wxwidgets-3.0.2_macosx_yosemite.patch is a metapatch

Still not quite right, I think. Garth > On Nov 12, 2014, at 4:39 PM, Wayne Stambaugh wrote: > > Adam, > > I committed the updated patch in the product branch r5265. > > Thanks, > > Wayne > > On 11/11/2014 8:54 PM, Adam Wolf wrote: >> Sorry folks! This is my fault. >> >> I attached a pat

Re: [Kicad-developers] wxwidgets-3.0.2_macosx_yosemite.patch is a metapatch

Adam, I committed the updated patch in the product branch r5265. Thanks, Wayne On 11/11/2014 8:54 PM, Adam Wolf wrote: > Sorry folks! This is my fault. > > I attached a patch against the latest bzr at the time, and I think Wayne > thought it was the actual patch that belonged in the patches di

Re: [Kicad-developers] wxwidgets-3.0.2_macosx_yosemite.patch is a metapatch

Sorry folks! This is my fault. I attached a patch against the latest bzr at the time, and I think Wayne thought it was the actual patch that belonged in the patches directory. I have attached a patch, that when applied to the latest version of kicad, will fix the patch. (If you want to see what

Re: [Kicad-developers] wxwidgets-3.0.2_macosx_yosemite.patch is a metapatch

Hi Garth, I guess that's one way to make sure it won't affect Windows or Linux! :) Unfortunately, I can't take a look at this until Monday. Adam Wolf Cofounder and Engineer W&L On Sat, Nov 8, 2014 at 2:27 AM, Garth Corral wrote: > > Hi, it’s late so maybe I’m just confused, but the newly adde

Re: [Kicad-developers] wxWidgets version.

On 9/7/2014 5:39 AM, Brian Sidebotham wrote: > KiCad-Winbuilder is using a patched 3.0.0 so it's pretty stable at the > moment. I wanted to wait for a period of no bug reporting against > wxWidgets (with regards to KiCad) until I bumped the version in the > wxWidgets-cmake project that Winbuilder u

Re: [Kicad-developers] wxWidgets version.

KiCad-Winbuilder is using a patched 3.0.0 so it's pretty stable at the moment. I wanted to wait for a period of no bug reporting against wxWidgets (with regards to KiCad) until I bumped the version in the wxWidgets-cmake project that Winbuilder uses. Best Regards, Brian.

Re: [Kicad-developers] wxWidgets version.

Hi, just FYI… I am using 3.0.1 on OSX since it has been published. I used eeschema quite a lot since then, pcbnew not so much. I never did see any problem with it… Regards, Bernhard On 06.09.2014, at 16:49, Wayne Stambaugh wrote: > On 9/5/2014 5:04 PM, Andrew Zonenberg wrote: >> In addition,

Re: [Kicad-developers] wxWidgets version.

On 9/5/2014 5:04 PM, Andrew Zonenberg wrote: > In addition, I strongly recommend putting a warning when someone tries > to build against wx 3.0.1 on Linux based on the regression I found a > while ago. I believe this bug is only on GTK3 builds. I have no problems on windows. I'm not sure what th

Re: [Kicad-developers] wxWidgets version.

On Fri, Sep 05, 2014 at 05:04:07PM -0400, Andrew Zonenberg wrote: > In addition, I strongly recommend putting a warning when someone tries > to build against wx 3.0.1 on Linux based on the regression I found a > while ago. Not that 3.0.0 works flawlessy (yet don't know if my issues are from wx or

Re: [Kicad-developers] wxWidgets version.

In addition, I strongly recommend putting a warning when someone tries to build against wx 3.0.1 on Linux based on the regression I found a while ago. On Fri, 2014-09-05 at 17:01 -0400, Wayne Stambaugh wrote: > I know we have informally discussed dropping wxWidgets 2.8 support due > to it's known

Re: [Kicad-developers] wxwidgets 3.0 issues?

On Sun, Aug 17, 2014 at 12:05:41PM +, Mário Luzeiro wrote: > Is that expected? I mean, should I continue build with wxwidgets 3.0 or > revert it back? AFAIK 2.8 is no longer supported since the new modular stuff doesn't work correctly with it. -- Lorenzo Marcantonio Logos Srl _

Re: [Kicad-developers] wxwidgets 3.0 issues?

Mario, I suggest you use wxWidgets 3.0.1 at a minimum. It is the latest release and resolves most (but not all of the issues) in 3.0.0. I've been using latest trunk from SourceForge on my Windows builds with good results but that may or may not work as well as on other platforms. Wayne On 8/17

Re: [Kicad-developers] wxWidgets 3.0

Brian, I "closed" my other thread where I was having problems with SCRIPTING ON. Unfortunately, I do not have clear direction for what was the "real" issue - but I can say it would be nice to have a parameters to pass to make.bat to allow for a "make clean" in case that was the issue. I dou

Re: [Kicad-developers] wxWidgets 3.0

Thanks for the release information Dick, we'll look to include that in Winbuilder as soon as possible. At the moment the version used is a patched v3.0.0, not a vanilla version. Therefore some vital fixes for KiCad were already included. It will be good to upgrade to get the bug fixes though. Jaso

Re: [Kicad-developers] wxWidgets 3.0

Thanks for the heads up -- this started me a bit down a rabbit hole. I've swapped out the winbuilder mingw with the "mingw-w64-dgn" personal build. He's got wxwidgets-3.0.1 pre-built. This brought gcc up to 4.8.3 (could have went the 4.9.0 way -- but decided to stay within the 4.8.x) and moved to

Re: [Kicad-developers] wxWidgets 2.9.1 menu bitmap problem.

Le 05/04/2011 19:09, Wayne Stambaugh a écrit : I just noticed that most (but not all) of the menu item bitmaps in Kicad are check marks when building against wxWidgets 2.9.1 on windows. Has any one else seen this or is it just me? Wayne Previous commit (commit 2945) is the culprit. This is du

Re: [Kicad-developers] wxWidgets requirement

On Tue, 17 Aug 2010, Dick Hollenbeck wrote: Play around with the attached patch if you want to stick with the 2.8.10 version. Too late, I already rebuilt the whole thing (noone at the office and a quad core only for compiling is really fast even for C++:D). Maybe I'll get a try with the old ve

Re: [Kicad-developers] wxWidgets requirement

On 08/17/2010 01:15 PM, Lorenzo Marcantonio wrote: > It seems the version requirement for wxWidgets needs a bump... > > Today's merge from bzr fails compiling on XNODE::AddAttribute (which is > available from 2.8.11). > > And of course I *only* have 2.8.10 :P > > Now rebuilding the world (tm)... >

Re: [Kicad-developers] wxWidgets requirement

On 08/17/2010 01:15 PM, Lorenzo Marcantonio wrote: > It seems the version requirement for wxWidgets needs a bump... > > Today's merge from bzr fails compiling on XNODE::AddAttribute (which is > available from 2.8.11). > > And of course I *only* have 2.8.10 :P > > Now rebuilding the world (tm)... >