Re: [Kicad-developers] [Patch] Another hotkey processing fix

Wow, this bug has been a real annoyance for some time. Thank you for tracking down the origin. I've tested Ian's patch and it works correctly. Allows the 'P' hotkey to correctly trigger the Place Power action in eeschema and the Create Pin action in LibEdit. Tested with individual

Re: [Kicad-developers] [Patch] Another hotkey processing fix

This somehow got lost in my email, but I have now found a case where this is needed in the "wild" (the master branch). For bug https://bugs.launchpad.net/kicad/+bug/1834547, it appears that on Linux the hotkey architecture is trying to run the action for place symbol pin instead of the place power

[Kicad-developers] [Patch] Remove unneeded wxWidgets tests

This patch removes two checks (and the unused code), since they tested for version 3.0.0 and the minimum version required by CMake is wxWidgets 3.0.0. From aa2c613dd13978c6befbcc1a48798ec1234eedd8 Mon Sep 17 00:00:00 2001 From: Ian McInerney Date: Thu, 5 Sep 2019 20:48:31 +0200 Subject: [PATCH]

Re: [Kicad-developers] Selection highlighting changes.

Hey Seth, I tested this on gtk3 and MSW and the default highlight color was a bit too subtle. I didn't notice much of a difference between the Cairo and OpenGL canvases. I will definitely need to use a more noticeable color on my system. I don't know if it's just my video card/monitor

Re: [Kicad-developers] [RFC] Comments for a Layer Stack Manager in Pcbnew

I just committed the Layer Stack Manager feature. Some comments below: Le 03/09/2019 à 20:47, Evan Shultz a écrit : > A few comments from the peanut gallery using Simon's "497" build... > > Some things Seth suggested that I support and don't see: > - Units could be shown once at the top of the

Re: [Kicad-developers] knowing last commit included in a nightly build?

It would be awesome to have them merged into upstream. They're all very packaging specific. Here is the current list: * https://github.com/KiCad/kicad-mac-builder/tree/master/kicad-mac-builder/patches/kicad Adam Wolf On Thu, Sep 5, 2019 at 8:19 AM Jeff Young wrote: > > Yeah, it would be

Re: [Kicad-developers] Selection highlighting changes.

Hi Wayne-Have a look at the new default gtk color. I think it shows up well but we can always adjust.-SethOn Sep 5, 2019 5:07 AM, Wayne Stambaugh wrote:I would prefer that we pick a more obvious color out of the box.  Under certain zoom conditions it's difficult to tell if anything is even

Re: [Kicad-developers] Selection highlighting changes.

On Thu, Sep 5, 2019 at 3:20 PM Jeff Young wrote: > > That was tried, but there were complaints that you then lose the differential > colouring between different items. (And it makes selections look just like > highlighting — and there’s enough confusion there already.) I'm not sure I

Re: [Kicad-developers] Selection highlighting changes.

That was tried, but there were complaints that you then lose the differential colouring between different items. (And it makes selections look just like highlighting — and there’s enough confusion there already.) Cheers, Jeff. > On 5 Sep 2019, at 14:05, Jonatan Liljedahl wrote: > >

Re: [Kicad-developers] knowing last commit included in a nightly build?

Yeah, it would be -really- nice if we could fix this somehow. I’ve run into it many times. Cheers, Jeff. > On 5 Sep 2019, at 14:07, Jonatan Liljedahl wrote: > > On Thu, Sep 5, 2019 at 1:59 PM Nick Østergaard wrote: >> >> Does the sha listed in the version info from the runtime app not

Re: [Kicad-developers] [Patch] Fix wxWidget compatibility issues

Wayne, Yes, it should probably be cherry picked to 5.1. -Ian On Thu, Sep 5, 2019 at 2:40 PM Wayne Stambaugh wrote: > Ian, > > I pushed your patch to the master branch. Should this patch be cherry > picked to 5.1? I suspect it does. At some point someone will most > likely want to build 5.1

Re: [Kicad-developers] knowing last commit included in a nightly build?

