[Kicad-developers] [PATCH] Icon for "Update PCB from Schematic"

[John Beard]

Hi,

Another icon! (Groan)

This one is the update PCB from Schematic icon. Currently, this
re-uses the "Import PCB board file" icon from the file menu.

I think this is a bit non-obvious, because the action isn't an
"import", it's an update, and the icon makes no reference to the
schematic nature of the action.

I have used a metaphor of schematic -> PCB, with an left-to-right
arrow indicating forward action.

I considered the update double arrow/circle, but it's not really a
bidirectional action between PCB and Schematic. If that's preferred, I
will do it that way. I personally don't really care what the icon is,
as long as it's clearly distinguished in context from any other
action.

As usual, PNG is for reference.

Cheers,

John
From fa555f19ef8a115cca2365ea88da010f1202c541 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Wed, 25 Jul 2018 23:44:57 +0100
Subject: [PATCH] Add icon for update PCB from Schematic

This previously used the "import board file" icon, which is a bit
confusing, as the action is not importing into a PCB.
---
 bitmaps_png/CMakeLists.txt  |   1 +
 bitmaps_png/cpp_26/update_pcb_from_sch.cpp  |  60 ++
 bitmaps_png/sources/update_pcb_from_sch.svg | 939 
 eeschema/menubar.cpp|   2 +-
 include/bitmaps.h   |   1 +
 pcbnew/menubar_pcb_editor.cpp   |   2 +-
 pcbnew/tool_pcb_editor.cpp  |   2 +-
 7 files changed, 1004 insertions(+), 3 deletions(-)
 create mode 100644 bitmaps_png/cpp_26/update_pcb_from_sch.cpp
 create mode 100644 bitmaps_png/sources/update_pcb_from_sch.svg

diff --git a/bitmaps_png/CMakeLists.txt b/bitmaps_png/CMakeLists.txt
index 645a804f4..91b21d43f 100644
--- a/bitmaps_png/CMakeLists.txt
+++ b/bitmaps_png/CMakeLists.txt
@@ -569,6 +569,7 @@ set( BMAPS_MID
 up
 update_fields
 update_module_board
+update_pcb_from_sch
 use_3D_copper_thickness
 via
 via_buried
diff --git a/bitmaps_png/cpp_26/update_pcb_from_sch.cpp b/bitmaps_png/cpp_26/update_pcb_from_sch.cpp
new file mode 100644
index 0..d6e2dc0ef
--- /dev/null
+++ b/bitmaps_png/cpp_26/update_pcb_from_sch.cpp
@@ -0,0 +1,60 @@
+
+/* Do not modify this file, it was automatically generated by the
+ * PNG2cpp CMake script, using a *.png file as input.
+ */
+
+#include 
+
+static const unsigned char png[] = {
+ 0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d, 0x49, 0x48, 0x44, 0x52,
+ 0x00, 0x00, 0x00, 0x1a, 0x00, 0x00, 0x00, 0x1a, 0x08, 0x02, 0x00, 0x00, 0x00, 0x26, 0x28, 0xdb,
+ 0x99, 0x00, 0x00, 0x02, 0xae, 0x49, 0x44, 0x41, 0x54, 0x48, 0xc7, 0x63, 0x30, 0x26, 0x0b, 0xa8,
+ 0xdb, 0xab, 0x33, 0xa4, 0x30, 0x60, 0x41, 0x40, 0xb9, 0x4f, 0xa8, 0x60, 0x01, 0x03, 0xc3, 0xe7,
+ 0xa7, 0x47, 0x81, 0xe4, 0x27, 0xdc, 0xc0, 0xab, 0xdf, 0x8b, 0x6a, 0xc6, 0x9d, 0xbd, 0x73, 0x96,
+ 0x29, 0x95, 0x89, 0x6a, 0xc6, 0xc5, 0xcc, 0x8a, 0xc1, 0x6e, 0x16, 0x56, 0xe3, 0x96, 0xf2, 0xf3,
+ 0x01, 0xcd, 0x02, 0x92, 0x58, 0xcd, 0xba, 0xf9, 0xf8, 0x06, 0x5b, 0x06, 0x1b, 0x09, 0xc6, 0x01,
+ 0x81, 0xdf, 0x2c, 0x36, 0x5c, 0x4e, 0xdb, 0x7d, 0x78, 0x1e, 0x44, 0x67, 0xc1, 0x44, 0xd7, 0xfb,
+ 0x7b, 0xbb, 0xd0, 0x10, 0x61, 0xe3, 0xbe, 0x7c, 0xf9, 0xf2, 0xe3, 0xc7, 0x0f, 0x20, 0x09, 0x64,
+ 0xbf, 0x7b, 0xf7, 0xea, 0xc1, 0x81, 0x09, 0xc8, 0xfa, 0x6f, 0xef, 0x6e, 0xdf, 0xb9, 0xae, 0xf8,
+ 0xea, 0xce, 0x16, 0x62, 0x8d, 0xfb, 0xfb, 0xf7, 0xef, 0xbc, 0x79, 0xf3, 0x80, 0xc6, 0x7d, 0xfb,
+ 0xf6, 0xad, 0x79, 0x63, 0xd3, 0xec, 0x45, 0x09, 0x70, 0xb3, 0x4e, 0x6c, 0xa9, 0x51, 0x2a, 0x96,
+ 0xe0, 0xcc, 0x60, 0x17, 0xcc, 0xe1, 0x59, 0xbd, 0x22, 0x0b, 0x61, 0x5c, 0x7a, 0x46, 0x6a, 0x68,
+ 0x78, 0x30, 0x10, 0x01, 0xd9, 0x17, 0x1e, 0x1c, 0x00, 0x1a, 0x77, 0xe1, 0xc1, 0x41, 0x48, 0x38,
+ 0xfe, 0xff, 0xff, 0x9f, 0x81, 0x81, 0x41, 0x53, 0x4f, 0xf5, 0xee, 0xdd, 0xbb, 0xf3, 0xf7, 0xce,
+ 0xe4, 0xc8, 0x60, 0xe7, 0xcf, 0xe2, 0x84, 0x20, 0xce, 0x0c, 0x36, 0xdf, 0xc9, 0xbe, 0x7f, 0xff,
+ 0xfd, 0x6d, 0xdd, 0xda, 0x6a, 0x51, 0xa3, 0x8e, 0xdd, 0x75, 0x8d, 0xdb, 0x02, 0x56, 0x9f, 0xef,
+ 0xfc, 0xf3, 0xf7, 0xf7, 0x7f, 0x18, 0x00, 0x1a, 0xe7, 0x56, 0x2f, 0xc0, 0x2f, 0xc4, 0xbd, 0x7e,
+ 0xfd, 0xfa, 0xfd, 0x37, 0xf6, 0x8b, 0x15, 0x8a, 0x41, 0x82, 0x8f, 0x39, 0x95, 0x39, 0x62, 0x66,
+ 0x04, 0x50, 0xc1, 0xc4, 0x3d, 0x13, 0x4d, 0xaa, 0x55, 0xa0, 0xc6, 0x41, 0xdc, 0x85, 0xe4, 0xba,
+ 0x83, 0xbf, 0xff, 0xfe, 0xe4, 0xe3, 0xe7, 0x65, 0x80, 0x01, 0x2e, 0x3e, 0xd6, 0xe2, 0x4b, 0x62,
+ 0x11, 0x0b, 0x05, 0x85, 0x24, 0x79, 0xea, 0x1a, 0x6a, 0x7e, 0x7e, 0xfb, 0x70, 0xeb, 0xf8, 0xdc,
+ 0x0b, 0xdb, 0x1b, 0xb7, 0xac, 0x29, 0x10, 0xcb, 0x13, 0x90, 0x2d, 0x91, 0xe2, 0xca, 0xe4, 0x58,
+ 0xb0, 0x24, 0x19, 0x67, 0xd8, 0x41, 0x5c, 0x04, 0x34, 0x02, 0x0d, 0x65, 0x1d, 0x14, 0x51, 0xb1,
+ 0x10, 0x74, 0xf1, 0x70, 0x7c, 0xf3, 0xe6, 0xd5, 0xf3, 0x6b, 0xdb, 0x81, 0xfa, 0xaf, 0xec, 0x68,
+ 0x5e, 0xb6, 0x2c, 0xfd, 0xd4, 0x96, 0x5a, 0x7c, 0x51, 0x81, 0xcb, 0x38, 0x20, 0x2a, 0x3c, 0x2f,
+ 0x66, 0x99, 0x2c, 0x20, 0xa7, 0x24, 0x75, 0xf1, 0xe2, 0xc5, 0xf7, 0x0f, 

Re: [Kicad-developers] Windows Builds

[Maciej Suminski]

Thank you all! It was the #1 issue with the 5.0 release.

Cheers,
Orson

On 07/25/2018 08:57 PM, Mark Roszko wrote:
> Appears Simon has handled it, the downloads are updated.
> 
> I installed it and it no longer asserts.
> 
> On Wed, Jul 25, 2018 at 1:20 PM Wayne Stambaugh  wrote:
>>
>> On 7/25/2018 12:54 PM, Mark Roszko wrote:
>>> * Simon's pull request.
>>>
>>> https://github.com/KiCad/kicad-winbuilder/pull/74
>>
>> Nick must have given me admin permissions so I merged Simon's pull
>> request.  The new release packages should be available shortly.  Do I
>> need to do anything to make sure the rebuilt packages are available on
>> the kicad download page?
>>
>>> On Wed, Jul 25, 2018 at 12:33 PM Wayne Stambaugh  
>>> wrote:

 I believe have github admin permissions at the org level.  Please post
 the link to Mark's pull request and I will see if I can merge it.

 On 7/25/2018 12:29 PM, Adam Wolf wrote:
> Does anyone else have admin permissions at the org level?
>
> On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh  > wrote:
>
> On 7/25/2018 11:15 AM, Mark Roszko wrote:
> > @Wayne, The hold up on Windows was that Nick went on vacation
> > basically the day after posting the first 5.0 build. So bad timing.>
> >
> >> I've changed it to Release for the time being (but someone still
> needs to accept my pull request in GitHub)
> >
> > Unforunately Nick is the only one with privs on the winbuilder repo 
> on
> > github unless someone else does from the organization level access
> > list.
>
> I guess we will have to wait until Nick returns from vacation to get
> this resolved.  Once he gets back, I'll ping him about having him 
> assign
> privileges to someone else as a backup so we don't get bit by this in
> the future.
>
> >
> >> RelWithDebInfo should generate the same code as Release, and
> after stripping debug information, the binaries should be identical.
> >
> > You know, looking at your commit, its interesting. Because PKGBUILD
> > which you change from RelWithDebInfo to Release explicitly was 
> always
> > fine, the nightlies never gave that assert (I checked).
> > But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
> > to DEBUG somehow?
> >
> > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
> mailto:simon.rich...@hogyros.de>> wrote:
> >>
> >> Hi,
> >>
> >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> >>
> >>> We should have created a release build of the stable version.
> I'm fine
> >>> with nightly builds having debugging information.  Stable releases
> >>> should not have debug info.
> >>
> >> These are built as RelWithDebInfo, and the debug information is
> stripped
> >> out during installation, or rather should be (we're trying to
> keep the
> >> MSYS build as close to a standard Linux/BSD build as possible,
> and they
> >> usually archive the debug information separately before
> stripping, which
> >> is why this mode is useful at all).
> >>
> >> I've changed it to Release for the time being (but someone still
> needs
> >> to accept my pull request in GitHub), but this is indicative of a
> bug in
> >> the build scripts. RelWithDebInfo should generate the same code as
> >> Release, and after stripping debug information, the binaries
> should be
> >> identical.
> >>
> >> There are two problems I see:
> >>
> >>  - we check explicitly if the build type is Release, which then
> doesn't
> >> match
> >>  - we have a redundant -DDEBUG which is explicitly set — release
> builds
> >> have -DNDEBUG, which is set by CMake already, and this is what 
> should
> >> switch debugging facilities like asserts.
> >>
> >> I've submitted a patch to get rid of -DDEBUG two years ago, I
> doubt it
> >> still applies. I can make a new one if it has a chance of being
> applied.
> >>
> >>Simon
> >>
> >> ___
> >> 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] Windows Builds

[Adam Wolf]

Nice work team!

On Wed, Jul 25, 2018, 1:57 PM Mark Roszko  wrote:

