date:20180520

Re: [Kicad-developers] More default fields in schematic

2018-05-20 Thread José Ignacio

Kicad v5 has that feature, it's called the field editor.

On Sun, May 20, 2018 at 5:27 PM, Andrey Kuznetsov 
wrote:

> I agree, I had the same issue when I was doing my board, I needed a field
> for all components, and I had to manually add it for every item, there was
> no way to add this field to all components at the same time or to have it
> add by default from the addition of a new component to the sheet.
>
> Which reminds me, Cadence Designer has tools to manipulate fields on a
> large scale, whether to add, delete, show, hide, etc, this is something
> that would be nice to have in KiCAD, either that or a table of all
> components for the sheet or schematic and columns for each field, with
> ability to show/hide each cell individually.
>
> I think the ultimate goal is to make the Symbol Table more useful, but
> that'll take to long for v5 so if Kristoffer's patch allows an easy way to
> add fields to all components or similar, I'd say do it because people will
> be pissed and waste their time doing it for every component in their
> schematic.
>
> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark <
> kristofferodmar...@gmail.com> wrote:
>
>> I obvviously disagree, the correct solution would be to have both. This
>> does not hinder that, its not even the same problem.
>>
>> The problem is for everyone who want for example the Manufacturer Part
>> Number will have to define a fieldname, which every time
>> results in them abbreviating it to something different. Hence nobody can
>> work with Manufacturer Part Numbers.
>>
>> Here is something similar, Imagine all of the colours in Kicad for all of
>> the layers where white by default. Have fun defining all the colours
>> yourself.
>> Maybe you want to define them yourself, nobody is stopping you now
>> either, just get cracking.
>>
>> How easy would it be for you to look at the board someone else made later
>> and understand what is what? Maybe for some that is a better solution, but
>> for me that
>> would be an extreme example of bad default values.
>>
>> This is how the default fields are now, they are white, or more like
>> see-throught, which makes life harder for anyone that
>> wants to contribute or create tools that interact with kicad, and as I
>> previously said, this is only a default, you are still
>> equally able to add/remove or change the fields how you want to. But,
>> tools like kibom or various other web-based tools can much
>> easier integrate to it, or at least support a default value as well. So
>> for the majority of users, who doesnt change defaults,
>> the tool would just work.
>>
>> I will reiterate, I do not care what they are named, I want a default
>> field where I can put my manufacturer part number, amongs others.
>> The specific abbreviation or name does not matter, If i care, I can
>> manually add/remove my own fields *JUST AS I DO NOW*, but for the people
>> who use it, it will be easier across projects, for the people that dont,
>> It will not matter.
>>
>> Sane defaults matter. A lot actually.
>>
>> - Kristoffer
>>
>> On 2018-05-20 23:40, José Ignacio wrote:
>>
>>> I dont like this, the right solution would be to allow for importing a
>>> default config into kicad for things like that, as different groups will
>>> have different policies.
>>>
>>> On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark <
>>> kristofferodmar...@gmail.com >
>>> wrote:
>>>
>>> The patch should only affect first startup, changes to the fields
>>> will be saved
>>>
>>> On May 20, 2018 22:18, "Seth Hillbrand" >> > wrote:
>>>
>>> Hi Kristoffer-
>>>
>>> This feels like a management issue rather than a tool issue.
>>> If the user doesn't want any extra fields, how would your
>>> patch allow that?
>>>
>>> -S
>>>
>>>
>>> Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark
>>> >> >:
>>>
>>>
>>> Hello!
>>>
>>> I will open this can of worms again, I feel that I have
>>> to. So from what
>>> I gather we have proffessionals as the main aim in Kicad.
>>> The reason I will open this issue again is that I feel we
>>> have a
>>> collaboration issue, maybe not a mayor one. But one
>>> nonetheless.
>>>
>>> We really need more default fields for our schematic
>>> symbols. Im not
>>> proposing required fields, I am *ONLY* proposing that
>>> there should be default fields added into the default
>>> fields settings
>>> tab. I am not proposing they need to be filled in the
>>> libraries, nor that people need to use them. only that
>>> they need to
>>> exist with a fresh install of kicad so that easy problems
>>> such as theese do not happen:
>>>
>>>

Re: [Kicad-developers] More default fields in schematic

2018-05-20 Thread Jean-Paul Louis

That discussion once again shows how people misunderstand the concept of part 
number.
In a schematic, the part number attached to a RefDes should be unique AND NOT a 
manufacturer number.
  There should be a one to one relationship between a part number (symbol) and 
a physical shape, so the PCB will be a unit manufacturable only when the BOM is 
generated, and is one to one relationship between part number and Mfg part 
number.
The BOM is only for manufacturing assembly and procurement purpose
and does not need to be part of the design database, so Manufacturing can use 
Equivalent Mfg numbers for a given part number. That’s why many companies use 
internal numbering systems that are non picture coded and just sequential.
The relationship Symbol, Shape, Supplier is the responsibility of the master 
library, not the designers.

Just my $0.02,
Jean-Paul
N1JPL


