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

[Seth Hillbrand]

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 applications as well as 
with both applications running at the same time.


Note, however, that when we edit the hotkeys in preferences, no such 
testing of whether a hotkey is handled takes place and we simply show a 
warning that the 'P' hotkey is bound to two separate actions.  I'm not 
sure what the course of action here could be other than to separate 
testing of the hotkey overlap between applications.


-Seth

On 2019-09-05 17:21, Ian McInerney wrote:
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 action. These two actions are never active 
on

the same editing session, so it is a valid configuration. Applying this
patch fixes the behavior, and the place power symbol action is actually
called.

-Ian

On Mon, Aug 12, 2019 at 9:02 PM Wayne Stambaugh 
wrote:


What is the status of this patch?

Cheers,

Wayne

On 8/8/19 7:16 PM, Ian McInerney wrote:
> In the current framework, if more than one global actions share the same
> hotkey (even if they are not all active in the current tool manager),
> the dispatcher will only choose the final action (in what seems to be
> alphabetical order) to run. I think that the correct behavior should
> instead be to loop through all global actions that have the hotkey until
> one handles it.
>
> The attached patch implements this change.
>
> -Ian
>
> ___
> 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] [Patch] Another hotkey processing fix

[Ian McInerney]

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 action. These two actions are never active on
the same editing session, so it is a valid configuration. Applying this
patch fixes the behavior, and the place power symbol action is actually
called.

-Ian

On Mon, Aug 12, 2019 at 9:02 PM Wayne Stambaugh 
wrote:

> What is the status of this patch?
>
> Cheers,
>
> Wayne
>
> On 8/8/19 7:16 PM, Ian McInerney wrote:
> > In the current framework, if more than one global actions share the same
> > hotkey (even if they are not all active in the current tool manager),
> > the dispatcher will only choose the final action (in what seems to be
> > alphabetical order) to run. I think that the correct behavior should
> > instead be to loop through all global actions that have the hotkey until
> > one handles it.
> >
> > The attached patch implements this change.
> >
> > -Ian
> >
> > ___
> > 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

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

[Ian McInerney]

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] Remove unneeded wxWidgets version checks in the code

Now that the minimum version is 3.0.0, we don't need to actually
check if the version is greater than 3.0.0 inside the code.
---
 common/view/wx_view_controls.cpp | 9 -
 1 file changed, 9 deletions(-)

diff --git a/common/view/wx_view_controls.cpp b/common/view/wx_view_controls.cpp
index 6bb61632d..4d6fb72e8 100644
--- a/common/view/wx_view_controls.cpp
+++ b/common/view/wx_view_controls.cpp
@@ -353,10 +353,8 @@ void WX_VIEW_CONTROLS::onTimer( wxTimerEvent& aEvent )
 return;
 }
 
-#if wxCHECK_VERSION( 3, 0, 0 )
 if( !m_parentPanel->HasFocus() )
 break;
-#endif
 
 double borderSize = std::min( m_settings.m_autoPanMargin * m_view->GetScreenPixelSize().x,
   m_settings.m_autoPanMargin * m_view->GetScreenPixelSize().y );
@@ -653,16 +651,9 @@ void WX_VIEW_CONTROLS::refreshMouse()
 moveEvent.SetY( msp.y );
 
 // Set the modifiers state
-#if wxCHECK_VERSION( 3, 0, 0 )
 moveEvent.SetControlDown( wxGetKeyState( WXK_CONTROL ) );
 moveEvent.SetShiftDown( wxGetKeyState( WXK_SHIFT ) );
 moveEvent.SetAltDown( wxGetKeyState( WXK_ALT ) );
-#else
-// wx <3.0 do not have accessors, but the fields are exposed
-moveEvent.m_controlDown = wxGetKeyState( WXK_CONTROL );
-moveEvent.m_shiftDown = wxGetKeyState( WXK_SHIFT );
-moveEvent.m_altDown = wxGetKeyState( WXK_ALT );
-#endif
 
 m_cursorPos = m_view->ToWorld( VECTOR2D( msp.x, msp.y ) );
 wxPostEvent( m_parentPanel, moveEvent );