> Appears Simon has handled it, the downloads are updated.
>
> I installed it and it no longer asserts.
>
> On Wed, Jul 25, 2018 at 1:20 PM Wayne Stambaugh 
> wrote:
> >
> > On 7/25/2018 12:54 PM, Mark Roszko wrote:
> > > * Simon's pull request.
> > >
> > > https://github.com/KiCad/kicad-winbuilder/pull/74
> >
> > Nick must have given me admin permissions so I merged Simon's pull
> > request.  The new release packages should be available shortly.  Do I
> > need to do anything to make sure the rebuilt packages are available on
> > the kicad download page?
> >
> > > On Wed, Jul 25, 2018 at 12:33 PM Wayne Stambaugh 
> wrote:
> > >>
> > >> I believe have github admin permissions at the org level.  Please post
> > >> the link to Mark's pull request and I will see if I can merge it.
> > >>
> > >> On 7/25/2018 12:29 PM, Adam Wolf wrote:
> > >>> Does anyone else have admin permissions at the org level?
> > >>>
> > >>> On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh  > >>> > wrote:
> > >>>
> > >>> On 7/25/2018 11:15 AM, Mark Roszko wrote:
> > >>> > @Wayne, The hold up on Windows was that Nick went on vacation
> > >>> > basically the day after posting the first 5.0 build. So bad
> timing.>
> > >>> >
> > >>> >> I've changed it to Release for the time being (but someone
> still
> > >>> needs to accept my pull request in GitHub)
> > >>> >
> > >>> > Unforunately Nick is the only one with privs on the winbuilder
> repo on
> > >>> > github unless someone else does from the organization level
> access
> > >>> > list.
> > >>>
> > >>> I guess we will have to wait until Nick returns from vacation to
> get
> > >>> this resolved.  Once he gets back, I'll ping him about having
> him assign
> > >>> privileges to someone else as a backup so we don't get bit by
> this in
> > >>> the future.
> > >>>
> > >>> >
> > >>> >> RelWithDebInfo should generate the same code as Release, and
> > >>> after stripping debug information, the binaries should be
> identical.
> > >>> >
> > >>> > You know, looking at your commit, its interesting. Because
> PKGBUILD
> > >>> > which you change from RelWithDebInfo to Release explicitly was
> always
> > >>> > fine, the nightlies never gave that assert (I checked).
> > >>> > But PKGBUILD-STABLE had no config specifiedso perhaps it
> drifted
> > >>> > to DEBUG somehow?
> > >>> >
> > >>> > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
> > >>> mailto:simon.rich...@hogyros.de>>
> wrote:
> > >>> >>
> > >>> >> Hi,
> > >>> >>
> > >>> >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> > >>> >>
> > >>> >>> We should have created a release build of the stable version.
> > >>> I'm fine
> > >>> >>> with nightly builds having debugging information.  Stable
> releases
> > >>> >>> should not have debug info.
> > >>> >>
> > >>> >> These are built as RelWithDebInfo, and the debug information
> is
> > >>> stripped
> > >>> >> out during installation, or rather should be (we're trying to
> > >>> keep the
> > >>> >> MSYS build as close to a standard Linux/BSD build as possible,
> > >>> and they
> > >>> >> usually archive the debug information separately before
> > >>> stripping, which
> > >>> >> is why this mode is useful at all).
> > >>> >>
> > >>> >> I've changed it to Release for the time being (but someone
> still
> > >>> needs
> > >>> >> to accept my pull request in GitHub), but this is indicative
> of a
> > >>> bug in
> > >>> >> the build scripts. RelWithDebInfo should generate the same
> code as
> > >>> >> Release, and after stripping debug information, the binaries
> > >>> should be
> > >>> >> identical.
> > >>> >>
> > >>> >> There are two problems I see:
> > >>> >>
> > >>> >>  - we check explicitly if the build type is Release, which
> then
> > >>> doesn't
> > >>> >> match
> > >>> >>  - we have a redundant -DDEBUG which is explicitly set —
> release
> > >>> builds
> > >>> >> have -DNDEBUG, which is set by CMake already, and this is
> what should
> > >>> >> switch debugging facilities like asserts.
> > >>> >>
> > >>> >> I've submitted a patch to get rid of -DDEBUG two years ago, I
> > >>> doubt it
> > >>> >> still applies. I can make a new one if it has a chance of
> being
> > >>> applied.
> > >>> >>
> > >>> >>Simon
> > >>> >>
> > >>> >> ___
> > >>> >> Mailing list: https://launchpad.net/~kicad-developers
> > >>> 
> > >>> >> Post to : kicad-developers@lists.launchpad.net
> > >>> 
> > >>> >> Unsubscribe : https://launchpad.net/~kicad-developers
> > >>> 

Re: [Kicad-developers] Windows Builds

[Mark Roszko]

Appears Simon has handled it, the downloads are updated.

I installed it and it no longer asserts.

On Wed, Jul 25, 2018 at 1:20 PM Wayne Stambaugh  wrote:
>
> On 7/25/2018 12:54 PM, Mark Roszko wrote:
> > * Simon's pull request.
> >
> > https://github.com/KiCad/kicad-winbuilder/pull/74
>
> Nick must have given me admin permissions so I merged Simon's pull
> request.  The new release packages should be available shortly.  Do I
> need to do anything to make sure the rebuilt packages are available on
> the kicad download page?
>
> > On Wed, Jul 25, 2018 at 12:33 PM Wayne Stambaugh  
> > wrote:
> >>
> >> I believe have github admin permissions at the org level.  Please post
> >> the link to Mark's pull request and I will see if I can merge it.
> >>
> >> On 7/25/2018 12:29 PM, Adam Wolf wrote:
> >>> Does anyone else have admin permissions at the org level?
> >>>
> >>> On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh  >>> > wrote:
> >>>
> >>> On 7/25/2018 11:15 AM, Mark Roszko wrote:
> >>> > @Wayne, The hold up on Windows was that Nick went on vacation
> >>> > basically the day after posting the first 5.0 build. So bad timing.>
> >>> >
> >>> >> I've changed it to Release for the time being (but someone still
> >>> needs to accept my pull request in GitHub)
> >>> >
> >>> > Unforunately Nick is the only one with privs on the winbuilder repo 
> >>> on
> >>> > github unless someone else does from the organization level access
> >>> > list.
> >>>
> >>> I guess we will have to wait until Nick returns from vacation to get
> >>> this resolved.  Once he gets back, I'll ping him about having him 
> >>> assign
> >>> privileges to someone else as a backup so we don't get bit by this in
> >>> the future.
> >>>
> >>> >
> >>> >> RelWithDebInfo should generate the same code as Release, and
> >>> after stripping debug information, the binaries should be identical.
> >>> >
> >>> > You know, looking at your commit, its interesting. Because PKGBUILD
> >>> > which you change from RelWithDebInfo to Release explicitly was 
> >>> always
> >>> > fine, the nightlies never gave that assert (I checked).
> >>> > But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
> >>> > to DEBUG somehow?
> >>> >
> >>> > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
> >>> mailto:simon.rich...@hogyros.de>> wrote:
> >>> >>
> >>> >> Hi,
> >>> >>
> >>> >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> >>> >>
> >>> >>> We should have created a release build of the stable version.
> >>> I'm fine
> >>> >>> with nightly builds having debugging information.  Stable releases
> >>> >>> should not have debug info.
> >>> >>
> >>> >> These are built as RelWithDebInfo, and the debug information is
> >>> stripped
> >>> >> out during installation, or rather should be (we're trying to
> >>> keep the
> >>> >> MSYS build as close to a standard Linux/BSD build as possible,
> >>> and they
> >>> >> usually archive the debug information separately before
> >>> stripping, which
> >>> >> is why this mode is useful at all).
> >>> >>
> >>> >> I've changed it to Release for the time being (but someone still
> >>> needs
> >>> >> to accept my pull request in GitHub), but this is indicative of a
> >>> bug in
> >>> >> the build scripts. RelWithDebInfo should generate the same code as
> >>> >> Release, and after stripping debug information, the binaries
> >>> should be
> >>> >> identical.
> >>> >>
> >>> >> There are two problems I see:
> >>> >>
> >>> >>  - we check explicitly if the build type is Release, which then
> >>> doesn't
> >>> >> match
> >>> >>  - we have a redundant -DDEBUG which is explicitly set — release
> >>> builds
> >>> >> have -DNDEBUG, which is set by CMake already, and this is what 
> >>> should
> >>> >> switch debugging facilities like asserts.
> >>> >>
> >>> >> I've submitted a patch to get rid of -DDEBUG two years ago, I
> >>> doubt it
> >>> >> still applies. I can make a new one if it has a chance of being
> >>> applied.
> >>> >>
> >>> >>Simon
> >>> >>
> >>> >> ___
> >>> >> 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
> >>> 

Re: [Kicad-developers] Branches

[Simon Richter]

Hi,

On 25.07.2018 18:00, Wayne Stambaugh wrote:

> The 5.1 branch will go away.  I just haven't gotten around to it.

Even better.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] Windows Builds

[Wayne Stambaugh]

On 7/25/2018 12:54 PM, Mark Roszko wrote:
> * Simon's pull request.
> 
> https://github.com/KiCad/kicad-winbuilder/pull/74

Nick must have given me admin permissions so I merged Simon's pull
request.  The new release packages should be available shortly.  Do I
need to do anything to make sure the rebuilt packages are available on
the kicad download page?

> On Wed, Jul 25, 2018 at 12:33 PM Wayne Stambaugh  wrote:
>>
>> I believe have github admin permissions at the org level.  Please post
>> the link to Mark's pull request and I will see if I can merge it.
>>
>> On 7/25/2018 12:29 PM, Adam Wolf wrote:
>>> Does anyone else have admin permissions at the org level?
>>>
>>> On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh >> > wrote:
>>>
>>> On 7/25/2018 11:15 AM, Mark Roszko wrote:
>>> > @Wayne, The hold up on Windows was that Nick went on vacation
>>> > basically the day after posting the first 5.0 build. So bad timing.>
>>> >
>>> >> I've changed it to Release for the time being (but someone still
>>> needs to accept my pull request in GitHub)
>>> >
>>> > Unforunately Nick is the only one with privs on the winbuilder repo on
>>> > github unless someone else does from the organization level access
>>> > list.
>>>
>>> I guess we will have to wait until Nick returns from vacation to get
>>> this resolved.  Once he gets back, I'll ping him about having him assign
>>> privileges to someone else as a backup so we don't get bit by this in
>>> the future.
>>>
>>> >
>>> >> RelWithDebInfo should generate the same code as Release, and
>>> after stripping debug information, the binaries should be identical.
>>> >
>>> > You know, looking at your commit, its interesting. Because PKGBUILD
>>> > which you change from RelWithDebInfo to Release explicitly was always
>>> > fine, the nightlies never gave that assert (I checked).
>>> > But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
>>> > to DEBUG somehow?
>>> >
>>> > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
>>> mailto:simon.rich...@hogyros.de>> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
>>> >>
>>> >>> We should have created a release build of the stable version.
>>> I'm fine
>>> >>> with nightly builds having debugging information.  Stable releases
>>> >>> should not have debug info.
>>> >>
>>> >> These are built as RelWithDebInfo, and the debug information is
>>> stripped
>>> >> out during installation, or rather should be (we're trying to
>>> keep the
>>> >> MSYS build as close to a standard Linux/BSD build as possible,
>>> and they
>>> >> usually archive the debug information separately before
>>> stripping, which
>>> >> is why this mode is useful at all).
>>> >>
>>> >> I've changed it to Release for the time being (but someone still
>>> needs
>>> >> to accept my pull request in GitHub), but this is indicative of a
>>> bug in
>>> >> the build scripts. RelWithDebInfo should generate the same code as
>>> >> Release, and after stripping debug information, the binaries
>>> should be
>>> >> identical.
>>> >>
>>> >> There are two problems I see:
>>> >>
>>> >>  - we check explicitly if the build type is Release, which then
>>> doesn't
>>> >> match
>>> >>  - we have a redundant -DDEBUG which is explicitly set — release
>>> builds
>>> >> have -DNDEBUG, which is set by CMake already, and this is what should
>>> >> switch debugging facilities like asserts.
>>> >>
>>> >> I've submitted a patch to get rid of -DDEBUG two years ago, I
>>> doubt it
>>> >> still applies. I can make a new one if it has a chance of being
>>> applied.
>>> >>
>>> >>Simon
>>> >>
>>> >> ___
>>> >> 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
>> 

