[Kicad-developers] DXF import behavior

[Cirilo Bernardo]

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 text. Perhaps I should rename it to
"Offset Units" or even "Grid Offset Units"?

2. Some DXF files in the wild do not specify a unit. The old behavior
was to interpret *all* files as having a design unit of mm and the
new behavior is to interpret files without a unit as mm. This
behavior may not be correct.  Should I add a "Default DXF Unit"
dropdown with a number of supported and commonly used units?
In the vast majority of cases the dropdown will not be necessary
since DXF files tend to have the unit specified, but there may be
users who frequently encounter unitless DXF files.

Any comments/suggestions?

- Cirilo
___
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] 3D file relative paths

[Cirilo Bernardo]

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 3D resolver code:

1. Environment var paths defined by kicad should be added to the
drop-down list for model selection. The list should probably be culled
with a simplistic check - anything with "://" in the name will not be
added (at least not until we have developed some scheme for
retrieving these files) and paths which end in "template{/}" will not
be added. Other paths may or may not correspond to model directories
but typically not many paths are defined so I think the benefits for
ease of browsing outweigh the nuisance of extra paths in the list.

2. Environment paths will have precedence over alias paths when a
filename is shortened. The use of ENV_VAR is compatible with
earlier versions of kicad while the use of aliases is not. While there
has technically been no change in the file format structure, the use
of aliases has essentially introduced a file format change (I didn't
really realize this before).

3. For compatibility with earlier versions, files within the current
working directory will be prefixed with ${KIPRJMOD}. Currently
such files do not have a prefix at all, they are simply partial
paths which must be resolved relative to the project directory,
which breaks compatibility with earlier versions.

Items 1-3 raise the question: is there any benefit in keeping the
alias scheme at all or would it be better to drop it and use
${ENV_PATH} definitions instead? I have no great attachment to
the scheme since it's only a minor part of the 3D refactor. On the
one hand we can argue against breaking compatibility with
earlier versions, but on the other hand we can argue that the
previous behavior is somewhat cumbersome and should be
supplanted.

One outstanding item to resolve:
Some users would like to specify 3D files relative to the current
project directory; with the current behavior of the resolver, any paths
which are not a descendant of an alias path are converted into
an absolute path. Should I provide a switch to decide between
absolute and relative to current project? In this particular instance
I can't think of a strong argument to allow relative paths since that
would cause a nightmare if a project directory is moved in the
filesystem. On the other hand do we really want to tell users
"use sed to convert to relative paths before you send a project to
another team member".

- Cirilo

On Thu, Apr 14, 2016 at 3:16 AM, Wayne Stambaugh 
wrote:

> 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 desktop icon, without extra setup,
> > and users need to be able to configure everything from the UI, because
> > we cannot expect them to learn how environment variables are set this
> week.
> >
> > Debian policy explicitly forbids this, for a reason.
> >
> >Simon
>
> No system or user level environment variables need to be set so there
> should be no Debian policy violation.  All environment variables are
> user configurable with kicad, are set per process, and have platform
> specific defaults that work for clean installs.  System and user level
> environment variables can be used at the discretion of the user but are
> not required.
>
> >
> >
> >
> > ___
> > 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] recent DXF fixes and KiCad Stable

[Cirilo Bernardo]

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 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 if I missed them and I will back port them to the 4.0 branch.
>
> Once Chris gets the board file version code committed, I'll back port
> that and push a 4.0.3 release.
>
> On 4/13/2016 12:55 AM, Cirilo Bernardo wrote:
> > Somewhat recently I submitted 2 patches to fix various issues
> > with DXF files and would just like some feedback on whether
> > or not those changes will be backported to KiCad Stable:
> >
> > https://lists.launchpad.net/kicad-developers/msg23849.html
> > https://lists.launchpad.net/kicad-developers/msg23852.html
> >
> > The first patch corrected the interpretation of LWPolyline
> > entities and added correct support of the Units flag. The
> > patch is small enough and I believe the issues fixed are
> > significant enough to backport this to Stable. The patch
> > unfortunately will not quite apply cleanly since it undoes
> > some misguided changes made in r6630. I'm aware of at
> > least 2 users who are using KiCad Stable and suffer
> > because of the issues which this patch addresses.
> >
> > The second patch adds LWPolyline support and correct
> > Units support to the dxf2idf tool.  The patch is small and
> > will apply cleanly so I think it should go in on the principle
> > that it fixes some bugs; in reality I don't know if anyone
> > uses that tool at all - I get very little feedback from the
> > handful of users who *do* use the IDF exporter and related
> > tools.
> >
> > - Cirilo
> >
>
___
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] dyn_cast

[Chris Pavlina]

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 the parallel type system in EDA_ITEM
disappear entirely, as duplication of information is always error-prone... but
no need to remove this outside of an attempt to purge that. ;)

On Wed, Apr 13, 2016 at 04:21:56PM -0400, Wayne Stambaugh wrote:
> 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 - 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 limited
> >> "optimized" replacement. I find it hard to believe that we call 
> >> dynamic_cast
> >> enough for it to be a performance issue.
> > 
> > Perhaps you're right, I'm not going to argue here.
> > 
> >>
> >> Also - *please* let me rename it. dynamic_cast vs dyn_cast is almost the
> >> _textboox_ example of poor naming. It's absolutely 100% non-obvious to 
> >> someone
> >> reading code using the latter _why_ it was chosen, what its advantage is 
> >> over
> >> the normal one, and whether it has any subtle issues that can cause bugs. 
> >> At
> >> least it should be called something like dynamic_cast_fast so there's
> >> justification for its use in the actual code using it.
> > 
> > Go on with the renaming.
> > 
> > Tom
> > 
> >>
> >> On Wed, Apr 13, 2016 at 06:34:28PM +0200, Tomasz Wlostowski wrote:
> >>> 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 explaining its purpose?
> 
>  It uses the parallel type system in EDA_ITEM rather than RTTI, so it
>  works if RTTI is broken, e.g. when compiling with gcc 2.95.
> 
> >>>
> >>> I wrote it inspired with Clang/LLVM design which uses a very similar
> >>> pattern. Sorry Simon, I didn't consider compatibility with gcc 2.95
> >>> would be of an advantage. My reasons were:
> >>>
> >>> 1) Much faster (code in the attachment):
> >>> - dynamic_cast<> : 9090437 usecs
> >>> - dyn_cast<> : 1832433 usecs (5x improvement)
> >>>
> >>> 2) Lightweight & compatible with existing Kicad type system.
> >>>
> >>> 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] dyn_cast

