Re: [Kicad-developers] Stable 5 development.

Just curious, a month back there were some emails discussing about major variable renames, it was decided to wait until people finished committing major features to avoid rebasing every patch. Has this been done? On Sat, Feb 24, 2018 at 3:30 PM, Wayne Stambaugh wrote: > I

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

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) diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt index

Re: [Kicad-developers] Stable 5 development.

I think for v4 we forked when there was agreement that all was good; new features like the new 3D viewer and 3D plugins simply had to be developed separately and merged after the v4 fork. For me this is the only process which makes sense; forking so early on is a nuisance to everyone including any

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

What do you mean by a second target? Keep in mind that we don't want to recompile everything twice just because of the kiface libraries. If you can create a target which is dependent on the pcbnew stand-alone app and which used the object files to create a shared library, that would be good. I

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

I took a look at what approaches might work to fix this. I looked at removing the RPATH manually, in keeping with manual file manipulation approach used by the authors of this section of the CMake file. Shell tools to do this don't appear to be universal and it's not using the CMake way. So I

Re: [Kicad-developers] Stable 5 development.

It didn't take much to convince me. I've made the changes. We are still at rc1 and marching on to rc2. Cheers, Wayne On 02/24/2018 06:37 PM, Jon Evans wrote: I would also recommend keeping 5.0 in master (and just use tags for the RCs) to keep things simpler. I think we don't have enough

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

I've confirmed that there is a wrong RPATH in the install. The issue is in pcbnew/CMakeFiles.txt#if( KICAD_SCRIPTING_MODULES ). Rather than using the CMake install target script, _pcbnew.so is getting copied manually and then installed as a file. On 25/02/18 10:37, Carsten Schoenert wrote:

Re: [Kicad-developers] Stable 5 development.

I would also recommend keeping 5.0 in master (and just use tags for the RCs) to keep things simpler. I think we don't have enough committers and QA process to handle two parallel branches. Like Jeff said, anyone working on 6.0 stuff can just keep it in a private branch a little longer. -Jon On

Re: [Kicad-developers] Stable 5 development.

I agree that it doesn’t make sense to branch if we’re not going to open main for 6.0. I think the main argument for opening main is that developers tend to write code. The best way to keep them from messing up the stable is to give them someplace else to put it. ;) But with git it probably

[Kicad-developers] Stable 5 development.

I quick note to my lead developers (those of you with repo privileges) please hold off on making any pushes until I make a decision on the current branch situation. I'm thinking it doesn't make sense to have two identical branches all the way up to the stable release. All this does is make

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

The RUNPATH should be stripped by the linker, if it isn't then there is a problem in our build system. I created the various dynamic plugins and the scenegraph library and made sure that the RUNPATH is removed; it is of value primarily to developers and in general is nothing but a headache when

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

On 25/02/18 10:37, Carsten Schoenert wrote: the build and installation is just fine, the issue is that this file has a RUNPATH set to folder there it was compiled. It should have*no* RUNPATH. I'm not understanding this thread 100% so apologies if this misses the point. RPATH is set by

Re: [Kicad-developers] Improving Eagle Import netlist matching

Hi Orson, I looked at the Kicad project from the and I don't see any global labels, just local labels. The PCB will still have the global nets though, since they are created during import of the eagle pcb file. Just to be clear my patches are intended to only generate global labels when

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

Hello Wayne, Am 24.02.18 um 21:44 schrieb Wayne Stambaugh: > Carsten, > > On 02/24/2018 02:08 PM, Carsten Schoenert wrote: >> Hi, >> >> I guess it's not intended that the library / shared object _pcbnew.so >> build in pcbnew/ set up a RPATH based on the build directory? > > This is the kicad

[Kicad-developers] Stable 5 branch is out

I created the v5 branch and tagged rc1 so we are officially working towards a stable 5 release. No new features will be added to dev branch until the stable version 5 is released so everyone stay focused on that and to keep life as easy as possible to apply patches to both branches. Thank you

Re: [Kicad-developers] validators

I looked in to wxWidget’s validators, and they’re definitely challenged. (Brain-dead might be more accurate.) As part of the units overhaul I’m going to propose making widespread use of the UNIT_BINDER, which is a wrapper for a wxTextEntry/wxStaticText-tuple. As a wrapper it’ll be easy to

Re: [Kicad-developers] Fabrication Outputs and Plot

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

Re: [Kicad-developers] [PATCH] Rearrange Render panel of PcbNew layer widget; add spacers

4. State of some checkboxes is not saved. Fix for that one in attachment. Andrzej >From 9ccc36e2d0de45175e928bb70f14340392bd35be Mon Sep 17 00:00:00 2001 From: Andrzej Wolski Date: Sat, 24 Feb 2018 21:51:33 +0100 Subject: [PATCH] Restore some missing visibility

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

Carsten, On 02/24/2018 02:08 PM, Carsten Schoenert wrote: Hi, I guess it's not intended that the library / shared object _pcbnew.so build in pcbnew/ set up a RPATH based on the build directory? This is the kicad python scripting shared object which should get installed in the correct python