Re: [Kicad-developers] Windows Builds

[Simon Richter]

Hi,

On 25.07.2018 18:18, Wayne Stambaugh wrote:

> I guess we will have to wait until Nick returns from vacation to get
> this resolved.

I just pointed Jenkins at my fork, but that's bad style, basically.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] Windows Builds

[Mark Roszko]

* Simon's pull request.

https://github.com/KiCad/kicad-winbuilder/pull/74
On Wed, Jul 25, 2018 at 12:33 PM Wayne Stambaugh  wrote:
>
> I believe have github admin permissions at the org level.  Please post
> the link to Mark's pull request and I will see if I can merge it.
>
> On 7/25/2018 12:29 PM, Adam Wolf wrote:
> > Does anyone else have admin permissions at the org level?
> >
> > On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh  > > wrote:
> >
> > On 7/25/2018 11:15 AM, Mark Roszko wrote:
> > > @Wayne, The hold up on Windows was that Nick went on vacation
> > > basically the day after posting the first 5.0 build. So bad timing.>
> > >
> > >> I've changed it to Release for the time being (but someone still
> > needs to accept my pull request in GitHub)
> > >
> > > Unforunately Nick is the only one with privs on the winbuilder repo on
> > > github unless someone else does from the organization level access
> > > list.
> >
> > I guess we will have to wait until Nick returns from vacation to get
> > this resolved.  Once he gets back, I'll ping him about having him assign
> > privileges to someone else as a backup so we don't get bit by this in
> > the future.
> >
> > >
> > >> RelWithDebInfo should generate the same code as Release, and
> > after stripping debug information, the binaries should be identical.
> > >
> > > You know, looking at your commit, its interesting. Because PKGBUILD
> > > which you change from RelWithDebInfo to Release explicitly was always
> > > fine, the nightlies never gave that assert (I checked).
> > > But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
> > > to DEBUG somehow?
> > >
> > > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
> > mailto:simon.rich...@hogyros.de>> wrote:
> > >>
> > >> Hi,
> > >>
> > >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> > >>
> > >>> We should have created a release build of the stable version.
> > I'm fine
> > >>> with nightly builds having debugging information.  Stable releases
> > >>> should not have debug info.
> > >>
> > >> These are built as RelWithDebInfo, and the debug information is
> > stripped
> > >> out during installation, or rather should be (we're trying to
> > keep the
> > >> MSYS build as close to a standard Linux/BSD build as possible,
> > and they
> > >> usually archive the debug information separately before
> > stripping, which
> > >> is why this mode is useful at all).
> > >>
> > >> I've changed it to Release for the time being (but someone still
> > needs
> > >> to accept my pull request in GitHub), but this is indicative of a
> > bug in
> > >> the build scripts. RelWithDebInfo should generate the same code as
> > >> Release, and after stripping debug information, the binaries
> > should be
> > >> identical.
> > >>
> > >> There are two problems I see:
> > >>
> > >>  - we check explicitly if the build type is Release, which then
> > doesn't
> > >> match
> > >>  - we have a redundant -DDEBUG which is explicitly set — release
> > builds
> > >> have -DNDEBUG, which is set by CMake already, and this is what should
> > >> switch debugging facilities like asserts.
> > >>
> > >> I've submitted a patch to get rid of -DDEBUG two years ago, I
> > doubt it
> > >> still applies. I can make a new one if it has a chance of being
> > applied.
> > >>
> > >>Simon
> > >>
> > >> ___
> > >> 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



-- 
Mark

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : 

Re: [Kicad-developers] Windows Builds

[Wayne Stambaugh]

I believe have github admin permissions at the org level.  Please post
the link to Mark's pull request and I will see if I can merge it.

On 7/25/2018 12:29 PM, Adam Wolf wrote:
> Does anyone else have admin permissions at the org level?
> 
> On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh  > wrote:
> 
> On 7/25/2018 11:15 AM, Mark Roszko wrote:
> > @Wayne, The hold up on Windows was that Nick went on vacation
> > basically the day after posting the first 5.0 build. So bad timing.>
> >
> >> I've changed it to Release for the time being (but someone still
> needs to accept my pull request in GitHub)
> >
> > Unforunately Nick is the only one with privs on the winbuilder repo on
> > github unless someone else does from the organization level access
> > list.
> 
> I guess we will have to wait until Nick returns from vacation to get
> this resolved.  Once he gets back, I'll ping him about having him assign
> privileges to someone else as a backup so we don't get bit by this in
> the future.
> 
> >
> >> RelWithDebInfo should generate the same code as Release, and
> after stripping debug information, the binaries should be identical.
> >
> > You know, looking at your commit, its interesting. Because PKGBUILD
> > which you change from RelWithDebInfo to Release explicitly was always
> > fine, the nightlies never gave that assert (I checked).
> > But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
> > to DEBUG somehow?
> >
> > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
> mailto:simon.rich...@hogyros.de>> wrote:
> >>
> >> Hi,
> >>
> >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> >>
> >>> We should have created a release build of the stable version. 
> I'm fine
> >>> with nightly builds having debugging information.  Stable releases
> >>> should not have debug info.
> >>
> >> These are built as RelWithDebInfo, and the debug information is
> stripped
> >> out during installation, or rather should be (we're trying to
> keep the
> >> MSYS build as close to a standard Linux/BSD build as possible,
> and they
> >> usually archive the debug information separately before
> stripping, which
> >> is why this mode is useful at all).
> >>
> >> I've changed it to Release for the time being (but someone still
> needs
> >> to accept my pull request in GitHub), but this is indicative of a
> bug in
> >> the build scripts. RelWithDebInfo should generate the same code as
> >> Release, and after stripping debug information, the binaries
> should be
> >> identical.
> >>
> >> There are two problems I see:
> >>
> >>  - we check explicitly if the build type is Release, which then
> doesn't
> >> match
> >>  - we have a redundant -DDEBUG which is explicitly set — release
> builds
> >> have -DNDEBUG, which is set by CMake already, and this is what should
> >> switch debugging facilities like asserts.
> >>
> >> I've submitted a patch to get rid of -DDEBUG two years ago, I
> doubt it
> >> still applies. I can make a new one if it has a chance of being
> applied.
> >>
> >>    Simon
> >>
> >> ___
> >> 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] Windows Builds

[Adam Wolf]

Does anyone else have admin permissions at the org level?

On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh  wrote:

> On 7/25/2018 11:15 AM, Mark Roszko wrote:
> > @Wayne, The hold up on Windows was that Nick went on vacation
> > basically the day after posting the first 5.0 build. So bad timing.>
> >
> >> I've changed it to Release for the time being (but someone still needs
> to accept my pull request in GitHub)
> >
> > Unforunately Nick is the only one with privs on the winbuilder repo on
> > github unless someone else does from the organization level access
> > list.
>
> I guess we will have to wait until Nick returns from vacation to get
> this resolved.  Once he gets back, I'll ping him about having him assign
> privileges to someone else as a backup so we don't get bit by this in
> the future.
>
> >
> >> RelWithDebInfo should generate the same code as Release, and after
> stripping debug information, the binaries should be identical.
> >
> > You know, looking at your commit, its interesting. Because PKGBUILD
> > which you change from RelWithDebInfo to Release explicitly was always
> > fine, the nightlies never gave that assert (I checked).
> > But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
> > to DEBUG somehow?
> >
> > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter 
> wrote:
> >>
> >> Hi,
> >>
> >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> >>
> >>> We should have created a release build of the stable version.  I'm fine
> >>> with nightly builds having debugging information.  Stable releases
> >>> should not have debug info.
> >>
> >> These are built as RelWithDebInfo, and the debug information is stripped
> >> out during installation, or rather should be (we're trying to keep the
> >> MSYS build as close to a standard Linux/BSD build as possible, and they
> >> usually archive the debug information separately before stripping, which
> >> is why this mode is useful at all).
> >>
> >> I've changed it to Release for the time being (but someone still needs
> >> to accept my pull request in GitHub), but this is indicative of a bug in
> >> the build scripts. RelWithDebInfo should generate the same code as
> >> Release, and after stripping debug information, the binaries should be
> >> identical.
> >>
> >> There are two problems I see:
> >>
> >>  - we check explicitly if the build type is Release, which then doesn't
> >> match
> >>  - we have a redundant -DDEBUG which is explicitly set — release builds
> >> have -DNDEBUG, which is set by CMake already, and this is what should
> >> switch debugging facilities like asserts.
> >>
> >> I've submitted a patch to get rid of -DDEBUG two years ago, I doubt it
> >> still applies. I can make a new one if it has a chance of being applied.
> >>
> >>Simon
> >>
> >> ___
> >> 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] Board setup icon

[Wayne Stambaugh]

Fabrizio,

On 7/25/2018 9:05 AM, Fabrizio Tappero wrote:
> Hi Guys,
> I just wold like to remind you that if you decide to personalize kicad
> icons, kicad will end up with a lot of icons to maintain.
> 
> Currently kicad is using really a lot of icons and few years ago we
> tried to simplified them so that icons could be reused. This is useful
> when you try to give consistancy to the overall looks of KiCad GUI.
> 
> What you guys are doing is maybe going back to what was kicad few
> years ago. I am not saying that this is a bad thing, mine is just a
> very generic comment and might not even apply to these icons in
> particular. I just would like to give you guys a larger overview of
> the icon situation.
> 
> The "property" option is (often) defined with a cog wheel. It is not
> unusual for open source projects to quickly develop 25 property icons
> made with a smaller cog wheel overlaid an other icon. How, this visual
> technique might not be the best option. Overlay tiny images to convey
> specific meaning might not lead to a present use of the GUI.
> 
> Also, I will not enter into tiny image pixel alignment problem because
> we did it so many time in the last 5 years here but instead I would
> love to propose to begin talking about the use of vector format icons
> and possible the use of script to combine icons.

I don't know if wx 3.1 supports vector image formats in controls on not.
 Unfortunately, the 3.0 branch does not so we are stuck with raster
images for the foreseeable future.  When a version of wx is widely
available that supports vector graphics in controls, I will be more than
happy to dump the bitmaps.

Wayne

> 
> Just my 2c
> 
> Cheers
> Fabrizio
> 
> On Wed, Jul 25, 2018 at 12:45 PM John Beard  wrote:
>>
>> Hi Jeff,
>>
>> Sure thing! Here they are.
>>
>> I have modified part_properties (patch 1) and create field_properties
>> and used in the menu and toolbar (patch 2).
>>
>> Attached are the PNGs for reference.
>>
>> Cheers,
>>
>> John
>>
>> On Tue, Jul 24, 2018 at 8:35 PM, Jeff Young  wrote:
>>> Hi John,
>>>
>>> When you get a chance could you also edit the part_properties_xpm icon to 
>>> be the op-amp with a gear over it?
>>>
>>> Oh, and a new icon with the op-amp with a little ’T’ in the bottom right 
>>> corner would be great.
>>>
>>> (Both are for the symbol editor.  They’re currently just a generic gear and 
>>> a generic ’T’.)
>>>
>>> Thanks,
>>> Jeff.
>>>
>>>
 On 24 Jul 2018, at 16:56, Jeff Young  wrote:

 I’ve merged your icon, John.  Thanks for your contribution!

> On 24 Jul 2018, at 12:35, John Beard  wrote:
>
> Hi,
>
> Here is a new icon for the board setup toolbar and menu item. The
> generic gear icon is no clear, as it looks like "Preferences" rather
> than board setup.
>
> PNG included for reference only.
>
> Cheers,
>
> John
> <0001-Pcbnew-add-new-icon-for-board-setup.patch>___
> 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
> 

___
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] Windows Builds

[Wayne Stambaugh]

On 7/25/2018 11:15 AM, Mark Roszko wrote:
> @Wayne, The hold up on Windows was that Nick went on vacation
> basically the day after posting the first 5.0 build. So bad timing.>
> 
>> I've changed it to Release for the time being (but someone still needs to 
>> accept my pull request in GitHub)
> 
> Unforunately Nick is the only one with privs on the winbuilder repo on
> github unless someone else does from the organization level access
> list.

I guess we will have to wait until Nick returns from vacation to get
this resolved.  Once he gets back, I'll ping him about having him assign
privileges to someone else as a backup so we don't get bit by this in
the future.