-- 
2.21.0

___
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] Selection highlighting changes.

[Wayne Stambaugh]

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
combination that is the issue so others may notice the same thing I am.
 We can change it if too many other users are seeing what I am.

Cheers,

Wayne

On 9/5/2019 10:24 AM, Seth Hillbrand wrote:
> Hi Wayne-
> 
> Have a look at the new default gtk color. I think it shows up well but
> we can always adjust.
> 
> -Seth
> 
> On 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
> 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 not working.
> 
> Wayne
> 
> On 9/4/19 7:24 PM, Seth Hillbrand wrote:
> > Oh, that's right.  We had been taking the color from system
> preferences
> > but this did not show up correctly on schematic sheets that were
> not the
> > system window color.  Allowing for customization fixes this but the
> > coloring is very light.  It apparently looks correct on Mac but is
> very
> > washed out under GTK3.  I've added a conditional for the defaults
> that
> > sets GTK/MSW values to the ones that seem appropriate on GTK3.  We
> may
> > want an additional default value for MSW if it similarly appears off.
> >
> > -S
> >
> > On 2019-09-04 18:12, Jeff Young wrote:
> >> The colour is in Preferences now; see if it’s just too washed out on
> >> your monitor.
> >>
> >>> On 4 Sep 2019, at 22:35, Seth Hillbrand  wrote:
> >>>
> >>> I'm working on one (slowly) but it hasn't been pushed. GTK3 in the
> >>> master branch looks normal for me.
> >>>
> >>> Does it look the same in OpenGL and Cairo?
> >>>
> >>> _Seth
> >>>
> >>> On 2019-09-04 15:36, Wayne Stambaugh wrote:
>  Was there a change recently to the selection highlighting in
> Eeschema?
>  I can barely see any difference between the selected and
> unselected
>  objects.  If there has not been changes then something needs to
> be done
>  about the highlighting on gtk3 builds on linux.  I thought I would
>  check
>  before I filed a bug report.
>  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
> >>>
> >>> ___
> >>> 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] [RFC] Comments for a Layer Stack Manager in Pcbnew

[jp charras]

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 panel or in each column
> header instead of each cell of the table. That would reduce clutter a
> bit and shorten the string that needs to go into each cell.
> - Moving the right-side stuff (impedance control and board finish) into
> a separate panel of the dialog would allow the table to be wider. It's
> awfully cramped right now.
> - Alternating a color across each row would make the table easier to
> visually parse.
> 
> And some suggestions from me, as a knucklehead who has ran into many
> issues with stackup:
> 1. In the left pane of the dialog, there is a mix of "Stack-up" and
> "Stackup".

Fixed

> 2. Dielectric layers are the only items in the Name column that do not
> start with a capital letter.

Fixed

> 3. This panel and the popups use a mix of sentence capitalization, camel
> case, and capitalizing every word. While it doesn't impair understanding
> the panel's purpose, it doesn't look polished.
> 4. The "X" column is not salient. It is the only column header with a
> popup, and that's required because the function is opaque. Along with
> the comment above about expanding the table, using a more verbose term
> (or an icon?) for this column would be nice.

Good idea.

> 5. There are tables in the Defaults > Text & Graphics and Design Rules >
> Net Classes panels. Having column dividers makes the table much easier
> to read. Adhering to that style, I suspect, would improve readability of
> the stackup table.

The layer stack panel does not use a wxGrid.
My first implementation used a wxGrid, but I had a lot of issues.