[Wayne Stambaugh]

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 - 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 limited
>> "optimized" replacement. I find it hard to believe that we call dynamic_cast
>> enough for it to be a performance issue.
> 
> Perhaps you're right, I'm not going to argue here.
> 
>>
>> Also - *please* let me rename it. dynamic_cast vs dyn_cast is almost the
>> _textboox_ example of poor naming. It's absolutely 100% non-obvious to 
>> someone
>> reading code using the latter _why_ it was chosen, what its advantage is over
>> the normal one, and whether it has any subtle issues that can cause bugs. At
>> least it should be called something like dynamic_cast_fast so there's
>> justification for its use in the actual code using it.
> 
> Go on with the renaming.
> 
> Tom
> 
>>
>> On Wed, Apr 13, 2016 at 06:34:28PM +0200, Tomasz Wlostowski wrote:
>>> 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 explaining its purpose?

 It uses the parallel type system in EDA_ITEM rather than RTTI, so it
 works if RTTI is broken, e.g. when compiling with gcc 2.95.

>>>
>>> I wrote it inspired with Clang/LLVM design which uses a very similar
>>> pattern. Sorry Simon, I didn't consider compatibility with gcc 2.95
>>> would be of an advantage. My reasons were:
>>>
>>> 1) Much faster (code in the attachment):
>>> - dynamic_cast<> : 9090437 usecs
>>> - dyn_cast<> : 1832433 usecs (5x improvement)
>>>
>>> 2) Lightweight & compatible with existing Kicad type system.
>>>
>>> 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] Silk on pads

[Wayne Stambaugh]

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 during plotting or during
> fabrication).
> 
> Still I have disabled it in my version!

I would prefer it to be disabled by default.  I can't remember how many
times I've forgot to disable it and had to go back an fix it.

> 
> 
> 
> ___
> 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] 3D file relative paths

[Wayne Stambaugh]

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 desktop icon, without extra setup,
> and users need to be able to configure everything from the UI, because
> we cannot expect them to learn how environment variables are set this week.
> 
> Debian policy explicitly forbids this, for a reason.
> 
>Simon

No system or user level environment variables need to be set so there
should be no Debian policy violation.  All environment variables are
user configurable with kicad, are set per process, and have platform
specific defaults that work for clean installs.  System and user level
environment variables can be used at the discretion of the user but are
not required.

> 
> 
> 
> ___
> 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] dyn_cast

[Tomasz Wlostowski]

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 misunderstand the usage and subtleties of the more limited
> "optimized" replacement. I find it hard to believe that we call dynamic_cast
> enough for it to be a performance issue.

Perhaps you're right, I'm not going to argue here.

>
> Also - *please* let me rename it. dynamic_cast vs dyn_cast is almost the
> _textboox_ example of poor naming. It's absolutely 100% non-obvious to someone
> reading code using the latter _why_ it was chosen, what its advantage is over
> the normal one, and whether it has any subtle issues that can cause bugs. At
> least it should be called something like dynamic_cast_fast so there's
> justification for its use in the actual code using it.

Go on with the renaming.

Tom

> 
> On Wed, Apr 13, 2016 at 06:34:28PM +0200, Tomasz Wlostowski wrote:
>> 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 explaining its purpose?
>>>
>>> It uses the parallel type system in EDA_ITEM rather than RTTI, so it
>>> works if RTTI is broken, e.g. when compiling with gcc 2.95.
>>>
>>
>> I wrote it inspired with Clang/LLVM design which uses a very similar
>> pattern. Sorry Simon, I didn't consider compatibility with gcc 2.95
>> would be of an advantage. My reasons were:
>>
>> 1) Much faster (code in the attachment):
>> - dynamic_cast<> : 9090437 usecs
>> - dyn_cast<> : 1832433 usecs (5x improvement)
>>
>> 2) Lightweight & compatible with existing Kicad type system.
>>
>> 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] dyn_cast

[Chris Pavlina]

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 limited
"optimized" replacement. I find it hard to believe that we call dynamic_cast
enough for it to be a performance issue.

Also - *please* let me rename it. dynamic_cast vs dyn_cast is almost the
_textboox_ example of poor naming. It's absolutely 100% non-obvious to someone
reading code using the latter _why_ it was chosen, what its advantage is over
the normal one, and whether it has any subtle issues that can cause bugs. At
least it should be called something like dynamic_cast_fast so there's
justification for its use in the actual code using it.

On Wed, Apr 13, 2016 at 06:34:28PM +0200, Tomasz Wlostowski wrote:
> 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 explaining its purpose?
> > 
> > It uses the parallel type system in EDA_ITEM rather than RTTI, so it
> > works if RTTI is broken, e.g. when compiling with gcc 2.95.
> > 
> 
> I wrote it inspired with Clang/LLVM design which uses a very similar
> pattern. Sorry Simon, I didn't consider compatibility with gcc 2.95
> would be of an advantage. My reasons were:
> 
> 1) Much faster (code in the attachment):
> - dynamic_cast<> : 9090437 usecs
> - dyn_cast<> : 1832433 usecs (5x improvement)
> 
> 2) Lightweight & compatible with existing Kicad type system.
> 
> 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] dyn_cast

