Re: [Kicad-developers] [PATCH] add oz/ft^2 as an option in the trace thickness calc

Updated the patch a teeny tiny bit. I switched from using mils to the actual microns value (wasn't paying attention to the micron conversion already there) and I forgot to update the comment next to that. On Tue, Jan 5, 2016 at 1:43 AM Jon Neal wrote: > Surprised this hasn't been in there until

[Kicad-developers] [PATCH] add oz/ft^2 as an option in the trace thickness calc

Surprised this hasn't been in there until now! I used the IPC-2221a thickness (1 oz/ft^2 = 34.30 microns = ~1.3503 mils). The calculations match other calculators pretty closely. Jon From 22e7d80bc3da668b974ef7382cba8122c10f630f Mon Sep 17 00:00:00 2001 From: Jon Neal Date: Tue, 5 Jan 2016 00:48

Re: [Kicad-developers] Need feedback on new way of pcbnew importing footprints

Five thumbs up! On Tue, Jan 05, 2016 at 01:59:33AM +, Jon Neal wrote: > I asked about this a while back and got a little bit of feedback, I now > have a patch for people to try. > > What this does is when you import a netlist (in GAL only though) it > automatically spreads out all newly added

[Kicad-developers] Need feedback on new way of pcbnew importing footprints

I asked about this a while back and got a little bit of feedback, I now have a patch for people to try. What this does is when you import a netlist (in GAL only though) it automatically spreads out all newly added footprints and it places them all in "selection + move" mode. So basically you impor

Re: [Kicad-developers] support of 3D model plugins

On Tue, Jan 5, 2016 at 10:26 AM, Chris Gagneraud wrote: > Hi Cirilo, > > Out of curiosity, are you using the OpenVRML parser framework for > VRML97 and VRML-encoded X3D files? > If not, any reason why? > FWIU, their implementation is template based and only depend on boost. > So theorically, this

Re: [Kicad-developers] [PATCH] Refactor hotkeys editor dialog more

Third step, again to be merged on top of the previous ones. This one pulls the Hotkeys dialog finally into the eeschema Preferences dialog. To go with it, I also pulled the load/save hotkeys command into that dialog, and for consistency, the load/save preferences command. These are now an "Impo

Re: [Kicad-developers] [PATCH] Refactor hotkeys editor dialog

Patch committed in r6422. Thanks. On 1/4/2016 3:05 PM, Chris Pavlina wrote: > Hi, > > First step in getting the hotkey configuration inside the main > preferences dialog is to refactor it a bit. This patch: > > - Replaces the wxListCtrl with a wxTreeListCtrl, allowing expandable > categorie

[Kicad-developers] [PATCH] Refactor hotkeys editor dialog more

Second step is to remove the pages from the hotkeys dialog and make it a single-page control, so we don't have nested tabs when it's brought into the already tabbed options dialog. This patch removes the pages, in favor of categories in the wxTreeListCtrl. It also makes the final few steps towa

Re: [Kicad-developers] support of 3D model plugins

thanks a lot! :) Maurice On 04/01/2016 21.33, Cirilo Bernardo wrote: The code has already been tested with FreeCAD VRML models (which have a very strange construction) and has already been improved to work with the FreeCAD output. So at the moment it's VRML1 (high priority) and X3D which are mis

Re: [Kicad-developers] support of 3D model plugins

The code has already been tested with FreeCAD VRML models (which have a very strange construction) and has already been improved to work with the FreeCAD output. So at the moment it's VRML1 (high priority) and X3D which are missing. I also have plans now to support the VRML Inline { } feature used

Re: [Kicad-developers] OS X drawing performance improvements

Patch committed in product branch r6420. Thanks. Cheers, Wayne On 1/4/2016 3:03 PM, Bernhard Stegmaier wrote: > From my point of view it is. > What makes you unsure? > > The comment about the #ifdefs was just about cosmetics. > But, it keeps the changes (and possible performance impacts when n

Re: [Kicad-developers] OS X drawing performance improvements

Do I need to give credit to anyone besides Bernhard on this? Does it fix any open bugs? I couldn't find any. On 1/4/2016 3:03 PM, Bernhard Stegmaier wrote: > From my point of view it is. > What makes you unsure? > > The comment about the #ifdefs was just about cosmetics. > But, it keeps the cha