> 6. I don't see the value of the "Board thickness" textbox at the top
> left. It changes the dielectric layer thicknesses when clicking the Set
> Dielectric Thickness button, but it sets the thickness of all dielectric
> layers equal. I have rarely seen this done in practice and never for an
> impedance-controlled board. This button seems to be mainly of value for
> simple boards with low layer counts. For a 2- or 4-layer board it's not
> much of a burden for the user to set the dielectric thickness manually
> to whatever they want, or leave it alone as the user probably doesn't
> care, and I can't imagine a high layer count board using controlled
> impedances having all dieletric layers with the same thickness. So this
> button doesn't seem useful to me. It's likely I'm daft and just don't
> get it.
> 7. One use for this is to specify the materials to be used by the board
> vendor. Picking a dielectric material type not in the list means keying
> in the parameters manually, probably after selecting "FR4". This can get
> tedious. It would be nice to have a list of materials, perhaps from an
> external file which could be shared company-wide, with approved
> materials (NanYa NP-175FR, ITEQ IT-180A, etc.). Selecting one of these
> materials would import the proper parameters. Perhaps an entire stackup,
> and just the stackup, could be imported from a file or existing board.


User defined dielectric material is not yet available.

I'll add it later.

> 8. Along with the above, allowing a custom name for the dielectric layer
> lets the user better communicate design intent to the board vendor. And
> if a custom material can be named once, perhaps it could appear as a
> selectable material in the list so other dielectric layers could use the
> same material with just a click. I get that keeping things in sync would
> then be a pain but I'm trying to imagine ways to avoid manually typing
> in the same info many times.

Good idea.
However it need a modifcation of .gbrjob specifications.

> 9. Another equally important use for this table is to select track width
> for single-ended and diff pair tracks (and in both broadside- and
> edge-coupled DPs). This table is a logical place to report all three
> impedances in new columns so the user can select the stackup, and then
> design constraints, before routing begins. While I can understand this
> being a later piece of the puzzle, I mention it in case there's anything
> that makes sense to do now.

Do not dream: one can calculate impedance only is basic cases.

> 10. It would be convenient if the copper thickness could be selected in
> ounces, even if that was converted to a mm thickness after selecting a
> value from the pulldown list. Selecting copper thicknesses (with custom
> names) and board finishes is another obvious set of selections that
> could be included in a company configuration as mentioned above.

You can enter a value with units: for instance 1oz instead of 0.035mm

> 11. Additionally, selecting the thickness on outer layers does not
> capture if the thickness is fully copper or copper plated up to the
> specified thickness. 

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

[Adam Wolf]

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 -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 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
> > lijon-mbp:kicad lijon$
> >
> >
> > --
> > /Jonatan
> > http://kymatica.com
> >
> > ___
> > 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] Selection highlighting changes.

[Seth Hillbrand]

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
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 not working.

Wayne

On 9/4/19 7:24 PM, Seth Hillbrand wrote:
> Oh, that's right.  We had been taking the color from system preferences
> but this did not show up correctly on schematic sheets that were not the
> system window color.  Allowing for customization fixes this but the
> coloring is very light.  It apparently looks correct on Mac but is very
> washed out under GTK3.  I've added a conditional for the defaults that
> sets GTK/MSW values to the ones that seem appropriate on GTK3.  We may
> want an additional default value for MSW if it similarly appears off.
> 
> -S
> 
> On 2019-09-04 18:12, Jeff Young wrote:
>> The colour is in Preferences now; see if it’s just too washed out on
>> your monitor.
>>
>>> On 4 Sep 2019, at 22:35, Seth Hillbrand  wrote:
>>>
>>> I'm working on one (slowly) but it hasn't been pushed. GTK3 in the
>>> master branch looks normal for me.
>>>
>>> Does it look the same in OpenGL and Cairo?
>>>
>>> _Seth
>>>
>>> On 2019-09-04 15:36, Wayne Stambaugh wrote:
 Was there a change recently to the selection highlighting in Eeschema?
 I can barely see any difference between the selected and unselected
 objects.  If there has not been changes then something needs to be done
 about the highlighting on gtk3 builds on linux.  I thought I would
 check
 before I filed a bug report.
 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
>>>
>>> ___
>>> 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] Selection highlighting changes.

[Jonatan Liljedahl]

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 understand the need for differential coloring inside
the selection highlight?
Highlighting nets are purple/pink, cross-probing is red, selection
could be some other bright color.