[Tomasz Wlostowski]

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 explaining its purpose?
> 
> It uses the parallel type system in EDA_ITEM rather than RTTI, so it
> works if RTTI is broken, e.g. when compiling with gcc 2.95.
> 

I wrote it inspired with Clang/LLVM design which uses a very similar
pattern. Sorry Simon, I didn't consider compatibility with gcc 2.95
would be of an advantage. My reasons were:

1) Much faster (code in the attachment):
- dynamic_cast<> : 9090437 usecs
- dyn_cast<> : 1832433 usecs (5x improvement)

2) Lightweight & compatible with existing Kicad type system.

Cheers,
Tom
#include 

#include "profile.h"
#include "typeinfo.h"

const int n_iter = 10;

const int id_base = 0;
const int id_derived = 1;


class Base {
public:
Base()
{
	m_type = id_base;
}

virtual ~Base() {};

static inline bool ClassOf( const Base* aItem )
{
return aItem && id_base == aItem->Type();
}

int Type() const
{
	return m_type;
}


protected:
int m_type;
int m_count;
};

class Derived : public Base {
public:
static inline bool ClassOf( const Base* aItem )
{
return aItem && id_derived == aItem->Type();
}

Derived()
{
	m_type = id_derived;
}

void DoSomething()
{
	m_count++;
}

};

main()
{
Base *b = new Derived();

prof_counter cnt;

prof_start();

for(int i = 0; i  (b);
	d->DoSomething();
}
prof_end();

printf("dynamic_cast<> : %d usecs\n", cnt.usecs());

prof_start();


for(int i = 0; i (b);
	d->DoSomething();
}

prof_end();
printf("dyn_cast<> : %d usecs\n", cnt.usecs());

}
___
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] DIALOG_ORIENT_FOOTPRINTS

[Chris Pavlina]

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 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 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:
> > 
> > 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 back in the correct area.
> > 
> > However rotating the components within the selection means they are
> > still in about the right position, so only minor placement adjustments
> > are required.
> > These minor adjustments can likely be made using the align and
> > distribute tools
> > 
> > I Agree half-implemented features are bad, better to update them and
> > properly implement.
> > 
> > Regards
> > David G
> > 
> > On 13/04/16 08:53, Chris Pavlina wrote:
> > > 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 not keep crusty old
> > > half-implemented legacy features around to require maintenance.
> > >
> > >
> > > On Wed, Apr 13, 2016 at 08:50:38AM +0800, David Godfrey wrote:
> > >> Hmm,
> > >>
> > >> I'v not used it on Kicad but the ability to change the
> > orientation of an
> > >> arbitrary selection of footprints is something I've used many
> > times in
> > >> Altium.
> > >>
> > >> Ideally you want to be able to set an absolute orientation, and
> > also a
> > >> relative (to current) angle adjustment.
> > >>
> > >> This is especially useful when designing boards like LED matrices and
> > >> wanting to put all resisters on a specific angle (eg: 21.3deg).
> > >> You can then do an array alignment with the same outer limit you used
> > >> for your LED alignment.
> > >> Then move the group of resistors into position relative to the LED's.
> > >>
> > >> Now running your tracks becomes trivial.
> > >>
> > >> Without the ability to auto adjust the orientation on a selection of
> > >> parts the job becomes long and tedious.
> > >> Some of the PCB's I've done this on have over 1000 LED's and
> > resistors,
> > >> and generally you need to orient both the resistors and the LED's
> > >>
> > >> So in summary, I'd like to keep the ability to do this, but on a
> > >> selection instead of globally.
> > >> And being able to alter it as an absolute angle, or as a relative to
> > >> current (prefix the new angle with + or - to get relative movement)
> > >> would be beneficial.
> > >>
> > >> Regards
> > >> David G
> > >>
> > >> On 13/04/16 06:40, Chris Pavlina wrote:
> > >>> I wonder how many of you are even aware of
> > DIALOG_ORIENT_FOOTPRINTS. It's
> > >>> hidden in the Secret Menu in pcbnew (the spread-and-place) one,
> > menu item
> > >>> Orient All Footprints. The code hasn't been touched since 2010
> > except a few
> > >>> cleanups, and it seems really simplistic and useless to me. I
> > was going to
> > >>> upgrade it to floating-point angle entry like everything else,
> > but
> > >>>
> > >>> Does _anybody_ even use this? It seems utterly useless. I have
> > no idea when
> > >>> you'd want to globally apply an orientation to footprints. Can I
> > just tear it
> > >>> out?  :P
> > >>>
> > >>
> > >>
> > >> ___
> > >> 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] dyn_cast

[Simon Richter]

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 system in EDA_ITEM rather than RTTI, so it
works if RTTI is broken, e.g. when compiling with gcc 2.95.

I believe this should go.

   Simon




signature.asc
Description: OpenPGP digital signature
___
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] dyn_cast

[Chris Pavlina]

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 dynamic_cast to be a bottleneck? It's not exactly heavy.

/**
 * Function dyn_cast()
 *
 * A lightweight dynamic downcast. Casts aObject to type Casted*.
 * Uses EDA_ITEM::Type() and EDA_ITEM::ClassOf() to check if type matches.
 * @param aObject object to be casted
 * @return down-casted object or NULL if type doesn't match Casted.
 */
