Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

Just rotate them first, then place. We don't need specific tools for every conceivable permutation of movements. Unless even more people come in saying they need this, or Wayne overrides me... I still don't think this needs to stay. On Apr 13, 2016 02:16, "David Godfrey" wrote:

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

On 13.04.2016 11:35, Chris Pavlina wrote: > Just rotate them first, then place. We don't need specific tools for > every conceivable permutation of movements. Unless even more people come > in saying they need this, or Wayne overrides me... I still don't think > this needs to stay. Hi Chris,

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

Le 13/04/2016 09:47, Clemens Koller a écrit : > Hello, There! > > I didn't use that functionality in KiCad, but in my other designtool I ran > into > the following case: > > - There is a finished design X. > > - The footprint library envolves over a year and lots of footprints > get migrated

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

Le 13/04/2016 02:53, Chris Pavlina a écrit : > GAL already has this. Block or multi select, Ctrl-M for "move exactly" (or use > the context menu), and type an angle. Just rotates the whole selection, then > you can place your rotated resistors. > > Considering legacy is on its way out, I'd rather

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

Hello, There! I didn't use that functionality in KiCad, but in my other designtool I ran into the following case: - There is a finished design X. - The footprint library envolves over a year and lots of footprints get migrated in it's zero orientation from pin 1 is on lower left to pin 1 is on

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

Yup, this is the way to do it. A generic tool for doing all of these sort of batch edit ops, not a specific "orient all footprints" tool. On Apr 13, 2016 05:42, "Tomasz Wlostowski" wrote: > On 13.04.2016 11:35, Chris Pavlina wrote: > > Just rotate them first, then

Re: [Kicad-developers] Silk on pads

Yeah, Peter, this suggestion is not to remove the possibility to have the silk, just to not enable the silk on through holes by default, which rarely makes sense anyway. I have been wondering about this default option many times and always find myself correcting the footprint when I realize that

Re: [Kicad-developers] [PATCH] Logic reformulation in Plot_Edges_Modules

On Tue, Apr 12, 2016 at 09:16:00PM +, Pereira, Patrick wrote: > Hi, > > Corrections to avoid unnecessary boolean operations > !(!a || !b) = a || b You just insulted DeMorgan :D Hope the code is better -- Lorenzo Marcantonio CZ Srl - Parma signature.asc Description: PGP signature

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

Hi Chris, A rotation of the selection is not the same as a rotation of the individual components. Consider you already have the components roughly in a grid, and you need to rotate them by 20 degrees. Rotating the selection means you have to do major repositioning of every component to get them

Re: [Kicad-developers] recent DXF fixes and KiCad Stable

I believe I did. Take a look at the commit log for the 4.0 branch at: http://bazaar.launchpad.net/~stambaughw/kicad/4.0/changes/6261?start_revid=6261 I see a few commits with your name since the 4.0.2 release so I'm guessing that they are the patches you are talking about. Please let me know

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

Since we have enough alternative methods for rotating a block of footprints, I don't think removing this is going to be much of a burden on anyone. On 4/13/2016 5:35 AM, Chris Pavlina wrote: > Just rotate them first, then place. We don't need specific tools for > every conceivable permutation of

Re: [Kicad-developers] Silk on pads

Yeah, as a mundane user, I also vote for default silk on pad off. Marcos On Wed, Apr 13, 2016 at 7:24 AM, Nick Østergaard wrote: > Yeah, Peter, this suggestion is not to remove the possibility to have > the silk, just to not enable the silk on through holes by default, >

Re: [Kicad-developers] Silk on pads

On Wed, Apr 13, 2016 at 07:56:14AM -0300, Marcos Chaparro wrote: > Yeah, as a mundane user, I also vote for default silk on pad off. It's harmless anyway since 99% of the time the silk will be removed where there is not solder mask (either during plotting or during fabrication). Still I have

[Kicad-developers] RES: [PATCH] Logic reformulation in Plot_Edges_Modules

Ops, sorry for my inattention. Correction in attachment. De: Kicad-developers [kicad-developers-bounces+patrick.pereira=intel@lists.launchpad.net] em nome de Lorenzo Marcantonio [l.marcanto...@cz-dynamic.it] Enviado: quarta-feira, 13 de abril de

Re: [Kicad-developers] dyn_cast

On 13.04.2016 18:38, Chris Pavlina wrote: > I would argue - quite strongly! - that it doesn't matter if it's faster in an > isolated test if it isn't used enough to actually affect the overall code > speed. Was this ever profiled in situ? This sort of thing just causes > headaches > when people

Re: [Kicad-developers] dyn_cast

On 13.04.2016 18:19, Simon Richter wrote: > Hi, > > On 13.04.2016 18:13, Chris Pavlina wrote: > >> What is the purpose of dyn_cast<> in include/core/typeinfo.h? Why don't we >> just >> use dynamic_cast<>? And can we either replace the former with the latter, or >> add a comment to the former

[Kicad-developers] dyn_cast