> On May 20, 2018, at 6:27 PM, Andrey Kuznetsov  wrote:
> 
> I agree, I had the same issue when I was doing my board, I needed a field for 
> all components, and I had to manually add it for every item, there was no way 
> to add this field to all components at the same time or to have it add by 
> default from the addition of a new component to the sheet.
> 
> Which reminds me, Cadence Designer has tools to manipulate fields on a large 
> scale, whether to add, delete, show, hide, etc, this is something that would 
> be nice to have in KiCAD, either that or a table of all components for the 
> sheet or schematic and columns for each field, with ability to show/hide each 
> cell individually.
> 
> I think the ultimate goal is to make the Symbol Table more useful, but 
> that'll take to long for v5 so if Kristoffer's patch allows an easy way to 
> add fields to all components or similar, I'd say do it because people will be 
> pissed and waste their time doing it for every component in their schematic.
> 
> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark 
>  wrote:
> I obvviously disagree, the correct solution would be to have both. This does 
> not hinder that, its not even the same problem.
> 
> The problem is for everyone who want for example the Manufacturer Part Number 
> will have to define a fieldname, which every time
> results in them abbreviating it to something different. Hence nobody can work 
> with Manufacturer Part Numbers.
> 
> Here is something similar, Imagine all of the colours in Kicad for all of the 
> layers where white by default. Have fun defining all the colours yourself.
> Maybe you want to define them yourself, nobody is stopping you now either, 
> just get cracking.
> 
> How easy would it be for you to look at the board someone else made later and 
> understand what is what? Maybe for some that is a better solution, but for me 
> that
> would be an extreme example of bad default values.
> 
> This is how the default fields are now, they are white, or more like 
> see-throught, which makes life harder for anyone that
> wants to contribute or create tools that interact with kicad, and as I 
> previously said, this is only a default, you are still
> equally able to add/remove or change the fields how you want to. But, tools 
> like kibom or various other web-based tools can much
> easier integrate to it, or at least support a default value as well. So for 
> the majority of users, who doesnt change defaults,
> the tool would just work.
> 
> I will reiterate, I do not care what they are named, I want a default field 
> where I can put my manufacturer part number, amongs others.
> The specific abbreviation or name does not matter, If i care, I can manually 
> add/remove my own fields *JUST AS I DO NOW*, but for the people
> who use it, it will be easier across projects, for the people that dont, It 
> will not matter.
> 
> Sane defaults matter. A lot actually.
> 
> - Kristoffer
> 
> On 2018-05-20 23:40, José Ignacio wrote:
> I dont like this, the right solution would be to allow for importing a 
> default config into kicad for things like that, as different groups will have 
> different policies.
> 
> On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark 
> mailto:kristofferodmar...@gmail.com>> wrote:
> 
> The patch should only affect first startup, changes to the fields
> will be saved
> 
> On May 20, 2018 22:18, "Seth Hillbrand"  > wrote:
> 
> Hi Kristoffer-
> 
> This feels like a management issue rather than a tool issue. 
> If the user doesn't want any extra fields, how would your
> patch allow that?
> 
> -S
> 
> 
> Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark
>  >:
> 
> 
> Hello!
> 
> I will open this can of worms again, I feel that I have
> to. So from what
> I gather we have proffessionals as the main aim in Kicad.
> The reason I will open this issue again is that I feel we
> have a
>

[Kicad-developers] rc2 tagged

2018-05-20 Thread Wayne Stambaugh

Just a quick heads up, I tagged rc2.  Hopefully the final countdown to 
the stable 5 release wont be quite as painful as the rc1 to rc2 cycle. 
Thank you to everyone for your hard work.  I cannot be express my 
appreciation for all that you do to make KiCad possible.


I will create a blog post announcement about rc2 in a couple of days to 
give our packagers time to create rc2 packages.


This also marks the UI string freeze so no UI string changes except for 
spelling errors.  I want to be fair to our translators so we can have 
the most complete translations possible.


Let's hope it wont be too much longer until we can celebrate the stable 
5 release which has been a long time coming.


Cheers,

Wayne

___
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] Initial rc6 development.

2018-05-20 Thread Seth Hillbrand

The discussion of 5.x releases was delayed but perhaps seems relevant
again.  Should we plan for a 5.1 release as Simon suggests with a goal of
working GTK3?  I'm not sure that I agree with his preference for banning
non-GTK3 patches but I do have a preference for avoiding file format
changes during 5.x releases.

-S



Am So., 20. Mai 2018 um 16:41 Uhr schrieb Wayne Stambaugh <
stambau...@gmail.com>:

>
>
> On 05/19/2018 09:36 AM, Simon Richter wrote:
> > Hi,
> >
> > On 18.05.2018 17:38, Wayne Stambaugh wrote:
> >
> >> I propose we spend some time immediately after the v5 release
> >> and fix the gtk3 issues before we start making major changes to the code
> >> base so that it is not difficult to back port.  Anyone else have any
> >> thoughts on this?
> >
> > We could make that official, and just announce that the next release
> > after 5.0 will be 5.1, for which only GTK3 changes and bugfixes will be
> > accepted.
>
> I would hope that the development team understands the issue.  I don't
> want KiCad to be unusable in a large number of modern Linux distros nor
> do a want the distro packagers to have to jump through a lot of hoops to
> get KiCad to build.  I would rather not have to drop the hammer but I
> could if it came to that.
>
> Cheers,
>
> Wayne
>
> >
> >Simon
> >
> > ___
> > 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] 5.0 RC2 / release status

2018-05-20 Thread Wayne Stambaugh

Great work Rene!

Last call for any changes before I tag RC2.  I wait another hour or two
but I'm going to tag rc2 before I call it a night unless there is
something critical that needs to get committed.

On 05/20/2018 10:24 AM, Rene Pöschl wrote:
> Hi all,
> 
> as promised in my last response the library repos are now tagged with
> 5.0.0-rc2
> If there is another major delay we might need to introduce a rc2.1 tag
> or something (or accept that at that time the libs are a bit older)
> 
> On 18/05/18 23:45, Wayne Stambaugh wrote:
>> Hi Rene,
>>
>> On 05/18/2018 11:53 AM, Rene Pöschl wrote:
>>> On 18/05/18 16:44, Wayne Stambaugh wrote:
 If any of our doc and library devs are on this mailing list, please
 forward this information so we aren't making major changes to the docs
 and libraries at the last minute.

