Re: [Kicad-developers] Python shebangs

2018-11-07 Thread Brüns , Stefan 
On Dienstag, 6. November 2018 15:45:29 CET Steven A. Falco wrote:
> I'd like to have a discussion about python shebangs.  I noticed several
> rpmlint errors when building the official Fedora packages.  Specifically,
> rpmlint is complaining about using "env" as a method for locating the
> python interpreter.  Here are the errors:
> 
> kicad-doc.noarch: E: wrong-script-interpreter
> /usr/share/doc/kicad/scripts/ddr3_length_match.py /usr/bin/env python2
> kicad-doc.noarch: E: wrong-script-interpreter
> /usr/share/doc/kicad/scripts/mk_macos_icons.py /usr/bin/env python
> kicad-doc.noarch: E: wrong-script-interpreter
> /usr/share/doc/kicad/scripts/mk_mime_icons.py /usr/bin/env python

I think the last two should just be deleted from the distribution package / 
not be installed, as these are just maintenance scripts.

Kind regards,

Stefan

___
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] Some of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

2018-11-07 Thread Kevin Cozens 

On 2018-11-07 7:55 a.m., Wayne Stambaugh wrote:

Am 2018-11-06 16:41, schrieb Rene Pöschl:

Sadly we did not come around to fix all symbols before the v5 release.

[snip]>> Do we need to do this during 5.1?  Or can it simply be done in the v6

branch of the libraries?

If we need to do this during 5.1, I guess I'd prefer option 2 for right
now as that is minimally disruptive.


I agree.  If we push this off to v6 then options 1 and 3 are in play.  I
would probably lean towards option 1 to avoid having multiple libraries
with essentially the same symbols.  The rescue feature should catch any
pin changes although we may want to test a symbol or two before we make
the changes to the library.


When I first read the options I was thinking that option 3 might be the best 
option long term.


How will not hiding pins affect IC's with multiple parts (e.g. a 7400)? Will 
each part have the power and ground pins?


If hidden power pins was supposed to have helped with auto-connection of 
power rails it seems it only worked with power rails with the same type. I 
have a schematic where I have had to manually tie VDD, VCC, and +5V together 
and also tied VSS and GND together.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   | "Nerds make the shiny things that
https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
| that's why we're powerful"
Owner of Elecraft K2 #2172  |
#include  | --Chris Hardwick

___
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] Some of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

2018-11-07 Thread Rene Pöschl 
On 07/11/18 17:39, Kevin Cozens wrote:ons I was thinking that option 3 
might be the best

How will not hiding pins affect IC's with multiple parts (e.g. a 7400)? Will
each part have the power and ground pins?


Like we did with the 4xxx series parts. There will be a further unit 
added that only holds the power pins. (Meaning the symbol will no longer 
be one where the units are interchangeable.)

Adding the power pins to every unit is confusing and error prone.

___
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] 5.0.2 release

2018-11-07 Thread Seth Hillbrand 

Am 2018-11-07 09:40, schrieb Wayne Stambaugh:

Hi Everyone,

I'm trying to get a feel for what is left before we can release 5.0.2.
I'm hoping we can get this out soon because I would like to announce 
the

string freeze for 5.1 by Thanksgiving.  I noticed there are a few
outstanding critical bugs (although I believe one of them has already
been resolved) that need addressed.  I would like to move forward on
this in the next week or two.  Please let me know if this isn't 
feasible.


Hi Wayne-

I can fix the ratsnest this week.  The eagle import crash is, I think, 
addressed already by the packaging.


The KDE error [1] is a bit less tractable.  It is a bad interaction 
between our data and Klipper (the KDE clipboard manager) and possibly 
the secondary plasma clipboard.  A real fix here may be simple and it is 
eluding me or we may need to selectively disable the clipboard for KDE 
window managers. I should know more this weekend.


-S

[1] https://bugs.launchpad.net/bugs/1800648

___
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] 5.0.2 release

2018-11-07 Thread Wayne Stambaugh 
Hi Everyone,

I'm trying to get a feel for what is left before we can release 5.0.2.
I'm hoping we can get this out soon because I would like to announce the
string freeze for 5.1 by Thanksgiving.  I noticed there are a few
outstanding critical bugs (although I believe one of them has already
been resolved) that need addressed.  I would like to move forward on
this in the next week or two.  Please let me know if this isn't feasible.

Cheers,

Wayne

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Option to not render 3D models for footprints

2018-11-07 Thread Wayne Stambaugh 
I haven't had a chance to review this patch yet.  It's on my to do list.
 Until 5.1 is tagged and branched, no file format changes are allowed.
Once the v6 development window opens, this patch will be up for
consideration.

Cheers,

Wayne

On 11/6/2018 4:46 PM, Mário Luzeiro wrote:
> Hi Oliver,
> I was about to bump your email too :)
> 
>> 2) The m_Preview parameter is saved to file (both .kicad_mod and .kicad_pcb)
> 
> At the time I worked on the 3D Viewer, some ideas arise that involve to add 
> new tags to the .kicad_pcb
> I understood that at that time it was not a good time to introduce changes on 
> the format files, special because as the stable release was approaching..
> 
> So, for this patch, I think the main question is if it is possible to 
> introduce new tags on the file formats.
> 
> Nice to see someone adding new features related to the 3D Viewer!
> 
> Regards,
> Mario Luzeiro
> 
> 
> From: Kicad-developers 
>  on behalf of 
> Oliver Walters 
> Sent: 06 November 2018 21:18:20
> To: KiCad Developers
> Subject: Re: [Kicad-developers] [PATCH] Option to not render 3D models for
>   footprints
> 
> Bump :)
> 
> On Tue, Oct 30, 2018 at 11:27 PM Oliver Walters 
> mailto:oliver.henry.walt...@gmail.com>> wrote:
> The attached patchset expands on the "Preview" checkbox in the 3D model tab 
> in the footprint editor.
> 
> This "Preview" option currently only applies to the preview window. However 
> if the user wishes to disable display of a given 3D model in the PCB renderer 
> they must delete the 3D model from the footprint entirely.
> 
> The new patchset does the following:
> 
> 1) The state of the m_Preview parameter for each 3D model is observed in the 
> various 3D renderers and exporters
> 
> 2) The m_Preview parameter is saved to file (both .kicad_mod and .kicad_pcb)
> 
> With regard to file saving, if the 3D model is "enabled" (default state) then 
> the file is unchanged making this change largely backwards compatible. If the 
> 3D model is disabled, then the keyword "(disabled)" is added to the file.
> 
> You can now quickly toggle 3D models on/off on an individual basis and this 
> is statefully saved between sessions.
> 
> Patch-set is rebased and compiled from 
> b445b0fab28f7dd41273801d06d7705215c57c0f
> 
> Regards,
> 
> 
> ___
> 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] Some of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

2018-11-07 Thread Wayne Stambaugh 
On 11/6/2018 6:14 PM, Seth Hillbrand wrote:
> Hi Rene-
> 
> Am 2018-11-06 16:41, schrieb Rene Pöschl:
>> Sadly we did not come around to fix all symbols before the v5 release.
>> We now seem to have a volunteer who would be prepared to fix these
>> symbols.
>>
>> There is a catch though. Whatever we do to fix this it will break
>> designs that use the old symbols right now.
> 
> Do we need to do this during 5.1?  Or can it simply be done in the v6
> branch of the libraries?
> 
> If we need to do this during 5.1, I guess I'd prefer option 2 for right
> now as that is minimally disruptive.

I agree.  If we push this off to v6 then options 1 and 3 are in play.  I
would probably lean towards option 1 to avoid having multiple libraries
with essentially the same symbols.  The rescue feature should catch any
pin changes although we may want to test a symbol or two before we make
the changes to the library.

> 
> -S
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Add legacy_gal implied include dirs

2018-11-07 Thread John Beard 
Hi,

The legacy_gal target doesn't add include/legacy_gal as a PUBLIC
include dir. This means:

* Targets have to specify it themselves and
* Its own files have to specify it manually too

This is at odds with how legacy_wx does it and adds complexity to
targets using legacy_gal (complexity which will need to be undone when
legacy_wx is removed).

Cheers,

John
From 04b3153d78614eb4617f3cf70b07ea1eae483a61 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Wed, 7 Nov 2018 11:34:12 +
Subject: [PATCH 1/2] Include directories are implied by legacy_gal linkage

This avoids having to manually specify include/legacy_gal
in and legacy GAL targets, and harominizes with legacy_wx.

This also means .cpp files in common/legacy_gal do not
need to specify the legacy_gal subdirectory, so they
will continue to work as needed when legacy_wx is removed.
---
 common/CMakeLists.txt| 1 +
 common/legacy_gal/block.cpp  | 2 +-
 common/legacy_gal/eda_draw_frame.cpp | 2 +-
 common/legacy_gal/other.cpp  | 3 +--
 eeschema/CMakeLists.txt  | 1 -
 5 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index f511fd449..924599753 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -88,6 +88,7 @@ add_library( legacy_gal STATIC ${LEGACY_GAL_SRCS} )
 add_library( legacy_wx STATIC ${LEGACY_WX_SRCS} )
 
 target_include_directories( legacy_wx PUBLIC ../include/legacy_wx )
+target_include_directories( legacy_gal PUBLIC ../include/legacy_gal )
 
 target_link_libraries( gal
 ${GLEW_LIBRARIES}
diff --git a/common/legacy_gal/block.cpp b/common/legacy_gal/block.cpp
index 15621610b..b6a6a98bb 100644
--- a/common/legacy_gal/block.cpp
+++ b/common/legacy_gal/block.cpp
@@ -34,7 +34,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/common/legacy_gal/eda_draw_frame.cpp b/common/legacy_gal/eda_draw_frame.cpp
index 926c25fff..cd033a84e 100644
--- a/common/legacy_gal/eda_draw_frame.cpp
+++ b/common/legacy_gal/eda_draw_frame.cpp
@@ -35,7 +35,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/common/legacy_gal/other.cpp b/common/legacy_gal/other.cpp
index 918a77a7a..7fe3938ff 100644
--- a/common/legacy_gal/other.cpp
+++ b/common/legacy_gal/other.cpp
@@ -3,7 +3,7 @@
 #include "base_screen.h"
 #include "common.h"
 #include "macros.h"
-#include "legacy_gal/class_drawpanel.h"
+#include "class_drawpanel.h"
 #include "marker_base.h"
 #include "dialog_display_info_HTML_base.h"
 
@@ -12,5 +12,4 @@
 void MARKER_BASE::DrawMarker( EDA_DRAW_PANEL* aPanel, wxDC* aDC, GR_DRAWMODE aDrawMode,
   const wxPoint& aOffset )
 {
-   
 }
diff --git a/eeschema/CMakeLists.txt b/eeschema/CMakeLists.txt
index 6a3cb8856..2f53e84de 100644
--- a/eeschema/CMakeLists.txt
+++ b/eeschema/CMakeLists.txt
@@ -20,7 +20,6 @@ endif()
 
 include_directories( BEFORE ${INC_BEFORE} )
 include_directories(
-../include/legacy_gal
 ./dialogs
 ./netlist_exporters
 ./widgets
-- 
2.19.1

___
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] warning: enum constant in boolean context in dialog_print_generic.cpp

2018-11-07 Thread Maciej Sumiński 
Hi Andrew,

Good catch, thank you! I have just pushed your patch to the master branch.

Regards,
Orson

On 11/7/18 6:16 AM, Andrew Lutsenko wrote:
> Hi Orson and KiCad devs,
> 
> During rebuilding current nightly I noticed this warning and decided to
> look into it.
> 
> /usr/local/google/home/alutsenko/src/kicad/common/dialogs/dialog_print_generic.cpp:
> In member function ‘virtual void
> DIALOG_PRINT_GENERIC::onCloseButton(wxCommandEvent&)’:
> /usr/local/google/home/alutsenko/src/kicad/common/dialogs/dialog_print_generic.cpp:246:24:
> warning: enum constant in boolean context [-Wint-in-bool-context]
>  Close( wxID_CANCEL );
> ^
> wxWindow::Close takes a boolean as an argument and wxID_CANCEL being not
> zero means this will be interpreted as force close. I don't think this was
> the intended behavior here.
> 
> Please take a look at my simple patch that fixes this warning and (I think)
> a latent bug.
> 
> Regards,
> Andrew Lutsenko
> 




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