Another alternative would be to use the new halo but with clean sharp
edges instead of the fading-out / glow (which IMHO looks a bit
unprofessional).
I attach a crude mockup of what I mean..


> Cheers,
> Jeff.
>
>
> > On 5 Sep 2019, at 14:05, Jonatan Liljedahl  wrote:
> >
> > 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.  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 not working.
> >>
> >> Wayne
> >>
> >> On 9/4/19 7:24 PM, Seth Hillbrand wrote:
> >>> Oh, that's right.  We had been taking the color from system preferences
> >>> but this did not show up correctly on schematic sheets that were not the
> >>> system window color.  Allowing for customization fixes this but the
> >>> coloring is very light.  It apparently looks correct on Mac but is very
> >>> washed out under GTK3.  I've added a conditional for the defaults that
> >>> sets GTK/MSW values to the ones that seem appropriate on GTK3.  We may
> >>> want an additional default value for MSW if it similarly appears off.
> >>>
> >>> -S
> >>>
> >>> On 2019-09-04 18:12, Jeff Young wrote:
>  The colour is in Preferences now; see if it’s just too washed out on
>  your monitor.
> 
> > On 4 Sep 2019, at 22:35, Seth Hillbrand  wrote:
> >
> > I'm working on one (slowly) but it hasn't been pushed. GTK3 in the
> > master branch looks normal for me.
> >
> > Does it look the same in OpenGL and Cairo?
> >
> > _Seth
> >
> > On 2019-09-04 15:36, Wayne Stambaugh wrote:
> >> Was there a change recently to the selection highlighting in Eeschema?
> >> I can barely see any difference between the selected and unselected
> >> objects.  If there has not been changes then something needs to be done
> >> about the highlighting on gtk3 builds on linux.  I thought I would
> >> check
> >> before I filed a bug report.
> >> 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
> >
> > ___
> > 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
> >
> >
> >
> > --
> > /Jonatan
> > http://kymatica.com
> > 
>


-- 
/Jonatan
http://kymatica.com
___
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] Selection highlighting changes.

[Jeff Young]

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:
> 
> 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.  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 not working.
>> 
>> Wayne
>> 
>> On 9/4/19 7:24 PM, Seth Hillbrand wrote:
>>> Oh, that's right.  We had been taking the color from system preferences
>>> but this did not show up correctly on schematic sheets that were not the
>>> system window color.  Allowing for customization fixes this but the
>>> coloring is very light.  It apparently looks correct on Mac but is very
>>> washed out under GTK3.  I've added a conditional for the defaults that
>>> sets GTK/MSW values to the ones that seem appropriate on GTK3.  We may
>>> want an additional default value for MSW if it similarly appears off.
>>> 
>>> -S
>>> 
>>> On 2019-09-04 18:12, Jeff Young wrote:
 The colour is in Preferences now; see if it’s just too washed out on
 your monitor.
 
> On 4 Sep 2019, at 22:35, Seth Hillbrand  wrote:
> 
> I'm working on one (slowly) but it hasn't been pushed. GTK3 in the
> master branch looks normal for me.
> 
> Does it look the same in OpenGL and Cairo?
> 
> _Seth
> 
> On 2019-09-04 15:36, Wayne Stambaugh wrote:
>> Was there a change recently to the selection highlighting in Eeschema?
>> I can barely see any difference between the selected and unselected
>> objects.  If there has not been changes then something needs to be done
>> about the highlighting on gtk3 builds on linux.  I thought I would
>> check
>> before I filed a bug report.
>> 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
> 
> ___
> 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
> 
> 
> 
> -- 
> /Jonatan
> http://kymatica.com
> 


___
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] knowing last commit included in a nightly build?

[Jeff Young]

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 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
> lijon-mbp:kicad lijon$
> 
> 
> -- 
> /Jonatan
> http://kymatica.com
> 
> ___
> 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] [Patch] Fix wxWidget compatibility issues