>>> We have one important pull request open that i will fix up my self
>>> tomorrow if the contributor does not fix the remaining issues him self.
>>> (Removing duplicate power pins from symbols as this can be quite
>>> dangerous if the user connects them multiple times.)
>>>
>>> After this is merged i will tag the library with "5.0.0-rc2" (Tomorrow
>>> evening)
>>>
>>> After this tag is set we will no longer allow renaming of libs until v6
>>> development. (Adding new libs will still be allowed.)
>> I'm OK with this.
>>
>>> I will also create a kicad 4 compatibility backport for this lib. (The
>>> intention is to allow users to use the new library structure for new
>>> projects even if they can not update to a nightly build. This should
>>> reduce their work when they then switch over to kicad 5)
>>>
>>> This backport will contain a reduced number of footprints as footprints
>>> with custom or roundrect pads are not supported by kicad 4. I will also
>>> backport the symbol libs. The 3d lib does not need any work in this
>>> regard but i will still ad a separate release tag to make it easier for
>>> users. Not sure if i will make a backport of the templates.
>>> Creating this backport will take some time but i hope to have it done
>>> one week after the rc2 tag is set.
>> Awesome!  I'm sure our v4 users will appreciate this.
>>
>>>
>>> Regarding the issue about footprint connection you reported in [1]:
>>> All symbols that have a valid symbol in the footprint lib are now
>>> correctly connected. Sadly a lot of symbols still need footprints to be
>>> generated. (Symbols where in the lib that never had a valid footprint)
>>> Some of this will be fixed after the rc2 release. This will not impact
>>> the library structure so i assume we can include these changes in the
>>> final v5 release. (It will simply add more footprints.)
>> That fine by me.  If we are going add new symbol libraries during v5, I
>> don't see any reason not to add new footprints and footprint libraries.
>> We should try to avoid wholesale renaming and/or moving of libraries and
>> their contents to avoid headaches for users.  If we have any major
>> library reorganizations, we can always create a v5 branch as we do for
>> the KiCad source.
>>
>> Thank you for all of your hard work on the libraries.  They really have
>> come a long way since v4 was released.
>>
>> Cheers,
>>
>> Wayne
>>
>>> [1]: https://github.com/KiCad/kicad-symbols/issues/520
>>>
>>> ___
>>> 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] Initial rc6 development.

2018-05-20 Thread Wayne Stambaugh



On 05/19/2018 09:36 AM, Simon Richter wrote:
> Hi,
> 
> On 18.05.2018 17:38, Wayne Stambaugh wrote:
> 
>> I propose we spend some time immediately after the v5 release
>> and fix the gtk3 issues before we start making major changes to the code
>> base so that it is not difficult to back port.  Anyone else have any
>> thoughts on this?
> 
> We could make that official, and just announce that the next release
> after 5.0 will be 5.1, for which only GTK3 changes and bugfixes will be
> accepted.

I would hope that the development team understands the issue.  I don't
want KiCad to be unusable in a large number of modern Linux distros nor
do a want the distro packagers to have to jump through a lot of hoops to
get KiCad to build.  I would rather not have to drop the hammer but I
could if it came to that.

Cheers,

Wayne

> 
>Simon
> 
> ___
> 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] More default fields in schematic

2018-05-20 Thread Andrey Kuznetsov

I agree, I had the same issue when I was doing my board, I needed a field
for all components, and I had to manually add it for every item, there was
no way to add this field to all components at the same time or to have it
add by default from the addition of a new component to the sheet.

Which reminds me, Cadence Designer has tools to manipulate fields on a
large scale, whether to add, delete, show, hide, etc, this is something
that would be nice to have in KiCAD, either that or a table of all
components for the sheet or schematic and columns for each field, with
ability to show/hide each cell individually.

I think the ultimate goal is to make the Symbol Table more useful, but
that'll take to long for v5 so if Kristoffer's patch allows an easy way to
add fields to all components or similar, I'd say do it because people will
be pissed and waste their time doing it for every component in their
schematic.

On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> I obvviously disagree, the correct solution would be to have both. This
> does not hinder that, its not even the same problem.
>
> The problem is for everyone who want for example the Manufacturer Part
> Number will have to define a fieldname, which every time
> results in them abbreviating it to something different. Hence nobody can
> work with Manufacturer Part Numbers.
>
> Here is something similar, Imagine all of the colours in Kicad for all of
> the layers where white by default. Have fun defining all the colours
> yourself.
> Maybe you want to define them yourself, nobody is stopping you now either,
> just get cracking.
>
> How easy would it be for you to look at the board someone else made later
> and understand what is what? Maybe for some that is a better solution, but
> for me that
> would be an extreme example of bad default values.
>
> This is how the default fields are now, they are white, or more like
> see-throught, which makes life harder for anyone that
> wants to contribute or create tools that interact with kicad, and as I
> previously said, this is only a default, you are still
> equally able to add/remove or change the fields how you want to. But,
> tools like kibom or various other web-based tools can much
> easier integrate to it, or at least support a default value as well. So
> for the majority of users, who doesnt change defaults,
> the tool would just work.
>
> I will reiterate, I do not care what they are named, I want a default
> field where I can put my manufacturer part number, amongs others.
> The specific abbreviation or name does not matter, If i care, I can
> manually add/remove my own fields *JUST AS I DO NOW*, but for the people
> who use it, it will be easier across projects, for the people that dont,
> It will not matter.
>
> Sane defaults matter. A lot actually.
>
> - Kristoffer
>
> On 2018-05-20 23:40, José Ignacio wrote:
>
>> I dont like this, the right solution would be to allow for importing a
>> default config into kicad for things like that, as different groups will
>> have different policies.
>>
>> On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark <
>> kristofferodmar...@gmail.com >
>> wrote:
>>
>> The patch should only affect first startup, changes to the fields
>> will be saved
>>
>> On May 20, 2018 22:18, "Seth Hillbrand" > > wrote:
>>
>> Hi Kristoffer-
>>
>> This feels like a management issue rather than a tool issue.
>> If the user doesn't want any extra fields, how would your
>> patch allow that?
>>
>> -S
>>
>>
>> Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark
>> > >:
>>
>>
>> Hello!
>>
>> I will open this can of worms again, I feel that I have
>> to. So from what
>> I gather we have proffessionals as the main aim in Kicad.
>> The reason I will open this issue again is that I feel we
>> have a
>> collaboration issue, maybe not a mayor one. But one
>> nonetheless.
>>
>> We really need more default fields for our schematic
>> symbols. Im not
>> proposing required fields, I am *ONLY* proposing that
>> there should be default fields added into the default
>> fields settings
>> tab. I am not proposing they need to be filled in the
>> libraries, nor that people need to use them. only that
>> they need to
>> exist with a fresh install of kicad so that easy problems
>> such as theese do not happen:
>>
>>  - Collaborators working on the same project will not
>> create
>> duplicate fields in libs/projects describing the same
>> thing by mistake
>>  - Projects that aim to interact or add to Kicad