template
Casted dyn_cast( From aObject )
{
if( remove_pointer::type::ClassOf ( aObject ) )
return static_cast( aObject );

return NULL;
}

-- 
Chris


___
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] RES: [PATCH] Logic reformulation in Plot_Edges_Modules

[Chris Pavlina]

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 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
>  wrote:
> > 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 2016 3:19
> > Para: Kicad Developers
> > Assunto: 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
> >
> > ___
> > 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] 3D file relative paths

[Simon Richter]

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 to configure everything from the UI, because
we cannot expect them to learn how environment variables are set this week.

Debian policy explicitly forbids this, for a reason.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] RES: [PATCH] Logic reformulation in Plot_Edges_Modules

[José Ignacio]

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
 wrote:
> 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 2016 3:19
> Para: Kicad Developers
> Assunto: 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
>
> ___
> 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] RES: [PATCH] Logic reformulation in Plot_Edges_Modules

[Pereira, Patrick]

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 2016 3:19
Para: Kicad Developers
Assunto: 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 - ParmaFrom 5b4238d5aca1f26d977463e999295ea944f081b2 Mon Sep 17 00:00:00 2001
From: "Patrick J.P" 
Date: Tue, 12 Apr 2016 18:08:49 -0300
Subject: [PATCH 1/1] Logic reformulation in Plot_Edges_Modules

Corrections to avoid unnecessary boolean operations
!(!a || !b) = a && b

+---+---+-++
| A | B | !(!A || !B) | A && B |
+---+---+-++
| 0 | 0 |  0  |0   |
+---+---+-++
| 0 | 1 |  0  |0   |
+---+---+-++
| 1 | 0 |  0  |0   |
+---+---+-++
| 1 | 1 |  1  |1   |
+---+---+-++

Signed-off-by: Patrick J.P 
---
 pcbnew/plot_brditems_plotter.cpp | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/pcbnew/plot_brditems_plotter.cpp b/pcbnew/plot_brditems_plotter.cpp
index e9d82c3..4634c39 100644
--- a/pcbnew/plot_brditems_plotter.cpp
+++ b/pcbnew/plot_brditems_plotter.cpp
@@ -354,10 +354,8 @@ void BRDITEMS_PLOTTER::Plot_Edges_Modules()
 {
 EDGE_MODULE* edge = dyn_cast( item );
 
-if( !edge || !m_layerMask[edge->GetLayer()] )
-continue;
-
-Plot_1_EdgeModule( edge );
+if( edge && m_layerMask[edge->GetLayer()] )
+Plot_1_EdgeModule( edge );
 }
 }
 }
-- 
2.8.0

___
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] KiCad daily PPA for Trusty not building

[Iñigo]

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 : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

[Nick Østergaard]

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 you need
> to rotate them by 20 degrees.
> Rotating the selection means you have to do major repositioning of every
> component to get them back in the correct area.
>
> However rotating the components within the selection means they are
> still in about the right position, so only minor placement adjustments
> are required.
> These minor adjustments can likely be made using the align and
> distribute tools
>
> I Agree half-implemented features are bad, better to update them and
> properly implement.
>
> Regards
> David G
>
> On 13/04/16 08:53, Chris Pavlina wrote:
>> 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 not keep crusty old
>> half-implemented legacy features around to require maintenance.
>>
>>
>> On Wed, Apr 13, 2016 at 08:50:38AM +0800, David Godfrey wrote:
>>> Hmm,
>>>
>>> I'v not used it on Kicad but the ability to change the orientation of an
>>> arbitrary selection of footprints is something I've used many times in
>>> Altium.
>>>
>>> Ideally you want to be able to set an absolute orientation, and also a
>>> relative (to current) angle adjustment.
>>>
>>> This is especially useful when designing boards like LED matrices and
>>> wanting to put all resisters on a specific angle (eg: 21.3deg).
>>> You can then do an array alignment with the same outer limit you used
>>> for your LED alignment.
>>> Then move the group of resistors into position relative to the LED's.
>>>
>>> Now running your tracks becomes trivial.
>>>
>>> Without the ability to auto adjust the orientation on a selection of
>>> parts the job becomes long and tedious.
>>> Some of the PCB's I've done this on have over 1000 LED's and resistors,
>>> and generally you need to orient both the resistors and the LED's
>>>
>>> So in summary, I'd like to keep the ability to do this, but on a
>>> selection instead of globally.
>>> And being able to alter it as an absolute angle, or as a relative to
>>> current (prefix the new angle with + or - to get relative movement)
>>> would be beneficial.
>>>
>>> Regards
>>> David G
>>>
>>> On 13/04/16 06:40, Chris Pavlina wrote:
 I wonder how many of you are even aware of DIALOG_ORIENT_FOOTPRINTS. It's
 hidden in the Secret Menu in pcbnew (the spread-and-place) one, menu item
 Orient All Footprints. The code hasn't been touched since 2010 except a few
 cleanups, and it seems really simplistic and useless to me. I was going to
 upgrade it to floating-point angle entry like everything else, but

 Does _anybody_ even use this? It seems utterly useless. I have no idea when
 you'd want to globally apply an orientation to footprints. Can I just tear 
 it
 out?  :P

>>>
>>>
>>> ___
>>> 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] DIALOG_ORIENT_FOOTPRINTS