[Ian McInerney]

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 against wxWidgets 3.1.3 or later.
>
> Cheers,
>
> Wayne
>
> On 8/31/19 10:49 AM, Ian McInerney wrote:
> > wxWidgets have renamed a variable in the wxGrid implementation for their
> > 3.1.3 release, so out implementation needs to have a compatibility check
> > for this now. This patch does that, and also removes an unneeded
> > check/define.
> >
> > -Ian
> >
> > ___
> > 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] knowing last commit included in a nightly build?

[Jonatan Liljedahl]

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
lijon-mbp:kicad lijon$


-- 
/Jonatan
http://kymatica.com

___
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] Selection highlighting changes.

[Jonatan Liljedahl]

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.  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 not working.
>
> Wayne
>
> On 9/4/19 7:24 PM, Seth Hillbrand wrote:
> > Oh, that's right.  We had been taking the color from system preferences
> > but this did not show up correctly on schematic sheets that were not the
> > system window color.  Allowing for customization fixes this but the
> > coloring is very light.  It apparently looks correct on Mac but is very
> > washed out under GTK3.  I've added a conditional for the defaults that
> > sets GTK/MSW values to the ones that seem appropriate on GTK3.  We may
> > want an additional default value for MSW if it similarly appears off.
> >
> > -S
> >
> > On 2019-09-04 18:12, Jeff Young wrote:
> >> The colour is in Preferences now; see if it’s just too washed out on
> >> your monitor.
> >>
> >>> On 4 Sep 2019, at 22:35, Seth Hillbrand  wrote:
> >>>
> >>> I'm working on one (slowly) but it hasn't been pushed. GTK3 in the
> >>> master branch looks normal for me.
> >>>
> >>> Does it look the same in OpenGL and Cairo?
> >>>
> >>> _Seth
> >>>
> >>> On 2019-09-04 15:36, Wayne Stambaugh wrote:
>  Was there a change recently to the selection highlighting in Eeschema?
>  I can barely see any difference between the selected and unselected
>  objects.  If there has not been changes then something needs to be done
>  about the highlighting on gtk3 builds on linux.  I thought I would
>  check
>  before I filed a bug report.
>  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
> >>>
> >>> ___
> >>> 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



-- 
/Jonatan
http://kymatica.com
___
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] [Patch] Fix wxWidget compatibility issues

[Wayne Stambaugh]

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 in the wxGrid implementation for their
> 3.1.3 release, so out implementation needs to have a compatibility check
> for this now. This patch does that, and also removes an unneeded
> check/define.
> 
> -Ian
> 
> ___
> 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] [Patch] Update common preview items

[Wayne Stambaugh]

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 the base class version, this
> also removes the need to have pcb_painter (and any pcbnew includes) in
> these files.
> 
> -Ian
> 
> ___
> 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] knowing last commit included in a nightly build?

[Wayne Stambaugh]

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 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.
> 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, Sep 5, 2019 at 9:49 AM Andrew Lutsenko  > wrote:
> >
> > 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 6688e80131e8283ecd2b45e0e2c04a4f3d6fcef2.
> >
> > Regards,
> > Andrew
> >
> > On Thu, Sep 5, 2019 at 12:25 AM Jonatan Liljedahl
> mailto:li...@kymatica.com>> wrote:
> >>
> >> 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     : kicad-developers@lists.launchpad.net
> 
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> -- 
> /Jonatan
> http://kymatica.com
> 
> ___
> 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] Selection highlighting changes.

[Wayne Stambaugh]

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 not working.

Wayne