[Kicad-developers] [PATCH] Refactor hotkeys editor dialog

Hi, First step in getting the hotkey configuration inside the main preferences dialog is to refactor it a bit. This patch: - Replaces the wxListCtrl with a wxTreeListCtrl, allowing expandable categories in a future change. - Cleans up the code to make HOTKEY_LIST_CTRL function a bit better o

Re: [Kicad-developers] OS X drawing performance improvements

(I like it!) On Mon, Jan 4, 2016 at 1:11 PM, Wayne Stambaugh wrote: > Is this patch ready to be committed? > > On 1/4/2016 11:12 AM, Bernhard Stegmaier wrote: > > It adds some #ifdefs for not compiling the wxGraphicsContext stuff at > all when USE_WX_GRAPHICS_CONTEXT isn’t in use. > > If you hat

Re: [Kicad-developers] OS X drawing performance improvements

>From my point of view it is. What makes you unsure? The comment about the #ifdefs was just about cosmetics. But, it keeps the changes (and possible performance impacts when not using USE_WX_GRAPHICS_CONTEXT) to OSX only. However, a “clean” integration of the wxGraphicsContext stuff would mean b

Re: [Kicad-developers] OS X drawing performance improvements

Is this patch ready to be committed? On 1/4/2016 11:12 AM, Bernhard Stegmaier wrote: > It adds some #ifdefs for not compiling the wxGraphicsContext stuff at all > when USE_WX_GRAPHICS_CONTEXT isn’t in use. > If you hate #ifdefs, this also could be dropped but then it will always check > if wxGra

Re: [Kicad-developers] Boost build removed.

On 1/3/2016 4:27 PM, culli...@rocketmail.com wrote: > Hi, Wayne! > > On 2016-01-03 21:36, Wayne Stambaugh wrote: >> I just committed removing the Boost library dependency (yeah) build >> so this will impact anyone who is still using it. You will now have to >> either install Boost 1.54 or la

[Kicad-developers] OS X drawing performance improvements

Hi, I got some promising feedback to my previous experimentals (thanks to Chris, Adam, and all others who tested behind the scenes!). So here it goes, attached the patch. OS X: Optimize drawing of grid, polygons, and line arrays in the legacy canvases using wxGraphicsContext. Note 1: The patch

[Kicad-developers] Fwd: Re: Build failed in Jenkins: KiCad (Linux, all options, Debug) #998

I've already rolled back the Cairo version to 1.8.8. I leave it as is unless there is a good reason to change it. I'm not familiar enough with Cairo to know what advantages a new version would give us. Forwarded Message Subject: Re: [Kicad-developers] Build failed in Jenkins: K

Re: [Kicad-developers] support of 3D model plugins

and also I would suggest to check the compatibility with VRML format coming from FreeCAD as it is fully compatible in the stable release... A lot of users are already using FreeCAD as 3D modeler both for VRML and MCAD models. On 04/01/2016 14.20, Wayne Stambaugh wrote: I agree. At a minimum,

[Kicad-developers] Jenkins build is back to normal : KiCad (Linux, all options, Debug) #1002

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

Re: [Kicad-developers] Linux dependencies for building from source

Makes sense. There is already a link to the Developer's Documentation on the website so everything should be good to go. Thanks, Wayne On 1/4/2016 9:49 AM, Mark Roszko wrote: > Yea I was going to trash the website copy of instructions. It's too > much of a pita to maintain separately. > > On M

Re: [Kicad-developers] OS X drawing performance

(This is working for me.) Good work! On Sun, Jan 3, 2016 at 3:48 PM, Chris Pavlina wrote: > We're still going back and forth privately with small tweaks, hold on a > bit :) > > > On Sun, Jan 03, 2016 at 04:46:55PM -0500, Wayne Stambaugh wrote: > > I'm willing to commit it if the osx devs are co

Re: [Kicad-developers] Linux dependencies for building from source

Yea I was going to trash the website copy of instructions. It's too much of a pita to maintain separately. On Mon, Jan 4, 2016 at 8:32 AM, Wayne Stambaugh wrote: > > > On 1/4/2016 5:14 AM, David Godfrey wrote: >> >> Hi Tom, Maciej >> >> On 04/01/16 17:47, Maciej Sumiński wrote: >>> Hi Tom, >> >>>