[Wayne Stambaugh]

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 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:
> 
> 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 back in the correct area.
> 
> However rotating the components within the selection means they are
> still in about the right position, so only minor placement adjustments
> are required.
> These minor adjustments can likely be made using the align and
> distribute tools
> 
> I Agree half-implemented features are bad, better to update them and
> properly implement.
> 
> Regards
> David G
> 
> On 13/04/16 08:53, Chris Pavlina wrote:
> > 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 not keep crusty old
> > half-implemented legacy features around to require maintenance.
> >
> >
> > On Wed, Apr 13, 2016 at 08:50:38AM +0800, David Godfrey wrote:
> >> Hmm,
> >>
> >> I'v not used it on Kicad but the ability to change the
> orientation of an
> >> arbitrary selection of footprints is something I've used many
> times in
> >> Altium.
> >>
> >> Ideally you want to be able to set an absolute orientation, and
> also a
> >> relative (to current) angle adjustment.
> >>
> >> This is especially useful when designing boards like LED matrices and
> >> wanting to put all resisters on a specific angle (eg: 21.3deg).
> >> You can then do an array alignment with the same outer limit you used
> >> for your LED alignment.
> >> Then move the group of resistors into position relative to the LED's.
> >>
> >> Now running your tracks becomes trivial.
> >>
> >> Without the ability to auto adjust the orientation on a selection of
> >> parts the job becomes long and tedious.
> >> Some of the PCB's I've done this on have over 1000 LED's and
> resistors,
> >> and generally you need to orient both the resistors and the LED's
> >>
> >> So in summary, I'd like to keep the ability to do this, but on a
> >> selection instead of globally.
> >> And being able to alter it as an absolute angle, or as a relative to
> >> current (prefix the new angle with + or - to get relative movement)
> >> would be beneficial.
> >>
> >> Regards
> >> David G
> >>
> >> On 13/04/16 06:40, Chris Pavlina wrote:
> >>> I wonder how many of you are even aware of
> DIALOG_ORIENT_FOOTPRINTS. It's
> >>> hidden in the Secret Menu in pcbnew (the spread-and-place) one,
> menu item
> >>> Orient All Footprints. The code hasn't been touched since 2010
> except a few
> >>> cleanups, and it seems really simplistic and useless to me. I
> was going to
> >>> upgrade it to floating-point angle entry like everything else,
> but
> >>>
> >>> Does _anybody_ even use this? It seems utterly useless. I have
> no idea when
> >>> you'd want to globally apply an orientation to footprints. Can I
> just tear it
> >>> out?  :P
> >>>
> >>
> >>
> >> ___
> >> 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] recent DXF fixes and KiCad Stable

[Wayne Stambaugh]

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 if I missed them and I will back port them to the 4.0 branch.

Once Chris gets the board file version code committed, I'll back port
that and push a 4.0.3 release.

On 4/13/2016 12:55 AM, Cirilo Bernardo wrote:
> Somewhat recently I submitted 2 patches to fix various issues
> with DXF files and would just like some feedback on whether
> or not those changes will be backported to KiCad Stable:
> 
> https://lists.launchpad.net/kicad-developers/msg23849.html
> https://lists.launchpad.net/kicad-developers/msg23852.html
> 
> The first patch corrected the interpretation of LWPolyline
> entities and added correct support of the Units flag. The
> patch is small enough and I believe the issues fixed are
> significant enough to backport this to Stable. The patch
> unfortunately will not quite apply cleanly since it undoes
> some misguided changes made in r6630. I'm aware of at
> least 2 users who are using KiCad Stable and suffer
> because of the issues which this patch addresses.
> 
> The second patch adds LWPolyline support and correct
> Units support to the dxf2idf tool.  The patch is small and
> will apply cleanly so I think it should go in on the principle
> that it fixes some bugs; in reality I don't know if anyone
> uses that tool at all - I get very little feedback from the
> handful of users who *do* use the IDF exporter and related
> tools.
> 
> - Cirilo
> 

___
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] Silk on pads

[Lorenzo Marcantonio]

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 disabled it in my version!

-- 
Lorenzo Marcantonio
CZ Srl - Parma


signature.asc
Description: PGP signature
___
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] Silk on pads

[Marcos Chaparro]

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,
> 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 it is
> enabled, which can become a bit tedious. So I vote for default silk on
> pad off too.
>
> 2016-04-13 1:39 GMT+02:00 Chris Pavlina :
> > Yeah, I can think of edge cases where it might be desirable. I'm just
> having
> > trouble imagining why it would be *default*. You can enable that layer
> manually
> > on these touch pads in this case.
> >
> > On Wed, Apr 13, 2016 at 09:07:16AM +0930, Peter Wintulich wrote:
> >> Hello,
> >> I had been court by this.
> >> There is one scenario where it may be use full, though SMT pads would
> more
> >> likely be used.
> >> This is for touch panels where the solder mask and Silk screen are over
> the
> >> pad area with no exposed metal.
> >>
> >> Regards Peter
> >>
> >> On 13/04/16 08:57, Wayne Stambaugh wrote:
> >> >On 4/12/2016 5:53 PM, Chris Pavlina wrote:
> >> >>Quick question... does anybody know why we are putting silkscreen
> over PTH pads
> >> >>by default? And can we change this? Obviously they shouldn't be
> manufactured
> >> >>this way, so we're depending on either the user to remember to choose
> "Subtract
> >> >>soldermask from silkscreen" or on the fab to do it, both of which
> aren't
> >> >>necessary dependable...
> >> >>
> >> >I would give users and devs a few days to respond and if no one
> >> >complains too loudly go ahead and remove the offending code.
> >> >
> >> >___
> >> >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
> >> >
> >>
> >>
> >> --
> >>
> >> Peter Wintulich
> >>
> >> Voicetronix Pty. Ltd.
> >> Suite 6, Level 1, 977 North East Road,
> >> MODBURY  5092
> >> South Australia
> >> AUSTRALIA
> >> +61 8 8264 2005
> >>
> >>
> >> ___
> >> 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] Silk on pads

[Nick Østergaard]

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 it is
enabled, which can become a bit tedious. So I vote for default silk on
pad off too.