Re: [Kicad-developers] More default fields in schematic

2018-05-20 Thread kristoffer Ödmark

I obvviously disagree, the correct solution would be to have both. This 
does not hinder that, its not even the same problem.


The problem is for everyone who want for example the Manufacturer Part 
Number will have to define a fieldname, which every time
results in them abbreviating it to something different. Hence nobody can 
work with Manufacturer Part Numbers.


Here is something similar, Imagine all of the colours in Kicad for all 
of the layers where white by default. Have fun defining all the colours 
yourself.
Maybe you want to define them yourself, nobody is stopping you now 
either, just get cracking.


How easy would it be for you to look at the board someone else made 
later and understand what is what? Maybe for some that is a better 
solution, but for me that

would be an extreme example of bad default values.

This is how the default fields are now, they are white, or more like 
see-throught, which makes life harder for anyone that
wants to contribute or create tools that interact with kicad, and as I 
previously said, this is only a default, you are still
equally able to add/remove or change the fields how you want to. But, 
tools like kibom or various other web-based tools can much
easier integrate to it, or at least support a default value as well. So 
for the majority of users, who doesnt change defaults,

the tool would just work.

I will reiterate, I do not care what they are named, I want a default 
field where I can put my manufacturer part number, amongs others.
The specific abbreviation or name does not matter, If i care, I can 
manually add/remove my own fields *JUST AS I DO NOW*, but for the people
who use it, it will be easier across projects, for the people that dont, 
It will not matter.


Sane defaults matter. A lot actually.

- Kristoffer

On 2018-05-20 23:40, José Ignacio wrote:
I dont like this, the right solution would be to allow for importing a 
default config into kicad for things like that, as different groups 
will have different policies.


On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark 
mailto:kristofferodmar...@gmail.com>> 
wrote:


The patch should only affect first startup, changes to the fields
will be saved

On May 20, 2018 22:18, "Seth Hillbrand" mailto:seth.hillbr...@gmail.com>> wrote:

Hi Kristoffer-

This feels like a management issue rather than a tool issue. 
If the user doesn't want any extra fields, how would your
patch allow that?

-S


Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark
mailto:kristofferodmar...@gmail.com>>:

Hello!

I will open this can of worms again, I feel that I have
to. So from what
I gather we have proffessionals as the main aim in Kicad.
The reason I will open this issue again is that I feel we
have a
collaboration issue, maybe not a mayor one. But one
nonetheless.

We really need more default fields for our schematic
symbols. Im not
proposing required fields, I am *ONLY* proposing that
there should be default fields added into the default
fields settings
tab. I am not proposing they need to be filled in the
libraries, nor that people need to use them. only that
they need to
exist with a fresh install of kicad so that easy problems
such as theese do not happen:

 - Collaborators working on the same project will not
create
duplicate fields in libs/projects describing the same
thing by mistake
 - Projects that aim to interact or add to Kicad can
assume that the
Fields will exist, and will know what name/tag to look for
   (bom exporters, price checkers, MacroFab, etc)
 - Open source projects will be easier to collaborate,
read and order

The reason I think it is better to have the fields by
default than the
current solution to add them is that the majority will use
what exists, and tools can support it from the very
beginning, people
with inhouse tools seems to dislike this, since they map their
parts with an inhouse number - and then handle the
information about the
part there. From what I gather, this is not the majority, and
these persons still modify the default fields settings.

I spent maybe 30-40 mins checking the "made with kicad"
projects, I
found that the most common addition to libs and schematics
are:
 - Manufacturers part number, these were named widely
different in
projects, (BOM, MP, MPN, #mfg, or different syntaxes in
the Value field )
     I even saw a m

Re: [Kicad-developers] More default fields in schematic

2018-05-20 Thread José Ignacio

I dont like this, the right solution would be to allow for importing a
default config into kicad for things like that, as different groups will
have different policies.