> 
>> RelWithDebInfo should generate the same code as Release, and after stripping 
>> debug information, the binaries should be identical.
> 
> You know, looking at your commit, its interesting. Because PKGBUILD
> which you change from RelWithDebInfo to Release explicitly was always
> fine, the nightlies never gave that assert (I checked).
> But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
> to DEBUG somehow?
> 
> On Wed, Jul 25, 2018 at 9:09 AM Simon Richter  
> wrote:
>>
>> Hi,
>>
>> On 25.07.2018 14:16, Wayne Stambaugh wrote:
>>
>>> We should have created a release build of the stable version.  I'm fine
>>> with nightly builds having debugging information.  Stable releases
>>> should not have debug info.
>>
>> These are built as RelWithDebInfo, and the debug information is stripped
>> out during installation, or rather should be (we're trying to keep the
>> MSYS build as close to a standard Linux/BSD build as possible, and they
>> usually archive the debug information separately before stripping, which
>> is why this mode is useful at all).
>>
>> I've changed it to Release for the time being (but someone still needs
>> to accept my pull request in GitHub), but this is indicative of a bug in
>> the build scripts. RelWithDebInfo should generate the same code as
>> Release, and after stripping debug information, the binaries should be
>> identical.
>>
>> There are two problems I see:
>>
>>  - we check explicitly if the build type is Release, which then doesn't
>> match
>>  - we have a redundant -DDEBUG which is explicitly set — release builds
>> have -DNDEBUG, which is set by CMake already, and this is what should
>> switch debugging facilities like asserts.
>>
>> I've submitted a patch to get rid of -DDEBUG two years ago, I doubt it
>> still applies. I can make a new one if it has a chance of being applied.
>>
>>Simon
>>
>> ___
>> 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] Branches

[Wayne Stambaugh]

I thought I made it clear what the current branches were for but I will
officially reiterate my previous comments.

The development branch is currently only open for 5.1 development.  This
includes 5.0 bug fixes, Jeff's UI refactoring, and the GTK3 fixes.  No
new features will be allowed until 5.1 is released.  I want to stay
focused on 5.1 to get the gtk3 fix release asap.  My fear is that if I
open the dev branch up to new features, we will get caught up in that
and forget about the gtk3 fix.

The 5.1 branch will go away.  I just haven't gotten around to it.

The only thing left to do is figure out the branch naming issue.
Apparently we cannot come up with a branch naming convention that
doesn't cause everyone to run out of the room with their hair on fire. :)

If anyone asks again what the official policy is, please point them to
this message.

Cheers,

Wayne

On 7/25/2018 8:45 AM, Simon Richter wrote:
> Hi,
> 
> On 24.07.2018 09:01, Maciej Sumiński wrote:
> 
>> At the moment the master branch contains all commits from 5.1 and a few
>> more. It might be the right moment to drop 5.1 branch.
> 
> As it should be. Well, ideally commits on 5.1 should be cherry-picked
> from master by the 5.1 release manager.
> 
> Do we have a release manager for 5.1? Or a scope for the release?
> 
> My suggestion:
> 
>  - 5.1: gtk3 (because that is what distros are waiting for)
>  - 5.2: UI updates (after 5.1 because they need user feedback and
> documentation updates)
> 
>Simon



___
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] [RFC] Op-amp symbol icons

[John Beard]

Hi,

The pixel alignment of the op-amp icons looks a bit fuzzy compared to
the other newer icons. These are not the only misaligned icons, but
they are a very prominent set of them.

The problem is that both:

1) The lines are not on the pixel grid
2) The lines are not a whole number of pixels wide.

If this *were* to be changed so horizontal lines are sharp, the icons
have to be modified. However, going up to 2px or down to 1px line
width changes the feel a bit.

Attached are some options (for the full size op-amp icons at 26px). If
a consensus or executive decision ever emerges, I will produce a patch
for the op-amp icons in that style.

Personally, my "vote" is 2A, or 5A for icons where the symbol is
smaller, like "copycomponent".

List of icons affected for reference:

 add_component.svg
 copycomponent.svg
 edit_cmp_symb_links.svg
 edit_comp_footprint.svg
 edit_comp_ref.svg
 edit_comp_value.svg
 edit_component.svg
 edit_part.svg
 export_part.svg
 field_properties.svg
 hidden_pin.svg
 icon_libedit.svg
 import_cmp_from_lib.svg
 import_part.svg
 libedit.svg
 new_component.svg
 new_cvpcb.svg
 part_properties.svg
 save_part.svg
 save_part_in_mem.svg

Yours, bike-sheddingly,

John
___
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] Windows Builds

[Mark Roszko]

@Wayne, The hold up on Windows was that Nick went on vacation
basically the day after posting the first 5.0 build. So bad timing.


>I've changed it to Release for the time being (but someone still needs to 
>accept my pull request in GitHub)

Unforunately Nick is the only one with privs on the winbuilder repo on
github unless someone else does from the organization level access
list.

>RelWithDebInfo should generate the same code as Release, and after stripping 
>debug information, the binaries should be identical.

You know, looking at your commit, its interesting. Because PKGBUILD
which you change from RelWithDebInfo to Release explicitly was always
fine, the nightlies never gave that assert (I checked).
But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
to DEBUG somehow?

On Wed, Jul 25, 2018 at 9:09 AM Simon Richter  wrote:
>
> Hi,
>
> On 25.07.2018 14:16, Wayne Stambaugh wrote:
>
> > We should have created a release build of the stable version.  I'm fine
> > with nightly builds having debugging information.  Stable releases
> > should not have debug info.
>
> These are built as RelWithDebInfo, and the debug information is stripped
> out during installation, or rather should be (we're trying to keep the
> MSYS build as close to a standard Linux/BSD build as possible, and they
> usually archive the debug information separately before stripping, which
> is why this mode is useful at all).
>
> I've changed it to Release for the time being (but someone still needs
> to accept my pull request in GitHub), but this is indicative of a bug in
> the build scripts. RelWithDebInfo should generate the same code as
> Release, and after stripping debug information, the binaries should be
> identical.
>
> There are two problems I see:
>
>  - we check explicitly if the build type is Release, which then doesn't
> match
>  - we have a redundant -DDEBUG which is explicitly set — release builds
> have -DNDEBUG, which is set by CMake already, and this is what should
> switch debugging facilities like asserts.
>
> I've submitted a patch to get rid of -DDEBUG two years ago, I doubt it
> still applies. I can make a new one if it has a chance of being applied.
>
>Simon
>
> ___
> 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



-- 
Mark

___
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] Board setup icon

[Jeff Young]

Hi Fabrizio,

I think we’re moving in both directions at once.  Where there is only a single 
context, I favour the generic icons (for instance, we’re moving to using a 
generic save icon in contexts where that isn’t ambiguous).  However, where 
multiple contexts are visible at once (such as in LibEdit where we had both 
Edit Symbol Fields and Place Text using the ’T’ icon), I favour making them 
specific.

Cheers,
Jeff.


> On 25 Jul 2018, at 14:05, Fabrizio Tappero  wrote:
> 
> Hi Guys,
> I just wold like to remind you that if you decide to personalize kicad
> icons, kicad will end up with a lot of icons to maintain.
> 
> Currently kicad is using really a lot of icons and few years ago we
> tried to simplified them so that icons could be reused. This is useful
> when you try to give consistancy to the overall looks of KiCad GUI.
> 
> What you guys are doing is maybe going back to what was kicad few
> years ago. I am not saying that this is a bad thing, mine is just a
> very generic comment and might not even apply to these icons in
> particular. I just would like to give you guys a larger overview of
> the icon situation.
> 
> The "property" option is (often) defined with a cog wheel. It is not
> unusual for open source projects to quickly develop 25 property icons
> made with a smaller cog wheel overlaid an other icon. How, this visual
> technique might not be the best option. Overlay tiny images to convey
> specific meaning might not lead to a present use of the GUI.
> 
> Also, I will not enter into tiny image pixel alignment problem because
> we did it so many time in the last 5 years here but instead I would
> love to propose to begin talking about the use of vector format icons
> and possible the use of script to combine icons.
> 
> Just my 2c
> 
> Cheers
> Fabrizio
> 
> On Wed, Jul 25, 2018 at 12:45 PM John Beard  > wrote:
>> 
>> Hi Jeff,
>> 
>> Sure thing! Here they are.
>> 
>> I have modified part_properties (patch 1) and create field_properties
>> and used in the menu and toolbar (patch 2).
>> 
>> Attached are the PNGs for reference.
>> 
>> Cheers,
>> 
>> John
>> 
>> On Tue, Jul 24, 2018 at 8:35 PM, Jeff Young  wrote:
>>> Hi John,
>>> 
>>> When you get a chance could you also edit the part_properties_xpm icon to 
>>> be the op-amp with a gear over it?
>>> 
>>> Oh, and a new icon with the op-amp with a little ’T’ in the bottom right 
>>> corner would be great.
>>> 
>>> (Both are for the symbol editor.  They’re currently just a generic gear and 
>>> a generic ’T’.)
>>> 
>>> Thanks,
>>> Jeff.
>>> 
>>> 
 On 24 Jul 2018, at 16:56, Jeff Young  wrote:
 
 I’ve merged your icon, John.  Thanks for your contribution!
 
> On 24 Jul 2018, at 12:35, John Beard  wrote:
> 
> Hi,
> 
> Here is a new icon for the board setup toolbar and menu item. The
> generic gear icon is no clear, as it looks like "Preferences" rather
> than board setup.
> 
> PNG included for reference only.
> 
> Cheers,
> 
> John
> <0001-Pcbnew-add-new-icon-for-board-setup.patch>___
> 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] Board setup icon

[Jeff Young]

Thanks, John!

> On 25 Jul 2018, at 11:44, John Beard  wrote:
> 
> Hi Jeff,
> 
> Sure thing! Here they are.
> 
> I have modified part_properties (patch 1) and create field_properties
> and used in the menu and toolbar (patch 2).
> 
> Attached are the PNGs for reference.
> 
> Cheers,
> 
> John
> 
> On Tue, Jul 24, 2018 at 8:35 PM, Jeff Young  wrote:
>> Hi John,
>> 
>> When you get a chance could you also edit the part_properties_xpm icon to be 
>> the op-amp with a gear over it?
>> 
>> Oh, and a new icon with the op-amp with a little ’T’ in the bottom right 
>> corner would be great.
>> 
>> (Both are for the symbol editor.  They’re currently just a generic gear and 
>> a generic ’T’.)
>> 
>> Thanks,
>> Jeff.
>> 
>> 
>>> On 24 Jul 2018, at 16:56, Jeff Young  wrote:
>>> 
>>> I’ve merged your icon, John.  Thanks for your contribution!
>>> 
 On 24 Jul 2018, at 12:35, John Beard  wrote:
 
 Hi,
 
 Here is a new icon for the board setup toolbar and menu item. The
 generic gear icon is no clear, as it looks like "Preferences" rather
 than board setup.
 
 PNG included for reference only.
 
 Cheers,
 
 John
 <0001-Pcbnew-add-new-icon-for-board-setup.patch>___
 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
>> 
> <0001-New-part-properties-icon-opamp-gear.patch><0002-Add-field-properties-icon-opamp-T.patch>


___
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] Hotkeys in GAL

[John Beard]

On Wed, Jul 25, 2018 at 8:45 AM, Maciej Sumiński
 wrote:
>
> I would not mind adding more hotkeys, I think the primary reason is that
> not every action is executed often enough to justify a hotkey. Even with
> the current configuration it might be challenging to find a free hotkey
> for an action.
>
> The initial idea was to list all TOOL_ACTIONs in the hotkey editor, so
> the user may decide for himself which actions should have a hotkey
> assigned.

That is what I was thinking too - have the more esoteric ones
unassigned by default.

> It might be somewhat tricky to implement with legacy canvas
> still in place, so perhaps the right moment will come when legacy canvas
> is out.

OK, that makes sense.

> I imagine we could have subsections in
> the editor that are specific to tools and these would be acceptable
> duplicates with global and other contexts hotkeys.

That sounds sensible. If the hotkey dialog knew which TOOL_ACTIONs
were AS_GLOBAL and AS_CONTEXT, it could then only disallow multiple
AS_GLOBAL bindings of the same key, or multiple AS_CONTEXTs actions
within the same tool group (eg. pcbnew.InteractiveRouter).

This probably can't be easily done while the legacy code also uses the
dialog, as it requires each hotkey binding to know the global/context
aspect and the tool group.

I'll hold off doing much more until the legacy canvas is on the way out.

Cheers,

John

___
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] Board setup icon