[Kicad-developers] Build failed in Jenkins: KiCad (Linux, all options, Debug) #1001

See Changes: [Maciej Suminski] Merged lp:~xzcvczx/kicad/page-settings_datetime. -- Started by an SCM change Building on master in workspace $ bzr revision-in

Re: [Kicad-developers] Changing the CMAKE_BUILD_TYPE flag

RelWithDebInfo is a nice compromise and would make backtrace information from user bug reports less useless. On Jan 4, 2016 09:06, "Wayne Stambaugh" wrote: > I would rather not. Most if not all projects I've ever work with the > release build was the default not the debug build. Enabling debugg

Re: [Kicad-developers] KiCad Coroutines

>My offer would be to test an alternative implementation, to drop another Boost >dependency and build upon a standard library foundation. >pthreads is not standard library <.< C+11 threads are standard library not pthreads ^^ Ideal implementation is in a way that can be swapped for the C++11 vari

Re: [Kicad-developers] Changing the CMAKE_BUILD_TYPE flag

I would rather not. Most if not all projects I've ever work with the release build was the default not the debug build. Enabling debugging is almost universally left to the developer. If we change this, my guess is all of our package builders would be creating debug builds which is not what we w

Re: [Kicad-developers] KiCad Coroutines

On 1/4/2016 7:08 AM, jp charras wrote: > Le 04/01/2016 10:59, "Torsten Hüter" a écrit : >> Mark, >> You're right Pthreads should eventually work on Windows/MinGW too. >> I don't know if their policy has changed, but the official documentation >> lists >> still MASM as requirement for Windows. I d

Re: [Kicad-developers] Linux dependencies for building from source

On 1/4/2016 5:14 AM, David Godfrey wrote: > > Hi Tom, Maciej > > On 04/01/16 17:47, Maciej Sumiński wrote: >> Hi Tom, > >> Thank you for noticing, a pull request to correct this has already been >> sent. > >> BTW: I have just noticed we keep two documents describing the compiling >> process -

Re: [Kicad-developers] support of 3D model plugins

I agree. At a minimum, we should support the file formats that were supported before the refactor. There may not be many folks using X3D but the few that are will not expect their X3D models to stop working. We should always strive to maintain backwards compatibility. On 1/4/2016 3:55 AM, Mário

Re: [Kicad-developers] KiCad Coroutines

Le 04/01/2016 10:59, "Torsten Hüter" a écrit : > Mark, > You're right Pthreads should eventually work on Windows/MinGW too. > I don't know if their policy has changed, but the official documentation > lists > still MASM as requirement for Windows. I did no further research about the > reasons. >

Re: [Kicad-developers] Linux dependencies for building from source

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tom, Maciej On 04/01/16 17:47, Maciej Sumiński wrote: > Hi Tom, > > Thank you for noticing, a pull request to correct this has already been > sent. > > BTW: I have just not

Re: [Kicad-developers] KiCad Coroutines

Mark,   You're right Pthreads should eventually work on Windows/MinGW too.   I don't know if their policy has changed, but the official documentation lists still MASM as requirement for Windows. I did no further research about the reasons.   Please read the (old) statement of our project lea

Re: [Kicad-developers] Linux dependencies for building from source

Hi Tom, Thank you for noticing, a pull request to correct this has already been sent. BTW: I have just noticed we keep two documents describing the compiling process - on the website and in the source repository (Documentation/development/compiling.md). How about getting rid of the latter one? R

Re: [Kicad-developers] Changing the CMAKE_BUILD_TYPE flag

Hi, On 04.01.2016 04:50, Jon Neal wrote: > Is there any chance that the CMAKE_BUILD_TYPE flag could be changed from > Product to Debug by default? It is the only flag I have to include when > I run cmake now and I often forget to set it. The goal is to make it easy for the people who want to ins

Re: [Kicad-developers] support of 3D model plugins

Hi all, As Bernhard pointed, when I added VRML1 support it was mainly because of the 3D content central website. Overall I think we should try to not make regressions and support at least the same as it was before, otherwise people will not be able to see their projects as it was before. X3D i