On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> The patch should only affect first startup, changes to the fields will be
> saved
>
> On May 20, 2018 22:18, "Seth Hillbrand"  wrote:
>
> Hi Kristoffer-
>
> This feels like a management issue rather than a tool issue.  If the user
> doesn't want any extra fields, how would your patch allow that?
>
> -S
>
>
> Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark <
> kristofferodmar...@gmail.com>:
>
>> Hello!
>>
>> I will open this can of worms again, I feel that I have to. So from what
>> I gather we have proffessionals as the main aim in Kicad.
>> The reason I will open this issue again is that I feel we have a
>> collaboration issue, maybe not a mayor one. But one nonetheless.
>>
>> We really need more default fields for our schematic symbols. Im not
>> proposing required fields, I am *ONLY* proposing that
>> there should be default fields added into the default fields settings
>> tab. I am not proposing they need to be filled in the
>> libraries, nor that people need to use them. only that they need to
>> exist with a fresh install of kicad so that easy problems
>> such as theese do not happen:
>>
>>  - Collaborators working on the same project will not create
>> duplicate fields in libs/projects describing the same thing by mistake
>>  - Projects that aim to interact or add to Kicad can assume that the
>> Fields will exist, and will know what name/tag to look for
>>(bom exporters, price checkers, MacroFab, etc)
>>  - Open source projects will be easier to collaborate, read and order
>>
>> The reason I think it is better to have the fields by default than the
>> current solution to add them is that the majority will use
>> what exists, and tools can support it from the very beginning, people
>> with inhouse tools seems to dislike this, since they map their
>> parts with an inhouse number - and then handle the information about the
>> part there. From what I gather, this is not the majority, and
>> these persons still modify the default fields settings.
>>
>> I spent maybe 30-40 mins checking the "made with kicad" projects, I
>> found that the most common addition to libs and schematics are:
>>  - Manufacturers part number, these were named widely different in
>> projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
>>  I even saw a mix of these in the same project once, along with
>> some people having the vendor id only.
>>  - Manufacturer ( found some different languages though )
>>
>> more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C,
>> 16V ), Vendor information and different Descriptions. They were named
>> and abbreviated
>> very differently accross projects.
>>
>> What I would like to see is these additional fields by default, but
>> hidden from the schematic unless changed by user.
>>  Tolerance ( used for setting tolerances of resistors, capacitors,
>> oscillators, etc )
>>  MaxRating ( field were one can specify max Voltage, Ampere,
>> Frequency, or whatever the component needs )
>>  Manufacturer ( For inhouse numbers, they could either just remove
>> it, or use the company/group name )
>>  MPN ( Maybe PartNumber could be used here, and people who use
>> inhouse numbers use it aswell, I dont really care what its called, as
>> long as its called something )
>>  Vendor
>>  Notes
>>
>> I would be all up for extra additions/removals, but I would prefer if
>> the naming is not discussed, but rather just decided/agreed upon by
>> someone in the lead team.
>> The very least I think should be added in case the previous is to much
>> are:
>>  Tolerance
>>  Manufacturer
>>  MPN
>>
>> I attach a patch for the minimal set, tested on linux by removing the
>> .config/kicad/eeschema file.
>>
>> - Kristoffer
>>
>>
>> ps
>> Some github files i reviewed, not all:
>> https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-
>> I_SN.lib
>> https://github.com/jonpe960/blixten/blob/master/Blixten%
>> 20LED%20Device/Blixten.sch
>> https://github.com/paltatech/half-bridge/blob/master/pcb%
>> 20design/IGBT_board-cache.lib
>> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
>> https://github.com/jim17/memtype/blob/master/schematic_
>> pcb/electronic_design_kicad/electronic_design_kicad.sch
>> ___
>> 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.

Re: [Kicad-developers] More default fields in schematic

2018-05-20 Thread Kristoffer Ödmark

The patch should only affect first startup, changes to the fields will be
saved

On May 20, 2018 22:18, "Seth Hillbrand"  wrote:

Hi Kristoffer-

This feels like a management issue rather than a tool issue.  If the user
doesn't want any extra fields, how would your patch allow that?

-S


Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark <
kristofferodmar...@gmail.com>:

> Hello!
>
> I will open this can of worms again, I feel that I have to. So from what
> I gather we have proffessionals as the main aim in Kicad.
> The reason I will open this issue again is that I feel we have a
> collaboration issue, maybe not a mayor one. But one nonetheless.
>
> We really need more default fields for our schematic symbols. Im not
> proposing required fields, I am *ONLY* proposing that
> there should be default fields added into the default fields settings
> tab. I am not proposing they need to be filled in the
> libraries, nor that people need to use them. only that they need to
> exist with a fresh install of kicad so that easy problems
> such as theese do not happen:
>
>  - Collaborators working on the same project will not create
> duplicate fields in libs/projects describing the same thing by mistake
>  - Projects that aim to interact or add to Kicad can assume that the
> Fields will exist, and will know what name/tag to look for
>(bom exporters, price checkers, MacroFab, etc)
>  - Open source projects will be easier to collaborate, read and order
>
> The reason I think it is better to have the fields by default than the
> current solution to add them is that the majority will use
> what exists, and tools can support it from the very beginning, people
> with inhouse tools seems to dislike this, since they map their
> parts with an inhouse number - and then handle the information about the
> part there. From what I gather, this is not the majority, and
> these persons still modify the default fields settings.
>
> I spent maybe 30-40 mins checking the "made with kicad" projects, I
> found that the most common addition to libs and schematics are:
>  - Manufacturers part number, these were named widely different in
> projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
>  I even saw a mix of these in the same project once, along with
> some people having the vendor id only.
>  - Manufacturer ( found some different languages though )
>
> more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C,
> 16V ), Vendor information and different Descriptions. They were named
> and abbreviated
> very differently accross projects.
>
> What I would like to see is these additional fields by default, but
> hidden from the schematic unless changed by user.
>  Tolerance ( used for setting tolerances of resistors, capacitors,
> oscillators, etc )
>  MaxRating ( field were one can specify max Voltage, Ampere,
> Frequency, or whatever the component needs )
>  Manufacturer ( For inhouse numbers, they could either just remove
> it, or use the company/group name )
>  MPN ( Maybe PartNumber could be used here, and people who use
> inhouse numbers use it aswell, I dont really care what its called, as
> long as its called something )
>  Vendor
>  Notes
>
> I would be all up for extra additions/removals, but I would prefer if
> the naming is not discussed, but rather just decided/agreed upon by
> someone in the lead team.
> The very least I think should be added in case the previous is to much are:
>  Tolerance
>  Manufacturer
>  MPN
>
> I attach a patch for the minimal set, tested on linux by removing the
> .config/kicad/eeschema file.
>
> - Kristoffer
>
>
> ps
> Some github files i reviewed, not all:
>
> https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib
>
> https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch
>
> https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib
> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
>
> https://github.com/jim17/memtype/blob/master/schematic_pcb/electronic_design_kicad/electronic_design_kicad.sch
> ___
> 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] [patch] small tweaks to the pcbnew move exactly dialog strings

2018-05-20 Thread Seth Hillbrand

