Re: [Kicad-developers] Do Not Fit

[Oliver Walters]

>
> I understand your frustration but I'm currently working on the new file
> format so I am not interested in adding a new feature to the current
> schematic file format.  This feature is already rolled into the new
> schematic file format.  I should have most of this work complete by the
> end of the year so it makes no sense to divert resources from the new
> file format development to test and maintain the proposed changes to the
> current file format.  The current file format is frozen permanently so
> that we can focus on the new format.
>
>
Wayne, thanks for your prompt feedback on this. Can I ask, does the new
format support simple "DNF" marking or full variant support?

Nobody in this thread has yet mentioned KiBoM, which has this
> kind of capability.  It has its quirks, to be sure, but I would
> recommend investigating it first, before starting to write something new.
>
>
I actually wrote that tool (many moons ago) to fill the gaps of KiCad
assembly management. I would love to see some if its features integrated
into KiCad directly.



On Thu, Sep 19, 2019 at 8:47 PM Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Hi all,
>
> Almost a year ago now I suggested a feature addition, allowing for marking
> parts in the schematic as "DO NOT FIT"
>
> https://lists.launchpad.net/kicad-developers/msg38415.html
>
> I had made a lot of progress towards feature completion, however was told
> at the time that such a feature would not be accepted.
>
> A year later, and after a lot of frustration of  sending the wrong files
> out for manufacturer due to confusion about which parts are fitted, I'd
> like to raise the issue again.
>
> Currently parts are marked as "DNF" by setting a special field in the BOM
> and checking for this with a special export script.
>
> However, I feel (and I'm sure many would agree) that this information
> should be integral to the schematic representation itself. Some other EDA
> packages achieve this quite well.
>
> I presented a way to achieve this without breaking backwards compatibility
> with the file format.
>
> If the "new" file format is still far in the future, can this feature be
> considered again?
>
> 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

[Kicad-developers] Do Not Fit

[Oliver Walters]

Hi all,

Almost a year ago now I suggested a feature addition, allowing for marking
parts in the schematic as "DO NOT FIT"

https://lists.launchpad.net/kicad-developers/msg38415.html

I had made a lot of progress towards feature completion, however was told
at the time that such a feature would not be accepted.

A year later, and after a lot of frustration of  sending the wrong files
out for manufacturer due to confusion about which parts are fitted, I'd
like to raise the issue again.

Currently parts are marked as "DNF" by setting a special field in the BOM
and checking for this with a special export script.

However, I feel (and I'm sure many would agree) that this information
should be integral to the schematic representation itself. Some other EDA
packages achieve this quite well.

I presented a way to achieve this without breaking backwards compatibility
with the file format.

If the "new" file format is still far in the future, can this feature be
considered again?

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

Re: [Kicad-developers] [PATCH] Option to not render 3D models for footprints

[Oliver Walters]

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 compatible.
> If the 3D model is disabled, then the keyword "(disabled)" is added to the
> file.
>
> You can now quickly toggle 3D models on/off on an individual basis and
> this is statefully saved between sessions.
>
> Patch-set is rebased and compiled
> from b445b0fab28f7dd41273801d06d7705215c57c0f
>
> Regards,
>
>
___
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] RFC: Moving footprint wizards to github

[Oliver Walters]

The libraries are licensed under CC-BY-SA 4.0

Is this the proper license for footprint wizards as they are code / scripts
and not just "data"?

Also, some of the existing scripts contain license information which
indicate various forms of licensing (MIT / GPL2+ )

Intuitively I think that this is effectively KiCad "source" and should be
licensed under the same arrangement. Here's a clipping from one of the
example wizards:

#
> # This program source code file is part of KiCad, a free EDA CAD
> application.
> #
> # Copyright (C) 2012-2014 KiCad Developers, see change_log.txt for
> contributors.
> #
> # This program is free software; you can redistribute it and/or
> # modify it under the terms of the GNU General Public License
> # as published by the Free Software Foundation; either version 2
> # of the License, or (at your option) any later version.
> #
> # This program is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> # GNU General Public License for more details.
> #
> # You should have received a copy of the GNU General Public License
> # along with this program; if not, you may find one here:
> # http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
> # or you may search the http://www.gnu.org website for the version 2
> license,
> # or you may write to the Free Software Foundation, Inc.,
> # 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA
> #


I am looking to as a matter of priority set up a LICENSE file and a CLA for
the repo, so looking for input here...

Thanks


On Sat, Dec 15, 2018 at 12:43 PM Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> The footprint wizards are currently mixed in with the source and could be
> better served if they are community contributed in an easier fashion.
>
> A while ago I made a repo for this purpose -
> https://github.com/KiCad/Footprint_Wizards
>
> Are there any objections to looking into moving the python script files to
> this repo? They would need to be pulled in at build time. But it would
> allow better community contribution and continuing improvements.
>
> At a minimum, the scripts do not conform to the current KLC requirements.
>
> 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

Re: [Kicad-developers] RFC: Moving footprint wizards to github

[Oliver Walters]

Seth,

I like this idea.  Coupled with a build/install CMake script in the repo
> would make iterating on the Python script development faster/easier.


A cmake script sounds like a good idea, would you be willing to add this to
the repo?

On Sat, Dec 15, 2018 at 3:15 PM Seth Hillbrand  wrote:

> Hi Oliver-
>
> Am 2018-12-14 20:43, schrieb Oliver Walters:
> > Are there any objections to looking into moving the python script
> > files to this repo? They would need to be pulled in at build time. But
> > it would allow better community contribution and continuing
> > improvements.
>
> I like this idea.  Coupled with a build/install CMake script in the repo
> would make iterating on the Python script development faster/easier.
>
> > At a minimum, the scripts do not conform to the current KLC
> > requirements.
>
> This will be good to update.  I had a swing at the line widths and a few
> bad courtyards but I'm sure I missed some things.
>
> -Seth
>
___
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] RFC: Moving footprint wizards to github

[Oliver Walters]

The footprint wizards are currently mixed in with the source and could be
better served if they are community contributed in an easier fashion.

A while ago I made a repo for this purpose -
https://github.com/KiCad/Footprint_Wizards

Are there any objections to looking into moving the python script files to
this repo? They would need to be pulled in at build time. But it would
allow better community contribution and continuing improvements.

At a minimum, the scripts do not conform to the current KLC requirements.

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

Re: [Kicad-developers] [RFQ] - Do Not Fit

[Oliver Walters]

Hi Oliver,
>
>
> I think we need to fit this in with the existing PCBNew Attributes stuff
> (“attr” in the file format).  We currently have through-hole, SMD and
> virtual (the later being similar to DNF/DNP), but a lot of folks have found
> that too limiting for various reasons.  I suspect this means we need
> user-defined attributes, but I’m not sure how many “system-defined” ones
> we’d also want to support.
>

I did consider this, but I don't think that we can overload the SMD / THT /
virtual attribute with a DNP attribute. Setting a component as DNP doesn't
mean that (for e.g.) it is *not* a SMD component. It just means that it
should not be loaded. DNP is an *extra* attribute it does not replace the
loading type of the component.

Perhaps something like "(attr smd dnp)" could work?

Allowing advance specification of the attributes in Eeschema would be a
> nice enhancement.  But due to file format changes (on at least the PCBNew
> side) it would have to wait for 6.0.
>
> Cheers,
> Jeff.
>
>
> On 25 Nov 2018, at 04:38, Oliver Walters 
> wrote:
>
> A feature I feel has been missing from KiCad is the ability to mark parts
> as "DNF" (Do Not Fit) so they are excluded from assembly files (BoM / PnP /
> etc).
>
> Many of the existing BoM tools (including mine) offer "hacks" to get
> around this shortfall by having a special field assigned to each component,
> for example.
>
> I have a branch working towards such functionality and am looking for some
> feedback.
>
> I consider this preliminary work towards full support of assembly
> variants. However this will need to wait until the new file format to be
> properly implemented. So for now, only DNF status is presented.
>
> Here are the features I have implemented so far:
>
> *A. Schematic components can be marked as "DNF" *
>
> A new checkbox in the component editor allows part fit to be deselected.
> By default all components are selected. (UI placement not final, just for
> demonstration).
>
> 
>
> Note that when rendered in the schematic, DNF parts are denoted by
> appended text after the RefDes field.
>
> Altium denotes DNF parts with a large red cross - I think that greying out
> DNF parts would look quite nice.
>
> *B. DNF part status is saved in the .sch schematic file*
>
> If a part is DNF , then the component line in the .sch file is appended:
>
> 
>
> Parts which *are* fitted do not get updated - to reduce file changes.
>
> As far as I can tell, this file change is fully backwards and forwards
> compatible. Old versions can open the file and simply ignore the DNF
> parameter. So perhaps this can be pushed into production before 6.x branch
> as it won't break any schematics.
>
> *C. Fitment status saved in exported netlist file*
>
> The fitment status of each component is saved to the exported netlist file.
>
> 
>
> So all this at least allows fit / DNF status to appear to the BOM tools.
>
> What's left?
>
> *1. PCBNEW*
>
> DNF status should be pushed to PCBEW, because:
>
>
>- Don't show 3D models for parts which are marked as DNF
>- Don't export DNF parts to the PnP files
>- (Eventually) ability to switch between assembly variants in PCBNEW
>
> However, this would require a file format change to the .kicad_pcb file,
> and this does not have the same opportunity for version compatibility that
> the simpler .sch files do.
>
> I can make this happen, but I'm guessing it has to wait for the 6.x branch.
>
> A simple example of how this could be included in the file:
>
> 
>
> *2. Multi-Unit Parts*
>
> If you mark one unit of a multi-unit part as DNF then *all* other units
> should be marked as DNF too.
>
> Question: How (from SCH_EDIT_FRAME context) do I find all the components
> that are the same master component as a given sub-part?
>
> *3. Better Display of DNF parts*
>
> I'd like to add a "greyed out" display for DNF parts in the schematic
> viewer.
>
> *4. Nomenclature*
>
> In the files I have used "DNF" or "fitted" - what should the accepted
> nomenclature be here? I've seen DNF / DNP / NC and other examples used. I'd
> like to get some clarity on what I should use going forward.
>
> As I said above, I'd like to move this on to support a full assembly
> variant management system but I feel it's best to wait until new file
> formats. Until then, some feedback on the items above would be great.
>
> Thanks,
>
> 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] [RFQ] - Do Not Fit

[Oliver Walters]

Frank,

That's a good idea,I hadn't thought of that. I'll add it to my working
document.

Cheers,

On Sun, 25 Nov 2018, 20:00  Hi Oliver
>
> This looks very nice! A plot option to disable DNF components in paste
> layer would be nice
>
>
> 25. nov. 2018 05.38 skrev Oliver Walters :
>
> A feature I feel has been missing from KiCad is the ability to mark parts
> as "DNF" (Do Not Fit) so they are excluded from assembly files (BoM / PnP /
> etc).
>
> Many of the existing BoM tools (including mine) offer "hacks" to get
> around this shortfall by having a special field assigned to each component,
> for example.
>
> I have a branch working towards such functionality and am looking for some
> feedback.
>
> I consider this preliminary work towards full support of assembly
> variants. However this will need to wait until the new file format to be
> properly implemented. So for now, only DNF status is presented.
>
> Here are the features I have implemented so far:
>
> *A. Schematic components can be marked as "DNF" *
>
> A new checkbox in the component editor allows part fit to be deselected.
> By default all components are selected. (UI placement not final, just for
> demonstration).
>
> [image: image.png]
>
> Note that when rendered in the schematic, DNF parts are denoted by
> appended text after the RefDes field.
>
> Altium denotes DNF parts with a large red cross - I think that greying out
> DNF parts would look quite nice.
>
> *B. DNF part status is saved in the .sch schematic file*
>
> If a part is DNF , then the component line in the .sch file is appended:
>
> [image: image.png]
>
> Parts which *are* fitted do not get updated - to reduce file changes.
>
> As far as I can tell, this file change is fully backwards and forwards
> compatible. Old versions can open the file and simply ignore the DNF
> parameter. So perhaps this can be pushed into production before 6.x branch
> as it won't break any schematics.
>
> *C. Fitment status saved in exported netlist file*
>
> The fitment status of each component is saved to the exported netlist file.
>
> [image: image.png]
>
> So all this at least allows fit / DNF status to appear to the BOM tools.
>
> What's left?
>
> *1. PCBNEW*
>
> DNF status should be pushed to PCBEW, because:
>
>
>- Don't show 3D models for parts which are marked as DNF
>- Don't export DNF parts to the PnP files
>- (Eventually) ability to switch between assembly variants in PCBNEW
>
> However, this would require a file format change to the .kicad_pcb file,
> and this does not have the same opportunity for version compatibility that
> the simpler .sch files do.
>
> I can make this happen, but I'm guessing it has to wait for the 6.x branch.
>
> A simple example of how this could be included in the file:
>
> [image: image.png]
>
> *2. Multi-Unit Parts*
>
> If you mark one unit of a multi-unit part as DNF then *all* other units
> should be marked as DNF too.
>
> Question: How (from SCH_EDIT_FRAME context) do I find all the components
> that are the same master component as a given sub-part?
>
> *3. Better Display of DNF parts*
>
> I'd like to add a "greyed out" display for DNF parts in the schematic
> viewer.
>
> *4. Nomenclature*
>
> In the files I have used "DNF" or "fitted" - what should the accepted
> nomenclature be here? I've seen DNF / DNP / NC and other examples used. I'd
> like to get some clarity on what I should use going forward.
>
> As I said above, I'd like to move this on to support a full assembly
> variant management system but I feel it's best to wait until new file
> formats. Until then, some feedback on the items above would be great.
>
> Thanks,
>
> 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

Re: [Kicad-developers] [PATCH] Option to not render 3D models for footprints

[Oliver Walters]

Bump :)

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 compatible.
> If the 3D model is disabled, then the keyword "(disabled)" is added to the
> file.
>
> You can now quickly toggle 3D models on/off on an individual basis and
> this is statefully saved between sessions.
>
> Patch-set is rebased and compiled
> from b445b0fab28f7dd41273801d06d7705215c57c0f
>
> Regards,
>
>
___
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] - Add x/y measurements to PCB ruler tool

[Oliver Walters]

Most of the time I wish to use the ruler tool to display x/y measurements.

This simple patch displays dx and dy on the ruler tool.
From 8a4f58580530b06d2161218e3e2b33a343e4ff97 Mon Sep 17 00:00:00 2001
From: Oliver 
Date: Sat, 25 Aug 2018 21:59:21 +1000
Subject: [PATCH] Add x/y dimensions to PCB ruler

- Display dx and dy in addition to euclidian distance and angle
---
 common/preview_items/ruler_item.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/common/preview_items/ruler_item.cpp b/common/preview_items/ruler_item.cpp
index 2442a17..21c24da 100644
--- a/common/preview_items/ruler_item.cpp
+++ b/common/preview_items/ruler_item.cpp
@@ -45,6 +45,9 @@ static void drawCursorStrings( KIGFX::VIEW* aView, const VECTOR2D& aCursor,
 // draw the cursor labels
 std::vector cursorStrings;
 
+cursorStrings.push_back( DimensionLabel( "x", aRulerVec.x, aUnits ) );
+cursorStrings.push_back( DimensionLabel( "y", aRulerVec.y, aUnits ) );
+
 cursorStrings.push_back( DimensionLabel( "r", aRulerVec.EuclideanNorm(), aUnits ) );
 
 double degs = RAD2DECIDEG( -aRulerVec.Angle() );
-- 
2.7.4

___
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] Libedit and Modedit Icons

[Oliver Walters]

I think you are all correct. During my revamp of the icons I tried to
achieve two things:

1. Differentiate between import and export based on arrow direction
(generally import arrows are right to left, and export are left to right)
2. Place import icons on the left, and export on the right (following the
"flow" outlined in 1)

However this means that both arrows are effectively flowing "out of" the
document.

I think that if the import icons are moved to the right hand side, then
they will then look like they are flowing "into" the document.

Thoughts?

On Tue, Jan 16, 2018 at 9:10 PM, Jeff Young  wrote:

> FWIW, I also agree that the current import arrow is backwards.
>
> > On 16 Jan 2018, at 07:11, Marco Ciampa  wrote:
> >
> > Hi Oliver, your thoughts?
> >
> > On Mon, Jan 15, 2018 at 09:09:48AM +0100, jp charras wrote:
> >> Le 15/01/2018 à 08:51, Marco Ciampa a écrit :
> >>> Hi Oliver,
> >>> about the bikeshedding thing I am not even a developer and I have the
> >>> audacity to say my thoughts about the icons!!!
> >>>
> >>> Follows my 0.002 euro cents
> >>>
> >>> My very humble opinion is that the import icon is not that clear and
> can
> >>> be improved alot in this way: just change the direction and position of
> >>> the arrow, the colour could stay as it is, it doesn't matter.
> >>>
> >>> I mean that the export icon is (almost) ok since it represent what I
> >>> expect in an "export" icon: the "out" direction is clear: just describe
> >>> an arrow that points _out_ of a document.
> >>>
> >>> Similarly the import icon should represent the "in" direction: and
> arrow
> >>> that point _into_ a document, not another arrow pointing out of the
> same
> >>> document but with a different color...
> >>
> >> I fully agree...
> >>
> >>>
> >>> I mean (ascii art: see it with a monospaced font):
> >>>
> >>> Export:
> >>>
> >>> ||
> >>> || |\
> >>> |  |---| \
> >>> |  |  \
> >>> |  |  /
> >>> |  |---| /
> >>> || |/
> >>> ||
> >>>
> >>> Import:
> >>>
> >>>  ||
> >>>  | |\ |
> >>> |---| \|
> >>> |  \   |
> >>> |  /   |
> >>> |---| /|
> >>>  | |/ |
> >>>  ||
> >>>
> >>>
> >>> I think this is much clearer...
> >>>
> >>> --
> >>>
> >>>
> >>> Marco Ciampa
> >>
> >>
> >> --
> >> 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
> >
> > --
> >
> >
> > Marco Ciampa
> >
> > I know a joke about UDP, but you might not get it.
> >
> > 
> >
> > GNU/Linux User #78271
> > FSFE fellow #364
> >
> > 
> >
> >
> > ___
> > 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] Library admin transition

[Oliver Walters]

Hi everyone,

After acting as library admin for 2017, I will shortly be handing the reins
over to Rene Pöschl. He has already been a major contributor to the
libraries and will continue to be a valuable asset to the KiCad project.

I think that we have achieved a great deal in the last year!

Due to personal circumstances I will not be able to actively contribute to
KiCad this year. I wish you all the best!

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

Re: [Kicad-developers] Libedit and Modedit Icons

[Oliver Walters]

Andrey,

Here's all I can provide currently (at work!)

[image: Inline image 1]

I have sent the entire patch to Wayne and JP privately so the merging is
now in their capable hands :)

On Fri, Jan 12, 2018 at 2:20 PM, Andrey Kuznetsov <kandre...@gmail.com>
wrote:

> Also the attached image of the final icon set was discarded, can you
> please resend the final icon image set?
>
> Thank you
>
> On Thu, Jan 11, 2018 at 8:35 AM, jp charras <jp.char...@wanadoo.fr> wrote:
>
>> Le 11/01/2018 à 08:54, Oliver Walters a écrit :
>> > Wayne,
>> >
>> > I have taken further suggestions and final icon set is shown below:
>> >
>> > [image: Inline image 1]
>> >
>> > The attached patch incorporates all of the icon changes thus far
>> > implemented.
>> >
>> > Thanks,
>> > Oliver
>> >
>>
>> Oliver,
>>
>> For some unknown reason, your mail was blocked by Launchpad.
>> And the attached patch was discarded.
>>
>>
>> --
>> 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
>>
>
>
>
> --
> 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

Re: [Kicad-developers] Libedit and Modedit Icons

[Oliver Walters]

Wayne,

I have taken further suggestions and final icon set is shown below:

[image: Inline image 1]

The attached patch incorporates all of the icon changes thus far
implemented.

Thanks,
Oliver

On Thu, Jan 11, 2018 at 1:58 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> I see scope creep happening here.  I thought the original goal was to
> make some minor tweaks to our existing icons not wholesale replacement
> of the them.  I don't like the camera either.  I'm not a big fan of the
> calculator icon.  Both of these icons looks completely out of place with
> our other icons.  Please keep the scope of these changes in check.  If
> we want to discuss an entirely new icon theme for v6, that's fine at the
> appropriate time but not for v5.
>
> On 1/10/2018 9:42 AM, Jeff Young wrote:
> > Splendid!
> >
> > Although I agree with Kristoffer that the new bitmap2component icon
> > isn’t much help.  Import/Export is the one area where we’ve kept the
> > arrows (which I think is fine).  Given that, the pixelated “a” with an
> > import arrow would be perfect.
> >
> > FWIW, this is one area where I disagree with Nick.  I did user interface
> > design and software architecture for Adobe for 25 years and in my
> > professional opinion, these icons are a HUGE improvement.
> >
> > Cheers,
> > Jeff
> >
> >
> >> On 10 Jan 2018, at 14:28, Oliver Walters
> >> <oliver.henry.walt...@gmail.com
> >> <mailto:oliver.henry.walt...@gmail.com>> wrote:
> >>
> >> Also, would it be too much to ask for getting the arrows, the
> >> diskette and the folder in the repo with the patch, basically if
> >> someone wants to create future icons. They could use the same
> >> arrows for any kind of export, import, save, inspect or view.
> >>
> >>
> >> I have created a set of "common icons" for exactly this purpose :)
> >>
> >>
> >> On Thu, Jan 11, 2018 at 1:27 AM, Kristoffer Ödmark
> >> <kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>>
> >> wrote:
> >>
> >> Wow, really nice! Although, the icon for the bitmap2component
> >> basically looks like a screenshot symbol to me, or something
> >> related to a webcam.
> >>
> >> The old one isnt as polished, but I think it fits better.
> >>
> >> Also, would it be too much to ask for getting the arrows, the
> >> diskette and the folder in the repo with the patch, basically if
> >> someone wants to create future icons. They could use the same
> >> arrows for any kind of export, import, save, inspect or view.
> >>
> >> Basically to help get a icon theme thing going ;)
> >>
> >>
> >>
> >>  -Kristoffer
> >>
> >>
> >> On 01/10/2018 03:13 PM, Oliver Walters wrote:
> >>
> >> Wayne,
> >>
> >> Here is the outcome of removing the save / load arrows and
> >> replacing with
> >> standard load / save icons.
> >>
> >> I have also further tweaked the main icons as per suggestions.
> >>
> >> Screenshots here:
> >>
> >> https://imgur.com/a/DzZhZ
> >>
> >> This is about as far as I want to go with this, please let me
> >> know if there
> >> are any outstanding issues that prevent me from submitting a
> >> patch.
> >>
> >> Thanks,
> >> Oliver
> >>
> >> On Wed, Jan 10, 2018 at 8:09 AM, Oliver Walters <
> >> oliver.henry.walt...@gmail.com
> >> <mailto:oliver.henry.walt...@gmail.com>> wrote:
> >>
> >> Ok, that's good to hear. I will take another look at the
> >> Gerber icons and
> >> otherwise see if anyone can suggest some simple clean
> >> replacements for the
> >> arrows. If not, I'll push a patch.
> >>
> >> On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh
> >> <stambau...@gmail.com <mailto:stambau...@gmail.com>>
> >> wrote:
> >>
> >> One good thing about bitmaps is they are low risk
> >> (other than the
> >> complaining that will surely ensue) so we can merge
> >> them just about any
> >

Re: [Kicad-developers] Libedit and Modedit Icons

[Oliver Walters]

>
> Also, would it be too much to ask for getting the arrows, the diskette and
> the folder in the repo with the patch, basically if someone wants to create
> future icons. They could use the same arrows for any kind of export,
> import, save, inspect or view.


I have created a set of "common icons" for exactly this purpose :)


On Thu, Jan 11, 2018 at 1:27 AM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> Wow, really nice! Although, the icon for the bitmap2component basically
> looks like a screenshot symbol to me, or something related to a webcam.
>
> The old one isnt as polished, but I think it fits better.
>
> Also, would it be too much to ask for getting the arrows, the diskette and
> the folder in the repo with the patch, basically if someone wants to create
> future icons. They could use the same arrows for any kind of export,
> import, save, inspect or view.
>
> Basically to help get a icon theme thing going ;)
>
>
>
>  -Kristoffer
>
>
> On 01/10/2018 03:13 PM, Oliver Walters wrote:
>
>> Wayne,
>>
>> Here is the outcome of removing the save / load arrows and replacing with
>> standard load / save icons.
>>
>> I have also further tweaked the main icons as per suggestions.
>>
>> Screenshots here:
>>
>> https://imgur.com/a/DzZhZ
>>
>> This is about as far as I want to go with this, please let me know if
>> there
>> are any outstanding issues that prevent me from submitting a patch.
>>
>> Thanks,
>> Oliver
>>
>> On Wed, Jan 10, 2018 at 8:09 AM, Oliver Walters <
>> oliver.henry.walt...@gmail.com> wrote:
>>
>> Ok, that's good to hear. I will take another look at the Gerber icons and
>>> otherwise see if anyone can suggest some simple clean replacements for
>>> the
>>> arrows. If not, I'll push a patch.
>>>
>>> On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh <stambau...@gmail.com>
>>> wrote:
>>>
>>> One good thing about bitmaps is they are low risk (other than the
>>>> complaining that will surely ensue) so we can merge them just about any
>>>> time.  I don't want to wait too long so our doc images can be updated to
>>>> reflect the changes so if we cannot come up with better alternatives to
>>>> replace the arrows, I'm OK with leaving them as is and pushing it off
>>>> until v6.
>>>>
>>>> Cheers,
>>>>
>>>> Wayne
>>>>
>>>> On 1/9/2018 3:31 PM, Jeff Young wrote:
>>>>
>>>>> I think the changes are absolutely good in general, and I’d very much
>>>>> like to see them get merged.  Not that I have any control over that. ;)
>>>>>
>>>>> As for the arrows, I’d still really like to see them go away.  The
>>>>> colour isn’t the problem, it’s the arrows themselves. ANY of the
>>>>> alternatives discussed (that don’t include arrows) would be better.
>>>>>
>>>>> Cheers,
>>>>> Jeff.
>>>>>
>>>>>
>>>>> On 9 Jan 2018, at 20:13, Oliver Walters
>>>>>> <oliver.henry.walt...@gmail.com
>>>>>> <mailto:oliver.henry.walt...@gmail.com>> wrote:
>>>>>>
>>>>>> The coloured arrows were already in place, all I have done is made
>>>>>> them all the same "style". In fact, previously concepts like "save"
>>>>>> and "load" were conveyed both with a downward pointing arrow, and the
>>>>>> arrow colour was the only point of difference.
>>>>>>
>>>>>> I thought I had made an improvement on what was already existing. My
>>>>>> intent was not to necessarily do a sweeping redesign.
>>>>>>
>>>>>> If this is now an additional requirement I can make these not arrows,
>>>>>> but I'd like some direction on what to do instead. It will be hard to
>>>>>> fit a more detailed icon.
>>>>>>
>>>>>> Other than this, what are your thoughts overall? Is it worth my time
>>>>>> pursuing this further? Are these changes good in general and can you
>>>>>> see them being merged?
>>>>>>
>>>>>> On 10 Jan 2018 04:44, "Wayne Stambaugh" <stambau...@gmail.com
>>>>>> <mailto:stambau...@gmail.com>> wrote:
>>>>>>
>>>>>>  On 1/9/2018 12:05 PM, Rene Pöschl wrote:
>>>

Re: [Kicad-developers] Libedit and Modedit Icons

[Oliver Walters]

Wayne,

Here is the outcome of removing the save / load arrows and replacing with
standard load / save icons.

I have also further tweaked the main icons as per suggestions.

Screenshots here:

https://imgur.com/a/DzZhZ

This is about as far as I want to go with this, please let me know if there
are any outstanding issues that prevent me from submitting a patch.

Thanks,
Oliver

On Wed, Jan 10, 2018 at 8:09 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Ok, that's good to hear. I will take another look at the Gerber icons and
> otherwise see if anyone can suggest some simple clean replacements for the
> arrows. If not, I'll push a patch.
>
> On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh <stambau...@gmail.com>
> wrote:
>
>> One good thing about bitmaps is they are low risk (other than the
>> complaining that will surely ensue) so we can merge them just about any
>> time.  I don't want to wait too long so our doc images can be updated to
>> reflect the changes so if we cannot come up with better alternatives to
>> replace the arrows, I'm OK with leaving them as is and pushing it off
>> until v6.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 1/9/2018 3:31 PM, Jeff Young wrote:
>> > I think the changes are absolutely good in general, and I’d very much
>> > like to see them get merged.  Not that I have any control over that. ;)
>> >
>> > As for the arrows, I’d still really like to see them go away.  The
>> > colour isn’t the problem, it’s the arrows themselves. ANY of the
>> > alternatives discussed (that don’t include arrows) would be better.
>> >
>> > Cheers,
>> > Jeff.
>> >
>> >
>> >> On 9 Jan 2018, at 20:13, Oliver Walters
>> >> <oliver.henry.walt...@gmail.com
>> >> <mailto:oliver.henry.walt...@gmail.com>> wrote:
>> >>
>> >> The coloured arrows were already in place, all I have done is made
>> >> them all the same "style". In fact, previously concepts like "save"
>> >> and "load" were conveyed both with a downward pointing arrow, and the
>> >> arrow colour was the only point of difference.
>> >>
>> >> I thought I had made an improvement on what was already existing. My
>> >> intent was not to necessarily do a sweeping redesign.
>> >>
>> >> If this is now an additional requirement I can make these not arrows,
>> >> but I'd like some direction on what to do instead. It will be hard to
>> >> fit a more detailed icon.
>> >>
>> >> Other than this, what are your thoughts overall? Is it worth my time
>> >> pursuing this further? Are these changes good in general and can you
>> >> see them being merged?
>> >>
>> >> On 10 Jan 2018 04:44, "Wayne Stambaugh" <stambau...@gmail.com
>> >> <mailto:stambau...@gmail.com>> wrote:
>> >>
>> >> On 1/9/2018 12:05 PM, Rene Pöschl wrote:
>> >> > On 09/01/18 16:50, Wayne Stambaugh wrote:
>> >> >> I'm with Jose on the arrows.  If we are going to use them,
>> >> please don't
>> >> >> make the all different colors.  I don't see how a blue left
>> >> arrow versus
>> >> >> a magenta right arrow conveys any meaning to the user.
>> >> >>
>> >> >
>> >> > I like the idea of coloring them differently. For me this will
>> >> give an
>> >> > additional way to distinguish the buttons. (Some of them have
>> >> only the
>> >> > direction of the arrow as a difference. Which is easily
>> >> overlooked.) I
>> >> > hope having different colors will make it easier for my brain to
>> >> > remember which button does what. (I can't tell you how often i
>> >> clicked
>> >> > load symbol instead of update symbol while working on the
>> >> reorganization
>> >> > of the official lib.)
>> >>
>> >> What information does the different color arrow convey?  If you are
>> >> using different colors for contrast, that is one thing but just
>> making
>> >> them different colors for informational purposes doesn't make any
>> >> sense
>> >> to me.  If you are trying convey information with different color
>> >> buttons, what is the impact on users who are color blind.
>> &g

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

[Oliver Walters]

Jorg, this has already been fixed and merged :)