2016-04-13 1:39 GMT+02:00 Chris Pavlina :
> Yeah, I can think of edge cases where it might be desirable. I'm just having
> trouble imagining why it would be *default*. You can enable that layer 
> manually
> on these touch pads in this case.
>
> On Wed, Apr 13, 2016 at 09:07:16AM +0930, Peter Wintulich wrote:
>> Hello,
>> I had been court by this.
>> There is one scenario where it may be use full, though SMT pads would more
>> likely be used.
>> This is for touch panels where the solder mask and Silk screen are over the
>> pad area with no exposed metal.
>>
>> Regards Peter
>>
>> On 13/04/16 08:57, Wayne Stambaugh wrote:
>> >On 4/12/2016 5:53 PM, Chris Pavlina wrote:
>> >>Quick question... does anybody know why we are putting silkscreen over PTH 
>> >>pads
>> >>by default? And can we change this? Obviously they shouldn't be 
>> >>manufactured
>> >>this way, so we're depending on either the user to remember to choose 
>> >>"Subtract
>> >>soldermask from silkscreen" or on the fab to do it, both of which aren't
>> >>necessary dependable...
>> >>
>> >I would give users and devs a few days to respond and if no one
>> >complains too loudly go ahead and remove the offending code.
>> >
>> >___
>> >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
>> >
>>
>>
>> --
>>
>> Peter Wintulich
>>
>> Voicetronix Pty. Ltd.
>> Suite 6, Level 1, 977 North East Road,
>> MODBURY  5092
>> South Australia
>> AUSTRALIA
>> +61 8 8264 2005
>>
>>
>> ___
>> 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] DIALOG_ORIENT_FOOTPRINTS

[Chris Pavlina]

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 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,
>
> There's even a work package in the roadmap (property system & inspector
> tool) for such 'rare' operations. Select a number of items, open a table
> with common properties (e.g. x, y, locked, orientation, size) and set
> the orientation to the desired value.
>
> Cheers,
> Tom
>
>
>
>
> >
> > On Apr 13, 2016 02:16, "David Godfrey"  > > wrote:
> >
> > 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 back in the correct area.
> >
> > However rotating the components within the selection means they are
> > still in about the right position, so only minor placement
> adjustments
> > are required.
> > These minor adjustments can likely be made using the align and
> > distribute tools
> >
> > I Agree half-implemented features are bad, better to update them and
> > properly implement.
> >
> > Regards
> > David G
> >
> > On 13/04/16 08:53, Chris Pavlina wrote:
> > > 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 not keep crusty
> old
> > > half-implemented legacy features around to require maintenance.
> > >
> > >
> > > On Wed, Apr 13, 2016 at 08:50:38AM +0800, David Godfrey wrote:
> > >> Hmm,
> > >>
> > >> I'v not used it on Kicad but the ability to change the
> > orientation of an
> > >> arbitrary selection of footprints is something I've used many
> > times in
> > >> Altium.
> > >>
> > >> Ideally you want to be able to set an absolute orientation, and
> > also a
> > >> relative (to current) angle adjustment.
> > >>
> > >> This is especially useful when designing boards like LED matrices
> and
> > >> wanting to put all resisters on a specific angle (eg: 21.3deg).
> > >> You can then do an array alignment with the same outer limit you
> used
> > >> for your LED alignment.
> > >> Then move the group of resistors into position relative to the
> LED's.
> > >>
> > >> Now running your tracks becomes trivial.
> > >>
> > >> Without the ability to auto adjust the orientation on a selection
> of
> > >> parts the job becomes long and tedious.
> > >> Some of the PCB's I've done this on have over 1000 LED's and
> > resistors,
> > >> and generally you need to orient both the resistors and the LED's
> > >>
> > >> So in summary, I'd like to keep the ability to do this, but on a
> > >> selection instead of globally.
> > >> And being able to alter it as an absolute angle, or as a relative
> to
> > >> current (prefix the new angle with + or - to get relative
> movement)
> > >> would be beneficial.
> > >>
> > >> Regards
> > >> David G
> > >>
> > >> On 13/04/16 06:40, Chris Pavlina wrote:
> > >>> I wonder how many of you are even aware of
> > DIALOG_ORIENT_FOOTPRINTS. It's
> > >>> hidden in the Secret Menu in pcbnew (the spread-and-place) one,
> > menu item
> > >>> Orient All Footprints. The code hasn't been touched since 2010
> > except a few
> > >>> cleanups, and it seems really simplistic and useless to me. I
> > was going to
> > >>> upgrade it to floating-point angle entry like everything else,
> > but
> > >>>
> > >>> Does _anybody_ even use this? It seems utterly useless. I have
> > no idea when
> > >>> you'd want to globally apply an orientation to footprints. Can I
> > just tear it
> > >>> out?  :P
> > >>>
> > >>
> > >>
> > >> ___
> > >> 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] DIALOG_ORIENT_FOOTPRINTS

[Tomasz Wlostowski]

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,

There's even a work package in the roadmap (property system & inspector
tool) for such 'rare' operations. Select a number of items, open a table
with common properties (e.g. x, y, locked, orientation, size) and set
the orientation to the desired value.

Cheers,
Tom