[John Beard]

Hi Fabrizio,

I agree with the principle, and I am happy that we have lost the huge
number of item-specific icons in GAL menus compared to Legacy.

To be honest, I don't care what the metaphor for "board properties"
is. However, I think it is unhelpful to use a generic "properties"
icon in the "global" context (on the menubar), as it is very unclear
what that icon does. Doubly so when the icon is historically and
currently also used for "Preferences".

Ditto for the two icons Jeff requested: the old icons both exist and
mean something totally different elsewhere. For the "T" icon, it's
even on the same screen.

If an icon is used in a specific context (e.g. you're in a text editor
dialog), then the generic icon should be used as that's the simpler
metaphor).

As I said to Andrey, I will generate patches for any proposed SVG
source files, as I am set up to do it, and I know it's a bit of a
fiddle.

Cheers,

John

On Wed, Jul 25, 2018 at 2:05 PM, Fabrizio Tappero
 wrote:
> Hi Guys,
> I just wold like to remind you that if you decide to personalize kicad
> icons, kicad will end up with a lot of icons to maintain.
>
> Currently kicad is using really a lot of icons and few years ago we
> tried to simplified them so that icons could be reused. This is useful
> when you try to give consistancy to the overall looks of KiCad GUI.
>
> What you guys are doing is maybe going back to what was kicad few
> years ago. I am not saying that this is a bad thing, mine is just a
> very generic comment and might not even apply to these icons in
> particular. I just would like to give you guys a larger overview of
> the icon situation.
>
> The "property" option is (often) defined with a cog wheel. It is not
> unusual for open source projects to quickly develop 25 property icons
> made with a smaller cog wheel overlaid an other icon. How, this visual
> technique might not be the best option. Overlay tiny images to convey
> specific meaning might not lead to a present use of the GUI.
>
> Also, I will not enter into tiny image pixel alignment problem because
> we did it so many time in the last 5 years here but instead I would
> love to propose to begin talking about the use of vector format icons
> and possible the use of script to combine icons.
>
> Just my 2c
>
> Cheers
> Fabrizio
>
> On Wed, Jul 25, 2018 at 12:45 PM John Beard  wrote:
>>
>> Hi Jeff,
>>
>> Sure thing! Here they are.
>>
>> I have modified part_properties (patch 1) and create field_properties
>> and used in the menu and toolbar (patch 2).
>>
>> Attached are the PNGs for reference.
>>
>> Cheers,
>>
>> John
>>
>> On Tue, Jul 24, 2018 at 8:35 PM, Jeff Young  wrote:
>> > Hi John,
>> >
>> > When you get a chance could you also edit the part_properties_xpm icon to 
>> > be the op-amp with a gear over it?
>> >
>> > Oh, and a new icon with the op-amp with a little ’T’ in the bottom right 
>> > corner would be great.
>> >
>> > (Both are for the symbol editor.  They’re currently just a generic gear 
>> > and a generic ’T’.)
>> >
>> > Thanks,
>> > Jeff.
>> >
>> >
>> >> On 24 Jul 2018, at 16:56, Jeff Young  wrote:
>> >>
>> >> I’ve merged your icon, John.  Thanks for your contribution!
>> >>
>> >>> On 24 Jul 2018, at 12:35, John Beard  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> Here is a new icon for the board setup toolbar and menu item. The
>> >>> generic gear icon is no clear, as it looks like "Preferences" rather
>> >>> than board setup.
>> >>>
>> >>> PNG included for reference only.
>> >>>
>> >>> Cheers,
>> >>>
>> >>> John
>> >>> <0001-Pcbnew-add-new-icon-for-board-setup.patch>___
>> >>> 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] Windows Builds

[Simon Richter]

Hi,

On 25.07.2018 14:16, Wayne Stambaugh wrote:

> We should have created a release build of the stable version.  I'm fine
> with nightly builds having debugging information.  Stable releases
> should not have debug info.

These are built as RelWithDebInfo, and the debug information is stripped
out during installation, or rather should be (we're trying to keep the
MSYS build as close to a standard Linux/BSD build as possible, and they
usually archive the debug information separately before stripping, which
is why this mode is useful at all).

I've changed it to Release for the time being (but someone still needs
to accept my pull request in GitHub), but this is indicative of a bug in
the build scripts. RelWithDebInfo should generate the same code as
Release, and after stripping debug information, the binaries should be
identical.

There are two problems I see:

 - we check explicitly if the build type is Release, which then doesn't
match
 - we have a redundant -DDEBUG which is explicitly set — release builds
have -DNDEBUG, which is set by CMake already, and this is what should
switch debugging facilities like asserts.

I've submitted a patch to get rid of -DDEBUG two years ago, I doubt it
still applies. I can make a new one if it has a chance of being applied.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] The version string in the master branch

[Simon Richter]

Hi,

On 25.07.2018 14:25, Wayne Stambaugh wrote:

> It seems to me that 5.1.0-dev would sort before 5.1.0-rc1 or am I
> missing something?

We already have tricks in place to sort RC before the release (without
suffix), which is annoying as is but an established convention.

IMO, any tag that begins with "5.1" should be close to the "5.1"
release. This is true for RC tags and the release tag, but not for a
"-dev" tag, so that tag should not exist.

Branches are a complication there in that for branches that are
essentially feature branches like 5.1, the tags don't apply to the
master branch, so after the 5.1 release, the master would still show
"5.0-3254+g3423425234". This can be fixed by doing a merge commit that
formally brings 5.1 back into master (which would be a no-op unless
someone messed up), at which point git-describe would find the 5.1 tag
as nearest.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] Branches

[Simon Richter]

Hi,

On 24.07.2018 09:01, Maciej Sumiński wrote:

> At the moment the master branch contains all commits from 5.1 and a few
> more. It might be the right moment to drop 5.1 branch.

As it should be. Well, ideally commits on 5.1 should be cherry-picked
from master by the 5.1 release manager.

Do we have a release manager for 5.1? Or a scope for the release?

My suggestion:

 - 5.1: gtk3 (because that is what distros are waiting for)
 - 5.2: UI updates (after 5.1 because they need user feedback and
documentation updates)

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] Windows Builds

[Adam Wolf]

(Marek and I did pull the macOS builds, and I regenerated it as
Release and got everything all fixed up on the website.)
On Wed, Jul 25, 2018 at 7:31 AM Wayne Stambaugh  wrote:
>
> We should have created a release build of the stable version.  I'm fine
> with nightly builds having debugging information.  Stable releases
> should not have debug info.
>
> On 7/25/2018 8:10 AM, Jakub Kozdon wrote:
> > There are probably in http://downloads.kicad-pcb.org/windows/testing/
> > instead of stable.
> >
> > Dne 25.7.2018 v 13:51 Wayne Stambaugh napsal(a):
> >> I thought we created a new windows release build to prevent the
> >> assertions.  Did that not happen?
> >>
> >> On 7/25/2018 7:01 AM, Andrew Lutsenko wrote:
> >>> Were the windows builds ever fixed?
> >>> I downloaded 5.0 today and get a wxWidgets assert simply from clicking
> >>> on tools menu in Pcbnew.
> >>> kicadassert.png
> >>>
> >>>
> >>> On Mon, Jul 23, 2018 at 6:34 AM Wayne Stambaugh  >>> > wrote:
> >>>
> >>>  I'm fine with creating a packaging document.  We could add it to
> >>> the
> >>>  developers documentation or it could also be an external
> >>> document with a
> >>>  link in the compiling doc.
> >>>
> >>>  Wayne
> >>>
> >>>  On 7/23/2018 8:40 AM, Adam Wolf wrote:
> >>>  > Agreed, Wayne. The macOS 5.0.0-1 build is uploading right now.
> >>> It is a
> >>>  > Release build.
> >>>  >
> >>>  > I have a small set of packaging tests I perform on releases
> >>> before
> >>>  > uploading them.  It *really* saved my bacon with the macOS
> >>> release,
> >>>  > and it sounds like it would have been helpful with the Windows
> >>>  > release.  What do we think about moving them, along with other
> >>>  > packager-oriented updates and directives, into its own
> >>> documentation
> >>>  > section?  This should help build package unity, and also help
> >>> clean up
> >>>  > the the 5.1 and later announcements.  (They won't need to have
> >>>  > packager-oriented updates, since that's all in a single
> >>> section in the
> >>>  > docs).  If it seems OK but no one else is excited about it, I
> >>>  > volunteer to coordinate this.  It goes along with another
> >>> V6-timeline
> >>>  > KiCad project of mine.
> >>>  >
> >>>  > Adam
> >>>  > On Mon, Jul 23, 2018 at 6:52 AM Wayne Stambaugh
> >>>  mailto:stambau...@gmail.com>> wrote:
> >>>  >>
> >>>  >> I would prefer that we create release builds
> >>>  (CMAKE_BUILD_TYPE=Release)
> >>>  >> for the stable releases.  Debug builds are fine for nightly
> >>> builds.
> >>>  >>
> >>>  >> On 7/23/2018 12:07 AM, Mark Roszko wrote:
> >>>  >>> Done.
> >>>  >>>
> >>>  >>> Wouldn't be bad if the wxAsserts were squashed :X
> >>>  >>> But then again some of them come from wx internally in annoying
> >>>  ways.
> >>>  >>> On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
> >>>  >>>  >>>  > wrote:
> >>>  
> >>>   Ok, this sounds bad.
> >>>  
> >>>   Can someone (Marek?) pull the macOS build and revert the macOS
> >>>  download page, please?  I'm running extremely low on sleep from the
> >>>  last two nights of KiCad hacking and I am literally in bed already.
> >>>  
> >>>   I will regenerate the macOS build with Release instead in
> >>>  approximately 8 hours.
> >>>  
> >>>   Adam
> >>>  
> >>>   On Sun, Jul 22, 2018, 10:48 PM Mark Roszko
> >>>  mailto:mark.ros...@gmail.com>> wrote:
> >>>  >
> >>>  > Welp, I poked Nick. It looks like the stable-debug build got
> >>>  packaged
> >>>  > instead of the stable build config (I can reproduce the
> >>> asserts).
> >>>  > Though the executables are suspiciously not huge like they
> >>>  should be.
> >>>  > On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand
> >>>  mailto:s...@hillbrand.org>> wrote:
> >>>  >>
> >>>  >> No, It's because asserts are being triggered.  These are
> >>>  disabled (normally) in Release builds.
> >>>  >>
> >>>  >> -S
> >>>  >>
> >>>  >> Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko
> >>>  mailto:mark.ros...@gmail.com>>:
> >>>  >>>
> >>>  >>> Is it because the installer exe is huge?
> >>>  >>>
> >>>  >>> That's because the footprint libraries are now part of the
> >>>  installers
> >>>  >>> and they are absolutely massive. (4GB uncompressed)
> >>>  >>>
> >>>  >>> the installed files look fine to me though? The kiface
> >>> files
> >>>  would be
> >>>  >>> hundreds of megs themselves if they had debug symbols but
> >>>  they are at
> >>>  >>> "normal" levels.
> >>>  >>> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand
> >>>  mailto:s...@hillbrand.org>> wrote:
> 

Re: [Kicad-developers] The version string in the master branch

[Wayne Stambaugh]

Dates do not convey useful branch information which is important from a
developer point of view.

It seems to me that 5.1.0-dev would sort before 5.1.0-rc1 or am I
missing something?  Would one of our package devs care to comment.  If
this sorts properly, I will change the kicad version and repo tag to
reflect this.  If not, we need to come up with a version tag that will
not break packages install order and still inform developers from which
branch the package was built.

On 7/25/2018 2:23 AM, Rene Pöschl wrote:
> Why not just use the date at which the nightly was compiled?
> 
> So something like dev-snapshot--mm-dd_g23849572
> This is sortable and it should confuse nobody.
> 
> On 24/07/18 23:58, Eeli Kaikkonen wrote:
>>
>>
>> ti 24. heinäk. 2018 klo 22.59 Wayne Stambaugh (stambau...@gmail.com
>> ) kirjoitti:
>>
>>      5.1-dev will confuse the package version
>>     sorting when 5.1.0 is released.
>>
>>
>> Why do development packages (nightly builds or self-compiled) need to
>> be sorted with release builds?
>>
>> The most misleading strings are in the window bar and in the About
>> KiCad dialog, and those texts aren't sorted anyways. Can't they be
>> different than package file names? Windows nightly build package names
>> don't have the version, nor do the ubuntu nightly packages.
>>
>>     I'm fine with Simon's proposal but
>>     users will be no less confused by 5.0.0-452-g23849572 than by
>>     6.0.0-rc1-xxx-commithash.
>>
>>
>> Based on my experience with linux distros and applications for about
>> 20 years and as a former open source developer I would like to
>> disagree. But I know it doesn't count... I just want this sorted out
>> because people will be confused for the next couple of years, and we
>> who answer questions in the user forum have to clarify the situation
>> every time.
>>
>> Eeli Kaikkonen
>>
>>
>> ___
>> 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] Windows Builds