On Thu, Jan 11, 2018 at 1:05 AM, Jörg Hermann  wrote:

> The summary of this thread to me is:
>
> 1) Everybody is in favour of uniform, consistent measurement units, mm
> that is.
> 2) Everybody sees a long term benefit.
> 3) Everybody agrees V5 is disruptive due to library changes.
> 4) There seems to be consensus that only few users will be bitten by the
> 3D offset change.
>
> Wayne disapproves the introduction of a version number. While I see the
> benefit - data format is always crystal clear, it makes parsers more
> complex all the time. From a maintenance pov I agree with Wayne, not
> introducing a version number.
>
> One solution introduces a semantic change, where the presence or absence
> of keywords conveys information. While we remember the absence today,
> upcoming maintainers will curse at us for this decision in only a few month
> time.
>
> So my plea is: Because of 1 - 4 this is now the best time to introduce the
> 3D offset change!
> Else this will bite all up to V6!
> Please go forward!
>
> Jörg
>
>
> ___
> 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] Libedit and Modedit Icons

[Oliver Walters]

>
> +1 to the Google icon overlays.
>

I'll have a look into that

On Wed, Jan 10, 2018 at 8:40 AM, Jeff Young <j...@rokeby.ie> wrote:

> +1 to the Google icon overlays.
>
> On 9 Jan 2018, at 21:15, Jon Evans <j...@craftyjon.com> wrote:
>
> Inspiration from Google's material design icons? (permissively-licensed) .
> These could be overlaid in the bottom right quarter maybe?
> 
> 
> 
>
> On Tue, Jan 9, 2018 at 4:09 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Ok, that's good to hear. I will take another look at the Gerber icons and
>> otherwise see if anyone can suggest some simple clean replacements for the
>> arrows. If not, I'll push a patch.
>>
>> On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh <stambau...@gmail.com>
>> wrote:
>>
>>> One good thing about bitmaps is they are low risk (other than the
>>> complaining that will surely ensue) so we can merge them just about any
>>> time.  I don't want to wait too long so our doc images can be updated to
>>> reflect the changes so if we cannot come up with better alternatives to
>>> replace the arrows, I'm OK with leaving them as is and pushing it off
>>> until v6.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 1/9/2018 3:31 PM, Jeff Young wrote:
>>> > I think the changes are absolutely good in general, and I’d very much
>>> > like to see them get merged.  Not that I have any control over that. ;)
>>> >
>>> > As for the arrows, I’d still really like to see them go away.  The
>>> > colour isn’t the problem, it’s the arrows themselves. ANY of the
>>> > alternatives discussed (that don’t include arrows) would be better.
>>> >
>>> > Cheers,
>>> > Jeff.
>>> >
>>> >
>>> >> On 9 Jan 2018, at 20:13, Oliver Walters
>>> >> <oliver.henry.walt...@gmail.com
>>> >> <mailto:oliver.henry.walt...@gmail.com>> wrote:
>>> >>
>>> >> The coloured arrows were already in place, all I have done is made
>>> >> them all the same "style". In fact, previously concepts like "save"
>>> >> and "load" were conveyed both with a downward pointing arrow, and the
>>> >> arrow colour was the only point of difference.
>>> >>
>>> >> I thought I had made an improvement on what was already existing. My
>>> >> intent was not to necessarily do a sweeping redesign.
>>> >>
>>> >> If this is now an additional requirement I can make these not arrows,
>>> >> but I'd like some direction on what to do instead. It will be hard to
>>> >> fit a more detailed icon.
>>> >>
>>> >> Other than this, what are your thoughts overall? Is it worth my time
>>> >> pursuing this further? Are these changes good in general and can you
>>> >> see them being merged?
>>> >>
>>> >> On 10 Jan 2018 04:44, "Wayne Stambaugh" <stambau...@gmail.com
>>> >> <mailto:stambau...@gmail.com>> wrote:
>>> >>
>>> >> On 1/9/2018 12:05 PM, Rene Pöschl wrote:
>>> >> > On 09/01/18 16:50, Wayne Stambaugh wrote:
>>> >> >> I'm with Jose on the arrows.  If we are going to use them,
>>> >> please don't
>>> >> >> make the all different colors.  I don't see how a blue left
>>> >> arrow versus
>>> >> >> a magenta right arrow conveys any meaning to the user.
>>> >> >>
>>> >> >
>>> >> > I like the idea of coloring them differently. For me this will
>>> >> give an
>>> >> > additional way to distinguish the buttons. (Some of them have
>>> >> only the
>>> >> > direction of the arrow as a difference. Which is easily
>>> >> overlooked.) I
>>> >> > hope having different colors will make it easier for my brain to
>>> >> > remember which button does what. (I can't tell you how often i
>>> >> clicked
>>> >> > load symbol instead of update symbol while working on the
>>> >> reorganization
>>> >> > of the official lib.)
>>> >>
>>> >> What information does th

Re: [Kicad-developers] Libedit and Modedit Icons

[Oliver Walters]

Ok, that's good to hear. I will take another look at the Gerber icons and
otherwise see if anyone can suggest some simple clean replacements for the
arrows. If not, I'll push a patch.

On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> One good thing about bitmaps is they are low risk (other than the
> complaining that will surely ensue) so we can merge them just about any
> time.  I don't want to wait too long so our doc images can be updated to
> reflect the changes so if we cannot come up with better alternatives to
> replace the arrows, I'm OK with leaving them as is and pushing it off
> until v6.
>
> Cheers,
>
> Wayne
>
> On 1/9/2018 3:31 PM, Jeff Young wrote:
> > I think the changes are absolutely good in general, and I’d very much
> > like to see them get merged.  Not that I have any control over that. ;)
> >
> > As for the arrows, I’d still really like to see them go away.  The
> > colour isn’t the problem, it’s the arrows themselves. ANY of the
> > alternatives discussed (that don’t include arrows) would be better.
> >
> > Cheers,
> > Jeff.
> >
> >
> >> On 9 Jan 2018, at 20:13, Oliver Walters
> >> <oliver.henry.walt...@gmail.com
> >> <mailto:oliver.henry.walt...@gmail.com>> wrote:
> >>
> >> The coloured arrows were already in place, all I have done is made
> >> them all the same "style". In fact, previously concepts like "save"
> >> and "load" were conveyed both with a downward pointing arrow, and the
> >> arrow colour was the only point of difference.
> >>
> >> I thought I had made an improvement on what was already existing. My
> >> intent was not to necessarily do a sweeping redesign.
> >>
> >> If this is now an additional requirement I can make these not arrows,
> >> but I'd like some direction on what to do instead. It will be hard to
> >> fit a more detailed icon.
> >>
> >> Other than this, what are your thoughts overall? Is it worth my time
> >> pursuing this further? Are these changes good in general and can you
> >> see them being merged?
> >>
> >> On 10 Jan 2018 04:44, "Wayne Stambaugh" <stambau...@gmail.com
> >> <mailto:stambau...@gmail.com>> wrote:
> >>
> >> On 1/9/2018 12:05 PM, Rene Pöschl wrote:
> >> > On 09/01/18 16:50, Wayne Stambaugh wrote:
> >> >> I'm with Jose on the arrows.  If we are going to use them,
> >> please don't
> >> >> make the all different colors.  I don't see how a blue left
> >> arrow versus
> >> >> a magenta right arrow conveys any meaning to the user.
> >> >>
> >> >
> >> > I like the idea of coloring them differently. For me this will
> >> give an
> >> > additional way to distinguish the buttons. (Some of them have
> >> only the
> >> > direction of the arrow as a difference. Which is easily
> >> overlooked.) I
> >> > hope having different colors will make it easier for my brain to
> >> > remember which button does what. (I can't tell you how often i
> >> clicked
> >> > load symbol instead of update symbol while working on the
> >> reorganization
> >> > of the official lib.)
> >>
> >> What information does the different color arrow convey?  If you are
> >> using different colors for contrast, that is one thing but just
> making
> >> them different colors for informational purposes doesn't make any
> >> sense
> >> to me.  If you are trying convey information with different color
> >> buttons, what is the impact on users who are color blind.
> >>
> >> >
> >> > Maybe there is a better way to communicate differences but if
> >> buttons
> >> > look as similar as a lot of them currently do, adding
> >> differentiating
> >> > colors might help.
> >> >
> >> > ___
> >> > 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>
&g

Re: [Kicad-developers] Libedit and Modedit Icons

[Oliver Walters]

The coloured arrows were already in place, all I have done is made them all
the same "style". In fact, previously concepts like "save" and "load" were
conveyed both with a downward pointing arrow, and the arrow colour was the
only point of difference.

I thought I had made an improvement on what was already existing. My intent
was not to necessarily do a sweeping redesign.

If this is now an additional requirement I can make these not arrows, but
I'd like some direction on what to do instead. It will be hard to fit a
more detailed icon.

Other than this, what are your thoughts overall? Is it worth my time
pursuing this further? Are these changes good in general and can you see
them being merged?

On 10 Jan 2018 04:44, "Wayne Stambaugh"  wrote:

> On 1/9/2018 12:05 PM, Rene Pöschl wrote:
> > On 09/01/18 16:50, Wayne Stambaugh wrote:
> >> I'm with Jose on the arrows.  If we are going to use them, please don't
> >> make the all different colors.  I don't see how a blue left arrow versus
> >> a magenta right arrow conveys any meaning to the user.
> >>
> >
> > I like the idea of coloring them differently. For me this will give an
> > additional way to distinguish the buttons. (Some of them have only the
> > direction of the arrow as a difference. Which is easily overlooked.) I
> > hope having different colors will make it easier for my brain to
> > remember which button does what. (I can't tell you how often i clicked
> > load symbol instead of update symbol while working on the reorganization
> > of the official lib.)
>
> What information does the different color arrow convey?  If you are
> using different colors for contrast, that is one thing but just making
> them different colors for informational purposes doesn't make any sense
> to me.  If you are trying convey information with different color
> buttons, what is the impact on users who are color blind.
>
> >
> > Maybe there is a better way to communicate differences but if buttons
> > look as similar as a lot of them currently do, adding differentiating
> > colors might help.
> >
> > ___
> > 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] Libedit and Modedit Icons

[Oliver Walters]

Andrey, I agree that those icons also could be improved

However I will wait for sign-off from JP / Wayne before I spend any further
time on this. If they veto this then I would have wasted my time.

Cheers

On Sun, Jan 7, 2018 at 12:01 PM, Andrey Kuznetsov <kandre...@gmail.com>
wrote:

> FYI, the 5th and last icons from the left do not convey what they are
> about.
>
> Perhaps you could add the word "Gerber" at the top portion of the icon and
> remove that stupid magnifying glass.
>
> The worksheet layout shouldn't have a schematic in gray color in it, why
> is there a schematic in an empty worksheet layout editor? It's not a
> schematic editor...
> I'm not sure what the best icon would look like to represent a worksheet
> layout editor.
>
> On Sat, Jan 6, 2018 at 4:24 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> I have attached a patchset which performs the following:
>>
>> 1. Revert libedit icon to previous version
>> 2. Revert modedit icon to previous version
>> 3. Updates pcbnew icon to look more like a PCB
>> 4. Update colors of eeschema icon
>> 5. Various (almost imperceptible) tweaks to a number of icons to fix
>> graphic alignment issues
>>
>> Here is a screenshot of the updated icons:
>>
>>
>> [image: Inline image 2]
>>
>>
>> [image: Inline image 1]
>>
>> On Sun, Jan 7, 2018 at 8:34 AM, Oliver Walters <
>> oliver.henry.walt...@gmail.com> wrote:
>>
>>> On 7 Jan 2018 05:04, "Chris Pavlina" <pavlina.ch...@gmail.com> wrote:
>>>
>>> I wish we had something resembling a policy for icons. It seems like
>>> someone always wants to change them. We had decent icons for these
>>> _before_, and then someone submitted new ones, and they were accepted
>>> because... I don't know? Many of the new icons are really ambiguous and
>>> kind of useless. Shouldn't have been merged.
>>>
>>>
>>> This is why I'm pushing for *a* change and not *my* change, I remember
>>> how the argument went last time, before they were silently merged.
>>>
>>> I also note that there is a lack of consistency between similar icons.
>>> e.g. there are many icons which incorporate an arrow but the style/shape of
>>> the arrows varies.
>>>
>>> For the record, I like these proposed ones. They bring back the ability
>>> to recognize them at a glance.
>>>
>>> On Sat, Jan 06, 2018 at 05:52:49PM +, kristoffer Ödmark wrote:
>>> > I would love to see improved icons, I still never get used to them so
>>> i read
>>> > the tooltip, newer know which one is pcb and which one is module
>>> editor.
>>> >
>>> > Luckily most of the time I only need to double click the kicad_pcb file
>>> > anyway :)
>>> >
>>> >
>>> > On 2018-01-06 15:08, Nick Østergaard wrote:
>>> > > 2018-01-06 14:15 GMT+01:00 Jeff Young <j...@rokeby.ie
>>> > > <mailto:j...@rokeby.ie>>:
>>> > >
>>> > > +1
>>> > >
>>> > > And I like Oliver’s proposed icons.  I’d suggest two further
>>> > > changes though:
>>> > >
>>> > > 1) The schematic icon (which Oliver didn’t change) should really
>>> > > use the default colours (dark red symbols, green wires).  Then
>>> > > there’s a stronger tie-in with the libedit icon.
>>> > >
>>> > > 2) I think I’d drop the dimensions from the modedit icon, and
>>> > > change the pad colour to the default (yellow).
>>> > >
>>> > >
>>> > > The default pad color is not yellow, that is only what you see for
>>> THT
>>> > > pads. Default pad color is green for bottom and red for top copper
>>> > >
>>> > >
>>> > > 3) Projects should use the current New Project icon, rather than
>>> > > the application icon.
>>> > >
>>> > >
>>> > > I have considered to submit a patch for this for some time, but I
>>> guess
>>> > > it is an appropiate time to do this with a major version bump.
>>> > >
>>> > >
>>> > > 4) Both the New Project and New Project from Template icons
>>> should
>>> > > get yellow “new” star.
>>> > >
>>> > > 5) New Footprint in modedit also needs the star, and the star on
>>&g

[Kicad-developers] Possible bug - libedit

[Oliver Walters]

In libedit, if you alter the description of a symbol, it does not get
updated in the tree view. You have to close and re-open libedit to see the
new description previewed here.

Is this desired behavior or should I raise a bug report?
___
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] Libedit and Modedit Icons

[Oliver Walters]

On 7 Jan 2018 05:04, "Chris Pavlina" <pavlina.ch...@gmail.com> wrote:

I wish we had something resembling a policy for icons. It seems like
someone always wants to change them. We had decent icons for these
_before_, and then someone submitted new ones, and they were accepted
because... I don't know? Many of the new icons are really ambiguous and
kind of useless. Shouldn't have been merged.


This is why I'm pushing for *a* change and not *my* change, I remember how
the argument went last time, before they were silently merged.

I also note that there is a lack of consistency between similar icons. e.g.
there are many icons which incorporate an arrow but the style/shape of the
arrows varies.

For the record, I like these proposed ones. They bring back the ability
to recognize them at a glance.

On Sat, Jan 06, 2018 at 05:52:49PM +, kristoffer Ödmark wrote:
> I would love to see improved icons, I still never get used to them so i
read
> the tooltip, newer know which one is pcb and which one is module editor.
>
> Luckily most of the time I only need to double click the kicad_pcb file
> anyway :)
>
>
> On 2018-01-06 15:08, Nick Østergaard wrote:
> > 2018-01-06 14:15 GMT+01:00 Jeff Young <j...@rokeby.ie
> > <mailto:j...@rokeby.ie>>:
> >
> > +1
> >
> > And I like Oliver’s proposed icons.  I’d suggest two further
> > changes though:
> >
> > 1) The schematic icon (which Oliver didn’t change) should really
> > use the default colours (dark red symbols, green wires).  Then
> > there’s a stronger tie-in with the libedit icon.
> >
> > 2) I think I’d drop the dimensions from the modedit icon, and
> > change the pad colour to the default (yellow).
> >
> >
> > The default pad color is not yellow, that is only what you see for THT
> > pads. Default pad color is green for bottom and red for top copper
> >
> >
> > 3) Projects should use the current New Project icon, rather than
> > the application icon.
> >
> >
> > I have considered to submit a patch for this for some time, but I guess
> > it is an appropiate time to do this with a major version bump.
> >
> >
> > 4) Both the New Project and New Project from Template icons should
> > get yellow “new” star.
> >
> > 5) New Footprint in modedit also needs the star, and the star on
> > New Symbol in libedit made more prominent.
> >
> > Cheers,
> > Jeff.
> >
> >
> > > On 6 Jan 2018, at 12:30, Oliver Walters
> > > <oliver.henry.walt...@gmail.com
> > > <mailto:oliver.henry.walt...@gmail.com>> wrote:
> > >
> > > I think there is a need to tweak the libedit and modedit icons,
> > > as identified below:
> > >
> > > 
> > >
> > > 
> > >
> > > 1. The blue 'textured' background is out of place with the other
> > > icons
> > > 2. They are very cluttered and hard to read
> > > 3. Weirdly specific callout of dimensions and part names (out of
> > > character with other icons)
> > >
> > > Further, I think that the pcbnew icon could be adjusted slightly
> > > to make it look a bit more like a PCB
> > >
> > > Even as someone who uses KiCad on a regular basis I find myself
> > > double checking which icon I am about to click on (and still
> > > getting it wrong half of the time).
> > >
> > > Below is a /**suggestion**/ of some improvements. I am not trying
> > > to back my own horse here, I'd be happy for anyone else to
> > > suggest a better design for any of these. But I feel that
> > > changing these icons would be a good improvement to make before
> > > the v5 release. There have been many people complaining about
> > > these icons in particular, both here and on the user forums.
> > >
> > > 
> > >
> > > Is this a worthwhile endeavor, or are people attached to the
> > > weird blue icons?
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > <https://launchpad.net/%7Ekicad-developers>
> > > Post to : kicad-developers@lists.launchpad.net
> > > <mailto:kicad-developers@lists.launchpad.net>
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > <https://launchpad.net/%7Ekicad-developers>
> > > More help   : https://help.launchpa

Re: [Kicad-developers] eeschema regression

[Oliver Walters]

Has this been fixed? I feel it should be addressed before v5 release. I
haven't had a chance to see if it has been remedied in a recent nightly.

On 22 Dec 2017 04:55, "Wayne Stambaugh" <stambau...@gmail.com> wrote:

> I was working a new board and I'm seeing this now too.  I didn't make
> any changes to this code so who ever broke it, please fix it.  You
> shouldn't need to reload the entire library table every time you add a
> symbol.  The library caches should only get reloaded the first time they
> are opened, a change occurs to the library file since the last time they
> were opened (this is automatic and doesn't require you do anything), or
> changes are made to the library table.
>
> On 12/17/2017 2:19 PM, Nick Østergaard wrote:
> > I am not sure why, but I see the progress dialog opened for an equal
> > amount of time every time in my case. Testing on windows 10.
> >
> > The path Seth proposed seem to work sort of. But it does not show the
> > loading dialog on init and I get an error dialog shortly after I open
> > eeschema that it fails to load a dcm file. This error does not occur
> > without Seths patch.
> >
> > But on subsequent additions of a symbol the dialog is not shown and with
> > no delay as expected.
> >
> > 2017-12-16 23:52 GMT+01:00 Oliver Walters
> > <oliver.henry.walt...@gmail.com <mailto:oliver.henry.walt...@gmail.com
> >>:
> >
> > Wayne,
> >
> > I believe you are correct, they are cached and the progress dialog
> > is the actual source of the perceived delay. If this dialog is only
> > shown on first library load that would be sufficient.
> >
> > On Sun, Dec 17, 2017 at 12:40 AM, Wayne Stambaugh
> > <stambau...@gmail.com <mailto:stambau...@gmail.com>> wrote:
> >
> > Are you sure the libraries are actually being reloaded?  The
> > behavior I
> > observe is the first time I open the symbol chooser, the
> > progress dialog
> > is open for a significant amount of time while the libraries are
> > being
> > loaded.  On all subsequent openings of the symbol chooser, the
> > progress
> > dialog is dismissed very quickly indicating that the libraries
> have
> > already been cached.  I agree that the progress dialog being
> > displayed
> > every time the symbol chooser is opened is annoying.  I probably
> > merged
> > this patch too quickly.  After the initial loading of all of the
> > symbol
> > libraries, the progress dialog doesn't need to be shown.
> >
> > On 12/15/2017 09:10 PM, Oliver Walters wrote:
> > > I think that there has been a functional regression in a
> > recent build,
> > > relating to placing symbols in eeschema.
> > >
> > > Previously, the libraries were loaded once when the schematic
> > was opened.
> > >
> > > now, the entire symbol library set is re-loaded every time you
> > select
> > > "Place Symbol". This brings up the "loading symbol libraries"
> > progress
> > > dialog before opening the component selector window.
> > >
> > > This is very tedious - especially on Windows where loading
> > symbols can
> > > be an order of magnitude slower than linux. It really
> > interrupts work flow.
> > >
> > > I do not imagine this is intended behaviour? Can anyone
> > comment on this?
> > >
> > > Oliver
> > >
> > >
> > > ___
> > > 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
> > <https://launchpad.net/~kicad-developers>
> > Post to 

Re: [Kicad-developers] New symbol table: problems with '/' characters?

[Oliver Walters]

This "policy" is already in place for the libraries -
http://kicad-pcb.org/libraries/klc/G1.1/

On 29 Dec 2017 10:25 AM, "Andy Peters"  wrote:

> On Nov 18, 2017, at 6:07 AM, 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.
>
>
> Hi, Wayne,
>
> I just ran into this problem. (I’m using the Dec 24 nightly on a High
> Sierra Mac.) The thing is that my libraries are in a directory to which
> Kicad should have write access. On my Mac, they’re at ~/Library/Application
> Support/kicad/library
>
> The three parts in my library that use a forward-slash in the name are new
> for a design I am still working on, so renaming them in the library and
> then replacing the components on the schematic from the library isn’t too
> painful. That said: should “policy” going forward be to simply not have
> slashes in part names? I guess this is probably wise, since as I understand
> it, the .sweet format will be like .pretty with one symbol per file and the
> file’s name is the symbol name.
>
> -a
>
>
> 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"  >> 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/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
>
>
>
>
> ___
> 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] OSX dev environments

[Oliver Walters]

I followed this guide to set-up eclipse environment.

https://gist.github.com/johnbeard/895bad60e4716f7f9c77

On 25 Dec 2017 12:37, "Tomasz Wlostowski"  wrote:

> On 25/12/17 02:03, Jeff Young wrote:
> > I was going to ask you guys for an Xcode project file for Christmas, but
> I’ve come to the conclusion that I absolutely hate Xcode.
> >
> > I’ve used Eclipse before, and was no big fan of it either.  I did really
> like IntelliJ, though, and I see they’ve got a C version too (CLion).  Has
> anyone used it to build KiCad?
> >
> Hi Jeff,
>
> I tried CLion. After a ~10 minute-long freeze (indexing the code) it
> crashed due to lack of memory. With a 6 GB java heap the project loaded,
> but the editor was veeery slow.
>
> IMHO Get Atom if you need something easy to use on a Mac or Visual
> Studio (if you like "big" C++ IDEs).
>
> 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] Question - Editing symbol aliases

[Oliver Walters]

jp,

Thanks, I did not know about that!

On Fri, Dec 22, 2017 at 6:23 PM, jp charras <jp.char...@wanadoo.fr> wrote:

> Le 22/12/2017 à 04:35, Oliver Walters a écrit :
> > Maybe I'm missing something very obvious, but how do you edit symbol
> aliases with the new symbol editor?
> >
> > If you select a symbol from the symbol tree, it jumps to the master
> copy, and I cannot see a way to
> > edit the .dcm information for the aliased versions...
> >
> > Any hints?
> >
>
> Like before:
> Select the alias from the list displayed in the main horizontal toolbar
> before editing information.
>
>
> --
> 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] Question - Editing symbol aliases

[Oliver Walters]

Maybe I'm missing something very obvious, but how do you edit symbol
aliases with the new symbol editor?

If you select a symbol from the symbol tree, it jumps to the master copy,
and I cannot see a way to edit the .dcm information for the aliased
versions...

Any hints?
___
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] Symbol library descriptions

[Oliver Walters]

I think it would be useful if the sym-lib-table entry descriptions could be
used within KiCad - perhaps in the component selector tree view?

For example, if a top-level item (library) is selected, display the text in
the sym-lib-table in the bottom-left panel?


[image: Inline image 1]

AFAIK this descriptive text is not displayed anywhere outside the library
table editor window.
___
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] eeschema regression

[Oliver Walters]

Wayne,

I believe you are correct, they are cached and the progress dialog is the
actual source of the perceived delay. If this dialog is only shown on first
library load that would be sufficient.

On Sun, Dec 17, 2017 at 12:40 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Are you sure the libraries are actually being reloaded?  The behavior I
> observe is the first time I open the symbol chooser, the progress dialog
> is open for a significant amount of time while the libraries are being
> loaded.  On all subsequent openings of the symbol chooser, the progress
> dialog is dismissed very quickly indicating that the libraries have
> already been cached.  I agree that the progress dialog being displayed
> every time the symbol chooser is opened is annoying.  I probably merged
> this patch too quickly.  After the initial loading of all of the symbol
> libraries, the progress dialog doesn't need to be shown.
>
> On 12/15/2017 09:10 PM, Oliver Walters wrote:
> > I think that there has been a functional regression in a recent build,
> > relating to placing symbols in eeschema.
> >
> > Previously, the libraries were loaded once when the schematic was opened.
> >
> > now, the entire symbol library set is re-loaded every time you select
> > "Place Symbol". This brings up the "loading symbol libraries" progress
> > dialog before opening the component selector window.
> >
> > This is very tedious - especially on Windows where loading symbols can
> > be an order of magnitude slower than linux. It really interrupts work
> flow.
> >
> > I do not imagine this is intended behaviour? Can anyone comment on this?
> >
> > 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
>
___
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] eeschema regression

[Oliver Walters]

I think that there has been a functional regression in a recent build,
relating to placing symbols in eeschema.

Previously, the libraries were loaded once when the schematic was opened.

now, the entire symbol library set is re-loaded every time you select
"Place Symbol". This brings up the "loading symbol libraries" progress
dialog before opening the component selector window.

This is very tedious - especially on Windows where loading symbols can be
an order of magnitude slower than linux. It really interrupts work flow.

I do not imagine this is intended behaviour? Can anyone comment on this?

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

Re: [Kicad-developers] Some thoughts on symbol remapping

[Oliver Walters]

>
> I noticed that your symbol library table uses absolute paths rather than
> using the SYMBOL_LIB_DIR path expansion.  This should not make any
> difference as long as the path you used is the same path as old library
> list look up path.  If it's not, that is your problem.  The remapping
> will not look up by symbol name in the symbol library table if the
> symbol is not found in the original library in the old library list that
> it was loaded from.  I will attempt to explain this again so everyone
> who is having this issue can understand what is happening.


The sym-lib-table was created by the project-update tool, and I had not
defined SYMBOL_LIB_DIR. However the generated sym-lib-table did point to
the libraries I was using previously in this project (v4)

SYMBOL_LIB_DIR was defined as "C:\msys64\mingw64\share\kicad\library". I
don't have a build setup on this machine and the signed windows were
unavailable. This is a jenkins nightly.

The process makes sense (I think) but the failures are quite transparent.

Currently the "rescue orphans" procedure in the other dialog works very
well. Perhaps we could:

a) Run this operation after "rescue" if the rescue did not work?
b) Explicitly point users to make use of this dialog.

On Fri, Dec 15, 2017 at 10:42 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> I noticed that your symbol library table uses absolute paths rather than
> using the SYMBOL_LIB_DIR path expansion.  This should not make any
> difference as long as the path you used is the same path as old library
> list look up path.  If it's not, that is your problem.  The remapping
> will not look up by symbol name in the symbol library table if the
> symbol is not found in the original library in the old library list that
> it was loaded from.  I will attempt to explain this again so everyone
> who is having this issue can understand what is happening.
>
> Here are the steps that occur for remapping each symbol (not including
> the final rescue since that is just another library in the old project
> library list):
>
> Find the full path and file name of the old library list lookup method
> used obtain the symbol link.  This is found in LIB_PART::m_library
> member.  This will point to the same library as if you were using stable
> version 4.
>
> Look for the library by path and full file name in the global symbol
> library table.  If the library cannot be found in the global symbol
> library table and the file exists, add this library to the project
> symbol library table and give it a unique name if necessary.
>
> Set the symbol library nickname to the entry in the symbol library table.
>
> Once all symbols are remapped, write the project symbol library table
> and refresh if necessary and remove all of the libraries from the old
> project library list.
>
> I suspect that you are running a development version of kicad that
> cannot find the original symbol libraries in the project library list
> because they are not in a path that it expects them to be in.  You can
> fix this by manually editing the project file to include this path so
> the remapping will work correctly.
>
> Once the remapping is complete,
> On 12/14/2017 06:05 PM, Oliver Walters wrote:
> > Wayne,
> >
> > Here is the issue I am facing. Maybe I have misunderstood the process,
> > or maybe I have found a bug.
> >
> > 1. Load simple legacy project and attempt to remap. Failures across the
> > board.
> > Inline image 1
> >
> > 2. Check the sym-lib-table
> >
> > Inline image 2
> >
> >
> > 3. Confirm that the symbols do actually exist in the loaded libs
> >
> >
> > Inline image 3
> >
> > 4. No dice
> >
> > Inline image 4
> >
> > 5. Try again?
> >
> > Inline image 5
> >
> > 6. Weep, etc
> >
> > What am I doing wrong?
> >
> > Oliver
> >
> > On Thu, Dec 14, 2017 at 10:41 AM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > On 12/13/2017 01:56 AM, Oliver Walters wrote:
> > > I finally had a chance to try the symbol remapping on a real
> project,
> > > and I have a few thoughts on how I think it could be improved from
> a
> > > users perspective (with code to back up my thoughts!)
> > >
> > > 1. "Remap" should replace "rescue"
> > >
> > > The remap tool, with some work, should replace the "symbol rescue"
> tool.
> > > There are two major cases which it should cover:
> > >
> > > a) Handling "legacy" (v4 and prior) sy

Re: [Kicad-developers] Some thoughts on symbol remapping

[Oliver Walters]

jp,

I was unaware of this new feature, that does perform a lot of the functions
I mentioned.

Can this new tool replace the "Rescue symbols" tool under the "tools" menu?

On Wed, Dec 13, 2017 at 6:19 PM, jp charras <jp.char...@wanadoo.fr> wrote:

> Le 13/12/2017 à 07:59, Oliver Walters a écrit :
> > Following is a screenshot of what happens when a symbol cannot be
> remapped:
> >
> > Inline image 1
> >
> > On Wed, Dec 13, 2017 at 5:56 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com
> > <mailto:oliver.henry.walt...@gmail.com>> wrote:
> >
> > I finally had a chance to try the symbol remapping on a real
> project, and I have a few thoughts
> > on how I think it could be improved from a users perspective (with
> code to back up my thoughts!)
> >
> > 1. "Remap" should replace "rescue"
> >
> > The remap tool, with some work, should replace the "symbol rescue"
> tool. There are two major
> > cases which it should cover:
> >
> > a) Handling "legacy" (v4 and prior) symbols which do not specify a
> library nickname
> > b) Handling missing libraries or symbols
> >  i) A library has been moved or deleted
> > ii) An item has been renamed in a library
> >
> > The rescue tool does not seem to work at all now, with the new
> sym-lib-table approach. I think I
> > have come up with a way to combine the two tools that provides a
> better approach anyhow.
> >
> > 2. Let users "remap" multiple times.
> >
> > The current implementation only allows remap if *all* the symbols
> are un-mapped. If a partial
> > remap occurs then the users are left high and dry. Partial remaps
> should be allowed, this gives
> > the users chance to fix their library tables or whatever.
> >
> > 3. Separate project-remap from symbol-remap
> >
> > The regeneration of library tables should be separate from symbol
> remapping. Rescue the project
> > once, (with a visible warning to user at first project load, as is
> currently the case). But,
> > allow symbol remap from the menu at any stage (even if there are no
> symbols to remap!)
> >
> > 4. Group similar symbols together when remapping
> >
> > If a schematic has 100+ 'R' symbols, they should be grouped together
> so that they can *all* be
> > remapped at once. Collect similar symbols together. (See
> demonstrator image below).
> >
> > 5. Allow manual remap selection
> >
> > If auto-remapping fails for a particular symbol, allow the user to
> select a new symbol manually
> >
> > 6. Allow skipping of remapped symbols
> >
> > Some may be not able to be remaped at the current time. Allow user
> to skip and come back later.
> >
> > 7. Provide a dry-run first and let the user see what is happening.
> >
> >
> > I have actually implemented all of the points above. See
> demonstrator images here:
> >
> > A) Dry run with explicit output messages, and information on what
> will be changed
> >
> > Inline image 1
> >
> > B) Success!
> >
> > Inline image 2
> >
> > If this is a good approach I will spend some more time on this,
> there are still some issues to
> > work out. However, It is (to me) a much cleaner approach.
> >
> > Thoughts?
> >
> > Oliver
>
> Remember there is a tool in schematic editor ( "Edit / Edit Components  to
> Symbol Library Links" )
> that should seriously help for global remapping.
>
>
> --
> 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] Add links to library contributor page(s) on GitHub

[Oliver Walters]

Wayne,

Ah, dropped the wxT.

I have fixed it in the attached patch.

Thanks,

On Tue, Dec 12, 2017 at 3:36 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Oliver,
>
> I see you noticed that I added a place holder for library devs.  I was
> going to ask you for a list of contributors but I like you solution
> better.  That being said, there is a problem with your patch on windows
> (see attached image).
>
> Cheers,
>
> Wayne
>
> On 12/11/2017 9:02 AM, Oliver Walters wrote:
> > The attached patch adds links to the library contributor pages, which
> > list all the contributors to the various library repositories:
> >
> > Previously the symbols and footprints were attributed to "Leet hacker1"
> > and her associate "Leet hacker2". While I am sure they have made
> > valuable contributions, I think their time has come.
> >
> > Inline image 1
> >
> >
> > Wayne: I would like to reiterate that Christophe and Renie have not made
> > contributions to the _current_ 3D model repository which has been
> > completely remastered thanks to the great efforts of Maurice et al. It
> > has _no_ resemblance to the old hodge-podge of model files, it's a real
> > credit to the work of the modeling team
> >
> > I think here (unlike the icons credits) it would be sufficient to just
> > link to the GitHub contributors page - would you agree?
> >
> > Thanks,
> > 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
>
>
From d1eec5b40dc1a3684af70e24e0de071bd0260779 Mon Sep 17 00:00:00 2001
From: Oliver <oliver.henry.walt...@gmail.com>
Date: Tue, 12 Dec 2017 00:56:32 +1100
Subject: [PATCH] Add links to list of library contributors on GitHub

- Apologies to "leet hackers"
- Add URL option to contributor entity
---
 common/dialog_about/AboutDialog_main.cpp | 43 ++--
 common/dialog_about/aboutinfo.h  |  4 +++
 common/dialog_about/dialog_about.cpp | 29 -
 3 files changed, 68 insertions(+), 8 deletions(-)

diff --git a/common/dialog_about/AboutDialog_main.cpp b/common/dialog_about/AboutDialog_main.cpp
index d259962..2c362f4 100644
--- a/common/dialog_about/AboutDialog_main.cpp
+++ b/common/dialog_about/AboutDialog_main.cpp
@@ -254,94 +254,117 @@ static void buildKicadAboutBanner( EDA_BASE_FRAME* aParent, ABOUT_APP_INFO& aInf
  */
 aInfo.AddTranslator( new CONTRIBUTOR( "Robert Buj",
   wxEmptyString,
+  wxEmptyString,
   "Catalan (CA)",
   KiBitmapNew( lang_catalan_xpm ) ) );
 aInfo.AddTranslator( new CONTRIBUTOR( wxT( "Martin Kratoška" ),
   wxEmptyString,
+  wxEmptyString,
   "Czech (CZ)",
   KiBitmapNew( lang_cs_xpm ) ) );
 aInfo.AddTranslator( new CONTRIBUTOR( "Jerry Jacobs",
   wxEmptyString,
+  wxEmptyString,
   "Dutch (NL)",
   KiBitmapNew( lang_nl_xpm ) ) );
 aInfo.AddTranslator( new CONTRIBUTOR( "Vesa Solonen",
   wxEmptyString,
+  wxEmptyString,
   "Finnish (FI)",
   KiBitmapNew( lang_fi_xpm ) ) );
 aInfo.AddTranslator( new CONTRIBUTOR( "Jean-Pierre Charras",
   wxEmptyString,
+  wxEmptyString,
   "French (FR)",
   KiBitmapNew( lang_fr_xpm ) ) );
 aInfo.AddTranslator( new CONTRIBUTOR( wxT( "Mateusz Skowroński" ),
   wxEmptyString,
+  wxEmptyString,
   

Re: [Kicad-developers] file format change and STEP exporter

[Oliver Walters]

>
> Thanks - some small change will be needed to kicad2step to handle the
> change in the file format from inch to mm for the model offsets.
> For the wrl/step substitution there is no other work needed.


This has already been done :)

On Sun, Dec 10, 2017 at 8:31 AM, Cirilo Bernardo <cirilo.berna...@gmail.com>
wrote:

> Thanks - some small change will be needed to kicad2step to handle the
> change in the file format from inch to mm for the model offsets.
> For the wrl/step substitution there is no other work needed.
>
> The reason the STEP exporter is separate from kicad is that not all
> people need the mechanical exporter and keeping it separate allows
> us to build kicad without the exporter and to install the exporter at
> any time in the future without recompiling kicad. The 3D viewer
> already makes use of OCE via its plugin system and the idea was
> that other export/import functions should eventually use a plugin
> system as well; keeping kicad2step separate makes it easier to
> convert it to a plugin in the future when we have a plugin API to
> support it.  I'm not too happy with OCE being in the plugin either;
> some defective models can cause OCE to crash and in the case
> of the plugin that means that kicad will also crash. I think the
> OCE (IGES/STEP) plugin will eventually have to be written so
> that the conversion happens in a separate process. In the case
> of kicad2step, if OCE crashes kicad is not affected.
>
> - Cirilo
>
> On Sat, Dec 9, 2017 at 8:37 AM, Oliver Walters
> <oliver.henry.walt...@gmail.com> wrote:
> > Cirilo, there are two changes that I am aware of:
> >
> > 1. The change to use mm for 3D model offset. The patch set I have
> submitted
> > fixed this in kicad2step. I do not believe this has been merged yet - JP?
> > 2. The wrl/step substitution which has already been accepted to master.
> >
> > As an aside, was it too difficult to integrate OCE code into KiCad? This
> way
> > we could get better error feedback, and many other advantages that an
> > external tool cannot provide. I'm sure you had your reasons though.
> >
> > On 9 Dec 2017 18:07, "José Ignacio" <jose.cyb...@gmail.com> wrote:
> >>
> >> Indeed, it is much easier to just re-parse pcb files than it is to
> extract
> >> data using the internal APIs. The intention is for that to be temporary
> >> until the internal api improves to the point where writing something
> >> interfacing with it wont be a pile of workarounds for quirks and sharp
> >> corners. If anything, it is a testament to the improvement the s-expr
> format
> >> brought to kicad, being so easy to parse and work with external tools.
> >>
> >> On Sat, Dec 9, 2017 at 12:59 AM, Kevin Cozens <ke...@ve3syb.ca> wrote:
> >>>
> >>> On 2017-12-08 04:34 PM, Cirilo Bernardo wrote:
> >>>>
> >>>>   I haven't had time to follow changes for quite some time but there
> >>>> was some talk about making changes to the PCB file format. If the
> >>>> file format changes, some changes will also have to be made to
> >>>> the STEP exporter (utils/kicad2step) to handle the new format.
> >>>
> >>>
> >>> This surprises me a little. Does that mean kicad2step is processing the
> >>> saved file and not working from the data held internal to the program?
> >>>
> >>> --
> >>> Cheers!
> >>>
> >>> Kevin.
> >>>
> >>> http://www.ve3syb.ca/   |"Nerds make the shiny things that
> >>> distract
> >>> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why
> >>> we're
> >>> | powerful!"
> >>> #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] file format change and STEP exporter

[Oliver Walters]

JP,

Yep I must have missed that. Thanks for merging.

On 9 Dec 2017 19:57, "jp charras" <jp.char...@wanadoo.fr> wrote:

> Le 09/12/2017 à 09:37, Oliver Walters a écrit :
> > Cirilo, there are two changes that I am aware of:
> >
> > 1. The change to use mm for 3D model offset. The patch set I have
> submitted fixed this in
> > kicad2step. I do not believe this has been merged yet - JP?
>
> AFAIK it was merged.
> Please verify.
>
> > 2. The wrl/step substitution which has already been accepted to master.
> >
>
>
> --
> 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] file format change and STEP exporter

[Oliver Walters]

Cirilo, there are two changes that I am aware of:

1. The change to use mm for 3D model offset. The patch set I have submitted
fixed this in kicad2step. I do not believe this has been merged yet - JP?
2. The wrl/step substitution which has already been accepted to master.

As an aside, was it too difficult to integrate OCE code into KiCad? This
way we could get better error feedback, and many other advantages that an
external tool cannot provide. I'm sure you had your reasons though.

On 9 Dec 2017 18:07, "José Ignacio"  wrote:

> Indeed, it is much easier to just re-parse pcb files than it is to extract
> data using the internal APIs. The intention is for that to be temporary
> until the internal api improves to the point where writing something
> interfacing with it wont be a pile of workarounds for quirks and sharp
> corners. If anything, it is a testament to the improvement the s-expr
> format brought to kicad, being so easy to parse and work with external
> tools.
>
> On Sat, Dec 9, 2017 at 12:59 AM, Kevin Cozens  wrote:
>
>> On 2017-12-08 04:34 PM, Cirilo Bernardo wrote:
>>
>>>   I haven't had time to follow changes for quite some time but there
>>> was some talk about making changes to the PCB file format. If the
>>> file format changes, some changes will also have to be made to
>>> the STEP exporter (utils/kicad2step) to handle the new format.
>>>
>>
>> This surprises me a little. Does that mean kicad2step is processing the
>> saved file and not working from the data held internal to the program?
>>
>> --
>> Cheers!
>>
>> Kevin.
>>
>> http://www.ve3syb.ca/   |"Nerds make the shiny things that
>> distract
>> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why
>> we're
>> | powerful!"
>> #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

Re: [Kicad-developers] Zone filling & display speed improvements

[Oliver Walters]

Tom,

Could the filling progress be displayed in the lower statusbar instead of a
popup window?

On Tue, Dec 5, 2017 at 2:48 PM, Henner Zeller  wrote:

> On 4 December 2017 at 16:41, Tomasz Wlostowski
>  wrote:
> > On 04/12/17 15:43, Henner Zeller wrote:
> >> On 4 December 2017 at 06:31, Tomasz Wlostowski
> >>  wrote:
> >>> On 04/12/17 02:05, Henner Zeller wrote:
>  On 2 December 2017 at 10:11, Henner Zeller  wrote:
> > On 1 December 2017 at 08:12, Tomasz Wlostowski
> >  wrote:
> >> On 29/11/17 16:10, jp charras wrote:
> >>> I am using a few board in Kicad demos: interf_u, video,
> pic_programmer.
> >>>
> >>> Also, filled areas are no shown in OpenGL, but are shown in Cairo
> canvas.
> >>
> >> Hi all,
> >>
> >> The branch [1] contains a set of improvements in the zone filling
> >> algorithm. It's several times faster than in the current master
> branch.
> >>
> >> I'd like to merge it soon and move on to fixing P issues pending
> for
> >> the V5 - I'll greatly appreciate testing and feedback!
> >
> > Hi Tom,
> >
> > I'll compile your branch hopefully later this weekend for testing.
> > If you need another board for testing, I am currently having a board
> > that takes annoying several seconds to fill the zones in head KiCad,
> > which hence might be interesting test case:
> >>>
> >>> Hi Henner,
> >>>
> >>> What OS did you build for?
> >>
> >> This was on Debian testing on a x86_64 machine.
> >> g++ 7.2.0, Cairo: 1.15.8, boost 1.62.0
> >>
> >> -h
> >
> > Hi guys,
> >
> > Now it should work fine - the filling algorithm was not thread safe and
> > apparently wxProgressDialog can't be invoked from non-main thread.
> >
> > Check out the updated branch.
>
> Thanks Tom!
>
> Nice, the [tom-faster-zones-dec01] branch works well and very fast. I
> have not seen any crashes anymore.
>
> There is a leftover method mentioned in pcbnew/class_zone.h:
>   void RemoveInsulatedCopperIslands()
> .. which is not used/implemented so should be removed from the header.
>
> One thing I noticed: since it is sooo fast now, the progress-popup is
> actually quite annoying as it just briefly blinks up and vanishes
> again (at least for the board I was testing it with). Maybe it should
> only show up if the operation is still ongoing after a second and less
> than 50% is done at that time ?
>
> Another thought: if zone filling can be that fast, maybe we should
> only store zone outlines in the *.kicad_pcb file, not the
> (filled_polygon ...) that are now also stored. It is cheap to just
> recreate them when loading the file.
> Backround: This can save a lot of disk space as the filled polygons
> tend to create a lot of points and tend to completely change with tiny
> changes to other elements on the board, such as a moved via. This
> means that version control has to store huge changes every time and it
> is hard to see what actual changes are happening just looking at the
> diff (I like to inspect diffs before checking something in, and this
> makes it hard. Also it makes it hard to git merge kicad-pcbs).
> Downside is, that everyone loading a file has to pay the extra cost to
> create the zones (e.g. gerber generation). Maybe it could be a
> heuristic to not store the filled polygons if recreating it takes less
> than a second or so.
>
> Cheers,
>   Henner.
>
> >
> > Thanks!
> > 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] COMPONENT_TREE performance

[Oliver Walters]

Perhaps to help prevent the discussion bubbling up unbidden every few
months, we should create a document which formalises:

1. Gripes or difficulties with wx
2. Features we would require in some hypothetical GUI toolkit
3. Pros/cons of each toolkit

This document could be updated as we discover new things that we love about
wx. It would also serve to prevent each point being rehashed all the time.

On 5 Dec 2017 07:34, "Gaurav Juvekar"  wrote:

Hi all,

>
> I wondered when this subject would rear it's ugly head again.  Every
> couple of years we dig this horse up and beat it to death again.  It's
> getting rather comical.  Like JP, I would like to see some proof of all
> the wonderful things QT can do for us that wx cannot.  It has been a
> long time since I've done anything with QT so maybe my information is
> dated but I don't remember QT being all that.  I just remember trading
> one set of issues for another.  I've used several UI toolkits over the
> years and they all have pros and cons.  I'm not opposed to using any
> toolkit.  I am opposed to doing it for someone's personal preference for
> one toolkit over another.  The question remains, would the effort to
> port to another toolkit be worth it?  I have seen no objective evidence
> to support the assumption that switching to QT or any other toolkit will
> make life better for KiCad developers and until I do, I see no reason to
> kick wx to the curb.  What I do know is that the effort will be massive
> and basically bring new feature development to a halt for a significant
> period of time.
>


My two cents (and I could be very wrong).

One way to (objectively) judge toolkits would be to look at other projects
"similar" to KiCad and see what woes they have/had with the GUI toolkit.

IMO, KiCad significantly uses four main things.
- Canvas (whose code won't be affected much by choice of a GUI toolkit,
except handling mouse / keyboard events)
- Toolbars/buttons (theres the old feature request of movable/dockable
toolbars and the bug that silently hides buttons if the window is small)
- Lists/trees and selections (component/libraries/CvPcb)
- Tables with editable cells (fp/sym-lib-table setting, DRC settings?)

Inkscape and GIMP are good examples of the first two (and cross-platform,
so that aspect can also be evaluated).

Synaptic (only one I know that filters a lot of rows) or file managers
would be good examples of using lists/trees in a GUI toolkit.

No idea about a popular software using heterogeneous editable table cells
(IDK if any spreadsheets use default GUI widgets), but I'm sure there's
something.

I'm not saying that we should switch (there's that personal bias as most of
these examples use GTK), but this could be a good way if we really want to
objectively consider switching GUI toolkits.


--
Regards,
Gaurav Juvekar

___
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] Is there a timeframe till the stable release will be announced

[Oliver Walters]

Thanks Wayne and Adam for the update

A friendly reminder once again that the packagers must now point to

Footprint - https://github.com/kicad/kicad-footprints
Symbols - https://github.com/kicad/kicad-symbols
Models - https://github.com/kicad/kicad-packages3d
Templates - https://github.com/kicad/kicad-templates

The footprint and symbol repos will maintain their own lib-table files.
These are checked by Travis CI so they will always stay in sync.

Further, please do not package the 3D models with KiCad by default. We have
now surpassed 2Gig of model files :)

Thanks,
Oliver

On Fri, Dec 1, 2017 at 9:09 AM, Wayne Stambaugh 
wrote:

> I am hoping for a release by FOSDEM (February 3-4, 2018) but I think
> that's a bit optimistic.  I would like to create the stable 5 branch
> over the Christmas break and that would give us another month to polish
> and bug fix before release.
>
> On 11/30/2017 05:07 PM, Adam Wolf wrote:
> > There's certainly a lot of moving pieces--once the library
> > reorganization is done, it'll take little bit of tweaking in the
> > packaging stuff, at least for macos, and then another (hopefully
> > quick!) round of testing.
> >
> > Adam Wolf
> >
> > On Thu, Nov 30, 2017 at 3:55 PM, Rene Pöschl  wrote:
> >> We librarians would need to know how long we have until our library
> >> reorganization needs to be finished.
> >>
> >> (The footprint lib reorganization is nearly done. Now we are working on
> the
> >> symbol libs.)
> >>
> >>
> >> ___
> >> 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] Tweaks to about dialog

[Oliver Walters]

Nick,

It appears this was changed in a74bad1630dcd9c280ddb126926e1313b2741333



On Fri, Dec 1, 2017 at 12:21 AM, Nick Østergaard <oe.n...@gmail.com> wrote:

> It seems that some characters are not rendered properly in the names
> anymore, like Ø. Maybe this is because of the removal of the wxT macros.
>
> 2017-11-28 0:23 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com>:
>
>> Oliver,
>>
>> I merged your patch in the development branch.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 11/26/2017 06:07 AM, Oliver Walters wrote:
>> > I'm not opposed to a
>> > contributors list on the website although I personally am not
>> terribly
>> > interested in maintaining this list.
>> >
>> >
>> > And yet we have an outdated list _compiled into a binary_ which does not
>> > reflect the great contributions made by the new 3D modelling team. I am
>> > not suggesting that we add everyone (quite the opposite), but just
>> > offload this to somewhere it can be updated without recompiling KiCad.
>> >
>> > In any case, please find attached an updated patch which only fixes the
>> > links on the first tab, removing the outdated smisoto links.
>> >
>> >
>> > On Sun, Nov 26, 2017 at 2:20 AM, Wayne Stambaugh <stambau...@gmail.com
>> > <mailto:stambau...@gmail.com>> wrote:
>> >
>> > On 11/24/2017 04:01 PM, Oliver Walters wrote:
>> > > Can we have a link to a page on the website where we have a long
>> form
>> > > list? Updating a binary file with a fluid list of contributors
>> seems hokey.
>> >
>> > I know it's a bit dated but I think having credits in the
>> application is
>> > a nice reward for folks who have contributed.  I'm not opposed to a
>> > contributors list on the website although I personally am not
>> terribly
>> > interested in maintaining this list.
>> >
>> > >
>> > > The 3D models for example are now script generated using
>> Maurice's tools
>> > > but contributed by various people.
>> > >
>> > > On 25 Nov 2017 06:37, "Simon Wells" <swel...@gmail.com > swel...@gmail.com>
>> > > <mailto:swel...@gmail.com <mailto:swel...@gmail.com>>> wrote:
>> > >
>> > > Well if you want to keep that panel it should represent all
>> those
>> > > people who have provided artistry to kicad, as such for those
>> non
>> > > programmers maybe there needs to be a script or similar that
>> someone
>> > > can just put their name in and it will spit out a patch that
>> can be
>> > > submitted to the mailing list
>> > >
>> > >
>> > >
>> > > > On 25/11/2017, at 3:44 AM, Wayne Stambaugh <
>> stambau...@gmail.com <mailto:stambau...@gmail.com>
>> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
>> wrote:
>> > > >
>> > > > Oliver,
>> > > >
>> > > > I would rather not remove the artists panel from the about
>> dialog.  I
>> > > > know some of those folks haven't contributed recently but
>> many of them
>> > > > contributed a lot of bitmaps and icons over the years so
>> they deserve
>> > > > credit for the efforts.  The remaining changes are fine.
>> > > >
>> > > > Cheers,
>> > > >
>> > > > Wayne
>> > > >
>> > > > On 11/23/2017 08:31 AM, Oliver Walters wrote:
>> > > >> As mentioned in previous thread, I have made some slight
>> changes
>> > > to the
>> > > >> About dialog.
>> > > >>
>> > > >> 1. Wording / link tweaks
>> > > >> 2. Removed references to outdated links (now better served
>> from the
>> > > >> kicad-pcb.org <http://kicad-pcb.org> <http://kicad-pcb.org
>> >
>> > <http://kicad-pcb.org> site)
>> > > >> 3. Removed "artists" tab - very outdated, 3D models are
>> now community
>> > > >> contributed
>> > > >>
>> >

Re: [Kicad-developers] Fwd: Re: [PATCH] Fix for 3D model offset

[Oliver Walters]

Rebuilt and attached

On Thu, Nov 30, 2017 at 7:53 PM, jp charras <jp.char...@wanadoo.fr> wrote:

>
>  Message transféré 
> Sujet : Re: [Kicad-developers] [PATCH] Fix for 3D model offset
> Date : Thu, 30 Nov 2017 09:43:05 +0100
> De : jp charras <jp.char...@wanadoo.fr>
> Répondre à : KiCad Developers <kicad-developers@lists.launchpad.net>
> Pour : Oliver Walters <oliver.henry.walt...@gmail.com>
>
> Le 30/11/2017 à 08:38, Oliver Walters a écrit :
> > JP, Wayne,
> >
> > Any update on how we want to handle this?
> >
> > On Mon, Nov 27, 2017 at 9:48 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com
> > <mailto:oliver.henry.walt...@gmail.com>> wrote:
> >
>
> Hi Oliver,
> Could you rebase and rebuild yours patches: they do not apply on current
> master.
>
> Thanks.
>
>
> --
> 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
>
From a16bf42914e78ca69c51d309b62784d9730a0973 Mon Sep 17 00:00:00 2001
From: Oliver <oliver.henry.walt...@gmail.com>
Date: Mon, 27 Nov 2017 21:46:53 +1100
Subject: [PATCH 3/3] Write "offset" only if non-zero

- Use "at" if all offset dimensions are zero
- Use "offset" otherwise
---
 pcbnew/kicad_plugin.cpp | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/pcbnew/kicad_plugin.cpp b/pcbnew/kicad_plugin.cpp
index 1314864..518e1c6 100644
--- a/pcbnew/kicad_plugin.cpp
+++ b/pcbnew/kicad_plugin.cpp
@@ -1143,9 +1143,22 @@ void PCB_IO::format( MODULE* aModule, int aNestLevel ) const
 /* Write 3D model offset in mm
  * 4.0.x wrote "at" which was actually in inches
  * 5.0.x onwards, 3D model offset is written using "offset"
+ *
+ * If the offset is all zero, write "at" (fewer file changes)
+ * Otherwise, write "offset"
  */
 
-m_out->Print( aNestLevel+2, "(offset (xyz %s %s %s))\n",
+wxString offsetTag = "offset";
+
+if( bs3D->m_Offset.x == 0 &&
+bs3D->m_Offset.y == 0 &&
+bs3D->m_Offset.z == 0 )
+{
+offsetTag = "at";
+}
+
+m_out->Print( aNestLevel+2, "(%s (xyz %s %s %s))\n",
+  offsetTag.ToStdString().c_str(),
   Double2Str( bs3D->m_Offset.x ).c_str(),
   Double2Str( bs3D->m_Offset.y ).c_str(),
   Double2Str( bs3D->m_Offset.z ).c_str() );
-- 
2.7.4

From be3002200847e49f7670099a0acacc9c98673e7f Mon Sep 17 00:00:00 2001
From: Oliver <oliver.henry.walt...@gmail.com>
Date: Mon, 27 Nov 2017 08:20:02 +1100
Subject: [PATCH 2/3] Decode "offset" in STEP export tool

- Read "at" as inches
- Read "offset" as mm
---
 pcbnew/kicad_plugin.cpp |  2 ++
 utils/kicad2step/pcb/kicadmodel.cpp | 25 +
 2 files changed, 27 insertions(+)

diff --git a/pcbnew/kicad_plugin.cpp b/pcbnew/kicad_plugin.cpp
index f42dcff..1314864 100644
--- a/pcbnew/kicad_plugin.cpp
+++ b/pcbnew/kicad_plugin.cpp
@@ -1142,7 +1142,9 @@ void PCB_IO::format( MODULE* aModule, int aNestLevel ) const
 
 /* Write 3D model offset in mm
  * 4.0.x wrote "at" which was actually in inches
+ * 5.0.x onwards, 3D model offset is written using "offset"
  */
+
 m_out->Print( aNestLevel+2, "(offset (xyz %s %s %s))\n",
   Double2Str( bs3D->m_Offset.x ).c_str(),
   Double2Str( bs3D->m_Offset.y ).c_str(),
diff --git a/utils/kicad2step/pcb/kicadmodel.cpp b/utils/kicad2step/pcb/kicadmodel.cpp
index 6f680e0..61395ba 100644
--- a/utils/kicad2step/pcb/kicadmodel.cpp
+++ b/utils/kicad2step/pcb/kicadmodel.cpp
@@ -80,12 +80,37 @@ bool KICADMODEL::Read( SEXPR::SEXPR* aEntry )
 std::string name = child->GetChild( 0 )->GetSymbol();
 bool ret = true;
 
+/*
+ * Version 4.x and prior used 'at' parameter,
+ * which was specified in inches.
+ */
 if( name == "at" )
+{
 ret = Get3DCoordinate( child->GetChild( 1 ), m_offset );
+
+if( ret )
+{
+m_offset.x *= 25.4f;
+m_offset.y *= 25.4f;
+m_offset.z *= 25.4f;
+}
+}
+/*
+ * From 5.x onwards, 3D model is provided in 'offset

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

[Oliver Walters]

JP, Wayne,

Any update on how we want to handle this?

On Mon, Nov 27, 2017 at 9:48 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> jp,
>
> Sorry I forgot to reapply that patch on top.
>
> Updated patch set is attached.
>
> Thanks,
>
> On Mon, Nov 27, 2017 at 6:48 PM, jp charras <jp.char...@wanadoo.fr> wrote:
>
>> Le 26/11/2017 à 22:21, Oliver Walters a écrit :
>> > Wayne,
>> >
>> > Please find attached an updated patch set which also fixes 3D model
>> units for the STEP exporter tool.
>> >
>> >
>> >
>> > On Thu, Nov 23, 2017 at 1:59 AM, Wayne Stambaugh <stambau...@gmail.com
>> > <mailto:stambau...@gmail.com>> wrote:
>> >
>> > Consistency.  Currently we have two separate units in kicad board
>> and
>> > footprint files.  This change unifies that issue.  I know it's
>> annoying
>> > but it is a decision that I made to make the file formatting more
>> > consistent.  Yes, it is a change that will break some users 3D
>> models
>> > but I think the long term benefit outweighs the short term
>> annoyance.
>>
>> Hi Oliver and Wayne,
>>
>> I am thinking the "offset" should be written in footprint (and board)
>> files *only* if it is not 0,0,0
>>
>> With this patch, all footprint files will be incompatible with stable
>> version, due to a not used
>> (most of time) parameter.
>> Moreover footprint files have no version identification.
>>
>> --
>> 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] [PATCH] Fix for 3D model offset

[Oliver Walters]

jp,

Sorry I forgot to reapply that patch on top.

Updated patch set is attached.

Thanks,

On Mon, Nov 27, 2017 at 6:48 PM, jp charras <jp.char...@wanadoo.fr> wrote:

> Le 26/11/2017 à 22:21, Oliver Walters a écrit :
> > Wayne,
> >
> > Please find attached an updated patch set which also fixes 3D model
> units for the STEP exporter tool.
> >
> >
> >
> > On Thu, Nov 23, 2017 at 1:59 AM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > Consistency.  Currently we have two separate units in kicad board and
> > footprint files.  This change unifies that issue.  I know it's
> annoying
> > but it is a decision that I made to make the file formatting more
> > consistent.  Yes, it is a change that will break some users 3D models
> > but I think the long term benefit outweighs the short term annoyance.
>
> Hi Oliver and Wayne,
>
> I am thinking the "offset" should be written in footprint (and board)
> files *only* if it is not 0,0,0
>
> With this patch, all footprint files will be incompatible with stable
> version, due to a not used
> (most of time) parameter.
> Moreover footprint files have no version identification.
>
> --
> 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
>
From 28025695e70160a5663d83ec4b6dff27dbd58f9e Mon Sep 17 00:00:00 2001
From: Oliver <oliver.henry.walt...@gmail.com>
Date: Mon, 27 Nov 2017 21:46:53 +1100
Subject: [PATCH 3/3] Write "offset" only if non-zero

- Use "at" if all offset dimensions are zero
- Use "offset" otherwise
---
 pcbnew/kicad_plugin.cpp | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/pcbnew/kicad_plugin.cpp b/pcbnew/kicad_plugin.cpp
index 79ef1cf..6dd19e4 100644
--- a/pcbnew/kicad_plugin.cpp
+++ b/pcbnew/kicad_plugin.cpp
@@ -1143,9 +1143,22 @@ void PCB_IO::format( MODULE* aModule, int aNestLevel ) const
 /* Write 3D model offset in mm
  * 4.0.x wrote "at" which was actually in inches
  * 5.0.x onwards, 3D model offset is written using "offset"
+ *
+ * If the offset is all zero, write "at" (fewer file changes)
+ * Otherwise, write "offset"
  */
 
-m_out->Print( aNestLevel+2, "(offset (xyz %s %s %s))\n",
+wxString offsetTag = "offset";
+
+if( bs3D->m_Offset.x == 0 &&
+bs3D->m_Offset.y == 0 &&
+bs3D->m_Offset.z == 0 )
+{
+offsetTag = "at";
+}
+
+m_out->Print( aNestLevel+2, "(%s (xyz %s %s %s))\n",
+  offsetTag.ToStdString().c_str(),
   Double2Str( bs3D->m_Offset.x ).c_str(),
   Double2Str( bs3D->m_Offset.y ).c_str(),
   Double2Str( bs3D->m_Offset.z ).c_str() );
-- 
2.7.4

From cf43b53bce992581902d99790fb305db004d1a7f Mon Sep 17 00:00:00 2001
From: Oliver <oliver.henry.walt...@gmail.com>
Date: Mon, 27 Nov 2017 08:20:02 +1100
Subject: [PATCH 2/3] Decode "offset" in STEP export tool

- Read "at" as inches
- Read "offset" as mm
---
 pcbnew/kicad_plugin.cpp |  2 ++
 utils/kicad2step/pcb/kicadmodel.cpp | 25 +
 2 files changed, 27 insertions(+)

diff --git a/pcbnew/kicad_plugin.cpp b/pcbnew/kicad_plugin.cpp
index 2c75f27..79ef1cf 100644
--- a/pcbnew/kicad_plugin.cpp
+++ b/pcbnew/kicad_plugin.cpp
@@ -1142,7 +1142,9 @@ void PCB_IO::format( MODULE* aModule, int aNestLevel ) const
 
 /* Write 3D model offset in mm
  * 4.0.x wrote "at" which was actually in inches
+ * 5.0.x onwards, 3D model offset is written using "offset"
  */
+
 m_out->Print( aNestLevel+2, "(offset (xyz %s %s %s))\n",
   Double2Str( bs3D->m_Offset.x ).c_str(),
   Double2Str( bs3D->m_Offset.y ).c_str(),
diff --git a/utils/kicad2step/pcb/kicadmodel.cpp b/utils/kicad2step/pcb/kicadmodel.cpp
index 6f680e0..61395ba 100644
--- a/utils/kicad2step/pcb/kicadmodel.cpp
+++ b/utils/kicad2step/pcb/kicadmodel.cpp
@@ -80,12 +80,37 @@ bool KICADMODEL::Read( SEXPR::SEXPR* aEntry )
 std::string name = child->GetChild( 0 )->GetSymbol();
 bool ret = true;
 
+/*
+ * Version 4.x and prior used 'at' parameter,
+ * which wa

Re: [Kicad-developers] [FEATURE] Add keepout areas in footprints

[Oliver Walters]

JP,

Given the feature freeze is now in place, I do not think this will make it
for 5.0.0 release.

I do not have time to spend on this currently, as I am focusing on library
issues.

Cheers,

On Sun, Nov 5, 2017 at 11:58 PM, jp charras <jp.char...@wanadoo.fr> wrote:

> Le 05/11/2017 à 12:04, Oliver Walters a écrit :
> > I think that is the desired behaviour, though? Once in the board, the
> can edit the layers
> > individually anyway.
>
> I missed something, I did not notice it was possible the layers
> individually from the board editor.
> (However, when trying that, I had a Pcbnew crash, but I am not able to
> reproduce it.)
>
> An other UI issue I missed is the fact (after your patch is applied) when
> you try to select a item
> inside a footprint (pad, field) in the board editor, a disambiguated menu
> is displayed showing twice
> the same item, although only one exists.
> It also happens in fpeditor when trying to select a keepout.
>
> >
> > On Sun, Nov 5, 2017 at 9:57 PM, jp charras <jp.char...@wanadoo.fr
> <mailto:jp.char...@wanadoo.fr>> wrote:
> >
> > Le 05/11/2017 à 11:48, Oliver Walters a écrit :
> > > How best to store the layer information then? The way I was doing
> it previously was:
> > >
> > > -  F.Cu
> > > - *.Inner.Cu
> > > - B.Cu
> > >
> > > Is this sufficient?
> >
> > Yes, this is sufficient, when a keepout is inside a footprint.
> >
> > The issue was the fact *.Inner.Cu information was lost with a 2
> layers board, when saving this
> > board, or exporting to the fp editor.
> >
> >
> > >
> >     > On Sun, Nov 5, 2017 at 9:41 PM, jp charras <jp.char...@wanadoo.fr
> > <mailto:jp.char...@wanadoo.fr> <mailto:jp.char...@wanadoo.fr
> <mailto:jp.char...@wanadoo.fr>>> wrote:
> > >
> > > Le 05/11/2017 à 11:12, Oliver Walters a écrit :
> > > > JP,
> > > >
> > > > Did you have any other things you want me to address here?
> > > >
> > > > Cheers,
> > > > Oliver
> > > >
> > >
> > > Yes: I did not make a lot of tests, but I found some issues
> (tested on W7 32 bits):
> > >
> > > First, Pcbnew crashed after editing (after adding a keepout) a
> footprint on a board in
> > this case:
> > > - select and edit a footprint (Ctrl+E) in fp editor: just add
> a keepout, and save it on
> > the board.
> > > - then reselect and edit this footprint a second time in fp
> editor: Pcbnew crashes.
> > >
> > > Other issues in fp editor:
> > > - modifying a keepout cannot be undone.
> > > - The keepout layers are no selectable: I am thinking the
> options: Top layer, bottom layer and
> > > internal layers (existing in the first version) is really
> better.
> > > Just this is the way these layers are managed in board editor
> and stored in file that was
> > not good
> > > (especially when a board has only 2 layers: the internal
> layers setting was lost).
> > >
> > > As a side effect: the look of the keepout layer dialog is not
> very good after resized:
> > > - Create a keepout on a board: the dialog shows the layers
> list.
> > > - After that, create a keepout in the fpeditor: the layers
> list is not shown, but its area
> > exists,
> > > and the look of the dialog is not good.
> > >
> > >
> > > --
> > > Jean-Pierre CHARRAS
> > >
> > >
> >
> >
> > --
> > 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

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

[Oliver Walters]

Wayne,

Please find attached an updated patch set which also fixes 3D model units
for the STEP exporter tool.



On Thu, Nov 23, 2017 at 1:59 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Consistency.  Currently we have two separate units in kicad board and
> footprint files.  This change unifies that issue.  I know it's annoying
> but it is a decision that I made to make the file formatting more
> consistent.  Yes, it is a change that will break some users 3D models
> but I think the long term benefit outweighs the short term annoyance.
>
> On 11/22/2017 09:51 AM, José Ignacio wrote:
> > I have several footprints that use manufacturer's models, where offsets
> > and rotations are necessary. I really fail to see the point of breaking
> > people's designs and libraries needlessly.
> >
> > On Nov 22, 2017 7:07 AM, "Wayne Stambaugh" <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > What is wrong with just reading the footprint in mm rather than
> > converting from decimils from now on?  It's only going to be a one
> time
> > issue when a user adds a footprint that has not been converted to mm
> to
> > a board.
> >
> > On 11/22/2017 06:16 AM, Oliver Walters wrote:
> > > Wayne,
> > >
> > >
> > > I believe he has a point. The footprint files do not have version
> > > information so if you load and save a footprint multiple times, the
> > > "offset" (if non zero) will continuously be multiplied by 2.54x
> > >
> > > I think there are two ways forward:
> > >
> > > 1. Revert my patch and live with the file format unit inconsistency
> > > 2. I can provide a patch for my original idea of writing "offset"
> > > instead of "at". We make a clean break and "at" is legacy and
> always
> > > read as inches. "offset" is new and is mm.
> > >
> > > Let me know what you want to do.
> > >
> > > Thanks,
> > > Oliver
> > >
> > > On Wed, Nov 22, 2017 at 8:25 PM, easyw <ea...@katamail.com
> > <mailto:ea...@katamail.com>
> > > <mailto:ea...@katamail.com <mailto:ea...@katamail.com>>> wrote:
> > >
> > > Hi Wayne,
> > >
> > > I'm not sure I understand what the issue is.  Once an
> > offset is
> > > changed
> > > to mm when either a footprint in a board or a library is
> > parsed, why
> > > would it not be saved as mm.  If it isn't, then this is a
> > bug.
> > > Once the
> > > footprint offset is converted to mm, there should be no
> > > expectation that
> > > it will be correct for older versions of KiCad.  Is there
> > > something else
> > > at play here?
> > >
> > >
> > > this issue is related to the footprint editor...
> > >
> > > 1) The fp exporter button exports correctly the footprint with
> > > offset in mm
> > > 2) The fp importer button imports always reading the data as
> > > deci-mils and multiplies it internally
> > > 3) To fix this issue the patch needs to manage the footprint
> > > importer code to read the values in mm instead of deci-mils.
> > >
> > > What if you open the same file again, how can it tell it's
> > in mm
> > > or inches?
> > >
> > > @Jose ... this is an issue already addressed...
> > > The decision to change offset values to mm will break previous
> > > footprints that have non zero offset.
> > > But I think this has been considered a 'small' disturb for
> users
> > > when the patch has been committed, as stated in a previous
> mail:
> > >
> > > This is not a big issue because the only effects the
> > footprints
> > > embedded
> > > in the board.  Users with custom footprint libraries that
> > contain 3D
> > > model offsets will just have to fix the offsets.  I'm
> guessing
> > > this is a
> > > fairly small number of users.
> > >
> > > https://lists.launchpad.net/kicad-developers/msg315

Re: [Kicad-developers] Tweaks to about dialog

[Oliver Walters]

>
> I'm not opposed to a
> contributors list on the website although I personally am not terribly
> interested in maintaining this list.
>

And yet we have an outdated list _compiled into a binary_ which does not
reflect the great contributions made by the new 3D modelling team. I am not
suggesting that we add everyone (quite the opposite), but just offload this
to somewhere it can be updated without recompiling KiCad.

In any case, please find attached an updated patch which only fixes the
links on the first tab, removing the outdated smisoto links.


On Sun, Nov 26, 2017 at 2:20 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> On 11/24/2017 04:01 PM, Oliver Walters wrote:
> > Can we have a link to a page on the website where we have a long form
> > list? Updating a binary file with a fluid list of contributors seems
> hokey.
>
> I know it's a bit dated but I think having credits in the application is
> a nice reward for folks who have contributed.  I'm not opposed to a
> contributors list on the website although I personally am not terribly
> interested in maintaining this list.
>
> >
> > The 3D models for example are now script generated using Maurice's tools
> > but contributed by various people.
> >
> > On 25 Nov 2017 06:37, "Simon Wells" <swel...@gmail.com
> > <mailto:swel...@gmail.com>> wrote:
> >
> > Well if you want to keep that panel it should represent all those
> > people who have provided artistry to kicad, as such for those non
> > programmers maybe there needs to be a script or similar that someone
> > can just put their name in and it will spit out a patch that can be
> > submitted to the mailing list
> >
> >
> >
> > > On 25/11/2017, at 3:44 AM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> > >
> > > Oliver,
> > >
> > > I would rather not remove the artists panel from the about
> dialog.  I
> > > know some of those folks haven't contributed recently but many of
> them
> > > contributed a lot of bitmaps and icons over the years so they
> deserve
> > > credit for the efforts.  The remaining changes are fine.
> > >
> > > Cheers,
> > >
> > > Wayne
> > >
> > > On 11/23/2017 08:31 AM, Oliver Walters wrote:
> > >> As mentioned in previous thread, I have made some slight changes
> > to the
> > >> About dialog.
> > >>
> > >> 1. Wording / link tweaks
> > >> 2. Removed references to outdated links (now better served from
> the
> > >> kicad-pcb.org <http://kicad-pcb.org> <http://kicad-pcb.org> site)
> > >> 3. Removed "artists" tab - very outdated, 3D models are now
> community
> > >> contributed
> > >>
> > >> I have also added myself as a developer credit - if this is an
> > >> acceptable indulgence.
> > >>
> > >> Patch attached.
> > >>
> > >> Regards,
> > >>
> > >>
> > >> ___
> > >> 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
> > <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
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad

Re: [Kicad-developers] emails in about box

[Oliver Walters]

+1

On 25 Nov 2017 16:15, "Chris Pavlina"  wrote:

> Hi,
>
> Can we please have a (hopefully short) discussion on the presence of
> developer email addresses in the About box? I don't want or need mine
> there. People can find it if they really want to, but I see no need to
> advertise myself in the about box as if I'm inviting people to contact
> me personally. I don't want them to.
>
> I'd remove it myself, but I didn't put it there either, so I'm sure
> it'll find its way back if we don't address this.
>
> --
> Chris
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
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] Tweaks to about dialog

[Oliver Walters]

Can we have a link to a page on the website where we have a long form list?
Updating a binary file with a fluid list of contributors seems hokey.

The 3D models for example are now script generated using Maurice's tools
but contributed by various people.

On 25 Nov 2017 06:37, "Simon Wells" <swel...@gmail.com> wrote:

Well if you want to keep that panel it should represent all those people
who have provided artistry to kicad, as such for those non programmers
maybe there needs to be a script or similar that someone can just put their
name in and it will spit out a patch that can be submitted to the mailing
list



> On 25/11/2017, at 3:44 AM, Wayne Stambaugh <stambau...@gmail.com> wrote:
>
> Oliver,
>
> I would rather not remove the artists panel from the about dialog.  I
> know some of those folks haven't contributed recently but many of them
> contributed a lot of bitmaps and icons over the years so they deserve
> credit for the efforts.  The remaining changes are fine.
>
> Cheers,
>
> Wayne
>
> On 11/23/2017 08:31 AM, Oliver Walters wrote:
>> As mentioned in previous thread, I have made some slight changes to the
>> About dialog.
>>
>> 1. Wording / link tweaks
>> 2. Removed references to outdated links (now better served from the
>> kicad-pcb.org <http://kicad-pcb.org> site)
>> 3. Removed "artists" tab - very outdated, 3D models are now community
>> contributed
>>
>> I have also added myself as a developer credit - if this is an
>> acceptable indulgence.
>>
>> Patch attached.
>>
>> Regards,
>>
>>
>> ___
>> 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] Tweaks to about dialog

[Oliver Walters]

As mentioned in previous thread, I have made some slight changes to the
About dialog.

1. Wording / link tweaks
2. Removed references to outdated links (now better served from the
kicad-pcb.org site)
3. Removed "artists" tab - very outdated, 3D models are now community
contributed

I have also added myself as a developer credit - if this is an acceptable
indulgence.

Patch attached.

Regards,
From 500378b90d8f91ab25c4a0e1bcbc4e6910f6c6a9 Mon Sep 17 00:00:00 2001
From: Oliver 
Date: Fri, 24 Nov 2017 00:29:30 +1100
Subject: [PATCH] Slight tweaks to About dialog

- Small wording improvements
- Hyperlinks now show URL
- Remove "artists" tab
- Remove links to outdated library sources
- Added myself as developer credit
---
 common/dialog_about/AboutDialog_main.cpp | 46 +++-
 common/dialog_about/dialog_about.cpp |  2 +-
 2 files changed, 17 insertions(+), 31 deletions(-)

diff --git a/common/dialog_about/AboutDialog_main.cpp b/common/dialog_about/AboutDialog_main.cpp
index e23d17c..4929b76 100644
--- a/common/dialog_about/AboutDialog_main.cpp
+++ b/common/dialog_about/AboutDialog_main.cpp
@@ -117,7 +117,7 @@ static void buildKicadAboutBanner( EDA_BASE_FRAME* aParent, ABOUT_APP_INFO& aInf
 
 description << wxT( "" )
 << _( "The KiCad EDA Suite is a set of open source applications for the "
-  "creation of electronic schematics and to design printed circuit boards." )
+  "creation of electronic schematics and printed circuit boards." )
 << wxT( "" );
 
 description << wxT( "" );
@@ -130,34 +130,17 @@ static void buildKicadAboutBanner( EDA_BASE_FRAME* aParent, ABOUT_APP_INFO& aInf
 // bullet-ed list with some http links
 description << wxT( "" );
 description << wxT( "" )
-<< HtmlHyperlink( wxT( "http://www.kicad-pcb.org; ),
-  _( "The official KiCad website" ) )
+<< wxT( "The official KiCad website - " )
+<< HtmlHyperlink( "http://www.kicad-pcb.org; )
 << wxT( "" );
 description << wxT( "" )
-<< HtmlHyperlink( wxT( "https://launchpad.net/kicad; ),
-  _( "Developer's website on Launchpad" ) )
+<< wxT( "Developer website on Launchpad - " )
+<< HtmlHyperlink( "https://launchpad.net/kicad; )
 << wxT("" );
 
 description << wxT( "" )
-<< HtmlHyperlink( wxT( "https://github.com/KiCad/; ),
-  _( "Official repository for component and footprint libraries" ) )
-<< wxT( "" );
-
-description << wxT( "" )
-<< HtmlHyperlink( wxT( "https://github.com/KiCad/Footprint_Wizards; ),
-  _( "Footprint wizards info on our official repository" ) )
-<< wxT( "" );
-description << wxT( "" );
-
-description << wxT( "" )
-<< _( "Non official repositories" )
-<< wxT( "" );
-
-description << wxT( "" );
-
-description << wxT( "" )
-<< HtmlHyperlink( wxT( "http://smisioto.no-ip.org/elettronica/kicad/kicad-en.htm; ),
-  _( "Additional component libraries repository (smisioto)" ) )
+<< wxT( "Official KiCad library repositories - " )
+<< HtmlHyperlink( "https://github.com/KiCad/; )
 << wxT( "" );
 
 description << wxT( "" );
@@ -169,8 +152,9 @@ static void buildKicadAboutBanner( EDA_BASE_FRAME* aParent, ABOUT_APP_INFO& aInf
 // bullet-ed list with some http links
 description << wxT( "" );
 description << wxT( "" )
-<< HtmlHyperlink( wxT( "https://bugs.launchpad.net/kicad/+bugs?orderby=-id=0; ),
-  _( "Report or examine bugs" ) )
+<< wxT( "Report or examine bugs - " )
+<< HtmlHyperlink( "https://bugs.launchpad.net/kicad/+bugs?orderby=-id=0;,
+  "https://bugs.launchpad.net/kicad; )
 << wxT( "" );
 description << wxT( "" );
 
@@ -180,13 +164,13 @@ static void buildKicadAboutBanner( EDA_BASE_FRAME* aParent, ABOUT_APP_INFO& aInf
 
 description << wxT( "" );
 description << wxT( "" )
-<< HtmlHyperlink( wxT( "https://groups.yahoo.com/neo/groups/kicad-users/info; ),
-  _( "KiCad user's group" ) )
+<< wxT( "KiCad forum - " )
+<< HtmlHyperlink( wxT( "https://forum.kicad.info; ) )
 << wxT( "" );
 
 description << wxT( "" )
-<< HtmlHyperlink( wxT( "https://forum.kicad.info; ),
-  _( "KiCad forum" ) )
+<< wxT( "KiCad user's group - " )
+<< HtmlHyperlink( "https://groups.yahoo.com/neo/groups/kicad-users/info; )
 

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

[Oliver Walters]

JP, Wayne,

I have implemented JP's suggestion to write "at" if offset is zero
(default) as patch 0002 attached.

Wayne, you can choose to apply 0002 if you like this idea.

On Thu, Nov 23, 2017 at 9:35 PM, jp charras <jp.char...@wanadoo.fr> wrote:

> Le 23/11/2017 à 11:25, Oliver Walters a écrit :
> > Orson, Wayne,
> >
> > I would agree. Please find attached a patch that implements "offset"
>
> Hi Oliver,
> Because all our footprints in libraries have the "offset" set to O,O,O,
> (the default value) if could
> be worth to export the offset only if it is not 0,0,0
>
> This is an easy way to keep footprint libraries readable be the stable
> version.
>
> >
> > On Thu, Nov 23, 2017 at 7:05 PM, Maciej Sumiński <
> maciej.sumin...@cern.ch
> > <mailto:maciej.sumin...@cern.ch>> wrote:
> >
> > I think the master branch already has enough new features to make its
> > output incompatible with v4. 'Offset' approach seems the easiest and
> > cleanest solution IMHO.
> >
> > Cheers,
> > Orson
> >
>
>
> --
> 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
>
From 52d080dda4419ea4f554666f73db93a839bc4c56 Mon Sep 17 00:00:00 2001
From: Oliver <oliver.henry.walt...@gmail.com>
Date: Thu, 23 Nov 2017 23:14:59 +1100
Subject: [PATCH 2/2] Write "at" if offset is (0, 0, 0)

- If non-zero offset, write "offset" instead
---
 pcbnew/kicad_plugin.cpp | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/pcbnew/kicad_plugin.cpp b/pcbnew/kicad_plugin.cpp
index 2c75f27..d619a78 100644
--- a/pcbnew/kicad_plugin.cpp
+++ b/pcbnew/kicad_plugin.cpp
@@ -1142,8 +1142,20 @@ void PCB_IO::format( MODULE* aModule, int aNestLevel ) const
 
 /* Write 3D model offset in mm
  * 4.0.x wrote "at" which was actually in inches
+ * To preserve files, "at" will be written for zero values
+ * If a non-zero offset is provided, it is written using "offset"
  */
-m_out->Print( aNestLevel+2, "(offset (xyz %s %s %s))\n",
+wxString tag = "at";
+
+if( ( fabs( bs3D->m_Offset.x ) > 0.0f ) ||
+( fabs( bs3D->m_Offset.y ) > 0.0f ) ||
+( fabs( bs3D->m_Offset.z ) > 0.0f ) )
+{
+tag = "offset";
+}
+
+m_out->Print( aNestLevel+2, "(%s (xyz %s %s %s))\n",
+  tag.ToStdString().c_str(),
   Double2Str( bs3D->m_Offset.x ).c_str(),
   Double2Str( bs3D->m_Offset.y ).c_str(),
   Double2Str( bs3D->m_Offset.z ).c_str() );
-- 
2.7.4

From 476e6350fb8bd04fc9275038fa403823cc15c78e Mon Sep 17 00:00:00 2001
From: Oliver <oliver.henry.walt...@gmail.com>
Date: Thu, 23 Nov 2017 21:21:48 +1100
Subject: [PATCH 1/2] CHANGE file format for 3D model offset

- Reverts behaviour of 3e71ed2421f5df433c11a554e0756f6898e25b06
- 3D model offset now explicitly written in mm, using "offset" tag
- Any read "at" tag is converted from inches to mm
- This will not break any 3D model offset when reading files
- It will however render files incompatible with old versions
---
 pcbnew/kicad_plugin.cpp |  6 --
 pcbnew/kicad_plugin.h   |  3 ++-
 pcbnew/pcb_parser.cpp   | 35 ---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/pcbnew/kicad_plugin.cpp b/pcbnew/kicad_plugin.cpp
index c4477ad..2c75f27 100644
--- a/pcbnew/kicad_plugin.cpp
+++ b/pcbnew/kicad_plugin.cpp
@@ -1140,8 +1140,10 @@ void PCB_IO::format( MODULE* aModule, int aNestLevel ) const
 m_out->Print( aNestLevel+1, "(model %s\n",
   m_out->Quotew( bs3D->m_Filename ).c_str() );
 
-// Model offset is in mm
-m_out->Print( aNestLevel+2, "(at (xyz %s %s %s))\n",
+/* Write 3D model offset in mm
+ * 4.0.x wrote "at" which was actually in inches
+ */
+m_out->Print( aNestLevel+2, "(offset (xyz %s %s %s))\n",
   Double2Str( bs3D->m_Offset.x ).c_str(),
   Double2Str( bs3D->m_Offset.y ).c_str(),
   Double2Str( bs3D->m_Offset.z ).c_str() );
diff --git a/pcbnew/kicad_plugin.h b/pcbnew/kicad_plugin.h
index 87dc736..7423b4f 100644
--- a/pcbnew/kicad_plugin.h
+++ b/pcbnew/kic

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

[Oliver Walters]

Orson, Wayne,

I would agree. Please find attached a patch that implements "offset"

On Thu, Nov 23, 2017 at 7:05 PM, Maciej Sumiński <maciej.sumin...@cern.ch>
wrote:

> I think the master branch already has enough new features to make its
> output incompatible with v4. 'Offset' approach seems the easiest and
> cleanest solution IMHO.
>
> Cheers,
> Orson
>
> On 11/22/2017 11:16 PM, Oliver Walters wrote:
> > I understand this will break "forwards compatibility" if opening a v5
> file
> > from v4. Sometimes such changes are unavoidable.
> >
> > On Thu, Nov 23, 2017 at 8:44 AM, easyw <ea...@katamail.com> wrote:
> >
> >> This option is in fact a smooth transition for footprints...
> >> but it will break the readability of new boards by previous release of
> >> kicad... no way back to previous releases, even to be just read...
> >> Which is better then?
> >> Library stuff are quite delicate to be touched IMO...
> >>
> >> On 11/22/2017 10:23 PM, Oliver Walters wrote:
> >>
> >>> Wayne I still have an issue with silently breaking files. Using an
> >>> "offset" parameter (but reading "at" for compatibility) does not break
> >>> anyone's models and there is absolutely no confusion about which is mm
> and
> >>> which is inches. Incidentally I think "offset" is a better name, it
> implies
> >>> relative position rather than absolute (but that's neither here nor
> there).
> >>>
> >>> On Thu, Nov 23, 2017 at 7:55 AM, Marcos Chaparro <nitrous...@gmail.com
> >>> <mailto:nitrous...@gmail.com>> wrote:
> >>>
> >>> On Wed, Nov 22, 2017 at 11:59 AM, Wayne Stambaugh
> >>> <stambau...@gmail.com <mailto:stambau...@gmail.com>> wrote:
> >>>
> >>> Yes, it is a change that will break some users 3D models
> >>> but I think the long term benefit outweighs the short term
> >>> annoyance.
> >>>
> >>>
> >>> It will break most of my boards. I won't complain because I
> >>> appreciate the effort and I welcome *every* improvement, but be
> >>> prepared for some very rough comments out there.
> >>>
> >>> ___
> >>> 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
> >
>
>
>
> ___
> 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
>
>
From 0f3df37e066034c8f4dbe760ee8966730ade2b19 Mon Sep 17 00:00:00 2001
From: Oliver <oliver.henry.walt...@gmail.com>
Date: Thu, 23 Nov 2017 21:21:48 +1100
Subject: [PATCH] CHANGE file format for 3D model offset

- Reverts behaviour of 3e71ed2421f5df433c11a554e0756f6898e25b06
- 3D model offset now explicitly written in mm, using "offset" tag
- Any read "at"

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

[Oliver Walters]

I understand this will break "forwards compatibility" if opening a v5 file
from v4. Sometimes such changes are unavoidable.

On Thu, Nov 23, 2017 at 8:44 AM, easyw <ea...@katamail.com> wrote:

> This option is in fact a smooth transition for footprints...
> but it will break the readability of new boards by previous release of
> kicad... no way back to previous releases, even to be just read...
> Which is better then?
> Library stuff are quite delicate to be touched IMO...
>
> On 11/22/2017 10:23 PM, Oliver Walters wrote:
>
>> Wayne I still have an issue with silently breaking files. Using an
>> "offset" parameter (but reading "at" for compatibility) does not break
>> anyone's models and there is absolutely no confusion about which is mm and
>> which is inches. Incidentally I think "offset" is a better name, it implies
>> relative position rather than absolute (but that's neither here nor there).
>>
>> On Thu, Nov 23, 2017 at 7:55 AM, Marcos Chaparro <nitrous...@gmail.com
>> <mailto:nitrous...@gmail.com>> wrote:
>>
>> On Wed, Nov 22, 2017 at 11:59 AM, Wayne Stambaugh
>> <stambau...@gmail.com <mailto:stambau...@gmail.com>> wrote:
>>
>> Yes, it is a change that will break some users 3D models
>> but I think the long term benefit outweighs the short term
>> annoyance.
>>
>>
>> It will break most of my boards. I won't complain because I
>> appreciate the effort and I welcome *every* improvement, but be
>> prepared for some very rough comments out there.
>>
>> ___
>> 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] [PATCH] Fix for 3D model offset

[Oliver Walters]

Wayne I still have an issue with silently breaking files. Using an "offset"
parameter (but reading "at" for compatibility) does not break anyone's
models and there is absolutely no confusion about which is mm and which is
inches. Incidentally I think "offset" is a better name, it implies relative
position rather than absolute (but that's neither here nor there).

On Thu, Nov 23, 2017 at 7:55 AM, Marcos Chaparro 
wrote:

> On Wed, Nov 22, 2017 at 11:59 AM, Wayne Stambaugh 
> wrote:
>
>> Yes, it is a change that will break some users 3D models
>> but I think the long term benefit outweighs the short term annoyance.
>
>
> It will break most of my boards. I won't complain because I appreciate the
> effort and I welcome *every* improvement, but be prepared for some very
> rough comments out there.
>
> ___
> 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] terms clarification

[Oliver Walters]

+1 for "symbol" and "footprint"

On Thu, Nov 23, 2017 at 12:28 AM, Marco Ciampa  wrote:

> On Wed, Nov 22, 2017 at 08:14:02AM -0500, Wayne Stambaugh wrote:
> > The devs discussed this some time ago and the general consensus is that
> > symbol is the preferred term.  I've already started converting the UI
> > strings to use the term symbol.  I'm sure there are UI strings that I
> > missed.  If you find them, please let me know so I can correct them.
> >
>
> I think that then there is some term confusion here ...
>
> #: eeschema/menubar.cpp:462
> msgid ""
> "Edit components to symbols library links to switch to an other library
> link "
> "(library IDs)"
>
> This obviously is not "symbol to symbol link" ...
>
> I really think that we should stick with the terms "footprint" and
> "symbol" only, and get rid of all the "component", "part", "module" and
> such altogether...
>
> TIA
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> 
>
>
> ___
> 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] Library Editor refactor

[Oliver Walters]

> Regarding the window title, I consider library selected after opening a
> part. Do you suggest that highlighting a library (single click) in the
> component tree should make it selected? I wonder if there is any benefit
> of doing so.
>

Ah I see that it does put the right text into the title bar once the part
is opened. That's good enough for me! Sorry for the noise :)




On Thu, Nov 23, 2017 at 12:19 AM, Maciej Sumiński <maciej.sumin...@cern.ch>
wrote:

> Hi Oliver,
>
> Thank you for the report. It should be fixed already.
>
> Regarding the window title, I consider library selected after opening a
> part. Do you suggest that highlighting a library (single click) in the
> component tree should make it selected? I wonder if there is any benefit
> of doing so.
>
> Cheers,
> Orson
>
> On 11/22/2017 12:34 PM, Oliver Walters wrote:
> > Orson,
> >
> > I have found another potential issue (only a small one!)
> >
> > If you add a new library but then cancel, it triggers an assert on debug
> > builds:
> >
> > To reproduce:
> >
> > 1. Press "Add an existing library"
> > 2. Select a library from the file chooser
> > 3. On the dialog that says "Choose the library table to add the library",
> > press cancel or hit escape
> >
> > Cheers
> >
> > On Wed, Nov 15, 2017 at 3:37 AM, Maciej Sumiński <
> maciej.sumin...@cern.ch>
> > wrote:
> >
> >> The long awaited refactor of the Symbol Library Editor is ready for
> >> testing!
> >>
> >> Changes (yes, it will be included in the commit message):
> >> - Component Tree widget as a user-friendly part selector
> >> - Multiple editor contexts, allowing the user to easily switch between
> >> modified parts
> >> - Cut/Copy/Paste/Duplicate for whole components (also between libraries)
> >> - Reverting unsaved modifications per part or library
> >> - 'Browse' button for Symbol Library Table dialog to add files
> >> - Redone menu and toolbar
> >> - Improved icons to make the user interface more consistent
> >>
> >> I look forward to your feedback. I would like to merge the branch this
> >> week, which would most likely indicate the v5 feature freeze start
> (yay!).
> >>
> >> I have also started to work on copy/paste for individual part items, but
> >> I cannot fully wrap my head around eeschema code. If such feature is
> >> desired and you are willing to help, I can share my desperate trial
> >> patch. I will try to implement it before the branch is merged, otherwise
> >> copy/paste will be postponed to v6.
> >>
> >> Regards,
> >> Orson
> >>
> >> 1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/libedit
> >>
> >>
> >> ___
> >> 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] [Question] - Artist Credits

[Oliver Walters]

Simon,

In that case I think this information should be nixed entirely. It serves
no real purpose to include front-and-center in the about screen. All that
info can be gleaned from the library repositories if users are really
interested.

On Wed, Nov 22, 2017 at 11:36 PM, Simon Wells <swel...@gmail.com> wrote:

> The only way I can see any of that information staying relevant is if it
> is collated at run time from a text file or something in each of the
> individual repos that are used, that way when someone submits a lib they
> can include a name in the text file if they so wish, and then the about
> code could just parse the list and dump that information out.
>
>
>
> > On 22/11/2017, at 11:45 PM, Oliver Walters <oliver.henry.walters@gmail.
> com> wrote:
> >
> > In the "About" dialog, under the "Artists" tab, I note that Christophe
> Boschat and Renie Marquet are credited with creation of the 3D models.
> >
> > I believe this is very outdated information, and there have been a few
> high value contributors of 3D model data in the library repositories.
> >
> > Unless anyone objects, I think this information should be redacted,
> rather than having to play catch up.
> >
> > Additionally, there is a fair bit of outdated info on the "Information"
> tab that could probably just point to the KiCad website...
> >
> > At the very least I would like to update this to remove info about (for
> e.g.) the smisioto libraries.
> >
> > Thoughts? Unless there are any objections I'll issue a patch.
> > ___
> > 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] Add live footprint filtering in modview window

[Oliver Walters]

Wayne,

That's disappointing. Any further debug info you can provide?

On Wed, Nov 22, 2017 at 11:31 PM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Oliver,
>
> I tested your footprint filtering patch set last night and it didn't go
> very well.  The very first letter I typed ('r') in the filter control
> caused kicad to crash so it's not ready just yet.
>
> Cheers,
>
> Wayne
>
> On 11/20/2017 06:57 PM, Oliver Walters wrote:
> > Wayne,
> >
> > Friendly bump in case this has been forgotten - this thread has wandered
> > around a fair bit. Patches 0001 through 0008 are in the email above.
> >
> > Thanks
> >
> > On Fri, Nov 17, 2017 at 11:05 PM, Oliver Walters
> > <oliver.henry.walt...@gmail.com <mailto:oliver.henry.walt...@gmail.com>>
> > wrote:
> >
> > Wayne,
> >
> > Please ignore the previous patch sets. I have made further tweaks
> > and the attached patch set 0001 through 0008 should be considered
> > canonical.
> > .
> > I have fixed a couple of pointer errors, and have also dropped the
> > filter-by-library functionality. It was a bit hooky and I'd rather
> > submit a solid functional set of patches and don't have time to
> > investigate further.
> >
> > I hope that the attached patch set meets your standards and can be
> > merged as-is :)
> >
> > Thanks!
> >
> > On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh
> > <stambau...@gmail.com <mailto:stambau...@gmail.com>> wrote:
> >
> > On 10/31/2017 5:01 PM, Oliver Walters wrote:
> > > How should I proceed here then?
> > >
> > > I would like to see the various libraries being "cached" in the
> > > background, but this is increasing the scope of the work by a
> large factor.
> > >
> > > One thing I have noticed:
> > >
> > > In eeschema when you launch the component viewer, it (on first
> run) maps
> > > and caches all the footprint libraries. This can take AGES
> (especially
> > > on Windows). However on subsequent launches of the component
> viewer it
> > > appears instantly. It appears to be keeping a static map of the
> > > footprint library data.
> > >
> > > a) Would this be an acceptable approach for the footprint
> viewer window
> >
> > Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
> > footprint library code is split out from the component chooser
> so it
> > should be reusable.
> >
> > > b) What happens when the library data changes externally? Does
> component
> > > viewer need to be reloaded?
> >
> > No, only the library that changed gets reloaded the next time
> it's
> > accessed.  It is not automatic.  I thought about using
> > wxFileWatcher but
> > that could be a lot of overhead for little net gain.  See the
> > pcb plugin
> > cache() functions.
> >
> > > c) Can we globally perform this caching in a background thread
> when
> > > KiCad launches? This will hide the large pauses (up to a
> minute under
> > > Windows) from the user...
> >
> > Yes, this should be done as a project element so that it can be
> > accessed
> > from all of the main windows.  Please keep in mind, this could
> > be a lot
> > of work and given that we are nearing a stable 5 release feature
> > freeze,
> > so if it's not by then it will not make it into the stable 5
> > release.
> >
> > >
> > > Oliver
> > >
> > > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > On 10/31/2017 1:25 AM, Oliver Walters wrote:
> > > > Hmm, I had thought that there was a way to load only the
> *names* of
> > > > footprints, rather than individually parsing each
> footprint file. It
> > > > appears that this is not the case. Any suggestions on
> how the speed
> > > > could be improved? Currently I'm reading out all the
> footprint names in
&

Re: [Kicad-developers] Library Editor refactor

[Oliver Walters]

Orson,

I have found another potential issue (only a small one!)

If you add a new library but then cancel, it triggers an assert on debug
builds:

To reproduce:

1. Press "Add an existing library"
2. Select a library from the file chooser
3. On the dialog that says "Choose the library table to add the library",
press cancel or hit escape

Cheers

On Wed, Nov 15, 2017 at 3:37 AM, Maciej Sumiński 
wrote:

> The long awaited refactor of the Symbol Library Editor is ready for
> testing!
>
> Changes (yes, it will be included in the commit message):
> - Component Tree widget as a user-friendly part selector
> - Multiple editor contexts, allowing the user to easily switch between
> modified parts
> - Cut/Copy/Paste/Duplicate for whole components (also between libraries)
> - Reverting unsaved modifications per part or library
> - 'Browse' button for Symbol Library Table dialog to add files
> - Redone menu and toolbar
> - Improved icons to make the user interface more consistent
>
> I look forward to your feedback. I would like to merge the branch this
> week, which would most likely indicate the v5 feature freeze start (yay!).
>
> I have also started to work on copy/paste for individual part items, but
> I cannot fully wrap my head around eeschema code. If such feature is
> desired and you are willing to help, I can share my desperate trial
> patch. I will try to implement it before the branch is merged, otherwise
> copy/paste will be postponed to v6.
>
> Regards,
> Orson
>
> 1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/libedit
>
>
> ___
> 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] Fix for 3D model offset

[Oliver Walters]

Wayne,


I believe he has a point. The footprint files do not have version
information so if you load and save a footprint multiple times, the
"offset" (if non zero) will continuously be multiplied by 2.54x

I think there are two ways forward:

1. Revert my patch and live with the file format unit inconsistency
2. I can provide a patch for my original idea of writing "offset" instead
of "at". We make a clean break and "at" is legacy and always read as
inches. "offset" is new and is mm.

Let me know what you want to do.

Thanks,
Oliver

On Wed, Nov 22, 2017 at 8:25 PM, easyw <ea...@katamail.com> wrote:

> Hi Wayne,
>
>> I'm not sure I understand what the issue is.  Once an offset is changed
>> to mm when either a footprint in a board or a library is parsed, why
>> would it not be saved as mm.  If it isn't, then this is a bug.  Once the
>> footprint offset is converted to mm, there should be no expectation that
>> it will be correct for older versions of KiCad.  Is there something else
>> at play here?
>>
>
> this issue is related to the footprint editor...
>
> 1) The fp exporter button exports correctly the footprint with offset in mm
> 2) The fp importer button imports always reading the data as deci-mils and
> multiplies it internally
> 3) To fix this issue the patch needs to manage the footprint importer code
> to read the values in mm instead of deci-mils.
>
> What if you open the same file again, how can it tell it's in mm or inches?
>>
> @Jose ... this is an issue already addressed...
> The decision to change offset values to mm will break previous footprints
> that have non zero offset.
> But I think this has been considered a 'small' disturb for users when the
> patch has been committed, as stated in a previous mail:
>
>> This is not a big issue because the only effects the footprints embedded
>> in the board.  Users with custom footprint libraries that contain 3D
>> model offsets will just have to fix the offsets.  I'm guessing this is a
>> fairly small number of users.
>>
> https://lists.launchpad.net/kicad-developers/msg31589.html
>
> M
>
>
> On 11/22/2017 2:19 AM, Wayne Stambaugh wrote:
>
>> I'm not sure I understand what the issue is.  Once an offset is changed
>> to mm when either a footprint in a board or a library is parsed, why
>> would it not be saved as mm.  If it isn't, then this is a bug.  Once the
>> footprint offset is converted to mm, there should be no expectation that
>> it will be correct for older versions of KiCad.  Is there something else
>> at play here?
>>
>> On 11/21/2017 04:26 PM, Oliver Walters wrote:
>>
>>> Wayne,
>>>
>>> Not sure how you want to handle this but I feel that making a clean
>>> break and using "offset" for mm solves all the issues associated with
>>> embedded footprints without version info, as Maurice says above. Let me
>>> know if want me to implement.
>>>
>>> On Wed, Nov 22, 2017 at 8:24 AM, easyw <ea...@katamail.com
>>> <mailto:ea...@katamail.com>> wrote:
>>>
>>>  Hi,
>>>  first headache symptom...
>>>
>>>  Testing conditions:
>>>  latest KiCad patched
>>>  Application: pcbnew
>>>  Version: (2017-11-21 revision 8de70f3)-master, release build
>>>
>>>  If you edit a footprint adding 3D models offset and then export it,
>>>  it will be saved with the new mm convention...
>>>  but when re-imported it will be read with deci-mils and displayed
>>>  with wrong convention...
>>>  Moreover if the imported footprint will be inserted into the board,
>>>  the footprint will conserve the wrong values...
>>>  Those wrong values will be then saved with the new kicad_pcb
>>> board
>>>
>>>
> ___
> 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] [Question] - Artist Credits

[Oliver Walters]

In the "About" dialog, under the "Artists" tab, I note that Christophe
Boschat and Renie Marquet are credited with creation of the 3D models.

I believe this is very outdated information, and there have been a few high
value contributors of 3D model data in the library repositories.

Unless anyone objects, I think this information should be redacted, rather
than having to play catch up.

Additionally, there is a fair bit of outdated info on the "Information" tab
that could probably just point to the KiCad website...

At the very least I would like to update this to remove info about (for
e.g.) the smisioto libraries.

Thoughts? Unless there are any objections I'll issue a patch.
___
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] Library Editor refactor

[Oliver Walters]

Orson,

The new symbol editor is looking great!

One small issue I have found:

The window title bar reads "Symbol library editor - no library selected" no
matter which library is currently selected. I think this needs to be
updated to report the currently selected library.

Thanks,

On Wed, Nov 15, 2017 at 3:37 AM, Maciej Sumiński 
wrote:

> The long awaited refactor of the Symbol Library Editor is ready for
> testing!
>
> Changes (yes, it will be included in the commit message):
> - Component Tree widget as a user-friendly part selector
> - Multiple editor contexts, allowing the user to easily switch between
> modified parts
> - Cut/Copy/Paste/Duplicate for whole components (also between libraries)
> - Reverting unsaved modifications per part or library
> - 'Browse' button for Symbol Library Table dialog to add files
> - Redone menu and toolbar
> - Improved icons to make the user interface more consistent
>
> I look forward to your feedback. I would like to merge the branch this
> week, which would most likely indicate the v5 feature freeze start (yay!).
>
> I have also started to work on copy/paste for individual part items, but
> I cannot fully wrap my head around eeschema code. If such feature is
> desired and you are willing to help, I can share my desperate trial
> patch. I will try to implement it before the branch is merged, otherwise
> copy/paste will be postponed to v6.
>
> Regards,
> Orson
>
> 1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/libedit
>
>
> ___
> 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] Fix for 3D model offset

[Oliver Walters]

Wayne,

Not sure how you want to handle this but I feel that making a clean break
and using "offset" for mm solves all the issues associated with embedded
footprints without version info, as Maurice says above. Let me know if want
me to implement.

On Wed, Nov 22, 2017 at 8:24 AM, easyw <ea...@katamail.com> wrote:

> Hi,
> first headache symptom...
>
> Testing conditions:
> latest KiCad patched
> Application: pcbnew
> Version: (2017-11-21 revision 8de70f3)-master, release build
>
> If you edit a footprint adding 3D models offset and then export it, it
> will be saved with the new mm convention...
> but when re-imported it will be read with deci-mils and displayed with
> wrong convention...
> Moreover if the imported footprint will be inserted into the board, the
> footprint will conserve the wrong values...
> Those wrong values will be then saved with the new kicad_pcb board
>
> On 11/15/2017 3:40 PM, Maciej Suminski wrote:
>
>> Hi Maurice,
>>
>> On 15/11/2017 1:21 PM, easyw wrote:
>>
>>> Just a clarification request:
>>>
>>> Kicad Stable has version assigned to 4
>>> Previous stable had version assigned to 3
>>>
>>> I imagine that next stable would have version assigned to 5...
>>> Am I right in supposing the next numbering release?
>>>
>>> If I'm fine, with the proposed patch the new stable release, if assigned
>>> coherently to actual releases numbering, will fail the check that is in
>>> this patch; the new parser will then mess up all 3D offsets each time
>>> the board will be saved/displayed...
>>>
>>> +if(m_requiredVersion < 20171114UL)
>>>>
>>>
>> I think you write this assuming the v5 file format will have
>> m_requiredVersion set to 5. If I recall correctly, we have decided to use
>> dates for file versioning and this method will be kept for v5 and later
>> versions, so we should be safe here.
>>
>> As I already stated the actual situation has no problem in displaying
>>> the correct offset in 3D viewer and the exporters are fine...
>>> The only 'issue', if we can say this is an issue, is that the offset is
>>> assigned to deci-mils and not millimeters inside the footprint...
>>>
>>> This is going to open big headaches for which enhancement?
>>> My 2 cents
>>>
>>
>> The solution Oliver has proposed looks solid to me, I do not see any
>> potential headache. The patch has a very noble goal of fixing one of the
>> biggest KiCad sins - incoherence. I think the reason is good enough to
>> commit the patch.
>>
>> Regards,
>> Orson
>>
>> Maurice
>>>
>>>
>>>
>>> On 11/14/2017 10:55 AM, Oliver Walters wrote:
>>>
>>>> Wayne,
>>>>
>>>> Please find attached updated patch set. If an old version is detected,
>>>> inches are converted to mm.
>>>>
>>>>
>>> ___
>>> 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] LIB_TABLE tweaks

[Oliver Walters]

Fantastic! Thanks very much Wayne

On 22 Nov 2017 01:17, "Wayne Stambaugh" <stambau...@gmail.com> wrote:

> Yeah!!  I finally got this merged.  Thank you Oliver for your
> contribution to KiCad and for your patience.
>
> Cheers,
>
> Wayne
>
> On 11/21/2017 12:51 AM, Oliver Walters wrote:
> > Wayne,
> >
> > I have recreated the patch set once again, and there is no reference to
> > "printf" in any of these patch files.
> >
> > Please apply with the --ignore-whitepace flag, the file
> > /include/lib_table_grid.h is full of MS-DOS line endings and I believe
> > this is the cause.
> >
> > Patch set attached, hopefully works this time!
> >
> > Thanks,
> > Oliver
> >
> > On Tue, Nov 21, 2017 at 10:02 AM, Oliver Walters
> > <oliver.henry.walt...@gmail.com <mailto:oliver.henry.walt...@gmail.com>>
> > wrote:
> >
> > Wayne,
> >
> > Ok, apologies I thought I had addressed that (I haven't had a chance
> > to go back and look at these patches). I'll do so tonight.
> >
> > On Tue, Nov 21, 2017 at 10:00 AM, Wayne Stambaugh
> > <stambau...@gmail.com <mailto:stambau...@gmail.com>> wrote:
> >
> > I looked at patches 3-6 and I didn't see where the printf was
> > removed.
> >
> > On 11/20/2017 05:47 PM, Oliver Walters wrote:
> > > The printf() statement should be removed in one of the
> subsequent
> > > patches, as should the removal of that line. I'm unable to
> check this
> > > right now, are you able to confirm if one of the later patches
> fixes
> > > this problem?
> > >
> > > On Tue, Nov 21, 2017 at 9:44 AM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > I made a change to fix a bug with the default plugin type
> when appending
> > > a new row to the table which caused the conflict.  This
> where I noticed
> >     > the printf() debugging statement.  I also noticed that it
> appears that
> > > you removed a scroll to row call and I'm not sure how to
> reconcile the
> > > conflict.  Did you remove the scroll to row call on
> purpose or wasn't it
> > > necessary.  I don't want to break that behavior.
> > >
> > > On 11/20/2017 04:29 PM, Oliver Walters wrote:
> > > > Wayne,
> > > >
> > > > I think it is a whitespace issue, does it apply if you
> add
> > > > --ignore-whitespace to git-am ?
> > > >
> > > > On Tue, Nov 21, 2017 at 1:03 AM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>
> > > > <mailto:stambau...@gmail.com  stambau...@gmail.com>
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>>
> wrote:
> > > >
> > > > Oliver,
> > > >
> > > > No go yet again.  It looks like my commit 8b2b1381
> is causing a conflict
> > > > with patch 2 so please rebase your patches.  I also
> noticed a printf()
> > > > debugging statement in patch 2.  Please remove this
> and make sure there
> > > > are not any other printf() statements in your
> patches.  Sorry about
> > > > asking you to fix these issues but I really don't
> have the time to fix
> > > > patches right now.
> > > >
> > > > Cheers,
> > > >
> > > > Wayne
> > > >
> > > > On 11/20/2017 1:20 AM, Oliver Walters wrote:
> > > > > Wayne,
> > > > >
> > > > > I'm at a loss too. git am fails on 0002 but git
> apply works fine on each
> > > > > individual patch.
> > > > >
> > > > > On Mon, Nov 20, 2017 at 3:29 AM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@

Re: [Kicad-developers] [PATCH] LIB_TABLE tweaks

[Oliver Walters]

Wayne,

I have recreated the patch set once again, and there is no reference to
"printf" in any of these patch files.

Please apply with the --ignore-whitepace flag, the file
/include/lib_table_grid.h is full of MS-DOS line endings and I believe this
is the cause.

Patch set attached, hopefully works this time!

Thanks,
Oliver

On Tue, Nov 21, 2017 at 10:02 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Wayne,
>
> Ok, apologies I thought I had addressed that (I haven't had a chance to go
> back and look at these patches). I'll do so tonight.
>
> On Tue, Nov 21, 2017 at 10:00 AM, Wayne Stambaugh <stambau...@gmail.com>
> wrote:
>
>> I looked at patches 3-6 and I didn't see where the printf was removed.
>>
>> On 11/20/2017 05:47 PM, Oliver Walters wrote:
>> > The printf() statement should be removed in one of the subsequent
>> > patches, as should the removal of that line. I'm unable to check this
>> > right now, are you able to confirm if one of the later patches fixes
>> > this problem?
>> >
>> > On Tue, Nov 21, 2017 at 9:44 AM, Wayne Stambaugh <stambau...@gmail.com
>> > <mailto:stambau...@gmail.com>> wrote:
>> >
>> > I made a change to fix a bug with the default plugin type when
>> appending
>> > a new row to the table which caused the conflict.  This where I
>> noticed
>> > the printf() debugging statement.  I also noticed that it appears
>> that
>> > you removed a scroll to row call and I'm not sure how to reconcile
>> the
>> > conflict.  Did you remove the scroll to row call on purpose or
>> wasn't it
>> > necessary.  I don't want to break that behavior.
>> >
>> > On 11/20/2017 04:29 PM, Oliver Walters wrote:
>> > > Wayne,
>> > >
>> > > I think it is a whitespace issue, does it apply if you add
>> > > --ignore-whitespace to git-am ?
>> > >
>> > > On Tue, Nov 21, 2017 at 1:03 AM, Wayne Stambaugh <
>> stambau...@gmail.com <mailto:stambau...@gmail.com>
>> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
>> wrote:
>> > >
>> > > Oliver,
>> > >
>> > > No go yet again.  It looks like my commit 8b2b1381 is causing
>> a conflict
>> > > with patch 2 so please rebase your patches.  I also noticed a
>> printf()
>> > > debugging statement in patch 2.  Please remove this and make
>> sure there
>> > > are not any other printf() statements in your patches.  Sorry
>> about
>> > > asking you to fix these issues but I really don't have the
>> time to fix
>> > > patches right now.
>> > >
>> > > Cheers,
>> > >
>> > > Wayne
>> > >
>> > > On 11/20/2017 1:20 AM, Oliver Walters wrote:
>> > > > Wayne,
>> > > >
>> > > > I'm at a loss too. git am fails on 0002 but git apply works
>> fine on each
>> > > > individual patch.
>> > > >
>> > > > On Mon, Nov 20, 2017 at 3:29 AM, Wayne Stambaugh <
>> stambau...@gmail.com <mailto:stambau...@gmail.com>
>> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>
>> > > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>
>> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>>
>> wrote:
>> > > >
>> > > > Oliver,
>> > > >
>> > > > Still no luck.  Did you possible do something to mess
>> up the
>> > > commit
>> > > > ordering?  I am applying these patches on top a clean
>> master
>> > > branch so
>> > > > I'm not sure what is going on here.  I'm getting the
>> > following
>> > > error
>> > > > from `git am` when I attempt to merge patch 2:
>> > > >
>> > > > Applying: Toggle LIB_TABLE_ROW enabled/disabled in grid
>> > editor
>> > > > error: patch failed:
>> > eeschema/dialogs/dialog_sym_lib_table.cpp:350
>> > > > error: eeschema/dialogs/dialog_sym_lib_table.cpp:
>> pat

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

[Oliver Walters]

Wayne,

Friendly bump in case this has been forgotten - this thread has wandered
around a fair bit. Patches 0001 through 0008 are in the email above.

Thanks

On Fri, Nov 17, 2017 at 11:05 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Wayne,
>
> Please ignore the previous patch sets. I have made further tweaks and the
> attached patch set 0001 through 0008 should be considered canonical.
> .
> I have fixed a couple of pointer errors, and have also dropped the
> filter-by-library functionality. It was a bit hooky and I'd rather submit a
> solid functional set of patches and don't have time to investigate further.
>
> I hope that the attached patch set meets your standards and can be merged
> as-is :)
>
> Thanks!
>
> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh <stambau...@gmail.com>
> wrote:
>
>> On 10/31/2017 5:01 PM, Oliver Walters wrote:
>> > How should I proceed here then?
>> >
>> > I would like to see the various libraries being "cached" in the
>> > background, but this is increasing the scope of the work by a large
>> factor.
>> >
>> > One thing I have noticed:
>> >
>> > In eeschema when you launch the component viewer, it (on first run) maps
>> > and caches all the footprint libraries. This can take AGES (especially
>> > on Windows). However on subsequent launches of the component viewer it
>> > appears instantly. It appears to be keeping a static map of the
>> > footprint library data.
>> >
>> > a) Would this be an acceptable approach for the footprint viewer window
>>
>> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
>> footprint library code is split out from the component chooser so it
>> should be reusable.
>>
>> > b) What happens when the library data changes externally? Does component
>> > viewer need to be reloaded?
>>
>> No, only the library that changed gets reloaded the next time it's
>> accessed.  It is not automatic.  I thought about using wxFileWatcher but
>> that could be a lot of overhead for little net gain.  See the pcb plugin
>> cache() functions.
>>
>> > c) Can we globally perform this caching in a background thread when
>> > KiCad launches? This will hide the large pauses (up to a minute under
>> > Windows) from the user...
>>
>> Yes, this should be done as a project element so that it can be accessed
>> from all of the main windows.  Please keep in mind, this could be a lot
>> of work and given that we are nearing a stable 5 release feature freeze,
>> so if it's not by then it will not make it into the stable 5 release.
>>
>> >
>> > Oliver
>> >
>> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <stambau...@gmail.com
>> > <mailto:stambau...@gmail.com>> wrote:
>> >
>> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
>> > > Hmm, I had thought that there was a way to load only the *names*
>> of
>> > > footprints, rather than individually parsing each footprint file.
>> It
>> > > appears that this is not the case. Any suggestions on how the
>> speed
>> > > could be improved? Currently I'm reading out all the footprint
>> names in
>> > > each footprint library and only storing the names (wxString)
>> rather than
>> > > the MODULE* objects. However, I still have to parse the entire
>> library
>> > > on load.
>> > >
>> > > Ideally, I think it would be good to just read in the names, and
>> then
>> > > load and display individual MODULE objects on demand.. Is this
>> possible?
>> >
>> > This is possible (although not implemented) for library types
>> (kicad,
>> > geda) that use one file per footprint.  You could just read the file
>> > names from the folder and load the files as required.  If you want
>> to
>> > search any other properties of the footprint, then you will have to
>> load
>> > all of the footprints anyway.  I don't know if this would be worth
>> the
>> > effort.
>> >
>> > For library types that contain multiple footprints per file (legacy,
>> > Eagle), this wouldn't make much sense.  Parsing the entire file
>> just to
>> > pick out the footprint names probably isn't going to save you very
>> much
>> > time.
>> >
>> > >
>> > > On Tue, Oct 31, 2017 at 10:40 

Re: [Kicad-developers] [PATCH] LIB_TABLE tweaks

[Oliver Walters]

Wayne,

Ok, apologies I thought I had addressed that (I haven't had a chance to go
back and look at these patches). I'll do so tonight.

On Tue, Nov 21, 2017 at 10:00 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> I looked at patches 3-6 and I didn't see where the printf was removed.
>
> On 11/20/2017 05:47 PM, Oliver Walters wrote:
> > The printf() statement should be removed in one of the subsequent
> > patches, as should the removal of that line. I'm unable to check this
> > right now, are you able to confirm if one of the later patches fixes
> > this problem?
> >
> > On Tue, Nov 21, 2017 at 9:44 AM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > I made a change to fix a bug with the default plugin type when
> appending
> > a new row to the table which caused the conflict.  This where I
> noticed
> > the printf() debugging statement.  I also noticed that it appears
> that
> > you removed a scroll to row call and I'm not sure how to reconcile
> the
> > conflict.  Did you remove the scroll to row call on purpose or
> wasn't it
> > necessary.  I don't want to break that behavior.
> >
> > On 11/20/2017 04:29 PM, Oliver Walters wrote:
> > > Wayne,
> > >
> > > I think it is a whitespace issue, does it apply if you add
> > > --ignore-whitespace to git-am ?
> > >
> > > On Tue, Nov 21, 2017 at 1:03 AM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > Oliver,
> > >
> > > No go yet again.  It looks like my commit 8b2b1381 is causing
> a conflict
> > > with patch 2 so please rebase your patches.  I also noticed a
> printf()
> > > debugging statement in patch 2.  Please remove this and make
> sure there
> > > are not any other printf() statements in your patches.  Sorry
> about
> > > asking you to fix these issues but I really don't have the
> time to fix
> > > patches right now.
> > >
> > > Cheers,
> > >
> > > Wayne
> > >
> > > On 11/20/2017 1:20 AM, Oliver Walters wrote:
> > > > Wayne,
> > > >
> > > > I'm at a loss too. git am fails on 0002 but git apply works
> fine on each
> > > > individual patch.
> > > >
> > > > On Mon, Nov 20, 2017 at 3:29 AM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>
> > > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>> wrote:
> > > >
> > > > Oliver,
> > > >
> > > > Still no luck.  Did you possible do something to mess up
> the
> > > commit
> > > > ordering?  I am applying these patches on top a clean
> master
> > > branch so
> > > > I'm not sure what is going on here.  I'm getting the
> > following
> > > error
> > > > from `git am` when I attempt to merge patch 2:
> > > >
> > > > Applying: Toggle LIB_TABLE_ROW enabled/disabled in grid
> > editor
> > > > error: patch failed:
> > eeschema/dialogs/dialog_sym_lib_table.cpp:350
> > > > error: eeschema/dialogs/dialog_sym_lib_table.cpp: patch
> does
> > > not apply
> > > > error: patch failed: include/lib_table_grid.h:32
> > > > error: include/lib_table_grid.h: patch does not apply
> > > > Patch failed at 0001 Toggle LIB_TABLE_ROW
> > enabled/disabled in grid
> > >     > editor
> > > > The copy of the patch that failed is found in:
> > > .git/rebase-apply/patch
> > > > When you have resolved this problem, run "git am
> > --continue".
> > > > If you prefer to skip this patch, run "git am --skip"
> > instead.
> > > > To restore the original branch and stop patching, run
> > 

Re: [Kicad-developers] [PATCH] LIB_TABLE tweaks

[Oliver Walters]

The printf() statement should be removed in one of the subsequent patches,
as should the removal of that line. I'm unable to check this right now, are
you able to confirm if one of the later patches fixes this problem?

On Tue, Nov 21, 2017 at 9:44 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> I made a change to fix a bug with the default plugin type when appending
> a new row to the table which caused the conflict.  This where I noticed
> the printf() debugging statement.  I also noticed that it appears that
> you removed a scroll to row call and I'm not sure how to reconcile the
> conflict.  Did you remove the scroll to row call on purpose or wasn't it
> necessary.  I don't want to break that behavior.
>
> On 11/20/2017 04:29 PM, Oliver Walters wrote:
> > Wayne,
> >
> > I think it is a whitespace issue, does it apply if you add
> > --ignore-whitespace to git-am ?
> >
> > On Tue, Nov 21, 2017 at 1:03 AM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > Oliver,
> >
> > No go yet again.  It looks like my commit 8b2b1381 is causing a
> conflict
> > with patch 2 so please rebase your patches.  I also noticed a
> printf()
> > debugging statement in patch 2.  Please remove this and make sure
> there
> > are not any other printf() statements in your patches.  Sorry about
> > asking you to fix these issues but I really don't have the time to
> fix
> > patches right now.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 11/20/2017 1:20 AM, Oliver Walters wrote:
> > > Wayne,
> > >
> > > I'm at a loss too. git am fails on 0002 but git apply works fine
> on each
> > > individual patch.
> > >
> > > On Mon, Nov 20, 2017 at 3:29 AM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > Oliver,
> > >
> > > Still no luck.  Did you possible do something to mess up the
> > commit
> > > ordering?  I am applying these patches on top a clean master
> > branch so
> > > I'm not sure what is going on here.  I'm getting the following
> > error
> > > from `git am` when I attempt to merge patch 2:
> > >
> > > Applying: Toggle LIB_TABLE_ROW enabled/disabled in grid editor
> > > error: patch failed: eeschema/dialogs/dialog_sym_
> lib_table.cpp:350
> > > error: eeschema/dialogs/dialog_sym_lib_table.cpp: patch does
> > not apply
> > > error: patch failed: include/lib_table_grid.h:32
> > > error: include/lib_table_grid.h: patch does not apply
> > > Patch failed at 0001 Toggle LIB_TABLE_ROW enabled/disabled in
> grid
> > > editor
> > > The copy of the patch that failed is found in:
> > .git/rebase-apply/patch
> > > When you have resolved this problem, run "git am --continue".
> > > If you prefer to skip this patch, run "git am --skip" instead.
> > > To restore the original branch and stop patching, run "git am
> > --abort".
> > >
> > > If any one has any ideas, I'm open to suggestion.  If these
> > patches were
> > > generated properly, there should be no issues applying them.
> > >
> > > Cheers,
> > >
> > > Wayne
> > >
> > > On 11/18/2017 07:11 PM, Oliver Walters wrote:
> > > > Wayne
> > > >
> > > > Please find updated patch set attached. I have rebased and
> > built from
> > > > commit b6884d and it all works fine.
> > > >
> > > > Thanks
> > > >
> > > > On Sun, Nov 19, 2017 at 4:42 AM, Wayne Stambaugh
> > <stambau...@gmail.com <mailto:stambau...@gmail.com>
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>
> > > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>> wrote:
> > > >
> > > > Oliver,
> > > >
> > > > I just tried to apply your patches and ran into some

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

[Oliver Walters]

Wayne,

Patch files attached.

Once again the --ignore-whitespace flag will need to be used, I believe it
is because a line in kicad-plugin.h (46, corresponding to 20170920) has a
DOS newline instead of a UNIX newline.


Thanks,

On Tue, Nov 21, 2017 at 4:27 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Oliver,
>
> Please send me the latest patch(es) when you get a chance so I can get
> this merged.  I cannot find it (them) in my inbox.  I must have deleted
> the email by accident.
>
> Cheers,
>
> Wayne
>
> On 11/18/2017 8:39 PM, Oliver Walters wrote:
> > Wayne,
> >
> > Any further issues to address here? :)
> >
> > On 14 Nov 2017 20:55, "Oliver Walters" <oliver.henry.walt...@gmail.com
> > <mailto:oliver.henry.walt...@gmail.com>> wrote:
> >
> > Wayne,
> >
> > Please find attached updated patch set. If an old version is
> > detected, inches are converted to mm.
> >
> > On Tue, Nov 14, 2017 at 9:33 AM, Nick Østergaard <oe.n...@gmail.com
> > <mailto:oe.n...@gmail.com>> wrote:
> >
> > Just to mention it, I think this quirk needs to be put in the
> > release
> > notes for 5.0.0 if that would be the case, or at least
> > documented as a
> >     note in the docs.
> >
> > 2017-11-13 18:10 GMT+01.00, Wayne Stambaugh
> > <stambau...@gmail.com <mailto:stambau...@gmail.com>>:
> > > On 11/12/2017 6:12 AM, Oliver Walters wrote:
> > >> Wayne,
> > >>
> > >> Another potential spanner in the works - the footprint files
> > do not
> > >> store the file version information. (should they?)
> > >
> > > I would rather not.  Otherwise there would be a footprint
> > version in
> > > every footprint embedded in the schematic and could lead to
> > some ugly
> > > parser code.  At some point we may need to revisit this but
> > not now.
> > >
> > > This is not a big issue because the only effects the
> > footprints embedded
> > > in the board.  Users with custom footprint libraries that
> > contain 3D
> > > model offsets will just have to fix the offsets.  I'm guessing
> > this is a
> > > fairly small number of users.
> > >
> > >>
> > >> Thus, footprint files cannot be parsed differently based on
> > their file
> > >> version. Changing "at" between mm and inches will work for
> > the pcb but
> > >> not for the individual footprint files
> > >>
> > >> On Sun, Nov 12, 2017 at 7:47 AM, Wayne Stambaugh
> > <stambau...@gmail.com <mailto:stambau...@gmail.com>
> > >> <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> > wrote:
> > >>
> > >> I misunderstood the intention of this patch.  I though it
> > had nothing
> > >> to
> > >> do with the units change patch.  I will revert it.
> > Please send me the
> > >> file format change patch when you get a chance and I
> > merge them both
> > >> at
> > >> the same time.  Sorry about the mix up.
> > >>
> > >> On 11/11/2017 03:34 PM, Oliver Walters wrote:
> > >> > Wayne,
> > >> >
> > >> > I had not yet made any changes to the file parser. Have
> > you done
> > >> this
> > >> > according to your new file-version approach? Or do you
> > want me to
> > >> submit
> >     >> > a further patch implementing that?
> > >> >
> > >> > On 12 Nov 2017 07:16, "Wayne Stambaugh"
> > <stambau...@gmail.com <mailto:stambau...@gmail.com>
> > >> <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>
> > >> > <mailto:stambau...@gmail.com
> > <mailto:stambau...@gmail.com> <mailto:stambau...@gmail.com
> > <mailto:stambau...@gmail.com>>>> wrote:
> > >> >
> > 

Re: [Kicad-developers] [PATCH] LIB_TABLE tweaks

[Oliver Walters]

Wayne,

I think it is a whitespace issue, does it apply if you add
--ignore-whitespace to git-am ?

On Tue, Nov 21, 2017 at 1:03 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Oliver,
>
> No go yet again.  It looks like my commit 8b2b1381 is causing a conflict
> with patch 2 so please rebase your patches.  I also noticed a printf()
> debugging statement in patch 2.  Please remove this and make sure there
> are not any other printf() statements in your patches.  Sorry about
> asking you to fix these issues but I really don't have the time to fix
> patches right now.
>
> Cheers,
>
> Wayne
>
> On 11/20/2017 1:20 AM, Oliver Walters wrote:
> > Wayne,
> >
> > I'm at a loss too. git am fails on 0002 but git apply works fine on each
> > individual patch.
> >
> > On Mon, Nov 20, 2017 at 3:29 AM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > Oliver,
> >
> > Still no luck.  Did you possible do something to mess up the commit
> > ordering?  I am applying these patches on top a clean master branch
> so
> > I'm not sure what is going on here.  I'm getting the following error
> > from `git am` when I attempt to merge patch 2:
> >
> > Applying: Toggle LIB_TABLE_ROW enabled/disabled in grid editor
> > error: patch failed: eeschema/dialogs/dialog_sym_lib_table.cpp:350
> > error: eeschema/dialogs/dialog_sym_lib_table.cpp: patch does not
> apply
> > error: patch failed: include/lib_table_grid.h:32
> > error: include/lib_table_grid.h: patch does not apply
> > Patch failed at 0001 Toggle LIB_TABLE_ROW enabled/disabled in grid
> > editor
> > The copy of the patch that failed is found in:
> .git/rebase-apply/patch
> > When you have resolved this problem, run "git am --continue".
> > If you prefer to skip this patch, run "git am --skip" instead.
> > To restore the original branch and stop patching, run "git am
> --abort".
> >
> > If any one has any ideas, I'm open to suggestion.  If these patches
> were
> > generated properly, there should be no issues applying them.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 11/18/2017 07:11 PM, Oliver Walters wrote:
> > > Wayne
> > >
> > > Please find updated patch set attached. I have rebased and built
> from
> > > commit b6884d and it all works fine.
> > >
> > > Thanks
> > >
> > > On Sun, Nov 19, 2017 at 4:42 AM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > Oliver,
> > >
> > > I just tried to apply your patches and ran into some issues.
> > Patch 1
> > > applies but patch 2 fails.  Would you please rebase your
> > patches so I
> > > can get them merged as soon as possible.
> > >
> > > Thanks,
> > >
> > > Wayne
> > >
> > > On 11/15/2017 06:41 AM, Oliver Walters wrote:
> > > > Wayne, et al,
> > > >
> > > > I am really liking the way that the new symbol table works!
> > Thanks for
> > > > the huge effort that has gone into this.
> > > >
> > > > One thing that I have noticed is that when opening (for
> > e.g.) the
> > > > component chooser, the UI hangs while all the libraries
> > load. Previously
> > > > there was a progress dialog which at least informed the user
> > what was
> > > > going on.
> > > >
> > > > I have re-implemented this dialog in the attached patch set.
> > > >
> > > > Further, I have also implemented a way to individually
> > enable / disable
> > > > each row in the library tables (this works for SYMBOL_LIB
> > and FP_LIB).
> > > >
> > > > This is based on the idea by Tomasz. Example screenshot
> below:
> > > >
> > > > Inline image 1
> > > >
> > > > I have tweaked the base LIB_TABLE_GRID code such that
> > disabled entries
> > > > are greyed out and made italic. The enabled / disabled
> s

Re: [Kicad-developers] [PATCH] LIB_TABLE tweaks

[Oliver Walters]

Wayne,

I'm at a loss too. git am fails on 0002 but git apply works fine on each
individual patch.

On Mon, Nov 20, 2017 at 3:29 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Oliver,
>
> Still no luck.  Did you possible do something to mess up the commit
> ordering?  I am applying these patches on top a clean master branch so
> I'm not sure what is going on here.  I'm getting the following error
> from `git am` when I attempt to merge patch 2:
>
> Applying: Toggle LIB_TABLE_ROW enabled/disabled in grid editor
> error: patch failed: eeschema/dialogs/dialog_sym_lib_table.cpp:350
> error: eeschema/dialogs/dialog_sym_lib_table.cpp: patch does not apply
> error: patch failed: include/lib_table_grid.h:32
> error: include/lib_table_grid.h: patch does not apply
> Patch failed at 0001 Toggle LIB_TABLE_ROW enabled/disabled in grid editor
> The copy of the patch that failed is found in: .git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
>
> If any one has any ideas, I'm open to suggestion.  If these patches were
> generated properly, there should be no issues applying them.
>
> Cheers,
>
> Wayne
>
> On 11/18/2017 07:11 PM, Oliver Walters wrote:
> > Wayne
> >
> > Please find updated patch set attached. I have rebased and built from
> > commit b6884d and it all works fine.
> >
> > Thanks
> >
> > On Sun, Nov 19, 2017 at 4:42 AM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > Oliver,
> >
> > I just tried to apply your patches and ran into some issues.  Patch 1
> >     applies but patch 2 fails.  Would you please rebase your patches so I
> > can get them merged as soon as possible.
> >
> > Thanks,
> >
> > Wayne
> >
> > On 11/15/2017 06:41 AM, Oliver Walters wrote:
> > > Wayne, et al,
> > >
> > > I am really liking the way that the new symbol table works! Thanks
> for
> > > the huge effort that has gone into this.
> > >
> > > One thing that I have noticed is that when opening (for e.g.) the
> > > component chooser, the UI hangs while all the libraries load.
> Previously
> > > there was a progress dialog which at least informed the user what
> was
> > > going on.
> > >
> > > I have re-implemented this dialog in the attached patch set.
> > >
> > > Further, I have also implemented a way to individually enable /
> disable
> > > each row in the library tables (this works for SYMBOL_LIB and
> FP_LIB).
> > >
> > > This is based on the idea by Tomasz. Example screenshot below:
> > >
> > > Inline image 1
> > >
> > > I have tweaked the base LIB_TABLE_GRID code such that disabled
> entries
> > > are greyed out and made italic. The enabled / disabled status is
> > > persistent in the sym/fp_lib_table files. Older version of
> xxx_lib_table
> > > files are read with all rows enabled by default.
> > >
> > > Please find patch set attached.
> > >
> > > Regards,
> > > Oliver
> > >
> > >
> > >
> > > ___
> > > 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
> > <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

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

[Oliver Walters]

Wayne,

Any further issues to address here? :)

On 14 Nov 2017 20:55, "Oliver Walters" <oliver.henry.walt...@gmail.com>
wrote:

> Wayne,
>
> Please find attached updated patch set. If an old version is detected,
> inches are converted to mm.
>
> On Tue, Nov 14, 2017 at 9:33 AM, Nick Østergaard <oe.n...@gmail.com>
> wrote:
>
>> Just to mention it, I think this quirk needs to be put in the release
>> notes for 5.0.0 if that would be the case, or at least documented as a
>> note in the docs.
>>
>> 2017-11-13 18:10 GMT+01.00, Wayne Stambaugh <stambau...@gmail.com>:
>> > On 11/12/2017 6:12 AM, Oliver Walters wrote:
>> >> Wayne,
>> >>
>> >> Another potential spanner in the works - the footprint files do not
>> >> store the file version information. (should they?)
>> >
>> > I would rather not.  Otherwise there would be a footprint version in
>> > every footprint embedded in the schematic and could lead to some ugly
>> > parser code.  At some point we may need to revisit this but not now.
>> >
>> > This is not a big issue because the only effects the footprints embedded
>> > in the board.  Users with custom footprint libraries that contain 3D
>> > model offsets will just have to fix the offsets.  I'm guessing this is a
>> > fairly small number of users.
>> >
>> >>
>> >> Thus, footprint files cannot be parsed differently based on their file
>> >> version. Changing "at" between mm and inches will work for the pcb but
>> >> not for the individual footprint files
>> >>
>> >> On Sun, Nov 12, 2017 at 7:47 AM, Wayne Stambaugh <stambau...@gmail.com
>> >> <mailto:stambau...@gmail.com>> wrote:
>> >>
>> >> I misunderstood the intention of this patch.  I though it had
>> nothing
>> >> to
>> >> do with the units change patch.  I will revert it.  Please send me
>> the
>> >> file format change patch when you get a chance and I merge them
>> both
>> >> at
>> >> the same time.  Sorry about the mix up.
>> >>
>> >> On 11/11/2017 03:34 PM, Oliver Walters wrote:
>> >> > Wayne,
>> >> >
>> >> > I had not yet made any changes to the file parser. Have you done
>> >> this
>> >> > according to your new file-version approach? Or do you want me to
>> >> submit
>> >> > a further patch implementing that?
>> >> >
>> >> > On 12 Nov 2017 07:16, "Wayne Stambaugh" <stambau...@gmail.com
>> >> <mailto:stambau...@gmail.com>
>> >> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
>> wrote:
>> >> >
>> >> > Oliver,
>> >> >
>> >> > I committed your patch to the KiCad development branch.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Wayne
>> >> >
>> >> > On 11/08/2017 05:05 AM, Oliver Walters wrote:
>> >> > > Attached is a patch that fixes the problems I found in my
>> 3D
>> >> model
>> >> > array
>> >> > > investigation. As discussion on that is stalled for now,
>> >> this patch
>> >> > > simply fixes the model offset issues.
>> >> > >
>> >> > > 1. Display offset units in 3D preview window
>> >> > >
>> >> > > - Offset units are displayed (either inches or mm)
>> >> > >
>> >> > > 2. Fix offset in 3D rendering
>> >> > >
>> >> > > - It appears that the internal units for 3D model offset
>> >> (mm) were
>> >> > being
>> >> > > multiplied by 25.4 incorrectly
>> >> > > - Fixed rendering in OGL and Raytracing
>> >> > >
>> >> > > 3. Fix offset in 3D export
>> >> > >
>> >> > > - VRML export
>> >> > > - STEP export
>> >> > >
>> >> > > Oliver
>> >> > >
>> >> > >
>> >> > &

Re: [Kicad-developers] [PATCH] LIB_TABLE tweaks

[Oliver Walters]

Wayne

Please find updated patch set attached. I have rebased and built from
commit b6884d and it all works fine.

Thanks

On Sun, Nov 19, 2017 at 4:42 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Oliver,
>
> I just tried to apply your patches and ran into some issues.  Patch 1
> applies but patch 2 fails.  Would you please rebase your patches so I
> can get them merged as soon as possible.
>
> Thanks,
>
> Wayne
>
> On 11/15/2017 06:41 AM, Oliver Walters wrote:
> > Wayne, et al,
> >
> > I am really liking the way that the new symbol table works! Thanks for
> > the huge effort that has gone into this.
> >
> > One thing that I have noticed is that when opening (for e.g.) the
> > component chooser, the UI hangs while all the libraries load. Previously
> > there was a progress dialog which at least informed the user what was
> > going on.
> >
> > I have re-implemented this dialog in the attached patch set.
> >
> > Further, I have also implemented a way to individually enable / disable
> > each row in the library tables (this works for SYMBOL_LIB and FP_LIB).
> >
> > This is based on the idea by Tomasz. Example screenshot below:
> >
> > Inline image 1
> >
> > I have tweaked the base LIB_TABLE_GRID code such that disabled entries
> > are greyed out and made italic. The enabled / disabled status is
> > persistent in the sym/fp_lib_table files. Older version of xxx_lib_table
> > files are read with all rows enabled by default.
> >
> > Please find patch set attached.
> >
> > 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
>
From 7031b7262c1afe7efa6dcd8c171a18ecbf5ca952 Mon Sep 17 00:00:00 2001
From: Oliver <oliver.henry.walt...@gmail.com>
Date: Wed, 15 Nov 2017 22:32:23 +1100
Subject: [PATCH 6/6] Improved LIB_TABLE rendering

- Moved "Active" to first column
- Changed text attributes for disabled rows
---
 include/lib_table_grid.h | 48 ++--
 1 file changed, 46 insertions(+), 2 deletions(-)

diff --git a/include/lib_table_grid.h b/include/lib_table_grid.h
index c35c4f4..94726b5 100644
--- a/include/lib_table_grid.h
+++ b/include/lib_table_grid.h
@@ -24,15 +24,18 @@
 
 #include 
 
+const wxColour COLOUR_ROW_ENABLED( 0, 0, 0 );
+const wxColour COLOUR_ROW_DISABLED( 100, 100, 100 );
+
 /// The library table grid column order is established by this sequence.
 enum COL_ORDER
 {
+COL_ENABLED,
 COL_NICKNAME,
 COL_URI,
 COL_TYPE,
 COL_OPTIONS,
 COL_DESCR,
-COL_ENABLED,
 
 COL_COUNT   // keep as last
 };
@@ -180,12 +183,53 @@ public:
 case COL_TYPE:  return _( "Plugin Type" );
 case COL_OPTIONS:   return _( "Options" );
 case COL_DESCR: return _( "Description" );
-case COL_ENABLED:   return _( "Enabled" );
+case COL_ENABLED:   return _( "Active" );
 
 default:return wxEmptyString;
 }
 }
 
+/**
+ * Customize the appearance of LIB_TABLE_ROW entries
+ * - If not enabled, greyed out and italic
+ */
+virtual wxGridCellAttr* GetAttr( int aRow, int aCol, wxGridCellAttr::wxAttrKind aKind) override
+{
+auto* attr = wxGridTableBase::GetAttr( aRow, aCol, aKind );
+
+if( aRow < (int) size() )
+{
+if( !attr )
+{
+attr = new wxGridCellAttr();
+}
+
+wxFont font;
+
+if( attr->HasFont() )
+{
+font = attr->GetFont();
+}
+
+LIB_TABLE_ROW* r = at( (size_t) aRow );
+
+if( r && r->GetIsEnabled() )
+{
+font.SetStyle( wxFONTSTYLE_NORMAL );
+attr->SetTextColour( COLOUR_ROW_ENABLED );
+}
+else
+{
+font.SetStyle( wxFONTSTYLE_ITALIC );
+attr->SetTextColour( COLOUR_ROW_DISABLED );
+}
+
+attr->SetFont( font );
+}
+
+return attr;
+}
+
 protected:
 virtual LIB_TABLE_ROW* at( size_t aIndex ) = 0;
 
-- 
2.7.4

From 7694084a6d0930c8500d9215f824f957688e72d7 M

Re: [Kicad-developers] [PATCH] LIB_TABLE tweaks

[Oliver Walters]

Thank you!

On 18 Nov 2017 00:47, "Wayne Stambaugh" <stambau...@gmail.com> wrote:

> Oliver,
>
> I took another look at your patch set and I see now that the library
> table files only change when there are disabled libraries.  This will
> ensure that the footprint library tables will be compatible with
> previous versions of KiCad as long as users don't disable any libraries.
>  I will merge your patch set over the weekend if there are no other
> major objections.  This change in behavior should be documented in the
> "Managing Footprint Libraries" section of the pcbnew docs.
>
> Folks, please do not hijack threads.  This thread should have only been
> a discussion about Oliver's proposed changes.
>
> Thanks,
>
> Wayne
>
> On 11/17/2017 07:06 AM, Oliver Walters wrote:
> > Wayne,
> >
> > Please confirm if you really do not want this feature now. This thread
> > is quickly turning into a how-to for the new symbol table :)
> >
> > Thanks
> >
> > On Thu, Nov 16, 2017 at 8:42 AM, Oliver Walters
> > <oliver.henry.walt...@gmail.com <mailto:oliver.henry.walt...@gmail.com>>
> > wrote:
> >
> >
> > On Thu, Nov 16, 2017 at 1:42 AM, Wayne Stambaugh
> > <stambau...@gmail.com <mailto:stambau...@gmail.com>> wrote:
> >
> > Gentlemen,
> >
> > I'm not sure about breaking the library table file format for the
> > version 5 release.  If we do, the footprint library table will
> > not be
> > compatible with older versions.  I would prefer that we push
> > this change
> > into version 6.
> >
> >
> > I'm not sure I understand why it would be ok to break it in v6 but
> > not v5? We are already introducing the sym-lib-table. If we waited
> > until v6 to make this change, then we would break *both* tables
> > (instead of just one).
> >
> >
> >
> > I'm OK with the progress dialog.  If you split that out as
> separate
> > patch, I will merge it.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 11/15/2017 9:38 AM, Tomasz Wlostowski wrote:
> > > On 15/11/17 15:30, Maciej Suminski wrote:
> > >> Hi Oliver,
> > >>
> > >> Thank you for restoring the progress bar dialog. While the
> > library load
> > >> time has recently decreased a lot, the UI freeze still
> > happens with long
> > >> library lists.
> > >> Disclaimer: I have not looked at the code yet, I am just
> > praising the idea.
> > >>
> > >> As you are looking on the Symbol Library Table dialog, I
> > suppose you
> > >> might be also tempted to add a file browser to add new
> > libraries. If
> > >> that is the case, please refrain from doing so - it is done
> > in the
> > >> library editor refactor branch. If you had no such intention,
> > then
> > >> simply ignore this message.
> > >
> > > Hi Olivier & Orson,
> > >
> > > I partially implemented the simplified dialog I proposed on
> > the dev list
> > > a few days ago. Would anyone be interested in helping me
> > finish it?
> > >
> > > Tom
> > >
> > >>
> > >> Cheers,
> > >> Orson
> > >>
> > >> On 15/11/2017 12:41 PM, Oliver Walters wrote:
> > >>> Wayne, et al,
> > >>>
> > >>> I am really liking the way that the new symbol table works!
> > Thanks for
> > >>> the huge effort that has gone into this.
> > >>>
> > >>> One thing that I have noticed is that when opening (for
> > e.g.) the
> > >>> component chooser, the UI hangs while all the libraries
> > load. Previously
> > >>> there was a progress dialog which at least informed the user
> > what was
> > >>> going on.
> > >>>
> > >>> I have re-implemented this dialog in the attached patch set.
> > >>>
> > >>> Further, I have also implemented a way to individually
&g

Re: [Kicad-developers] [PATCH] LIB_TABLE tweaks

[Oliver Walters]

Wayne,

Please confirm if you really do not want this feature now. This thread is
quickly turning into a how-to for the new symbol table :)

Thanks

On Thu, Nov 16, 2017 at 8:42 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

>
> On Thu, Nov 16, 2017 at 1:42 AM, Wayne Stambaugh <stambau...@gmail.com>
> wrote:
>
>> Gentlemen,
>>
>> I'm not sure about breaking the library table file format for the
>> version 5 release.  If we do, the footprint library table will not be
>> compatible with older versions.  I would prefer that we push this change
>> into version 6.
>>
>
> I'm not sure I understand why it would be ok to break it in v6 but not v5?
> We are already introducing the sym-lib-table. If we waited until v6 to make
> this change, then we would break *both* tables (instead of just one).
>
>
>>
>> I'm OK with the progress dialog.  If you split that out as separate
>> patch, I will merge it.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 11/15/2017 9:38 AM, Tomasz Wlostowski wrote:
>> > On 15/11/17 15:30, Maciej Suminski wrote:
>> >> Hi Oliver,
>> >>
>> >> Thank you for restoring the progress bar dialog. While the library load
>> >> time has recently decreased a lot, the UI freeze still happens with
>> long
>> >> library lists.
>> >> Disclaimer: I have not looked at the code yet, I am just praising the
>> idea.
>> >>
>> >> As you are looking on the Symbol Library Table dialog, I suppose you
>> >> might be also tempted to add a file browser to add new libraries. If
>> >> that is the case, please refrain from doing so - it is done in the
>> >> library editor refactor branch. If you had no such intention, then
>> >> simply ignore this message.
>> >
>> > Hi Olivier & Orson,
>> >
>> > I partially implemented the simplified dialog I proposed on the dev list
>> > a few days ago. Would anyone be interested in helping me finish it?
>> >
>> > Tom
>> >
>> >>
>> >> Cheers,
>> >> Orson
>> >>
>> >> On 15/11/2017 12:41 PM, Oliver Walters wrote:
>> >>> Wayne, et al,
>> >>>
>> >>> I am really liking the way that the new symbol table works! Thanks for
>> >>> the huge effort that has gone into this.
>> >>>
>> >>> One thing that I have noticed is that when opening (for e.g.) the
>> >>> component chooser, the UI hangs while all the libraries load.
>> Previously
>> >>> there was a progress dialog which at least informed the user what was
>> >>> going on.
>> >>>
>> >>> I have re-implemented this dialog in the attached patch set.
>> >>>
>> >>> Further, I have also implemented a way to individually enable /
>> disable
>> >>> each row in the library tables (this works for SYMBOL_LIB and FP_LIB).
>> >>>
>> >>> This is based on the idea by Tomasz. Example screenshot below:
>> >>>
>> >>> Inline image 1
>> >>>
>> >>> I have tweaked the base LIB_TABLE_GRID code such that disabled entries
>> >>> are greyed out and made italic. The enabled / disabled status is
>> >>> persistent in the sym/fp_lib_table files. Older version of
>> xxx_lib_table
>> >>> files are read with all rows enabled by default.
>> >>>
>> >>> Please find patch set attached.
>> >>>
>> >>> 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
>> >
>> >
>> > ___
>> > 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] Add live footprint filtering in modview window

[Oliver Walters]

Wayne,

Please ignore the previous patch sets. I have made further tweaks and the
attached patch set 0001 through 0008 should be considered canonical.
.
I have fixed a couple of pointer errors, and have also dropped the
filter-by-library functionality. It was a bit hooky and I'd rather submit a
solid functional set of patches and don't have time to investigate further.

I hope that the attached patch set meets your standards and can be merged
as-is :)

Thanks!

On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> On 10/31/2017 5:01 PM, Oliver Walters wrote:
> > How should I proceed here then?
> >
> > I would like to see the various libraries being "cached" in the
> > background, but this is increasing the scope of the work by a large
> factor.
> >
> > One thing I have noticed:
> >
> > In eeschema when you launch the component viewer, it (on first run) maps
> > and caches all the footprint libraries. This can take AGES (especially
> > on Windows). However on subsequent launches of the component viewer it
> > appears instantly. It appears to be keeping a static map of the
> > footprint library data.
> >
> > a) Would this be an acceptable approach for the footprint viewer window
>
> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
> footprint library code is split out from the component chooser so it
> should be reusable.
>
> > b) What happens when the library data changes externally? Does component
> > viewer need to be reloaded?
>
> No, only the library that changed gets reloaded the next time it's
> accessed.  It is not automatic.  I thought about using wxFileWatcher but
> that could be a lot of overhead for little net gain.  See the pcb plugin
> cache() functions.
>
> > c) Can we globally perform this caching in a background thread when
> > KiCad launches? This will hide the large pauses (up to a minute under
> > Windows) from the user...
>
> Yes, this should be done as a project element so that it can be accessed
> from all of the main windows.  Please keep in mind, this could be a lot
> of work and given that we are nearing a stable 5 release feature freeze,
> so if it's not by then it will not make it into the stable 5 release.
>
> >
> > Oliver
> >
> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
> > > Hmm, I had thought that there was a way to load only the *names* of
> > > footprints, rather than individually parsing each footprint file.
> It
> > > appears that this is not the case. Any suggestions on how the speed
> > > could be improved? Currently I'm reading out all the footprint
> names in
> > > each footprint library and only storing the names (wxString)
> rather than
> > > the MODULE* objects. However, I still have to parse the entire
> library
> > > on load.
> > >
> > > Ideally, I think it would be good to just read in the names, and
> then
> > > load and display individual MODULE objects on demand.. Is this
> possible?
> >
> > This is possible (although not implemented) for library types (kicad,
> > geda) that use one file per footprint.  You could just read the file
> > names from the folder and load the files as required.  If you want to
> > search any other properties of the footprint, then you will have to
> load
> > all of the footprints anyway.  I don't know if this would be worth
> the
> > effort.
> >
> > For library types that contain multiple footprints per file (legacy,
> > Eagle), this wouldn't make much sense.  Parsing the entire file just
> to
> > pick out the footprint names probably isn't going to save you very
> much
> > time.
> >
> > >
> > > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > On 10/30/2017 5:23 PM, Oliver Walters wrote:
> > > > Thanks for the suggestions on fixing the text. I have that
> sorted.
> > > >
> > > > I will look into different ways of caching footprint data so
> it is quicker.
> > > >
> > > > Wayne, I didn't know about FOOTPRINT_FILTER I will switch to
> using that
> > > > instead (and provide rege

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

[Oliver Walters]

Seth,

Currently at work but I'll have a look at these issues ASAP. I'd like to
get this merged :)

On Fri, Nov 17, 2017 at 9:46 AM, Seth Hillbrand <seth.hillbr...@gmail.com>
wrote:

> Hi Oliver-
>
> I found where the issue is.  I apparently have an invalid line in my
> fp-lib-table.  It lists my github library as type "KiCad".  This is why the
> URL looked odd in the debug message.  I have to admit, I'm not certain how
> this got mixed up but it must have been my mistake at some point in the
> past.  However, I think we should be able to handle a bad line without
> crashing.
>
> Once I fixed the error in my fp-lib-table, your patch functions without
> crashing.  Couple comments:
>
> - When the user clicks on a new library, it seems to move the location of
> the selected row to the top of the listbox.  This isn't a problem if you
> are scrolling but clicking around, I find it problematic.
> - The layout of the window doesn't seem to adjust well to changing the
> width.  (see attached image)  It seems to remember the starting width and
> not unwrap when enlarged.
>
> Thanks for the work on this!
>
> Best-
> Seth
>
>
>
>
> On Thu, Nov 16, 2017 at 1:26 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Wayne,
>>
>> Patch set now goes to 0009 (all patches re-attached to this email).
>>
>> Most recent patch adds the following:
>>
>> - Busy cursor while loading each library (otherwise it feels like KiCad
>> is just sleepy)
>> - Further nullptr checks, trying to fix Seth's error
>> - Removed a tooltip that erroneously suggested that regex was supported.
>>
>> Cheers
>>
>> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh <stambau...@gmail.com>
>> wrote:
>>
>>> On 10/31/2017 5:01 PM, Oliver Walters wrote:
>>> > How should I proceed here then?
>>> >
>>> > I would like to see the various libraries being "cached" in the
>>> > background, but this is increasing the scope of the work by a large
>>> factor.
>>> >
>>> > One thing I have noticed:
>>> >
>>> > In eeschema when you launch the component viewer, it (on first run)
>>> maps
>>> > and caches all the footprint libraries. This can take AGES (especially
>>> > on Windows). However on subsequent launches of the component viewer it
>>> > appears instantly. It appears to be keeping a static map of the
>>> > footprint library data.
>>> >
>>> > a) Would this be an acceptable approach for the footprint viewer window
>>>
>>> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
>>> footprint library code is split out from the component chooser so it
>>> should be reusable.
>>>
>>> > b) What happens when the library data changes externally? Does
>>> component
>>> > viewer need to be reloaded?
>>>
>>> No, only the library that changed gets reloaded the next time it's
>>> accessed.  It is not automatic.  I thought about using wxFileWatcher but
>>> that could be a lot of overhead for little net gain.  See the pcb plugin
>>> cache() functions.
>>>
>>> > c) Can we globally perform this caching in a background thread when
>>> > KiCad launches? This will hide the large pauses (up to a minute under
>>> > Windows) from the user...
>>>
>>> Yes, this should be done as a project element so that it can be accessed
>>> from all of the main windows.  Please keep in mind, this could be a lot
>>> of work and given that we are nearing a stable 5 release feature freeze,
>>> so if it's not by then it will not make it into the stable 5 release.
>>>
>>> >
>>> > Oliver
>>> >
>>> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <
>>> stambau...@gmail.com
>>> > <mailto:stambau...@gmail.com>> wrote:
>>> >
>>> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
>>> > > Hmm, I had thought that there was a way to load only the *names*
>>> of
>>> > > footprints, rather than individually parsing each footprint
>>> file. It
>>> > > appears that this is not the case. Any suggestions on how the
>>> speed
>>> > > could be improved? Currently I'm reading out all the footprint
>>> names in
>>> > > each footprint library and only storing the names (wxString)
>>> rather than
>>> > > the MODULE*

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

[Oliver Walters]

Kevin - noted. It appears that Seth found the cause of the issue anyway :)

On Fri, Nov 17, 2017 at 10:30 AM, Kevin Cozens <ke...@ve3syb.ca> wrote:

> On 2017-11-16 04:08 PM, Oliver Walters wrote:
>
>> I just tried that github repo and it works fine for me. It appears that
>> you are missing a "/" after https:/
>>
>
> I don't think the second / is missing after https:/. There are places
> where the code normalizes paths which converts // to /.
>
> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   |"Nerds make the shiny things that
> distract
> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
> | powerful!"
> #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

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

[Oliver Walters]

Orson,

Yes this is correct. I have noticed this too and there is a workaround I
can make.

On Fri, Nov 17, 2017 at 10:07 AM, Maciej Suminski <maciej.sumin...@cern.ch>
wrote:

> Hi Oliver,
>
> I admit that recently I have wished for a footprint filter (/me puts a
> tinfoil hat), so I like the idea.
>
> Being picky, I noticed that library and footprint filters behave a
> little differently: for libraries one needs to explicitly use wildcards,
> whereas it is not necessary for footprint names. To give an example:
> "SMD:" leaves an empty list but "*SMD*:" gets me beloved SMD parts. For
> footprint names it is enough to type "0603", no need to use "*0603*". As
> you see, it is a minor detail, no showstoppers.
>
> Cheers,
> Orson
>
> On 11/16/2017 10:26 PM, Oliver Walters wrote:
> > Wayne,
> >
> > Patch set now goes to 0009 (all patches re-attached to this email).
> >
> > Most recent patch adds the following:
> >
> > - Busy cursor while loading each library (otherwise it feels like KiCad
> is
> > just sleepy)
> > - Further nullptr checks, trying to fix Seth's error
> > - Removed a tooltip that erroneously suggested that regex was supported.
> >
> > Cheers
> >
> > On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh <stambau...@gmail.com>
> > wrote:
> >
> >> On 10/31/2017 5:01 PM, Oliver Walters wrote:
> >>> How should I proceed here then?
> >>>
> >>> I would like to see the various libraries being "cached" in the
> >>> background, but this is increasing the scope of the work by a large
> >> factor.
> >>>
> >>> One thing I have noticed:
> >>>
> >>> In eeschema when you launch the component viewer, it (on first run)
> maps
> >>> and caches all the footprint libraries. This can take AGES (especially
> >>> on Windows). However on subsequent launches of the component viewer it
> >>> appears instantly. It appears to be keeping a static map of the
> >>> footprint library data.
> >>>
> >>> a) Would this be an acceptable approach for the footprint viewer window
> >>
> >> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
> >> footprint library code is split out from the component chooser so it
> >> should be reusable.
> >>
> >>> b) What happens when the library data changes externally? Does
> component
> >>> viewer need to be reloaded?
> >>
> >> No, only the library that changed gets reloaded the next time it's
> >> accessed.  It is not automatic.  I thought about using wxFileWatcher but
> >> that could be a lot of overhead for little net gain.  See the pcb plugin
> >> cache() functions.
> >>
> >>> c) Can we globally perform this caching in a background thread when
> >>> KiCad launches? This will hide the large pauses (up to a minute under
> >>> Windows) from the user...
> >>
> >> Yes, this should be done as a project element so that it can be accessed
> >> from all of the main windows.  Please keep in mind, this could be a lot
> >> of work and given that we are nearing a stable 5 release feature freeze,
> >> so if it's not by then it will not make it into the stable 5 release.
> >>
> >>>
> >>> Oliver
> >>>
> >>> On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <
> stambau...@gmail.com
> >>> <mailto:stambau...@gmail.com>> wrote:
> >>>
> >>> On 10/31/2017 1:25 AM, Oliver Walters wrote:
> >>> > Hmm, I had thought that there was a way to load only the *names*
> of
> >>> > footprints, rather than individually parsing each footprint file.
> >> It
> >>> > appears that this is not the case. Any suggestions on how the
> speed
> >>> > could be improved? Currently I'm reading out all the footprint
> >> names in
> >>> > each footprint library and only storing the names (wxString)
> >> rather than
> >>> > the MODULE* objects. However, I still have to parse the entire
> >> library
> >>> > on load.
> >>> >
> >>> > Ideally, I think it would be good to just read in the names, and
> >> then
> >>> > load and display individual MODULE objects on demand.. Is this
> >> possible?
> >>>
> >>> This is possible (although not implemented) for libra

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

[Oliver Walters]

Wayne,

Patch set now goes to 0009 (all patches re-attached to this email).

Most recent patch adds the following:

- Busy cursor while loading each library (otherwise it feels like KiCad is
just sleepy)
- Further nullptr checks, trying to fix Seth's error
- Removed a tooltip that erroneously suggested that regex was supported.

Cheers

On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> On 10/31/2017 5:01 PM, Oliver Walters wrote:
> > How should I proceed here then?
> >
> > I would like to see the various libraries being "cached" in the
> > background, but this is increasing the scope of the work by a large
> factor.
> >
> > One thing I have noticed:
> >
> > In eeschema when you launch the component viewer, it (on first run) maps
> > and caches all the footprint libraries. This can take AGES (especially
> > on Windows). However on subsequent launches of the component viewer it
> > appears instantly. It appears to be keeping a static map of the
> > footprint library data.
> >
> > a) Would this be an acceptable approach for the footprint viewer window
>
> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
> footprint library code is split out from the component chooser so it
> should be reusable.
>
> > b) What happens when the library data changes externally? Does component
> > viewer need to be reloaded?
>
> No, only the library that changed gets reloaded the next time it's
> accessed.  It is not automatic.  I thought about using wxFileWatcher but
> that could be a lot of overhead for little net gain.  See the pcb plugin
> cache() functions.
>
> > c) Can we globally perform this caching in a background thread when
> > KiCad launches? This will hide the large pauses (up to a minute under
> > Windows) from the user...
>
> Yes, this should be done as a project element so that it can be accessed
> from all of the main windows.  Please keep in mind, this could be a lot
> of work and given that we are nearing a stable 5 release feature freeze,
> so if it's not by then it will not make it into the stable 5 release.
>
> >
> > Oliver
> >
> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
> > > Hmm, I had thought that there was a way to load only the *names* of
> > > footprints, rather than individually parsing each footprint file.
> It
> > > appears that this is not the case. Any suggestions on how the speed
> > > could be improved? Currently I'm reading out all the footprint
> names in
> > > each footprint library and only storing the names (wxString)
> rather than
> > > the MODULE* objects. However, I still have to parse the entire
> library
> > > on load.
> > >
> > > Ideally, I think it would be good to just read in the names, and
> then
> > > load and display individual MODULE objects on demand.. Is this
> possible?
> >
> > This is possible (although not implemented) for library types (kicad,
> > geda) that use one file per footprint.  You could just read the file
> > names from the folder and load the files as required.  If you want to
> > search any other properties of the footprint, then you will have to
> load
> > all of the footprints anyway.  I don't know if this would be worth
> the
> > effort.
> >
> > For library types that contain multiple footprints per file (legacy,
> > Eagle), this wouldn't make much sense.  Parsing the entire file just
> to
> > pick out the footprint names probably isn't going to save you very
> much
> > time.
> >
> > >
> > > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > On 10/30/2017 5:23 PM, Oliver Walters wrote:
> > > > Thanks for the suggestions on fixing the text. I have that
> sorted.
> > > >
> > > > I will look into different ways of caching footprint data so
> it is quicker.
> > > >
> > > > Wayne, I didn't know about FOOTPRINT_FILTER I will switch to
> using that
> > > > instead (and provide regex search).
> > >
> > > Thanks Oliver!
> > >
> > > >
> >

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

[Oliver Walters]

nctor&, wxEvent&) const () from /usr/lib/x86_64-linux-gnu/
> libwx_baseu-3.0.so.0
> #30 0x764c9ea5 in 
> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
> const&, wxEvtHandler*, wxEvent&) () from /usr/lib/x86_64-linux-gnu/
> libwx_baseu-3.0.so.0
> #31 0x764c9f9b in wxEventHashTable::HandleEvent(wxEvent&,
> wxEvtHandler*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #32 0x764ca34b in wxEvtHandler::TryHereOnly(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #33 0x7fffd6deffb7 in EDA_BASE_FRAME::ProcessEvent
> (this=0x5913e640, aEvent=...) at /home/seth/code/kicad/kicad-
> launchpad/common/basicframe.cpp:187
> #34 0x764ca153 in wxEvtHandler::DoTryChain(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #35 0x764ca435 in wxEvtHandler::ProcessEvent(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #36 0x76e562f8 in wxWindowBase::TryAfter(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
> #37 0x77989878 in wxAuiToolBar::OnLeftUp(wxMouseEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_aui-3.0.so.0
> #38 0x7634440e in wxAppConsoleBase::CallEventHandler(wxEvtHandler*,
> wxEventFunctor&, wxEvent&) const () from /usr/lib/x86_64-linux-gnu/
> libwx_baseu-3.0.so.0
> #39 0x764c9ea5 in 
> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
> const&, wxEvtHandler*, wxEvent&) () from /usr/lib/x86_64-linux-gnu/
> libwx_baseu-3.0.so.0
> #40 0x764c9f9b in wxEventHashTable::HandleEvent(wxEvent&,
> wxEvtHandler*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #41 0x764ca34b in wxEvtHandler::TryHereOnly(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #42 0x764ca3d3 in wxEvtHandler::ProcessEventLocally(wxEvent&) ()
> from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #43 0x764ca435 in wxEvtHandler::ProcessEvent(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #44 0x764ca1a7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) ()
> from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
>
>
> -S
>
> On Thu, Nov 16, 2017 at 9:37 AM, Seth Hillbrand <seth.hillbr...@gmail.com>
> wrote:
>
>> Hi Oliver-
>>
>> I tried the new patchset but I can't seem to get it to work.  It only
>> loads the local libraries (none of the Github libraries).
>>
>> I get the error:
>> Error: IO_ERROR: Footprint library path 'https:/github.com/KiCad/Conne
>> ctors_JST.pretty' does not exist
>>
>> -S
>>
>> On Thu, Nov 16, 2017 at 5:23 AM, Oliver Walters <
>> oliver.henry.walt...@gmail.com> wrote:
>>
>>> Important! Patch 0008 (attached) fixes a nullpointer error.
>>>
>>> BUT more importantly, it also reintroduces the ability to filter out
>>> libraries using the ':' separator!
>>>
>>> Now we are getting somewhere!
>>>
>>> On Thu, Nov 16, 2017 at 11:38 PM, Oliver Walters <
>>> oliver.henry.walt...@gmail.com> wrote:
>>>
>>>> Wayne,
>>>>
>>>> I have finally found some time to readdress this.
>>>>
>>>> I have reimplemented the filtering using the existing FOOTPRINT_FILTER
>>>> class. I have also reverted behaviour to work only on the currently
>>>> selected footprint library. This removes the requirement to load all the
>>>> libraries when the dialog opens.
>>>>
>>>> I think all requirements are satisfied now. Please find modified patch
>>>> set attached.
>>>>
>>>> Regards,
>>>> Oliver
>>>>
>>>> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh <stambau...@gmail.com>
>>>> wrote:
>>>>
>>>>> On 10/31/2017 5:01 PM, Oliver Walters wrote:
>>>>> > How should I proceed here then?
>>>>> >
>>>>> > I would like to see the various libraries being "cached" in the
>>>>> > background, but this is increasing the scope of the work by a large
>>>>> factor.
>>>>> >
>>>>> > One thing I have noticed:
>>>>> >
>>>>> > In eeschema when you launch the component viewer, it (on first run)
>>>>> maps
>>>>> > and caches all the footprint libraries. This can take AGES
>>>>> (especially
>>>>> > on Windows). However on subsequent launches of the component viewer
>

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

[Oliver Walters]

Seth,

I just tried that github repo and it works fine for me. It appears that you
are missing a "/" after https:/

On Fri, Nov 17, 2017 at 4:37 AM, Seth Hillbrand <seth.hillbr...@gmail.com>
wrote:

> Hi Oliver-
>
> I tried the new patchset but I can't seem to get it to work.  It only
> loads the local libraries (none of the Github libraries).
>
> I get the error:
> Error: IO_ERROR: Footprint library path 'https:/github.com/KiCad/
> Connectors_JST.pretty' does not exist
>
> -S
>
> On Thu, Nov 16, 2017 at 5:23 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Important! Patch 0008 (attached) fixes a nullpointer error.
>>
>> BUT more importantly, it also reintroduces the ability to filter out
>> libraries using the ':' separator!
>>
>> Now we are getting somewhere!
>>
>> On Thu, Nov 16, 2017 at 11:38 PM, Oliver Walters <
>> oliver.henry.walt...@gmail.com> wrote:
>>
>>> Wayne,
>>>
>>> I have finally found some time to readdress this.
>>>
>>> I have reimplemented the filtering using the existing FOOTPRINT_FILTER
>>> class. I have also reverted behaviour to work only on the currently
>>> selected footprint library. This removes the requirement to load all the
>>> libraries when the dialog opens.
>>>
>>> I think all requirements are satisfied now. Please find modified patch
>>> set attached.
>>>
>>> Regards,
>>> Oliver
>>>
>>> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh <stambau...@gmail.com>
>>> wrote:
>>>
>>>> On 10/31/2017 5:01 PM, Oliver Walters wrote:
>>>> > How should I proceed here then?
>>>> >
>>>> > I would like to see the various libraries being "cached" in the
>>>> > background, but this is increasing the scope of the work by a large
>>>> factor.
>>>> >
>>>> > One thing I have noticed:
>>>> >
>>>> > In eeschema when you launch the component viewer, it (on first run)
>>>> maps
>>>> > and caches all the footprint libraries. This can take AGES (especially
>>>> > on Windows). However on subsequent launches of the component viewer it
>>>> > appears instantly. It appears to be keeping a static map of the
>>>> > footprint library data.
>>>> >
>>>> > a) Would this be an acceptable approach for the footprint viewer
>>>> window
>>>>
>>>> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
>>>> footprint library code is split out from the component chooser so it
>>>> should be reusable.
>>>>
>>>> > b) What happens when the library data changes externally? Does
>>>> component
>>>> > viewer need to be reloaded?
>>>>
>>>> No, only the library that changed gets reloaded the next time it's
>>>> accessed.  It is not automatic.  I thought about using wxFileWatcher but
>>>> that could be a lot of overhead for little net gain.  See the pcb plugin
>>>> cache() functions.
>>>>
>>>> > c) Can we globally perform this caching in a background thread when
>>>> > KiCad launches? This will hide the large pauses (up to a minute under
>>>> > Windows) from the user...
>>>>
>>>> Yes, this should be done as a project element so that it can be accessed
>>>> from all of the main windows.  Please keep in mind, this could be a lot
>>>> of work and given that we are nearing a stable 5 release feature freeze,
>>>> so if it's not by then it will not make it into the stable 5 release.
>>>>
>>>> >
>>>> > Oliver
>>>> >
>>>> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <
>>>> stambau...@gmail.com
>>>> > <mailto:stambau...@gmail.com>> wrote:
>>>> >
>>>> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
>>>> > > Hmm, I had thought that there was a way to load only the
>>>> *names* of
>>>> > > footprints, rather than individually parsing each footprint
>>>> file. It
>>>> > > appears that this is not the case. Any suggestions on how the
>>>> speed
>>>> > > could be improved? Currently I'm reading out all the footprint
>>>> names in
>>>> > > each footprint library and only storing 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

[Oliver Walters]

Important! Patch 0008 (attached) fixes a nullpointer error.

BUT more importantly, it also reintroduces the ability to filter out
libraries using the ':' separator!

Now we are getting somewhere!

On Thu, Nov 16, 2017 at 11:38 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Wayne,
>
> I have finally found some time to readdress this.
>
> I have reimplemented the filtering using the existing FOOTPRINT_FILTER
> class. I have also reverted behaviour to work only on the currently
> selected footprint library. This removes the requirement to load all the
> libraries when the dialog opens.
>
> I think all requirements are satisfied now. Please find modified patch set
> attached.
>
> Regards,
> Oliver
>
> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh <stambau...@gmail.com>
> wrote:
>
>> On 10/31/2017 5:01 PM, Oliver Walters wrote:
>> > How should I proceed here then?
>> >
>> > I would like to see the various libraries being "cached" in the
>> > background, but this is increasing the scope of the work by a large
>> factor.
>> >
>> > One thing I have noticed:
>> >
>> > In eeschema when you launch the component viewer, it (on first run) maps
>> > and caches all the footprint libraries. This can take AGES (especially
>> > on Windows). However on subsequent launches of the component viewer it
>> > appears instantly. It appears to be keeping a static map of the
>> > footprint library data.
>> >
>> > a) Would this be an acceptable approach for the footprint viewer window
>>
>> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
>> footprint library code is split out from the component chooser so it
>> should be reusable.
>>
>> > b) What happens when the library data changes externally? Does component
>> > viewer need to be reloaded?
>>
>> No, only the library that changed gets reloaded the next time it's
>> accessed.  It is not automatic.  I thought about using wxFileWatcher but
>> that could be a lot of overhead for little net gain.  See the pcb plugin
>> cache() functions.
>>
>> > c) Can we globally perform this caching in a background thread when
>> > KiCad launches? This will hide the large pauses (up to a minute under
>> > Windows) from the user...
>>
>> Yes, this should be done as a project element so that it can be accessed
>> from all of the main windows.  Please keep in mind, this could be a lot
>> of work and given that we are nearing a stable 5 release feature freeze,
>> so if it's not by then it will not make it into the stable 5 release.
>>
>> >
>> > Oliver
>> >
>> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <stambau...@gmail.com
>> > <mailto:stambau...@gmail.com>> wrote:
>> >
>> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
>> > > Hmm, I had thought that there was a way to load only the *names*
>> of
>> > > footprints, rather than individually parsing each footprint file.
>> It
>> > > appears that this is not the case. Any suggestions on how the
>> speed
>> > > could be improved? Currently I'm reading out all the footprint
>> names in
>> > > each footprint library and only storing the names (wxString)
>> rather than
>> > > the MODULE* objects. However, I still have to parse the entire
>> library
>> > > on load.
>> > >
>> > > Ideally, I think it would be good to just read in the names, and
>> then
>> > > load and display individual MODULE objects on demand.. Is this
>> possible?
>> >
>> > This is possible (although not implemented) for library types
>> (kicad,
>> > geda) that use one file per footprint.  You could just read the file
>> > names from the folder and load the files as required.  If you want
>> to
>> > search any other properties of the footprint, then you will have to
>> load
>> > all of the footprints anyway.  I don't know if this would be worth
>> the
>> > effort.
>> >
>> > For library types that contain multiple footprints per file (legacy,
>> > Eagle), this wouldn't make much sense.  Parsing the entire file
>> just to
>> > pick out the footprint names probably isn't going to save you very
>> much
>> > time.
>> >
>> > >
>> > > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh <
&g

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

[Oliver Walters]

Wayne,

I have finally found some time to readdress this.

I have reimplemented the filtering using the existing FOOTPRINT_FILTER
class. I have also reverted behaviour to work only on the currently
selected footprint library. This removes the requirement to load all the
libraries when the dialog opens.

I think all requirements are satisfied now. Please find modified patch set
attached.

Regards,
Oliver

On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> On 10/31/2017 5:01 PM, Oliver Walters wrote:
> > How should I proceed here then?
> >
> > I would like to see the various libraries being "cached" in the
> > background, but this is increasing the scope of the work by a large
> factor.
> >
> > One thing I have noticed:
> >
> > In eeschema when you launch the component viewer, it (on first run) maps
> > and caches all the footprint libraries. This can take AGES (especially
> > on Windows). However on subsequent launches of the component viewer it
> > appears instantly. It appears to be keeping a static map of the
> > footprint library data.
> >
> > a) Would this be an acceptable approach for the footprint viewer window
>
> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
> footprint library code is split out from the component chooser so it
> should be reusable.
>
> > b) What happens when the library data changes externally? Does component
> > viewer need to be reloaded?
>
> No, only the library that changed gets reloaded the next time it's
> accessed.  It is not automatic.  I thought about using wxFileWatcher but
> that could be a lot of overhead for little net gain.  See the pcb plugin
> cache() functions.
>
> > c) Can we globally perform this caching in a background thread when
> > KiCad launches? This will hide the large pauses (up to a minute under
> > Windows) from the user...
>
> Yes, this should be done as a project element so that it can be accessed
> from all of the main windows.  Please keep in mind, this could be a lot
> of work and given that we are nearing a stable 5 release feature freeze,
> so if it's not by then it will not make it into the stable 5 release.
>
> >
> > Oliver
> >
> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
> > > Hmm, I had thought that there was a way to load only the *names* of
> > > footprints, rather than individually parsing each footprint file.
> It
> > > appears that this is not the case. Any suggestions on how the speed
> > > could be improved? Currently I'm reading out all the footprint
> names in
> > > each footprint library and only storing the names (wxString)
> rather than
> > > the MODULE* objects. However, I still have to parse the entire
> library
> > > on load.
> > >
> > > Ideally, I think it would be good to just read in the names, and
> then
> > > load and display individual MODULE objects on demand.. Is this
> possible?
> >
> > This is possible (although not implemented) for library types (kicad,
> > geda) that use one file per footprint.  You could just read the file
> > names from the folder and load the files as required.  If you want to
> > search any other properties of the footprint, then you will have to
> load
> > all of the footprints anyway.  I don't know if this would be worth
> the
> > effort.
> >
> > For library types that contain multiple footprints per file (legacy,
> > Eagle), this wouldn't make much sense.  Parsing the entire file just
> to
> > pick out the footprint names probably isn't going to save you very
> much
> > time.
> >
> > >
> > > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > On 10/30/2017 5:23 PM, Oliver Walters wrote:
> > > > Thanks for the suggestions on fixing the text. I have that
> sorted.
> > > >
> > > > I will look into different ways of caching footprint data so
> it is quicker.
> > > >
> > > > Wayne, I didn't know about FOOTPRINT_FILTER I will switch to
> using that
> > > > instead (and provide regex search).
> > >
> > > Thanks Oliver!

Re: [Kicad-developers] [PATCH] LIB_TABLE tweaks

[Oliver Walters]

On Thu, Nov 16, 2017 at 1:42 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Gentlemen,
>
> I'm not sure about breaking the library table file format for the
> version 5 release.  If we do, the footprint library table will not be
> compatible with older versions.  I would prefer that we push this change
> into version 6.
>

I'm not sure I understand why it would be ok to break it in v6 but not v5?
We are already introducing the sym-lib-table. If we waited until v6 to make
this change, then we would break *both* tables (instead of just one).


>
> I'm OK with the progress dialog.  If you split that out as separate
> patch, I will merge it.
>
> Cheers,
>
> Wayne
>
> On 11/15/2017 9:38 AM, Tomasz Wlostowski wrote:
> > On 15/11/17 15:30, Maciej Suminski wrote:
> >> Hi Oliver,
> >>
> >> Thank you for restoring the progress bar dialog. While the library load
> >> time has recently decreased a lot, the UI freeze still happens with long
> >> library lists.
> >> Disclaimer: I have not looked at the code yet, I am just praising the
> idea.
> >>
> >> As you are looking on the Symbol Library Table dialog, I suppose you
> >> might be also tempted to add a file browser to add new libraries. If
> >> that is the case, please refrain from doing so - it is done in the
> >> library editor refactor branch. If you had no such intention, then
> >> simply ignore this message.
> >
> > Hi Olivier & Orson,
> >
> > I partially implemented the simplified dialog I proposed on the dev list
> > a few days ago. Would anyone be interested in helping me finish it?
> >
> > Tom
> >
> >>
> >> Cheers,
> >> Orson
> >>
> >> On 15/11/2017 12:41 PM, Oliver Walters wrote:
> >>> Wayne, et al,
> >>>
> >>> I am really liking the way that the new symbol table works! Thanks for
> >>> the huge effort that has gone into this.
> >>>
> >>> One thing that I have noticed is that when opening (for e.g.) the
> >>> component chooser, the UI hangs while all the libraries load.
> Previously
> >>> there was a progress dialog which at least informed the user what was
> >>> going on.
> >>>
> >>> I have re-implemented this dialog in the attached patch set.
> >>>
> >>> Further, I have also implemented a way to individually enable / disable
> >>> each row in the library tables (this works for SYMBOL_LIB and FP_LIB).
> >>>
> >>> This is based on the idea by Tomasz. Example screenshot below:
> >>>
> >>> Inline image 1
> >>>
> >>> I have tweaked the base LIB_TABLE_GRID code such that disabled entries
> >>> are greyed out and made italic. The enabled / disabled status is
> >>> persistent in the sym/fp_lib_table files. Older version of
> xxx_lib_table
> >>> files are read with all rows enabled by default.
> >>>
> >>> Please find patch set attached.
> >>>
> >>> 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
> >
> >
> > ___
> > 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] Library development.

[Oliver Walters]

Thanks Wayne, I'm really pleased with how it is all turned out! Thanks to
all who assisted and guided.



On 16 Nov 2017 04:47, "Wayne Stambaugh"  wrote:

> For those of you who have not seen the recent libraries section of the
> kicad website, I highly recommend you check it out when you get a
> chance.  It is really well done.  Hats off to the library development
> team for their efforts to make this happen.  Our libraries are really
> nice thanks to their efforts and will make a nice addition to the stable
> 5 release.  Keep up the great work.
>
> 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

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

[Oliver Walters]

Wayne,

Please find attached updated patch set. If an old version is detected,
inches are converted to mm.

On Tue, Nov 14, 2017 at 9:33 AM, Nick Østergaard <oe.n...@gmail.com> wrote:

> Just to mention it, I think this quirk needs to be put in the release
> notes for 5.0.0 if that would be the case, or at least documented as a
> note in the docs.
>
> 2017-11-13 18:10 GMT+01.00, Wayne Stambaugh <stambau...@gmail.com>:
> > On 11/12/2017 6:12 AM, Oliver Walters wrote:
> >> Wayne,
> >>
> >> Another potential spanner in the works - the footprint files do not
> >> store the file version information. (should they?)
> >
> > I would rather not.  Otherwise there would be a footprint version in
> > every footprint embedded in the schematic and could lead to some ugly
> > parser code.  At some point we may need to revisit this but not now.
> >
> > This is not a big issue because the only effects the footprints embedded
> > in the board.  Users with custom footprint libraries that contain 3D
> > model offsets will just have to fix the offsets.  I'm guessing this is a
> > fairly small number of users.
> >
> >>
> >> Thus, footprint files cannot be parsed differently based on their file
> >> version. Changing "at" between mm and inches will work for the pcb but
> >> not for the individual footprint files
> >>
> >> On Sun, Nov 12, 2017 at 7:47 AM, Wayne Stambaugh <stambau...@gmail.com
> >> <mailto:stambau...@gmail.com>> wrote:
> >>
> >> I misunderstood the intention of this patch.  I though it had
> nothing
> >> to
> >> do with the units change patch.  I will revert it.  Please send me
> the
> >> file format change patch when you get a chance and I merge them both
> >> at
> >> the same time.  Sorry about the mix up.
> >>
> >> On 11/11/2017 03:34 PM, Oliver Walters wrote:
> >> > Wayne,
> >> >
> >> > I had not yet made any changes to the file parser. Have you done
> >> this
> >> > according to your new file-version approach? Or do you want me to
> >> submit
> >> > a further patch implementing that?
> >> >
> >> > On 12 Nov 2017 07:16, "Wayne Stambaugh" <stambau...@gmail.com
> >> <mailto:stambau...@gmail.com>
> >> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> >> >
> >> > Oliver,
> >> >
> >> > I committed your patch to the KiCad development branch.
> >> >
> >> > Thanks,
> >> >
> >> > Wayne
> >> >
> >> > On 11/08/2017 05:05 AM, Oliver Walters wrote:
> >> > > Attached is a patch that fixes the problems I found in my 3D
> >> model
> >> > array
> >> > > investigation. As discussion on that is stalled for now,
> >> this patch
> >> > > simply fixes the model offset issues.
> >> > >
> >> > > 1. Display offset units in 3D preview window
> >> > >
> >> > > - Offset units are displayed (either inches or mm)
> >> > >
> >> > > 2. Fix offset in 3D rendering
> >> > >
> >> > > - It appears that the internal units for 3D model offset
> >> (mm) were
> >> > being
> >> > > multiplied by 25.4 incorrectly
> >> > > - Fixed rendering in OGL and Raytracing
> >> > >
> >> > > 3. Fix offset in 3D export
> >> > >
> >> > > - VRML export
> >> > > - STEP export
> >> > >
> >> > > Oliver
> >> > >
> >> > >
> >> > > ___
> >> > > Mailing list: https://launchpad.net/~kicad-developers
> >> <https://launchpad.net/~kicad-developers>
> >> > <https://launchpad.net/~kicad-developers
> >> <https://launchpad.net/~kicad-developers>>
> >> > > Post to : kicad-developers@lists.launchpad.net
> >> <mailto:kicad-developers@lists.launchpad.net>
> >> > <mailto:kicad

Re: [Kicad-developers] [RFC] redesign of Library Table dialog

[Oliver Walters]

>
>
> I like it. What options would you put in the "library options" section?


I'm not sure. I include it only with the thought that perhaps in the future
we will have global library options. It would probably not be present in
the initial version of the dialog.

On Mon, Nov 13, 2017 at 8:10 AM, Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:

> On 12/11/17 01:44, Oliver Walters wrote:
>
> Hi Olivier,
>
> Many thanks for your comments, my answers below:
>
> > Regarding the "advanced options" button, why not have an extra button
> > (next to Add / Remove / etc) which says "Edit". Clicking on this brings
> > up a dialog for the selected library with all extra options...
>
> I would keep the current library table dialog as it is under the
> advanced button, so that the users who already got used to it remain
> happy. It's also less coding work for us.
>
> >
> > Should the footprints / symbols / etc / all appear in the same list? I
> > like the idea of a single library preferences dialog, but what if the
> > various library types were separated by a panel on the left hand side,
> > as is common in many preferences windows?  I'm thinking of Eclipse as an
> > example.
> My idea was to have a structured table using wxDataView (as in [1]), but
> I'm not opposed to have a tree control to select between SCH/PCB/other
> (e.g. SPICE) libraries.
>
>
> >
> > Here is an example of something I have in a development branch (that has
> > been wanting my attention for some time). The core code to make this
> > dialog style is pretty solid, so I could share that part with you i>
> think this is a good idea.
>
> I like it. What options would you put in the "library options" section?
>
> Cheers,
> Tom
>
>
> [1]
> https://www.google.fr/url?sa=i=j==s=
> images==rja=8=0ahUKEwj1jp7n-LnXAhUHOxoKHdxgCMAQjRwIBw=
> https%3A%2F%2Fwxpython.org%2FPhoenix%2Fdocs%2Fhtml%2Fwx.
> dataview.DataViewCtrl.html=AOvVaw2ALsZb-bFXnvvx9LumvJkd=
> 1510607285812822
>
___
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] Fix for 3D model offset

[Oliver Walters]

Wayne,

Another potential spanner in the works - the footprint files do not store
the file version information. (should they?)

Thus, footprint files cannot be parsed differently based on their file
version. Changing "at" between mm and inches will work for the pcb but not
for the individual footprint files.

On Sun, Nov 12, 2017 at 7:47 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> I misunderstood the intention of this patch.  I though it had nothing to
> do with the units change patch.  I will revert it.  Please send me the
> file format change patch when you get a chance and I merge them both at
> the same time.  Sorry about the mix up.
>
> On 11/11/2017 03:34 PM, Oliver Walters wrote:
> > Wayne,
> >
> > I had not yet made any changes to the file parser. Have you done this
> > according to your new file-version approach? Or do you want me to submit
> > a further patch implementing that?
> >
> > On 12 Nov 2017 07:16, "Wayne Stambaugh" <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > Oliver,
> >
> > I committed your patch to the KiCad development branch.
> >
> > Thanks,
> >
> > Wayne
> >
> > On 11/08/2017 05:05 AM, Oliver Walters wrote:
> > > Attached is a patch that fixes the problems I found in my 3D model
> > array
> > > investigation. As discussion on that is stalled for now, this patch
> > > simply fixes the model offset issues.
> > >
> > > 1. Display offset units in 3D preview window
> > >
> > > - Offset units are displayed (either inches or mm)
> > >
> > > 2. Fix offset in 3D rendering
> > >
> > > - It appears that the internal units for 3D model offset (mm) were
> > being
> > > multiplied by 25.4 incorrectly
> > > - Fixed rendering in OGL and Raytracing
> > >
> > > 3. Fix offset in 3D export
> > >
> > > - VRML export
> > > - STEP export
> > >
> > > Oliver
> > >
> > >
> > > ___
> > > 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
> > <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

Re: [Kicad-developers] [RFC] redesign of Library Table dialog

[Oliver Walters]

Simon,

I agree that we should not use wxGrid for such a dialog. Other wx classes
are somewhat harder to use but provide a much better interface (once you
get them right).

On Sun, Nov 12, 2017 at 11:46 AM, Simon Wells <swel...@gmail.com> wrote:

> would it not be better to use one of the types that uses native tables
> rather than wxgrid? what is wxgrid giving you that the native tables aren't?
>
>
> On 12/11/2017, at 13:44, Oliver Walters <oliver.henry.walt...@gmail.com>
> wrote:
>
> Hi Tom,
>
> This is a fantastic idea, I think that your mock up has a lot of good UX
> improvements.
>
> In particular I like the idea of "active" for each library. You then do
> not have to find a library once you have removed it from the table, only
> tick "active". Brilliant.
>
> Regarding the "advanced options" button, why not have an extra button
> (next to Add / Remove / etc) which says "Edit". Clicking on this brings up
> a dialog for the selected library with all extra options...
>
> Should the footprints / symbols / etc / all appear in the same list? I
> like the idea of a single library preferences dialog, but what if the
> various library types were separated by a panel on the left hand side, as
> is common in many preferences windows?  I'm thinking of Eclipse as an
> example.
>
> Here is an example of something I have in a development branch (that has
> been wanting my attention for some time). The core code to make this dialog
> style is pretty solid, so I could share that part with you if you think
> this is a good idea.
>
>
> 
>
> I'm thinking that the window above would be adapted to have in the left
> column:
>
> "Library Options"
> "Symbol Libraries"
> "Footprint Libraries"
>
> Overall I am really behind your idea :)
>
> On Sun, Nov 12, 2017 at 11:01 AM, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
>> Dear colleagues,
>>
>> Now that we have the new library table system in the schematic editor
>> (may thanks Wayne!), we also have the library table dialog to configure
>> the tables.
>>
>> For many users - including myself - these dialogs are a bit too complex.
>>  A few days ago I asked the Polish Kicad community of what users find
>> annoying and the complexity of the library manager window was heavily
>> criticized. The main points were exposing too many advanced functions
>> straight away (such as special configuration options for each plugin)
>> and requiring the user to type in the library paths by hand or paste
>> them instead of selecting the files with a browser. Currently I prefer
>> editing the lib-table files by hand instead of using the GUI.
>>
>> I believe that the introduction of the new library system into eeschema
>> is a good chance to consolidate the library management UI and improve
>> Kicad's User Experience. In the attachment, you'll find the example
>> design of simplified library setup dialog, with some remarks and
>> comments. Your feedback will be greatly appreciated!
>>
>> Tom
>>
>> PS1. I haven't started coding yet - this is just a mockup.
>> PS2. The current library table dialog will remain accessible if the user
>> selects the 'show advanced options' checkbox - so if some of you prefer
>> the current UI, it's not going to disappear :)
>>
>>
>>
>>
>>
>> ___
>> 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] [RFC] redesign of Library Table dialog

[Oliver Walters]

Tom,

Another thought I have had which would address some ongoing discussion
regarding default library paths.

I think that the table(s) should show which libraries are located in
'read-only' locations. I am not sure how to determine this in an OS
independent manner, but I think that it would be a really good feature -
currently users get very confused regarding library paths.

Perhaps greyed out text, with a hover tool tip?

Oliver

On Sun, Nov 12, 2017 at 11:01 AM, Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:

> Dear colleagues,
>
> Now that we have the new library table system in the schematic editor
> (may thanks Wayne!), we also have the library table dialog to configure
> the tables.
>
> For many users - including myself - these dialogs are a bit too complex.
>  A few days ago I asked the Polish Kicad community of what users find
> annoying and the complexity of the library manager window was heavily
> criticized. The main points were exposing too many advanced functions
> straight away (such as special configuration options for each plugin)
> and requiring the user to type in the library paths by hand or paste
> them instead of selecting the files with a browser. Currently I prefer
> editing the lib-table files by hand instead of using the GUI.
>
> I believe that the introduction of the new library system into eeschema
> is a good chance to consolidate the library management UI and improve
> Kicad's User Experience. In the attachment, you'll find the example
> design of simplified library setup dialog, with some remarks and
> comments. Your feedback will be greatly appreciated!
>
> Tom
>
> PS1. I haven't started coding yet - this is just a mockup.
> PS2. The current library table dialog will remain accessible if the user
> selects the 'show advanced options' checkbox - so if some of you prefer
> the current UI, it's not going to disappear :)
>
>
>
>
>
> ___
> 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] [RFC] redesign of Library Table dialog

[Oliver Walters]

Hi Tom,

This is a fantastic idea, I think that your mock up has a lot of good UX
improvements.

In particular I like the idea of "active" for each library. You then do not
have to find a library once you have removed it from the table, only tick
"active". Brilliant.

Regarding the "advanced options" button, why not have an extra button (next
to Add / Remove / etc) which says "Edit". Clicking on this brings up a
dialog for the selected library with all extra options...

Should the footprints / symbols / etc / all appear in the same list? I like
the idea of a single library preferences dialog, but what if the various
library types were separated by a panel on the left hand side, as is common
in many preferences windows?  I'm thinking of Eclipse as an example.

Here is an example of something I have in a development branch (that has
been wanting my attention for some time). The core code to make this dialog
style is pretty solid, so I could share that part with you if you think
this is a good idea.


[image: Inline image 1]

I'm thinking that the window above would be adapted to have in the left
column:

"Library Options"
"Symbol Libraries"
"Footprint Libraries"

Overall I am really behind your idea :)

On Sun, Nov 12, 2017 at 11:01 AM, Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:

> Dear colleagues,
>
> Now that we have the new library table system in the schematic editor
> (may thanks Wayne!), we also have the library table dialog to configure
> the tables.
>
> For many users - including myself - these dialogs are a bit too complex.
>  A few days ago I asked the Polish Kicad community of what users find
> annoying and the complexity of the library manager window was heavily
> criticized. The main points were exposing too many advanced functions
> straight away (such as special configuration options for each plugin)
> and requiring the user to type in the library paths by hand or paste
> them instead of selecting the files with a browser. Currently I prefer
> editing the lib-table files by hand instead of using the GUI.
>
> I believe that the introduction of the new library system into eeschema
> is a good chance to consolidate the library management UI and improve
> Kicad's User Experience. In the attachment, you'll find the example
> design of simplified library setup dialog, with some remarks and
> comments. Your feedback will be greatly appreciated!
>
> Tom
>
> PS1. I haven't started coding yet - this is just a mockup.
> PS2. The current library table dialog will remain accessible if the user
> selects the 'show advanced options' checkbox - so if some of you prefer
> the current UI, it's not going to disappear :)
>
>
>
>
>
> ___
> 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] Fix for 3D model offset

[Oliver Walters]

Wayne,

I had not yet made any changes to the file parser. Have you done this
according to your new file-version approach? Or do you want me to submit a
further patch implementing that?

On 12 Nov 2017 07:16, "Wayne Stambaugh" <stambau...@gmail.com> wrote:

> Oliver,
>
> I committed your patch to the KiCad development branch.
>
> Thanks,
>
> Wayne
>
> On 11/08/2017 05:05 AM, Oliver Walters wrote:
> > Attached is a patch that fixes the problems I found in my 3D model array
> > investigation. As discussion on that is stalled for now, this patch
> > simply fixes the model offset issues.
> >
> > 1. Display offset units in 3D preview window
> >
> > - Offset units are displayed (either inches or mm)
> >
> > 2. Fix offset in 3D rendering
> >
> > - It appears that the internal units for 3D model offset (mm) were being
> > multiplied by 25.4 incorrectly
> > - Fixed rendering in OGL and Raytracing
> >
> > 3. Fix offset in 3D export
> >
> > - VRML export
> > - STEP export
> >
> > 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
>
___
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] Fix for 3D model offset

[Oliver Walters]

JP,

Yes I will update with a patch.

On 11 Nov 2017 19:45, "jp charras" <jp.char...@wanadoo.fr> wrote:

> Le 09/11/2017 à 21:48, Oliver Walters a écrit :
> > JP,
> >
> > I think that 3) is the better option, because it preservers PCB file
> compatibility (as long as the
> > offset is zero). Any time the PCB is saved, the (at (xyz 0 0 0)) gets
> written.
> >
> > You are also correct that none of the official library footprints have a
> defined offset. This is why
> > i have never encountered this before.
>
> So I also think 3 is the better option:
>
> (at (xyz nn mm ll)) is read as position in inches (old files)
> (offset(xyz nn mm ll)) is read as position in mm (new files)
>
> And the position is written in file only if not 0 (that is the case of our
> footprint files) to avoid
> breaking the compatibility with older Pcbnew version when not mandatory,
> at least for now.
>
> Could you prepare a patch?
> Thanks.
>
> >
> > On Fri, Nov 10, 2017 at 7:09 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com
> > <mailto:oliver.henry.walt...@gmail.com>> wrote:
> >
> > I like 2) or 3) - I think that a major release is a good time to fix
> such a bug.
> >
> > Would you like me to add a patch implementing one of these options
> JP?
> >
> > On 9 Nov 2017 23:33, "Kristoffer Ödmark" <
> kristofferodmar...@gmail.com
> > <mailto:kristofferodmar...@gmail.com>> wrote:
> >
> > Currently the footprints arent compatible anyway i guess, they
> support more than 4.07
> > footprints do. So option 2 is my preferred solution.
> >
> > On 11/09/2017 12:51 PM, jp charras wrote:
> >
> > Le 09/11/2017 à 11:12, Kristoffer Ödmark a écrit :
> >
> > My 2 cents is that the headaches of storing values in
> mixed units, without
> > indication of which unit
> > they are stored as is a huge drawback for readability of
> the saved files and for
> > maintainability.
> >
> > Also I think the proposed new tag offset is a good idea,
> since the libraries can be
> > gradually
> > updated then. That the files cannot be opened by
> previous versions is a minor
> > problem, since the
> > files cannot be opened by kicad 4.07 anyway already.
> >
> >
> > In fact, footprint files can be opened by 4.07 version, as
> long as they contain no round
> > rect or
> > custom pads (should be most of files)
> >
> >
> > On 11/09/2017 12:55 AM, Wayne Stambaugh wrote:
> >
> > This requires a file version bump and code that
> tests for prior versions
> > before converting the units on read.  At that point,
> the file will no
> > longer be compatible with prior version of KiCad.
> I'm not opposed to
> > this but I'm not sure it's worth the headaches it
> will cause.
> >
> > On 11/08/2017 03:33 PM, Oliver Walters wrote:
> >
> > What about a controversial idea:
> >
> > Read "at" dimensions as inches, but new files
> write "offset" in mm.
> >
> > This preserves read compatibility but fixes the
> units issue going forward.
> >
> > <...>
> >
> > There are 3 different things related to the anchor
> coordinate 3D shapes in Oliver's patch:
> >
> > 1 - coordinate units inside Kicad: they should be in
> internal units
> > (I do not remember if it is currently the case).
> > no problem.
> >
> > 2 - Display unit name in dialog: good enhancement.
> >
> > 3 - how to store this anchor coordinate in .kicad_pcb files.
> > There are 2 options:
> > opt 1 - use keyword "at" and store it in inches (current
> case). Certainly annoying
> > because all other
> > coordinates use mm, but this is not a major issue.
> > opt 2 - be able to read "at" (inches) and "offset" (or
> perhaps "anchor") (in mm) and use
> > offset as
> > new keyword: but it breaks compatibility with old (namely
> the recent 4.07) kicad version.
> > opt 

[Kicad-developers] [PATCH] Change default repo for 3D model downloader

[Oliver Walters]

This patch changes the default directory for the 3D model downloader tool.

The new 3d model repository is at https://github.com/kicad/kicad-packages3d
From dc2d5176a1aab8872068238afb02cafd909e12bd Mon Sep 17 00:00:00 2001
From: Oliver 
Date: Sat, 11 Nov 2017 10:06:25 +1100
Subject: [PATCH] Change default 3D model repository

- New location is kicad-packages3d
---
 pcbnew/dialogs/wizard_3DShape_Libs_downloader.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/pcbnew/dialogs/wizard_3DShape_Libs_downloader.cpp b/pcbnew/dialogs/wizard_3DShape_Libs_downloader.cpp
index 021282b..a366cab 100644
--- a/pcbnew/dialogs/wizard_3DShape_Libs_downloader.cpp
+++ b/pcbnew/dialogs/wizard_3DShape_Libs_downloader.cpp
@@ -52,7 +52,8 @@
 #define KICAD_3DLIBS_LAST_DOWNLOAD_DIR wxT( "kicad_3Dlib_last_download_dir" )
 
 #define DEFAULT_GITHUB_3DSHAPES_LIBS_URL \
-wxT( "https://github.com/KiCad/kicad-library/tree/master/modules/packages3d; )
+"https://github.com/KiCad/kicad-packages3d;
+//wxT( "https://github.com/KiCad/kicad-library/tree/master/modules/packages3d; )
 
 void Invoke3DShapeLibsDownloaderWizard( wxTopLevelWindow* aCaller )
 {
-- 
2.7.4

___
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] Symbol library table merged.

[Oliver Walters]

What is the reasoning behind not wanting to use threads?

On Fri, Nov 10, 2017 at 11:46 PM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> On 11/10/2017 7:36 AM, Oliver Walters wrote:
> > Wayne,
> >
> > You're probably right that there's no good way to decide which libraries
> > are the "default" ones. Maybe this is the best entry-level approach.
> >
> > I think that a background library loader will solve a lot of the
> > "freeze" problems, but I imagine that is a lot of work.
>
> It will not be trivial loading libraries in the background but it's
> something we need to look into at some point.  I was thinking about
> loading one library on each idle event rather than in a separate thread
> although this could cause some UI lag issues with the github libraries.
> This is a task for version 6 so I'm going to shelve this until after the
> version 5 release.  I will add it to the version 6 road map when I get a
> chance.
>
> >
> > On Fri, Nov 10, 2017 at 11:17 PM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > Oliver,
> >
> > Including all of the libraries has been requested many times in the
> > past.  Personally, I don't work that way but it seems to be the
> > preference of a large percentage of users.  My guess is new users
> will
> > prefer to have access to all libraries initially and start removing
> them
> > when they get tired of the the overhead involved in using them.  I
> >     wouldn't be opposed to removing some of them but I doubt you will
> get a
> > consensus on this issue.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 11/9/2017 10:38 PM, Oliver Walters wrote:
> > > Wayne,
> > >
> > > That's great news, and a welcome addition.
> > >
> > > Regarding the decision to include all the libraries by default -
> is this
> > > a sensible solution? No project requires all libraries to be
> added, and
> > > some of the libraries are particularly large. Is it really that
> > > difficult for new users to understand that libraries are there to
> be
> > > added and removed at will? Personally if I found all libraries
> loaded by
> > > default I would unload most of them straight away...
> > >
> > > Perhaps I am not aware of the justification for this approach.
> > >
> > > Cheers,
> > >
> > > Oliver
> > >
> > > On Fri, Nov 10, 2017 at 1:35 PM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > I finally got the symbol library table changes merged into the
> > > development branch of KiCad so be prepared for some pretty
> > significant
> > > changes in the way symbol libraries are handled both from a
> > user and a
> > > developer perspective.  Also be prepared for a massive amount
> of
> > > complaining about the change.  I wrote a blog post for the
> KiCad
> > > website[1] with all of the pertinent information you need to
> > know before
> > > you remap your schematic symbols.  If users have any
> > questions, please
> > > point them to blog post.  One thing I didn't mention in the
> > blog post
> > > (although I may add it) is the component (now symbol) chooser
> > dialog
> > > took another performance hit.  The default global symbol
> > library table
> > > contains all of the symbol libraries of which there are over
> > 90 so the
> > > symbol library load time shot up significantly when using the
> > chooser.
> > > The Eeschema load time actually go better since like the
> footprint
> > > library table, symbol libraries are now loaded on demand so
> > only the
> > > libraries that contain symbols in the schematic get loaded.
> > The rest of
> > > them get loaded as required.  If you find any issues please
> > file a bug
> > > report and include a copy of the project files and symbol
> > libraries (if
> > > possible) prior to the remapping that are causing the issue so
> > I can fix
> > > them.
> > >
> >

Re: [Kicad-developers] Symbol library table merged.

[Oliver Walters]

Great, I'm glad to hear that it is in the pipeline :)

On Fri, Nov 10, 2017 at 11:46 PM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> On 11/10/2017 7:36 AM, Oliver Walters wrote:
> > Wayne,
> >
> > You're probably right that there's no good way to decide which libraries
> > are the "default" ones. Maybe this is the best entry-level approach.
> >
> > I think that a background library loader will solve a lot of the
> > "freeze" problems, but I imagine that is a lot of work.
>
> It will not be trivial loading libraries in the background but it's
> something we need to look into at some point.  I was thinking about
> loading one library on each idle event rather than in a separate thread
> although this could cause some UI lag issues with the github libraries.
> This is a task for version 6 so I'm going to shelve this until after the
> version 5 release.  I will add it to the version 6 road map when I get a
> chance.
>
> >
> > On Fri, Nov 10, 2017 at 11:17 PM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > Oliver,
> >
> > Including all of the libraries has been requested many times in the
> > past.  Personally, I don't work that way but it seems to be the
> > preference of a large percentage of users.  My guess is new users
> will
> > prefer to have access to all libraries initially and start removing
> them
> > when they get tired of the the overhead involved in using them.  I
> >     wouldn't be opposed to removing some of them but I doubt you will
> get a
> > consensus on this issue.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 11/9/2017 10:38 PM, Oliver Walters wrote:
> > > Wayne,
> > >
> > > That's great news, and a welcome addition.
> > >
> > > Regarding the decision to include all the libraries by default -
> is this
> > > a sensible solution? No project requires all libraries to be
> added, and
> > > some of the libraries are particularly large. Is it really that
> > > difficult for new users to understand that libraries are there to
> be
> > > added and removed at will? Personally if I found all libraries
> loaded by
> > > default I would unload most of them straight away...
> > >
> > > Perhaps I am not aware of the justification for this approach.
> > >
> > > Cheers,
> > >
> > > Oliver
> > >
> > > On Fri, Nov 10, 2017 at 1:35 PM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > I finally got the symbol library table changes merged into the
> > > development branch of KiCad so be prepared for some pretty
> > significant
> > > changes in the way symbol libraries are handled both from a
> > user and a
> > > developer perspective.  Also be prepared for a massive amount
> of
> > > complaining about the change.  I wrote a blog post for the
> KiCad
> > > website[1] with all of the pertinent information you need to
> > know before
> > > you remap your schematic symbols.  If users have any
> > questions, please
> > > point them to blog post.  One thing I didn't mention in the
> > blog post
> > > (although I may add it) is the component (now symbol) chooser
> > dialog
> > > took another performance hit.  The default global symbol
> > library table
> > > contains all of the symbol libraries of which there are over
> > 90 so the
> > > symbol library load time shot up significantly when using the
> > chooser.
> > > The Eeschema load time actually go better since like the
> footprint
> > > library table, symbol libraries are now loaded on demand so
> > only the
> > > libraries that contain symbols in the schematic get loaded.
> > The rest of
> > > them get loaded as required.  If you find any issues please
> > file a bug
> > > report and include a copy of the project files and symbol
> > libraries (if
> > > possible) prior to the remapping that are causing the issue so
> > I can fix
> > > them.
> > >
> >

Re: [Kicad-developers] Symbol library table merged.

[Oliver Walters]

Wayne,

You're probably right that there's no good way to decide which libraries
are the "default" ones. Maybe this is the best entry-level approach.

I think that a background library loader will solve a lot of the "freeze"
problems, but I imagine that is a lot of work.

On Fri, Nov 10, 2017 at 11:17 PM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Oliver,
>
> Including all of the libraries has been requested many times in the
> past.  Personally, I don't work that way but it seems to be the
> preference of a large percentage of users.  My guess is new users will
> prefer to have access to all libraries initially and start removing them
> when they get tired of the the overhead involved in using them.  I
> wouldn't be opposed to removing some of them but I doubt you will get a
> consensus on this issue.
>
> Cheers,
>
> Wayne
>
> On 11/9/2017 10:38 PM, Oliver Walters wrote:
> > Wayne,
> >
> > That's great news, and a welcome addition.
> >
> > Regarding the decision to include all the libraries by default - is this
> > a sensible solution? No project requires all libraries to be added, and
> > some of the libraries are particularly large. Is it really that
> > difficult for new users to understand that libraries are there to be
> > added and removed at will? Personally if I found all libraries loaded by
> > default I would unload most of them straight away...
> >
> > Perhaps I am not aware of the justification for this approach.
> >
> > Cheers,
> >
> > Oliver
> >
> > On Fri, Nov 10, 2017 at 1:35 PM, Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > I finally got the symbol library table changes merged into the
> > development branch of KiCad so be prepared for some pretty
> significant
> > changes in the way symbol libraries are handled both from a user and
> a
> > developer perspective.  Also be prepared for a massive amount of
> > complaining about the change.  I wrote a blog post for the KiCad
> > website[1] with all of the pertinent information you need to know
> before
> > you remap your schematic symbols.  If users have any questions,
> please
> > point them to blog post.  One thing I didn't mention in the blog post
> > (although I may add it) is the component (now symbol) chooser dialog
> > took another performance hit.  The default global symbol library
> table
> > contains all of the symbol libraries of which there are over 90 so
> the
> > symbol library load time shot up significantly when using the
> chooser.
> > The Eeschema load time actually go better since like the footprint
> > library table, symbol libraries are now loaded on demand so only the
> > libraries that contain symbols in the schematic get loaded.  The
> rest of
> > them get loaded as required.  If you find any issues please file a
> bug
> > report and include a copy of the project files and symbol libraries
> (if
> > possible) prior to the remapping that are causing the issue so I can
> fix
> > them.
> >
> > This should be the last major change except for the new symbol
> library
> > manager before the feature freeze of the stable 5 version.  Thank you
> > for your patience during this transition and enjoy.
> >
> > Cheers,
> >
> > Wayne
> >
> > [1]: http://kicad-pcb.org/post/symbol-lib-table/
> > <http://kicad-pcb.org/post/symbol-lib-table/>
> >
> > ___
> > 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

Re: [Kicad-developers] Symbol library table merged.

[Oliver Walters]

Wayne,

That's great news, and a welcome addition.

Regarding the decision to include all the libraries by default - is this a
sensible solution? No project requires all libraries to be added, and some
of the libraries are particularly large. Is it really that difficult for
new users to understand that libraries are there to be added and removed at
will? Personally if I found all libraries loaded by default I would unload
most of them straight away...

Perhaps I am not aware of the justification for this approach.

Cheers,

Oliver

On Fri, Nov 10, 2017 at 1:35 PM, Wayne Stambaugh 
wrote:

> I finally got the symbol library table changes merged into the
> development branch of KiCad so be prepared for some pretty significant
> changes in the way symbol libraries are handled both from a user and a
> developer perspective.  Also be prepared for a massive amount of
> complaining about the change.  I wrote a blog post for the KiCad
> website[1] with all of the pertinent information you need to know before
> you remap your schematic symbols.  If users have any questions, please
> point them to blog post.  One thing I didn't mention in the blog post
> (although I may add it) is the component (now symbol) chooser dialog
> took another performance hit.  The default global symbol library table
> contains all of the symbol libraries of which there are over 90 so the
> symbol library load time shot up significantly when using the chooser.
> The Eeschema load time actually go better since like the footprint
> library table, symbol libraries are now loaded on demand so only the
> libraries that contain symbols in the schematic get loaded.  The rest of
> them get loaded as required.  If you find any issues please file a bug
> report and include a copy of the project files and symbol libraries (if
> possible) prior to the remapping that are causing the issue so I can fix
> them.
>
> This should be the last major change except for the new symbol library
> manager before the feature freeze of the stable 5 version.  Thank you
> for your patience during this transition and enjoy.
>
> Cheers,
>
> Wayne
>
> [1]: http://kicad-pcb.org/post/symbol-lib-table/
>
> ___
> 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] Fix for 3D model offset

[Oliver Walters]

Maurice,

The error is that the offset is stored (file format) in inches but it
should be mm.

Now that I know that the issue is in the file, I'm happy that the internals
to KiCad were working well, it just didn't make sense for the assumption
that units were in mm

On 10 Nov 2017 08:39, "easyw" <ea...@katamail.com> wrote:

Hi Oliver,

could you please explain me if the proposed patch/rework is fixing an issue
in 3d visualization and/or exporting or just changing the fact that ATM the
offset is stored in inches, compared to other values in mm?

I remember that Mario avoided to change the internal kicad_pcb format, but
fixed the displaying of the offset calculating it correctly and displaying
correctly the value in inches or millimeters, depending on the pcb settings
both in the editor or the model ...

I never noticed a wrong offset in VRML when exporting a board and parts
using the offset...
Nor I noticed a wrong offset in 3D viewer ...

I could say nothing about the step exporter because I use mine and so I
never tested the internal step exporter...

I attached an image of two cubes, the red is 1x1x1mm and the blue is
2x1x0.5mm.
I applied an offset of 1x1x1 in mm to the second one, and the reciprocal
positions are fine; moreover when I select the units to mm I get the offset
displayed in mm, and if I set the unit in inches, the offset is displayed
in inches...

Maurice



On 11/9/2017 9:09 PM, Oliver Walters wrote:

> I like 2) or 3) - I think that a major release is a good time to fix such
> a bug.
>
> Would you like me to add a patch implementing one of these options JP?
>
> On 9 Nov 2017 23:33, "Kristoffer Ödmark" <kristofferodmar...@gmail.com
> <mailto:kristofferodmar...@gmail.com>> wrote:
>
> Currently the footprints arent compatible anyway i guess, they
> support more than 4.07 footprints do. So option 2 is my preferred
> solution.
>
> On 11/09/2017 12:51 PM, jp charras wrote:
>
> Le 09/11/2017 à 11:12, Kristoffer Ödmark a écrit :
>
> My 2 cents is that the headaches of storing values in mixed
> units, without indication of which unit
> they are stored as is a huge drawback for readability of the
> saved files and for maintainability.
>
> Also I think the proposed new tag offset is a good idea,
> since the libraries can be gradually
> updated then. That the files cannot be opened by previous
> versions is a minor problem, since the
> files cannot be opened by kicad 4.07 anyway already.
>
>
> In fact, footprint files can be opened by 4.07 version, as long
> as they contain no round rect or
> custom pads (should be most of files)
>
>
> On 11/09/2017 12:55 AM, Wayne Stambaugh wrote:
>
> This requires a file version bump and code that tests
> for prior versions
> before converting the units on read.  At that point, the
> file will no
> longer be compatible with prior version of KiCad.  I'm
> not opposed to
> this but I'm not sure it's worth the headaches it will
> cause.
>
> On 11/08/2017 03:33 PM, Oliver Walters wrote:
>
> What about a controversial idea:
>
> Read "at" dimensions as inches, but new files write
> "offset" in mm.
>
> This preserves read compatibility but fixes the
> units issue going forward.
>
> <...>
>
> There are 3 different things related to the anchor coordinate 3D
> shapes in Oliver's patch:
>
> 1 - coordinate units inside Kicad: they should be in internal units
> (I do not remember if it is currently the case).
> no problem.
>
> 2 - Display unit name in dialog: good enhancement.
>
> 3 - how to store this anchor coordinate in .kicad_pcb files.
> There are 2 options:
> opt 1 - use keyword "at" and store it in inches (current case).
> Certainly annoying because all other
> coordinates use mm, but this is not a major issue.
> opt 2 - be able to read "at" (inches) and "offset" (or perhaps
> "anchor") (in mm) and use offset as
> new keyword: but it breaks compatibility with old (namely the
> recent 4.07) kicad version.
> opt 3 - same as 2, but stores "offset" (or "anchor") *only* if
> it is not the default value (0 0 0).
> AFAIK, the default value is the case of most (