> 
> On Apr 13, 2016 02:16, "David Godfrey"  > wrote:
> 
> 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 back in the correct area.
> 
> However rotating the components within the selection means they are
> still in about the right position, so only minor placement adjustments
> are required.
> These minor adjustments can likely be made using the align and
> distribute tools
> 
> I Agree half-implemented features are bad, better to update them and
> properly implement.
> 
> Regards
> David G
> 
> On 13/04/16 08:53, Chris Pavlina wrote:
> > 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 not keep crusty old
> > half-implemented legacy features around to require maintenance.
> >
> >
> > On Wed, Apr 13, 2016 at 08:50:38AM +0800, David Godfrey wrote:
> >> Hmm,
> >>
> >> I'v not used it on Kicad but the ability to change the
> orientation of an
> >> arbitrary selection of footprints is something I've used many
> times in
> >> Altium.
> >>
> >> Ideally you want to be able to set an absolute orientation, and
> also a
> >> relative (to current) angle adjustment.
> >>
> >> This is especially useful when designing boards like LED matrices and
> >> wanting to put all resisters on a specific angle (eg: 21.3deg).
> >> You can then do an array alignment with the same outer limit you used
> >> for your LED alignment.
> >> Then move the group of resistors into position relative to the LED's.
> >>
> >> Now running your tracks becomes trivial.
> >>
> >> Without the ability to auto adjust the orientation on a selection of
> >> parts the job becomes long and tedious.
> >> Some of the PCB's I've done this on have over 1000 LED's and
> resistors,
> >> and generally you need to orient both the resistors and the LED's
> >>
> >> So in summary, I'd like to keep the ability to do this, but on a
> >> selection instead of globally.
> >> And being able to alter it as an absolute angle, or as a relative to
> >> current (prefix the new angle with + or - to get relative movement)
> >> would be beneficial.
> >>
> >> Regards
> >> David G
> >>
> >> On 13/04/16 06:40, Chris Pavlina wrote:
> >>> I wonder how many of you are even aware of
> DIALOG_ORIENT_FOOTPRINTS. It's
> >>> hidden in the Secret Menu in pcbnew (the spread-and-place) one,
> menu item
> >>> Orient All Footprints. The code hasn't been touched since 2010
> except a few
> >>> cleanups, and it seems really simplistic and useless to me. I
> was going to
> >>> upgrade it to floating-point angle entry like everything else,
> but
> >>>
> >>> Does _anybody_ even use this? It seems utterly useless. I have
> no idea when
> >>> you'd want to globally apply an orientation to footprints. Can I
> just tear it
> >>> out?  :P
> >>>
> >>
> >>
> >> ___
> >> 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   : 

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

[Chris Pavlina]

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:

> 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 back in the correct area.
>
> However rotating the components within the selection means they are
> still in about the right position, so only minor placement adjustments
> are required.
> These minor adjustments can likely be made using the align and
> distribute tools
>
> I Agree half-implemented features are bad, better to update them and
> properly implement.
>
> Regards
> David G
>
> On 13/04/16 08:53, Chris Pavlina wrote:
> > 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 not keep crusty old
> > half-implemented legacy features around to require maintenance.
> >
> >
> > On Wed, Apr 13, 2016 at 08:50:38AM +0800, David Godfrey wrote:
> >> Hmm,
> >>
> >> I'v not used it on Kicad but the ability to change the orientation of an
> >> arbitrary selection of footprints is something I've used many times in
> >> Altium.
> >>
> >> Ideally you want to be able to set an absolute orientation, and also a
> >> relative (to current) angle adjustment.
> >>
> >> This is especially useful when designing boards like LED matrices and
> >> wanting to put all resisters on a specific angle (eg: 21.3deg).
> >> You can then do an array alignment with the same outer limit you used
> >> for your LED alignment.
> >> Then move the group of resistors into position relative to the LED's.
> >>
> >> Now running your tracks becomes trivial.
> >>
> >> Without the ability to auto adjust the orientation on a selection of
> >> parts the job becomes long and tedious.
> >> Some of the PCB's I've done this on have over 1000 LED's and resistors,
> >> and generally you need to orient both the resistors and the LED's
> >>
> >> So in summary, I'd like to keep the ability to do this, but on a
> >> selection instead of globally.
> >> And being able to alter it as an absolute angle, or as a relative to
> >> current (prefix the new angle with + or - to get relative movement)
> >> would be beneficial.
> >>
> >> Regards
> >> David G
> >>
> >> On 13/04/16 06:40, Chris Pavlina wrote:
> >>> I wonder how many of you are even aware of DIALOG_ORIENT_FOOTPRINTS.
> It's
> >>> hidden in the Secret Menu in pcbnew (the spread-and-place) one, menu
> item
> >>> Orient All Footprints. The code hasn't been touched since 2010 except
> a few
> >>> cleanups, and it seems really simplistic and useless to me. I was
> going to
> >>> upgrade it to floating-point angle entry like everything else, but
> >>>
> >>> Does _anybody_ even use this? It seems utterly useless. I have no idea
> when
> >>> you'd want to globally apply an orientation to footprints. Can I just
> tear it
> >>> out?  :P
> >>>
> >>
> >>
> >> ___
> >> 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] DIALOG_ORIENT_FOOTPRINTS

[jp charras]

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 in it's zero orientation from pin 1 is on lower left to
> pin 1 is on upper left.
> 
> - Now, design X needs an update. I want to update all my footprints to
> be up-to-date with my latest library.
> Then, the footprints with the changed zero orientation need an additional
> added +-90° or +-270° rotation while they get updated from library.
> This was not easy to achieve without manual work.
> 
> Regards,
> 
> Clemens
> 

Yes, I understand.

The old dialog set a given orientation to all specified footprints.
This is not an incremental rotation.
This is not what you need.

And new footprints can have an other orientation, but also an other anchor 
position and other subtle
changes.

What you want is more a job for a python script.

-- 
Jean-Pierre CHARRAS

___
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] DIALOG_ORIENT_FOOTPRINTS

[Clemens Koller]

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 upper left.