[Wayne Stambaugh]

We should have created a release build of the stable version.  I'm fine
with nightly builds having debugging information.  Stable releases
should not have debug info.

On 7/25/2018 8:10 AM, Jakub Kozdon wrote:
> There are probably in http://downloads.kicad-pcb.org/windows/testing/
> instead of stable.
> 
> Dne 25.7.2018 v 13:51 Wayne Stambaugh napsal(a):
>> I thought we created a new windows release build to prevent the
>> assertions.  Did that not happen?
>>
>> On 7/25/2018 7:01 AM, Andrew Lutsenko wrote:
>>> Were the windows builds ever fixed?
>>> I downloaded 5.0 today and get a wxWidgets assert simply from clicking
>>> on tools menu in Pcbnew.
>>> kicadassert.png
>>> ​
>>>
>>> On Mon, Jul 23, 2018 at 6:34 AM Wayne Stambaugh >> > wrote:
>>>
>>>  I'm fine with creating a packaging document.  We could add it to
>>> the
>>>  developers documentation or it could also be an external
>>> document with a
>>>  link in the compiling doc.
>>>
>>>  Wayne
>>>
>>>  On 7/23/2018 8:40 AM, Adam Wolf wrote:
>>>  > Agreed, Wayne. The macOS 5.0.0-1 build is uploading right now.
>>> It is a
>>>  > Release build.
>>>  >
>>>  > I have a small set of packaging tests I perform on releases
>>> before
>>>  > uploading them.  It *really* saved my bacon with the macOS
>>> release,
>>>  > and it sounds like it would have been helpful with the Windows
>>>  > release.  What do we think about moving them, along with other
>>>  > packager-oriented updates and directives, into its own
>>> documentation
>>>  > section?  This should help build package unity, and also help
>>> clean up
>>>  > the the 5.1 and later announcements.  (They won't need to have
>>>  > packager-oriented updates, since that's all in a single
>>> section in the
>>>  > docs).  If it seems OK but no one else is excited about it, I
>>>  > volunteer to coordinate this.  It goes along with another
>>> V6-timeline
>>>  > KiCad project of mine.
>>>  >
>>>  > Adam
>>>  > On Mon, Jul 23, 2018 at 6:52 AM Wayne Stambaugh
>>>  mailto:stambau...@gmail.com>> wrote:
>>>  >>
>>>  >> I would prefer that we create release builds
>>>  (CMAKE_BUILD_TYPE=Release)
>>>  >> for the stable releases.  Debug builds are fine for nightly
>>> builds.
>>>  >>
>>>  >> On 7/23/2018 12:07 AM, Mark Roszko wrote:
>>>  >>> Done.
>>>  >>>
>>>  >>> Wouldn't be bad if the wxAsserts were squashed :X
>>>  >>> But then again some of them come from wx internally in annoying
>>>  ways.
>>>  >>> On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
>>>  >>> >>  > wrote:
>>>  
>>>   Ok, this sounds bad.
>>>  
>>>   Can someone (Marek?) pull the macOS build and revert the macOS
>>>  download page, please?  I'm running extremely low on sleep from the
>>>  last two nights of KiCad hacking and I am literally in bed already.
>>>  
>>>   I will regenerate the macOS build with Release instead in
>>>  approximately 8 hours.
>>>  
>>>   Adam
>>>  
>>>   On Sun, Jul 22, 2018, 10:48 PM Mark Roszko
>>>  mailto:mark.ros...@gmail.com>> wrote:
>>>  >
>>>  > Welp, I poked Nick. It looks like the stable-debug build got
>>>  packaged
>>>  > instead of the stable build config (I can reproduce the
>>> asserts).
>>>  > Though the executables are suspiciously not huge like they
>>>  should be.
>>>  > On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand
>>>  mailto:s...@hillbrand.org>> wrote:
>>>  >>
>>>  >> No, It's because asserts are being triggered.  These are
>>>  disabled (normally) in Release builds.
>>>  >>
>>>  >> -S
>>>  >>
>>>  >> Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko
>>>  mailto:mark.ros...@gmail.com>>:
>>>  >>>
>>>  >>> Is it because the installer exe is huge?
>>>  >>>
>>>  >>> That's because the footprint libraries are now part of the
>>>  installers
>>>  >>> and they are absolutely massive. (4GB uncompressed)
>>>  >>>
>>>  >>> the installed files look fine to me though? The kiface
>>> files
>>>  would be
>>>  >>> hundreds of megs themselves if they had debug symbols but
>>>  they are at
>>>  >>> "normal" levels.
>>>  >>> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand
>>>  mailto:s...@hillbrand.org>> wrote:
>>>  
>>>   Hi Devs-
>>>  
>>>   I'm seeing some reports (lp:1783037) that indicate the
>>>  Windows build may be compiled CMAKE_BUILD_TYPE=RelWithDebInfo
>>>  instead of Release.
>>>  
>>>   Can anyone confirm this?  Is there a reason to do this for
>>>  Windows?
>>>  
>>>   -Seth
>>>  
>>>  

Re: [Kicad-developers] Windows Builds

[Jakub Kozdon]

There are probably in http://downloads.kicad-pcb.org/windows/testing/ 
instead of stable.


Dne 25.7.2018 v 13:51 Wayne Stambaugh napsal(a):

I thought we created a new windows release build to prevent the
assertions.  Did that not happen?

On 7/25/2018 7:01 AM, Andrew Lutsenko wrote:

Were the windows builds ever fixed?
I downloaded 5.0 today and get a wxWidgets assert simply from clicking
on tools menu in Pcbnew.
kicadassert.png
​

On Mon, Jul 23, 2018 at 6:34 AM Wayne Stambaugh mailto:stambau...@gmail.com>> wrote:

 I'm fine with creating a packaging document.  We could add it to the
 developers documentation or it could also be an external document with a
 link in the compiling doc.

 Wayne

 On 7/23/2018 8:40 AM, Adam Wolf wrote:
 > Agreed, Wayne. The macOS 5.0.0-1 build is uploading right now. It is a
 > Release build.
 >
 > I have a small set of packaging tests I perform on releases before
 > uploading them.  It *really* saved my bacon with the macOS release,
 > and it sounds like it would have been helpful with the Windows
 > release.  What do we think about moving them, along with other
 > packager-oriented updates and directives, into its own documentation
 > section?  This should help build package unity, and also help clean up
 > the the 5.1 and later announcements.  (They won't need to have
 > packager-oriented updates, since that's all in a single section in the
 > docs).  If it seems OK but no one else is excited about it, I
 > volunteer to coordinate this.  It goes along with another V6-timeline
 > KiCad project of mine.
 >
 > Adam
 > On Mon, Jul 23, 2018 at 6:52 AM Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:
 >>
 >> I would prefer that we create release builds
 (CMAKE_BUILD_TYPE=Release)
 >> for the stable releases.  Debug builds are fine for nightly builds.
 >>
 >> On 7/23/2018 12:07 AM, Mark Roszko wrote:
 >>> Done.
 >>>
 >>> Wouldn't be bad if the wxAsserts were squashed :X
 >>> But then again some of them come from wx internally in annoying
 ways.
 >>> On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
 >>> mailto:adamw...@feelslikeburning.com>> wrote:
 
  Ok, this sounds bad.
 
  Can someone (Marek?) pull the macOS build and revert the macOS
 download page, please?  I'm running extremely low on sleep from the
 last two nights of KiCad hacking and I am literally in bed already.
 
  I will regenerate the macOS build with Release instead in
 approximately 8 hours.
 
  Adam
 
  On Sun, Jul 22, 2018, 10:48 PM Mark Roszko
 mailto:mark.ros...@gmail.com>> wrote:
 >
 > Welp, I poked Nick. It looks like the stable-debug build got
 packaged
 > instead of the stable build config (I can reproduce the asserts).
 > Though the executables are suspiciously not huge like they
 should be.
 > On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand
 mailto:s...@hillbrand.org>> wrote:
 >>
 >> No, It's because asserts are being triggered.  These are
 disabled (normally) in Release builds.
 >>
 >> -S
 >>
 >> Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko
 mailto:mark.ros...@gmail.com>>:
 >>>
 >>> Is it because the installer exe is huge?
 >>>
 >>> That's because the footprint libraries are now part of the
 installers
 >>> and they are absolutely massive. (4GB uncompressed)
 >>>
 >>> the installed files look fine to me though? The kiface files
 would be
 >>> hundreds of megs themselves if they had debug symbols but
 they are at
 >>> "normal" levels.
 >>> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand
 mailto:s...@hillbrand.org>> wrote:
 
  Hi Devs-
 
  I'm seeing some reports (lp:1783037) that indicate the
 Windows build may be compiled CMAKE_BUILD_TYPE=RelWithDebInfo
 instead of Release.
 
  Can anyone confirm this?  Is there a reason to do this for
 Windows?
 
  -Seth
 
  ___
  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
 >>>
 >>>
 >>>
 >>> --
 >>> Mark
 >
 >
 >
 > --
 > Mark
 >
 > ___
 > 

Re: [Kicad-developers] Branches

[Carsten Schoenert]

Am 25.07.18 um 17:40 schrieb Maciej Sumiński:
> Nobody forbids working on new features in separate branches that we will
> start merging once 5.1 is released and 6.0 development cycle starts. I
> have already started a few branches for v6 features, but they need to
> wait now.

That's what I mean, why I need to wait? In recent days this is for me a
mismanagement and such things are mostly not needed. Those are feature
branches made for so people can continue on their work continuously. You
will need to merge the related changes into the other branches.

Remember the link to the website I made, it show this nicely.

https://nvie.com/posts/a-successful-git-branching-model/

> I simply rebase them from time to time, but it is not a big deal so
> far.
This will get annoying and frustrating the more often you need to do
this. It may be not a big deal for you as a core developer because you
know mostly every detail in the source, but for people from outside it's
unneeded load to do such rebasing again and again. I've done this for
thunderbird for about a half year before I was going further. This was
really frustrating.

> I anticipate GTK3 fixes to be ready in 1-2 months from now,
> I am not sure if the delay is significant enough to keep this discussion
> going on.

This is a decision you have to make. For me GTK fixes are a thing you of
course will need to have also in later version so the typical solution
is to merge theses things into the current master branch. No need for
cherry-picking.

> We have already experienced a significant overhead in late v5 cycle due
> to porting certain v4 fixes to v5 branch or vice versa. Imagine that we
> keep working on 5.1 and 6.0 at the same time.

I know such things from other projects, this is real life. Other
projects have people which are responsible for release management.

> I am sure we could right now dump enough code onto the 6.0 branch to
> diverge it from 5.1 so much that porting fixes between them becomes
> non trivial. Keep in mind that there is 5.0 branch that may need to
> share some patches with the remaining branches too. Please notice
> that *every* patch that we applied to 5.1 had to be applied to the
> master branch as well via cherry-picking.
You really wont do cherry-picking! Merging is the right thing here.
KiCad is not the Linux kernel or Gnome, but look how these projects are
working. Both need to take care about older releases too. And many other
projects also.
If you keep up the branches in the core in sync it isn't that difficult
to backport changes.

> What are the benefits of maintaining 3 branches?

Simply that every one can make progress without being slowed down due
some technical reasons? It's all about organization.

In the long run you will need at least two branches like before, so
currently you will need also 5.0 to provide urgent fixes before any
5.1.x release is made. It's not that much more I guess.

But again, it's up to you guys how you will organize your work, all from
me are just suggestions based on experiences I made in the last decade
while contributing to various projects. Let's stop here.

-- 
Regards
Carsten Schoenert

___
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] Windows Builds

[Wayne Stambaugh]

I thought we created a new windows release build to prevent the
assertions.  Did that not happen?

