Re: [Kicad-developers] Updating Paths

[Diego Herranz]

Hi, Seth

I can merge the kicad-symbols and kicad-footprints MRs later today when
we're OK to go.

Reviewing those two, the kicad-symbols MR contains many files. I don't
think that one looks correct.

Given that we're tidying this up, the repo for 3D models is
kicad-packages3D but the folder is 3dmodels. Would we want to make them
match by naming the folder packages3D or the repo kicad-3dmodels?

Thanks,
Diego


On Sun, 21 Mar 2021, 16:39 Jeff Young,  wrote:

> Woot!
>
> On 21 Mar 2021, at 14:41, Seth Hillbrand  wrote:
>
> Hi All-
>
> I've submitted a series of merge requests to coordinate renaming the
> default paths from "library" to  "symbols" and from "modules" to
> "footprints"
>
> https://gitlab.com/kicad/code/kicad/-/merge_requests/741
> https://gitlab.com/kicad/libraries/kicad-footprints/-/merge_requests/2618
> https://gitlab.com/kicad/libraries/kicad-symbols/-/merge_requests/3229
> https://gitlab.com/kicad/packaging/kicad-win-builder/-/merge_requests/116
>
> https://gitlab.com/kicad/packaging/kicad-ubuntu-builder/kicad-daily-package/-/merge_requests/3
> https://gitlab.com/kicad/packaging/kicad-fedora-builder/-/merge_requests/55
>
> These should be merged at the same time to minimize disruption to our
> daily packages.  Please look over any areas that affect you and let me know
> if anything looks amiss.
>
> Also, packagers not in our GitLab repository, please note that this is
> changing (hopefully today).
>
> -Seth
>
> --
> [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬
> Long Beach, CA
> www.kipro-pcb.comi...@kipro-pcb.com
> ___
> 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] Timestamps in footprint library files

[Diego Herranz]

Hi,

I've recently noticed (sometime in the past few months) that the footprint
library file format has changed to include a timestamp on each of the
elements (e.g. each line, each pad), rather than just a timestamp (tedit)
per footprint.

I guess this was taken into account but it makes "diifs" very hard to
interpret since any small change makes everything to change. And it makes
the review of submission to the official library a bit more difficult. E.g.
https://gitlab.com/kicad/libraries/kicad-footprints/-/merge_requests/2571/diffs?commit_id=16df40744c47cefb812e17372ca3d9de9ac7035b

First of all, I guess those new timestamps are necessary?
Assuming so, would it be possible to only update the timestamp for the
elements which have actually changed?
I don't really know how these timestamps are used so please forgive me if
anything I've said is silly.

Somehow related, the other thing that makes "diffs" hard to read is the
fact that the line order seems to change arbitrarily. Would there be a way
of keeping the same line order? That applies to other KiCad files and not
just footprint library files.

If anything here makes sense, I can raise issues/feature requests, but
wanted to discuss it first.

Thanks,
Diego
___
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] Auto-generated backup files: are they useful?

[Diego Herranz]

This possibility to save the last N backups would be useful. It is what
Altium does more or less and it has proven useful to me in the past.
Especially if you change your mind after 2h working on something which is
not going anywhere :)

Thanks,
Diego

On Tue, 30 Jun 2020 at 15:15, Wayne Stambaugh  wrote:

> Sounds like a great solution to me.
>
> On 6/30/20 10:12 AM, Jon Evans wrote:
> > JP, I agree that true backups are useful.
> >
> > Maybe even it is a good idea for KiCad to have a built-in backup
> function.
> >
> > I just don't think the current backup function is actually useful
> > because of my first point (backups are overwritten on each save).
> >
> > I would propose:
> >
> > 1) Remove the current backup file generation
> >
> > 2) Create a spec (in GitLab issue) for a better backup system that:
> >
> > - Can be turned on or off
> > - Backs up the whole project in a zip file
> > - Can keep the last N backups
> > - Runs on a schedule, not necessarily every time you click Save.
> >
> > Anyone opposed to this?
> >
> > -Jon
> >
> > On Tue, Jun 30, 2020 at 3:32 AM jp charras 
> wrote:
> >>
> >> Le 30/06/2020 à 00:13, hauptmech a écrit :
> >>>
> >>> While I agree that it is not KiCad's job to do archival backups or
> version control, I do think that KiCad should preserve the integrity of
> users data through a crash. Even better if the work between the last save
> and the crash is also preserved and recovered on restart.
> >>>
> >>> I have had to use the backup files to recover data in the past. I have
> no idea if that recovery was related to something that is now no longer a
> possible issue.
> >>>
> >>>
> >>> -Hauptmech
> >>>
> >>>
> >>
> >> I am also thinking a backup can be useful when something unexpected
> happens.
> >>
> >> Backups, like any security system, bothers you as long as you do not
> need to use them.
> >> But you are happy to find them in case of trouble.
> >>
> >> I like the way some CAD tools manage backup:
> >> only one zip archive is created (for instance projectname_backup.zip)
> and contains all saved files
> >> (in our case: *.kicad_sch (and sub paths) and .kicad_pcb)
> >> This is not a full project backup, just main files are saved.
> >>
> >> This is not invasive (only one file, or a few .zip if one want to keep
> last n saved versions)
> >> and is a security against  unexpected cases.
> >>
> >> For me, backups are like a accident insurance: you need them and you
> hope never use them.
> >>
> >> And about VCS use:
> >>
> >> Many good electronics guys do not even know what is it, and have never
> compiled any source code.
> >> Electronics world and Software world are not exactly the same world.
> >>
> >> --
> >> 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
> >
> > ___
> > 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] DRC rules

[Diego Herranz]

If the Inspect > Design Rules Checker dialog is going to be re-done, I'll
wait for that to happen and provide feedback if and when.

Thanks.

On Wed, 20 May 2020, 20:28 Jon Evans,  wrote:

> Copying and pasting Jeff's text from the forum since it wasn't in his
> original email to this list:
>
> "First the small text: the rule syntax WILL CHANGE. What’s there today is
> a PROTOTYPE. There will be NO TOOLS for migrating today’s rules to later
> rules. Think of it as a sandbox, not a work-in-progress."
>
> The kind of feedback we are most interested in at this point is around
> whether this kind of system can meet all your needs in terms of defining
> design rules.
>
> On Wed, May 20, 2020 at 3:24 PM Jon Evans  wrote:
>
>> You can file this as an issue if you'd like, but it's already planned to
>> completely re-do this UI at some point once we know what the actual DRC
>> implementation will be.
>>
>> We're not doing that yet because the new system is still very much in
>> flux.
>>
>> On Wed, May 20, 2020 at 3:22 PM Diego Herranz <
>> diegoherr...@diegoherranz.com> wrote:
>>
>>> Hi,
>>>
>>> It's nice getting a powerful rules system. Thank you for all the work.
>>>
>>> Just because it is slightly related to this. I find misleading that
>>> opening Inspect > Design Rules Checker, you get access to modify Minimum
>>> Track Width, Minimum via size and minimum uVia size. That is a subset of
>>> the Constraints in the revamped Board Setup dialog.
>>> Personally, I would remove them from Inspect > Design Rules Checker.
>>> If this was well received, let me know and I can raise a gitlab issue.
>>>
>>> Thanks,
>>> Diego
>>>
>>> On Wed, 20 May 2020 at 16:04, Evan Shultz  wrote:
>>>
>>>> Awesome! Thanks Jeff!
>>>>
>>>> I'm just starting to look at this and I have something quick to mention
>>>> regarding the UI: At Design Rules > Constraints in the 'Zone fill strategy'
>>>> section, the options are two checkboxes but they appear to be
>>>> mutually-exclusive. Should they be radio buttons instead?
>>>>
>>>> On Mon, May 18, 2020 at 12:21 PM  wrote:
>>>>
>>>>> Excellent, now it works :-)
>>>>>
>>>>> I'll test the big board tomorrow. For me this was the most important
>>>>> feature missing from kicad, thanks for making it work.
>>>>>
>>>>> regards,
>>>>>
>>>>> Mark.
>>>>>
>>>>> Jeff Young  wrote:
>>>>>
>>>>> Congrats on the first bug!
>>>>>
>>>>> Actually 4 separate ones: the caching mechanism was causing
>>>>> the rules to not be loaded when the board was read, the zone cutout stuff
>>>>> wasn???t fully hooked up to the new rules engine, there???s no
>>>>> "Net-(C1-Pad2)" netclass in the document (only "Net-(C1-Pad1)???), and the
>>>>> code responded poorly to failing to find a net (putting subsequent nets
>>>>> off-by-one).
>>>>>
>>>>> The third one is yours. ;)
>>>>>
>>>>> Fixes for the other three are now in master (if you build your
>>>>> own); otherwise you can get them from tonight???s nightly.
>>>>>
>>>>> Cheers,
>>>>> Jeff.
>>>>>
>>>>> > On 18 May 2020, at 12:01, mdoes...@xs4all.nl wrote:
>>>>> >
>>>>> > Sorry, forgot to attach the project.
>>>>> >
>>>>> >
>>>>> > 
>>>>>
>>>>> ___
>>>>> 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] DRC rules

[Diego Herranz]

Hi,

It's nice getting a powerful rules system. Thank you for all the work.

Just because it is slightly related to this. I find misleading that opening
Inspect > Design Rules Checker, you get access to modify Minimum Track
Width, Minimum via size and minimum uVia size. That is a subset of the
Constraints in the revamped Board Setup dialog.
Personally, I would remove them from Inspect > Design Rules Checker.
If this was well received, let me know and I can raise a gitlab issue.

Thanks,
Diego

On Wed, 20 May 2020 at 16:04, Evan Shultz  wrote:

> Awesome! Thanks Jeff!
>
> I'm just starting to look at this and I have something quick to mention
> regarding the UI: At Design Rules > Constraints in the 'Zone fill strategy'
> section, the options are two checkboxes but they appear to be
> mutually-exclusive. Should they be radio buttons instead?
>
> On Mon, May 18, 2020 at 12:21 PM  wrote:
>
>> Excellent, now it works :-)
>>
>> I'll test the big board tomorrow. For me this was the most important
>> feature missing from kicad, thanks for making it work.
>>
>> regards,
>>
>> Mark.
>>
>> Jeff Young  wrote:
>>
>> Congrats on the first bug!
>>
>> Actually 4 separate ones: the caching mechanism was causing the
>> rules to not be loaded when the board was read, the zone cutout stuff
>> wasn???t fully hooked up to the new rules engine, there???s no
>> "Net-(C1-Pad2)" netclass in the document (only "Net-(C1-Pad1)???), and the
>> code responded poorly to failing to find a net (putting subsequent nets
>> off-by-one).
>>
>> The third one is yours. ;)
>>
>> Fixes for the other three are now in master (if you build your
>> own); otherwise you can get them from tonight???s nightly.
>>
>> Cheers,
>> Jeff.
>>
>> > On 18 May 2020, at 12:01, mdoes...@xs4all.nl wrote:
>> >
>> > Sorry, forgot to attach the project.
>> >
>> >
>> > 
>>
>> ___
>> 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] Minimum Boost version

[Diego Herranz]

A man can dream xD

On Mon, 21 Oct 2019 at 23:15, Jon Evans  wrote:

>
> On Mon, Oct 21, 2019 at 5:53 PM Diego Herranz <
> diegoherr...@diegoherranz.com> wrote:
>
>>
>> It looks like by the time 6.0 is out, Ubuntu 16.04 may still be
>> officially supported. Just something to have in mind.
>>
>
> I love your optimism :)
>
___
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] Minimum Boost version

[Diego Herranz]

I understand and that'll mean I'll have to move on, which in my case, it's
not a big issue. I was waiting until 20.04 LTS, though :)

>> The stable version of KiCad will always build with 16.04.

It looks like by the time 6.0 is out, Ubuntu 16.04 may still be officially
supported. Just something to have in mind.

Cheers,
Diego

On Mon, 21 Oct 2019, 21:11 Nick Østergaard,  wrote:

> You can still run 5.1 on 16.04. If you want bleeding edge, don't lock
> yourself down with a "stable" system.
>
> On Mon, 21 Oct 2019 at 21:37, Diego Herranz
>  wrote:
> >
> > I see. Are those dates when the respective OS support finishes or when
> we stop supporting them?
> > I was under the impression it is the former (although it is not fully
> clear) in which case that date is wrong.
> >
> > Thanks,
> > Diego
> >
> > On Mon, 21 Oct 2019 at 20:16, Ian McInerney 
> wrote:
> >>
> >> The listing I used when looking at whether our supported OS's had Boost
> 1.59 were the dates given here:
> http://kicad-pcb.org/help/system-requirements/#_gnulinux. On that page,
> it says that our support for 16.04 ended in April.
> >>
> >> -Ian
> >>
> >> On Mon, Oct 21, 2019 at 8:03 PM Diego Herranz <
> diegoherr...@diegoherranz.com> wrote:
> >>>
> >>> I wasn't getting any nightly package update lately and checking [1]
> I've just noticed this boost bump has left Ubuntu 16.04 (Xenial) out.
> >>> Ubuntu 16.04 will be supported until April 2021 [2].
> >>>
> >>> Was this overlooked when checking distros? Or was it a deliberate
> decision? Is there anything that can be done?
> >>> I've been planning to move to a newer Ubuntu LTS release for some time
> but didn't really have the need while it is supported (everything stable
> and working very well).
> >>> I guess there may be more people in a situation similar to mine.
> >>>
> >>> Cheers,
> >>> Diego
> >>>
> >>> [1]
> https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-dev-nightly
> >>> [2]
> https://en.wikipedia.org/wiki/Ubuntu_version_history#Table_of_versions
> >>>
> >>> On Thu, 3 Oct 2019 at 19:59, Wayne Stambaugh 
> wrote:
> >>>>
> >>>> 10/2/2019 8:34 PM, Wayne Stambaugh wrote:
> >>>> > On 9/27/19 12:20 AM, Carsten Schoenert wrote:
> >>>> >> Hi,
> >>>> >>
> >>>> >> Am 26.09.19 um 22:26 schrieb Ian McInerney:
> >>>> >>> Ping. Is there any opposition to bumping the minimum Boost
> version to
> >>>> >>> 1.59?
> >>>> >> I still see no technical need to increase the minimal version for
> Boost.
> >>>> >>
> >>>> >
> >>>> > The boost version used in Debian old stable is 1.62.  I think 1.59
> is a
> >>>> > pretty safe bet at this point for the development version.  For the
> 5.1
> >>>> > branch, we should keep the current version unless we are planning to
> >>>> > back port any of the testing features which were the primary reason
> for
> >>>> > the version bump request.  I will make the change as soon as I get a
> >>>> > chance, we can always revert it if it causes too much grief.
> >>>> >
> >>>> > Cheers,
> >>>> >
> >>>> > Wayne
> >>>> >
> >>>>
> >>>> I bumped the Boost version to 1.59.  If this causes any major
> headaches,
> >>>> I can always revert it.  Before we go using any new Boost stuff,
> please
> >>>> let the dust settle on the version bump change so we don't have to
> back
> >>>> out a bunch of changes.
> >>>>
> >>>> 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
> >>>
> >>> ___
> >>> 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] Minimum Boost version

[Diego Herranz]

I see. Are those dates when the respective OS support finishes or when we
stop supporting them?
I was under the impression it is the former (although it is not fully
clear) in which case that date is wrong.

Thanks,
Diego

On Mon, 21 Oct 2019 at 20:16, Ian McInerney 
wrote:

> The listing I used when looking at whether our supported OS's had Boost
> 1.59 were the dates given here:
> http://kicad-pcb.org/help/system-requirements/#_gnulinux. On that page,
> it says that our support for 16.04 ended in April.
>
> -Ian
>
> On Mon, Oct 21, 2019 at 8:03 PM Diego Herranz <
> diegoherr...@diegoherranz.com> wrote:
>
>> I wasn't getting any nightly package update lately and checking [1] I've
>> just noticed this boost bump has left Ubuntu 16.04 (Xenial) out.
>> Ubuntu 16.04 will be supported until April 2021 [2].
>>
>> Was this overlooked when checking distros? Or was it a deliberate
>> decision? Is there anything that can be done?
>> I've been planning to move to a newer Ubuntu LTS release for some time
>> but didn't really have the need while it is supported (everything stable
>> and working very well).
>> I guess there may be more people in a situation similar to mine.
>>
>> Cheers,
>> Diego
>>
>> [1] https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-dev-nightly
>> [2]
>> https://en.wikipedia.org/wiki/Ubuntu_version_history#Table_of_versions
>>
>> On Thu, 3 Oct 2019 at 19:59, Wayne Stambaugh 
>> wrote:
>>
>>> 10/2/2019 8:34 PM, Wayne Stambaugh wrote:
>>> > On 9/27/19 12:20 AM, Carsten Schoenert wrote:
>>> >> Hi,
>>> >>
>>> >> Am 26.09.19 um 22:26 schrieb Ian McInerney:
>>> >>> Ping. Is there any opposition to bumping the minimum Boost version to
>>> >>> 1.59?
>>> >> I still see no technical need to increase the minimal version for
>>> Boost.
>>> >>
>>> >
>>> > The boost version used in Debian old stable is 1.62.  I think 1.59 is a
>>> > pretty safe bet at this point for the development version.  For the 5.1
>>> > branch, we should keep the current version unless we are planning to
>>> > back port any of the testing features which were the primary reason for
>>> > the version bump request.  I will make the change as soon as I get a
>>> > chance, we can always revert it if it causes too much grief.
>>> >
>>> > Cheers,
>>> >
>>> > Wayne
>>> >
>>>
>>> I bumped the Boost version to 1.59.  If this causes any major headaches,
>>> I can always revert it.  Before we go using any new Boost stuff, please
>>> let the dust settle on the version bump change so we don't have to back
>>> out a bunch of changes.
>>>
>>> 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
>>>
>> ___
>> 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] Minimum Boost version

[Diego Herranz]

I wasn't getting any nightly package update lately and checking [1] I've
just noticed this boost bump has left Ubuntu 16.04 (Xenial) out.
Ubuntu 16.04 will be supported until April 2021 [2].

Was this overlooked when checking distros? Or was it a deliberate decision?
Is there anything that can be done?
I've been planning to move to a newer Ubuntu LTS release for some time but
didn't really have the need while it is supported (everything stable and
working very well).
I guess there may be more people in a situation similar to mine.

Cheers,
Diego

[1] https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-dev-nightly
[2] https://en.wikipedia.org/wiki/Ubuntu_version_history#Table_of_versions

On Thu, 3 Oct 2019 at 19:59, Wayne Stambaugh  wrote:

> 10/2/2019 8:34 PM, Wayne Stambaugh wrote:
> > On 9/27/19 12:20 AM, Carsten Schoenert wrote:
> >> Hi,
> >>
> >> Am 26.09.19 um 22:26 schrieb Ian McInerney:
> >>> Ping. Is there any opposition to bumping the minimum Boost version to
> >>> 1.59?
> >> I still see no technical need to increase the minimal version for Boost.
> >>
> >
> > The boost version used in Debian old stable is 1.62.  I think 1.59 is a
> > pretty safe bet at this point for the development version.  For the 5.1
> > branch, we should keep the current version unless we are planning to
> > back port any of the testing features which were the primary reason for
> > the version bump request.  I will make the change as soon as I get a
> > chance, we can always revert it if it causes too much grief.
> >
> > Cheers,
> >
> > Wayne
> >
>
> I bumped the Boost version to 1.59.  If this causes any major headaches,
> I can always revert it.  Before we go using any new Boost stuff, please
> let the dust settle on the version bump change so we don't have to back
> out a bunch of changes.
>
> 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
>
___
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] CERN Open Days

[Diego Herranz]

Hi, all

The CERN Open Days (https://opendays.cern/) will be held this weekend.
I'll be there on Sunday. Will any developer or librarian be there? Or any
of the guys working at CERN?

Just for a quick hello and putting faces to names.

Thanks.

Cheers,
Diego
___
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] Board statistics dialog

[Diego Herranz]

>> About the weight estimation of the pcb, considering that in the
(probably near) future a board stackup definition with copper thickness and
dielectric properties will be a part of pcbnew, the weight calculation as
another data of the statistics window will become possible, once the
density of the materials is one of the columns that define the stackup.

Sounds nice. Not sure whether it may be too complex, though.

>> By the way, a statistics report like the one of pcbnew,  with number of
nets and number of components would be useful also in eeschema. Its typical
usage would be to estimate he complexity (and cost) of pcb routing. I'm
asking myself if Alexander's code can be extended to be used also in
eeschema, so that we can have an almost identical "statistics" window there
with minimal effort and consistent interface.

+1

Thanks,
Diego



On Mon, 29 Jul 2019, 21:19 Dino Ghilardi,  wrote:

> Hi,
>
> About the weight estimation of the pcb, considering that in the (probably
> near) future a board stackup definition with copper thickness and
> dielectric properties will be a part of pcbnew, the weight calculation as
> another data of the statistics window will become possible, once the
> density of the materials is one of the columns that define the stackup.
>
> By the way, a statistics report like the one of pcbnew,  with number of
> nets and number of components would be useful also in eeschema. Its typical
> usage would be to estimate he complexity (and cost) of pcb routing. I'm
> asking myself if Alexander's code can be extended to be used also in
> eeschema, so that we can have an almost identical "statistics" window there
> with minimal effort and consistent interface.
>
> Cheers,
> Dino.
>
> Il Lun 29 Lug 2019 20:24 Diego Herranz  ha
> scritto:
>
>> I agree both are useful.
>> (Max width x Max height) area is useful as a worst case scenario for
>> manufacturing: it may end up being better depending on the shape of the
>> board and panel design.
>> Regarding actual area, I'm working on a project right now where I need to
>> provide an estimation of the weight of the board. Knowing the actual area
>> of FR4 is useful.
>>
>> Thanks!
>>
>>
>>
>>
>> On Mon, 29 Jul 2019 at 14:33, Wayne Stambaugh 
>> wrote:
>>
>>> I agree.  There is utility in both the actual area of a board and the
>>> manufacturing area.  The latter should be fairly trivial to implement.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 7/29/19 9:30 AM, Clemens Koller wrote:
>>> > Hi!
>>> > I think it could be good to see both:
>>> > - The actual PCB area of the outline (well, without drills).
>>> > - The max-width * max-height which is usually what you have to pay for
>>> when you get it manufactured.
>>> > The second one could be also an interesting task to calculate if you
>>> have an odd shaped polygonal outline.
>>> >
>>> > Regards,
>>> > Clemens
>>> >
>>> >
>>> > On 29/07/2019 14.43, Alexander Shuklin wrote:
>>> >>   Hi! I've been asked to do actually PCB area calculation. Since
>>> English is not my first language, maybe I just miss-understood. Do you
>>> mean, that area has to be just max width * max height? I never seen that,
>>> but there's a message in thread about sometimes you need proper area.
>>> >> I utilized kicad outline functions for that.
>>> >>
>>> >>
>>> >> Понедельник, 29 июля 2019, 15:35 +03:00 от Mark Roszko <
>>> mark.ros...@gmail.com>:
>>> >>
>>> >> Huh, looking at the statistics code, it actually tries and find
>>> the more "detailed area" of a board based on any polygonal outline.
>>> >> Is there any value in it this way? PCB manufacturing charges are
>>> generally per-square area  because ultimately the price is on panel space
>>> you are using.
>>> >>
>>> >> On Sat, Jul 27, 2019 at 5:07 AM Diego Herranz <
>>> diegoherr...@diegoherranz.com >> e.mail.ru/compose/?mailto=mailto%3adiegoherr...@diegoherranz.com>>
>>> wrote:
>>> >>
>>> >> I've been testing this dialog and I think it is a nice
>>> addition. Thanks!
>>> >>
>>> >> There seems to be something wrong with the area calculation,
>>> though. See image below:
>>> >> area.png
>>> >>
>>> &

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Diego Herranz]

I agree both are useful.
(Max width x Max height) area is useful as a worst case scenario for
manufacturing: it may end up being better depending on the shape of the
board and panel design.
Regarding actual area, I'm working on a project right now where I need to
provide an estimation of the weight of the board. Knowing the actual area
of FR4 is useful.

Thanks!




On Mon, 29 Jul 2019 at 14:33, Wayne Stambaugh  wrote:

> I agree.  There is utility in both the actual area of a board and the
> manufacturing area.  The latter should be fairly trivial to implement.
>
> Cheers,
>
> Wayne
>
> On 7/29/19 9:30 AM, Clemens Koller wrote:
> > Hi!
> > I think it could be good to see both:
> > - The actual PCB area of the outline (well, without drills).
> > - The max-width * max-height which is usually what you have to pay for
> when you get it manufactured.
> > The second one could be also an interesting task to calculate if you
> have an odd shaped polygonal outline.
> >
> > Regards,
> > Clemens
> >
> >
> > On 29/07/2019 14.43, Alexander Shuklin wrote:
> >>   Hi! I've been asked to do actually PCB area calculation. Since
> English is not my first language, maybe I just miss-understood. Do you
> mean, that area has to be just max width * max height? I never seen that,
> but there's a message in thread about sometimes you need proper area.
> >> I utilized kicad outline functions for that.
> >>
> >>
> >> Понедельник, 29 июля 2019, 15:35 +03:00 от Mark Roszko <
> mark.ros...@gmail.com>:
> >>
> >> Huh, looking at the statistics code, it actually tries and find the
> more "detailed area" of a board based on any polygonal outline.
> >> Is there any value in it this way? PCB manufacturing charges are
> generally per-square area  because ultimately the price is on panel space
> you are using.
> >>
> >> On Sat, Jul 27, 2019 at 5:07 AM Diego Herranz <
> diegoherr...@diegoherranz.com  e.mail.ru/compose/?mailto=mailto%3adiegoherr...@diegoherranz.com>> wrote:
> >>
> >> I've been testing this dialog and I think it is a nice
> addition. Thanks!
> >>
> >> There seems to be something wrong with the area calculation,
> though. See image below:
> >> area.png
> >>
> >> Thanks,
> >> Diego
> >>
> >> On Tue, 23 Jul 2019 at 11:18, Ian McInerney <
> ian.s.mciner...@ieee.org  e.mail.ru/compose/?mailto=mailto%3aian.s.mciner...@ieee.org>> wrote:
> >>
> >> Alexander,
> >>
> >> Instead of declaring the 2 static variables separately, I
> would suggest creating a struct for the settings then store that as the
> static variable. For an example of this see the dialog_create_array.cpp
> file. This way if any new options must be added in the future, they can
> just be added to the struct very easily.
> >>
> >> -Ian
> >>
> >> On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin <
> jasura...@mail.ru >
> wrote:
> >>
> >> Damn ><,
> >> don't use last patch, please.
> >> It doesn't count total vias amount. Use this one.
> >>
> >>
> >> Понедельник, 22 июля 2019, 22:14 +03:00 от
> Alexander Shuklin  e.mail.ru/compose/?mailto=mailto%3ajasura...@mail.ru>>:
> >>
> >> Hi,
> >> thanks for sharing experience, as I never used that
> translations or wxWidgets before. And I have no idea where else could I get
> that information. ))
> >> So, there's the patch with vias information and
> some tiny improvements.
> >>
> >>
> >> Понедельник, 22 июля 2019, 13:34 +03:00 от Ian
> McInerney  e.mail.ru/compose/?mailto=mailto%3aian.s.mciner...@ieee.org>>:
> >>
> >>
> >>
> >> On Mon, Jul 22, 2019 at 11:03 AM Dino Ghilardi <
> dino.ghila...@ieee.org <
> http://e.mail.ru/compose/?mailto=mailto%3adino.ghila...@ieee.org>> wrote:
> >>
> >> Hi Alexander,
> >>
> >> One possible solution for the translation
> could be put the ":" in a
> >> different column of the table and
> right-align the field description text
> >> (so all the colons will be alig

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Diego Herranz]

Done: https://bugs.launchpad.net/kicad/+bug/1838325

Thanks!

On Sun, 28 Jul 2019 at 15:04, Wayne Stambaugh  wrote:

> Diego,
>
> Please file a bug report for this and include the board file that causes
> this so it's easier for us to figure out what is going on.
>
> Thanks,
>
> Wayne
>
> On 7/27/19 5:06 AM, Diego Herranz wrote:
> > I've been testing this dialog and I think it is a nice addition. Thanks!
> >
> > There seems to be something wrong with the area calculation, though. See
> > image below:
> > area.png
> >
> > Thanks,
> > Diego
> >
> > On Tue, 23 Jul 2019 at 11:18, Ian McInerney  > <mailto:ian.s.mciner...@ieee.org>> wrote:
> >
> > Alexander,
> >
> > Instead of declaring the 2 static variables separately, I would
> > suggest creating a struct for the settings then store that as the
> > static variable. For an example of this see the
> > dialog_create_array.cpp file. This way if any new options must be
> > added in the future, they can just be added to the struct very
> easily.
> >
> > -Ian
> >
> > On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin  > <mailto:jasura...@mail.ru>> wrote:
> >
> > Damn ><,
> > don't use last patch, please.
> > It doesn't count total vias amount. Use this one.
> >
> >
> > Понедельник, 22 июля 2019, 22:14 +03:00 от Alexander Shuklin
> > mailto:jasura...@mail.ru>>:
> >
> > Hi,
> > thanks for sharing experience, as I never used that
> > translations or wxWidgets before. And I have no idea where
> > else could I get that information. ))
> > So, there's the patch with vias information and some tiny
> > improvements.
> >
> >
> > Понедельник, 22 июля 2019, 13:34 +03:00 от Ian McInerney
> >  > <mailto:ian.s.mciner...@ieee.org>>:
> >
> >
> >
> > On Mon, Jul 22, 2019 at 11:03 AM Dino Ghilardi
> >  > <
> http://e.mail.ru/compose/?mailto=mailto%3adino.ghila...@ieee.org>>
> > wrote:
> >
> > Hi Alexander,
> >
> > One possible solution for the translation could be
> > put the ":" in a
> > different column of the table and right-align the
> > field description text
> > (so all the colons will be aligned). A rapid google
> > search shown that in
> > French and Vietnamese there should be a space before
> > the colon, while in
> > the rest of the world there is not, so having the
> > translation for the
> > ":" word seems to make sense. Also another question
> > arises: Is there
> > some language in which the colon should be another
> > character before the
> > word? (I'm thinking about spanish where the question
> > mark upside-down
> > appears before a question...)? ...conclusion:
> > keeping "Height:" and
> > "Height" as two different words seem to be the
> > solution that gives
> > maximum flexibility to translators.
> >
> >
> > This actually doesn't give them as much flexibility.
> > When translations are done, they need to examine the
> > entire string that needs translating, so the ":"
> > character should be included in the string. Separating
> > out the two portions is the equivalent of saying that
> > every lanugage will follow the same compositional rules.
> >
> >
> > Another possible solution (probably better then the
> > one above since it
> > just removes the problem) is to remove the ":" and
> > have the cell borders
> > in a different color, just like the tables in the
> > "board setup" dialog
> > (so that you can also ta

Re: [Kicad-developers] Bus upgrades merge

[Diego Herranz]

Thanks, JP. I've created https://bugs.launchpad.net/kicad/+bug/1838140.

Cheers,
Diego

On Sat, 27 Jul 2019 at 15:03, jp charras  wrote:

> Le 27/07/2019 à 14:35, Diego Herranz a écrit :
> > Hi, all.
> >
> > I'm using nightlies and facing a weird bug with buses. I was wondering
> > whether it can be related to these bus upgrades.
> >
> > I've got a bus:
> > ROW0, ROW1, ROW2, ROW3, ROW4, ROW5, ROW6, ROW7, which on the PCB layout
> > becomes
> > ROW0, ROW0, ROW0, ROW0, ROW0, ROW0, ROW0, ROW7 ???
> > It seems to be semi-random and I've seen other combinations too.
> >
> > I've managed to reduce the SCH to a minimal example (link below).
> > Further changes to this seem to fix it somehow, so I couldn't reduce it
> > anymore.
> > Note that one of the symbols is not on the official library so I've
> > included a local library.
> > I've tried replacing that symbol for a standard header, but that seems
> > to fix the problem, although I can't see anything wrong with the symbol
> > itself.
> >
> > Can anyone confirm that it is a bug and not something I'm doing wrong?
> > Is it related to this upgrade?
> > Please let me know how to proceed. I can report the bug on launchpad.
> >
> > Many thanks!
>
> I confirm there is a serious issue shown by this sample: the netlist is
> broken.
> Moreover, when I try to add a bus name ("ROW[0..7]") to the bus,
> Eeschema crashes.
> Looks like the bug has something to do with hierarchical labels.
>
> I do not see issues with the schematic.
>
> Please, report the bug on launchpad.
>
> >
> >  bus_bug.zip
> > <
> https://drive.google.com/file/d/1K7tWvM5M8F-Y-2bBwAPGBKG7O452hcrL/view?usp=drive_web
> >
> >
> >
> > Application: KiCad
> > Version: 6.0.0-unknown-6b031d9~100~ubuntu16.04.1, release build
> > Libraries:
> > wxWidgets 3.0.2
> > libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
> > Platform: Linux 4.4.0-157-generic x86_64, 64 bit, Little endian,
> wxGTK
> > Build Info:
> > wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
> > GTK+ 2.24
> > Boost: 1.58.0
> > OpenCASCADE Community Edition: 6.8.0
> > Curl: 7.47.0
> > Compiler: GCC 5.4.0 with C++ ABI 1009
> > Build settings:
> > KICAD_SCRIPTING=ON
> > KICAD_SCRIPTING_MODULES=ON
> > KICAD_SCRIPTING_PYTHON3=OFF
> > KICAD_SCRIPTING_WXPYTHON=ON
> > KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
> > KICAD_SCRIPTING_ACTION_MENU=ON
> > BUILD_GITHUB_PLUGIN=ON
> > KICAD_USE_OCE=ON
> > KICAD_USE_OCC=OFF
> > KICAD_SPICE=ON
> >
> >
> > On Wed, 3 Apr 2019 at 19:01, Jon Evans  > <mailto:j...@craftyjon.com>> wrote:
> >
> > I can move to stdlib regex; I'll look in to that later this week.
> >
> > On Wed, Apr 3, 2019 at 1:44 PM Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> >
> > Tom,
> >
> > On 4/3/2019 1:34 PM, Tomasz Wlostowski wrote:
> > > On 02/04/2019 17:27, Wayne Stambaugh wrote:
> > >> We should always be using wxLogTrace.  Using printf and cout
> are
> > >> meaningless on windows and wxLogDebug means that your
> > debugging output
> > >> is always spewed on debug builds even when it's not needed.
> > I haven't
> > >> made the draconian move of making this policy but maybe I
> > should since
> > >> we seem to be leaving lots of debugging code in all manner of
> > formats in
> > >> our source code.
> > >>
> > > @Wayne Can I somehow use wxLogTrace() on release builds?
> >
> > Unfortunately no.  All of the wxLog macros compile away in
> > release builds.
> >
> > >
> > > @Jon I just tried to build today's master and it complained
> about
> > > missing boost::regex library. There is regexp support in
> > libstdc++ in
> > > C++11, why go for boost?
> >
> > I got bit by this too on Debian.  I think boost packaging on
> > Debian is
> > in a state of flux the moment.  I see the boost-dev package is
> being
> > held back even when I do a dist-upgrade.  This is (was) the
> &g

Re: [Kicad-developers] Bus upgrades merge

[Diego Herranz]

Hi, all.

I'm using nightlies and facing a weird bug with buses. I was wondering
whether it can be related to these bus upgrades.

I've got a bus:
ROW0, ROW1, ROW2, ROW3, ROW4, ROW5, ROW6, ROW7, which on the PCB layout
becomes
ROW0, ROW0, ROW0, ROW0, ROW0, ROW0, ROW0, ROW7 ???
It seems to be semi-random and I've seen other combinations too.

I've managed to reduce the SCH to a minimal example (link below). Further
changes to this seem to fix it somehow, so I couldn't reduce it anymore.
Note that one of the symbols is not on the official library so I've
included a local library.
I've tried replacing that symbol for a standard header, but that seems to
fix the problem, although I can't see anything wrong with the symbol itself.

Can anyone confirm that it is a bug and not something I'm doing wrong?
Is it related to this upgrade?
Please let me know how to proceed. I can report the bug on launchpad.

Many thanks!

 bus_bug.zip



Application: KiCad
> Version: 6.0.0-unknown-6b031d9~100~ubuntu16.04.1, release build
> Libraries:
> wxWidgets 3.0.2
> libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
> Platform: Linux 4.4.0-157-generic x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
> Boost: 1.58.0
> OpenCASCADE Community Edition: 6.8.0
> Curl: 7.47.0
> Compiler: GCC 5.4.0 with C++ ABI 1009
> Build settings:
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_PYTHON3=OFF
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_USE_OCC=OFF
> KICAD_SPICE=ON


On Wed, 3 Apr 2019 at 19:01, Jon Evans  wrote:

> I can move to stdlib regex; I'll look in to that later this week.
>
> On Wed, Apr 3, 2019 at 1:44 PM Wayne Stambaugh 
> wrote:
>
>> Tom,
>>
>> On 4/3/2019 1:34 PM, Tomasz Wlostowski wrote:
>> > On 02/04/2019 17:27, Wayne Stambaugh wrote:
>> >> We should always be using wxLogTrace.  Using printf and cout are
>> >> meaningless on windows and wxLogDebug means that your debugging output
>> >> is always spewed on debug builds even when it's not needed.  I haven't
>> >> made the draconian move of making this policy but maybe I should since
>> >> we seem to be leaving lots of debugging code in all manner of formats
>> in
>> >> our source code.
>> >>
>> > @Wayne Can I somehow use wxLogTrace() on release builds?
>>
>> Unfortunately no.  All of the wxLog macros compile away in release builds.
>>
>> >
>> > @Jon I just tried to build today's master and it complained about
>> > missing boost::regex library. There is regexp support in libstdc++ in
>> > C++11, why go for boost?
>>
>> I got bit by this too on Debian.  I think boost packaging on Debian is
>> in a state of flux the moment.  I see the boost-dev package is being
>> held back even when I do a dist-upgrade.  This is (was) the package that
>> used to pull in all of boost and it's libraries.  Maybe there is a new
>> meta package that does that.  I just installed boost-regex-dev and all
>> was well.
>>
>> >
>> > 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] [PATCH] Board statistics dialog

[Diego Herranz]

I've been testing this dialog and I think it is a nice addition. Thanks!

There seems to be something wrong with the area calculation, though. See
image below:
[image: area.png]

Thanks,
Diego

On Tue, 23 Jul 2019 at 11:18, Ian McInerney 
wrote:

> Alexander,
>
> Instead of declaring the 2 static variables separately, I would suggest
> creating a struct for the settings then store that as the static variable.
> For an example of this see the dialog_create_array.cpp file. This way if
> any new options must be added in the future, they can just be added to the
> struct very easily.
>
> -Ian
>
> On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin 
> wrote:
>
>> Damn ><,
>> don't use last patch, please.
>> It doesn't count total vias amount. Use this one.
>>
>>
>> Понедельник, 22 июля 2019, 22:14 +03:00 от Alexander Shuklin <
>> jasura...@mail.ru>:
>>
>> Hi,
>> thanks for sharing experience, as I never used that translations or
>> wxWidgets before. And I have no idea where else could I get that
>> information. ))
>> So, there's the patch with vias information and some tiny improvements.
>>
>>
>> Понедельник, 22 июля 2019, 13:34 +03:00 от Ian McInerney <
>> ian.s.mciner...@ieee.org>:
>>
>>
>>
>> On Mon, Jul 22, 2019 at 11:03 AM Dino Ghilardi > >
>> wrote:
>>
>> Hi Alexander,
>>
>> One possible solution for the translation could be put the ":" in a
>> different column of the table and right-align the field description text
>> (so all the colons will be aligned). A rapid google search shown that in
>> French and Vietnamese there should be a space before the colon, while in
>> the rest of the world there is not, so having the translation for the
>> ":" word seems to make sense. Also another question arises: Is there
>> some language in which the colon should be another character before the
>> word? (I'm thinking about spanish where the question mark upside-down
>> appears before a question...)? ...conclusion: keeping "Height:" and
>> "Height" as two different words seem to be the solution that gives
>> maximum flexibility to translators.
>>
>>
>> This actually doesn't give them as much flexibility. When translations
>> are done, they need to examine the entire string that needs translating, so
>> the ":" character should be included in the string. Separating out the two
>> portions is the equivalent of saying that every lanugage will follow the
>> same compositional rules.
>>
>>
>> Another possible solution (probably better then the one above since it
>> just removes the problem) is to remove the ":" and have the cell borders
>> in a different color, just like the tables in the "board setup" dialog
>> (so that you can also take a look at that code to solve also the color
>> problem seeing how it was solved there). The advantage of this approach
>> is also having a more consistent "look" through all the dialogs.
>>
>>
>>
>> P.S. (a little bit off-topic):
>> If you move the statistic window and check/uncheck one of the checkboxes
>> ("subctract holes" or "Exclude components...") the window "jumps" to
>> the center of the screen (its default position on open): do you have
>> also this behaviour or it is just on my debian-linux with gtk3?
>>
>>
>> Cheers,
>> Dino.
>>
>> On 22/07/19 10:13, Alexander Shuklin wrote:
>> > Hi!
>> > I'll have a look to add vias count to dialog.
>> > There's some questions:
>> >
>> > 1)I don't have too much experience with wxdialogs. There was commit on
>> > master, which says:
>> >  >> remove settings for fg/bg color: the result is unpredictable: was
>> > black texts on black background on my computer.
>> > And now I have all tables with data just in white boxes. Is it how it
>> > meant to be, or just some misbehavior on different systems? I use
>> > archlinux x64 OS.
>> > there's screenshot in attachment
>> >
>> > 2) Can we use something like _( "Height" ) + ":" for translation, not
>> _(
>> > "Height:" )? As far as I understand, now we will need to have 2
>> > translations, first for "Height" and second for "Height:" but that's
>> > basically same word.
>> >
>> > Воскресенье, 21 июля 2019, 23:42 +03:00 от Dino Ghilardi
>> > > >:
>> >
>> > Makes sense.
>> > Instead of a generic "via count" a more complete table similar to
>> the
>> > one generated in the drill report file could be useful, but may be
>> it
>> > can became quite long if a lot of different drill sizes are used
>> (ok,
>> > scrollbars are made to handle that).
>> > Also having "vias", "blind vias" and "microvias" count man make
>> sense
>> > (or at least having something like "microvias used: yes/no"), just
>> to
>> > have in board statistics the information about the need of an
>> advanced
>> > pcb manufacturing process.
>> >
>> >
>> > Cheers,
>> > Dino.
>> >
>> >
>> > On 21/07/19 20:54, Mark Roszko wrote:
>> >  > > Since making every 

Re: [Kicad-developers] Ratsnest options

[Diego Herranz]

>> As far as Preferences, I agree that it’s the right place for
curved/straight (well, actually I’d be inclined to just offer curved, but I
already lost that fight)
Quick question: is curved ratsnest the default? I think it looks much
better so I'd vote to make it the default if it isn't, especially if that
option gets hidden into preferences.

Thanks,
Diego

On Thu, 13 Jun 2019 at 15:27, Jeff Young  wrote:

> So I’ll be the contrary one.
>
> First, I do agree with getting the number of access points down.
>
> However, I find myself turning the ratsnest on and off a lot.  And the
> toolbar is /much/ easier than the layers palette for that.
>
> As far as Preferences, I agree that it’s the right place for
> curved/straight (well, actually I’d be inclined to just offer curved, but I
> already lost that fight).  But why have shown/not shown in preferences?
> And for that matter units and coordinates.  These aren’t really
> set-and-forget types of things, and the options toolbar is both easier to
> access and more visible for inspection.
>
> So how about removing in/mm and polar/cartesian from Preferences (and
> leaving them and ratsnest on/off in the options toolbar), rather than
> moving ratsnest on/off to Preferences?
>
> Cheers,
> Jeff.
>
> On 13 Jun 2019, at 14:47, Wayne Stambaugh  wrote:
>
> On 6/13/19 9:35 AM, Seth Hillbrand wrote:
>
> On 2019-06-12 22:50, Jon Evans wrote:
>
> I like that set of options. It fits in to my plan of absorbing as much
> as possible from the left toolbar into the layer widget as part of my
> overhaul of that part of the UI.
> I also think it would be totally fine to have it *only* in the layer
> widget, because we don't duplicate the other object visibility
> controls in Preferences.
>
>
> I like this even better.  Single location, placed with all view options.
>  Anyone have objections to this idea?
>
>
> The "Show ratsnest with curved lines" checkbox fits in to Preferences
> (and not the left toolbar) in my mind, because it seems like a "set
> and forget" kind of setting, not one that I would toggle on and off
> all the time while I'm working on a board (but maybe others
> disagree??)
>
>
> I tend to agree with this as well.  I've placed it in the preferences
> for now and I think removing it from the View menu and the left toolbar
> is a good idea.  Any objections to this idea?
>
> -S
>
>
> I don't have an issue with either of these.
>
> 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
>
>
> ___
> 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] Option to not render 3D models for footprints

[Diego Herranz]

>> Maybe a better option would be to have footprint variations similar to
>> aliases.
>> Something with a new name, new 3d model path and new description but the
>> same land pattern.

This would be great and ease the libraries development quite a lot.

Diego


On Mon, Mar 25, 2019 at 8:50 PM Rene Pöschl  wrote:

> Maybe a better option would be to have footprint variations similar to
> aliases.
> Something with a new name, new 3d model path and new description but the
> same land pattern.
>
> This could be useful not only for having specialized 3d models but also
> when the manufacturer uses a very strange part naming scheme where it
> gets hard to define a footprint name well such that it tells the user
> which parts it exactly fits. (Example is if the part number code has for
> example a place that is either a,b.e for fp1 but c,d for fp2. right now
> we would need at least 3 possibly 5 footprints to properly do this.)
>
> The individual visibility stuff could also be useful for usecases that
> do not fit the one handled by my suggestion. One example would be a
> battery holder where you have the battery as a separate model. You might
> be interested in seeiing how it looks without a battery. Maybe even have
> a model where the battery is in the process of being inserted to see the
> space required for that task.
>
> Or a shield that covers some other parts. Might be useful to just hide
> this alone.
>
> On 25/03/19 19:46, Jeff Young wrote:
> > Multiple models is an existing feature (for building up parts).  There’s
> just no individual control over visibility.
> >
> > Cheers,
> > Jeff.
> >
> >> On 25 Mar 2019, at 18:38, Wayne Stambaugh  wrote:
> >>
> >> Sorry it took so long to get back to this but I've been really busy.
> >> The the capacitor example makes sense although I'm not sure this is a
> >> significant enough feature to warrant a file format change.  I'm not
> >> terribly opposed to this idea either.  I do have a few questions.  Can
> >> multiple models be visible at the same time?  If so, have the STEP and
> >> VRML exporters been tested to work under this case?
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> On 3/14/2019 10:26 AM, Jeff Young wrote:
> >>> Hi Wayne,
> >>>
> >>> No, it would need to be saved in the file.  Think of it as Units for 3D
> >>> models: for instance you might have 30mm, 35mm and 40mm tall capacitors
> >>> all assigned to the single 20mm diameter 7.5mm pitch footprint.
> >>>
> >>> Cheers,
> >>> Jeff.
> >>>
> >>>
>  On 14 Mar 2019, at 13:38, Wayne Stambaugh   > wrote:
> 
>  Jeff,
> 
>  I haven't looked at Oliver's patch so I'm flying blind here.  My
>  question is why does this require a board change.  Is this a state we
>  really need to save in the board file or could it be some 3D viewer
>  visibility state option saved in a config file?  I would prefer the
>  latter if possible.  I guess I don't understand the purpose of this.
> 
>  Cheers,
> 
>  Wayne
> 
>  On 3/14/2019 6:44 AM, Jeff Young wrote:
> > @Wayne, this builds on top of my m_Preview addition so I’m happy to
> > review it and merge it after Oliver re-bases.  But where do we stand
> on
> > PCBNew file format changes for 6.0?  (There are also some hold-overs
> I
> > have from 5.1; namely storing defined diff pair dimensions and the
> > courtyard DRC settings in the files.
> >
> >> On 14 Mar 2019, at 08:30, Oliver Walters
> >>  oliver.henry.walt...@gmail.com>
> >> > wrote:
> >>
> >> This has gone unresolved for a while now - if I put in some effort
> to
> >> rebase this, is there any likelihood it will be accepted?
> >>
> >> This patchset does involve a file format change to the PCB file but
> it
> >> is backwards compatible and introduces a useful new feature.
> >>
> >> On Tue, Oct 30, 2018 at 11:27 PM Oliver Walters
> >>  oliver.henry.walt...@gmail.com>
> >> > wrote:
> >>
> >> The attached patchset expands on the "Preview" checkbox in the
> 3D
> >> model tab in the footprint editor.
> >>
> >> This "Preview" option currently only applies to the preview
> >> window. However if the user wishes to disable display of a given
> >> 3D model in the PCB renderer they must delete the 3D model from
> >> the footprint entirely.
> >>
> >> The new patchset does the following:
> >>
> >> 1) The state of the m_Preview parameter for each 3D model is
> >> observed in the various 3D renderers and exporters
> >>
> >> 2) The m_Preview parameter is saved to file (both .kicad_mod and
> >> .kicad_pcb)
> >>
> >> With regard to file saving, if the 3D model is "enabled"
> (default
> >> state) then the file is unchanged making this change largely
> >> backwards com

Re: [Kicad-developers] Why we chose to put libraries in directories?

[Diego Herranz]

My 2 cents.

Having separate files is very convenient when dealing with Pull Requests on
the git libraries repos.
On the kicad-symbols repo (1 file contains many symbols) there are many
more merging conflicts than on kicad-footprints (1 file per footprint).

Having said that, I understand that zipping the files may improve speed,
but at the repo level, I think we should keep separate files and in
fact, kicad-symbols
should be more similar to kicad-footprints (1 file per footprint per the
reasoning above). And definitely not zip files which is something that
doesn't work well on a repo.

I understand that all this is better discussed in person at FOSDEM. Could
you guys update us all after the event? ;)

Thanks!

On Mon, Jan 28, 2019 at 5:23 PM Tomasz Wlostowski 
wrote:

> Hi Devs,
>
> A (probably) dumb question of a programmer who tried to put himself in
> the user's shoes:
>
> - KiCad libraries (.pretty) are directories full of tiny files.
> - Other libraries (Eagle, etc.) are just files.
> - The Library Table dialog must support both, but there's no single
> dialog that allows selecting both files and directories (or even faking
> directories to look as files).
> - [update] wxDirDialog seems to support the above ^^, but it doesn't
> look like a standard file chooser dialog. This is confusing to users.
> - Why do footprint libraries have the extension ".pretty"? What does it
> convey to the user (it's a nice codename for programmers, though)?.
> - Why the PROJECT class is compiled conditionally, exposing only PCB
> libs to pcbnew and SCH libs to eeschema? This prevents having a single,
> unified library configuration dialog accessible from all Kicad apps as
> well as the Project Manager.
> - Do we *really* need to expose all these environmental variables,
> fp-lib-table paths, plugin options and so on in the main library
> configuration dialog? This is extremely confusing. I'm not opposed to
> support environment vars, but should they be as visible as they are now?
> - How about adding support for .zip library files (zipped
> .pretty/.sweet/.3dshapes directory)? This could significantly improve
> the library loading speed as the scanner will no longer need to access
> every single .kicad_mod/.kicad_sym file just to enumerate the
> footprint/symbol it contains. It's quite annoying, in particular under
> Windows or NFS/Samba (loading the standard FP library on my laptop takes
> ~20 seconds).
> - Should we have the same interface for adding 3D model libraries
> (directories/zipfiles with .STEP files) instead of a 3D model search path?
>
> I'm asking because despite our efforts to improve Kicad's UX, the
> library configuration is still quite difficult, even for experienced PCB
> designers who are switching to KiCad from proprietary tools (see recent
> posts on the Kicad Forum). I'd like to improve this during the V6
> development cycle.
>
> 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] Some of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

[Diego Herranz]

Hi, Rene.

Thanks for bringing this up. I've never liked hidden power pins. In my
opinion, the python philosophy applies here too: "Explicit is better than
implicit."

How many libraries will need this?
I'm asking because, if we went for option 3 (or 2), will we end up with a
lot of nearly identical duplicated libraries? That can be very confusing
for users and for maintaining the GitHub libraries (e.g. getting pull
requests for the old libraries instead of the new ones, etc.).
And at some point we would need to get rid of the old ones anyway not to
carry them forever, won't we?

I'm wondering whether we can for option 1 if we evaluate what the behaviour
would be regarding ERC, symbol rescue, etc.

Thanks,
Diego

On Tue, Nov 6, 2018 at 9:42 PM Rene Pöschl  wrote:

> Hi all,
>
>
> Sadly we did not come around to fix all symbols before the v5 release.
> We now seem to have a volunteer who would be prepared to fix these symbols.
>
> There is a catch though. Whatever we do to fix this it will break
> designs that use the old symbols right now.
>
>
> So we have a few options:
>
> - 1 - Change the symbols inside the library and inform the users about
> this fix. (Will break current designs as the power pins will no longer
> be connected automatically. This after all is the point of the fix. Not
> sure if rescue is reliable enought to chatch that. ERC might also not
> complain if we put the power pins onto a separate unit.)
>
> - 2 - Add a separate library that holds the fixed symbols, keep the old
> one but remove it from the template library table. This means no designs
> are borken as old users do not get the new lib added without an explicit
> action on their part.
>
> - 3 - Rename the library before fixing it. add the new lib to the lib
> table. This would still break designs. (But in a different way. In this
> case the symbol might simply not be found. This is something that the
> rescue stuff should deal with.) In addition users will get an error
> message when starting eeschema or the symbol editor that alerts them
> about a missing file. (So if we make an announcement that includes the
> error message they should find it when they google for it.)
>
>
> My personal vote would be for option 3.
>
>
> ___
> 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.1 UI feedback

[Diego Herranz]

Thanks, Jeff.

I'll give it a try when it hits the nightlies.

Diego

On Fri, Jul 20, 2018 at 6:54 PM Jeff Young  wrote:

> I’ve merged this suggestion.
>
> Unfortunately wxGrid conspires against us in trying to present the buttons
> when the grid cell is focused, but you do get them once you try to edit the
> cell.
>
> Cheers,
> Jeff.
>
>
> > On 20 Jul 2018, at 13:52, Jeff Young  wrote:
> >
> > No need.  I’ve just about got it implemented so a reminder would be
> surplus to requirements. ;)
> >
> >> On 20 Jul 2018, at 12:32, Wayne Stambaugh  wrote:
> >>
> >> I don't remember seeing a bug report for that just Diego's post to the
> >> mailing list.  If you want me to, I will create a bug report.
> >>
> >> On 07/19/2018 03:53 PM, Jeff Young wrote:
> >>> I thought there was already a bug for this (reported by Gabriel
> >>> perhaps?), but I can’t seem to find it.
> >>>
> >>>> On 19 Jul 2018, at 20:40, Wayne Stambaugh  >>>> <mailto:stambau...@gmail.com>> wrote:
> >>>>
> >>>> I second this motion.  I didn't find the right click trick so I fell
> >>>> back to cvpcb which is overkill to change the footprint of a single
> >>>> symbol.  A tooltip might be useful here as well.
> >>>>
> >>>> On 7/19/2018 3:19 PM, Diego Herranz wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I've started to test these changes and, on the Symbol properties
> dialog,
> >>>>> I found it hard to assign a footprint.
> >>>>> Before, there used to be a button to open the Footprint selector
> window.
> >>>>> Now you seem to need right click on the footprint field and "select
> >>>>> footprint" and that only works if you're not editing the text of that
> >>>>> field. It took me a while to find out.
> >>>>> I don't find it straightforward.
> >>>>>
> >>>>> Maybe a double-click on that field should open the Footprint
> selector?
> >>>>> Maybe a button like attached? (Mind my poor mock-up)
> >>>>> Any other suggestions?
> >>>>>
> >>>>> Thanks for all the work on this.
> >>>>>
> >>>>> Diego
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Jul 18, 2018 at 6:00 PM Jeff Young  >>>>> <mailto:j...@rokeby.ie>
> >>>>> <mailto:j...@rokeby.ie>> wrote:
> >>>>>
> >>>>>   Changes in.  Could Kevin or Wayne please post the following dialogs
> >>>>>   one more time:
> >>>>>
> >>>>>   1) Change Footprints
> >>>>>   2) CvPCB (with footprint selected from right column)
> >>>>>   3) Footprint Properties
> >>>>>   4) Edit Track & Via Properties
> >>>>>
> >>>>>   Thanks,
> >>>>>   Jeff.
> >>>>>
> >>>>>> On 18 Jul 2018, at 15:28, Jeff Young  >>>>>> <mailto:j...@rokeby.ie>
> >>>>>   <mailto:j...@rokeby.ie>> wrote:
> >>>>>>
> >>>>>> Yeah, the “Show” label of the Output Messages checkboxes is
> >>>>>   misplaced too.
> >>>>>>
> >>>>>> I’ll have another build along shortly….
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Jeff.
> >>>>>>
> >>>>>>
> >>>>>>> On 18 Jul 2018, at 15:05, Kevin Cozens  >>>>>>> <mailto:ke...@ve3syb.ca>
> >>>>>   <mailto:ke...@ve3syb.ca>> wrote:
> >>>>>>>
> >>>>>>> On 2018-07-18 08:32 AM, Wayne Stambaugh wrote:
> >>>>>>>> Attached are the updated screen shots.
> >>>>>>>
> >>>>>>> One minor point. In the first screen shot the icon with the books
> >>>>>   and magnifying glass is on the right side of the dialog the first
> >>>>>   time it appears but is just after the end of the entry field the
> >>>>>   second time it appears.
> >>>>>>>
> >>>>>>> It would look a little better if they were in the same

Re: [Kicad-developers] 5.1 UI feedback

[Diego Herranz]

Hi,

I've started to test these changes and, on the Symbol properties dialog, I
found it hard to assign a footprint.
Before, there used to be a button to open the Footprint selector window.
Now you seem to need right click on the footprint field and "select
footprint" and that only works if you're not editing the text of that
field. It took me a while to find out.
I don't find it straightforward.

Maybe a double-click on that field should open the Footprint selector?
Maybe a button like attached? (Mind my poor mock-up)
Any other suggestions?

Thanks for all the work on this.

Diego





On Wed, Jul 18, 2018 at 6:00 PM Jeff Young  wrote:

> Changes in.  Could Kevin or Wayne please post the following dialogs one
> more time:
>
> 1) Change Footprints
> 2) CvPCB (with footprint selected from right column)
> 3) Footprint Properties
> 4) Edit Track & Via Properties
>
> Thanks,
> Jeff.
>
> > On 18 Jul 2018, at 15:28, Jeff Young  wrote:
> >
> > Yeah, the “Show” label of the Output Messages checkboxes is misplaced
> too.
> >
> > I’ll have another build along shortly….
> >
> > Cheers,
> > Jeff.
> >
> >
> >> On 18 Jul 2018, at 15:05, Kevin Cozens  wrote:
> >>
> >> On 2018-07-18 08:32 AM, Wayne Stambaugh wrote:
> >>> Attached are the updated screen shots.
> >>
> >> One minor point. In the first screen shot the icon with the books and
> magnifying glass is on the right side of the dialog the first time it
> appears but is just after the end of the entry field the second time it
> appears.
> >>
> >> It would look a little better if they were in the same relative
> horizontal position.
> >>
> >> --
> >> Cheers!
> >>
> >> Kevin.
> >>
> >> http://www.ve3syb.ca/   | "Nerds make the shiny things that
> >> https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
> >>   | that's why we're powerful"
> >> Owner of Elecraft K2 #2172  |
> >> #include  | --Chris Hardwick
> >>
> >> ___
> >> 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] Fabrication Outputs and Plot

[Diego Herranz]

Gentle reminder.

Thanks,
Diego

On Tue, Feb 27, 2018 at 12:16 AM, Wayne Stambaugh 
wrote:

> This looks fine to me.  Does anyone else have any objections to this
> change?
>
> On 02/25/2018 03:17 PM, Diego Herranz wrote:
>
>> Thanks for your replies. I think there's a consensus that this needs
>> improving and restructuring, but given your emails, it sounds like a big
>> task :)
>>
>> In the meantime, would you accept the attached patch to change the order
>> in which "Fabrication Outputs" is listed in the menu?
>>
>> Before:
>> Fabrication Outputs
>> Import
>> Export
>>
>> After:
>> Import
>> Export
>> Fabrication Outputs
>>
>>
>> I think that "Fabrication Outputs" is conceptually very similar to
>> "Export" and it belongs next to it better than having "Import" in between
>> them.
>>
>> Thanks,
>> Diego
>>
>>
>>
>> On Sat, Feb 24, 2018 at 9:01 PM, Wayne Stambaugh > <mailto:stambau...@gmail.com>> wrote:
>>
>> I'm open to any solution that improves the current situation.  This
>> solution seems reasonable as well.  I also just noticed that wx
>> 3.1.1 was just released and it looks like there have been a lot of
>> fixes the various device contexts so some of the work may have
>> already been done for us.
>>
>> On 02/24/2018 03:31 PM, Jon Evans wrote:
>>
>> I thought the idea was to write a backend for GAL that could
>> render onto a wxDC for printing?  It seems wise to use the
>> wxWidgets printing API rather than bypassing it; so we just need
>> to be able to render onto a DC (without using the old XOR tricks
>> from the legacy drawing code)
>>
>> On Sat, Feb 24, 2018 at 3:26 PM, Jeff Young > <mailto:j...@rokeby.ie> <mailto:j...@rokeby.ie
>> <mailto:j...@rokeby.ie>>> wrote:
>>
>>  On the other hand, if we don’t then we have to keep
>> carrying around
>>  a boat-load of Legacy rendering code (because we use that
>> for printing).
>>
>>   > On 24 Feb 2018, at 20:16, Wayne Stambaugh
>> mailto:stambau...@gmail.com>
>>  <mailto:stambau...@gmail.com
>>
>> <mailto:stambau...@gmail.com>>> wrote:
>>   >
>>   > There is no plan yet but it has been discussed.  The only
>>  downside is that we will have to write our own print
>> handling on
>>  windows and I'm guessing macos.  That's one of the reasons
>> no one
>>  has signed up yet because it will be a large undertaking.
>>   >
>>   > On 02/24/2018 02:02 PM, Jon Evans wrote:
>>   >> Yes I think that's the plan, just needs someone to sign
>> up to
>>  write it :)
>>   >> On Sat, Feb 24, 2018, 14:00 Andrzej Wolski
>>  mailto:awolski.ki...@gmail.com>
>> <mailto:awolski.ki...@gmail.com <mailto:awolski.ki...@gmail.com>>
>>  <mailto:awolski.ki...@gmail.com
>> <mailto:awolski.ki...@gmail.com> <mailto:awolski.ki...@gmail.com
>> <mailto:awolski.ki...@gmail.com>>>>
>>  wrote:
>>   >>Cairo have PDF, SVG and Postscript support. I was once
>>  wondering if
>>   >>GAL/Cairo could be used for printing.
>>   >>Andrzej
>>   >>W dniu 2018-02-24 o 19:24, Jon Evans pisze:
>>   >>>Yeah, there (at least) three different dialogs that
>> all present
>>   >>>similar things (i.e. a list of layers to include,
>> settings,
>>  etc):
>>   >>>
>>   >>>Export->SVG
>>   >>>Print
>>   >>>Plot
>>   >>>
>>   >>>The Print code for Export->SVG seems to just use
>> the same SVG
>>   >>>plotter, so maybe it's just mostly GUI cleanup that
>> is needed.
>>   >>>
>>   >>>The main Print code does need an overhaul to use
>> something other
>> 

Re: [Kicad-developers] Fabrication Outputs and Plot

[Diego Herranz]

Thanks for your replies. I think there's a consensus that this needs
improving and restructuring, but given your emails, it sounds like a big
task :)

In the meantime, would you accept the attached patch to change the order in
which "Fabrication Outputs" is listed in the menu?

Before:
Fabrication Outputs
Import
Export

After:
Import
Export
Fabrication Outputs


I think that "Fabrication Outputs" is conceptually very similar to "Export"
and it belongs next to it better than having "Import" in between them.

Thanks,
Diego



On Sat, Feb 24, 2018 at 9:01 PM, Wayne Stambaugh 
wrote:

> I'm open to any solution that improves the current situation.  This
> solution seems reasonable as well.  I also just noticed that wx 3.1.1 was
> just released and it looks like there have been a lot of fixes the various
> device contexts so some of the work may have already been done for us.
>
> On 02/24/2018 03:31 PM, Jon Evans wrote:
>
>> I thought the idea was to write a backend for GAL that could render onto
>> a wxDC for printing?  It seems wise to use the wxWidgets printing API
>> rather than bypassing it; so we just need to be able to render onto a DC
>> (without using the old XOR tricks from the legacy drawing code)
>>
>> On Sat, Feb 24, 2018 at 3:26 PM, Jeff Young > j...@rokeby.ie>> wrote:
>>
>> On the other hand, if we don’t then we have to keep carrying around
>> a boat-load of Legacy rendering code (because we use that for
>> printing).
>>
>>  > On 24 Feb 2018, at 20:16, Wayne Stambaugh > <mailto:stambau...@gmail.com>> wrote:
>>  >
>>  > There is no plan yet but it has been discussed.  The only
>> downside is that we will have to write our own print handling on
>> windows and I'm guessing macos.  That's one of the reasons no one
>> has signed up yet because it will be a large undertaking.
>>  >
>>  > On 02/24/2018 02:02 PM, Jon Evans wrote:
>>  >> Yes I think that's the plan, just needs someone to sign up to
>> write it :)
>>  >> On Sat, Feb 24, 2018, 14:00 Andrzej Wolski
>> mailto:awolski.ki...@gmail.com>
>> <mailto:awolski.ki...@gmail.com <mailto:awolski.ki...@gmail.com>>>
>> wrote:
>>  >>Cairo have PDF, SVG and Postscript support. I was once
>> wondering if
>>  >>GAL/Cairo could be used for printing.
>>  >>Andrzej
>>  >>W dniu 2018-02-24 o 19:24, Jon Evans pisze:
>>  >>>Yeah, there (at least) three different dialogs that all
>> present
>>  >>>similar things (i.e. a list of layers to include, settings,
>> etc):
>>  >>>
>>  >>>Export->SVG
>>  >>>Print
>>  >>>Plot
>>  >>>
>>  >>>The Print code for Export->SVG seems to just use the same SVG
>>  >>>plotter, so maybe it's just mostly GUI cleanup that is needed.
>>  >>>
>>  >>>The main Print code does need an overhaul to use something
>> other
>>  >>>than wxDC for graphics generation (and perhaps adding some
>> more
>>  >>>features to PDF export)
>>  >>>
>>  >>>-Jon
>>  >>>
>>  >>>On Sat, Feb 24, 2018 at 1:16 PM, Jeff Young > <mailto:j...@rokeby.ie>
>>  >>><mailto:j...@rokeby.ie <mailto:j...@rokeby.ie>>> wrote:
>>  >>>
>>  >>>Plot SVG and Export SVG are different.  The former goes
>>  >>>through the Plot code while the later goes through the
>> Print
>>  >>>code.
>>  >>>
>>  >>>Do we need both?  I haven’t a clue.
>>  >>>
>>  >>>It would be nice to clean this stuff up, if there is in
>> fact a
>>  >>>clean way to present it.
>>  >>>
>>  >>>Cheers,
>>  >>>Jeff.
>>  >>>
>>  >>>
>>  >>>>On 24 Feb 2018, at 14:54, Jon Evans > <mailto:j...@craftyjon.com>
>>  >>>><mailto:j...@craftyjon.com <mailto:j...@craftyjon.com>>>
>> wrote:
>>  >>>>
>>  >>>>I agree with th

[Kicad-developers] Fabrication Outputs and Plot

[Diego Herranz]

Hi,

Now that so much work is happening on re-structuring menus, I've remembered
something I have always found weird on pcbnew.

"Plot", from wihch you can obtain Gerbers is not inside "Fabrication
Outputs", but on its own.
I find it weird to have the drill option inside "Fabrication Outputs" but
not the Gerbers (they are normally needed together and in fact, you can go
to "Drill" from "Plot").

If "Plot" was Gerber only, I would recommend moving it inside "Fabrication
Outputs" straight away but because it also exports other formats, it's not
so straightforward.

I think ideally we would have:

- Fabrication outputs
- Gerber...
- Drill
- ...
- Export
- STEP
- PDF...
- Postcript...
- DXF...
- ...

And I have just noticed SVG can be obtained from "Plot" or the "Export"
submenu. Is it the same?

What do you guys think? I'm not necessarily suggesting looking into this
before KiCad 5, just wanted to have your view.

Thanks,
Diego
___
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] Schematic symbol chooser clarification

[Diego Herranz]

I can relate to this issue. It happened to me as well and I thought my
library setup wasn't right. Then I found out it was showing power symbols
only.

+1 to make it more evident. At least changing the dialog title?

Thanks,
Diego

On Mon, Feb 5, 2018 at 1:22 PM, kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> Yeah, that to adds to the confusion. I think maybe coherency should be one
> of the main goal for v6.
>
>
> On 2018-02-05 13:25, Marco Ciampa wrote:
>
>> On Mon, Feb 05, 2018 at 01:10:08PM +0100, kristoffer Ödmark wrote:
>>
>>> Hey!
>>>
>>> I just spent some time trying to "debug" a library non-issue with a EE
>>> switching from Altium for a test. He had added the libraries correctly,
>>> and
>>> they showed up. But everytime he tried adding a symbol to the schematic,
>>> no
>>> symbols was there. We sent pictures back and forth, and indeed the
>>> libraries
>>> added, but did not show up.
>>>
>>> To make a long hassle short, turns out the shortcut "P" is used to place
>>> symbols in Altium, but to place Power symbols in kicad.
>>> This is not an issue, however, there is no indication at all that the
>>> symbol
>>> chooser is actually filtered or limited when using the shortcut key.
>>>
>>> I think there could be benefits of adding some kind of visualization to
>>> the
>>> symbol chooser that the list is limited to only power symbols, maybe just
>>> changing the window title to something like "Choose Power Symbol" or the
>>> more general term of adding the filter to the window name. Let me know
>>> what
>>> you think
>>>
>> Also when you place a power symbol, the dialog shows normal symbols in
>> the history list, and it also permits to insert these symbols even if
>> they are not power symbols... that to me seems incoherent...
>>
>>
>
> ___
> 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] desired layer sequence for pcb technical layers

[Diego Herranz]

Regarding Front vs Top, I see it called Top everywhere else, but back to
the original question: +1 for Top/Front first.

Thanks,
Diego

On Thu, Jan 11, 2018 at 5:52 AM, Andrey Kuznetsov 
wrote:

> Why is it Front and Back, as opposed to Top and Bottom?
> Front/Top should be first.
>
> On Wed, Jan 10, 2018 at 8:50 PM, Jon Evans  wrote:
>
>> Hi all,
>>
>> Right now, we have conflicting "desired order" for technical layers in
>> various places.
>>
>> The layer widget displays "front first", i.e. F.Paste before B.Paste,
>> F.Fab before B.Fab, etc.
>>
>> Everywhere else in the codebase is "back first".
>> This leads to this bug: https://bugs.launchpad.net/kicad/+bug/1673792
>> because the properties dialog is using LSET::UIOrder() which uses the
>> "preferred" back first ordering.
>>
>> Which way should we actually have it?  "front first" makes sense to me,
>> and that is the precedent set in the most user-visible part (the layer
>> manager) but then why in LSET::Technicals() is there a comment saying the
>> desired order is "back first"?
>>
>> -Jon
>>
>> ___
>> 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
>>
>>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
>
> ___
> 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] Migrating old designs best practice

[Diego Herranz]

Thanks for the tip.
I'll use it to check schematics wiring.

Diego

On Sun, Nov 26, 2017 at 6:53 PM, jp charras  wrote:

> Le 26/11/2017 à 19:15, Diego Herranz a écrit :
> > It's interesting that only happen if I rescue symbols.
> >
> > Anyway, thanks for the help and I'll keep an eye on properly wired
> schematics to see if all goes OK.
> >
> > Thanks,
> > Diego
>
> To seen if your wires are OK, try to create a netlist:
>
> The first thing the netlist calculation make is to simplify wires
> (especially merge overlapping).
> This is mandatory to avoid incorrect netlists.
>
> If your issue can be seen after creating a netlist, you just have some
> incorrect (questionable?) wires.
>
> >
> > On Sun, Nov 26, 2017 at 5:23 PM, José Ignacio  <mailto:jose.cyb...@gmail.com>>
> > wrote:
> >
> > This might be related to the wire optimizer/junction management
> code. Eeschema used to allow
> > degenerate connections like that, where an L was superimposed to a
> wire, connecting into a junction.
> >
>
> --
> 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
>
___
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] Migrating old designs best practice

[Diego Herranz]

It's interesting that only happen if I rescue symbols.

Anyway, thanks for the help and I'll keep an eye on properly wired
schematics to see if all goes OK.

Thanks,
Diego

On Sun, Nov 26, 2017 at 5:23 PM, José Ignacio  wrote:

> This might be related to the wire optimizer/junction management code.
> Eeschema used to allow degenerate connections like that, where an L was
> superimposed to a wire, connecting into a junction.
>
> On Sun, Nov 26, 2017 at 4:59 AM, Diego Herranz <
> diegoherr...@diegoherranz.com> wrote:
>
>> Please ignore the previous attachments. They should have been these.
>>
>> Thanks.
>>
>> On Sun, Nov 26, 2017 at 10:55 AM, Diego Herranz <
>> diegoherr...@diegoherranz.com> wrote:
>>
>>> Hi, Nick
>>>
>>> Changes like: (- is removed, + added)
>>>
>>> -Wire Wire Line
>>> - 12550 700  12600 700
>>>
>>> -Wire Wire Line
>>> - 12700 700  12700 700
>>>
>>>  Wire Wire Line
>>> - 22250 14500 22250 11600
>>> + 22250 9200 22250 14600
>>>
>>> - Wire Wire Line
>>> - 22250 9200 22250 14600
>>>
>>> - Wire Wire Line
>>> - 22700 750  15350 750
>>>
>>>  Wire Wire Line
>>> - 16650 750  16650 750
>>> + 15350 750  22700 750
>>>
>>>
>>> This happens on a dummy schematic which I've got for basically trying
>>> things out in KiCad, and to test nightlies. So the schematic is basically a
>>> mess.
>>>
>>> Thant means I've got crappy connections (before.png), which the rescue
>>> process broke (after.png). Maybe it wouldn't have happened if the
>>> connections were nice in the first place, but I wasn't expecting them to
>>> break.
>>>
>>> Thanks!
>>>
>>>
>>>
>>> On Sat, Nov 25, 2017 at 9:15 PM, Nick Østergaard 
>>> wrote:
>>>
>>>> What modifications are made to the wires?
>>>>
>>>> 2017-11-25 21:28 GMT+01:00 Diego Herranz >>> >:
>>>>
>>>>> Hi,
>>>>>
>>>>> Related to this, I'm migrating an old design (~2 month old nightly) to
>>>>> the current master. First I faced some problem with '/' characters (
>>>>> https://lists.launchpad.net/kicad-developers/msg31705.html) but there
>>>>> have been some improvements since then so I'm trying again.
>>>>>
>>>>> When opening the schematic, 2 dialogs are shown:
>>>>> 1) Rescue symbols dialog: it offers to rescue a couple of symbols
>>>>> which use '/' in their name. It seems to rescue them properly
>>>>> on -rescue.lib (replacing '/' by '_')
>>>>> 2) Remap dialog: Everything gets remapped properly except the symbols
>>>>> mentioned in 1). That is because -rescue.lib is not in sym-lib-table
>>>>> yet. After adding it to sym-lib-table, I can edit those broken symbols
>>>>> ("?")  to point those rescued in -rescue.lib and it all looks OK.
>>>>>
>>>>> After this, which I think that can be challenging for many people (it
>>>>> has been for me), it seems everything should be OK now. However when I 
>>>>> push
>>>>> the netlist to pcbnew, it shows a few changes and I wasn't expecting any.
>>>>> Comparing the schematic file with a text editor a few wires have been
>>>>> modified.
>>>>>
>>>>> I've don't some testing it seems the wires get modified when doing 1).
>>>>> If I skip the rescue, no wire gets modified.
>>>>>
>>>>> Why is that happening? I wouldn't expect the rescue process to modify
>>>>> wires. Am I doing something wrong?
>>>>>
>>>>> Many thanks,
>>>>> Diego
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Nov 25, 2017 at 3:00 PM, Wayne Stambaugh >>>> > wrote:
>>>>>
>>>>>> On 11/24/2017 05:01 PM, hauptmech wrote:
>>>>>> > On 25/11/17 02:14, Wayne Stambaugh wrote:
>>>>>> >> This is *the* fatal flaw with the cache library.  User's assume it
>>>>>> is
>>>>>> >> stale symbols or a temporary copy.  It is not.  It is a snapshot
>>>>>> of the
>>>>>> >> current library symbols linked to the symb

Re: [Kicad-developers] Migrating old designs best practice

[Diego Herranz]

Please ignore the previous attachments. They should have been these.

Thanks.

On Sun, Nov 26, 2017 at 10:55 AM, Diego Herranz <
diegoherr...@diegoherranz.com> wrote:

> Hi, Nick
>
> Changes like: (- is removed, + added)
>
> -Wire Wire Line
> - 12550 700  12600 700
>
> -Wire Wire Line
> - 12700 700  12700 700
>
>  Wire Wire Line
> - 22250 14500 22250 11600
> + 22250 9200 22250 14600
>
> - Wire Wire Line
> - 22250 9200 22250 14600
>
> - Wire Wire Line
> - 22700 750  15350 750
>
>  Wire Wire Line
> - 16650 750  16650 750
> + 15350 750  22700 750
>
>
> This happens on a dummy schematic which I've got for basically trying
> things out in KiCad, and to test nightlies. So the schematic is basically a
> mess.
>
> Thant means I've got crappy connections (before.png), which the rescue
> process broke (after.png). Maybe it wouldn't have happened if the
> connections were nice in the first place, but I wasn't expecting them to
> break.
>
> Thanks!
>
>
>
> On Sat, Nov 25, 2017 at 9:15 PM, Nick Østergaard 
> wrote:
>
>> What modifications are made to the wires?
>>
>> 2017-11-25 21:28 GMT+01:00 Diego Herranz :
>>
>>> Hi,
>>>
>>> Related to this, I'm migrating an old design (~2 month old nightly) to
>>> the current master. First I faced some problem with '/' characters (
>>> https://lists.launchpad.net/kicad-developers/msg31705.html) but there
>>> have been some improvements since then so I'm trying again.
>>>
>>> When opening the schematic, 2 dialogs are shown:
>>> 1) Rescue symbols dialog: it offers to rescue a couple of symbols which
>>> use '/' in their name. It seems to rescue them properly on -rescue.lib
>>> (replacing '/' by '_')
>>> 2) Remap dialog: Everything gets remapped properly except the symbols
>>> mentioned in 1). That is because -rescue.lib is not in sym-lib-table
>>> yet. After adding it to sym-lib-table, I can edit those broken symbols
>>> ("?")  to point those rescued in -rescue.lib and it all looks OK.
>>>
>>> After this, which I think that can be challenging for many people (it
>>> has been for me), it seems everything should be OK now. However when I push
>>> the netlist to pcbnew, it shows a few changes and I wasn't expecting any.
>>> Comparing the schematic file with a text editor a few wires have been
>>> modified.
>>>
>>> I've don't some testing it seems the wires get modified when doing 1).
>>> If I skip the rescue, no wire gets modified.
>>>
>>> Why is that happening? I wouldn't expect the rescue process to modify
>>> wires. Am I doing something wrong?
>>>
>>> Many thanks,
>>> Diego
>>>
>>>
>>>
>>> On Sat, Nov 25, 2017 at 3:00 PM, Wayne Stambaugh 
>>> wrote:
>>>
>>>> On 11/24/2017 05:01 PM, hauptmech wrote:
>>>> > On 25/11/17 02:14, Wayne Stambaugh wrote:
>>>> >> This is *the* fatal flaw with the cache library.  User's assume it is
>>>> >> stale symbols or a temporary copy.  It is not.  It is a snapshot of
>>>> the
>>>> >> current library symbols linked to the symbols in the schematic.  It
>>>> gets
>>>> >> refreshed every time the schematic is saved.  Once you delete this
>>>> file
>>>> >> or keep an out of date copy using cvs, all bets are off.  It is only
>>>> a
>>>> >> matter of time before one of your symbol libraries changes or gets
>>>> >> removed and you will end up with a broken schematic.  The rescue code
>>>> >> depends on the cache being up to date in order preserve you
>>>> schematic.
>>>> >> If the cache is not current, the rescuing cannot be guaranteed.
>>>> >
>>>> > I don't think it's necessarily a flaw. And your description above is
>>>> > indeed a cache. That's not a bad thing. I recall that I left it out of
>>>> > version control because I wanted to make sure fixes to my symbols were
>>>> > always propagated to the design. In the repo I'm referencing for this
>>>> > discussion I had 10 project files all using the same local library. I
>>>> > didn't want to have to manually update each schematic to propagate
>>>> > changes. Deleting untracked files was what I did instead. At the time
>>>> n

Re: [Kicad-developers] Migrating old designs best practice

[Diego Herranz]

Hi, Nick

Changes like: (- is removed, + added)

-Wire Wire Line
- 12550 700  12600 700

-Wire Wire Line
- 12700 700  12700 700

 Wire Wire Line
- 22250 14500 22250 11600
+ 22250 9200 22250 14600

- Wire Wire Line
- 22250 9200 22250 14600

- Wire Wire Line
- 22700 750  15350 750

 Wire Wire Line
- 16650 750  16650 750
+ 15350 750  22700 750


This happens on a dummy schematic which I've got for basically trying
things out in KiCad, and to test nightlies. So the schematic is basically a
mess.

Thant means I've got crappy connections (before.png), which the rescue
process broke (after.png). Maybe it wouldn't have happened if the
connections were nice in the first place, but I wasn't expecting them to
break.

Thanks!



On Sat, Nov 25, 2017 at 9:15 PM, Nick Østergaard  wrote:

> What modifications are made to the wires?
>
> 2017-11-25 21:28 GMT+01:00 Diego Herranz :
>
>> Hi,
>>
>> Related to this, I'm migrating an old design (~2 month old nightly) to
>> the current master. First I faced some problem with '/' characters (
>> https://lists.launchpad.net/kicad-developers/msg31705.html) but there
>> have been some improvements since then so I'm trying again.
>>
>> When opening the schematic, 2 dialogs are shown:
>> 1) Rescue symbols dialog: it offers to rescue a couple of symbols which
>> use '/' in their name. It seems to rescue them properly on -rescue.lib
>> (replacing '/' by '_')
>> 2) Remap dialog: Everything gets remapped properly except the symbols
>> mentioned in 1). That is because -rescue.lib is not in sym-lib-table
>> yet. After adding it to sym-lib-table, I can edit those broken symbols
>> ("?")  to point those rescued in -rescue.lib and it all looks OK.
>>
>> After this, which I think that can be challenging for many people (it has
>> been for me), it seems everything should be OK now. However when I push the
>> netlist to pcbnew, it shows a few changes and I wasn't expecting any.
>> Comparing the schematic file with a text editor a few wires have been
>> modified.
>>
>> I've don't some testing it seems the wires get modified when doing 1). If
>> I skip the rescue, no wire gets modified.
>>
>> Why is that happening? I wouldn't expect the rescue process to modify
>> wires. Am I doing something wrong?
>>
>> Many thanks,
>> Diego
>>
>>
>>
>> On Sat, Nov 25, 2017 at 3:00 PM, Wayne Stambaugh 
>> wrote:
>>
>>> On 11/24/2017 05:01 PM, hauptmech wrote:
>>> > On 25/11/17 02:14, Wayne Stambaugh wrote:
>>> >> This is *the* fatal flaw with the cache library.  User's assume it is
>>> >> stale symbols or a temporary copy.  It is not.  It is a snapshot of
>>> the
>>> >> current library symbols linked to the symbols in the schematic.  It
>>> gets
>>> >> refreshed every time the schematic is saved.  Once you delete this
>>> file
>>> >> or keep an out of date copy using cvs, all bets are off.  It is only a
>>> >> matter of time before one of your symbol libraries changes or gets
>>> >> removed and you will end up with a broken schematic.  The rescue code
>>> >> depends on the cache being up to date in order preserve you schematic.
>>> >> If the cache is not current, the rescuing cannot be guaranteed.
>>> >
>>> > I don't think it's necessarily a flaw. And your description above is
>>> > indeed a cache. That's not a bad thing. I recall that I left it out of
>>> > version control because I wanted to make sure fixes to my symbols were
>>> > always propagated to the design. In the repo I'm referencing for this
>>> > discussion I had 10 project files all using the same local library. I
>>> > didn't want to have to manually update each schematic to propagate
>>> > changes. Deleting untracked files was what I did instead. At the time
>>> no
>>> > one was making breaking changes to system installed symbols, so the
>>> > system libs were stable for this workflow.
>>> >
>>> > I'm trying think of the least effort way to migrate an old design in
>>> > these circumstances.
>>> >
>>> > Can we have the rescue code fail if no cache file is found? That at
>>> > least lets the user know they are in uncharted territory. Then if a lot
>>> > of users come complaining you will know if it is worth doing a bit more
>>> > in the rescue code.

Re: [Kicad-developers] Migrating old designs best practice

[Diego Herranz]

Hi,

Related to this, I'm migrating an old design (~2 month old nightly) to the
current master. First I faced some problem with '/' characters (
https://lists.launchpad.net/kicad-developers/msg31705.html) but there have
been some improvements since then so I'm trying again.

When opening the schematic, 2 dialogs are shown:
1) Rescue symbols dialog: it offers to rescue a couple of symbols which use
'/' in their name. It seems to rescue them properly on -rescue.lib
(replacing '/' by '_')
2) Remap dialog: Everything gets remapped properly except the symbols
mentioned in 1). That is because -rescue.lib is not in sym-lib-table
yet. After adding it to sym-lib-table, I can edit those broken symbols
("?")  to point those rescued in -rescue.lib and it all looks OK.

After this, which I think that can be challenging for many people (it has
been for me), it seems everything should be OK now. However when I push the
netlist to pcbnew, it shows a few changes and I wasn't expecting any.
Comparing the schematic file with a text editor a few wires have been
modified.

I've don't some testing it seems the wires get modified when doing 1). If I
skip the rescue, no wire gets modified.

Why is that happening? I wouldn't expect the rescue process to modify
wires. Am I doing something wrong?

Many thanks,
Diego



On Sat, Nov 25, 2017 at 3:00 PM, Wayne Stambaugh 
wrote:

> On 11/24/2017 05:01 PM, hauptmech wrote:
> > On 25/11/17 02:14, Wayne Stambaugh wrote:
> >> This is *the* fatal flaw with the cache library.  User's assume it is
> >> stale symbols or a temporary copy.  It is not.  It is a snapshot of the
> >> current library symbols linked to the symbols in the schematic.  It gets
> >> refreshed every time the schematic is saved.  Once you delete this file
> >> or keep an out of date copy using cvs, all bets are off.  It is only a
> >> matter of time before one of your symbol libraries changes or gets
> >> removed and you will end up with a broken schematic.  The rescue code
> >> depends on the cache being up to date in order preserve you schematic.
> >> If the cache is not current, the rescuing cannot be guaranteed.
> >
> > I don't think it's necessarily a flaw. And your description above is
> > indeed a cache. That's not a bad thing. I recall that I left it out of
> > version control because I wanted to make sure fixes to my symbols were
> > always propagated to the design. In the repo I'm referencing for this
> > discussion I had 10 project files all using the same local library. I
> > didn't want to have to manually update each schematic to propagate
> > changes. Deleting untracked files was what I did instead. At the time no
> > one was making breaking changes to system installed symbols, so the
> > system libs were stable for this workflow.
> >
> > I'm trying think of the least effort way to migrate an old design in
> > these circumstances.
> >
> > Can we have the rescue code fail if no cache file is found? That at
> > least lets the user know they are in uncharted territory. Then if a lot
> > of users come complaining you will know if it is worth doing a bit more
> > in the rescue code.
> >
> > If the cache is not available during rescue you can load a copy of the
> > libraries that were current at the schematic save date and either
> > re-cache them or rescue them directly. But this is only worth doing if a
> > significant number of users are affected.
>
> AFAIK, the rescue code doesn't do anything if there is not cache file
> because the cache file is used for the comparison.  I actually
> considered adding a check on schematic load to warn the user with a list
> of all of symbols linked to the cache library so they could fix them.
> I'm not sure this is desirable but at least users would know that
> symbols were missing from their libraries and the links were falling
> back to the cache which is tenuous at best.
>
> ___
> 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] New symbol table: problems with '/' characters?

[Diego Herranz]

Hi, Wayne.

I've read the bug and I've seen it's not a trivial fix. I wasn't offering
to fix it just, just to follow that bug and see what was agreed and done. I
guess I didn't explain myself (English is not my first language) :)

Thanks!
Diego

On Sat, Nov 18, 2017 at 1:07 PM, Wayne Stambaugh 
wrote:

> Diego,
>
> Thank you for the offer but I'm already working on it.  It is not as
> easy to fix as it would seem.  The problem is what to do when you do not
> have write access to the library with the invalid characters.  I have a
> few ideas but it will take me a while to get it the way I want it.
>
> Cheers,
>
> Wayne
>
> On 11/18/2017 08:00 AM, Diego Herranz wrote:
> > Thanks. I'll chase that bug.
> >
> > Diego
> >
> > On 18 Nov 2017 11:35 am, "Nick Østergaard"  > <mailto:oe.n...@gmail.com>> wrote:
> >
> >     See https://bugs.launchpad.net/bugs/1732236
> > <https://bugs.launchpad.net/bugs/1732236>
> >
> > 2017-11-18 11:42 GMT+01:00 Diego Herranz
> > mailto:diegoherr...@diegoherranz.com
> >>:
> >
> > Hi,
> >
> > I'm testing a recent build (41f9c19b) on Ubuntu 16.04 64 bits.
> >
> > When opening a schematic made with a nightly build ~2 months
> > old, the remapping dialog shows up. So far so good.
> >
> > I've followed the recommendations
> > in http://kicad-pcb.org/post/symbol-lib-table/
> > <http://kicad-pcb.org/post/symbol-lib-table/> and most things
> > seem to be working fine. Every symbol gets remapped but 2. Both
> > of which include '/' in their name (e.g. PIC32MX110F016D-I/PT).
> >
> > Opening the schematic after the remap, it seems Kicad has
> > changed it to PIC32MX110F016D-I_PT.
> >
> > In fact, after a bit more searching, I've found out that as soon
> > as the remapping dialog shows up, before clicking on "Remap
> > symbols" the '/' characters have been replaced to '_'. So I'm
> > guessing that is the reason why it can't find the symbols when
> > remapping?
> > "Warning: No symbol 'PIC32MX110F016D-I_PT' found in symbol
> > library table." confirms that the name was changed before the
> > remapping attempt.
> >
> > I have then tried to edit the broken symbols in Eeschema. When I
> > try to assign "PIC32MX110F016D-I/PT" again, which can be found
> > through the "Choose Symbol" dialog without problems, it
> complains:
> > " Symbol 'PIC32MX1XXFXXXD-I_PT' not found in library
> > 'MCU_Microchip_PIC32'! "
> >
> > Am I doing something wrong? Is this a bug?
> >
> > Many thanks,
> > Diego
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net
> > <mailto:kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp
> > <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] New symbol table: problems with '/' characters?

[Diego Herranz]

Thanks. I'll chase that bug.

Diego

On 18 Nov 2017 11:35 am, "Nick Østergaard"  wrote:

> See https://bugs.launchpad.net/bugs/1732236
>
> 2017-11-18 11:42 GMT+01:00 Diego Herranz :
>
>> Hi,
>>
>> I'm testing a recent build (41f9c19b) on Ubuntu 16.04 64 bits.
>>
>> When opening a schematic made with a nightly build ~2 months old, the
>> remapping dialog shows up. So far so good.
>>
>> I've followed the recommendations in http://kicad-pcb.org/post/s
>> ymbol-lib-table/ and most things seem to be working fine. Every symbol
>> gets remapped but 2. Both of which include '/' in their name
>> (e.g. PIC32MX110F016D-I/PT).
>>
>> Opening the schematic after the remap, it seems Kicad has changed it
>> to PIC32MX110F016D-I_PT.
>>
>> In fact, after a bit more searching, I've found out that as soon as the
>> remapping dialog shows up, before clicking on "Remap symbols" the '/'
>> characters have been replaced to '_'. So I'm guessing that is the reason
>> why it can't find the symbols when remapping?
>> "Warning: No symbol 'PIC32MX110F016D-I_PT' found in symbol library
>> table." confirms that the name was changed before the remapping attempt.
>>
>> I have then tried to edit the broken symbols in Eeschema. When I try to
>> assign "PIC32MX110F016D-I/PT" again, which can be found through the "Choose
>> Symbol" dialog without problems, it complains:
>> " Symbol 'PIC32MX1XXFXXXD-I_PT' not found in library
>> 'MCU_Microchip_PIC32'! "
>>
>> Am I doing something wrong? Is this a bug?
>>
>> Many thanks,
>> Diego
>>
>> ___
>> 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] New symbol table: problems with '/' characters?

[Diego Herranz]

Hi,

I'm testing a recent build (41f9c19b) on Ubuntu 16.04 64 bits.

When opening a schematic made with a nightly build ~2 months old, the
remapping dialog shows up. So far so good.

I've followed the recommendations in
http://kicad-pcb.org/post/symbol-lib-table/ and most things seem to be
working fine. Every symbol gets remapped but 2. Both of which include '/'
in their name (e.g. PIC32MX110F016D-I/PT).

Opening the schematic after the remap, it seems Kicad has changed it
to PIC32MX110F016D-I_PT.

In fact, after a bit more searching, I've found out that as soon as the
remapping dialog shows up, before clicking on "Remap symbols" the '/'
characters have been replaced to '_'. So I'm guessing that is the reason
why it can't find the symbols when remapping?
"Warning: No symbol 'PIC32MX110F016D-I_PT' found in symbol library table."
confirms that the name was changed before the remapping attempt.

I have then tried to edit the broken symbols in Eeschema. When I try to
assign "PIC32MX110F016D-I/PT" again, which can be found through the "Choose
Symbol" dialog without problems, it complains:
" Symbol 'PIC32MX1XXFXXXD-I_PT' not found in library 'MCU_Microchip_PIC32'!
"

Am I doing something wrong? Is this a bug?

Many thanks,
Diego
___
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] KiCad Libraries (again)

[Diego Herranz]

Hi,

I've just submitted a pull request (
https://github.com/KiCad/kicad-website/pull/236) trying to make a bit more
clear when/why you need to update the libraries. Also adding links to
github lib repos. Comments welcome :)

Thanks,
Diego

On Sun, Nov 5, 2017 at 10:33 PM, Diego Herranz <
diegoherr...@diegoherranz.com> wrote:

> Thanks, Rene
>
> On 4 Nov 2017 4:06 pm, "Rene Pöschl"  wrote:
>
> On 03/11/17 21:34, Diego Herranz wrote:
>
>> First of all, I think all the recent work around the libraries is great!
>> Thanks to everyone involved. I think sometimes libraries are underestimated
>> (not just in KiCad). If KiCad manages to have extensive, high-quality and
>> clearly arranged libraries, many more users will end up using it.
>>
>> Having said that, I've used Kicad for some time and even contributed some
>> code but still can't fully understand how all the library stuff works. It
>> is the most common complaint I read about KiCad by newbies and somehow I
>> feel myself in a similar situation.
>>
>> So, I've reviewed http://kicad-pcb.org/libraries/download/ <
>> http://kicad-pcb.org/libraries/download/> with my lack of library
>> understanding and will try to provide some feedback from that view:
>>
>>
>> - It seems to imply that the user needs to download the libraries from
>> there. However they come with the installer, don't they?
>>
> A user might want do download an older or newer version of the lib than is
> offered with their software version. (Maybe because they want to open a
> project designed with this version of the lib.)
>
> And there is talk about giving users the option to get a small installer
> without libs. (Some users have data constrains. The installer is now nearly
> 1GB including all the 3d model libs.)
> It might also be a good idea to decouple the library release cycle from
> the software release cycle.
>
> I understand. We may want to explain that not to make users think they
> *need* to download them. I may submit a patch.
>
>
>
>
> - It says "Users who wish to keep their libraries up to date with the
>> latest additions should clone the library repositories using Git.". But,
>> does that apply to footprint libraries? I think my installs have always
>> gone to github for those. Is that true? Do they grab the latest or a
>> specific tag?
>>
> The github plugin in general is a bad idea. It grabs the current master
> head and downloads everything in every session. (At least everytime it
> needs information about footprints for the first time in this session.) It
> does not even use git but pulls a zip archive.
>
> Another problem of having the github plugin is that the libs of the user
> get out of sync. So the symbol libs and 3d model libs stay at the version
> they where at the release of the installed software version. But the
> footprint libs get every change we make in the repos. (This means that if
> we rename a footprint, the footprint filters defined in the symbol might no
> longer work. Or if we change the scaling of the 3d model this will produce
> wrongly scaled results in the 3d viewer until the user manually downloads
> newer 3d models.)
>
> Because we decided to kill the one repo per footprint lib nonsense for the
> v5 release the current github plugin will no longer work there. (So you
> could say the download page is already prepared for the v5 release.)
> Unless of course someone fixes the github plugin such that it supports one
> large repo that holds all footprint libs. (But i would not suggest to use
> it as the default option, because it has the major drawbacks mentioned
> above.)
>
> Thanks, I understand it a bit better now.
>
>
>
>
>
> - I would explain the differences between schematic (old style,
>> per project) and layout libraries (new table style, per project or global).
>> Also in "Future of the Libraries" explain the new symbol table, etc.
>>
> If i read the conversations on the mailing list correctly then kicad 5
> will include a symbol table for managing symbols.
> We could of course add a pointer to the documentation of this stuff. But i
> don't really know where it would fit.
>
>
> - I would maybe mention kicad-packages3d-source (maybe in brackets)
>>
> good idea
>
> Again, I may submit a patch.
>
>
>
> - I would add links to the repos in "Future of the Libraries"
>>
> I think oliver is already designing a better version of the download page.
> Have a look at the other library related conversation here on the mailing
> list.
> https://lists.launchpad.net/kicad-developers/msg31312.html
>

Re: [Kicad-developers] KiCad Libraries (again)

[Diego Herranz]

Thanks, Rene

On 4 Nov 2017 4:06 pm, "Rene Pöschl"  wrote:

On 03/11/17 21:34, Diego Herranz wrote:

> First of all, I think all the recent work around the libraries is great!
> Thanks to everyone involved. I think sometimes libraries are underestimated
> (not just in KiCad). If KiCad manages to have extensive, high-quality and
> clearly arranged libraries, many more users will end up using it.
>
> Having said that, I've used Kicad for some time and even contributed some
> code but still can't fully understand how all the library stuff works. It
> is the most common complaint I read about KiCad by newbies and somehow I
> feel myself in a similar situation.
>
> So, I've reviewed http://kicad-pcb.org/libraries/download/ <
> http://kicad-pcb.org/libraries/download/> with my lack of library
> understanding and will try to provide some feedback from that view:
>
>
> - It seems to imply that the user needs to download the libraries from
> there. However they come with the installer, don't they?
>
A user might want do download an older or newer version of the lib than is
offered with their software version. (Maybe because they want to open a
project designed with this version of the lib.)

And there is talk about giving users the option to get a small installer
without libs. (Some users have data constrains. The installer is now nearly
1GB including all the 3d model libs.)
It might also be a good idea to decouple the library release cycle from the
software release cycle.

I understand. We may want to explain that not to make users think they
*need* to download them. I may submit a patch.




- It says "Users who wish to keep their libraries up to date with the
> latest additions should clone the library repositories using Git.". But,
> does that apply to footprint libraries? I think my installs have always
> gone to github for those. Is that true? Do they grab the latest or a
> specific tag?
>
The github plugin in general is a bad idea. It grabs the current master
head and downloads everything in every session. (At least everytime it
needs information about footprints for the first time in this session.) It
does not even use git but pulls a zip archive.

Another problem of having the github plugin is that the libs of the user
get out of sync. So the symbol libs and 3d model libs stay at the version
they where at the release of the installed software version. But the
footprint libs get every change we make in the repos. (This means that if
we rename a footprint, the footprint filters defined in the symbol might no
longer work. Or if we change the scaling of the 3d model this will produce
wrongly scaled results in the 3d viewer until the user manually downloads
newer 3d models.)

Because we decided to kill the one repo per footprint lib nonsense for the
v5 release the current github plugin will no longer work there. (So you
could say the download page is already prepared for the v5 release.)
Unless of course someone fixes the github plugin such that it supports one
large repo that holds all footprint libs. (But i would not suggest to use
it as the default option, because it has the major drawbacks mentioned
above.)

Thanks, I understand it a bit better now.





- I would explain the differences between schematic (old style,
> per project) and layout libraries (new table style, per project or global).
> Also in "Future of the Libraries" explain the new symbol table, etc.
>
If i read the conversations on the mailing list correctly then kicad 5 will
include a symbol table for managing symbols.
We could of course add a pointer to the documentation of this stuff. But i
don't really know where it would fit.


- I would maybe mention kicad-packages3d-source (maybe in brackets)
>
good idea

Again, I may submit a patch.



- I would add links to the repos in "Future of the Libraries"
>
I think oliver is already designing a better version of the download page.
Have a look at the other library related conversation here on the mailing
list.
https://lists.launchpad.net/kicad-developers/msg31312.html

I think that's different from the landing download page, but not sure how
both would interact.



- If anything of what I said doesn't make sense or it's wrong, please let
> me know. I'd love to understand it better.
>
done

mfg Rene Pöschl


Many thanks for your help, Rene.
Diego
___
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] KiCad Libraries (again)

[Diego Herranz]

First of all, I think all the recent work around the libraries is great!
Thanks to everyone involved. I think sometimes libraries are underestimated
(not just in KiCad). If KiCad manages to have extensive, high-quality and
clearly arranged libraries, many more users will end up using it.

Having said that, I've used Kicad for some time and even contributed some
code but still can't fully understand how all the library stuff works. It
is the most common complaint I read about KiCad by newbies and somehow I
feel myself in a similar situation.

So, I've reviewed http://kicad-pcb.org/libraries/download/ with my lack of
library understanding and will try to provide some feedback from that view:

- It seems to imply that the user needs to download the libraries from
there. However they come with the installer, don't they?
- It says "Users who wish to keep their libraries up to date with the
latest additions should clone the library repositories using Git.". But,
does that apply to footprint libraries? I think my installs have always
gone to github for those. Is that true? Do they grab the latest or a
specific tag?
- I would explain the differences between schematic (old style,
per project) and layout libraries (new table style, per project or global).
Also in "Future of the Libraries" explain the new symbol table, etc.
- I would maybe mention kicad-packages3d-source (maybe in brackets)
- I would add links to the repos in "Future of the Libraries"
- If anything of what I said doesn't make sense or it's wrong, please let
me know. I'd love to understand it better.

Many thanks,
Diego


On Wed, Nov 1, 2017 at 9:32 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Thanks Nick! Really happy to have this running on the website! I think a
> blog post would be a good idea, I'll see if I can make some words
>
> On Thu, Nov 2, 2017 at 8:14 AM, Nick Østergaard  wrote:
>
>> Hello
>>
>> I will just announce that I merged the pull request. I hope this will aid
>> in getting the librarians to feel more part of the "official" KiCad, if
>> they didn't before. I am glad that we have motivated librarians around.
>>
>> I will encourage Oliver and Co. to write an article to the "blog" section
>> if they see fit. http://kicad-pcb.org/post/
>>
>> Nick
>>
>> 2017-10-18 17:04 GMT+02:00 Oliver Walters > >:
>>
>>> I have been working on this for a while, and have submitted the first
>>> version here - https://github.com/KiCad/kicad-website/pull/219
>>>
>>> On Thu, Sep 14, 2017 at 10:01 PM, Oliver Walters <
>>> oliver.henry.walt...@gmail.com> wrote:
>>>
 Hi everyone,

 The conversation of how best to manage and distribute KiCad libraries
 has been raging for a while now.

 Users looking to download or contribute to the libraries are currently
 presented with a github landing page and some bland wiki pages (e.g. for
 the KLC information).

 I have been working on a new-and-improved website system for the
 following:

 * Clear information about the libraries
 * A place to download the latest libraries
 * Information on what is *in* the libraries
 * Instructions on how to contribute to the libs
 * Better presentation of the KLC

 This website will need to be updated periodically to present the latest
 version of the libraries to the users. Also, if users are going to be
 downloading library files then it could potentially use a lot of bandwidth.
 Thirdly, the generated content should be scripted but statically hosted.

 The solution? GitHub pages! - https://pages.github.com/ -

 These are hosted from your github repository, and for e.g. ours would
 have the URL kicad.github.io - this could be easily redirected from
 kicad-lib.org/library (for example).

 GitHub pages use the jekyll toolset to generate static content.

 With a small amount of additional Python scripting I have created a
 bare-bones example of what this might look like (locally hosted on my
 laptop for now):

 Here are some screenshots! Ignore the colors and simple layout scheme,
 this is currently just a framework.

 https://imgur.com/a/0GELG

 The main objectives of this project are:

 a) Present a more professional landing page for the libraries
 b) Leverage GitHub Pages functionality
 c) Improve KLC

 And, eventually:

 Provide a standardised way to separate the KiCad libraries from the
 KiCad installer!

 Thoughts and comments appreciated!

 Cheers,

 Oliver

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

Re: [Kicad-developers] GitHub Plugin (my nemesis)

[Diego Herranz]

I completely understand Oliver's view on maintaining every individual repo
even if they are submodules of a kicad-footprint repo.

Even from an a user perspective (which is clearly easier than the
maintainer one), I like knowing what progress is being made, so I'd like to
subscribe for updates of a single repo on github, to follow commits, pull
requests, etc. There's no way I will subscribe to every repo and what's
most difficult, checking to make sure that I subscribe for new repos as
they are created too.

I have basically no say here, but I'd go for a single repo and no
submodules.

Thanks,
Diego

On Thu, Sep 28, 2017 at 6:53 PM, Bernhard Stegmaier  wrote:

> Just my 2 cents… I have seen some projects using submodules (open source
> and in my company).
> I have seen lots of problems and complaints (… doesn’t compile …) just
> because normal users or even normal developers (being no git experts)
> didn’t sync all submodules correctly.
> Thinking of how many problems are already seen now by users which are not
> used to version control systems (because they just don’t understand what’s
> happening under the hood) I wouldn’t want to force them to use git
> submodules… at least not as long as this is not completely hidden by some
> users friendly and dead simple KiCad GUI.
>
>
> Regards,
> Bernhard
>
> On 28. Sep 2017, at 13:29, Oliver Walters 
> wrote:
>
> Simon, David,
>
> Thanks for the synopsis of your idea David, there are certainly some
> advantages to using the submodule approach.
>
> Is it github compatible?
>
>
> Simon, yes git-submodule is compatible with github. I have a test
> repository here - https://github.com/kicad/kicad-footprints - this
> contains a submodule for each of the current footprint directories.
>
> Does it simplify the maintenance of the kicad library by the librarians?
>
>
> Compared to having all the .pretty folders as subdirectories of a single
> repo, no. Reorganising libraries or adding new ones is tedious, and for
> each of the 100+ .pretty repos, we (the librarians) have to manage:
>
> * Pull requests and isues
> * CI tools (e.g. Travis KLC scripts)
> * Updating each library when new requirements are enacted (e.g. KLC)
> * Ensure that changes in one repo do not conflict with a different repo
> * Handle reclassification or moving of footprints between repos
>
> It is also quite possible for submodules to become out of sync. The link
> that Simon posted has some a good example of how this can occur (detached
> head). I have some projects at work that contain about 5 submodules and it
> rapidly becomes difficult to deal with even for a competent user of Git.
>
> It becomes harder for users, too. KiCad users cannot, in the general case,
> be classified as competent users of git. Currently, users who wish to
> contribute to the footprint libraries have a hard time. For each library
> they want to contribute to, they have to fork and manage another
> repository. Personally I have done this for 50 separate repositories.
>
> Further, once changes are made to each submodule, the master repository
> then needs to be updated otherwise it's not up to date with the latest
> changes. Perhaps we can use git hooks here, but this is just further
> complication!
>
> Let's also consider consistency. The footprint libraries are (currently)
> split into separate repos. However the symbol libraries and 3d model
> libraries are not. Should we split them too? Now we have 300+ repositories
> to manage.
>
> Let's not make this an academic problem and say "but it's possible to
> manage with this complex set of tools"! From the perspective of a
> contributor, and as the person who has to manage the libraries, the simpler
> the better.
>
> Oliver
>
>
>
> On Thu, Sep 28, 2017 at 7:25 PM, Simon Küppers 
> wrote:
>
>> Thanks for your detailed description. I think it is a nice way to go.
>> However two remarks:
>> Does it simplify the maintenance of the kicad library by the librarians?
>> Is it github compatible? If not, we would need to find another platform to
>> host the libraries.
>>
>> If I look for git submodule, there is a lot of different opinions on why
>> you should or should not use it. (e.g. https://www.google.de/amp/s/co
>> dingkilledthecat.wordpress.com/2012/04/28/why-your-company-
>> shouldnt-use-git-submodules/amp/). Does it apply in our case? What about
>> git subtree?
>>
>> Best regards
>> Simon
>>
>> Am 28. September 2017 02:37:09 MESZ schrieb David Godfrey <
>> i...@sbts.com.au>:
>>
>>> Hi All
>>>
>>> I have to agree with some of the other posters, why not use git as it
>>> was intended?
>>>
>>> Specifically I think the following makes sense.
>>>
>>> - Keep the multiple repositories, this helps when a company only wants
>>> to make certain sets of libs available to it's staff
>>>
>>> - Have a master repository that includes all other repositories as
>>> submodules.
>>>
>>> - Have branches that are matched to kicad versions. This allows
>>> footprint changes in a version safe way.

Re: [Kicad-developers] New feature: support for Gerber job file.

[Diego Herranz]

Hi JP,

Is this something new in GerberX2? I had never seen Gerber
jobfiles before...

I've given it a try (export and then load on GerbView) and seems to work
OK, it loads every layer by just loading the jobfile.
Any other gerber viewer which supports it to give it a try? gerbv
 doesn't seem to support it.

Thanks,
Diego



On Wed, Aug 30, 2017 at 5:35 PM, jp charras  wrote:

> Le 30/08/2017 à 18:02, Jon Evans a écrit :
> > Hi JP,
> >
> > This is a nice feature and it seems to work well!
> > I did have to make one change in gerber_jobfile_writer.cpp:154 to get it
> to compile on MacOS / LLVM:
> > adding c_str()
> >
> > fputs( header[ii].c_str(), jobFile );
> >
> > Best,
> > Jon
> >
>
> Thanks.
>
> I committed a fix (use TO_UTF8() instead of c_str() ). It should work on
> all platforms.
>
>
> > On Wed, Aug 30, 2017 at 11:26 AM, jp charras  >
> > wrote:
> >
> > Le 30/08/2017 à 13:40, Marcos Chaparro a écrit :
> > > For simple jobs I tell the manufacturer layer count and pcb
> thickness, both parameters are available
> > > in design rules->layers setup
> >
> > Sure, for simple jobs, this is enough.
> >
> > But in more tricky cases ( impedance controlled boards, or boards
> using large tracks for high
> > currents ), you need to add a lot more info.
> > For instance:
> > - Dielectric thickness for each layer (and sometimes dielectric
> constant and thickness tolerance for
> > impedance controlled ).
> >   It is not always the (pcb thickness) / (number of layers-1)
> > - Copper layers thickness (not necessary the same for all layers).
> > - Where are the core and prepeg layers.
> > - Color of solder masks and/or silk screen
> > - The finishing of external copper layers
> > and certainly more...
> >
> > Of course, you can send this info to the manufacturer in a text file
> written by hand, but
> > a board layers stack editor and the associated Gerber job file are a
> convenient way to manage these
> > cases.
> > Moreover, a board layers stack editor could help to manage
> blind/buried vias constraints.
> > (Currently there is no constraint for blind/buried vias, but many
> manufacturers have constraints)
> >
> > > Silkscreen and soldermask colors are somehow stored for 3Dviewer,
> maybe they are not stored in a
> > > usable way.
> >
> > Not usable, because it does not live in the .kicad_pcb file but in
> your user preferences.
> >
> > >
> > > Cheers
> > >
> > > Marcos>
> > > On Wed, Aug 30, 2017 at 8:16 AM, jp charras  >   >>
> > > wrote:
> > >
> > > Hi all,
> > >
> > > I just committed a basic support for Gerber job file.
> > >
> > > The purpose of a Gerber job file is to handle info needed for
> board manufacturing.
> > >
> > > Because (unfortunately) Pcbnew has not actual support of the
> board layers stack, info about layer
> > > stack, dielectric and copper thickness, silkscreen color,
> finishing external copper layers... is not
> > > output in the job file.
> > >
> > > However, this job file contains (among a few other useful
> parameters) the list of Gerber plot files
> > > created by the plot dialog, and loading this file by Gerbview
> loads also all Gerber files created by
> > > this plot dialog.
> > >
> > > Please, try it.
> > >
> > > --
> > > Jean-Pierre CHARRAS
> --
> 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
>
___
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] ATTN: Package Maintainers - RFC: Library Reorganization

[Diego Herranz]

Thanks, Oliver and Wayne, for the replies.
Keep us posted with all progress related to this.

Thanks,
Diego

On Fri, Jul 14, 2017 at 2:45 PM, Wayne Stambaugh 
wrote:

> On 7/14/2017 9:31 AM, Oliver Walters wrote:
> > Hi Diego,
> >
> >
> >
> > Thinking of naming, should we use "kicad-packages3d" to keep the
> > same format (kicad-symbols)?
> >
> >
> > That's not a bad idea, I was considering this myself. It would make
> > sense to rename this before a v5 release
> >
> >  On a separate note, how does this work with the future symbols
> > (.sweet)? Would that happen on v5 as well? Would that be a different
> > repo?
> >
> >
> > I'm not sure on the plan for .sweet in v5, I thought it was just the
> > symbol-table and .sweet was v6, which means that the reorganization will
> > be separate from the transfer to using .sweet libraries. I imagine there
> > will need to be some scripts written to convert all the symbols.
>
> Sweet will not be completed for v5.  Only the symbol library table will
> be implemented.  The new symbol library file (sweet) and schematic file
> formats are expected to be part of the v6 release.
>
> >
> >  You say footprint libraries will remain as they are. Does that
> > mean no unified repo?
> >
> >
> > For now, at least. I want to merge them into a single kicad-footprints
> > repo but this will require a lot of work because we have to maintain
> > support for users who use the GitHub plugin to access repositories
> > individually. I have yet to develop a clear plan to address this. One
> > thing at a time :)
> >
> > Thanks!
> >
> > On Fri, Jul 14, 2017 at 11:24 PM, Diego Herranz
> > mailto:diegoherr...@diegoherranz.com>>
> > wrote:
> >
> > Hi, Oliver.
> >
> > When I started using KiCad I got confused with the repos for
> > symbols, footprints and 3D models. I think it's getting better and
> > this will make it easier.
> >
> > Thinking of naming, should we use "kicad-packages3d" to keep the
> > same format (kicad-symbols)?
> >
> > On a separate note, how does this work with the future symbols
> > (.sweet)? Would that happen on v5 as well? Would that be a different
> > repo? Or kicad-symbols would get updated to hold .sweet files
> instead?
> > You say footprint libraries will remain as they are. Does that mean
> > no unified repo?
> >
> > Thanks!
> >
> > On Fri, Jul 14, 2017 at 2:18 AM, Oliver Walters
> >  > <mailto:oliver.henry.walt...@gmail.com>> wrote:
> >
> > To the package maintainers:
> >
> > There has been a lot of movement of late by the library team,
> > with a view to improve (vastly) the quality of the symbol
> libraries.
> >
> > The major change is our plan to reorganize the symbol libraries
> > to bring some consistency - currently they are scattered and
> > there is no real rhyme or reason to library convention.
> >
> > Reference - https://github.com/KiCad/kicad-library/issues/1402
> > <https://github.com/KiCad/kicad-library/issues/1402>
> >
> > This is a big change - so much so that I would like to retain a
> > separation between the current symbol libraries (for legacy
> > compatibility). My suggestion is to enact the new symbols in a
> > new repository:
> >
> > <http://goog_1316844941>
> > https://github.com/kicad/kicad-symbols
> > <https://github.com/kicad/kicad-symbols>
> >
> > We currently have a separate discussion underway as to how we
> > manage migration to the new repository (or whether we simply
> > make a block change to the current one)
> > - https://github.com/KiCad/kicad-library/issues/1415
> > <https://github.com/KiCad/kicad-library/issues/1415>
> >
> > A further very important note is that there is a new repository
> > for 3d models, which is of far higher quality
> > - https://github.com/kicad/packages3d
> > <https://github.com/kicad/packages3d>
> >
> > This repository should supersede the 3d models currently located
> > in the kicad-library repository. This also brings a functional
> > separation between the symbol libraries and the 3d library,
> > which is fantastic.
> >
> 

Re: [Kicad-developers] ATTN: Package Maintainers - RFC: Library Reorganization

[Diego Herranz]

Hi, Oliver.

When I started using KiCad I got confused with the repos for symbols,
footprints and 3D models. I think it's getting better and this will make it
easier.

Thinking of naming, should we use "kicad-packages3d" to keep the same
format (kicad-symbols)?

On a separate note, how does this work with the future symbols (.sweet)?
Would that happen on v5 as well? Would that be a different repo?
Or kicad-symbols would get updated to hold .sweet files instead?
You say footprint libraries will remain as they are. Does that mean no
unified repo?

Thanks!

On Fri, Jul 14, 2017 at 2:18 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> To the package maintainers:
>
> There has been a lot of movement of late by the library team, with a view
> to improve (vastly) the quality of the symbol libraries.
>
> The major change is our plan to reorganize the symbol libraries to bring
> some consistency - currently they are scattered and there is no real rhyme
> or reason to library convention.
>
> Reference - https://github.com/KiCad/kicad-library/issues/1402
>
> This is a big change - so much so that I would like to retain a separation
> between the current symbol libraries (for legacy compatibility). My
> suggestion is to enact the new symbols in a new repository:
>
> 
> https://github.com/kicad/kicad-symbols
>
> We currently have a separate discussion underway as to how we manage
> migration to the new repository (or whether we simply make a block change
> to the current one) - https://github.com/KiCad/kicad-library/issues/1415
>
> A further very important note is that there is a new repository for 3d
> models, which is of far higher quality - https://github.com/kicad/
> packages3d
>
> This repository should supersede the 3d models currently located in the
> kicad-library repository. This also brings a functional separation between
> the symbol libraries and the 3d library, which is fantastic.
>
>
> My goal for release concurrent with KiCad v5 is thus:
>
> a) Mark kicad-library as legacy and don't package with v5
> b) Package kicad-symbols as the symbol libraries
> c) Package packages3d as the 3D model libraries
>
> I'm not 100% on top of how the packaging takes place so if there are any
> good reasons that this should not take place as I have laid out above,
> please let me know now.
>
> The footprint libraries will remain as they are for v5. I have some ideas
> there but they require a lot more work - this is the first step towards the
> KiCad Library Management Manifesto (evil laugh).
>
> Regards,
> Oliver
>
> ___
> 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] correct text inside two importantplot windows

[Diego Herranz]

Hi,

Random comments for a few of the topics discussed or proposed:

- "Format" -> "Coordinate Format": The Gerber standard

uses
Coordinate format for this, so I think this change is OK.

- "solder mask" vs "solder stop mask": I'm European and I've never used (or
heard used) "solder stop mask". Always solder mask or I've also used resist
or solder resist. But I think solder mask is the most common.

- "Save Messages to File": +1

- "Default line width" -> "Line width": please don't. The former is more
descriptive and correct in my opinion.

Thanks,

Diego

On Wed, Jun 21, 2017 at 5:59 PM, Wayne Stambaugh 
wrote:

> Fabrizio,
>
> I finally had a chance to look at this.  Here are my comments.
>
> You fixed the capitalization for some labels but broke it for others.
> Please take a look at the "Capitalization Table" section in the KiCad
> "User Interface Guidelines" [1] and make the appropriate changes.
>
> For the most part we do not use colons (:) at the end of group box
> label.  I know we are not as consistent with this as we should be but
> most of the dialogs do not use them.  We should probably make this a UI
> policy.  Text labels for other controls should have a colon at the end.
>
> I don't think the wording change from "Current solder mask settings" to
> "Solder Stop Mask Options" is very good.  Here in the states, I cannot
> ever remember some referring to solder mask as solder stop mask.  Maybe
> this is a European thing.
>
> The "Save Output" button could be more descriptive.  The previous label
> was better (although capitalized incorrectly).  Perhaps "Save Messages
> to File" would be better.
>
> Everything else seems fine to me.
>
> Cheers,
>
> Wayne
>
>
> [1]:
> http://docs.kicad-pcb.org/doxygen/md_Documentation_
> development_ui-policy.html
>
> On 6/9/2017 6:43 AM, Fabrizio Tappero wrote:
> > things like
> >
> > Options => Options:
> > 4.5 (unit mm) => 4.5, unit mm
> > Messages => Output Mesages:
> > Save report to file... => Save Output
> > Capital letters, shorten sentences, etc
> >
> > Please refer to the patch for a detailed
> >
> > cheers
> > Fabrizio
> >
> >
> > On Fri, Jun 9, 2017 at 12:31 AM, liyoubdu  > > wrote:
> >
> >
> > It is not obvious what you changed here
> > ---Original---
> > *From:* "Nick Østergaard" oe.n...@gmail.com>>
> > *Date:* 2017/6/9 00:39:01
> > *To:* "Fabrizio Tappero" > >;
> > *Cc:* "KiCad Developers" > >;
> > *Subject:* Re: [Kicad-developers] [PATCH] correct text inside two
> > importantplot windows
> >
> > It is not obvious what you changed here. Could you explain in detail?
> >
> > 2017-06-08 13:00 GMT+02:00 Fabrizio Tappero
> > mailto:fabrizio.tapp...@gmail.com>>:
> >
> > Hello,
> > the following patch corrects some text
> > ​ and labels​
> > inside the two Plot menus accessible from schematic editor and
> > pcb editor. See below
> >
> > ​​
> > ​​
> >
> >
> >
> > So that we know what we are talking about I include here a
> > before vs after comparison
> >
> >
> >
> >
> >
> >
> >
> > ​Cheers
> > Fabrizio
> >
> > ___
> > 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

[Kicad-developers] [PATCH]: Calculator: Simplify color code tolerance chooser + typo

[Diego Herranz]

Hi,

Commit message:
"
Since for this tool the only difference for different tolerances
is the 4th band, which is present for tolerance <= 2% and not
present for 10%/5%, reduce radio choices to those two groups for
clarity.

Fix a typo (4rd -> 4th) and rename one variable to make it
more descriptive as well.
"

In my opinion, reducing the number of tolerance choices makes sense
and makes it easier to understand, however, I understand that this is
subjective and others may think differently.

If you didn't want to include these changes, please let me know and I'll
create another patch for the typo only.

Thanks,
Diego
From 03ee65284fdb24aea5eb8499b0044b3e56747ac7 Mon Sep 17 00:00:00 2001
From: Diego Herranz 
Date: Sat, 25 Feb 2017 06:22:17 +
Subject: [PATCH] Calculator: Simplify color code tolerance chooser + typo

Since for this tool the only difference for different tolerances
is the 4th band, which is present for tolerance <= 2% and not
present for 10%/5%, reduce radio choices to those two groups for
clarity.

Fix a typo (4rd -> 4th) and rename one variable to make it
more descriptive as well.
---
 pcb_calculator/colorcode.cpp   | 24 --
 .../dialogs/pcb_calculator_frame_base.cpp  |  4 ++--
 .../dialogs/pcb_calculator_frame_base.fbp  |  4 ++--
 3 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/pcb_calculator/colorcode.cpp b/pcb_calculator/colorcode.cpp
index d102461..a14569b 100644
--- a/pcb_calculator/colorcode.cpp
+++ b/pcb_calculator/colorcode.cpp
@@ -36,25 +36,27 @@ void PCB_CALCULATOR_FRAME::OnToleranceSelection( wxCommandEvent& event )
 
 void PCB_CALCULATOR_FRAME::ToleranceSelection( int aSelection )
 {
-/* For tolerance = 5 or 10 %, there are 3 ring for the value
- * but for tolerance < 5 %, there are 4 ring
+/* For tolerance = 5 or 10 %, there are 3 bands for the value
+ * but for tolerance < 5 %, there are 4 bands
  */
-bool enable = true;
+bool show4thBand;
 switch( aSelection )
 {
-case 0:
-case 1:
-enable = false;
+case 0: // 5 or 10 %
+show4thBand = false;
 break;
-
-default:
+case 1: // < 5 %
+show4thBand = true;
+break;
+default: // Show 4th band if something went wrong
+show4thBand = true;
 break;
 }
 bool oldstate = m_Band4Label->IsShown();
-if( oldstate != enable )
+if( oldstate != show4thBand )
 {
-m_Band4bitmap->Show(enable);
-m_Band4Label->Show(enable);
+m_Band4bitmap->Show(show4thBand);
+m_Band4Label->Show(show4thBand);
 // m_Band4Label visibility has changed:
 // The new size must be taken in account
 m_panelColorCode->GetSizer()->Layout();
diff --git a/pcb_calculator/dialogs/pcb_calculator_frame_base.cpp b/pcb_calculator/dialogs/pcb_calculator_frame_base.cpp
index 93ca9dd..b90b423 100644
--- a/pcb_calculator/dialogs/pcb_calculator_frame_base.cpp
+++ b/pcb_calculator/dialogs/pcb_calculator_frame_base.cpp
@@ -1176,7 +1176,7 @@ PCB_CALCULATOR_FRAME_BASE::PCB_CALCULATOR_FRAME_BASE( wxWindow* parent, wxWindow
 	wxBoxSizer* bSizerPanelColorCode;
 	bSizerPanelColorCode = new wxBoxSizer( wxHORIZONTAL );
 	
-	wxString m_rbToleranceSelectionChoices[] = { _("10%"), _("5%"), _("2%"), _("1%"), _("0.5%"), _("0.25%"), _("0.1%"), _("0.05%") };
+	wxString m_rbToleranceSelectionChoices[] = { _("10% / 5%"), _("<= 2%") };
 	int m_rbToleranceSelectionNChoices = sizeof( m_rbToleranceSelectionChoices ) / sizeof( wxString );
 	m_rbToleranceSelection = new wxRadioBox( m_panelColorCode, wxID_ANY, _("Tolerance"), wxDefaultPosition, wxDefaultSize, m_rbToleranceSelectionNChoices, m_rbToleranceSelectionChoices, 1, wxRA_SPECIFY_COLS );
 	m_rbToleranceSelection->SetSelection( 0 );
@@ -1199,7 +1199,7 @@ PCB_CALCULATOR_FRAME_BASE::PCB_CALCULATOR_FRAME_BASE( wxWindow* parent, wxWindow
 	m_staticText35->Wrap( -1 );
 	fgSizerColoCode->Add( m_staticText35, 0, wxALL|wxALIGN_CENTER_HORIZONTAL, 5 );
 	
-	m_Band4Label = new wxStaticText( m_panelColorCode, wxID_ANY, _("4rd Band"), wxDefaultPosition, wxDefaultSize, 0 );
+	m_Band4Label = new wxStaticText( m_panelColorCode, wxID_ANY, _("4th Band"), wxDefaultPosition, wxDefaultSize, 0 );
 	m_Band4Label->Wrap( -1 );
 	fgSizerColoCode->Add( m_Band4Label, 0, wxALL|wxALIGN_CENTER_HORIZONTAL, 5 );
 	
diff --git a/pcb_calculator/dialogs/pcb_calculator_frame_base.fbp b/pcb_calculator/dialogs/pcb_calculator_frame_base.fbp
index 96663d1..5267723 100644
--- a/pcb_calculator/dialogs/pcb_calculator_frame_base.fbp
+++ b/pcb_calculator/dialogs/pcb_calculator_frame_base.fbp
@@ -17732,7 +17732,7 @@
 

Re: [Kicad-developers] [PATCH] Pcbnew, plot dialog: grey out advanced net attributes if Gerber X2 is unchecked.

[Diego Herranz]

I didn't know about wxUpdateUIEvent at all. I'll have a look and try to
rewrite it using it when I've got time.

Thanks!

On Thu, Jan 5, 2017 at 2:10 PM, Wayne Stambaugh 
wrote:

> On 1/5/2017 9:03 AM, Chris Pavlina wrote:
> > Okay, thanks for letting me know. If this was policy, I forgot about it.
>
> It's not in our UI policy but it probably should be.  I know I've
> mentioned it before.  I'll add that to my todo list.
>
> >
> > Do you want me to rework the patch to use wxUpdateUIEvent?
>
> Don't bother unless you have the time.  It might be a good exercise for
> Diego to learn how to use wxUpdateUIEvent.
>
> >
> > On Thu, Jan 05, 2017 at 08:57:14AM -0500, Wayne Stambaugh wrote:
> >> Thanks Chris.  In the future, please make sure that contributions use
> >> wxUpdateUIEvent for updating UI states.  A single code path for updating
> >> UI element states prevents potential state conflicts when setting the
> >> state in multiple wxCommandEvents.  We have had issues with this in the
> >> past where a UI element state would get toggled in one command event and
> >> toggled again in a different command event causing the UI element state
> >> to be incorrect.
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> On 1/4/2017 5:18 PM, Chris Pavlina wrote:
> >>> Looks good to me, I pushed it. Thank you for your contribution to
> KiCad.
> >>>
> >>> It's easy for patches to slip through the cracks - in the future, don't
> >>> be afraid to bump a patch a bit sooner, say within a week or two.
> >>> Apologies for losing it.
> >>>
> >>> On Wed, Jan 04, 2017 at 07:45:40PM +, Diego Herranz wrote:
> >>>> Hi,
> >>>>
> >>>> Did anyone have a chance to look at this?
> >>>>
> >>>> Many thanks.
> >>>>
> >>>> Regards,
> >>>> Diego
> >>>>
> >>>> On Tue, Nov 22, 2016 at 8:10 AM, Diego Herranz <
> >>>> diegoherr...@diegoherranz.com> wrote:
> >>>>
> >>>>>
> >>>>> m_useGerberNetAttributes is useless if m_useGerberX2Attributes is not
> >>>>> checked.
> >>>>> So disabled (greyed out) when Gerber X2 gets unchecked to make it
> clear to
> >>>>> the user.
> >>>>> ---
> >>>>>  pcbnew/dialogs/dialog_plot.cpp  | 20 
> >>>>>  pcbnew/dialogs/dialog_plot.h|  3 ++-
> >>>>>  pcbnew/dialogs/dialog_plot_base.cpp |  4 +++-
> >>>>>  pcbnew/dialogs/dialog_plot_base.fbp |  2 +-
> >>>>>  pcbnew/dialogs/dialog_plot_base.h   |  3 ++-
> >>>>>  5 files changed, 28 insertions(+), 4 deletions(-)
> >>>>>
> >>>>>
> >>>
> >>>
> >>> ___
> >>> 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] [PATCH] Pcbnew, plot dialog: grey out advanced net attributes if Gerber X2 is unchecked.

[Diego Herranz]

Hi,

Did anyone have a chance to look at this?

Many thanks.

Regards,
Diego

On Tue, Nov 22, 2016 at 8:10 AM, Diego Herranz <
diegoherr...@diegoherranz.com> wrote:

>
> m_useGerberNetAttributes is useless if m_useGerberX2Attributes is not
> checked.
> So disabled (greyed out) when Gerber X2 gets unchecked to make it clear to
> the user.
> ---
>  pcbnew/dialogs/dialog_plot.cpp  | 20 
>  pcbnew/dialogs/dialog_plot.h|  3 ++-
>  pcbnew/dialogs/dialog_plot_base.cpp |  4 +++-
>  pcbnew/dialogs/dialog_plot_base.fbp |  2 +-
>  pcbnew/dialogs/dialog_plot_base.h   |  3 ++-
>  5 files changed, 28 insertions(+), 4 deletions(-)
>
>
___
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] [PATCH] Pcbnew, plot dialog: grey out advanced net attributes if Gerber X2 is unchecked.

[Diego Herranz]

m_useGerberNetAttributes is useless if m_useGerberX2Attributes is not checked.
So disabled (greyed out) when Gerber X2 gets unchecked to make it clear to
the user.
---
 pcbnew/dialogs/dialog_plot.cpp  | 20 
 pcbnew/dialogs/dialog_plot.h|  3 ++-
 pcbnew/dialogs/dialog_plot_base.cpp |  4 +++-
 pcbnew/dialogs/dialog_plot_base.fbp |  2 +-
 pcbnew/dialogs/dialog_plot_base.h   |  3 ++-
 5 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/pcbnew/dialogs/dialog_plot.cpp b/pcbnew/dialogs/dialog_plot.cpp
index 0e51867..dea1cec 100644
--- a/pcbnew/dialogs/dialog_plot.cpp
+++ b/pcbnew/dialogs/dialog_plot.cpp
@@ -166,6 +166,9 @@ void DIALOG_PLOT::Init_Dialog()
 // Option for including Gerber netlist info (from Gerber X2 format) in the output
 #ifdef KICAD_USE_GBR_NETATTRIBUTES
 m_useGerberNetAttributes->SetValue( m_plotOpts.GetIncludeGerberNetlistInfo() );
+
+// Grey out if m_useGerberX2Attributes is not checked
+m_useGerberNetAttributes->Enable( m_useGerberX2Attributes->GetValue() );
 #else
 m_plotOpts.SetIncludeGerberNetlistInfo( false );
 m_useGerberNetAttributes->SetValue( false );
@@ -670,6 +673,23 @@ void DIALOG_PLOT::applyPlotSettings()
 }
 
 
+void DIALOG_PLOT::OnGerberX2Checked( wxCommandEvent& event )
+{
+// m_useGerberNetAttributes is useless if m_useGerberX2Attributes
+// is not checked. So disabled (greyed out) when Gerber X2 gets unchecked
+// to make it clear to the user.
+if( m_useGerberX2Attributes->GetValue() )
+{
+m_useGerberNetAttributes->Enable( true );
+}
+else
+{
+m_useGerberNetAttributes->Enable( false );
+m_useGerberNetAttributes->SetValue( false );
+}
+}
+
+
 void DIALOG_PLOT::Plot( wxCommandEvent& event )
 {
 applyPlotSettings();
diff --git a/pcbnew/dialogs/dialog_plot.h b/pcbnew/dialogs/dialog_plot.h
index c4e152a..5fa534e 100644
--- a/pcbnew/dialogs/dialog_plot.h
+++ b/pcbnew/dialogs/dialog_plot.h
@@ -68,9 +68,10 @@ private:
 voidSetPlotFormat( wxCommandEvent& event ) override;
 voidOnSetScaleOpt( wxCommandEvent& event ) override;
 voidCreateDrillFile( wxCommandEvent& event ) override;
+voidOnGerberX2Checked( wxCommandEvent& event ) override;
 	virtual void onRunDRC( wxCommandEvent& event ) override;
 
-// orther functions
+// other functions
 voidapplyPlotSettings();
 PlotFormat  getPlotFormat();
 
diff --git a/pcbnew/dialogs/dialog_plot_base.cpp b/pcbnew/dialogs/dialog_plot_base.cpp
index f14b082..2610f6d 100644
--- a/pcbnew/dialogs/dialog_plot_base.cpp
+++ b/pcbnew/dialogs/dialog_plot_base.cpp
@@ -1,5 +1,5 @@
 ///
-// C++ code generated with wxFormBuilder (version May  6 2016)
+// C++ code generated with wxFormBuilder (version Feb 16 2016)
 // http://www.wxformbuilder.org/
 //
 // PLEASE DO "NOT" EDIT THIS FILE!
@@ -410,6 +410,7 @@ DIALOG_PLOT_BASE::DIALOG_PLOT_BASE( wxWindow* parent, wxWindowID id, const wxStr
 	m_browseButton->Connect( wxEVT_COMMAND_BUTTON_CLICKED, wxCommandEventHandler( DIALOG_PLOT_BASE::OnOutputDirectoryBrowseClicked ), NULL, this );
 	m_layerCheckListBox->Connect( wxEVT_RIGHT_DOWN, wxMouseEventHandler( DIALOG_PLOT_BASE::OnRightClick ), NULL, this );
 	m_scaleOpt->Connect( wxEVT_COMMAND_CHOICE_SELECTED, wxCommandEventHandler( DIALOG_PLOT_BASE::OnSetScaleOpt ), NULL, this );
+	m_useGerberX2Attributes->Connect( wxEVT_COMMAND_CHECKBOX_CLICKED, wxCommandEventHandler( DIALOG_PLOT_BASE::OnGerberX2Checked ), NULL, this );
 	m_plotButton->Connect( wxEVT_COMMAND_BUTTON_CLICKED, wxCommandEventHandler( DIALOG_PLOT_BASE::Plot ), NULL, this );
 	m_buttonDrill->Connect( wxEVT_COMMAND_BUTTON_CLICKED, wxCommandEventHandler( DIALOG_PLOT_BASE::CreateDrillFile ), NULL, this );
 	m_buttonDRC->Connect( wxEVT_COMMAND_BUTTON_CLICKED, wxCommandEventHandler( DIALOG_PLOT_BASE::onRunDRC ), NULL, this );
@@ -431,6 +432,7 @@ DIALOG_PLOT_BASE::~DIALOG_PLOT_BASE()
 	m_browseButton->Disconnect( wxEVT_COMMAND_BUTTON_CLICKED, wxCommandEventHandler( DIALOG_PLOT_BASE::OnOutputDirectoryBrowseClicked ), NULL, this );
 	m_layerCheckListBox->Disconnect( wxEVT_RIGHT_DOWN, wxMouseEventHandler( DIALOG_PLOT_BASE::OnRightClick ), NULL, this );
 	m_scaleOpt->Disconnect( wxEVT_COMMAND_CHOICE_SELECTED, wxCommandEventHandler( DIALOG_PLOT_BASE::OnSetScaleOpt ), NULL, this );
+	m_useGerberX2Attributes->Disconnect( wxEVT_COMMAND_CHECKBOX_CLICKED, wxCommandEventHandler( DIALOG_PLOT_BASE::OnGerberX2Checked ), NULL, this );
 	m_plotButton->Disconnect( wxEVT_COMMAND_BUTTON_CLICKED, wxCommandEventHandler( DIALOG_PLOT_BASE::Plot ), NULL, this );
 	m_buttonDrill->Disconnect( wxEVT_COMMAND_BUTTON_CLICKED, wxCommandEventHandler( DIALOG_PLOT_BASE::CreateDrillFile ), NULL, this );
 	m_buttonDRC->Disconnect( wxEVT_COMMAND_BUTTON_CLICKED, wxCommandEventHandler( DIALOG_PLOT_BASE::onRunDRC ), NULL, this );
diff --git a/pcbnew/dialogs/dialog_plot_base.fbp b/pcbn

Re: [Kicad-developers] [PATCH] Pcbnew: fix plot dialog tip text

[Diego Herranz]

Thanks!

By the way, I just spotted the "PLEASE DO "NOT" EDIT THIS FILE!". Oops!
Thanks for fixing it the right way :)

Diego

On Sat, Nov 19, 2016 at 9:31 AM, jp charras  wrote:

> Le 19/11/2016 à 00:12, Diego Herranz a écrit :
> >
> > I guess this was a literal translation from French "Ne plus..."?
> >
> > Signed-off-by: Diego Herranz 
> > ---
> >  pcbnew/dialogs/dialog_plot_base.cpp | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Thanks. I committed your fix.
>
>
> --
> 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
>
___
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] [PATCH] Pcbnew: fix plot dialog tip text

[Diego Herranz]

I guess this was a literal translation from French "Ne plus..."?

Signed-off-by: Diego Herranz 
---
 pcbnew/dialogs/dialog_plot_base.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pcbnew/dialogs/dialog_plot_base.cpp b/pcbnew/dialogs/dialog_plot_base.cpp
index d0a567b..a35b81b 100644
--- a/pcbnew/dialogs/dialog_plot_base.cpp
+++ b/pcbnew/dialogs/dialog_plot_base.cpp
@@ -224,7 +224,7 @@ DIALOG_PLOT_BASE::DIALOG_PLOT_BASE( wxWindow* parent, wxWindowID id, const wxStr
 	bSizerGbrOpt = new wxBoxSizer( wxVERTICAL );
 	
 	m_useGerberExtensions = new wxCheckBox( m_GerberOptionsSizer->GetStaticBox(), wxID_ANY, _("Use Protel filename extensions"), wxDefaultPosition, wxDefaultSize, 0 );
-	m_useGerberExtensions->SetToolTip( _("Use Protel Gerber extensions - .GBL, .GTL, etc...\nNo more recommended. The official extension is .gbr") );
+	m_useGerberExtensions->SetToolTip( _("Use Protel Gerber extensions - .GBL, .GTL, etc...\nNo longer recommended. The official extension is .gbr") );
 	
 	bSizerGbrOpt->Add( m_useGerberExtensions, 0, wxALL, 2 );
 	
___
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