Re: [Kicad-developers] Fabrication Outputs and Plot

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,

Re: [Kicad-developers] Fabrication Outputs and Plot

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

Re: [Kicad-developers] Fabrication Outputs and Plot

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

[Kicad-developers] RPATH issue on _pcbnew.so

Hi, I guess it's not intended that the library / shared object _pcbnew.so build in pcbnew/ set up a RPATH based on the build directory? > root@i5:/# ldd build/kicad-5.0.0~rc0+dfsg1/debian/build/pcbnew/_pcbnew.so | > grep build > libkicad_3dsg.so.2.0.0 => >

Re: [Kicad-developers] Fabrication Outputs and Plot

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

Re: [Kicad-developers] Fabrication Outputs and Plot

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):

Re: [Kicad-developers] Fabrication Outputs and Plot

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

Re: [Kicad-developers] [PATCH] fix crashes related to footprint selection

All set. Included here for reference On Sat, Feb 24, 2018 at 1:09 PM, Jeff Young wrote: > Hi Jon, > > Cool. You want to attach that one to the bug? > > Cheers, > Jeff. > > > On 24 Feb 2018, at 17:55, Jon Evans wrote: > > Yes it definitely is specific to

Re: [Kicad-developers] Fabrication Outputs and Plot

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. Cheers, Jeff. > On 24 Feb 2018, at 14:54,

Re: [Kicad-developers] [PATCH] fix crashes related to footprint selection

Hi Jon, Cool. You want to attach that one to the bug? Cheers, Jeff. > On 24 Feb 2018, at 17:55, Jon Evans wrote: > > Yes it definitely is specific to some kind of library config issue. I think > I have one or more invalid library path, which helps in triggering the

Re: [Kicad-developers] [PATCH] fix crashes related to footprint selection

Yes it definitely is specific to some kind of library config issue. I think I have one or more invalid library path, which helps in triggering the bug. Your patch does not completely fix the issue for me. FP_CACHE::Load() is throwing an exception which is passed through validateCache() but then

Re: [Kicad-developers] [PATCH] fix crashes related to footprint selection

Hey guys,I’m not sure why I can’t reproduce this (perhaps because I’m still on old libraries?), but could you guys try this one out?Cheers,Jeff. 0002-Fix-segfault-when-not-all-libraries-loaded.patch Description: Binary data On 24 Feb 2018, at 17:32, Jeff Young wrote:Hi Jon,Thanks

Re: [Kicad-developers] [PATCH] fix crashes related to footprint selection

Hi Jon, Thanks for looking into this, but the second one will kill performance. I’ve got a slightly different one baking…. Cheers, Jeff. > On 24 Feb 2018, at 17:18, Jon Evans wrote: > > See: https://bugs.launchpad.net/kicad/+bug/1751464 >

Re: [Kicad-developers] Fabrication Outputs and Plot

I agree with this! It has always tripped me up when I switch back and forth between kicad and other EDA tools. On Feb 24, 2018 9:31 AM, "Diego Herranz" wrote: > Hi, > > Now that so much work is happening on re-structuring menus, I've > remembered something I have

[Kicad-developers] Fabrication Outputs and Plot

Hi, Now that so much work is happening on re-structuring menus, I've remembered something I have always found weird on pcbnew. "Plot", from wihch you can obtain Gerbers is not inside "Fabrication Outputs", but on its own. I find it weird to have the drill option inside "Fabrication Outputs" but

Re: [Kicad-developers] [PATCH] expose BOARD_COMMIT to python

Miles, I'm not opposite to exposing the BOARD_COMMIT object but there are some serious ramifications of doing so. Although we already expose objects that can crash the board editor from python scripting so I don't know that one more will be all that significant. Can anyone else think of a

Re: [Kicad-developers] Non copper zones

Orson, The problem is that users have been using zones in non-copper layers so the expectation is that they will be able to continue to use them. I tested this and when you create a zone on a non-copper zone using the zone editor tool, it actually saves the object as a zone which is

[Kicad-developers] [PATCH] expose BOARD_COMMIT to python

Back in November I was in a thread about board_commit: https://lists.launchpad.net/kicad-developers/msg32063.html The topic had come up in another patch: https://lists.launchpad.net/kicad-developers/msg32134.html See attached path file. added needed code to SWIG to enable using BOARD_COMMIT

Re: [Kicad-developers] Nightly builds.

Hi Wayne, On 23.02.2018 19:10, Wayne Stambaugh wrote: > Thanks. I've never used a RelWithDebInfo build. What kind of debugging > info would this give me if I ran it gdb? Would it be good enough for > someone to do produce useful debugging information performing a > backtrace on a segfault?

Re: [Kicad-developers] Non copper zones

Le 24/02/2018 à 08:42, Maciej Suminski a écrit : > Sorry for late answer, I will not have a reliable Internet connection until > Sunday evening. I > removed the option to draw ZONE_CONTAINERs as they are dedicated to copper > layers. For graphical > items there is DRAWSEGMENT of POLYGON type. If