Re: [Kicad-developers] Grid in GAL canvas

On 15.01.2016 00:50, Wayne Stambaugh wrote: > On 1/14/2016 3:06 PM, Bernhard Stegmaier wrote: >> Question for me is what happens to eeschema? >> For pcbnew it is maybe just adding some missing things and polishing some >> other, but eeschema currently has nothing in that direction. >> Anybody

Re: [Kicad-developers] Grid in GAL canvas

Swt, I've been wanting a flipped mode for a long time now. Thanks Tom! :) On Fri, Jan 15, 2016 at 05:58:41PM +0100, Tomasz Wlostowski wrote: > On 15.01.2016 00:50, Wayne Stambaugh wrote: > > On 1/14/2016 3:06 PM, Bernhard Stegmaier wrote: > >> Question for me is what happens to eeschema? >

[Kicad-developers] [PATCH] Remove dead legacy save code

Hi, Here's a patch to remove a bunch of ancient, dead file-save code from the legacy plugin. There's no point in keeping this around anymore, as the formats aren't even compatible now. I don't expect this to be controversial - the code hasn't been touched in over a year and a half - so if

Re: [Kicad-developers] Grid in GAL canvas

On 1/15/2016 12:02 PM, Tomasz Wlostowski wrote: > On 14.01.2016 19:58, Chris Pavlina wrote: >> Yeah, I'll be difficult too - it looks Bad now, very distracting. The >> legacy grid color was meant for use with a dot grid, not a line grid, so >> it has to be brighter. When you use it for a line

Re: [Kicad-developers] [RFC PATCH] Rounded rectangle pads

Le 14/01/2016 01:39, Cirilo Bernardo a écrit : > On Tue, Jan 12, 2016 at 10:06 AM, Mathias Grimmberger > wrote: <> > I'd like to implement arbitrary pad shapes but this requires a functional 2D > geometry kernel first. I'm starting on one but I may have nothing to >

[Kicad-developers] wxDC GAL (Re: Grid in GAL canvas)

Hi,   Are we even still going to have legacy pcbnew at the next release? What's the schedule for fully deprecating it? >> >>It will not be deprecated until we have one for one feature parity >>between the canvases and we can get by without it on all supported >>platforms. AFAIK, Tom is

Re: [Kicad-developers] wxDC GAL (Re: Grid in GAL canvas)

It is a new(ish) decision. Cairo is an implementation that doesn't require hardware features, but it is uselessly slow - even on my main build machine which is quite snappy I'd completely refuse to work under it. We need a GAL backend that works with minimal hardware at a usable speed, and I

Re: [Kicad-developers] KiCad Coroutines

Hi Tom,   I'm working on some alternatives, that I'm getting a better impression. I'll upload the example code this weekend, then we can discuss. One alternative are for instance stackless coroutines. I've also checked how you're using them in your code and have some ideas to modify that.  

Re: [Kicad-developers] [RFC PATCH] Rounded rectangle pads

On 15.01.2016 21:02, jp charras wrote: > Le 14/01/2016 01:39, Cirilo Bernardo a écrit : >> On Tue, Jan 12, 2016 at 10:06 AM, Mathias Grimmberger >> wrote: > > <> > >> I'd like to implement arbitrary pad shapes but this requires a functional 2D >> geometry kernel first.

Re: [Kicad-developers] wxDC GAL (Re: Grid in GAL canvas)

On 15.01.2016 20:44, "Torsten Hüter" wrote: > Hi, > > Are we even still going to have legacy pcbnew at the next release? > What's the schedule for fully deprecating it? >>> >>> It will not be deprecated until we have one for one feature parity >>> between the canvases and we can get by

[Kicad-developers] Dreaming of geometry kernels and physics engines... (RFC/OT)

Once, I had a dream... [snippets of last threads:] >>> I'd like to implement arbitrary pad shapes but this requires a functional 2D >>> geometry kernel first. >> There is already a geometry kernel in Kicad: Have a look at >> include/geometry before writing anything. > Indeed, there is a

[Kicad-developers] [PATCH 00/11] Portability series

Hi, these are portability patches, most of them derived from MSVC diagnostics. The MSVC standard library and compiler are a lot more picky about standards compliance, so a lot of code that has only been tested on GCC is not actually standards compliant. This patch series mainly reduces our

[Kicad-developers] [PATCH 01/11] Avoid comparing filepos with integers

The filepos type is not necessarily an integer type, because it also needs to save the multibyte character state in case we're reading from a stream with shift states. The convention of using -1 as a special value is from Unix ftell(), and not portable. Instead, the stream's failbit needs to be

[Kicad-developers] [PATCH] Remove superfluous include in the middle of source file

--- pcbnew/autorouter/rect_placement/rect_placement.cpp | 1 - 1 file changed, 1 deletion(-) diff --git a/pcbnew/autorouter/rect_placement/rect_placement.cpp b/pcbnew/autorouter/rect_placement/rect_placement.cpp index da53097..3c7f562 100644 ---

Re: [Kicad-developers] [PATCH 01/11] Avoid comparing filepos with integers

Hi, On 16.01.2016 04:41, Simon Richter wrote: > The convention of using -1 as a special value is from Unix ftell(), and not > portable. Instead, the stream's failbit needs to be examined after the call > to tellg(). Wait, that patch got damaged in a rebase apparently. The test should be after

[Kicad-developers] [PATCH] Pull eeschema colors into preferences dialog

Hi, The next installment of my preferences work is simple, I pulled the color configuration dialog into the eeschema preferences dialog. I deleted the original color dialog, removing it from libedit as well (it's just redundant there, it edits the same settings that are shared across both).

Re: [Kicad-developers] GCC and C++14

With help from Nick I set up my computer to do C++11 builds with clang and gcc. You can find the jenkins builds here: http://ci.kicad-pcb.org/view/KiCad%20builds/ (look for C++11) I'll discuss with people on IRC to see about setting up a C++11 branch to test things out. Everyone pushing for C++11

Re: [Kicad-developers] [PATCH 11/11] Replace GCC-specific __func__ with portable __FUNCTION__

On 16.01.2016 04:41, Simon Richter wrote: > > This macro is GCC-specific and should be avoided in portable code. > --- > include/common.h | 6 ++ > 1 file changed, 6 insertions(+) > Meh, that shouldn't have been in the portability branch, but only the msvc branch. Please ignore that one.

[Kicad-developers] [PATCH] Genericize Windows import/export

Windows-style dllimport/dllexport should be used whenever targetting Windows directly, not just for MINGW. --- include/import_export.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/import_export.h b/include/import_export.h index c31729e..672709f 100644 ---

[Kicad-developers] [PATCH 05/11] Correct import/export of KIFACE_GETTER.

This function is passed through a DLL interface, so users need to be aware that they need to generate import stubs on Windows. Implicit generation of stubs for undefined functions is an extension of the GNU toolchain. --- include/kiway.h | 9 +++-- 1 file changed, 7 insertions(+), 2

[Kicad-developers] [PATCH 03/11] Clarify atan2 overloads

In the C++ standard, this function is only defined for floating point types, and integers cannot be implicitly converted. Using explicit conversions avoids a GCC specific extension to the standard library. --- common/trigo.cpp| 2 +- gerbview/gerbview_frame.cpp | 2 +-

[Kicad-developers] [PATCH 04/11] Avoid cast from const_iterator to iterator

The standard library requires iterators passed to functions that modify the container to be mutable iterators, but GCC's implementation accepts const_iterator in some places where these are only used to mark a place, but the actual modification happens through a different parameter. As this

[Kicad-developers] [PATCH 02/11] Drop some debug output

This was apparently left in from debugging earlier, and should no longer be needed. Since it uses a GCC extension, it makes compilation on others fail. --- pcbnew/tools/pcbnew_control.cpp | 4 1 file changed, 4 deletions(-) diff --git a/pcbnew/tools/pcbnew_control.cpp

[Kicad-developers] [PATCH 09/11] Use const int instead of anonymous enum type

These values are used in a context where the implicit conversion to integer is necessary, but creates ambiguous template resolutions that MSVC 9 cannot resolve. As these constants are not actually an enumerated type, simply declaring them as static members avoids the problem. ---

[Kicad-developers] [PATCH 07/11] Open namespace around definitions

While defining functions in another namespace is technically allowed as long as the definition can be matched to a declaration, this can lead to ambiguous resolutions, such as here. --- pcbnew/ratsnest_viewitem.cpp | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[Kicad-developers] [PATCH 11/11] Replace GCC-specific __func__ with portable __FUNCTION__

This macro is GCC-specific and should be avoided in portable code. --- include/common.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/common.h b/include/common.h index b881444..5eeea09 100644 --- a/include/common.h +++ b/include/common.h @@ -98,6 +98,12 @@ enum pseudokeys {

[Kicad-developers] [PATCH 10/11] Avoid conflicting declaration for Pgm()

This function has two conflicting definitions in the "kicad" executable and the other wrapper programs. As the kifaces can be loaded from either, this silently assumes compatible data layout for the PGM_KICAD and PGM_BASE types when passed by reference, which is valid only when the compiler is

[Kicad-developers] [PATCH 06/11] Add missing C++ stdlib headers

The GCC standard library headers often include other headers as an implementation detail. As this is not guaranteed by the standard, it is non-portable. --- common/gal/graphics_abstraction_layer.cpp | 2 ++ common/grid_tricks.cpp | 2 ++ common/selcolor.cpp

[Kicad-developers] [PATCH 08/11] Use numeric_limits for NaN constant

The NAN macro is not necessarily defined in math.h, so use std::numeric_limits to look up an appropriate value. --- common/gal/color4d.cpp | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/common/gal/color4d.cpp b/common/gal/color4d.cpp index 3b509d3..3a19dc5 100644 ---