On 7/25/2018 7:01 AM, Andrew Lutsenko wrote:
> Were the windows builds ever fixed? 
> I downloaded 5.0 today and get a wxWidgets assert simply from clicking
> on tools menu in Pcbnew.
> kicadassert.png
> ​
> 
> On Mon, Jul 23, 2018 at 6:34 AM Wayne Stambaugh  > wrote:
> 
> I'm fine with creating a packaging document.  We could add it to the
> developers documentation or it could also be an external document with a
> link in the compiling doc.
> 
> Wayne
> 
> On 7/23/2018 8:40 AM, Adam Wolf wrote:
> > Agreed, Wayne. The macOS 5.0.0-1 build is uploading right now. It is a
> > Release build.
> >
> > I have a small set of packaging tests I perform on releases before
> > uploading them.  It *really* saved my bacon with the macOS release,
> > and it sounds like it would have been helpful with the Windows
> > release.  What do we think about moving them, along with other
> > packager-oriented updates and directives, into its own documentation
> > section?  This should help build package unity, and also help clean up
> > the the 5.1 and later announcements.  (They won't need to have
> > packager-oriented updates, since that's all in a single section in the
> > docs).  If it seems OK but no one else is excited about it, I
> > volunteer to coordinate this.  It goes along with another V6-timeline
> > KiCad project of mine.
> >
> > Adam
> > On Mon, Jul 23, 2018 at 6:52 AM Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> >>
> >> I would prefer that we create release builds
> (CMAKE_BUILD_TYPE=Release)
> >> for the stable releases.  Debug builds are fine for nightly builds.
> >>
> >> On 7/23/2018 12:07 AM, Mark Roszko wrote:
> >>> Done.
> >>>
> >>> Wouldn't be bad if the wxAsserts were squashed :X
> >>> But then again some of them come from wx internally in annoying
> ways.
> >>> On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
> >>>  > wrote:
> 
>  Ok, this sounds bad.
> 
>  Can someone (Marek?) pull the macOS build and revert the macOS
> download page, please?  I'm running extremely low on sleep from the
> last two nights of KiCad hacking and I am literally in bed already.
> 
>  I will regenerate the macOS build with Release instead in
> approximately 8 hours.
> 
>  Adam
> 
>  On Sun, Jul 22, 2018, 10:48 PM Mark Roszko
> mailto:mark.ros...@gmail.com>> wrote:
> >
> > Welp, I poked Nick. It looks like the stable-debug build got
> packaged
> > instead of the stable build config (I can reproduce the asserts).
> > Though the executables are suspiciously not huge like they
> should be.
> > On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand
> mailto:s...@hillbrand.org>> wrote:
> >>
> >> No, It's because asserts are being triggered.  These are
> disabled (normally) in Release builds.
> >>
> >> -S
> >>
> >> Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko
> mailto:mark.ros...@gmail.com>>:
> >>>
> >>> Is it because the installer exe is huge?
> >>>
> >>> That's because the footprint libraries are now part of the
> installers
> >>> and they are absolutely massive. (4GB uncompressed)
> >>>
> >>> the installed files look fine to me though? The kiface files
> would be
> >>> hundreds of megs themselves if they had debug symbols but
> they are at
> >>> "normal" levels.
> >>> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand
> mailto:s...@hillbrand.org>> wrote:
> 
>  Hi Devs-
> 
>  I'm seeing some reports (lp:1783037) that indicate the
> Windows build may be compiled CMAKE_BUILD_TYPE=RelWithDebInfo
> instead of Release.
> 
>  Can anyone confirm this?  Is there a reason to do this for
> Windows?
> 
>  -Seth
> 
>  ___
>  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
> >>>
> >>>
> >>>
> >>> --
> >>> Mark
> >
> >
> >
> > --
> > Mark
> >
> > ___
> > 

Re: [Kicad-developers] Windows Builds

[Andrew Lutsenko]

Were the windows builds ever fixed?
I downloaded 5.0 today and get a wxWidgets assert simply from clicking on
tools menu in Pcbnew.
[image: kicadassert.png]
​

On Mon, Jul 23, 2018 at 6:34 AM Wayne Stambaugh 
wrote:

> I'm fine with creating a packaging document.  We could add it to the
> developers documentation or it could also be an external document with a
> link in the compiling doc.
>
> Wayne
>
> On 7/23/2018 8:40 AM, Adam Wolf wrote:
> > Agreed, Wayne. The macOS 5.0.0-1 build is uploading right now. It is a
> > Release build.
> >
> > I have a small set of packaging tests I perform on releases before
> > uploading them.  It *really* saved my bacon with the macOS release,
> > and it sounds like it would have been helpful with the Windows
> > release.  What do we think about moving them, along with other
> > packager-oriented updates and directives, into its own documentation
> > section?  This should help build package unity, and also help clean up
> > the the 5.1 and later announcements.  (They won't need to have
> > packager-oriented updates, since that's all in a single section in the
> > docs).  If it seems OK but no one else is excited about it, I
> > volunteer to coordinate this.  It goes along with another V6-timeline
> > KiCad project of mine.
> >
> > Adam
> > On Mon, Jul 23, 2018 at 6:52 AM Wayne Stambaugh 
> wrote:
> >>
> >> I would prefer that we create release builds (CMAKE_BUILD_TYPE=Release)
> >> for the stable releases.  Debug builds are fine for nightly builds.
> >>
> >> On 7/23/2018 12:07 AM, Mark Roszko wrote:
> >>> Done.
> >>>
> >>> Wouldn't be bad if the wxAsserts were squashed :X
> >>> But then again some of them come from wx internally in annoying ways.
> >>> On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
> >>>  wrote:
> 
>  Ok, this sounds bad.
> 
>  Can someone (Marek?) pull the macOS build and revert the macOS
> download page, please?  I'm running extremely low on sleep from the last
> two nights of KiCad hacking and I am literally in bed already.
> 
>  I will regenerate the macOS build with Release instead in
> approximately 8 hours.
> 
>  Adam
> 
>  On Sun, Jul 22, 2018, 10:48 PM Mark Roszko 
> wrote:
> >
> > Welp, I poked Nick. It looks like the stable-debug build got packaged
> > instead of the stable build config (I can reproduce the asserts).
> > Though the executables are suspiciously not huge like they should be.
> > On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand 
> wrote:
> >>
> >> No, It's because asserts are being triggered.  These are disabled
> (normally) in Release builds.
> >>
> >> -S
> >>
> >> Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko <
> mark.ros...@gmail.com>:
> >>>
> >>> Is it because the installer exe is huge?
> >>>
> >>> That's because the footprint libraries are now part of the
> installers
> >>> and they are absolutely massive. (4GB uncompressed)
> >>>
> >>> the installed files look fine to me though? The kiface files would
> be
> >>> hundreds of megs themselves if they had debug symbols but they are
> at
> >>> "normal" levels.
> >>> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand <
> s...@hillbrand.org> wrote:
> 
>  Hi Devs-
> 
>  I'm seeing some reports (lp:1783037) that indicate the Windows
> build may be compiled CMAKE_BUILD_TYPE=RelWithDebInfo instead of Release.
> 
>  Can anyone confirm this?  Is there a reason to do this for
> Windows?
> 
>  -Seth
> 
>  ___
>  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
> >>>
> >>>
> >>>
> >>> --
> >>> Mark
> >
> >
> >
> > --
> > Mark
> >
> > ___
> > 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 : 

Re: [Kicad-developers] Board setup icon

[John Beard]

Hi Jeff,

Sure thing! Here they are.

I have modified part_properties (patch 1) and create field_properties
and used in the menu and toolbar (patch 2).

Attached are the PNGs for reference.

Cheers,

John

On Tue, Jul 24, 2018 at 8:35 PM, Jeff Young  wrote:
> Hi John,
>
> When you get a chance could you also edit the part_properties_xpm icon to be 
> the op-amp with a gear over it?
>
> Oh, and a new icon with the op-amp with a little ’T’ in the bottom right 
> corner would be great.
>
> (Both are for the symbol editor.  They’re currently just a generic gear and a 
> generic ’T’.)
>
> Thanks,
> Jeff.
>
>
>> On 24 Jul 2018, at 16:56, Jeff Young  wrote:
>>
>> I’ve merged your icon, John.  Thanks for your contribution!
>>
>>> On 24 Jul 2018, at 12:35, John Beard  wrote:
>>>
>>> Hi,
>>>
>>> Here is a new icon for the board setup toolbar and menu item. The
>>> generic gear icon is no clear, as it looks like "Preferences" rather
>>> than board setup.
>>>
>>> PNG included for reference only.
>>>
>>> Cheers,
>>>
>>> John
>>> <0001-Pcbnew-add-new-icon-for-board-setup.patch>___
>>> 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
>
From ea68d50ce9aa3305d0ae180e3a47c3837ef3504d Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Wed, 25 Jul 2018 11:29:04 +0100
Subject: [PATCH 1/2] New part properties icon: opamp + gear

This was just the gear, which is conflated with general preferences.
Adding the opamp makes the connection to "symbol/part" clearer.
---
 bitmaps_png/cpp_26/part_properties.cpp  | 103 
 bitmaps_png/sources/part_properties.svg | 121 ++--
 2 files changed, 153 insertions(+), 71 deletions(-)