On 9/4/19 7:24 PM, Seth Hillbrand wrote:
> Oh, that's right.  We had been taking the color from system preferences
> but this did not show up correctly on schematic sheets that were not the
> system window color.  Allowing for customization fixes this but the
> coloring is very light.  It apparently looks correct on Mac but is very
> washed out under GTK3.  I've added a conditional for the defaults that
> sets GTK/MSW values to the ones that seem appropriate on GTK3.  We may
> want an additional default value for MSW if it similarly appears off.
> 
> -S
> 
> On 2019-09-04 18:12, Jeff Young wrote:
>> The colour is in Preferences now; see if it’s just too washed out on
>> your monitor.
>>
>>> On 4 Sep 2019, at 22:35, Seth Hillbrand  wrote:
>>>
>>> I'm working on one (slowly) but it hasn't been pushed. GTK3 in the
>>> master branch looks normal for me.
>>>
>>> Does it look the same in OpenGL and Cairo?
>>>
>>> _Seth
>>>
>>> On 2019-09-04 15:36, Wayne Stambaugh wrote:
 Was there a change recently to the selection highlighting in Eeschema?
 I can barely see any difference between the selected and unselected
 objects.  If there has not been changes then something needs to be done
 about the highlighting on gtk3 builds on linux.  I thought I would
 check
 before I filed a bug report.
 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
>>>
>>> ___
>>> 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] knowing last commit included in a nightly build?

[Nick Østergaard]

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  
> 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 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.
> >> 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, Sep 5, 2019 at 9:49 AM Andrew Lutsenko  
> >> wrote:
> >> >
> >> > 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 6688e80131e8283ecd2b45e0e2c04a4f3d6fcef2.
> >> >
> >> > Regards,
> >> > Andrew
> >> >
> >> > On Thu, Sep 5, 2019 at 12:25 AM Jonatan Liljedahl  
> >> > wrote:
> >> >>
> >> >> 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 : kicad-developers@lists.launchpad.net
> >> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >>
> >> --
> >> /Jonatan
> >> http://kymatica.com
> >>
> >> ___
> >> 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
>
>
>
> --
> /Jonatan
> http://kymatica.com
>
> ___
> 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] knowing last commit included in a nightly build?

[Jonatan Liljedahl]

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 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.
>> 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, Sep 5, 2019 at 9:49 AM Andrew Lutsenko  wrote:
>> >
>> > 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 
>> > 6688e80131e8283ecd2b45e0e2c04a4f3d6fcef2.
>> >
>> > Regards,
>> > Andrew
>> >
>> > On Thu, Sep 5, 2019 at 12:25 AM Jonatan Liljedahl  
>> > wrote:
>> >>
>> >> 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 : kicad-developers@lists.launchpad.net
>> >> Unsubscribe : https://launchpad.net/~kicad-developers
>> >> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>> --
>> /Jonatan
>> http://kymatica.com
>>
>> ___
>> 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



-- 
/Jonatan
http://kymatica.com

___
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] knowing last commit included in a nightly build?

[Ian McInerney]

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.
> 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, Sep 5, 2019 at 9:49 AM Andrew Lutsenko 
> wrote:
> >
> > 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 6688e80131e8283ecd2b45e0e2c04a4f3d6fcef2.
> >
> > Regards,
> > Andrew
> >
> > On Thu, Sep 5, 2019 at 12:25 AM Jonatan Liljedahl 
> wrote:
> >>
> >> 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 : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
>
>
>
> --
> /Jonatan
> http://kymatica.com
>
> ___
> 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] knowing last commit included in a nightly build?

[Jonatan Liljedahl]

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, Sep 5, 2019 at 9:49 AM Andrew Lutsenko  wrote:
>
> 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 
> 6688e80131e8283ecd2b45e0e2c04a4f3d6fcef2.
>
> Regards,
> Andrew
>
> On Thu, Sep 5, 2019 at 12:25 AM Jonatan Liljedahl  wrote:
>>
>> 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 : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp



-- 
/Jonatan
http://kymatica.com

___
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] knowing last commit included in a nightly build?

[Andrew Lutsenko]

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 6688e80131e8283ecd2b45e0e2c04a4f3d6fcef2.

Regards,
Andrew

On Thu, Sep 5, 2019 at 12:25 AM Jonatan Liljedahl 
wrote:

> 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 : 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] knowing last commit included in a nightly build?

[Jonatan Liljedahl]

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 : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp