Re: [Kicad-developers] [PATCH] Fix depency bug introduced in RPATH patch

[Steven A. Falco]

On 03/05/2018 07:52 PM, hauptmech wrote:
> The attached patch may fix the build error seen after the RPATH patch.

I was able to build the latest source on my machine with this patch included.  
While one run is hardly conclusive, I think this patch has merit.

I'll do some additional runs, and hopefully Nick can also re-test.

Thanks for the rapid response.

Steve


___
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] Fix depency bug introduced in RPATH patch

[hauptmech]

The attached patch may fix the build error seen after the RPATH patch.

>From 4bdf9c309ae7a794014d5c3240ad8599b1273dc9 Mon Sep 17 00:00:00 2001
From: hauptmech 
Date: Tue, 6 Mar 2018 13:46:05 +1300
Subject: [PATCH] Fix dependency bug introduced in RPATH patch e0b33ee8
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.16.2"

This is a multi-part message in MIME format.
--2.16.2
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit

---
 pcbnew/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


--2.16.2
Content-Type: text/x-patch; name="0001-Fix-dependency-bug-introduced-in-RPATH-patch-e0b33ee.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Fix-dependency-bug-introduced-in-RPATH-patch-e0b33ee.patch"

diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index 3ec6bbc23..dfe8e7113 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -685,7 +685,7 @@ add_dependencies( pcbnew pcbnew_kiface )
 
 # add dependency to specctra_lexer_source_files, to force
 # generation of autogenerated file
-add_dependencies( pcbnew_kiface specctra_lexer_source_files )
+add_dependencies( pcbnew_kiface_objects specctra_lexer_source_files )
 
 # these 2 binaries are a matched set, keep them together:
 if( APPLE )

--2.16.2--


___
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] Build error

[hauptmech]

Sorry, you did and I missed it.

A dependency was missed. I think the following might fix it.

in pcbnew/CMakeLists.txt
-add_dependencies( pcbnew_kiface specctra_lexer_source_files )
+add_dependencies( pcbnew_kiface_objects specctra_lexer_source_files )


On 06/03/18 13:10, Nick Østergaard wrote:
I just gave you hints on how to reproduce this. I suspect the most 
important part is the high number of make jobs. I use cmake version 
3.10.2 on archlinux.


2018-03-06 1:03 GMT+01:00 hauptmech >:


If you have any hints on how to reproduce the failure I can try to
help. The cmake version being used might help.


On 06/03/18 12:55, Nick Østergaard wrote:

I reproduce in a clean workspace like this:
git clone https://github.com/KiCad/kicad-source-mirror.git
 kicad_steven
cd kicad_steven/
mkdir build
cd build/
cmake .. -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF
-DKICAD_SCRIPTING_WXPYTHON=OFF
make -j40


On 5.0.0-rc2-dev-101-gf7ef010fe

2018-03-06  0:37 GMT+01:00 Nick Østergaard
>:

Ok, now I also see that issue. It could very easily be that
RPATH commit making the build system unstable. It is a
problem that the generated files are not in the build dir,
but in the source dir.


2018-03-05 23:22 GMT+01:00 Nick Østergaard >:

It also seem to build correctly on jenkins.

2018-03-05 23:16 GMT+01:00 Steven A. Falco
>:

I'm going to retract this report.  It builds
correctly on copr, so the problem must be something
in my local setup.

Sorry for the noise.

        Steve

___
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] Build error

[Steven A. Falco]

On 03/05/2018 06:55 PM, Nick Østergaard wrote:
> I reproduce in a clean workspace like this:
> git clone https://github.com/KiCad/kicad-source-mirror.git kicad_steven
> cd kicad_steven/
> mkdir build
> cd build/
> cmake .. -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF 
> -DKICAD_SCRIPTING_WXPYTHON=OFF
> make -j40

Thank you, thank you, thank you!

I thought I was going crazy there for a minute - sometimes it would work and 
other times it would fail.  So it looks like a race somewhere.  The contents of 
the generated file suggest that, too.  Here is part of specctra_lexer.h, which 
looks like two iterations of the generator are running simultaneously into the 
same file:

T_LEFT  = DSN_LEFT, // left bracket:  '('
T_STRING= DSN_STRING,   // a quoted string, stripped of the 
quotes
T_EOF   = DSN_EOF,  // special case for end of file

,
T_add_pinsT_absolute = 0,
,
T_add_groupT_added,
T_add_pins,
,
T_allow_antennaT_added,
,
T_allow_antenna,
T_allow_redundant_wiringT_allow_redundant_wiring,
,
T_ampT_amp,

Later on in the generated file there is:


#endif   // SPECCTRA_LEXER_H_
,
T_use_via,
T_value,
T_vertical,

so it looks like one incarnation has ended, and emitted its #endif, but the 
second is still running, and pushes out more values.

The clincher is that I have two copies of DSN::T NextTok() in the generated 
file.

Again for reference I've attached the generated specctra_lexer.h.

So I guess my first report was not noise after all!

Steve


> 
> 
> On 5.0.0-rc2-dev-101-gf7ef010fe
> 
> 2018-03-06 0:37 GMT+01:00 Nick Østergaard  >:
> 
> Ok, now I also see that issue. It could very easily be that RPATH commit 
> making the build system unstable. It is a problem that the generated files 
> are not in the build dir, but in the source dir.
> 
> 
> 2018-03-05 23:22 GMT+01:00 Nick Østergaard  >:
> 
> It also seem to build correctly on jenkins.
> 
> 2018-03-05 23:16 GMT+01:00 Steven A. Falco  >:
> 
> I'm going to retract this report.  It builds correctly on copr, 
> so the problem must be something in my local setup.
> 
> Sorry for the noise.
> 
>         Steve
> 
> ___
> 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 
> 
> 
> 
> 
> 


/* Do not modify this file it was automatically generated by the
 * TokenList2DsnLexer CMake script.
 */

#ifndef SPECCTRA_LEXER_H_
#define SPECCTRA_LEXER_H_

#include 

/**
 * C++ does not put enum _values_ in separate namespaces unless the enum itself
 * is in a separate namespace.  All the token enums must be in separate namespaces
 * otherwise the C++ compiler will eventually complain if it sees more than one
 * DSNLEXER in the same compilation unit, say by mutliple header file inclusion.
 * Plus this also enables re-use of the same enum name T.  A typedef can always be used
 * to clarify which enum T is in play should that ever be a problem.  This is
 * unlikely since Parse() functions will usually only be exposed to one header
 * file like this one.  But if there is a problem, then use:
 *   typedef DSN::T T;
 * within that problem area.
 */
namespace DSN
{
/// enum T contains all this lexer's tokens.
enum T
{
// these first few are negative special ones for syntax, and are
// inherited from DSNLEXER.
T_NONE  = DSN_NONE,
T_COMMENT   = DSN_COMMENT,
T_STRING_QUOTE  = DSN_STRING_QUOTE,
T_QUOTE_DEF = DSN_QUOTE_DEF,
T_DASH  = DSN_DASH,
T_SYMBOL= DSN_SYMBOL,
T_NUMBER= DSN_NUMBER,
T_RIGHT = DSN_RIGHT,// right bracket: ')'
T_LEFT  = DSN_LEFT, // left bracket:  '('
T_STRING= DSN_STRING,   // a quoted string, stripped of the quotes
T_EOF   = DSN_EOF,  // special case for end of file

,
T_add_pinsT_absolute = 0,
,
T_add_groupT_added,
T_add_pins,
,
T_allow_antennaT_added,
,
T_allow_antenna,
T_allow_redundant_wiringT_allow_redundant_wiring,
,
T_ampT_amp,
,
T_ancestor,
T_ancestorT_antipad,
,
T_aperture_type   

Re: [Kicad-developers] Build error

[Nick Østergaard]

I just gave you hints on how to reproduce this. I suspect the most
important part is the high number of make jobs. I use cmake version 3.10.2
on archlinux.

2018-03-06 1:03 GMT+01:00 hauptmech :

> If you have any hints on how to reproduce the failure I can try to help.
> The cmake version being used might help.
>
>
> On 06/03/18 12:55, Nick Østergaard wrote:
>
> I reproduce in a clean workspace like this:
> git clone https://github.com/KiCad/kicad-source-mirror.git kicad_steven
> cd kicad_steven/
> mkdir build
> cd build/
> cmake .. -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF
> -DKICAD_SCRIPTING_WXPYTHON=OFF
> make -j40
>
>
> On 5.0.0-rc2-dev-101-gf7ef010fe
>
> 2018-03-06 <20%2018%2003%2006> 0:37 GMT+01:00 Nick Østergaard <
> oe.n...@gmail.com>:
>
>> Ok, now I also see that issue. It could very easily be that RPATH commit
>> making the build system unstable. It is a problem that the generated files
>> are not in the build dir, but in the source dir.
>>
>>
>> 2018-03-05 23:22 GMT+01:00 Nick Østergaard :
>>
>>> It also seem to build correctly on jenkins.
>>>
>>> 2018-03-05 23:16 GMT+01:00 Steven A. Falco :
>>>
 I'm going to retract this report.  It builds correctly on copr, so the
 problem must be something in my local setup.

 Sorry for the noise.

 Steve

 ___
 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] Build error

[hauptmech]

If you have any hints on how to reproduce the failure I can try to help. 
The cmake version being used might help.


On 06/03/18 12:55, Nick Østergaard wrote:

I reproduce in a clean workspace like this:
git clone https://github.com/KiCad/kicad-source-mirror.git kicad_steven
cd kicad_steven/
mkdir build
cd build/
cmake .. -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF 
-DKICAD_SCRIPTING_WXPYTHON=OFF

make -j40


On 5.0.0-rc2-dev-101-gf7ef010fe

2018-03-06 0:37 GMT+01:00 Nick Østergaard >:


Ok, now I also see that issue. It could very easily be that RPATH
commit making the build system unstable. It is a problem that the
generated files are not in the build dir, but in the source dir.


2018-03-05 23:22 GMT+01:00 Nick Østergaard >:

It also seem to build correctly on jenkins.

2018-03-05 23:16 GMT+01:00 Steven A. Falco
>:

I'm going to retract this report.  It builds correctly on
copr, so the problem must be something in my local setup.

Sorry for the noise.

        Steve

___
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] GerbView: Severe bug: ASSERT on Startup

[Nick Østergaard]

Go here https://bugs.launchpad.net/kicad/+bug/1753592

Den 6. mar. 2018 12.58 AM skrev "Clemens Koller" :

> Debug build of SHA1 ID: 5a33f09
> KiCad-from-scratch (no configs, etc...)
> When I open GerbView, I immediately get:
>
>
> ASSERT INFO:
> ./src/gtk/scrolwin.cpp(227): assert "scrolled" failed in
> DoShowScrollbars(): window must be created
>
> BACKTRACE:
> [1] wxScrollHelper::DoShowScrollbars(wxScrollbarVisibility,
> wxScrollbarVisibility)
> [2] wxEntry(int&, wchar_t**)
> [3] __libc_start_main
> [4] _start
>
> -8<-
>
> Application: gerbview
> Version: (5.0.0-rc2-dev-101-g525270ac2), debug build
> Libraries:
> wxWidgets 3.0.3
> libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1
> (+libidn2/2.0.4) nghttp2/1.30.0
> Platform: Linux 4.15.6-1-ARCH x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
> Boost: 1.66.0
> Curl: 7.58.0
> Compiler: GCC 7.3.0 with C++ ABI 1011
>
> Build settings:
> USE_WX_GRAPHICS_CONTEXT=OFF
> USE_WX_OVERLAY=OFF
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_SPICE=ON
>
>
> Regards,
>
> Clemens
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] GerbView: Severe bug: ASSERT on Startup

[Clemens Koller]

Debug build of SHA1 ID: 5a33f09
KiCad-from-scratch (no configs, etc...)
When I open GerbView, I immediately get:


ASSERT INFO:
./src/gtk/scrolwin.cpp(227): assert "scrolled" failed in DoShowScrollbars(): 
window must be created

BACKTRACE:
[1] wxScrollHelper::DoShowScrollbars(wxScrollbarVisibility, 
wxScrollbarVisibility)
[2] wxEntry(int&, wchar_t**)
[3] __libc_start_main
[4] _start

-8<-

Application: gerbview
Version: (5.0.0-rc2-dev-101-g525270ac2), debug build
Libraries:
wxWidgets 3.0.3
libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
(+libidn2/2.0.4) nghttp2/1.30.0
Platform: Linux 4.15.6-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.66.0
Curl: 7.58.0
Compiler: GCC 7.3.0 with C++ ABI 1011

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_SPICE=ON


Regards,

Clemens

___
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] Build error

[Nick Østergaard]

I reproduce in a clean workspace like this:
git clone https://github.com/KiCad/kicad-source-mirror.git kicad_steven
cd kicad_steven/
mkdir build
cd build/
cmake .. -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF
-DKICAD_SCRIPTING_WXPYTHON=OFF
make -j40


On 5.0.0-rc2-dev-101-gf7ef010fe

2018-03-06 0:37 GMT+01:00 Nick Østergaard :

> Ok, now I also see that issue. It could very easily be that RPATH commit
> making the build system unstable. It is a problem that the generated files
> are not in the build dir, but in the source dir.
>
>
> 2018-03-05 23:22 GMT+01:00 Nick Østergaard :
>
>> It also seem to build correctly on jenkins.
>>
>> 2018-03-05 23:16 GMT+01:00 Steven A. Falco :
>>
>>> I'm going to retract this report.  It builds correctly on copr, so the
>>> problem must be something in my local setup.
>>>
>>> Sorry for the noise.
>>>
>>> Steve
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] GerbView: Minor cleanup of Menus + Toolbar for consistency.

[Wayne Stambaugh]

Clemens,

I merged your patch.  Thank you for your contribution to KiCad.

Cheers,

Wayne

On 02/27/2018 05:35 PM, Clemens Koller wrote:
> replace: File -> File(s) when wxFD_MULTIPLE
> replace: Load -> Open
> replace: Erase -> Clear
> add Excellon / Gerber where it makes sense
> re-sort File menu
> 
> Regards,
> 
> Clemens
> 
> 
> 
> ___
> 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] Build error

[Nick Østergaard]

Ok, now I also see that issue. It could very easily be that RPATH commit
making the build system unstable. It is a problem that the generated files
are not in the build dir, but in the source dir.

2018-03-05 23:22 GMT+01:00 Nick Østergaard :

> It also seem to build correctly on jenkins.
>
> 2018-03-05 23:16 GMT+01:00 Steven A. Falco :
>
>> I'm going to retract this report.  It builds correctly on copr, so the
>> problem must be something in my local setup.
>>
>> Sorry for the noise.
>>
>> Steve
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [deadly serious feature request] Use PNS for components as well as traces using rigid body simulation.

[Clemens Koller]

Hi!

I am wondering how difficult it might get to apply the Push & Shove idea also 
to components including all attached traces and use rigid body simulation of a 
physics engine to get it pushed and shoved around?

Quick & Dirty ideas: KiCad exports as .SVG. Blender imports .SVG.
The rest is easy, as you can see: [Blender Tutorial - Quick Rigid Body Fun] 
https://www.youtube.com/watch?v=nHVYYMG3QVY

Can we put that on the roadmap for V7 ??!  8-)

Regards,

Clemens

___
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] MacOS + OpenMP

[Bernhard Stegmaier]

Hi again,

just wanted to share some of my OpenMP on macOS experience, FWIW:

I used both clang-5.0.1 and clang-6.0 from MacPorts.
KiCad builds fine with it.

It works fine on my build machine (b).
On my MacBook (a) such a build always crashes when ratsnest changes after I 
opened the PCB (e.g. move/update a footprint).
Initial ratsnest on opening the PCB is for whatever reason OK.
On a third machine (c) it crashes just like on (a).

There is some OpenMP stuff in the ratsnest code.
On my build machine I can stress the ratsnest code by moving a component around.
It is really using multiple threads according to CPU load.

That’s with clang-6.0.

A previous build with clang-5.0 doesn’t show this crash with ratsnest, but the 
3d-viewer hang/crash problems I asked about in the other mail.
Again, 3d-viewer in OpenGL mode doesn’t work on my MacBook, but perfectly works 
on my build machine (same PCB, of course).

In backtraces of crashes always libomp task stuff is involved.

(b) and (c) are still on macOS 10.12, (a) is on 10.13.
It doesn’t seem to be about macOS version, because on one 10.12 machine the 
build is working, on the other not.

Of course, all machines are different HW. 
(b) is a 2012 i7. The other machines are a 2012 i5 and i3.
I even did a local build of libomp on my MacBook to rule out that it might use 
some i7 specific stuff that doesn’t run on i5/i3.
Didn’t help, I get the same crashes.

At the moment, I don’t really know what’s going on.
I looked at the code both for the 3d-viewer problem and the ratsnest stuff, but 
I don’t see anything being obviously wrong.
Of course, I don’t claim that I have understood every detail of it and I am no 
OpenMP expert.
It obviously works on a lot of linux boxes, so I guess it can’t be that wrong.

If someone wants to try the build:
  https://drive.google.com/open?id=1rpuKYxpHZTk5YiWe8s3LhIssHxJ9Y1oh 

I’d be happy to hear if it works or not, especially with OpenGL 3d-viewer 
and/or the rats nest use-case.


Regards,
Bernhard

> On 3. Mar 2018, at 20:33, Bernhard Stegmaier  wrote:
> 
> Hi all,
> 
> So, I played around a bit to get OpenMP and GCD into something like a 
> “parallel_for” wrapper which either uses OpenMP or GCD.
> Unfortunately, OpenMP seems to require that the “for” statement directly 
> follows the “#pragma omg for …”.
> That currently killed all my attempts to define such a “parallel_for” (as 
> function, #define, ?) so that the code will stay the same for both.
> One option would be to pull the “#pragma omp for …” into the wrapper, but I 
> guess this is not really acceptable (since you can’t specify any specific 
> schedule parameters any longer).
> 
> I will think about it some more just because of the challenge… but I am not 
> very optimistic at the moment to get something nice.
> If anyone else has a nice idea, I’d be very interested to learn freaky new 
> stuff… :)
> 
> On the other side, I looked at using a non-Xcode OpenMP capable clang.
> The only caveat seems to be not to mix standard C++ libraries (in the past 
> libc++/libstdc++ haven’t been compatible in some aspects - didn’t try to find 
> out if that is resolved).
> Default on macOS now is libc++, but it seems that at least MacPorts builds 
> clang with libstdc++ per default (no idea why).
> The MacPorts build can easily be switched to libc++.
> That clang-mp builds KiCad without problems even if dependencies have been 
> built with Xcode clang.
> Everything seems to work as expected, multithreading is there where it should 
> be.
> 
> So, for now it seems to be the most easy solution to switch to a suitable 
> non-Xcode clang for building packages - if we want to have OpenMP for macOS.
> 
> AFAIK our build machines use Homebrew.
> Seems as if Homebrew decides which standard library to use depending on macOS 
> version (https://docs.brew.sh/C++-Standard-Libraries 
> ).
> So, if everything is recent enough it might not be a problem at all… like it 
> obviously also has been for Seth below.
> 
> 
> Regards,
> Bernhard
> 
>> On 1. Mar 2018, at 17:47, Seth Hillbrand > > wrote:
>> 
>> Hi All-
>> 
>> I was playing with this last night (don't normally compile on the mac) and 
>> found that using homebrew's llvm 3.8.1 seems to compile fine with -fopenmp.  
>> Running some OMP test code from 
>> https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5 
>>  
>> shows expected result of 4 threads.  I didn't get OpenMP errors when 
>> compiling KiCad although I didn't really notice a substantial difference in 
>> speed for the quick tests I was running.  Maybe with more involved 
>> operations.
>> 
>> I'm not sure if this will require us to distribute a different libstdc++ 
>> with KiCad.  Probably.  Does that 

Re: [Kicad-developers] Build error

[Nick Østergaard]

It also seem to build correctly on jenkins.

2018-03-05 23:16 GMT+01:00 Steven A. Falco :

> I'm going to retract this report.  It builds correctly on copr, so the
> problem must be something in my local setup.
>
> Sorry for the noise.
>
> Steve
>
> ___
> 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] Build error

[Steven A. Falco]

I'm going to retract this report.  It builds correctly on copr, so the problem 
must be something in my local setup.

Sorry for the noise.

Steve

___
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] Build error

[Steven A. Falco]

I ran a bisection, and it looks like the first bad commit is:

e0b33ee8a Fix RPATH not removed in shared object file for python

I can build its predecessor, 62bcf4fde41, without any problems.  I attached the 
bisect log, showing which commits I tried to build, and the results.

Steve


On 03/05/2018 02:13 PM, Steven A. Falco wrote:
> Yes it does.  I'm building on Fedora via the "mock" tool, which always starts 
> from an empty directory.  Just to be sure, I removed the entire "mock" 
> working area, and I even re-downloaded the source repositories.  I'll try 
> pushing the build up to the Copr build-system, and I'll report back with my 
> findings.
> 
>   Steve
> 
> On 03/05/2018 01:43 PM, Seth Hillbrand wrote:
>> Does the compile error exist after you make clean and re-make?
>>
>> 2018-03-05 10:20 GMT-08:00 Steven A. Falco > >:
>>
>> I just got a build error on Linux, at git commit 218f66a08, which 
>> appears to be the latest commit.
>>
>> In file included from 
>> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra.h:36:0,
>>                  from 
>> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_import.cpp:50:
>> 
>> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:1075:2:
>>  error: #endif without #if
>>  #endif   // SPECCTRA_LEXER_H_
>>   ^
>> 
>> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:308:25:
>>  error: expected '}' before 'T_absolute'
>>          T_routes        T_absolute = 0,
>>                          ^~
>> 
>> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:308:38:
>>  error: invalid conversion from 'int' to 'DSN::T' [-fpermissive]
>>          T_routes        T_absolute = 0,
>>                                       ^
>> 
>> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:309:1:
>>  error: expected unqualified-id before ',' token
>>  ,
>>  ^
>> 
>> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:310:33:
>>  error: expected initializer before 'T_add_group'
>>          T_routes_include        T_add_group,
>>                                  ^~~
>> 
>> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:511:1:
>>  error: expected declaration before '}' token
>>  }   // namespace DSN
>>  ^
>> make[2]: *** 
>> [pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/build.make:4979: 
>> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/specctra_import_export/specctra_import.cpp.o]
>>  Error 1
>>
>>
>> I looked at specctra_lexer.h (attached) and sure enough it has an 
>> unbalanced #ifndef / #endif.  This file is apparently auto-generated by 
>> cmake - I have no knowledge of the details.
>>
>>         Steve
>>
>> ___
>> 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 
>> 
>>
>>
> 
> 

bad 218f66a08b36bba9f2f4ab32753a97ca116f863a Fix sign comparison warning
5bbb4489b3ab7f36fccd8822ee03ae5f92234fc3 Fixed out of bounds access to 
m_shaderBuffer array in 3D viewer raytracer
bad e0b33ee8a605c5366e0b2e26e8d30192d9b742f7 Fix RPATH not removed in 
shared object file for python
good62bcf4fde41e68dc2bb5435270155efa689dd300 pcbnew: reorder "Fabrication 
Outputs" in menu
good3e54e16bdceedd2d96bafd7728cdb223df8a6876 Update ratsnest after a 
footprint change
0521b63503c2b70864e22e28a9e9a6408c4fcd33 Remove negation from 
PCB_BASE_FRAME::PlaceModule() parameter
4be12292a0555f4127003ba54b3131797c759703 Fixed duplicate misbehaviour 
when duplicating single track/via
fabbc48b40445ff2b7ec30d025dcc808920046df macOS: standardise 
CFBundleName to application names.
good9c44d67f3b3162d7abf9ce5eb689975229348eed Eeschema: Simplify 
transformation representation
f4eb63f8716ec3ce5e37bcf556523c6e6bf0bf3c Size fields list correctly in 
symbol edit.
90e2c8dd7f2aa31b74fb24fce0a4b96b6e93d581 Get rid of first-scroll 
jerkiness in eeschema.
cd2224b94d14ab6ffd43f4a7f684aed324c143b0 Add missing hotkey support to 
GerbView
d2c86f859456589a71ff93ccdc04c7a6090fea5b GerbView: Disable legacy-only 
event handlers when GAL is active
01ef0bd2e9237ce5d6109616ee94294a1501c161 pcbnew: Add graphic polygon on 
drawing layer

Re: [Kicad-developers] [fun feature request] Create PCB from schematic with one click :)

[Russell Oliver]

I didn't mean to infer that the final location of a part would be
determined by the schematic, just the initial placement of parts in pcbnew
when the netlist is first read. Similar to the spread out all components
tool. A starting point.

I can also imagine a tool that would try to minimise the overall bounding
box of the selection, with maybe a specified minimum gap.

I think there exists plenty of scope for semi automatic processes to boost
designer productivity; dragging tracks attached to a component, grouping
tools, pin swapping. Single/differential track autorouting i.e select a net
or pair and auto route it and present multiple alternatives. Much like the
alternative routes in say Google maps.

And many more that are probably all ready thought of and have been made
into a script.




On Tue, 6 Mar 2018 07:53 Andy Peters,  wrote:

>
> > On Mar 5, 2018, at 11:49 AM, Russell Oliver 
> wrote:
> >
> > In terms of automatically arranging  components a force directed graph
> algorithm may work quite nicely, especially if the algorithm is seeded with
> the layout of components on the schematic.
> >
> > A simplistic version would be to just arrange components on board sheet
> as to their position on the schematic sheets.
>
> That approach might be fine for something like a VME CPU board filled with
> 74xxx TTL parts, but modern designs have too many other considerations. For
> example, most things fit into some kind of enclosure, and as such the
> mechanical constraints matter, and then trying to draw a schematic to
> represent placement can make a mess of things. What if the person drawing
> the schematic has no idea at the start what kind of enclosure will be used?
>
> The “seeding” can be in some cases inferred from the netlist and
> connections. This goes to that, that goes to something else, and this that
> there ends up being in the middle. pcbnew’s netlist import generally keeps
> parts on the same schematic page together. Start with stuff that needs to
> be located specifically because of mechanical concerns. It usually turns
> out that parts will go whether they need to go, and that becomes obvious
> once you have them all on the canvas and the rats nest is visible. You
> start with the big parts and fit the supporting parts around them.
>
> I can’t think of any board I’ve done in the last {harumph!} years where I
> drew the schematic in a way that reflected the final parts placement.
>
> -a
> ___
> 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] Settable clearances

[hauptmech]

Yeah, this is a really tough part of leading a project, figuring out 
what is whim and what is worth adjusting course for.  Anyway, I'll 
finish the patch, get it checked, and then present my case.


On 06/03/18 04:01, Wayne Stambaugh wrote:

This happened last stable release.  Users wait to the last minute and
then make a request for a new feature.  If this would have been proposed
six months ago, it probably would be part of the v5 release.  The
feature itself is a good idea but it will have to be deferred to some
later version.  We really need to stay focused on the v5 release.  It's
too easy to give into every whim and just keep pushing back v5.  This
happened somewhat in v4 and it took a long time to get from feature
freeze to release so I'm trying to prevent that from happening again.
We are never going to win this fight.  There will always be people who
think we should push back a stable release for some new feature.

Wayne

On 3/5/2018 8:59 AM, Jon Evans wrote:

I can certainly help check it.  I think Wayne would have to make a call
as to whether or not it's too big a change to introduce now.

-Jon

On Mon, Mar 5, 2018 at 7:59 AM, hauptmech > wrote:

 While testing version 5 I realized that clearances are still not
 settable (like track width or via size) and my life is going to be
 miserable if I have to continue with my current work flow which is
 to change the default netclass clearance to the desired clearance
 constantly as I lay down different tracks which require different
 clearances even though they are part of the some net.

 There is a previous thread detailing why netclass is not sufficient
 for all use cases. Search for netclass in the subject.

 Anyway, I wrote most of a patch today (it's 1am in my timezone now)
 and expect to finish it tomorrow. I believe I have a solution which
 will be useful for those that need it and mostly invisible to those
 that don't.

 The question is whether there is a core developer willing to check,
 sign off, and help sell it for inclusion in 5. (I'm stuck using
 whatever the current stable version of kicad is when I'm working)

 This is a huge pain point for me and I'm willing to negotiate a
 small bounty if that helps.



 ___
 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] [fun feature request] Create PCB from schematic with one click :)

[Pedro Martin]

So it is already implemented in the legacy canvas:

-Global spread and place -> Spread out All Footprints
-Autoroute -> Automatically Route All Footprints

Well, two clicks instead one just one.

I'm with Wayne: no effort should be added to autorouting as there are 
plenty of features to sort out.


What about 16 layer autorouter, with differential pairs, automatic 
zones, impedance matching, etc...


We are wasting our time with this topic, but some fun from time to time 
doesn't hurt.


Pedro.

El 05/03/18 a las 19:49, Russell Oliver escribi�:

In terms of automatically arranging  components a force directed graph
algorithm may work quite nicely, especially if the algorithm is seeded
with the layout of components on the schematic.

A simplistic version would be to just arrange components on board sheet
as to their position on the schematic sheets.

On Tue, 6 Mar 2018 05:07 Andy Peters, > wrote:



> On Mar 5, 2018, at 10:49 AM, Wayne Stambaugh > wrote:
>
> I was thinking one level of abstraction higher where I just input my
> design requirements and it spits out a schematic, full simulation to
> match the design requirements, and a completed board layout.  That
would
> make my job a *lot* easier. ;)

Maybe it can do my FPGA design for me, and also write firmware for
the ARM processor too! Why am I doing all of this hard work when I
could be drinking coffee and reading the New York Times?

> All kidding aside, I was told by a very highly skilled board designer
> not to waste our time with auto-routers because no one actually uses
> them except for the simplest designs with lots of free board space and
> few or no routing restrictions.  This is someone who uses Altium
in his
> day job and has laid out far more boards than I have.

At the previous day job, we did VME and CompactPCI single-board
computers, and the layout people took advantage of full-up Specctra
autorouting. The designs had a lot of wide parallel buses and
suchlike which could be autorouted, but there was still plenty of
stuff on those boards which needed to be routed manually. And
setting up constraints for the autorouter was still a couple of days
work.

At the current job everything is smaller. Each product has multiple
boards that need to connect correctly. Boards are mixed signal, they
have power supply parts, there are connectors that poke through the
enclosure, etc etc etc and suffice it to say we never autoroute.
Assisted routing, like the Kicad push-and-shove, and Altium�s �bus
routing� (a feature I�d like to see in Kicad, for sure!) goes a long
way.


> I'm guessing auto-routers appeal to hobbyists rather than
professionals.

How many questions on forums do you see from hobbyists asking about
how to autoroute, or wondering if the results from the autorouter
are good?

-a
___
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] Build error

[Steven A. Falco]

Yes it does.  I'm building on Fedora via the "mock" tool, which always starts 
from an empty directory.  Just to be sure, I removed the entire "mock" working 
area, and I even re-downloaded the source repositories.  I'll try pushing the 
build up to the Copr build-system, and I'll report back with my findings.

Steve

On 03/05/2018 01:43 PM, Seth Hillbrand wrote:
> Does the compile error exist after you make clean and re-make?
> 
> 2018-03-05 10:20 GMT-08:00 Steven A. Falco  >:
> 
> I just got a build error on Linux, at git commit 218f66a08, which appears 
> to be the latest commit.
> 
> In file included from 
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra.h:36:0,
>                  from 
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_import.cpp:50:
> 
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:1075:2:
>  error: #endif without #if
>  #endif   // SPECCTRA_LEXER_H_
>   ^
> 
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:308:25:
>  error: expected '}' before 'T_absolute'
>          T_routes        T_absolute = 0,
>                          ^~
> 
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:308:38:
>  error: invalid conversion from 'int' to 'DSN::T' [-fpermissive]
>          T_routes        T_absolute = 0,
>                                       ^
> 
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:309:1:
>  error: expected unqualified-id before ',' token
>  ,
>  ^
> 
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:310:33:
>  error: expected initializer before 'T_add_group'
>          T_routes_include        T_add_group,
>                                  ^~~
> 
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:511:1:
>  error: expected declaration before '}' token
>  }   // namespace DSN
>  ^
> make[2]: *** 
> [pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/build.make:4979: 
> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/specctra_import_export/specctra_import.cpp.o]
>  Error 1
> 
> 
> I looked at specctra_lexer.h (attached) and sure enough it has an 
> unbalanced #ifndef / #endif.  This file is apparently auto-generated by cmake 
> - I have no knowledge of the details.
> 
>         Steve
> 
> ___
> 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] [fun feature request] Create PCB from schematic with one click :)

[Russell Oliver]

The "spring" constants in a force directed graph algorithm could be set by
a user given priority or even by the length of schematic wires.

On Tue, 6 Mar 2018 05:53 Jon Evans,  wrote:

> In many commercial tools you can use some or another feature to mark up
> the design at the schematic level with what components "go together".
> Then that information is used during PCB placement, the first-pass arrange
> of components when you start designing a board can place those components
> together, but it is also possible to group them together and move as a
> group easily, etc.
>
> There are even some tools that automatically identify bypass capacitors
> (did the schematic have a capacitor drawn right near a pin on an IC?  In
> that case, assume it's a bypass cap) and can place them right near the IC
> (and run ERCs to make sure you don't have missing bypass caps, DRC to make
> sure they are close enough to the power pin in the layout, etc)
>
>
>
> On Mon, Mar 5, 2018 at 1:49 PM, Russell Oliver 
> wrote:
>
>> In terms of automatically arranging  components a force directed graph
>> algorithm may work quite nicely, especially if the algorithm is seeded with
>> the layout of components on the schematic.
>>
>> A simplistic version would be to just arrange components on board sheet
>> as to their position on the schematic sheets.
>>
>>
>> On Tue, 6 Mar 2018 05:07 Andy Peters,  wrote:
>>
>>>
>>>
>>> > On Mar 5, 2018, at 10:49 AM, Wayne Stambaugh 
>>> wrote:
>>> >
>>> > I was thinking one level of abstraction higher where I just input my
>>> > design requirements and it spits out a schematic, full simulation to
>>> > match the design requirements, and a completed board layout.  That
>>> would
>>> > make my job a *lot* easier. ;)
>>>
>>> Maybe it can do my FPGA design for me, and also write firmware for the
>>> ARM processor too! Why am I doing all of this hard work when I could be
>>> drinking coffee and reading the New York Times?
>>>
>>> > All kidding aside, I was told by a very highly skilled board designer
>>> > not to waste our time with auto-routers because no one actually uses
>>> > them except for the simplest designs with lots of free board space and
>>> > few or no routing restrictions.  This is someone who uses Altium in his
>>> > day job and has laid out far more boards than I have.
>>>
>>> At the previous day job, we did VME and CompactPCI single-board
>>> computers, and the layout people took advantage of full-up Specctra
>>> autorouting. The designs had a lot of wide parallel buses and suchlike
>>> which could be autorouted, but there was still plenty of stuff on those
>>> boards which needed to be routed manually. And setting up constraints for
>>> the autorouter was still a couple of days work.
>>>
>>> At the current job everything is smaller. Each product has multiple
>>> boards that need to connect correctly. Boards are mixed signal, they have
>>> power supply parts, there are connectors that poke through the enclosure,
>>> etc etc etc and suffice it to say we never autoroute. Assisted routing,
>>> like the Kicad push-and-shove, and Altium’s “bus routing” (a feature I’d
>>> like to see in Kicad, for sure!) goes a long way.
>>>
>>>
>>> > I'm guessing auto-routers appeal to hobbyists rather than
>>> professionals.
>>>
>>> How many questions on forums do you see from hobbyists asking about how
>>> to autoroute, or wondering if the results from the autorouter are good?
>>>
>>> -a
>>> ___
>>> 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] [fun feature request] Create PCB from schematic with one click :)

[Jon Evans]

In many commercial tools you can use some or another feature to mark up the
design at the schematic level with what components "go together".
Then that information is used during PCB placement, the first-pass arrange
of components when you start designing a board can place those components
together, but it is also possible to group them together and move as a
group easily, etc.

There are even some tools that automatically identify bypass capacitors
(did the schematic have a capacitor drawn right near a pin on an IC?  In
that case, assume it's a bypass cap) and can place them right near the IC
(and run ERCs to make sure you don't have missing bypass caps, DRC to make
sure they are close enough to the power pin in the layout, etc)



On Mon, Mar 5, 2018 at 1:49 PM, Russell Oliver 
wrote:

> In terms of automatically arranging  components a force directed graph
> algorithm may work quite nicely, especially if the algorithm is seeded with
> the layout of components on the schematic.
>
> A simplistic version would be to just arrange components on board sheet as
> to their position on the schematic sheets.
>
>
> On Tue, 6 Mar 2018 05:07 Andy Peters,  wrote:
>
>>
>>
>> > On Mar 5, 2018, at 10:49 AM, Wayne Stambaugh 
>> wrote:
>> >
>> > I was thinking one level of abstraction higher where I just input my
>> > design requirements and it spits out a schematic, full simulation to
>> > match the design requirements, and a completed board layout.  That would
>> > make my job a *lot* easier. ;)
>>
>> Maybe it can do my FPGA design for me, and also write firmware for the
>> ARM processor too! Why am I doing all of this hard work when I could be
>> drinking coffee and reading the New York Times?
>>
>> > All kidding aside, I was told by a very highly skilled board designer
>> > not to waste our time with auto-routers because no one actually uses
>> > them except for the simplest designs with lots of free board space and
>> > few or no routing restrictions.  This is someone who uses Altium in his
>> > day job and has laid out far more boards than I have.
>>
>> At the previous day job, we did VME and CompactPCI single-board
>> computers, and the layout people took advantage of full-up Specctra
>> autorouting. The designs had a lot of wide parallel buses and suchlike
>> which could be autorouted, but there was still plenty of stuff on those
>> boards which needed to be routed manually. And setting up constraints for
>> the autorouter was still a couple of days work.
>>
>> At the current job everything is smaller. Each product has multiple
>> boards that need to connect correctly. Boards are mixed signal, they have
>> power supply parts, there are connectors that poke through the enclosure,
>> etc etc etc and suffice it to say we never autoroute. Assisted routing,
>> like the Kicad push-and-shove, and Altium’s “bus routing” (a feature I’d
>> like to see in Kicad, for sure!) goes a long way.
>>
>>
>> > I'm guessing auto-routers appeal to hobbyists rather than professionals.
>>
>> How many questions on forums do you see from hobbyists asking about how
>> to autoroute, or wondering if the results from the autorouter are good?
>>
>> -a
>> ___
>> 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] [fun feature request] Create PCB from schematic with one click :)

[Russell Oliver]

In terms of automatically arranging  components a force directed graph
algorithm may work quite nicely, especially if the algorithm is seeded with
the layout of components on the schematic.

A simplistic version would be to just arrange components on board sheet as
to their position on the schematic sheets.

On Tue, 6 Mar 2018 05:07 Andy Peters,  wrote:

>
>
> > On Mar 5, 2018, at 10:49 AM, Wayne Stambaugh 
> wrote:
> >
> > I was thinking one level of abstraction higher where I just input my
> > design requirements and it spits out a schematic, full simulation to
> > match the design requirements, and a completed board layout.  That would
> > make my job a *lot* easier. ;)
>
> Maybe it can do my FPGA design for me, and also write firmware for the ARM
> processor too! Why am I doing all of this hard work when I could be
> drinking coffee and reading the New York Times?
>
> > All kidding aside, I was told by a very highly skilled board designer
> > not to waste our time with auto-routers because no one actually uses
> > them except for the simplest designs with lots of free board space and
> > few or no routing restrictions.  This is someone who uses Altium in his
> > day job and has laid out far more boards than I have.
>
> At the previous day job, we did VME and CompactPCI single-board computers,
> and the layout people took advantage of full-up Specctra autorouting. The
> designs had a lot of wide parallel buses and suchlike which could be
> autorouted, but there was still plenty of stuff on those boards which
> needed to be routed manually. And setting up constraints for the autorouter
> was still a couple of days work.
>
> At the current job everything is smaller. Each product has multiple boards
> that need to connect correctly. Boards are mixed signal, they have power
> supply parts, there are connectors that poke through the enclosure, etc etc
> etc and suffice it to say we never autoroute. Assisted routing, like the
> Kicad push-and-shove, and Altium’s “bus routing” (a feature I’d like to see
> in Kicad, for sure!) goes a long way.
>
>
> > I'm guessing auto-routers appeal to hobbyists rather than professionals.
>
> How many questions on forums do you see from hobbyists asking about how to
> autoroute, or wondering if the results from the autorouter are good?
>
> -a
> ___
> 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] Build error

[Seth Hillbrand]

Does the compile error exist after you make clean and re-make?

2018-03-05 10:20 GMT-08:00 Steven A. Falco :

> I just got a build error on Linux, at git commit 218f66a08, which appears
> to be the latest commit.
>
> In file included from /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/
> specctra_import_export/specctra.h:36:0,
>  from /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/
> specctra_import_export/specctra_import.cpp:50:
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:1075:2:
> error: #endif without #if
>  #endif   // SPECCTRA_LEXER_H_
>   ^
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:308:25:
> error: expected '}' before 'T_absolute'
>  T_routesT_absolute = 0,
>  ^~
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:308:38:
> error: invalid conversion from 'int' to 'DSN::T' [-fpermissive]
>  T_routesT_absolute = 0,
>   ^
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:309:1:
> error: expected unqualified-id before ',' token
>  ,
>  ^
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:310:33:
> error: expected initializer before 'T_add_group'
>  T_routes_includeT_add_group,
>  ^~~
> /builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:511:1:
> error: expected declaration before '}' token
>  }   // namespace DSN
>  ^
> make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/build.make:4979:
> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/specctra_
> import_export/specctra_import.cpp.o] Error 1
>
>
> I looked at specctra_lexer.h (attached) and sure enough it has an
> unbalanced #ifndef / #endif.  This file is apparently auto-generated by
> cmake - I have no knowledge of the details.
>
> Steve
>
> ___
> 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] Jumpy canvas on other platforms?

[Jeff Young]

I love wxWidgets.  :(

> On 5 Mar 2018, at 18:38, Wayne Stambaugh  wrote:
> 
> I'm still seeing this issue on windows as of commit 218f66a08.  The
> scrollbars are shown greyed out initially after the zoom extents but it
> appears that on windows, the paint area does not include the scollbar
> width when the scollbar is greyed out but does include them as soon as
> you pan and they get enabled.  This is what is causing the jumpy
> behavior.  The drawing canvas size is be reported differently even
> though the scrollbars are always shown.
> 
> On 3/5/2018 12:07 PM, Jeff Young wrote:
>> Thanks, everyone.  I think it’s more sensitive to a trackpad than mouse, but 
>> I merged a fix yesterday anyway.
>> 
>>> On 5 Mar 2018, at 16:41, Wayne Stambaugh  wrote:
>>> 
>>> I see it now.  I was moving the cursor too fast.  You have to move it
>>> very slowly to see the issue.  Hmm, never noticed that before.
>>> 
>>> On 3/5/2018 11:39 AM, Andrey Kuznetsov wrote:
 I notice the jerkiness on WIndows!
 
 When you start panning, very slowly, by a little bit, there is a period
 when it looks like the view window tries to center itself, so it jumps
 back and forth between where it used to be and where the mouse is going,
 until it's far enough and it snaps out of it and at the same time the
 scroll bars appear.
 
 On Mon, Mar 5, 2018 at 5:54 AM, Wayne Stambaugh > wrote:
 
   I'm not seeing this on my windows 7 builds.  The panning after zoom
   extents works smoothly.  I even tried resizing the main frame several
   times but I still didn't notice it.
 
   On 3/4/2018 5:00 PM, Jeff Young wrote:
> There is actually code in there to make them always on, but there seems
> to be something defeating it.  I’ll poke around some more.
> 
>> On 4 Mar 2018, at 21:57, Jon Evans > 
>> >> wrote:
>> 
>> Ah yes, I can reproduce that on Windows too.  I guess I didn't notice
>> before because generally the scrollbars are visible (I noticed that
>> "zoom extents" doesnt *always* result in the scrollbars being hidden,
>> for whatever reason)
>> Any reason why we hide the scrollbars?  Seems like it might be simpler
>> to just always show them...
>> -Jon
>> 
>> On Sun, Mar 4, 2018 at 4:52 PM, Bernhard Stegmaier
>> 
   >>
   wrote:
>> 
>> Do a “fit to window” and then pan left/right… I use the touchpad.
>> After “fit to window” there is no scrollbar.
>> When the scrollbar comes back due to panning, I see almost always
>> a small shift of the whole view down and then up again.
>> Sometimes, but not always if you just pan left/right it will make
>> this small jump downwards every time you cross center, just as if
>> it would “snap" to middle position.
>> 
>> 
>>> On 4. Mar 2018, at 21:25, Jon Evans >> 
>>> >> wrote:
>>> 
>>> Maybe I don't really understand what you mean, but I can't see
>>> any jumpiness on Linux when panning around (with middle-mouse drag).
>>> What do you mean by "it automatically fits to window, so there's
>>> not really any place to go"?  It does not do any kind of
>>> auto-fitting except for the zoom-extents on file load on Linux,
>>> and I don't have my Mac machine handy to compare.
>>> 
>>> On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young >> 
>>> >> wrote:
>>> 
>>> If I open an eeschema file on OSX and pan around (it
>>> automatically fits to window, so there’s not really any place
>>> to go), the screen jumps around a bit.  True also on other
>>> platforms, or Mac-specific?
>>> 
>>> Thanks,
>>> Jeff.
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
   
>>> >
>>> Post to : kicad-developers@lists.launchpad.net
   
>>> >
>>> Unsubscribe : https://launchpad.net/~kicad-developers
   
>>> 

Re: [Kicad-developers] Jumpy canvas on other platforms?

[Wayne Stambaugh]

I'm still seeing this issue on windows as of commit 218f66a08.  The
scrollbars are shown greyed out initially after the zoom extents but it
appears that on windows, the paint area does not include the scollbar
width when the scollbar is greyed out but does include them as soon as
you pan and they get enabled.  This is what is causing the jumpy
behavior.  The drawing canvas size is be reported differently even
though the scrollbars are always shown.

On 3/5/2018 12:07 PM, Jeff Young wrote:
> Thanks, everyone.  I think it’s more sensitive to a trackpad than mouse, but 
> I merged a fix yesterday anyway.
> 
>> On 5 Mar 2018, at 16:41, Wayne Stambaugh  wrote:
>>
>> I see it now.  I was moving the cursor too fast.  You have to move it
>> very slowly to see the issue.  Hmm, never noticed that before.
>>
>> On 3/5/2018 11:39 AM, Andrey Kuznetsov wrote:
>>> I notice the jerkiness on WIndows!
>>>
>>> When you start panning, very slowly, by a little bit, there is a period
>>> when it looks like the view window tries to center itself, so it jumps
>>> back and forth between where it used to be and where the mouse is going,
>>> until it's far enough and it snaps out of it and at the same time the
>>> scroll bars appear.
>>>
>>> On Mon, Mar 5, 2018 at 5:54 AM, Wayne Stambaugh >> > wrote:
>>>
>>>I'm not seeing this on my windows 7 builds.  The panning after zoom
>>>extents works smoothly.  I even tried resizing the main frame several
>>>times but I still didn't notice it.
>>>
>>>On 3/4/2018 5:00 PM, Jeff Young wrote:
 There is actually code in there to make them always on, but there seems
 to be something defeating it.  I’ll poke around some more.

> On 4 Mar 2018, at 21:57, Jon Evans  
> >> wrote:
>
> Ah yes, I can reproduce that on Windows too.  I guess I didn't notice
> before because generally the scrollbars are visible (I noticed that
> "zoom extents" doesnt *always* result in the scrollbars being hidden,
> for whatever reason)
> Any reason why we hide the scrollbars?  Seems like it might be simpler
> to just always show them...
> -Jon
>
> On Sun, Mar 4, 2018 at 4:52 PM, Bernhard Stegmaier
> 
>>>>>
>>>wrote:
>
>  Do a “fit to window” and then pan left/right… I use the touchpad.
>  After “fit to window” there is no scrollbar.
>  When the scrollbar comes back due to panning, I see almost always
>  a small shift of the whole view down and then up again.
>  Sometimes, but not always if you just pan left/right it will make
>  this small jump downwards every time you cross center, just as if
>  it would “snap" to middle position.
>
>
>>  On 4. Mar 2018, at 21:25, Jon Evans > 
>>  >> wrote:
>>
>>  Maybe I don't really understand what you mean, but I can't see
>>  any jumpiness on Linux when panning around (with middle-mouse drag).
>>  What do you mean by "it automatically fits to window, so there's
>>  not really any place to go"?  It does not do any kind of
>>  auto-fitting except for the zoom-extents on file load on Linux,
>>  and I don't have my Mac machine handy to compare.
>>
>>  On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young > 
>>  >> wrote:
>>
>>  If I open an eeschema file on OSX and pan around (it
>>  automatically fits to window, so there’s not really any place
>>  to go), the screen jumps around a bit.  True also on other
>>  platforms, or Mac-specific?
>>
>>  Thanks,
>>  Jeff.
>>  ___
>>  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] Proposed roadmap changes

[Wayne Stambaugh]

On 3/5/2018 1:15 PM, Jon Evans wrote:
> I believe embedded symbols is part of the file format / library format
> change heading.

It is part of the new schematic file format.

> 
> Back-annotation support in general is under the heading of "Pin and Part
> Swapping" in the roadmap, and it's a good idea to include re-annotating
> components as part of that.

That would be part of the back annotation process.

> 
> On Mon, Mar 5, 2018 at 1:11 PM, Andy Peters  > wrote:
> 
> 
> 
>> On Mar 5, 2018, at 10:57 AM, Jon Evans > > wrote:
>>
>> Hi all,
>>
>> Since my day job involves a lot of engineering
>> planning/timelines/etc, I've had this rolling around in my head...
>> I started brainstorming some proposed changes to the roadmaps.
>>
>> I am using Google drive because that's what is easiest for me to
>> play with; I'm happy to send patches against the official roadmaps
>> if get some buy-in for this.
>>
>> Feel free to comment (either directly on the doc or by email) with
>> thoughts on this.
>>
>> 
>> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
>> 
>> 
>>
>> Basically what I am proposing is to put most of the energy into
>> Eeschema for 6.0, with changes to other parts of the software
>> basically being "whatever people have time left over for". 
>> Everything else has been bumped to 7.0
> 
> I’m not sure where it fits into the roadmap, but the main EESchema
> feature I’d like to see implemented is the embedding of schematic
> symbols into the schematic sheet, in the same way that footprints
> are part of the kicad_pcb file.
> 
> Also the whole idea of renumbering the reference designators in a
> layout to be geographical, and then backannotating the designators
> to the schematic. (A guy can dream ..)
> -a
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

[Kicad-developers] Build error

[Steven A. Falco]

I just got a build error on Linux, at git commit 218f66a08, which appears to be 
the latest commit.

In file included from 
/builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra.h:36:0,
 from 
/builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_import.cpp:50:
/builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:1075:2:
 error: #endif without #if
 #endif   // SPECCTRA_LEXER_H_
  ^
/builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:308:25:
 error: expected '}' before 'T_absolute'
 T_routesT_absolute = 0,
 ^~
/builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:308:38:
 error: invalid conversion from 'int' to 'DSN::T' [-fpermissive]
 T_routesT_absolute = 0,
  ^
/builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:309:1:
 error: expected unqualified-id before ',' token
 ,
 ^
/builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:310:33:
 error: expected initializer before 'T_add_group'
 T_routes_includeT_add_group,
 ^~~
/builddir/build/BUILD/kicad-r12311-218f66a0/pcbnew/specctra_import_export/specctra_lexer.h:511:1:
 error: expected declaration before '}' token
 }   // namespace DSN
 ^
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/build.make:4979: 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/specctra_import_export/specctra_import.cpp.o]
 Error 1


I looked at specctra_lexer.h (attached) and sure enough it has an unbalanced 
#ifndef / #endif.  This file is apparently auto-generated by cmake - I have no 
knowledge of the details.

Steve

/* Do not modify this file it was automatically generated by the
 * TokenList2DsnLexer CMake script.
 */

#ifndef SPECCTRA_LEXER_H_
#define SPECCTRA_LEXER_H_

#include 

/**
 * C++ does not put enum _values_ in separate namespaces unless the enum itself
 * is in a separate namespace.  All the token enums must be in separate namespaces
 * otherwise the C++ compiler will eventually complain if it sees more than one
 * DSNLEXER in the same compilation unit, say by mutliple header file inclusion.
 * Plus this also enables re-use of the same enum name T.  A typedef can always be used
 * to clarify which enum T is in play should that ever be a problem.  This is
 * unlikely since Parse() functions will usually only be exposed to one header
 * file like this one.  But if there is a problem, then use:
 *   typedef DSN::T T;
 * within that problem area.
 */
namespace DSN
{
/// enum T contains all this lexer's tokens.
enum T
{
// these first few are negative special ones for syntax, and are
// inherited from DSNLEXER.
T_NONE  = DSN_NONE,
T_COMMENT   = DSN_COMMENT,
T_STRING_QUOTE  = DSN_STRING_QUOTE,
T_QUOTE_DEF = DSN_QUOTE_DEF,
T_DASH  = DSN_DASH,
T_SYMBOL= DSN_SYMBOL,
T_NUMBER= DSN_NUMBER,
T_RIGHT = DSN_RIGHT,// right bracket: ')'
T_LEFT  = DSN_LEFT, // left bracket:  '('
T_STRING= DSN_STRING,   // a quoted string, stripped of the quotes
T_EOF   = DSN_EOF,  // special case for end of file

T_back,
T_base_design,
T_bbv_ctr2ctr,
T_bend_keepout,
T_bond,
T_both,
T_bottom,
T_bottom_layer_sel,
T_boundary,
T_brickpat,
T_bundle,
T_bus,
T_bypass,
T_capacitance_resolution,
T_capacitor,
T_case_sensitive,
T_cct1,
T_cct1a,
T_center_center,
T_checking_trim_by_pin,
T_circ,
T_circle,
T_circuit,
T_class,
T_class_class,
T_classes,
T_clear,
T_clearance,
T_cluster,
T_cm,
T_color,
T_colors,
T_comment,
T_comp,
T_comp_edge_center,
T_comp_order,
T_component,
T_composite,
T_conductance_resolution,
T_conductor,
T_conflict,
T_connect,
T_constant,
T_contact,
T_control,
T_corner,
T_corners,
T_cost,
T_created_time,
T_cross,
T_crosstalk_model,
T_current_resolution,
T_deleted,
T_deleted_keepout,
T_delta,
T_diagonal,
T_direction,
T_directory,
T_discrete,
T_effective_via_length,
T_elongate_keepout,
T_exclude,
T_expose,
T_extra_image_directory,
T_family,
T_family_family,
T_family_family_spacing,
T_fanout,
T_farad,
T_file,
  

Re: [Kicad-developers] Proposed roadmap changes

[Jon Evans]

I believe embedded symbols is part of the file format / library format
change heading.

Back-annotation support in general is under the heading of "Pin and Part
Swapping" in the roadmap, and it's a good idea to include re-annotating
components as part of that.

On Mon, Mar 5, 2018 at 1:11 PM, Andy Peters  wrote:

>
>
> On Mar 5, 2018, at 10:57 AM, Jon Evans  wrote:
>
> Hi all,
>
> Since my day job involves a lot of engineering planning/timelines/etc,
> I've had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
>
> I am using Google drive because that's what is easiest for me to play
> with; I'm happy to send patches against the official roadmaps if get some
> buy-in for this.
>
> Feel free to comment (either directly on the doc or by email) with
> thoughts on this.
>
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF
> 7ooTtcT_HU86kw/edit#
>
> Basically what I am proposing is to put most of the energy into Eeschema
> for 6.0, with changes to other parts of the software basically being
> "whatever people have time left over for".  Everything else has been bumped
> to 7.0
>
>
> I’m not sure where it fits into the roadmap, but the main EESchema feature
> I’d like to see implemented is the embedding of schematic symbols into the
> schematic sheet, in the same way that footprints are part of the kicad_pcb
> file.
>
> Also the whole idea of renumbering the reference designators in a layout
> to be geographical, and then backannotating the designators to the
> schematic. (A guy can dream ..)
> -a
>
>
> ___
> 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] Proposed roadmap changes

[Andy Peters]

> On Mar 5, 2018, at 10:57 AM, Jon Evans  wrote:
> 
> Hi all,
> 
> Since my day job involves a lot of engineering planning/timelines/etc, I've 
> had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
> 
> I am using Google drive because that's what is easiest for me to play with; 
> I'm happy to send patches against the official roadmaps if get some buy-in 
> for this.
> 
> Feel free to comment (either directly on the doc or by email) with thoughts 
> on this.
> 
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
>  
> 
> 
> Basically what I am proposing is to put most of the energy into Eeschema for 
> 6.0, with changes to other parts of the software basically being "whatever 
> people have time left over for".  Everything else has been bumped to 7.0

I’m not sure where it fits into the roadmap, but the main EESchema feature I’d 
like to see implemented is the embedding of schematic symbols into the 
schematic sheet, in the same way that footprints are part of the kicad_pcb file.

Also the whole idea of renumbering the reference designators in a layout to be 
geographical, and then backannotating the designators to the schematic. (A guy 
can dream ..)
-a

___
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] [fun feature request] Create PCB from schematic with one click :)

[Andy Peters]

> On Mar 5, 2018, at 10:49 AM, Wayne Stambaugh  wrote:
> 
> I was thinking one level of abstraction higher where I just input my
> design requirements and it spits out a schematic, full simulation to
> match the design requirements, and a completed board layout.  That would
> make my job a *lot* easier. ;)

Maybe it can do my FPGA design for me, and also write firmware for the ARM 
processor too! Why am I doing all of this hard work when I could be drinking 
coffee and reading the New York Times?

> All kidding aside, I was told by a very highly skilled board designer
> not to waste our time with auto-routers because no one actually uses
> them except for the simplest designs with lots of free board space and
> few or no routing restrictions.  This is someone who uses Altium in his
> day job and has laid out far more boards than I have.  

At the previous day job, we did VME and CompactPCI single-board computers, and 
the layout people took advantage of full-up Specctra autorouting. The designs 
had a lot of wide parallel buses and suchlike which could be autorouted, but 
there was still plenty of stuff on those boards which needed to be routed 
manually. And setting up constraints for the autorouter was still a couple of 
days work.

At the current job everything is smaller. Each product has multiple boards that 
need to connect correctly. Boards are mixed signal, they have power supply 
parts, there are connectors that poke through the enclosure, etc etc etc and 
suffice it to say we never autoroute. Assisted routing, like the Kicad 
push-and-shove, and Altium’s “bus routing” (a feature I’d like to see in Kicad, 
for sure!) goes a long way.


> I'm guessing auto-routers appeal to hobbyists rather than professionals. 

How many questions on forums do you see from hobbyists asking about how to 
autoroute, or wondering if the results from the autorouter are good?

-a
___
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] [fun feature request] Create PCB from schematic with one click :)

[Wayne Stambaugh]

One thing that may be of more interest to board designers is an
automatic footprint placement algorithm that minimizes the number of air
wire crossings.  Not so much to place the footprints but to orient them.
 A few years ago someone proposed using a chemical reaction stability
algorithm where the number of air wire crossings were used to determine
the heat between neighboring footprints.  There was even an open source
library that was generic enough to use for our purposes.  I'm not sure
if this message is on the launchpad mailing list or if this went back to
the sourceforge mailing list.

On 3/5/2018 12:56 PM, Jon Evans wrote:
> Yes, I have also heard that from my hard-core board design colleagues. 
> No one uses auto-routers anymore, they instead use interactive routers
> that have gotten very good lately.
> 
> We should continue to push the KiCad interactive (PNS) router to add
> capabilities (multi-net routing, via array styles, automatic fan-out,
> automatic clean-up, automatic completion, etc).
> Then, a feature such as "auto-route the last bit of this track because
> the user nudged the component over slightly or rotated it 90 degrees"
> sort of come for free.
> 
> -Jon
> 
> On Mon, Mar 5, 2018 at 12:49 PM, Wayne Stambaugh  > wrote:
> 
> I was thinking one level of abstraction higher where I just input my
> design requirements and it spits out a schematic, full simulation to
> match the design requirements, and a completed board layout.  That would
> make my job a *lot* easier. ;)
> 
> All kidding aside, I was told by a very highly skilled board designer
> not to waste our time with auto-routers because no one actually uses
> them except for the simplest designs with lots of free board space and
> few or no routing restrictions.  This is someone who uses Altium in his
> day job and has laid out far more boards than I have.  I'm guessing
> auto-routers appeal to hobbyists rather than professionals.  I've never
> seen an auto-router come any where close to how I would route a board so
> I never use them.  There are far more useful features to add to KiCad
> than auto-routing.  If we ever get to the point we are sitting around
> twiddling our thumbs, then we should work on an auto-router.
> 
> On 3/5/2018 12:16 PM, Jon Evans wrote:
> > Actually the second point in that post is a gem (rerouting of tracks
> > when you move a component)  It is a feature of some super-high end
> > packages (Xpedition, Allegro I think) but missing from lots of paid
> > tools (Altium, Zuken, etc).
> >
> > It's on my list of things I want to add to KiCad at some point (if
> > someone else doesn't get to it first), but it's also one of the most
> > complex problems to solve on that list...
> >
> > -Jon
> >
> > On Mon, Mar 5, 2018 at 12:09 PM, Tomasz Wlostowski
> > 
>  >> wrote:
> >
> >     Ladies and gentlemen, there's a lot of work for us ahead!
> >
> >     
> https://www.reddit.com/r/AskElectronics/comments/815fz2/what_eda_is_really_the_best_out_there_for_macos/
> 
> 
> >     
>  
> >
> >
> >     Cheers,
> >     Tom
> >
> >     ___
> >     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 : 

[Kicad-developers] Proposed roadmap changes

[Jon Evans]

Hi all,

Since my day job involves a lot of engineering planning/timelines/etc, I've
had this rolling around in my head...
I started brainstorming some proposed changes to the roadmaps.

I am using Google drive because that's what is easiest for me to play with;
I'm happy to send patches against the official roadmaps if get some buy-in
for this.

Feel free to comment (either directly on the doc or by email) with thoughts
on this.

https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#

Basically what I am proposing is to put most of the energy into Eeschema
for 6.0, with changes to other parts of the software basically being
"whatever people have time left over for".  Everything else has been bumped
to 7.0

-Jon
___
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] Rework footprint selection filtering to improve behavior

[Andrzej Wolski]

Hi Jon,

another small issue: if only enabled layer is In1.Cu, THT pads are 
visible, but footprint cannot be selected.

I think that breaks your visible=selectable rule.

Fragment of code from D_PAD::ViewGetLOD that may help here:

    if( ( GetAttribute() == PAD_ATTRIB_STANDARD || GetAttribute() == 
PAD_ATTRIB_HOLE_NOT_PLATED )

 && !aView->IsLayerVisible( LAYER_PADS_TH ) )
    return HIDE;

Cheers,
Andrzej

W dniu 2018-03-03 o 23:39, Jon Evans pisze:

Hey Andy, Andrzej,

Updated patch attached, let me know if this behavior makes more sense

Best,
Jon

On Fri, Mar 2, 2018 at 3:29 PM, Andy Peters > wrote:





On Mar 2, 2018, at 10:28 AM, Andrzej Wolski
> wrote:

Jon,

I probably didn't express myself clearly. What I mean is a
situation when *only* enabled layer if F.Paste and then you
disable "Pads Front". Now nothing is visible on the board, but
footprints are still selectable.

In other words, when no single item belonging to footprint is
visible, footprints should not be selectable.

Do you still disagree with me?


I agree with Andrzej. This is the crux of my bug report.

But I understand what Jon is saying, and it doesn’t contradict. If
the _pads_ (for example) are invisible, but say the silkscreen is
visible, then the footprint _should_ be selectable.

That, I think, is the difference between layer visibility and item
visibility. All of the layers could be visible, but if I disable
Footprints Front, then everything associated with all top-layer
footprints vanishes and none of the footprints can be selected.
That’s the proper operation.

The converse of that is if I leave Footprints Front visibility
enabled, and then I go and disable all of the layers associated
with front footprints, like I did in my bug report case (disable
all layers except Cmts.User), I am still able to select all of the
invisible footprints. That’s not correct (IMHO).

-a




Andrzej

W dniu 2018-03-02 o 15:42, Jon Evans pisze:

Hi Andrzej,

This was my intention, which is why I said I was prepared for
other people to have other opinions :-)

I think that you should still be able to select footprints even
if the "front pads" is hidden from layers like the paste layer,
*unless* you are in high contrast mode.

-Jon

On Fri, Mar 2, 2018 at 3:53 AM, Andrzej Wolski
> wrote:

I've tried this patch, and there is a small issue: if you
have only eg front paste layer enabled and front pads are
hidden, footprint is still selectable.

Andrzej


W dniu 2018-02-27 o 04:11, Jon Evans pisze:

This patch changes the selection logic for footprints to
fix a reported issue[1] and to make the behavior more
logical to me.

I know that correct selection behavior is something of a
personal preference, so I'm ready to be flamed :-)

The new behavior:

A footprint may be selected if:
1) The corresponding "Footprints" switch is on in the Items
tab, AND
2) One or more of the layers that the footprint draws on is
visible

This means that if all of the layers are turned off,
footprints are not selectable (fixes the bug), but it also
means that now footprints can be selected if any draw
layers are visible (for example, if you have only F.Mask
enabled, you can select a footprint that has solder mask
and is on the front layer).

Before anyone complains, this is only if high-contrast mode
is turned OFF.  When it is on, you can still only select
items that *only* exist on that layer (to make moving
silkscreen around easier, for example)

Even though this adds some more for-loops to selection
filtering, I have not noticed any performance hits on some
selection of large boards that I tested. More testing is
welcome.

[1] https://bugs.launchpad.net/kicad/+bug/1751960


-Jon




___
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   

Re: [Kicad-developers] [fun feature request] Create PCB from schematic with one click :)

[Jon Evans]

Yes, I have also heard that from my hard-core board design colleagues.  No
one uses auto-routers anymore, they instead use interactive routers that
have gotten very good lately.

We should continue to push the KiCad interactive (PNS) router to add
capabilities (multi-net routing, via array styles, automatic fan-out,
automatic clean-up, automatic completion, etc).
Then, a feature such as "auto-route the last bit of this track because the
user nudged the component over slightly or rotated it 90 degrees" sort of
come for free.

-Jon

On Mon, Mar 5, 2018 at 12:49 PM, Wayne Stambaugh 
wrote:

> I was thinking one level of abstraction higher where I just input my
> design requirements and it spits out a schematic, full simulation to
> match the design requirements, and a completed board layout.  That would
> make my job a *lot* easier. ;)
>
> All kidding aside, I was told by a very highly skilled board designer
> not to waste our time with auto-routers because no one actually uses
> them except for the simplest designs with lots of free board space and
> few or no routing restrictions.  This is someone who uses Altium in his
> day job and has laid out far more boards than I have.  I'm guessing
> auto-routers appeal to hobbyists rather than professionals.  I've never
> seen an auto-router come any where close to how I would route a board so
> I never use them.  There are far more useful features to add to KiCad
> than auto-routing.  If we ever get to the point we are sitting around
> twiddling our thumbs, then we should work on an auto-router.
>
> On 3/5/2018 12:16 PM, Jon Evans wrote:
> > Actually the second point in that post is a gem (rerouting of tracks
> > when you move a component)  It is a feature of some super-high end
> > packages (Xpedition, Allegro I think) but missing from lots of paid
> > tools (Altium, Zuken, etc).
> >
> > It's on my list of things I want to add to KiCad at some point (if
> > someone else doesn't get to it first), but it's also one of the most
> > complex problems to solve on that list...
> >
> > -Jon
> >
> > On Mon, Mar 5, 2018 at 12:09 PM, Tomasz Wlostowski
> > > wrote:
> >
> > Ladies and gentlemen, there's a lot of work for us ahead!
> >
> > https://www.reddit.com/r/AskElectronics/comments/
> 815fz2/what_eda_is_really_the_best_out_there_for_macos/
> >  815fz2/what_eda_is_really_the_best_out_there_for_macos/>
> >
> > Cheers,
> > Tom
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> > 
> >
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Rework footprint selection filtering to improve behavior

[Wayne Stambaugh]

I like this change!  I've never liked the fact that objects on invisible
layers get selected.  Has anyone else had a chance to test this?  If
there are no objections, I recommend that this patch get merged for rc2.

On 2/26/2018 10:11 PM, Jon Evans wrote:
> This patch changes the selection logic for footprints to fix a reported
> issue[1] and to make the behavior more logical to me.
> 
> I know that correct selection behavior is something of a personal
> preference, so I'm ready to be flamed :-)
> 
> The new behavior:
> 
> A footprint may be selected if:
> 1) The corresponding "Footprints" switch is on in the Items tab, AND
> 2) One or more of the layers that the footprint draws on is visible
> 
> This means that if all of the layers are turned off, footprints are not
> selectable (fixes the bug), but it also means that now footprints can be
> selected if any draw layers are visible (for example, if you have only
> F.Mask enabled, you can select a footprint that has solder mask and is
> on the front layer).
> 
> Before anyone complains, this is only if high-contrast mode is turned
> OFF.  When it is on, you can still only select items that *only* exist
> on that layer (to make moving silkscreen around easier, for example)
> 
> Even though this adds some more for-loops to selection filtering, I have
> not noticed any performance hits on some selection of large boards that
> I tested.  More testing is welcome.
> 
> [1] https://bugs.launchpad.net/kicad/+bug/1751960
> 
> -Jon
> 
> 
> ___
> 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] [fun feature request] Create PCB from schematic with one click :)

[Wayne Stambaugh]

I was thinking one level of abstraction higher where I just input my
design requirements and it spits out a schematic, full simulation to
match the design requirements, and a completed board layout.  That would
make my job a *lot* easier. ;)

All kidding aside, I was told by a very highly skilled board designer
not to waste our time with auto-routers because no one actually uses
them except for the simplest designs with lots of free board space and
few or no routing restrictions.  This is someone who uses Altium in his
day job and has laid out far more boards than I have.  I'm guessing
auto-routers appeal to hobbyists rather than professionals.  I've never
seen an auto-router come any where close to how I would route a board so
I never use them.  There are far more useful features to add to KiCad
than auto-routing.  If we ever get to the point we are sitting around
twiddling our thumbs, then we should work on an auto-router.

On 3/5/2018 12:16 PM, Jon Evans wrote:
> Actually the second point in that post is a gem (rerouting of tracks
> when you move a component)  It is a feature of some super-high end
> packages (Xpedition, Allegro I think) but missing from lots of paid
> tools (Altium, Zuken, etc).
> 
> It's on my list of things I want to add to KiCad at some point (if
> someone else doesn't get to it first), but it's also one of the most
> complex problems to solve on that list...
> 
> -Jon
> 
> On Mon, Mar 5, 2018 at 12:09 PM, Tomasz Wlostowski
> > wrote:
> 
> Ladies and gentlemen, there's a lot of work for us ahead!
> 
> 
> https://www.reddit.com/r/AskElectronics/comments/815fz2/what_eda_is_really_the_best_out_there_for_macos/
> 
> 
> 
> Cheers,
> Tom
> 
> ___
> 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] [fun feature request] Create PCB from schematic with one click :)

[Seth Hillbrand]

Ha!

Sounds like a job for Alpha Zero to me.

-S

2018-03-05 9:09 GMT-08:00 Tomasz Wlostowski :

> Ladies and gentlemen, there's a lot of work for us ahead!
>
> https://www.reddit.com/r/AskElectronics/comments/
> 815fz2/what_eda_is_really_the_best_out_there_for_macos/
>
> Cheers,
> Tom
>
> ___
> 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] [fun feature request] Create PCB from schematic with one click :)

[Jon Evans]

Actually the second point in that post is a gem (rerouting of tracks when
you move a component)  It is a feature of some super-high end packages
(Xpedition, Allegro I think) but missing from lots of paid tools (Altium,
Zuken, etc).

It's on my list of things I want to add to KiCad at some point (if someone
else doesn't get to it first), but it's also one of the most complex
problems to solve on that list...

-Jon

On Mon, Mar 5, 2018 at 12:09 PM, Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:

> Ladies and gentlemen, there's a lot of work for us ahead!
>
> https://www.reddit.com/r/AskElectronics/comments/
> 815fz2/what_eda_is_really_the_best_out_there_for_macos/
>
> Cheers,
> Tom
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [fun feature request] Create PCB from schematic with one click :)

[Tomasz Wlostowski]

Ladies and gentlemen, there's a lot of work for us ahead!

https://www.reddit.com/r/AskElectronics/comments/815fz2/what_eda_is_really_the_best_out_there_for_macos/

Cheers,
Tom

___
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] Jumpy canvas on other platforms?

[Jeff Young]

Thanks, everyone.  I think it’s more sensitive to a trackpad than mouse, but I 
merged a fix yesterday anyway.

> On 5 Mar 2018, at 16:41, Wayne Stambaugh  wrote:
> 
> I see it now.  I was moving the cursor too fast.  You have to move it
> very slowly to see the issue.  Hmm, never noticed that before.
> 
> On 3/5/2018 11:39 AM, Andrey Kuznetsov wrote:
>> I notice the jerkiness on WIndows!
>> 
>> When you start panning, very slowly, by a little bit, there is a period
>> when it looks like the view window tries to center itself, so it jumps
>> back and forth between where it used to be and where the mouse is going,
>> until it's far enough and it snaps out of it and at the same time the
>> scroll bars appear.
>> 
>> On Mon, Mar 5, 2018 at 5:54 AM, Wayne Stambaugh > > wrote:
>> 
>>I'm not seeing this on my windows 7 builds.  The panning after zoom
>>extents works smoothly.  I even tried resizing the main frame several
>>times but I still didn't notice it.
>> 
>>On 3/4/2018 5:00 PM, Jeff Young wrote:
>>> There is actually code in there to make them always on, but there seems
>>> to be something defeating it.  I’ll poke around some more.
>>> 
 On 4 Mar 2018, at 21:57, Jon Evans 
 >> wrote:
 
 Ah yes, I can reproduce that on Windows too.  I guess I didn't notice
 before because generally the scrollbars are visible (I noticed that
 "zoom extents" doesnt *always* result in the scrollbars being hidden,
 for whatever reason)
 Any reason why we hide the scrollbars?  Seems like it might be simpler
 to just always show them...
 -Jon
 
 On Sun, Mar 4, 2018 at 4:52 PM, Bernhard Stegmaier
 
>>>>
>>wrote:
 
  Do a “fit to window” and then pan left/right… I use the touchpad.
  After “fit to window” there is no scrollbar.
  When the scrollbar comes back due to panning, I see almost always
  a small shift of the whole view down and then up again.
  Sometimes, but not always if you just pan left/right it will make
  this small jump downwards every time you cross center, just as if
  it would “snap" to middle position.
 
 
>  On 4. Mar 2018, at 21:25, Jon Evans  
>  >> wrote:
> 
>  Maybe I don't really understand what you mean, but I can't see
>  any jumpiness on Linux when panning around (with middle-mouse drag).
>  What do you mean by "it automatically fits to window, so there's
>  not really any place to go"?  It does not do any kind of
>  auto-fitting except for the zoom-extents on file load on Linux,
>  and I don't have my Mac machine handy to compare.
> 
>  On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young  
>  >> wrote:
> 
>  If I open an eeschema file on OSX and pan around (it
>  automatically fits to window, so there’s not really any place
>  to go), the screen jumps around a bit.  True also on other
>  platforms, or Mac-specific?
> 
>  Thanks,
>  Jeff.
>  ___
>  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
>>
>  

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[Wayne Stambaugh]

hauptmech,

I tested this on windows and it doesn't seem to break anything that I
can see so I merged it.  Thank you for your contribution to KiCad.

Cheers,

Wayne

On 2/25/2018 8:49 PM, hauptmech wrote:
> 
> Attached
> 
> On 26/02/18 11:15, Wayne Stambaugh wrote:
>> hauptmech,
>>
>> Would you please attach this change as a committed patch when you get
>> a chance?  I want to test this on windows and linux and maybe we can
>> get one of our macos devs to test it there as well.  I would like to
>> work out any packaging issues as soon as possible to give our package
>> devs as much time as possible to work out any issue for the stable
>> release.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 02/24/2018 08:49 PM, hauptmech wrote:
>>> I don't have enough understanding of all the platforms to suggest a
>>> full patch. However the following works for me on linux (two targets,
>>> but shared object files so there should be no significant change in
>>> compile time)
> 
> 
> 
> ___
> 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] Jumpy canvas on other platforms?

[Wayne Stambaugh]

I see it now.  I was moving the cursor too fast.  You have to move it
very slowly to see the issue.  Hmm, never noticed that before.

On 3/5/2018 11:39 AM, Andrey Kuznetsov wrote:
> I notice the jerkiness on WIndows!
> 
> When you start panning, very slowly, by a little bit, there is a period
> when it looks like the view window tries to center itself, so it jumps
> back and forth between where it used to be and where the mouse is going,
> until it's far enough and it snaps out of it and at the same time the
> scroll bars appear.
> 
> On Mon, Mar 5, 2018 at 5:54 AM, Wayne Stambaugh  > wrote:
> 
> I'm not seeing this on my windows 7 builds.  The panning after zoom
> extents works smoothly.  I even tried resizing the main frame several
> times but I still didn't notice it.
> 
> On 3/4/2018 5:00 PM, Jeff Young wrote:
> > There is actually code in there to make them always on, but there seems
> > to be something defeating it.  I’ll poke around some more.
> >
> >> On 4 Mar 2018, at 21:57, Jon Evans  
> >> >> wrote:
> >>
> >> Ah yes, I can reproduce that on Windows too.  I guess I didn't notice
> >> before because generally the scrollbars are visible (I noticed that
> >> "zoom extents" doesnt *always* result in the scrollbars being hidden,
> >> for whatever reason)
> >> Any reason why we hide the scrollbars?  Seems like it might be simpler
> >> to just always show them...
> >> -Jon
> >>
> >> On Sun, Mar 4, 2018 at 4:52 PM, Bernhard Stegmaier
> >> 
> >>
> wrote:
> >>
> >>     Do a “fit to window” and then pan left/right… I use the touchpad.
> >>     After “fit to window” there is no scrollbar.
> >>     When the scrollbar comes back due to panning, I see almost always
> >>     a small shift of the whole view down and then up again.
> >>     Sometimes, but not always if you just pan left/right it will make
> >>     this small jump downwards every time you cross center, just as if
> >>     it would “snap" to middle position.
> >>
> >>
> >>>     On 4. Mar 2018, at 21:25, Jon Evans  
> >>>     >> wrote:
> >>>
> >>>     Maybe I don't really understand what you mean, but I can't see
> >>>     any jumpiness on Linux when panning around (with middle-mouse 
> drag).
> >>>     What do you mean by "it automatically fits to window, so there's
> >>>     not really any place to go"?  It does not do any kind of
> >>>     auto-fitting except for the zoom-extents on file load on Linux,
> >>>     and I don't have my Mac machine handy to compare.
> >>>
> >>>     On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young  
> >>>     >> wrote:
> >>>
> >>>         If I open an eeschema file on OSX and pan around (it
> >>>         automatically fits to window, so there’s not really any place
> >>>         to go), the screen jumps around a bit.  True also on other
> >>>         platforms, or Mac-specific?
> >>>
> >>>         Thanks,
> >>>         Jeff.
> >>>         ___
> >>>         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
> 
> >>>      

Re: [Kicad-developers] Jumpy canvas on other platforms?

[Andrey Kuznetsov]

I notice the jerkiness on WIndows!

When you start panning, very slowly, by a little bit, there is a period
when it looks like the view window tries to center itself, so it jumps back
and forth between where it used to be and where the mouse is going, until
it's far enough and it snaps out of it and at the same time the scroll bars
appear.

On Mon, Mar 5, 2018 at 5:54 AM, Wayne Stambaugh 
wrote:

> I'm not seeing this on my windows 7 builds.  The panning after zoom
> extents works smoothly.  I even tried resizing the main frame several
> times but I still didn't notice it.
>
> On 3/4/2018 5:00 PM, Jeff Young wrote:
> > There is actually code in there to make them always on, but there seems
> > to be something defeating it.  I’ll poke around some more.
> >
> >> On 4 Mar 2018, at 21:57, Jon Evans  >> > wrote:
> >>
> >> Ah yes, I can reproduce that on Windows too.  I guess I didn't notice
> >> before because generally the scrollbars are visible (I noticed that
> >> "zoom extents" doesnt *always* result in the scrollbars being hidden,
> >> for whatever reason)
> >> Any reason why we hide the scrollbars?  Seems like it might be simpler
> >> to just always show them...
> >> -Jon
> >>
> >> On Sun, Mar 4, 2018 at 4:52 PM, Bernhard Stegmaier
> >> > wrote:
> >>
> >> Do a “fit to window” and then pan left/right… I use the touchpad.
> >> After “fit to window” there is no scrollbar.
> >> When the scrollbar comes back due to panning, I see almost always
> >> a small shift of the whole view down and then up again.
> >> Sometimes, but not always if you just pan left/right it will make
> >> this small jump downwards every time you cross center, just as if
> >> it would “snap" to middle position.
> >>
> >>
> >>> On 4. Mar 2018, at 21:25, Jon Evans  >>> > wrote:
> >>>
> >>> Maybe I don't really understand what you mean, but I can't see
> >>> any jumpiness on Linux when panning around (with middle-mouse
> drag).
> >>> What do you mean by "it automatically fits to window, so there's
> >>> not really any place to go"?  It does not do any kind of
> >>> auto-fitting except for the zoom-extents on file load on Linux,
> >>> and I don't have my Mac machine handy to compare.
> >>>
> >>> On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young  >>> > wrote:
> >>>
> >>> If I open an eeschema file on OSX and pan around (it
> >>> automatically fits to window, so there’s not really any place
> >>> to go), the screen jumps around a bit.  True also on other
> >>> platforms, or Mac-specific?
> >>>
> >>> Thanks,
> >>> Jeff.
> >>> ___
> >>> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Mac HighDPI performance

[Wayne Stambaugh]

The problem with this branching method is that virtually no one else but
the developer who is working in a feature branch actually tests the code
in the feature branch.  If you are lucky, one other person developer
will test it.  That is why I don't really like this model.  Our
development branch gets a high amount of user testing since it's readily
available in nightly builds.  This results in bugs being fixed quickly
and helps keep the development branch reasonably stable.

On 3/5/2018 10:23 AM, Jon Evans wrote:
> I think you're describing something similar to
> this: http://nvie.com/posts/a-successful-git-branching-model/
> which I think can work pretty well.  It does require more
> work/dedication than the model KiCad uses today.
> 
> On Mon, Mar 5, 2018 at 10:19 AM, José Ignacio  > wrote:
> 
> Once the point release is done, no more bugfix releases are
> necessary on the previous one, that should reduce the effort of
> backporting fixes to a codebase that was branched way back. As it is
> right now, fixing a bug that affects both stable and dev 1 year in
> the future would mean writing a patch for 2 pretty different looking
> codebases (and the bug might not even exist in dev because the code
> was rewritten), so either the effort is (almost) duplicated or the
> bug goes unfixed.
> 
> One way this could work is to, instead of keeping a stale branch
> with the stable release where fixes need to be
> backported/cherry-picked to, just keep big destabilizing changes
> away from Master. And make all stable releases be just a tag in
> Master, with a x.x-bugfix branch existing only if a bug fix had to
> be backported before the next point release was ready, big features
> that can leave kicad unstable or incompatible can go into a staging
> branch that gets pulled into master when the next point release
> merge window opens. Those disruptions almost never happened during
> 5.0 development, most of the time devs have been exceptionally good
> at keeping kicad stable and compatible throughout the dev process,
> except where it couldn't be avoided (like the big sym-lib-table change).
> 
> On Mon, Mar 5, 2018 at 8:52 AM, Wayne Stambaugh
> > wrote:
> 
> There is no formal process.  It's primarily based on discussion
> on the
> mailing list and me making the final decisions.  The road maps
> live in
> the kicad source repo in the /Documentation/development/
> folder.  They
> definitely need updated.  I just haven't gotten around to
> updating them.
>  I was going to do that sometime after the v5 release.
> 
> As for a v5.1, we have not done point releases in the past due
> to lack
> of manpower.  I have done most of the stable branch maintenance
> and it's
> more work than you would think and I just don't have the time to add
> point releases to my list of responsibilities.  If someone
> proposes a
> reasonable way to do this without tying up a lot of developer
> time then
> I'm  not opposed to it.  Please keep in mind the long term
> ramifications
> of potentially maintaining multiple stable branches when developers
> leave the project.  If we could always depend on a given level of
> developer time, this probably wouldn't be that big of an issue
> but we
> cannot depend on any guaranteed level of manpower.  Maybe in the
> future
> that is a luxury we will have.
> 
> Wayne
> 
> On 3/5/2018 9:36 AM, Jon Evans wrote:
> > Do we have a process or workflow for proposing changes to the 
> roadmap? 
> > A number of the things from the V5 roadmap didn't happen, so it 
> might
> > make sense to move some things around to V6 (and possibly a V5.1) 
> roadmaps
> >
> > -Jon
> >
> > On Mon, Mar 5, 2018 at 9:12 AM, Wayne Stambaugh 
> 
> > >> wrote:
> >
> >     Jon,
> >
> >     The v6 road map is here:
> >
> >     http://docs.kicad-pcb.org/doxygen/v6_road_map.html
> 
> >      >
> >
> >     I was planning on working on the schematic object but I 
> wouldn't be
> >     offended if you want to implement it.  If you do decide to work 
> on this,
> >     please keep me in the loop.  I have some things that I 
> definitely want
> >     implemented as part of this object most of which 

Re: [Kicad-developers] Fabrication Outputs and Plot

[Wayne Stambaugh]

Diego,

I merged your patch.  Thank you for your contribution to KiCad.

Cheers,

Wayne

On 2/25/2018 3:17 PM, Diego Herranz wrote:
> Thanks for your replies. I think there's a consensus that this needs
> improving and restructuring, but given your emails, it sounds like a big
> task :)
> 
> In the meantime, would you accept the attached patch to change the order
> in which "Fabrication Outputs" is listed in the menu?
> 
> Before:
> Fabrication Outputs
> Import
> Export
> 
> After:
> Import
> Export
> Fabrication Outputs
> 
> 
> I think that "Fabrication Outputs" is conceptually very similar to
> "Export" and it belongs next to it better than having "Import" in
> between them.
> 
> Thanks,
> Diego
> 
> 
> 
> On Sat, Feb 24, 2018 at 9:01 PM, Wayne Stambaugh  > wrote:
> 
> I'm open to any solution that improves the current situation.  This
> solution seems reasonable as well.  I also just noticed that wx
> 3.1.1 was just released and it looks like there have been a lot of
> fixes the various device contexts so some of the work may have
> already been done for us.
> 
> On 02/24/2018 03:31 PM, Jon Evans wrote:
> 
> I thought the idea was to write a backend for GAL that could
> render onto a wxDC for printing?  It seems wise to use the
> wxWidgets printing API rather than bypassing it; so we just need
> to be able to render onto a DC (without using the old XOR tricks
> from the legacy drawing code)
> 
> On Sat, Feb 24, 2018 at 3:26 PM, Jeff Young    >> wrote:
> 
>     On the other hand, if we don’t then we have to keep carrying
> around
>     a boat-load of Legacy rendering code (because we use that
> for printing).
> 
>      > On 24 Feb 2018, at 20:16, Wayne Stambaugh
> 
>     >>
> wrote:
>      >
>      > There is no plan yet but it has been discussed.  The only
>     downside is that we will have to write our own print handling on
>     windows and I'm guessing macos.  That's one of the reasons
> no one
>     has signed up yet because it will be a large undertaking.
>      >
>      > On 02/24/2018 02:02 PM, Jon Evans wrote:
>      >> Yes I think that's the plan, just needs someone to sign
> up to
>     write it :)
>      >> On Sat, Feb 24, 2018, 14:00 Andrzej Wolski
>     
> >
>             wrote:
>      >>    Cairo have PDF, SVG and Postscript support. I was once
>     wondering if
>      >>    GAL/Cairo could be used for printing.
>      >>    Andrzej
>      >>    W dniu 2018-02-24 o 19:24, Jon Evans pisze:
>      >>>    Yeah, there (at least) three different dialogs that
> all present
>      >>>    similar things (i.e. a list of layers to include,
> settings,
>     etc):
>      >>>
>      >>>    Export->SVG
>      >>>    Print
>      >>>    Plot
>      >>>
>      >>>    The Print code for Export->SVG seems to just use the
> same SVG
>      >>>    plotter, so maybe it's just mostly GUI cleanup that
> is needed.
>      >>>
>      >>>    The main Print code does need an overhaul to use
> something other
>      >>>    than wxDC for graphics generation (and perhaps
> adding some more
>      >>>    features to PDF export)
>      >>>
>      >>>    -Jon
>      >>>
>      >>>    On Sat, Feb 24, 2018 at 1:16 PM, Jeff Young
> 
>     >
>      >>>    
>       >>>
>      >>>        Plot SVG and Export SVG are different.  The
> former goes
>      >>>        through the Plot code while the later goes
> through the Print
>      >>>        code.
>      >>>
>      >>>        Do we need both?  I haven’t a clue.
>      >>>
>      >>>        It would be nice to clean this stuff up, if
> there is in
>     fact a
>      >>>        clean way to present it.
>      >>>
>      >>>      

Re: [Kicad-developers] [PATCH] macOS CFBundleName

[Wayne Stambaugh]

Thanks!  Sorry for the noise.

On 3/5/2018 10:18 AM, Jeff Young wrote:
> He he… reading our mail out of order, are we? ;)
> 
> (Already reviewed.  Already merged.)
> 
> Cheers,
> Jeff.
> 
> 
>> On 5 Mar 2018, at 14:33, Wayne Stambaugh  wrote:
>>
>> This patch looks fine to me but would one of our macos devs please take
>> a look at this to make sure it is correct.
>>
>> As for the symlink names, I don't know that the capitalization is all
>> that important unless it's a macos-centric thing.  I don't have an
>> opinion on this one way or the other.
>>
>> On 3/4/2018 5:37 PM, Michael Kavanagh wrote:
>>> The attached trivial patch fixes the app menubar items to match the
>>> window titles, as well as when you "Quicklook" an executable, in
>>> activity monitor and probably some other places as well.
>>>
>>> As a side is there any reason why the bundle/symlink names aren't
>>> capitalised/contain underscores instead of spaces? See attached
>>> screenshot.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] [PATCH] macOS CFBundleName

[Jeff Young]

He he… reading our mail out of order, are we? ;)

(Already reviewed.  Already merged.)

Cheers,
Jeff.


> On 5 Mar 2018, at 14:33, Wayne Stambaugh  wrote:
> 
> This patch looks fine to me but would one of our macos devs please take
> a look at this to make sure it is correct.
> 
> As for the symlink names, I don't know that the capitalization is all
> that important unless it's a macos-centric thing.  I don't have an
> opinion on this one way or the other.
> 
> On 3/4/2018 5:37 PM, Michael Kavanagh wrote:
>> The attached trivial patch fixes the app menubar items to match the
>> window titles, as well as when you "Quicklook" an executable, in
>> activity monitor and probably some other places as well.
>> 
>> As a side is there any reason why the bundle/symlink names aren't
>> capitalised/contain underscores instead of spaces? See attached
>> screenshot.
>> 
>> Regards,
>> Michael
>> 
>> 
>> 
>> ___
>> 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] Settable clearances

[Wayne Stambaugh]

This happened last stable release.  Users wait to the last minute and
then make a request for a new feature.  If this would have been proposed
six months ago, it probably would be part of the v5 release.  The
feature itself is a good idea but it will have to be deferred to some
later version.  We really need to stay focused on the v5 release.  It's
too easy to give into every whim and just keep pushing back v5.  This
happened somewhat in v4 and it took a long time to get from feature
freeze to release so I'm trying to prevent that from happening again.
We are never going to win this fight.  There will always be people who
think we should push back a stable release for some new feature.

Wayne

On 3/5/2018 8:59 AM, Jon Evans wrote:
> I can certainly help check it.  I think Wayne would have to make a call
> as to whether or not it's too big a change to introduce now.
> 
> -Jon
> 
> On Mon, Mar 5, 2018 at 7:59 AM, hauptmech  > wrote:
> 
> While testing version 5 I realized that clearances are still not
> settable (like track width or via size) and my life is going to be
> miserable if I have to continue with my current work flow which is
> to change the default netclass clearance to the desired clearance
> constantly as I lay down different tracks which require different
> clearances even though they are part of the some net.
> 
> There is a previous thread detailing why netclass is not sufficient
> for all use cases. Search for netclass in the subject.
> 
> Anyway, I wrote most of a patch today (it's 1am in my timezone now)
> and expect to finish it tomorrow. I believe I have a solution which
> will be useful for those that need it and mostly invisible to those
> that don't. 
> 
> The question is whether there is a core developer willing to check,
> sign off, and help sell it for inclusion in 5. (I'm stuck using
> whatever the current stable version of kicad is when I'm working)
> 
> This is a huge pain point for me and I'm willing to negotiate a
> small bounty if that helps.
> 
> 
> 
> ___
> 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] Mac HighDPI performance

[Wayne Stambaugh]

There is no formal process.  It's primarily based on discussion on the
mailing list and me making the final decisions.  The road maps live in
the kicad source repo in the /Documentation/development/ folder.  They
definitely need updated.  I just haven't gotten around to updating them.
 I was going to do that sometime after the v5 release.

As for a v5.1, we have not done point releases in the past due to lack
of manpower.  I have done most of the stable branch maintenance and it's
more work than you would think and I just don't have the time to add
point releases to my list of responsibilities.  If someone proposes a
reasonable way to do this without tying up a lot of developer time then
I'm  not opposed to it.  Please keep in mind the long term ramifications
of potentially maintaining multiple stable branches when developers
leave the project.  If we could always depend on a given level of
developer time, this probably wouldn't be that big of an issue but we
cannot depend on any guaranteed level of manpower.  Maybe in the future
that is a luxury we will have.

Wayne

On 3/5/2018 9:36 AM, Jon Evans wrote:
> Do we have a process or workflow for proposing changes to the roadmap? 
> A number of the things from the V5 roadmap didn't happen, so it might
> make sense to move some things around to V6 (and possibly a V5.1) roadmaps
> 
> -Jon
> 
> On Mon, Mar 5, 2018 at 9:12 AM, Wayne Stambaugh  > wrote:
> 
> Jon,
> 
> The v6 road map is here:
> 
> http://docs.kicad-pcb.org/doxygen/v6_road_map.html
> 
> 
> I was planning on working on the schematic object but I wouldn't be
> offended if you want to implement it.  If you do decide to work on this,
> please keep me in the loop.  I have some things that I definitely want
> implemented as part of this object most of which you have probably
> already run into with your connectivity work.
> 
> Cheers,
> 
> Wayne
> 
> 
> On 3/4/2018 3:07 PM, Jon Evans wrote:
> > We should probably make some kind of road map if it doesn't exist
> > already, concerning the path to GAL for eeschema and who will be doing
> > what. For example, it might make sense to do the SCHEMATIC class
> > refactoring you were talking about before or in parallel with parts of
> > the porting effort.
> >
> > I'm up for working on this too, as soon as my connectivity / bus stuff
> > has landed. 
> >
> > -Jon
> >
> > On Sun, Mar 4, 2018, 14:46 Wayne Stambaugh  
> > >> wrote:
> >
> >     I agree.  If it's not an easy straight forward fix, I would prefer 
> to
> >     spend our precious manpower resources on the GAL port as well.  I 
> don't
> >     know when in the v6 cycle any of this will happen but I'm guessing 
> it
> >     will happen fairly early.  Tom or Orson, do either of you have any 
> idea
> >     when this will happen?
> >
> >     Wayne
> >
> >     On 03/04/2018 02:40 PM, Jon Evans wrote:
> >     > FWIW, I don't find the existing performance to be unusable, it's 
> just
> >     > not up to the standards of PcbNew/GAL.  I don't think it's worth 
> any
> >     > effort beyond easy fixes, we should put that energy into the GAL
> >     port. 
> >     >
> >     > -Jon
> >     >
> >     > On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier
> >     
> >
> >     > 
>  >     wrote:
> >     >
> >     >     I would judge it wrt eeschema GAL conversion.
> >     >     If that starts with v6, I don’t know if it is worth the 
> effort.
> >     >     If it is unsure when this will happen, it might be worth it.
> >     >
> >     >
> >     >>     On 4. Mar 2018, at 20:30, Wayne Stambaugh
> >     
> >
> >     >>     
>  >     wrote:
> >     >>
> >     >>     Ughh!  I don't have a good answer for this one.  My
> best guess is
> >     >>     to fix
> >     >>     the wx macos code first and see what performance issues are
> >     left.  The
> >     >>     problem with messing with any of this is that if you break
> >     >>     something it
> >     >>     will break all of the legacy canvas rendering not just the
> >     schematic
> >     >>     editor.  I 

Re: [Kicad-developers] Mac HighDPI performance

[Jon Evans]

Do we have a process or workflow for proposing changes to the roadmap?  A
number of the things from the V5 roadmap didn't happen, so it might make
sense to move some things around to V6 (and possibly a V5.1) roadmaps

-Jon

On Mon, Mar 5, 2018 at 9:12 AM, Wayne Stambaugh 
wrote:

> Jon,
>
> The v6 road map is here:
>
> http://docs.kicad-pcb.org/doxygen/v6_road_map.html
>
> I was planning on working on the schematic object but I wouldn't be
> offended if you want to implement it.  If you do decide to work on this,
> please keep me in the loop.  I have some things that I definitely want
> implemented as part of this object most of which you have probably
> already run into with your connectivity work.
>
> Cheers,
>
> Wayne
>
>
> On 3/4/2018 3:07 PM, Jon Evans wrote:
> > We should probably make some kind of road map if it doesn't exist
> > already, concerning the path to GAL for eeschema and who will be doing
> > what. For example, it might make sense to do the SCHEMATIC class
> > refactoring you were talking about before or in parallel with parts of
> > the porting effort.
> >
> > I'm up for working on this too, as soon as my connectivity / bus stuff
> > has landed.
> >
> > -Jon
> >
> > On Sun, Mar 4, 2018, 14:46 Wayne Stambaugh  > > wrote:
> >
> > I agree.  If it's not an easy straight forward fix, I would prefer to
> > spend our precious manpower resources on the GAL port as well.  I
> don't
> > know when in the v6 cycle any of this will happen but I'm guessing it
> > will happen fairly early.  Tom or Orson, do either of you have any
> idea
> > when this will happen?
> >
> > Wayne
> >
> > On 03/04/2018 02:40 PM, Jon Evans wrote:
> > > FWIW, I don't find the existing performance to be unusable, it's
> just
> > > not up to the standards of PcbNew/GAL.  I don't think it's worth
> any
> > > effort beyond easy fixes, we should put that energy into the GAL
> > port.
> > >
> > > -Jon
> > >
> > > On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier
> > 
> > > >>
> > wrote:
> > >
> > > I would judge it wrt eeschema GAL conversion.
> > > If that starts with v6, I don’t know if it is worth the effort.
> > > If it is unsure when this will happen, it might be worth it.
> > >
> > >
> > >> On 4. Mar 2018, at 20:30, Wayne Stambaugh
> > 
> > >> >>
> > wrote:
> > >>
> > >> Ughh!  I don't have a good answer for this one.  My best
> guess is
> > >> to fix
> > >> the wx macos code first and see what performance issues are
> > left.  The
> > >> problem with messing with any of this is that if you break
> > >> something it
> > >> will break all of the legacy canvas rendering not just the
> > schematic
> > >> editor.  I would move extremely carefully here.  I would
> prefer
> > >> that we
> > >> don't go too crazy this late in the v5 release cycle.  If the
> > >> performance is truly not usable on macos, then we may have no
> > choice.
> > >>
> > >> On 03/04/2018 02:07 PM, Jeff Young wrote:
> > >>> It turns out the fonts aren’t really the problem.
> > >>>
> > >>> It starts with this gem in wxWidgets:
> > >>>
> > >>>
> > voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)
> > >>>
> > >>>{
> > >>>
> > >>>#if1
> > >>>
> > >>>SetNeedsDisplay();
> > >>>
> > >>>#else
> > >>>
> > >>>//Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.
> > >>>
> > >>>if(GetNeedsDisplay())
> > >>>
> > >>>{
> > >>>
> > >>>SetNeedsDisplay() ;
> > >>>
> > >>>}
> > >>>
> > >>>NSRectr=wxToNSRect([m_osxViewsuperview],*rect);
> > >>>
> > >>>NSSizeoffset=NSMakeSize((float)dx,(float)dy);
> > >>>
> > >>>[m_osxViewscrollRect:rby:offset];
> > >>>
> > >>>#endif
> > >>>
> > >>>}
> > >>>
> > >>>
> > >>> SetNeedsDisplay() with no rectangle argument invalidates the
> > >>> entire window.
> > >>>
> > >>> Even if you fix that (to scroll most of the window and only
> > >>> invalidate
> > >>> the newly-exposed parts), you run into this:
> > >>>
> > >>>
> > voidwxWidgetCocoaImpl::drawRect(void*rect,
> WXWidgetslf,void*WXUNUSED(_cmd))
> > >>>
> > >>>{
> > >>>
> > >>>//preparingtheupdateregion
> > >>>
> > >>>wxRegionupdateRgn;
> > >>>
> > >>>
> > >>>
> >   

Re: [Kicad-developers] [PATCH] macOS CFBundleName

[Wayne Stambaugh]

This patch looks fine to me but would one of our macos devs please take
a look at this to make sure it is correct.

As for the symlink names, I don't know that the capitalization is all
that important unless it's a macos-centric thing.  I don't have an
opinion on this one way or the other.

On 3/4/2018 5:37 PM, Michael Kavanagh wrote:
> The attached trivial patch fixes the app menubar items to match the
> window titles, as well as when you "Quicklook" an executable, in
> activity monitor and probably some other places as well.
> 
> As a side is there any reason why the bundle/symlink names aren't
> capitalised/contain underscores instead of spaces? See attached
> screenshot.
> 
> Regards,
> Michael
> 
> 
> 
> ___
> 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] MacOS + OpenMP

[Wayne Stambaugh]

On windows builds using msys, openmp 4.5, gcc 7.3.0

On 3/4/2018 1:36 PM, Bernhard Stegmaier wrote:
> Hi all,
> 
> could please anybody test the following on a Windows/Linux OpenMP version?
> 
> I have a PCB with only components placed (via “Update from Schematic”),
> no routing done yet.
> Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer.
> Now, edit a footprint (“e”) and do a “Update Footprint from Library” for
> only this footprint (no changes in footprint needed).
> Open 3d-viewer again.
> 
> Or:
> Open PCB as above with only components and no routing yet.
> Make sure that 3d-viewer in OpenGL mode is fine, close 3d-viewer.
> Delete some of the components and reimport them vie “Update PCB from
> Schematic”.
> Open 3d-viewer again.
> 
> In both cases my OpenMP builds (clang-5.0.1 with libomp-3.1) crash or
> hang (all cores at 100%, grey window, nothing happens) 3d-viewer .
> It doesn’t hang/crash in my non-OpenMP builds.
> 
> If I save the PCB after the changes, close and reopen KiCad, then
> 3d-viewer of OpenMP build is also fine again.
> 
> 
> Regards,
> Bernhard
> 
>> On 3. Mar 2018, at 20:33, Bernhard Stegmaier > > wrote:
>>
>> Hi all,
>>
>> So, I played around a bit to get OpenMP and GCD into something like a
>> “parallel_for” wrapper which either uses OpenMP or GCD.
>> Unfortunately, OpenMP seems to require that the “for” statement
>> directly follows the “#pragma omg for …”.
>> That currently killed all my attempts to define such a “parallel_for”
>> (as function, #define, ?) so that the code will stay the same for both.
>> One option would be to pull the “#pragma omp for …” into the wrapper,
>> but I guess this is not really acceptable (since you can’t specify any
>> specific schedule parameters any longer).
>>
>> I will think about it some more just because of the challenge… but I
>> am not very optimistic at the moment to get something nice.
>> If anyone else has a nice idea, I’d be very interested to learn freaky
>> new stuff… :)
>>
>> On the other side, I looked at using a non-Xcode OpenMP capable clang.
>> The only caveat seems to be not to mix standard C++ libraries (in the
>> past libc++/libstdc++ haven’t been compatible in some aspects - didn’t
>> try to find out if that is resolved).
>> Default on macOS now is libc++, but it seems that at least MacPorts
>> builds clang with libstdc++ per default (no idea why).
>> The MacPorts build can easily be switched to libc++.
>> That clang-mp builds KiCad without problems even if dependencies have
>> been built with Xcode clang.
>> Everything seems to work as expected, multithreading is there where it
>> should be.
>>
>> So, for now it seems to be the most easy solution to switch to a
>> suitable non-Xcode clang for building packages - if we want to have
>> OpenMP for macOS.
>>
>> AFAIK our build machines use Homebrew.
>> Seems as if Homebrew decides which standard library to use depending
>> on macOS version (https://docs.brew.sh/C++-Standard-Libraries).
>> So, if everything is recent enough it might not be a problem at all…
>> like it obviously also has been for Seth below.
>>
>>
>> Regards,
>> Bernhard
>>
>>> On 1. Mar 2018, at 17:47, Seth Hillbrand >> > wrote:
>>>
>>> Hi All-
>>>
>>> I was playing with this last night (don't normally compile on the
>>> mac) and found that using homebrew's llvm 3.8.1 seems to compile fine
>>> with -fopenmp.  Running some OMP test code
>>> from https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5
>>> shows expected result of 4 threads.  I didn't get OpenMP errors when
>>> compiling KiCad although I didn't really notice a substantial
>>> difference in speed for the quick tests I was running.  Maybe with
>>> more involved operations.
>>>
>>> I'm not sure if this will require us to distribute a different
>>> libstdc++ with KiCad.  Probably.  Does that seem feasible to the
>>> packing team?
>>>
>>> -S
>>>
>>> 2018-03-01 7:23 GMT-08:00 Bernhard Stegmaier >> >:
>>>
>>> Hmm?
>>> You keep everything as is (especially creating threads), but just
>>> put the “#pragma …” before the for-loop.
>>> So, there is one thread for the progress and one for the workers.
>>> In the workers thread OpenMP (if there) takes care of adding
>>> additional threads for parallelising the loop?
>>>
>>> Or, am I wrong with that?
>>>
>>> > On 1. Mar 2018, at 16:11, Jeff Young >> > wrote:
>>> >
>>> > But then the progress reporter won’t work (and you’ve got no
>>> way to cancel).
>>> >
>>> > Non-pooling parallel threads are sufficient for zone filling,
>>> aren’t they?
>>> >
>>> >
>>> >> On 1 Mar 2018, at 15:00, Bernhard Stegmaier
>>> > wrote:
>>> >>
>>> >> For now it 

Re: [Kicad-developers] Mac HighDPI performance

[Wayne Stambaugh]

Jon,

The v6 road map is here:

http://docs.kicad-pcb.org/doxygen/v6_road_map.html

I was planning on working on the schematic object but I wouldn't be
offended if you want to implement it.  If you do decide to work on this,
please keep me in the loop.  I have some things that I definitely want
implemented as part of this object most of which you have probably
already run into with your connectivity work.

Cheers,

Wayne


On 3/4/2018 3:07 PM, Jon Evans wrote:
> We should probably make some kind of road map if it doesn't exist
> already, concerning the path to GAL for eeschema and who will be doing
> what. For example, it might make sense to do the SCHEMATIC class
> refactoring you were talking about before or in parallel with parts of
> the porting effort.
> 
> I'm up for working on this too, as soon as my connectivity / bus stuff
> has landed. 
> 
> -Jon
> 
> On Sun, Mar 4, 2018, 14:46 Wayne Stambaugh  > wrote:
> 
> I agree.  If it's not an easy straight forward fix, I would prefer to
> spend our precious manpower resources on the GAL port as well.  I don't
> know when in the v6 cycle any of this will happen but I'm guessing it
> will happen fairly early.  Tom or Orson, do either of you have any idea
> when this will happen?
> 
> Wayne
> 
> On 03/04/2018 02:40 PM, Jon Evans wrote:
> > FWIW, I don't find the existing performance to be unusable, it's just
> > not up to the standards of PcbNew/GAL.  I don't think it's worth any
> > effort beyond easy fixes, we should put that energy into the GAL
> port. 
> >
> > -Jon
> >
> > On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier
> 
> > >>
> wrote:
> >
> >     I would judge it wrt eeschema GAL conversion.
> >     If that starts with v6, I don’t know if it is worth the effort.
> >     If it is unsure when this will happen, it might be worth it.
> >
> >
> >>     On 4. Mar 2018, at 20:30, Wayne Stambaugh
> 
> >>     >>
> wrote:
> >>
> >>     Ughh!  I don't have a good answer for this one.  My best guess is
> >>     to fix
> >>     the wx macos code first and see what performance issues are
> left.  The
> >>     problem with messing with any of this is that if you break
> >>     something it
> >>     will break all of the legacy canvas rendering not just the
> schematic
> >>     editor.  I would move extremely carefully here.  I would prefer
> >>     that we
> >>     don't go too crazy this late in the v5 release cycle.  If the
> >>     performance is truly not usable on macos, then we may have no
> choice.
> >>
> >>     On 03/04/2018 02:07 PM, Jeff Young wrote:
> >>>     It turns out the fonts aren’t really the problem.
> >>>
> >>>     It starts with this gem in wxWidgets:
> >>>
> >>>   
> voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)
> >>>
> >>>    {
> >>>
> >>>    #if1
> >>>
> >>>    SetNeedsDisplay();
> >>>
> >>>    #else
> >>>
> >>>    //Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.
> >>>
> >>>    if(GetNeedsDisplay())
> >>>
> >>>    {
> >>>
> >>>    SetNeedsDisplay() ;
> >>>
> >>>    }
> >>>
> >>>    NSRectr=wxToNSRect([m_osxViewsuperview],*rect);
> >>>
> >>>    NSSizeoffset=NSMakeSize((float)dx,(float)dy);
> >>>
> >>>    [m_osxViewscrollRect:rby:offset];
> >>>
> >>>    #endif
> >>>
> >>>    }
> >>>
> >>>
> >>>     SetNeedsDisplay() with no rectangle argument invalidates the
> >>>     entire window.
> >>>
> >>>     Even if you fix that (to scroll most of the window and only
> >>>     invalidate
> >>>     the newly-exposed parts), you run into this:
> >>>
> >>>   
> 
> voidwxWidgetCocoaImpl::drawRect(void*rect,WXWidgetslf,void*WXUNUSED(_cmd))
> >>>
> >>>    {
> >>>
> >>>    //preparingtheupdateregion
> >>>
> >>>    wxRegionupdateRgn;
> >>>
> >>>
> >>>   
> 
> //sinceaddingmanyrectstoaregionisacostlyprocess,bydefaultusetheboundingrect
> >>>
> >>>    #if0
> >>>
> >>>    constNSRect*rects;
> >>>
> >>>    NSIntegercount;
> >>>
> >>>    [slfgetRectsBeingDrawn::];
> >>>
> >>>    for(inti=0;i >>>
> >>>    {
> >>>
> >>>    updateRgn.Union(wxFromNSRect(slf,rects[i]));
> >>>
> >>>    }
> >>>
> >>>    #else
> >>>
> >>>    updateRgn.Union(wxFromNSRect(slf,*(NSRect*)rect));
>

Re: [Kicad-developers] Settable clearances

[Jon Evans]

I can certainly help check it.  I think Wayne would have to make a call as
to whether or not it's too big a change to introduce now.

-Jon

On Mon, Mar 5, 2018 at 7:59 AM, hauptmech  wrote:

> While testing version 5 I realized that clearances are still not settable
> (like track width or via size) and my life is going to be miserable if I
> have to continue with my current work flow which is to change the default
> netclass clearance to the desired clearance constantly as I lay down
> different tracks which require different clearances even though they are
> part of the some net.
>
> There is a previous thread detailing why netclass is not sufficient for
> all use cases. Search for netclass in the subject.
>
> Anyway, I wrote most of a patch today (it's 1am in my timezone now) and
> expect to finish it tomorrow. I believe I have a solution which will be
> useful for those that need it and mostly invisible to those that don't.
>
> The question is whether there is a core developer willing to check, sign
> off, and help sell it for inclusion in 5. (I'm stuck using whatever the
> current stable version of kicad is when I'm working)
>
> This is a huge pain point for me and I'm willing to negotiate a small
> bounty if that helps.
>
>
>
> ___
> 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] Jumpy canvas on other platforms?

[Wayne Stambaugh]

I'm not seeing this on my windows 7 builds.  The panning after zoom
extents works smoothly.  I even tried resizing the main frame several
times but I still didn't notice it.

On 3/4/2018 5:00 PM, Jeff Young wrote:
> There is actually code in there to make them always on, but there seems
> to be something defeating it.  I’ll poke around some more.
> 
>> On 4 Mar 2018, at 21:57, Jon Evans > > wrote:
>>
>> Ah yes, I can reproduce that on Windows too.  I guess I didn't notice
>> before because generally the scrollbars are visible (I noticed that
>> "zoom extents" doesnt *always* result in the scrollbars being hidden,
>> for whatever reason)
>> Any reason why we hide the scrollbars?  Seems like it might be simpler
>> to just always show them...
>> -Jon
>>
>> On Sun, Mar 4, 2018 at 4:52 PM, Bernhard Stegmaier
>> > wrote:
>>
>> Do a “fit to window” and then pan left/right… I use the touchpad.
>> After “fit to window” there is no scrollbar.
>> When the scrollbar comes back due to panning, I see almost always
>> a small shift of the whole view down and then up again.
>> Sometimes, but not always if you just pan left/right it will make
>> this small jump downwards every time you cross center, just as if
>> it would “snap" to middle position.
>>
>>
>>> On 4. Mar 2018, at 21:25, Jon Evans >> > wrote:
>>>
>>> Maybe I don't really understand what you mean, but I can't see
>>> any jumpiness on Linux when panning around (with middle-mouse drag).
>>> What do you mean by "it automatically fits to window, so there's
>>> not really any place to go"?  It does not do any kind of
>>> auto-fitting except for the zoom-extents on file load on Linux,
>>> and I don't have my Mac machine handy to compare.
>>>
>>> On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young >> > wrote:
>>>
>>> If I open an eeschema file on OSX and pan around (it
>>> automatically fits to window, so there’s not really any place
>>> to go), the screen jumps around a bit.  True also on other
>>> platforms, or Mac-specific?
>>>
>>> Thanks,
>>> Jeff.
>>> ___
>>> 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

[Kicad-developers] Settable clearances

[hauptmech]

While testing version 5 I realized that clearances are still not settable
(like track width or via size) and my life is going to be miserable if I
have to continue with my current work flow which is to change the default
netclass clearance to the desired clearance constantly as I lay down
different tracks which require different clearances even though they are
part of the some net.

There is a previous thread detailing why netclass is not sufficient for all
use cases. Search for netclass in the subject.

Anyway, I wrote most of a patch today (it's 1am in my timezone now) and
expect to finish it tomorrow. I believe I have a solution which will be
useful for those that need it and mostly invisible to those that don't.

The question is whether there is a core developer willing to check, sign
off, and help sell it for inclusion in 5. (I'm stuck using whatever the
current stable version of kicad is when I'm working)

This is a huge pain point for me and I'm willing to negotiate a small
bounty if that helps.
___
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] Mac HighDPI performance

[Wayne Stambaugh]

It is not possible for me to make any kind of accurate time predictions
about when v6 might be released.  KiCad development does not move at a
constant pace.  Right now, we are at an all time high with developer
involvement but that may not last.  We have had a number of developers
come and go over the years so the project development tends to happen in
short bursts.  I wish I could give you a better answer than that but I
cannot.  I suspect this is the case with most if not all open source
projects.

Wayne

On 3/4/2018 8:40 PM, Andrey Kuznetsov wrote:
> Of course Wayne, that was my way of expressing concern for delaying a
> performance issue and trying to sauce out your feeling of the possible
> duration of v6 development.
> Do you think there is currently manpower and list of features that
> requires 1 year plus 6 months delay, or do you think it's more like 2
> years best case and 1 year of delay worst case time of thing?
> 
> On Sun, Mar 4, 2018 at 5:03 PM, Wayne Stambaugh  > wrote:
> 
> When you become the project leader of KiCad, then you can make these
> decisions and live with the consequences of them.  In the mean time,
> that responsibility falls on my shoulders.  We are in a feature
> freeze for v5 stable so I'm going to err on the side of caution
> here.  If we can pick up some performance gains without pushing the
> v5 stable release out, then I'm fine with that but if there are any
> stability issues then we will have to live with what we have. 
> Implementing this at the beginning of v6 and back porting it when
> it's stable is also acceptable.  Hopefully v6 will not take 2-3 years.
> 
> Wayne
> 
> On 03/04/2018 07:00 PM, Andrey Kuznetsov wrote:
> 
> If 6.0 is coming in 1 year, OK, but if it's 2-3 years away then
> I'd say v5.0 should be stable and not have performance issues,
> in my mind better to delay v5 up to 1 month at most to fix it
> rather than let it sit like that for 2-3 years.
> 
> On Sun, Mar 4, 2018 at 3:39 PM, Jeff Young    >> wrote:
> 
>     As for road-map, I’d suggest that EeschemaGAL +
> newSymbolFileFormat
>     == 6.0.  Anything else that can ride along is fine, but not
> definitive.
> 
>     The legacy stuff represents a tax on all development we do.
> 
>     Cheers,
>     Jeff.
> 
> 
>     On 4 Mar 2018, at 23:31, Jeff Young  
>     >> wrote:
> 
>     Well, I pounded on it a bit more, and it wasn’t really
> fitting
>     into “easy” /or/ “straight forward”.  It’ll have to wait.
> 
>     Cheers,
>     Jeff.
> 
>     On 4 Mar 2018, at 20:07, Jon Evans
> 
>      >> wrote:
> 
>     We should probably make some kind of road map if it
> doesn't exist
>     already, concerning the path to GAL for eeschema and
> who will be
>     doing what. For example, it might make sense to do
> the SCHEMATIC
>     class refactoring you were talking about before or
> in parallel
>     with parts of the porting effort.
> 
>     I'm up for working on this too, as soon as my
> connectivity / bus
>     stuff has landed.
> 
>     -Jon
> 
>     On Sun, Mar 4, 2018, 14:46 Wayne Stambaugh
> 
>      >> wrote:
> 
>         I agree.  If it's not an easy straight forward
> fix, I would
>         prefer to
>         spend our precious manpower resources on the GAL
> port as
>         well.  I don't
>         know when in the v6 cycle any of this will
> happen but I'm
>         guessing it
>         will happen fairly early.  Tom or Orson, do
> either of you
>         have any idea
>         when this will happen?
> 
>         Wayne
> 
>         On 03/04/2018 02:40 PM, Jon Evans wrote:
>         > FWIW, I don't find the existing performance to
> be unusable,
>         it's just
>         > not up to