I like the extra tooltips in this, except for line 48 which talks about
centers and anchors interchangeably and is not clear.

-S



Am So., 20. Mai 2018 um 12:41 Uhr schrieb Robbert Lagerweij <
rlagerw...@hotmail.com>:

> Inspired by the discussion on bug 1771424
>  I have made some small
> tweaks to the strings to hopefully improve the clarity on the way the tool
> works for users. As a non native speaker this is always a bit tricky so I'm
> happy to take suggestions if someone has better wording in mind.
>
>
> Robbert
>
> ___
> 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] More default fields in schematic

2018-05-20 Thread Seth Hillbrand

Hi Kristoffer-

This feels like a management issue rather than a tool issue.  If the user
doesn't want any extra fields, how would your patch allow that?

-S


Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark <
kristofferodmar...@gmail.com>:

> Hello!
>
> I will open this can of worms again, I feel that I have to. So from what
> I gather we have proffessionals as the main aim in Kicad.
> The reason I will open this issue again is that I feel we have a
> collaboration issue, maybe not a mayor one. But one nonetheless.
>
> We really need more default fields for our schematic symbols. Im not
> proposing required fields, I am *ONLY* proposing that
> there should be default fields added into the default fields settings
> tab. I am not proposing they need to be filled in the
> libraries, nor that people need to use them. only that they need to
> exist with a fresh install of kicad so that easy problems
> such as theese do not happen:
>
>  - Collaborators working on the same project will not create
> duplicate fields in libs/projects describing the same thing by mistake
>  - Projects that aim to interact or add to Kicad can assume that the
> Fields will exist, and will know what name/tag to look for
>(bom exporters, price checkers, MacroFab, etc)
>  - Open source projects will be easier to collaborate, read and order
>
> The reason I think it is better to have the fields by default than the
> current solution to add them is that the majority will use
> what exists, and tools can support it from the very beginning, people
> with inhouse tools seems to dislike this, since they map their
> parts with an inhouse number - and then handle the information about the
> part there. From what I gather, this is not the majority, and
> these persons still modify the default fields settings.
>
> I spent maybe 30-40 mins checking the "made with kicad" projects, I
> found that the most common addition to libs and schematics are:
>  - Manufacturers part number, these were named widely different in
> projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
>  I even saw a mix of these in the same project once, along with
> some people having the vendor id only.
>  - Manufacturer ( found some different languages though )
>
> more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C,
> 16V ), Vendor information and different Descriptions. They were named
> and abbreviated
> very differently accross projects.
>
> What I would like to see is these additional fields by default, but
> hidden from the schematic unless changed by user.
>  Tolerance ( used for setting tolerances of resistors, capacitors,
> oscillators, etc )
>  MaxRating ( field were one can specify max Voltage, Ampere,
> Frequency, or whatever the component needs )
>  Manufacturer ( For inhouse numbers, they could either just remove
> it, or use the company/group name )
>  MPN ( Maybe PartNumber could be used here, and people who use
> inhouse numbers use it aswell, I dont really care what its called, as
> long as its called something )
>  Vendor
>  Notes
>
> I would be all up for extra additions/removals, but I would prefer if
> the naming is not discussed, but rather just decided/agreed upon by
> someone in the lead team.
> The very least I think should be added in case the previous is to much are:
>  Tolerance
>  Manufacturer
>  MPN
>
> I attach a patch for the minimal set, tested on linux by removing the
> .config/kicad/eeschema file.
>
> - Kristoffer
>
>
> ps
> Some github files i reviewed, not all:
>
> https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib
>
> https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch
>
> https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib
> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
>
> https://github.com/jim17/memtype/blob/master/schematic_pcb/electronic_design_kicad/electronic_design_kicad.sch
> ___
> 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] More default fields in schematic

2018-05-20 Thread kristoffer Ödmark


Hello!

I will open this can of worms again, I feel that I have to. So from what 
I gather we have proffessionals as the main aim in Kicad.
The reason I will open this issue again is that I feel we have a 
collaboration issue, maybe not a mayor one. But one nonetheless.


We really need more default fields for our schematic symbols. Im not 
proposing required fields, I am *ONLY* proposing that
there should be default fields added into the default fields settings 
tab. I am not proposing they need to be filled in the
libraries, nor that people need to use them. only that they need to 
exist with a fresh install of kicad so that easy problems

such as theese do not happen:

    - Collaborators working on the same project will not create 
duplicate fields in libs/projects describing the same thing by mistake
    - Projects that aim to interact or add to Kicad can assume that the 
Fields will exist, and will know what name/tag to look for

  (bom exporters, price checkers, MacroFab, etc)
    - Open source projects will be easier to collaborate, read and order

The reason I think it is better to have the fields by default than the 
current solution to add them is that the majority will use
what exists, and tools can support it from the very beginning, people 
with inhouse tools seems to dislike this, since they map their
parts with an inhouse number - and then handle the information about the 
part there. From what I gather, this is not the majority, and

these persons still modify the default fields settings.

I spent maybe 30-40 mins checking the "made with kicad" projects, I 
found that the most common addition to libs and schematics are:
    - Manufacturers part number, these were named widely different in 
projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
        I even saw a mix of these in the same project once, along with 
some people having the vendor id only.

    - Manufacturer ( found some different languages though )

more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C, 
16V ), Vendor information and different Descriptions. They were named 
and abbreviated

very differently accross projects.

What I would like to see is these additional fields by default, but 
hidden from the schematic unless changed by user.
    Tolerance ( used for setting tolerances of resistors, capacitors, 
oscillators, etc )
    MaxRating ( field were one can specify max Voltage, Ampere, 
Frequency, or whatever the component needs )
    Manufacturer ( For inhouse numbers, they could either just remove 
it, or use the company/group name )
    MPN ( Maybe PartNumber could be used here, and people who use 
inhouse numbers use it aswell, I dont really care what its called, as 
long as its called something )

    Vendor
    Notes