diff --git a/bitmaps_png/cpp_26/part_properties.cpp b/bitmaps_png/cpp_26/part_properties.cpp
index 689490ffd..54a97d4f3 100644
--- a/bitmaps_png/cpp_26/part_properties.cpp
+++ b/bitmaps_png/cpp_26/part_properties.cpp
@@ -8,46 +8,69 @@
 static const unsigned char png[] = {
  0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d, 0x49, 0x48, 0x44, 0x52,
  0x00, 0x00, 0x00, 0x1a, 0x00, 0x00, 0x00, 0x1a, 0x08, 0x06, 0x00, 0x00, 0x00, 0xa9, 0x4a, 0x4c,
- 0xce, 0x00, 0x00, 0x02, 0x60, 0x49, 0x44, 0x41, 0x54, 0x48, 0xc7, 0xbd, 0x96, 0x3b, 0x6e, 0x22,
- 0x41, 0x10, 0x86, 0x49, 0x58, 0x12, 0x02, 0x03, 0x02, 0x0e, 0x00, 0x27, 0x41, 0xe2, 0x19, 0x92,
- 0x71, 0x01, 0x62, 0x96, 0x80, 0x1c, 0x24, 0x5e, 0x47, 0x20, 0x43, 0xa4, 0x48, 0x48, 0x10, 0x92,
- 0x8d, 0x78, 0x07, 0x04, 0x0e, 0x91, 0x10, 0x43, 0x00, 0x04, 0xbe, 0x01, 0x09, 0xe5, 0xf9, 0x5a,
- 0xd3, 0xa3, 0x91, 0x3d, 0x6b, 0x63, 0xaf, 0x4d, 0x4b, 0x65, 0xda, 0xdd, 0xf5, 0xff, 0xd5, 0xf5,
- 0xea, 0x1e, 0x9f, 0xef, 0xce, 0x21, 0x22, 0xcf, 0xf2, 0x7e, 0x3c, 0xfb, 0x7e, 0x72, 0x58, 0x84,
- 0x7f, 0x2c, 0xb9, 0xf5, 0xfb, 0x7d, 0x09, 0x04, 0x02, 0x4a, 0x98, 0xb3, 0xc6, 0xde, 0x77, 0x49,
- 0x07, 0x96, 0xbc, 0x58, 0x32, 0xb5, 0xe4, 0xc9, 0x5e, 0x2b, 0xc2, 0x5a, 0x2a, 0x95, 0xa4, 0xd1,
- 0x68, 0x28, 0x61, 0x6e, 0x8f, 0xa2, 0xad, 0xf3, 0x64, 0x63, 0xc0, 0x0e, 0x3e, 0x33, 0x62, 0x80,
- 0xdc, 0xef, 0xf7, 0x72, 0xbb, 0x71, 0x58, 0xb9, 0x5a, 0xf2, 0xd7, 0x92, 0x15, 0xff, 0x24, 0x12,
- 0x09, 0x19, 0x0e, 0x87, 0x4a, 0x92, 0xc9, 0xa4, 0x36, 0xc4, 0x5e, 0x05, 0x5d, 0x30, 0x60, 0xed,
- 0x61, 0x7c, 0xe4, 0x89, 0xf4, 0x7a, 0x3d, 0xf1, 0xfb, 0xfd, 0x92, 0x4a, 0xa5, 0xe4, 0x70, 0x38,
- 0x38, 0xc9, 0x80, 0x20, 0x18, 0x0c, 0xca, 0x66, 0xb3, 0x51, 0xc2, 0xdc, 0x45, 0xaa, 0x74, 0xc1,
- 0x80, 0x85, 0xc3, 0x1e, 0x03, 0x2f, 0x43, 0x2f, 0xbb, 0xdd, 0x4e, 0x29, 0x8e, 0xc7, 0x63, 0xa9,
- 0x56, 0xab, 0x12, 0x0e, 0x87, 0x55, 0x98, 0xd2, 0xe9, 0xb4, 0x84, 0x42, 0x21, 0x29, 0x97, 0xcb,
- 0xb2, 0x5a, 0xad, 0x94, 0x30, 0x67, 0x8d, 0x3d, 0x74, 0xd0, 0x05, 0x03, 0x16, 0x0e, 0xb8, 0xe0,
- 0xf4, 0x32, 0x34, 0xc5, 0x75, 0x4e, 0x05, 0x60, 0xbb, 0xdd, 0xca, 0x68, 0x34, 0x92, 0x6c, 0x36,
- 0x2b, 0xb5, 0x5a, 0x4d, 0x0c, 0xc3, 0x90, 0xf9, 0x7c, 0x2e, 0xb3, 0xd9, 0x4c, 0x09, 0x73, 0xd6,
- 0xd8, 0x43, 0x07, 0x5d, 0x30, 0x60, 0xe1, 0xb0, 0x43, 0x3f, 0xf5, 0x32, 0x44, 0x32, 0xaf, 0xc7,
- 0xe3, 0x51, 0x22, 0x91, 0x88, 0x02, 0xae, 0xd7, 0x6b, 0x59, 0x2c, 0x16, 0x0e, 0x31, 0x73, 0xb7,
- 0x68, 0xc3, 0xcc, 0xd1, 0xc5, 0x1b, 0xb0, 0x76, 0x48, 0xaf, 0xba, 0x98, 0xbc, 0x8c, 0x91, 0x54,
- 0x27, 0x5c, 0xda, 0x08, 0xbf, 0xcb, 0xe5, 0x52, 0x85, 0x0c, 0x42, 0x84, 0x39, 0x6b, 0x6e, 0x1d,
- 0x1d, 0x46, 0x7b, 0x54, 0xfe, 0xd5, 0x27, 0x45, 0x5d, 0x5d, 0x00, 0x08, 0x89, 0x26, 0x80, 0x94,
- 0xd3, 0xe6, 0x72, 0x39, 0x89, 0xc5, 0x62, 0x12, 0x8f, 0xc7, 0x25, 0x9f, 0xcf, 0xab, 0x35, 0xf6,
- 0xb4, 0x31, 0x30, 0x60, 

Re: [Kicad-developers] Branches

[Maciej Sumiński]

On 07/25/2018 11:23 AM, Carsten Schoenert wrote:
> Hello Orson,
> 
> Am 25.07.18 um 15:53 schrieb Maciej Sumiński:
> ...
>> It has been discussed in this thread already, but I will repeat: the
>> main problem now is that we need to apply patches to both master and
>> 5.1.
> 
> thanks for clarifying (probably again).
> The question will come again and again, unless it's written down to a
> road map where it can be referenced to. I haven't found anything related
> to this on the website and I also haven't time to follow any thread in
> deep here on the ml which is more technical, but it's also interesting
> for me as the person who is doing the Debian packaging where the
> developing will move to and what are the plans for which release.
> 
> Why not discuss the goals which are targeted for 5.1.x (now mostly
> already happen) and make this public (as a blog post on the website
> e.g.)? This can be used later while developing to see how far the next
> release is. I think the current development isn't that transparent
> that's for sure not intended.

A blog post sounds like a good idea, I have noticed the current plan is
not very clear for everyone.

>> This is fairly easy now, as there are no new features in the master
>> branch yet, but if we merged all the feature branches then I think we
>> would spend too much time resolving conflicts. There is no point nor
>> manpower to develop two branches in parallel.
> 
> Sorry, I don't get this or I don't understand this really. If you say
> this you will also constrain the development to only work in serial mode
> like happen a decade ago while Subversion was a modern VCS and all needs
> mostly done in just one branch. I don't think this is wanted as this
> would mean you bothersome people who want to work on features for 6.x to
> delay their work. And this is normally the last thing you wanna do.
> That's part of the development projects needs to handle and deal with.
> Git gives the possibility to get this managed, the only thing you need
> to be clear is to know which branch needs to be merged into another.
> And, yes this needs manpower to handle releases, but this needs to be
> done anyway. To say there is no manpower would be a wrong thing to me,
> as this has will have a huge impact just later. As I tried to express in
> one of my previous emails I think it's important KiCad will get a better
> policy for development and also for release planning.
> 
> All above is just my personal view and I don't want to enforce the
> "real" developers to do something exactly in this way. The developers
> are deciding what to do and how, so I don't want to bother any of you.

Nobody forbids working on new features in separate branches that we will
start merging once 5.1 is released and 6.0 development cycle starts. I
have already started a few branches for v6 features, but they need to
wait now. I simply rebase them from time to time, but it is not a big
deal so far. I anticipate GTK3 fixes to be ready in 1-2 months from now,
I am not sure if the delay is significant enough to keep this discussion
going on.

We have already experienced a significant overhead in late v5 cycle due
to porting certain v4 fixes to v5 branch or vice versa. Imagine that we
keep working on 5.1 and 6.0 at the same time. I am sure we could right
now dump enough code onto the 6.0 branch to diverge it from 5.1 so much
that porting fixes between them becomes non trivial. Keep in mind that
there is 5.0 branch that may need to share some patches with the
remaining branches too. Please notice that *every* patch that we applied
to 5.1 had to be applied to the master branch as well via
cherry-picking. What are the benefits of maintaining 3 branches?

Cheers,
Orson



signature.asc
Description: OpenPGP digital signature
___
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] Branches

[Carsten Schoenert]

Hello Orson,

Am 25.07.18 um 15:53 schrieb Maciej Sumiński:
...
> It has been discussed in this thread already, but I will repeat: the
> main problem now is that we need to apply patches to both master and
> 5.1.

thanks for clarifying (probably again).
The question will come again and again, unless it's written down to a
road map where it can be referenced to. I haven't found anything related
to this on the website and I also haven't time to follow any thread in
deep here on the ml which is more technical, but it's also interesting
for me as the person who is doing the Debian packaging where the
developing will move to and what are the plans for which release.

Why not discuss the goals which are targeted for 5.1.x (now mostly
already happen) and make this public (as a blog post on the website
e.g.)? This can be used later while developing to see how far the next
release is. I think the current development isn't that transparent
that's for sure not intended.

> This is fairly easy now, as there are no new features in the master
> branch yet, but if we merged all the feature branches then I think we
> would spend too much time resolving conflicts. There is no point nor
> manpower to develop two branches in parallel.

Sorry, I don't get this or I don't understand this really. If you say
this you will also constrain the development to only work in serial mode
like happen a decade ago while Subversion was a modern VCS and all needs
mostly done in just one branch. I don't think this is wanted as this
would mean you bothersome people who want to work on features for 6.x to
delay their work. And this is normally the last thing you wanna do.
That's part of the development projects needs to handle and deal with.
Git gives the possibility to get this managed, the only thing you need
to be clear is to know which branch needs to be merged into another.
And, yes this needs manpower to handle releases, but this needs to be
done anyway. To say there is no manpower would be a wrong thing to me,
as this has will have a huge impact just later. As I tried to express in
one of my previous emails I think it's important KiCad will get a better
policy for development and also for release planning.

All above is just my personal view and I don't want to enforce the
"real" developers to do something exactly in this way. The developers
are deciding what to do and how, so I don't want to bother any of you.

-- 
Regards
Carsten Schoenert

___
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] Branches

[Maciej Sumiński]

On 07/25/2018 04:28 AM, Carsten Schoenert wrote:
> Am 24.07.18 um 15:01 schrieb Maciej Sumiński:
>> At the moment the master branch contains all commits from 5.1 and a few
>> more. It might be the right moment to drop 5.1 branch.
> 
> This depends on the achievements which are desired or wanted in my eyes.
> 
> The branch 5.1 was created to work on the planned releases 5.1.x, right?
> Dropping this branch would mean all further work would done only in the
> master branch. I'm not sure this is really wanted as it's need to be
> ensured that all releases are backwards compatible to the current 5.0.0
> release without breaking potential work done from people targeted post
> 5.x. KiCad will need some kine of release managing in the near future I
> guess.
> 
> It seem to me that there are at least some potential confusion exists
> about the intention of feature branches, nothing more are the existing
> branches 5.1 and master.
> 
> But as long there is no agreement what should happen to which release it
> will be messy all the time. Is this somewhere documented what will
> happen to 5.1 especially?

There is no document regarding 5.1 goals, as I think it is too brief to
make it formal: wxGTK3 fix is the main goal, minor UI improvements and
bugfixes are acceptable, no new features in 5.1. We want to push it out
as soon as possible so we can move on with 6.x.

It has been discussed in this thread already, but I will repeat: the
main problem now is that we need to apply patches to both master and
5.1. This is fairly easy now, as there are no new features in the master
branch yet, but if we merged all the feature branches then I think we
would spend too much time resolving conflicts. There is no point nor
manpower to develop two branches in parallel.

Cheers,
Orson



signature.asc
Description: OpenPGP digital signature
___
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] Hotkeys in GAL

[Maciej Sumiński]

Hi John,

On 07/24/2018 07:21 PM, John Beard wrote:
> Hi,
> 
> I have a few questions about hotkeys in GAL tools:
> 
> 1) Is there are reason so many GAL tools don't get hotkeys?
> 
> Very many TOOL_ACTIONS have a hotkey set to '0'. Most others that do
> have a hotkey have a LegacyHotkey definition. Only a very few have the
> GAL-style keys (e.g. rotate CW).
> 
> I think nearly all GAL tools should have a hotkey assignable, even if
> they default to unassigned. It's quite limiting to not be able to
> access some tools except by the menu. (This may mean some tools need
> defences against being called even when the menu item is disabled.)

I would not mind adding more hotkeys, I think the primary reason is that
not every action is executed often enough to justify a hotkey. Even with
the current configuration it might be challenging to find a free hotkey
for an action.

The initial idea was to list all TOOL_ACTIONs in the hotkey editor, so
the user may decide for himself which actions should have a hotkey
assigned. It might be somewhat tricky to implement with legacy canvas
still in place, so perhaps the right moment will come when legacy canvas
is out.

> 2) Is it/will it be supported to have the same hotkey for multiple
> contexts? For example, say there's an AS_GLOBAL action using "G".
> However, when you're in a tool mode, that could be overridden by a
> AS_CONTEXT action that only makes sense in that tool.
> 
> This already sort of works, *but* the hotkey dialog does not like
> duplicate keys, even when one is global and one is contextual. Can
> this be changed, or is it pending removal of the legacy canvas and
> hotkey system first?

As I said, it might be difficult to make the hotkey editor handle two
sets of hotkey configurations. I imagine we could have subsections in
the editor that are specific to tools and these would be acceptable
duplicates with global and other contexts hotkeys. I am open to other
ideas too.

Cheers,
Orson

> Cheers,
> 
> John
> 
> ___
> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] The version string in the master branch

[Rene Pöschl]

Why not just use the date at which the nightly was compiled?

So something like dev-snapshot--mm-dd_g23849572
This is sortable and it should confuse nobody.

On 24/07/18 23:58, Eeli Kaikkonen wrote:



ti 24. heinäk. 2018 klo 22.59 Wayne Stambaugh (stambau...@gmail.com 
) kirjoitti:


 5.1-dev will confuse the package version
sorting when 5.1.0 is released.


Why do development packages (nightly builds or self-compiled) need to 
be sorted with release builds?


The most misleading strings are in the window bar and in the About 
KiCad dialog, and those texts aren't sorted anyways. Can't they be 
different than package file names? Windows nightly build package names 
don't have the version, nor do the ubuntu nightly packages.


I'm fine with Simon's proposal but
users will be no less confused by 5.0.0-452-g23849572 than by
6.0.0-rc1-xxx-commithash.


Based on my experience with linux distros and applications for about 
20 years and as a former open source developer I would like to 
disagree. But I know it doesn't count... I just want this sorted out 
because people will be confused for the next couple of years, and we 
who answer questions in the user forum have to clarify the situation 
every time.


Eeli Kaikkonen


___
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