- Now, design X needs an update. I want to update all my footprints to
be up-to-date with my latest library.
Then, the footprints with the changed zero orientation need an additional
added +-90° or +-270° rotation while they get updated from library.
This was not easy to achieve without manual work.

Regards,

Clemens


On 2016-04-13 08:16, David Godfrey wrote:
> 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 back in the correct area.
> 
> However rotating the components within the selection means they are
> still in about the right position, so only minor placement adjustments
> are required.
> These minor adjustments can likely be made using the align and
> distribute tools
> 
> I Agree half-implemented features are bad, better to update them and
> properly implement.
> 
> Regards
> David G
> 
> On 13/04/16 08:53, Chris Pavlina wrote:
>> 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 not keep crusty old
>> half-implemented legacy features around to require maintenance.
>>
>>
>> On Wed, Apr 13, 2016 at 08:50:38AM +0800, David Godfrey wrote:
>>> Hmm,
>>>
>>> I'v not used it on Kicad but the ability to change the orientation of an
>>> arbitrary selection of footprints is something I've used many times in
>>> Altium.
>>>
>>> Ideally you want to be able to set an absolute orientation, and also a
>>> relative (to current) angle adjustment.
>>>
>>> This is especially useful when designing boards like LED matrices and
>>> wanting to put all resisters on a specific angle (eg: 21.3deg).
>>> You can then do an array alignment with the same outer limit you used
>>> for your LED alignment.
>>> Then move the group of resistors into position relative to the LED's.
>>>
>>> Now running your tracks becomes trivial.
>>>
>>> Without the ability to auto adjust the orientation on a selection of
>>> parts the job becomes long and tedious.
>>> Some of the PCB's I've done this on have over 1000 LED's and resistors,
>>> and generally you need to orient both the resistors and the LED's
>>>
>>> So in summary, I'd like to keep the ability to do this, but on a
>>> selection instead of globally.
>>> And being able to alter it as an absolute angle, or as a relative to
>>> current (prefix the new angle with + or - to get relative movement)
>>> would be beneficial.
>>>
>>> Regards
>>> David G
>>>
>>> On 13/04/16 06:40, Chris Pavlina wrote:
 I wonder how many of you are even aware of DIALOG_ORIENT_FOOTPRINTS. It's
 hidden in the Secret Menu in pcbnew (the spread-and-place) one, menu item
 Orient All Footprints. The code hasn't been touched since 2010 except a few
 cleanups, and it seems really simplistic and useless to me. I was going to
 upgrade it to floating-point angle entry like everything else, but

 Does _anybody_ even use this? It seems utterly useless. I have no idea when
 you'd want to globally apply an orientation to footprints. Can I just tear 
 it
 out?  :P

>>>
>>>
>>> ___
>>> 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] DIALOG_ORIENT_FOOTPRINTS

[jp charras]

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 not keep crusty old
> half-implemented legacy features around to require maintenance.
> 

This dialog is a relic.
I added it at the beginning of the Pcbnew, when I want to explore 
auto-placement of footprints.

>From my point of view, it has no interest and can be safely removed.
If some users want to rotate footprints after loading them, the block rotate 
makes the same thing.


-- 
Jean-Pierre CHARRAS

___
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] Logic reformulation in Plot_Edges_Modules

[Lorenzo Marcantonio]

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
___
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] DIALOG_ORIENT_FOOTPRINTS

[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 you need
to rotate them by 20 degrees.
Rotating the selection means you have to do major repositioning of every
component to get them back in the correct area.

However rotating the components within the selection means they are
still in about the right position, so only minor placement adjustments
are required.
These minor adjustments can likely be made using the align and
distribute tools

I Agree half-implemented features are bad, better to update them and
properly implement.

Regards
David G

On 13/04/16 08:53, Chris Pavlina wrote:
> 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 not keep crusty old
> half-implemented legacy features around to require maintenance.
>
>
> On Wed, Apr 13, 2016 at 08:50:38AM +0800, David Godfrey wrote:
>> Hmm,
>>
>> I'v not used it on Kicad but the ability to change the orientation of an
>> arbitrary selection of footprints is something I've used many times in
>> Altium.
>>
>> Ideally you want to be able to set an absolute orientation, and also a
>> relative (to current) angle adjustment.
>>
>> This is especially useful when designing boards like LED matrices and
>> wanting to put all resisters on a specific angle (eg: 21.3deg).
>> You can then do an array alignment with the same outer limit you used
>> for your LED alignment.
>> Then move the group of resistors into position relative to the LED's.
>>
>> Now running your tracks becomes trivial.
>>
>> Without the ability to auto adjust the orientation on a selection of
>> parts the job becomes long and tedious.
>> Some of the PCB's I've done this on have over 1000 LED's and resistors,
>> and generally you need to orient both the resistors and the LED's
>>
>> So in summary, I'd like to keep the ability to do this, but on a
>> selection instead of globally.
>> And being able to alter it as an absolute angle, or as a relative to
>> current (prefix the new angle with + or - to get relative movement)
>> would be beneficial.
>>
>> Regards
>> David G
>>
>> On 13/04/16 06:40, Chris Pavlina wrote:
>>> I wonder how many of you are even aware of DIALOG_ORIENT_FOOTPRINTS. It's
>>> hidden in the Secret Menu in pcbnew (the spread-and-place) one, menu item
>>> Orient All Footprints. The code hasn't been touched since 2010 except a few
>>> cleanups, and it seems really simplistic and useless to me. I was going to
>>> upgrade it to floating-point angle entry like everything else, but
>>>
>>> Does _anybody_ even use this? It seems utterly useless. I have no idea when
>>> you'd want to globally apply an orientation to footprints. Can I just tear 
>>> it
>>> out?  :P
>>>
>>
>>
>> ___
>> 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