I would be all up for extra additions/removals, but I would prefer if 
the naming is not discussed, but rather just decided/agreed upon by 
someone in the lead team.

The very least I think should be added in case the previous is to much are:
    Tolerance
    Manufacturer
    MPN

I attach a patch for the minimal set, tested on linux by removing the 
.config/kicad/eeschema file.


- Kristoffer


ps
Some github files i reviewed, not all:
https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib
https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch
https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib
https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
https://github.com/jim17/memtype/blob/master/schematic_pcb/electronic_design_kicad/electronic_design_kicad.sch
>From f0af6575bfa46e70168c1d3cfcafdf19dbc7b125 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= 
Date: Sun, 20 May 2018 21:59:13 +0200
Subject: [PATCH] Added minimal set of default template fields

---
 eeschema/eeschema_config.cpp | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/eeschema/eeschema_config.cpp b/eeschema/eeschema_config.cpp
index 205ab2674..53b510bac 100644
--- a/eeschema/eeschema_config.cpp
+++ b/eeschema/eeschema_config.cpp
@@ -588,7 +588,10 @@ void SCH_EDIT_FRAME::LoadSettings( wxConfigBase* aCfg )
 m_replaceStringHistoryList.Add( tmpHistory );
 }
 
-wxString templateFieldNames = aCfg->Read( FieldNamesEntry, wxEmptyString );
+// Read the template field settings, use default if no found
+const wxString defaultTemplateFieldNames =
+"(templatefields (field (name Tolerance)(value ~)) (field (name Manufacturer)(value ~)) (field (name MPN)(value ~)))";
+wxString templateFieldNames = aCfg->Read( FieldNamesEntry, defaultTemplateFieldNames );
 
 if( !templateFieldNames.IsEmpty() )
 {
-- 
2.17.0

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

[Kicad-developers] [patch] small tweaks to the pcbnew move exactly dialog strings

2018-05-20 Thread Robbert Lagerweij

Inspired by the discussion on bug 
1771424 I have made some small 
tweaks to the strings to hopefully improve the clarity on the way the tool 
works for users. As a non native speaker this is always a bit tricky so I'm 
happy to take suggestions if someone has better wording in mind.


Robbert

From df007df15ea66b26e6644c70dfb0c6e655a6b216 Mon Sep 17 00:00:00 2001
From: Unknown 
Date: Sun, 20 May 2018 21:03:33 +0200
Subject: [PATCH] pcbnew: move exactly dialog tweaks

Clarify some texts to remove ambiguity on the functioning of the tool. Updated dialog title.
---
 pcbnew/dialogs/dialog_move_exact_base.cpp | 12 
 pcbnew/dialogs/dialog_move_exact_base.fbp | 16 
 pcbnew/dialogs/dialog_move_exact_base.h   |  4 ++--
 3 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/pcbnew/dialogs/dialog_move_exact_base.cpp b/pcbnew/dialogs/dialog_move_exact_base.cpp
index fe3c8b8..eb309de 100644
--- a/pcbnew/dialogs/dialog_move_exact_base.cpp
+++ b/pcbnew/dialogs/dialog_move_exact_base.cpp
@@ -1,5 +1,5 @@
 ///
-// C++ code generated with wxFormBuilder (version Aug  4 2017)
+// C++ code generated with wxFormBuilder (version May 20 2018)
 // http://www.wxformbuilder.org/
 //
 // PLEASE DO "NOT" EDIT THIS FILE!
@@ -59,6 +59,8 @@ DIALOG_MOVE_EXACT_BASE::DIALOG_MOVE_EXACT_BASE( wxWindow* parent, wxWindowID id,
 	
 	m_rotLabel = new wxStaticText( this, wxID_ANY, _("Item rotation:"), wxDefaultPosition, wxDefaultSize, 0 );
 	m_rotLabel->Wrap( -1 );
+	m_rotLabel->SetToolTip( _("Rotation is applied after the move and around the anchor") );
+	
 	fgInputSizer->Add( m_rotLabel, 0, wxALIGN_CENTER_VERTICAL|wxALIGN_RIGHT|wxALL, 5 );
 	
 	m_rotEntry = new TEXT_CTRL_EVAL( this, wxID_ANY, _("0"), wxDefaultPosition, wxDefaultSize, 0 );
@@ -76,7 +78,7 @@ DIALOG_MOVE_EXACT_BASE::DIALOG_MOVE_EXACT_BASE( wxWindow* parent, wxWindowID id,
 	
 	wxString m_originChooserChoices[] = { _("Current position"), _("User origin"), _("Grid origin"), _("Drill/Place origin"), _("Sheet origin") };
 	int m_originChooserNChoices = sizeof( m_originChooserChoices ) / sizeof( wxString );
-	m_originChooser = new wxRadioBox( this, wxID_ANY, _("Move Relative To:"), wxDefaultPosition, wxDefaultSize, m_originChooserNChoices, m_originChooserChoices, 1, wxRA_SPECIFY_COLS );
+	m_originChooser = new wxRadioBox( this, wxID_ANY, _("Move Start Point:"), wxDefaultPosition, wxDefaultSize, m_originChooserNChoices, m_originChooserChoices, 1, wxRA_SPECIFY_COLS );
 	m_originChooser->SetSelection( 0 );
 	bMiddleSizer->Add( m_originChooser, 0, wxALL, 5 );
 	
@@ -85,10 +87,12 @@ DIALOG_MOVE_EXACT_BASE::DIALOG_MOVE_EXACT_BASE( wxWindow* parent, wxWindowID id,
 	
 	bAnchorSizer = new wxBoxSizer( wxHORIZONTAL );
 	
-	m_cbOverride = new wxCheckBox( this, wxID_ANY, _("Override default footprint anchor with:"), wxDefaultPosition, wxDefaultSize, 0 );
+	m_cbOverride = new wxCheckBox( this, wxID_ANY, _("Override default anchor with:"), wxDefaultPosition, wxDefaultSize, 0 );
+	m_cbOverride->SetToolTip( _("By default the center of the selected item(s) will be positioned on the selected location. For footprints the default anchor is determined by the designer. ") );
+	
 	bAnchorSizer->Add( m_cbOverride, 1, wxALL, 5 );
 	
-	wxString m_anchorChoiceChoices[] = { _("Top left pad"), _("Footprint center") };
+	wxString m_anchorChoiceChoices[] = { _("Top left pad"), _("Center point") };
 	int m_anchorChoiceNChoices = sizeof( m_anchorChoiceChoices ) / sizeof( wxString );
 	m_anchorChoice = new wxChoice( this, wxID_ANY, wxDefaultPosition, wxDefaultSize, m_anchorChoiceNChoices, m_anchorChoiceChoices, 0 );
 	m_anchorChoice->SetSelection( 0 );
diff --git a/pcbnew/dialogs/dialog_move_exact_base.fbp b/pcbnew/dialogs/dialog_move_exact_base.fbp
index cbb91c3..7f90100 100644
--- a/pcbnew/dialogs/dialog_move_exact_base.fbp
+++ b/pcbnew/dialogs/dialog_move_exact_base.fbp
@@ -44,10 +44,10 @@
 -1,-1
 DIALOG_MOVE_EXACT_BASE
 
-427,250
+527,307
 wxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER
 DIALOG_SHIM; dialog_shim.h
-Move Item
+Move Exactly
 
 
 
@@ -194,7 +194,7 @@
 5
 wxALL|wxBOTTOM|wxEXPAND|wxTOP
 1
-
+
 4
 wxBOTH
 1
@@ -949,7 +949,7 @@
 
 
 0
-
+Rotation is applied after the move and around the center of the selection

Re: [Kicad-developers] 5.0 RC2 / release status

2018-05-20 Thread Rene Pöschl


Hi all,

as promised in my last response the library repos are now tagged with 
5.0.0-rc2
If there is another major delay we might need to introduce a rc2.1 tag 
or something (or accept that at that time the libs are a bit older)


On 18/05/18 23:45, Wayne Stambaugh wrote:

Hi Rene,

On 05/18/2018 11:53 AM, Rene Pöschl wrote:

On 18/05/18 16:44, Wayne Stambaugh wrote:

If any of our doc and library devs are on this mailing list, please
forward this information so we aren't making major changes to the docs
and libraries at the last minute.


We have one important pull request open that i will fix up my self
tomorrow if the contributor does not fix the remaining issues him self.
(Removing duplicate power pins from symbols as this can be quite
dangerous if the user connects them multiple times.)

After this is merged i will tag the library with "5.0.0-rc2" (Tomorrow
evening)

After this tag is set we will no longer allow renaming of libs until v6
development. (Adding new libs will still be allowed.)

I'm OK with this.


I will also create a kicad 4 compatibility backport for this lib. (The
intention is to allow users to use the new library structure for new
projects even if they can not update to a nightly build. This should
reduce their work when they then switch over to kicad 5)

This backport will contain a reduced number of footprints as footprints
with custom or roundrect pads are not supported by kicad 4. I will also
backport the symbol libs. The 3d lib does not need any work in this
regard but i will still ad a separate release tag to make it easier for
users. Not sure if i will make a backport of the templates.
Creating this backport will take some time but i hope to have it done
one week after the rc2 tag is set.

Awesome!  I'm sure our v4 users will appreciate this.



Regarding the issue about footprint connection you reported in [1]:
All symbols that have a valid symbol in the footprint lib are now
correctly connected. Sadly a lot of symbols still need footprints to be
generated. (Symbols where in the lib that never had a valid footprint)
Some of this will be fixed after the rc2 release. This will not impact
the library structure so i assume we can include these changes in the
final v5 release. (It will simply add more footprints.)

That fine by me.  If we are going add new symbol libraries during v5, I
don't see any reason not to add new footprints and footprint libraries.
We should try to avoid wholesale renaming and/or moving of libraries and
their contents to avoid headaches for users.  If we have any major
library reorganizations, we can always create a v5 branch as we do for
the KiCad source.

Thank you for all of your hard work on the libraries.  They really have
come a long way since v4 was released.

Cheers,

Wayne


[1]: https://github.com/KiCad/kicad-symbols/issues/520

___
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

[Kicad-developers] Length tuning hotkeys

2018-05-20 Thread Jeff Young

The length tuning hotkeys (L for settings, 1 - 4 for increase/decrease 
spacing/amplitude) don’t work for me because the events are eaten by the status 
popup.  I suspect this is an OSX-specific issue, but I just wanted to check 
before making the fix OSX-only.

Steps:
Create a diff pair.
Route -> Tune Differential Pair Length
click on the diff pair and start dragging
hit one of the hotkeys (L should bring up the settings dialog; all it does is 
beep on Mac)

Thanks,
Jeff.
___
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] More default fields in schematic

Re: [Kicad-developers] More default fields in schematic

[Kicad-developers] rc2 tagged

Re: [Kicad-developers] Initial rc6 development.

Re: [Kicad-developers] 5.0 RC2 / release status

Re: [Kicad-developers] Initial rc6 development.

Re: [Kicad-developers] More default fields in schematic

Re: [Kicad-developers] More default fields in schematic

Re: [Kicad-developers] More default fields in schematic

Re: [Kicad-developers] More default fields in schematic

Re: [Kicad-developers] [patch] small tweaks to the pcbnew move exactly dialog strings

Re: [Kicad-developers] More default fields in schematic

[Kicad-developers] More default fields in schematic

[Kicad-developers] [patch] small tweaks to the pcbnew move exactly dialog strings

Re: [Kicad-developers] 5.0 RC2 / release status

[Kicad-developers] Length tuning hotkeys

16 matches

Site Navigation

Mail list logo

Footer information