What is the purpose of dyn_cast<> in include/core/typeinfo.h? Why don't we just use dynamic_cast<>? And can we either replace the former with the latter, or add a comment to the former explaining its purpose? Looks like an optimization for speed, but has anyone actually profiled and found

Re: [Kicad-developers] RES: [PATCH] Logic reformulation in Plot_Edges_Modules

I agree. I'm against committing this simply because I think it doesn't add anything, though I do see the intent behind it. On Wed, Apr 13, 2016 at 11:03:45AM -0500, José Ignacio wrote: > Looking at the change in context, it might be a slight improvement in > readability, using a positive vs a

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

The response on the forum has also been an overwhelming "rip it out". On Wed, Apr 13, 2016 at 08:25:48AM -0400, Wayne Stambaugh wrote: > Since we have enough alternative methods for rotating a block of > footprints, I don't think removing this is going to be much of a burden > on anyone. > > On

Re: [Kicad-developers] RES: [PATCH] Logic reformulation in Plot_Edges_Modules

Looking at the change in context, it might be a slight improvement in readability, using a positive vs a double negative, it's still mostly a no-op though. that logic is so simple it shouldn't be confusing either way when read in context. On Wed, Apr 13, 2016 at 9:53 AM, Pereira, Patrick

Re: [Kicad-developers] dyn_cast

I would argue - quite strongly! - that it doesn't matter if it's faster in an isolated test if it isn't used enough to actually affect the overall code speed. Was this ever profiled in situ? This sort of thing just causes headaches when people misunderstand the usage and subtleties of the more

Re: [Kicad-developers] 3D file relative paths

Hi, On 13.04.2016 02:40, David Godfrey wrote: > The use of Env Vars is the only sensible and portable method that can be > used. From a distribution point of view: this is unusable. We need to ship something that can be started from a desktop icon, without extra setup, and users need to be able

Re: [Kicad-developers] 3D file relative paths

On 4/13/2016 12:04 PM, Simon Richter wrote: > Hi, > > On 13.04.2016 02:40, David Godfrey wrote: > >> The use of Env Vars is the only sensible and portable method that can be >> used. > > From a distribution point of view: this is unusable. We need to ship > something that can be started from a

Re: [Kicad-developers] dyn_cast

Hi, On 13.04.2016 18:13, Chris Pavlina wrote: > What is the purpose of dyn_cast<> in include/core/typeinfo.h? Why don't we > just > use dynamic_cast<>? And can we either replace the former with the latter, or > add a comment to the former explaining its purpose? It uses the parallel type

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

You can achieve exactly this with the move exact and array tools. 2016-04-13 8:16 GMT+02:00 David Godfrey : > Hi Chris, > > A rotation of the selection is not the same as a rotation of the > individual components. > Consider you already have the components roughly in a grid, and

[Kicad-developers] KiCad daily PPA for Trusty not building

Hi, I have tried to contact PPA maintainer but I have not received any response. Maybe someone here has relationship with js-reynaud so the build error can be fixed. Iñigo.___ Mailing list: https://launchpad.net/~kicad-developers Post to :

Re: [Kicad-developers] dyn_cast

Please proceed with caution. I don't have any issue with renaming it to make the intent clear but thorough real world testing should be done before changing over to dynamic_cast<>. On 4/13/2016 12:42 PM, Tomasz Wlostowski wrote: > On 13.04.2016 18:38, Chris Pavlina wrote: >> I would argue -

Re: [Kicad-developers] dyn_cast

I'm just going to rename it. I think the optimization was probably unnecessary, but if it works fine, the only thing it hurts is maintainability, which can be fixed somewhat by naming it something more obvious. No need to risk introducing bugs unnecessarily. Of course personally I'd like to see

Re: [Kicad-developers] Silk on pads

On 4/13/2016 8:03 AM, Lorenzo Marcantonio wrote: > On Wed, Apr 13, 2016 at 07:56:14AM -0300, Marcos Chaparro wrote: >> Yeah, as a mundane user, I also vote for default silk on pad off. > > It's harmless anyway since 99% of the time the silk will be removed > where there is not solder mask (either

Re: [Kicad-developers] recent DXF fixes and KiCad Stable

Thanks Wayne, they are indeed there. - Cirilo On Wed, Apr 13, 2016 at 10:23 PM, Wayne Stambaugh wrote: > I believe I did. Take a look at the commit log for the 4.0 branch at: > > > http://bazaar.launchpad.net/~stambaughw/kicad/4.0/changes/6261?start_revid=6261 > > I see

[Kicad-developers] DXF import behavior

Hi folks, 1. Some users have commented about the DXF Import UI showing "a disabled Units dropdown". The dropdown with the text "Units" is in fact the grid offset unit but some users are being confused and thinking it is the DXF units. Even I was confused and I added that UI item and its help

Re: [Kicad-developers] 3D file relative paths

I agree there should be no Debian policy violation here. I was unaware of the "Configure Paths" scheme for defining environment variables though. I'll look at the docs and see if there is any mention of using the configured paths with 3D models. I propose to make the following improvements to the