On Thu, Sep 5, 2019 at 1:59 PM Nick Østergaard wrote: > > Does the sha listed in the version info from the runtime app not match? Unfortunately not. For example (5.1.4-60-ga2950354a) lijon-mbp:kicad lijon$ git branch * 5.1 master lijon-mbp:kicad lijon$ git log --oneline | grep ga2950354a

Re: [Kicad-developers] Selection highlighting changes.

Personally, I'd much more prefer it like this (see attached screenshot) :) On Thu, Sep 5, 2019 at 2:07 PM Wayne Stambaugh wrote: > > I would prefer that we pick a more obvious color out of the box. Under > certain zoom conditions it's difficult to tell if anything is even > selected on gtk3.

Re: [Kicad-developers] [Patch] Fix wxWidget compatibility issues

Ian, I pushed your patch to the master branch. Should this patch be cherry picked to 5.1? I suspect it does. At some point someone will most likely want to build 5.1 against wxWidgets 3.1.3 or later. Cheers, Wayne On 8/31/19 10:49 AM, Ian McInerney wrote: > wxWidgets have renamed a variable

Re: [Kicad-developers] [Patch] Update common preview items

Ian, I pushed your patch to the master branch. Thanks. Wayne On 8/31/19 10:42 AM, Ian McInerney wrote: > Some preview items were still static casting into PCB_RENDER_SETTINGS > while others were using the base class version to get the layer colors. > This patch updates it so all calls are to

Re: [Kicad-developers] knowing last commit included in a nightly build?

Should (can?) these patches be merged into the source repo? I was caught of guard recently by this as well. I'm guessing this only affects macos builds. Wayne On 9/5/19 4:46 AM, Ian McInerney wrote: > I believe that OSX adds several patches to the build process still, so > the last few commits

Re: [Kicad-developers] Selection highlighting changes.

I would prefer that we pick a more obvious color out of the box. Under certain zoom conditions it's difficult to tell if anything is even selected on gtk3. Users could make it more subtle if they find it too obnoxious. I think that would be better than a bug report about selection highlighting

Re: [Kicad-developers] knowing last commit included in a nightly build?

Does the sha listed in the version info from the runtime app not match? On Thu, 5 Sep 2019 at 12:49, Jonatan Liljedahl wrote: > > Oh, I see. So then how can I check if a commit is included or not in a > specific nightly 5.1 download? > > Cheers > > On Thu, Sep 5, 2019 at 10:47 AM Ian McInerney

Re: [Kicad-developers] knowing last commit included in a nightly build?

Oh, I see. So then how can I check if a commit is included or not in a specific nightly 5.1 download? Cheers On Thu, Sep 5, 2019 at 10:47 AM Ian McInerney wrote: > > I believe that OSX adds several patches to the build process still, so the > last few commits are OSX specific and the one being

Re: [Kicad-developers] knowing last commit included in a nightly build?

I believe that OSX adds several patches to the build process still, so the last few commits are OSX specific and the one being picked for the version string is probably one of this. Adam should be able to confirm this. -Ian On Thu, Sep 5, 2019 at 10:12 AM Jonatan Liljedahl wrote: > Hmm, weird.

Re: [Kicad-developers] knowing last commit included in a nightly build?

Hmm, weird. I'm looking at nightlies of the 5.1 branch for OSX. For example the latest: https://kicad-downloads.s3.cern.ch/osx/testing/5.1/kicad-5.1-nightly-20190904-112458-3d75100e0-10_14.dmg Looking at the hash (3d75100e0), this yields no results: $ git log --oneline | grep 3d75100e0 On Thu,

Re: [Kicad-developers] knowing last commit included in a nightly build?

Hello, What do you mean? The hex string in the file name is the prefix of the commit hash, common way to identify commits in git. E.g. latest nightly kicad-r14168.6688e8013-x86_64.exe is built from commit

[Kicad-developers] knowing last commit included in a nightly build?

Hi list, Is there any way to see from which commit a nightly was built? The hex strings in the download files doesn't seem to be git refs. -- /Jonatan http://kymatica.com ___ Mailing list: https://launchpad.net/~kicad-developers Post to :