[Kicad-developers] macOS nightly builds no longer supporting 10.11

2019-07-09 Thread Adam Wolf
Hi folks! I've been unable to keep 10.11 builds going. I'm certain it's possible, but 10.11 is out of security updates and has been for a bit, so I don't feel too bad about bumping the lower version to 10.12. I should be be spending more time getting 10.15 working, not keeping 10.11 working. :)

Re: [Kicad-developers] common/tool/tool_dispatcher needs fixing.

2019-07-09 Thread Jeff Young
I’ve pushed some code (and put my fire-suit on). Cheers, Jeff. > On 9 Jul 2019, at 21:10, Jeff Young wrote: > > Hmm… now I know why it doesn’t indicate handled for other stuff: it’s > difficult to get that information back from the coroutine. But I think a bug > fix I made earlier for the

Re: [Kicad-developers] Strange program version numbering in KiCad

2019-07-09 Thread Carsten Schoenert
Hello Nick, Am 09.07.19 um 21:57 schrieb Nick Østergaard: > I have a hard time to understand how 5.99 is better to describe a > development version. 6.00 was already a bad way to describe it. > People also were confused. To me .99 seems very arbitrary. Why not > .1234? simply your mind is

Re: [Kicad-developers] Strange program version numbering in KiCad

2019-07-09 Thread Nick Østergaard
An option could be to prepend the branch name via something like: git symbolic-ref -q --short HEAD To the git describe --long we already have. On Tue, 9 Jul 2019 at 21:57, Nick Østergaard wrote: > > I have a hard time to understand how 5.99 is better to describe a > development version. 6.00

Re: [Kicad-developers] common/tool/tool_dispatcher needs fixing.

2019-07-09 Thread Jeff Young
Hmm… now I know why it doesn’t indicate handled for other stuff: it’s difficult to get that information back from the coroutine. But I think a bug fix I made earlier for the PassEvent stuff may give us a proxy for “handled”. > On 9 Jul 2019, at 21:07, Jeff Young wrote: > > Hi JP, > > This

Re: [Kicad-developers] common/tool/tool_dispatcher needs fixing.

2019-07-09 Thread Jeff Young
Hi JP, This code definitely seems to have evolved a bit over time. ProcessEvent() specifically returns true only if it was a hotkey that was handled, and not for anything else. But I can’t find any code that benefits from that, so I suspect it’s vestigial. I think the best thing to do is to

Re: [Kicad-developers] Strange program version numbering in KiCad

2019-07-09 Thread Nick Østergaard
I have a hard time to understand how 5.99 is better to describe a development version. 6.00 was already a bad way to describe it. People also were confused. To me .99 seems very arbitrary. Why not .1234? On Mon, 8 Jul 2019 at 23:20, Eeli Kaikkonen wrote: > > > > ma 8. heinäk. 2019 klo 23.47

[Kicad-developers] common/tool/tool_dispatcher needs fixing.

2019-07-09 Thread jp charras
Hi Jeff, Sorry to bother you, but could you have a look into this file, and especially into void TOOL_DISPATCHER::DispatchWxEvent( wxEvent& aEvent ). There are 2 things that need fixing (related to key event handling), because our key event handler has bugs: 1 - the first is related to ESC

Re: [Kicad-developers] Strange program version numbering in KiCad

2019-07-09 Thread Eeli Kaikkonen
ti 9. heinäk. 2019 klo 19.45 Simon Richter (simon.rich...@hogyros.de) kirjoitti: > I still think it is a bit confusing to have a tag > on something that is not a release. > "git tag" reveals to me that 5.1.0-dev is already a tag, and it's not a release. Right? Eeli Kaikkonen

Re: [Kicad-developers] Strange program version numbering in KiCad

2019-07-09 Thread Simon Richter
Hi, On Tue, Jul 09, 2019 at 09:26:11AM -0400, Steven A. Falco wrote: > I'd vote for the .99 approach, assuming I get a vote. :-) The main difficulty is the way the version number generation is implemented. We use "git describe" to get the name of the last tag, then add the number of commits and

Re: [Kicad-developers] Compil issue due to commit 36f1d023

2019-07-09 Thread Jeff Young
Oops, those were supposed to be tool IDs. I’ve pushed another commit. Let me know if it still doesn’t compile (the LLDB compiler is much more aggressive about auto-type-casting). > On 9 Jul 2019, at 16:44, jp charras wrote: > > This commit creates 2 similar issues: > the first issue is: > >

[Kicad-developers] Compil issue due to commit 36f1d023

2019-07-09 Thread jp charras
This commit creates 2 similar issues: the first issue is: F:/kicad-launchpad/git_testing/pcbnew/tools/edit_tool.cpp:1299:24: error: cannot convert 'const wxString' to 'const string&' {aka 'const std::__cxx11::basic_string&'} 1299 | frame()->PushTool( _( "Select reference point for the

Re: [Kicad-developers] Strange program version numbering in KiCad

2019-07-09 Thread Steven A. Falco
On 7/8/19 10:41 PM, Reece R. Pollack wrote: > On 7/8/19 10:36 PM, Kevin Cozens wrote: >> On 2019-07-08 5:10 p.m., Dino Ghilardi wrote: >>> think about the linux kernel versioning number scheme: even subversion >>> number means stable release. Odd subversion number means >>>

Re: [Kicad-developers] [PATCH] Crash Reporter

2019-07-09 Thread Wayne Stambaugh
Tom, On 7/9/19 2:41 AM, Tomasz Wlostowski wrote: > On 06/07/2019 21:10, Ian McInerney wrote: >> Tom, >> >> Not to pile on the questions, but does the linux stack trace support >> exist in the entire 3.0.x line, or how far back does it go? Currently, >> the minimum version searched by cmake is