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] Update of KiCad documentation?

[hauptmech]

A URL into the documentation would probably lessen the friction of 
locating exactly what section of documentation needs fixing. Dev's 
changing user facing stuff will be familiar with (if not actively 
stubbing out, or updating the docs) it so it seems a reasonable ask.


CHANGED: Synopsis. url#section

Consider just one keyword (CHANGE, or FEATURE) so we are not doing "git 
log --grep=CHANGE|NEW|REMOVED"


On 10/11/17 05:44, Wayne Stambaugh wrote:

I like this idea as well.  It's simple and easy to remember.  If there
are no objections, I will updated the commit message policy to add NEW,
CHANGED, and REMOVED tags and a brief explanation of when each tag
should be used.  Is there any special formatting that we want to use
with these tags to make life easier for folks trying to extract
information using scripts?  Rather than adding the tag to the end which
may be a bit limiting, I was thinking it may make more sense to add the
tag to the beginning of the description of the change separated by empty
lines.  It could look something like this.

Major rewrite of some existing feature.

NEW: The feature adds support for X, Y, and Z operations.

REMOVED: The feature no longer supports the foo operation.

CHANGED: The feature operations bar and baz now require manual frobnication.

If anyone has any better ideas, now is the time.

Cheers,

Wayne

On 11/9/2017 11:06 AM, Maciej Sumiński wrote:

I am in favor of including the information in commit messages. In the
simplest version, one can simple append "CHANGE" at the end of a commit
message. If we follow this scheme, then to get a changelog it is enough
to execute "git log --grep=CHANGE". One can also modify the query to get
changelog for different periods.

It is a tiny effort on the developers side which significantly helps
people willing to work on the documentation, therefore I think it is
worth pursuing. The only possible problem I see here is to get into the
habit, but we did well with "Fixes".

Regards,
Orson

On 11/09/2017 01:40 PM, Nick Østergaard wrote:

I didn't mean to indicate that one shall not write useful commit messages
in the kicad source repo. The start of this topic was how to make sure to
keep the doc up to date. This is what I was trying to comment on. Here it
is better to track the work where it is to be done, in the kicad-doc repo.
That does not hinder anyone from grepping the kicad commit log for new
features, when one gets the urge to create documentation. This shall of
course not hinder anyone who submits a feature to kicad to also submit
documentation updates for it either.

When we release I expect a release note to be composed that will describe
the new features as we did with http://kicad-pcb.org/post/release-4.0.0/

2017-11-09 12:39 GMT+01:00 Kristoffer Ödmark :


That doesnt sound like a good idea, when adding patches, just having to
add a line or two to the commit message seems best, and I imagine the news
or changelog file is just there to later help the kicad-doc repo to do a
proper changelog. Having to go to a new repo seems a bit more annoying.

Or skip the file totally this time, and just enfore the commit messages.
This way this will not be such a hassle next time one wonders what have
changed between versions.

On 11/09/2017 11:05 AM, Nick Østergaard wrote:


I think this might be better handled as bugs on the kicad-doc repo. Then
everyone can contribute easily and we can track it for the documentation,
where the info is to be used anyways. For now label them new_kicad_feature
if it is.

2017-11-09 10:54 GMT+01:00 Kristoffer Ödmark <
kristofferodmar...@gmail.com >:


 I think for this to start happen, a decision has to be made, and
 enforced by everyone with commit access to the repo.

 Bugfixes need not be tagged like this. Major changes only.

 I still think a we should start collect a list in the repo with
 changes from kicad 4 up to the point this commit message policy is
 set. I for one love reading changelogs when upgrading, and I think
 the users are expecting this as well, and it probably will be useful
 in the FOSDEM presentation :)


 On 11/04/2017 01:53 AM, Wayne Stambaugh wrote:

 On 11/3/2017 8:54 AM, Maciej Sumiński wrote:

 On 11/03/2017 11:30 AM, Kristoffer Ödmark wrote:

 I think starting small would be best in this case. The
 least needed
 would be a "News" File, that is always refering to kicad
 stable.

 I propose the same way that patches with policy errors
 are rejected,
 patches that introduces new functionality or change of
 existing
 functionality are required to add to the News file, max
 one line. Just
 something like this, I would like markdown formatting.


 Changes from Kicad 4
  

[Kicad-developers] Symbol library table merged.

[Wayne Stambaugh]

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

Re: [Kicad-developers] when to release kicad-5.0

[Wayne Stambaugh]

Thank you for the offer.  I have to look and see what needs to be done
to give you access privileges to the timeline and milestones.  I don't
know when I have time to do that.  We should probably agree on how we
are going to use them if at all before we do anything and then nobody
follows suite.  We will need buy in from the dev team.

On 11/9/2017 10:40 AM, Nick Østergaard wrote:
> There is no need. We already use the series thing. And one can specify
> milestones to a series. But I don't have the required access rights to
> edit this. I would be happy to help manage this.
> 
> Den 9. nov. 2017 16.03  skrev "Wayne Stambaugh"
> >:
> 
> Hey Nick,
> 
> The last time I looked, milestones could still not be linked to git
> repos, only bzr repos.  This is problematic since we have switched to
> git.  This may have changed recently.  I haven't looked.  Even if they
> could be linked to git repos, I'm not sure how much extra work it would
> be maintain them.  I'm at my bandwidth limit right now and I don't see
> that changing until after the stable 5 release.
> 
> Cheers,
> 
> Wayne
> 
> 
> On 11/9/2017 7:49 AM, Nick Østergaard wrote:
> > Hi Wayne
> >
> > It is hard to get any overview on how far from a branchout to a stable
> > v5 release. I propose that we start using the milestones on launchpad.
> > Then we can relate bugs to this and have an easier overview on what we
> > would like to get done before releasing v5. What do you think?
> >
> > Nick
> >
> > 2017-10-31 13:06 GMT+01:00 Wayne Stambaugh  
> > >>:
> >
> >     We are very close to a feature freeze and creating a 5 stable
> branch.
> >     Once that is done, it typically takes a few months to make
> sure there
> >     are no critical or major bugs before we can release.  The goal
> is to
> >     have it released before FOSDEM 2018 so I have some good news
> to deliver
> >     during the KiCad presentation.
> >
> >     On 10/30/2017 8:56 PM, Bang He wrote:
> >     > kicad-5.0 have developed for a long time. so i want to ask
> when the
> >     > kicad-5.0 is going to release.
> >     >
> >     >
> >     > ___
> >     > Mailing list: https://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 00/12] Minor cleanups and improvements

[Maciej Suminski]

Hi Marvin,

On 11/09/2017 08:12 PM, Marvin Schmidt wrote:
> Hey Orson,
> 
> I actually didn't skip any patch, #8 ("Remove orphaned code files")
> should is there:
> https://lists.launchpad.net/kicad-developers/msg31304.html

Strange, I have never received this message, but now I am glad that I
have asked.

> I rebased my patches and pushed them to my Github repository, I think
> it's easier for both of us that way :-)
> 
> Please pull from https://github.com/marv/kicad-dev/tree/housekeeping

Surely it is much easier. I have just pushed your changes to the master
branch. Thank you!

Regards,
Orson

> Best regards,
> Marvin
> 
> On Sun, Nov 05, 2017 at 10:21:41PM +0100, Maciej Suminski wrote:
>> Hi Marvin,
>>
>> Have you skipped patch 0008 intentionally? Some of the changes from this
>> set do not apply cleanly, would you rebase them?
>>
>> Regards,
>> Orson
>>
>> On 11/02/2017 09:58 PM, Marvin Schmidt wrote:
>>> Just a set of small code cleanups to fix a bunch of warnings
>>> and remove dead code.
>>> Other than that the 'build:' commits avoid/remove/fix the
>>> installation of certain files:
>>>  - it doesn't make much sense to install the INSTALL.txt
>>>  - *.bat scripts shouldn't be installed on UNIX systems
>>>  - use CMAKE_INSTALL_* consistently to install files in the
>>>correct places
>>>
>>> Marvin Schmidt (12):
>>>   build: Don't install INSTALL.txt
>>>   build: Use CMAKE_INSTALL_DATADIR
>>>   build: Remove dead code
>>>   build: Don't install *.bat scripts on Unix
>>>   Fix a typo
>>>   Remove unused #define
>>>   Remove some dead code
>>>   Remove orphaned code files
>>>   Remove some extra semicolons
>>>   Remove duplicate #include
>>>   Remove some else-after-return's
>>>   Use std::remove_pointer instead of own implementation (NFC)
>>>
>>>  3d-viewer/3d_cache/dialogs/3d_cache_dialogs.h   |   2 +-
>>>  3d-viewer/3d_cache/sg/sg_helpers.cpp|   2 +-
>>>  3d-viewer/3d_cache/sg/sg_helpers.h  |   2 +-
>>>  3d-viewer/3d_cache/sg/sg_node.h |   2 +-
>>>  3d-viewer/3d_cache/str_rsort.h  |   2 +-
>>>  3d-viewer/3d_canvas/eda_3d_canvas.h |   2 +-
>>>  3d-viewer/3d_model_viewer/c3d_model_viewer.h|   2 +-
>>>  3d-viewer/3d_viewer/eda_3d_viewer.h |   2 +-
>>>  CMakeLists.txt  |  17 +--
>>>  common/bitmap.cpp   |   4 +-
>>>  common/class_undoredo_container.cpp |  39 ---
>>>  common/eagle_parser.cpp |   4 +-
>>>  common/single_top.cpp   |   2 +-
>>>  common/view/view.cpp|   2 +-
>>>  common/widgets/mathplot.cpp |   6 +-
>>>  common/wxunittext.cpp   | 142 
>>> ---
>>>  eeschema/dialogs/dialog_bom.cpp |   2 +-
>>>  eeschema/pin_shape.cpp  |   2 +-
>>>  eeschema/plot_schematic_HPGL.cpp|   2 +-
>>>  eeschema/sch_io_mgr.cpp |   2 +-
>>>  eeschema/sch_io_mgr.h   |   2 +-
>>>  eeschema/sch_item_struct.cpp|   7 --
>>>  eeschema/sch_item_struct.h  |   4 -
>>>  eeschema/sch_screen.cpp |   3 -
>>>  gerbview/class_gerber_draw_item.h   |   2 +-
>>>  gerbview/class_gerbview_layer_widget.cpp|   2 +-
>>>  include/class_draw_panel_gal.h  |   2 +-
>>>  include/core/typeinfo.h |  22 +---
>>>  include/geometry/rtree.h|   2 +-
>>>  include/plugins/3dapi/ifsg_api.h|   2 +-
>>>  include/plugins/3dapi/sg_types.h|   2 +-
>>>  include/system/libcontext.h |   4 +-
>>>  include/tool/tool_base.h|   2 +-
>>>  include/tool/tool_dispatcher.h  |   2 +-
>>>  include/ttl/halfedge/hetraits.h |   2 +-
>>>  include/ttl/halfedge/hetriang.h |   4 +-
>>>  include/wxunittext.h| 144 
>>> 
>>>  kicad/kicad.cpp |   2 +-
>>>  pcb_calculator/UnitSelector.cpp |  10 +-
>>>  pcbnew/class_drawsegment.cpp|   2 +-
>>>  pcbnew/class_module.h   |   2 +-
>>>  pcbnew/class_netclass.h |   2 +-
>>>  pcbnew/class_pad.h  |   2 +-
>>>  pcbnew/class_zone.cpp   |   2 +-
>>>  pcbnew/class_zone_settings.cpp  |   2 +-
>>>  pcbnew/dialogs/dialog_footprint_wizard_list.cpp |   6 +-
>>>  pcbnew/exporters/export_gencad.cpp  |   4 +-
>>>  pcbnew/exporters/export_vrml.cpp|   2 +-
>>>  pcbnew/moduleframe.cpp  |   2 +-
>>>  pcbnew/router/pns_kicad_iface.h |   2 +-
>>>  pcbnew/router/pns_router.h  |   

Re: [Kicad-developers] [PATCH 0/3] Minor fixes for VECTOR2 and BOX2

[Maciej Suminski]

Hi Marvin,

IIRC, I could not apply some of the patches cleanly, but I decided they
were short enough to introduce the changes manually. Apparently even
with such short patches there is a place for mistakes, I am sorry about
that.

Regards,
Orson

On 11/09/2017 08:07 PM, Marvin Schmidt wrote:
> Hey Orson,
> 
> thanks for pushing those patches!
> 
> Just wondering: why did you alter them? I intentionally left one of the
> `#include ` in place because the Rotate function uses sin and cos
> (which should really be std::{sin,cos} by the way) and ordered the
> includes alphabetically
> 
> Best regards,
> Marvin
> 
> On Sun, Nov 05, 2017 at 11:04:48PM +0100, Maciej Suminski wrote:
>> Hi Marvin,
>>
>> Thank you for the patches. I have just pushed them to the master branch.
>>
>> Regards,
>> Orson
>>
>> On 10/31/2017 12:17 PM, Marvin Schmidt wrote:
>>> I was irritated by the usage of the vector_traits class as you usually
>>> use it to gather more information about a certain type using
>>> something like `traits::property`. Here the vector2d classes
>>> queries the traits class to get the extended coordinate type but also
>>> derives from it to get the limits of that type which are hardcoded in
>>> the traits class. The second patch removes the hardcoded limits from
>>> the traits class and the inheritance of the vector2d class from the traits
>>> class. Instead the vector2d class uses the std::numeric_limits facility
>>> to get the limits of the extended coordinate type it got through the
>>> traits class
>>>
>>> The other two patches are just minor fixes. The wrong use of the
>>> typename keyword in the box2 class might have been triggering a bug
>>> in the MSVC compiler though (not sure about that as I can't test it,
>>> just seems possible from workaround I've seen)
>>>
>>> Marvin Schmidt (3):
>>>   vector2d: Remove duplicate #include
>>>   vector2d: Fix traits usage and use std::numeric_limits
>>>   box2: Remove wrong use of typename keyword
>>>
>>>  include/math/box2.h |  2 +-
>>>  include/math/vector2d.h | 10 +-
>>>  2 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

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

[easyw]

Oliver,

historically that was in inches for the 3D viewer...
Mario didn't change the file format to avoid breaking any previous 
releases I think, but managed to calculate correctly offset and 
displaying in the 3D viewer and exporter...


I don't know if aligning these parameters to mm inside the kicad_pcb 
file format would worth the breaking back compatibility of boards, 
considering that there are no errors in the 3D viewer nor in the 
exporters...


The only issue is that offset values, as pointed out from JP, are stored 
internally in inches, but in terms of user experience and in the 3D Gui 
everything is displayed and calculated fine right now...


Maurice



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

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

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

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"  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"  > 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 (perhaps all)
> footprint files in our official repo.
>
> in case of option 2, the parser should be (obviously) able to
> understand the keyword  "offset" (or
> "anchor") to prepare the future.
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 

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

[Oliver Walters]

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.

On Fri, Nov 10, 2017 at 7:09 AM, Oliver Walters <
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" 
> 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 (perhaps all) footprint
>>> files in our official repo.
>>>
>>> in case of option 2, the parser should be (obviously) able to understand
>>> the keyword  "offset" (or
>>> "anchor") to prepare the future.
>>>
>>>
>> ___
>> Mailing list: https://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]

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" 
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 (perhaps all) footprint
>> files in our official repo.
>>
>> in case of option 2, the parser should be (obviously) able to understand
>> the keyword  "offset" (or
>> "anchor") to prepare the future.
>>
>>
> ___
> Mailing list: https://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 0/3] Minor fixes for VECTOR2 and BOX2

[Marvin Schmidt]

Hey Orson,

thanks for pushing those patches!

Just wondering: why did you alter them? I intentionally left one of the
`#include ` in place because the Rotate function uses sin and cos
(which should really be std::{sin,cos} by the way) and ordered the
includes alphabetically

Best regards,
Marvin

On Sun, Nov 05, 2017 at 11:04:48PM +0100, Maciej Suminski wrote:
> Hi Marvin,
> 
> Thank you for the patches. I have just pushed them to the master branch.
> 
> Regards,
> Orson
> 
> On 10/31/2017 12:17 PM, Marvin Schmidt wrote:
> > I was irritated by the usage of the vector_traits class as you usually
> > use it to gather more information about a certain type using
> > something like `traits::property`. Here the vector2d classes
> > queries the traits class to get the extended coordinate type but also
> > derives from it to get the limits of that type which are hardcoded in
> > the traits class. The second patch removes the hardcoded limits from
> > the traits class and the inheritance of the vector2d class from the traits
> > class. Instead the vector2d class uses the std::numeric_limits facility
> > to get the limits of the extended coordinate type it got through the
> > traits class
> > 
> > The other two patches are just minor fixes. The wrong use of the
> > typename keyword in the box2 class might have been triggering a bug
> > in the MSVC compiler though (not sure about that as I can't test it,
> > just seems possible from workaround I've seen)
> > 
> > Marvin Schmidt (3):
> >   vector2d: Remove duplicate #include
> >   vector2d: Fix traits usage and use std::numeric_limits
> >   box2: Remove wrong use of typename keyword
> > 
> >  include/math/box2.h |  2 +-
> >  include/math/vector2d.h | 10 +-
> >  2 files changed, 6 insertions(+), 6 deletions(-)
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Update of KiCad documentation?

[Wayne Stambaugh]

I like this idea as well.  It's simple and easy to remember.  If there
are no objections, I will updated the commit message policy to add NEW,
CHANGED, and REMOVED tags and a brief explanation of when each tag
should be used.  Is there any special formatting that we want to use
with these tags to make life easier for folks trying to extract
information using scripts?  Rather than adding the tag to the end which
may be a bit limiting, I was thinking it may make more sense to add the
tag to the beginning of the description of the change separated by empty
lines.  It could look something like this.

Major rewrite of some existing feature.

NEW: The feature adds support for X, Y, and Z operations.

REMOVED: The feature no longer supports the foo operation.

CHANGED: The feature operations bar and baz now require manual frobnication.

If anyone has any better ideas, now is the time.

Cheers,

Wayne

On 11/9/2017 11:06 AM, Maciej Sumiński wrote:
> I am in favor of including the information in commit messages. In the
> simplest version, one can simple append "CHANGE" at the end of a commit
> message. If we follow this scheme, then to get a changelog it is enough
> to execute "git log --grep=CHANGE". One can also modify the query to get
> changelog for different periods.
> 
> It is a tiny effort on the developers side which significantly helps
> people willing to work on the documentation, therefore I think it is
> worth pursuing. The only possible problem I see here is to get into the
> habit, but we did well with "Fixes".
> 
> Regards,
> Orson
> 
> On 11/09/2017 01:40 PM, Nick Østergaard wrote:
>> I didn't mean to indicate that one shall not write useful commit messages
>> in the kicad source repo. The start of this topic was how to make sure to
>> keep the doc up to date. This is what I was trying to comment on. Here it
>> is better to track the work where it is to be done, in the kicad-doc repo.
>> That does not hinder anyone from grepping the kicad commit log for new
>> features, when one gets the urge to create documentation. This shall of
>> course not hinder anyone who submits a feature to kicad to also submit
>> documentation updates for it either.
>>
>> When we release I expect a release note to be composed that will describe
>> the new features as we did with http://kicad-pcb.org/post/release-4.0.0/
>>
>> 2017-11-09 12:39 GMT+01:00 Kristoffer Ödmark :
>>
>>> That doesnt sound like a good idea, when adding patches, just having to
>>> add a line or two to the commit message seems best, and I imagine the news
>>> or changelog file is just there to later help the kicad-doc repo to do a
>>> proper changelog. Having to go to a new repo seems a bit more annoying.
>>>
>>> Or skip the file totally this time, and just enfore the commit messages.
>>> This way this will not be such a hassle next time one wonders what have
>>> changed between versions.
>>>
>>> On 11/09/2017 11:05 AM, Nick Østergaard wrote:
>>>
 I think this might be better handled as bugs on the kicad-doc repo. Then
 everyone can contribute easily and we can track it for the documentation,
 where the info is to be used anyways. For now label them new_kicad_feature
 if it is.

 2017-11-09 10:54 GMT+01:00 Kristoffer Ödmark <
 kristofferodmar...@gmail.com >:


 I think for this to start happen, a decision has to be made, and
 enforced by everyone with commit access to the repo.

 Bugfixes need not be tagged like this. Major changes only.

 I still think a we should start collect a list in the repo with
 changes from kicad 4 up to the point this commit message policy is
 set. I for one love reading changelogs when upgrading, and I think
 the users are expecting this as well, and it probably will be useful
 in the FOSDEM presentation :)


 On 11/04/2017 01:53 AM, Wayne Stambaugh wrote:

 On 11/3/2017 8:54 AM, Maciej Sumiński wrote:

 On 11/03/2017 11:30 AM, Kristoffer Ödmark wrote:

 I think starting small would be best in this case. The
 least needed
 would be a "News" File, that is always refering to kicad
 stable.

 I propose the same way that patches with policy errors
 are rejected,
 patches that introduces new functionality or change of
 existing
 functionality are required to add to the News file, max
 one line. Just
 something like this, I would like markdown formatting.


 Changes from Kicad 4
 =

 NEW: Pcbnew now supports clipboard copy/paste
 CHANGE: Delete button now removes entire trace, not just

Re: [Kicad-developers] Update of KiCad documentation?

[Maciej Sumiński]

I am in favor of including the information in commit messages. In the
simplest version, one can simple append "CHANGE" at the end of a commit
message. If we follow this scheme, then to get a changelog it is enough
to execute "git log --grep=CHANGE". One can also modify the query to get
changelog for different periods.

It is a tiny effort on the developers side which significantly helps
people willing to work on the documentation, therefore I think it is
worth pursuing. The only possible problem I see here is to get into the
habit, but we did well with "Fixes".

Regards,
Orson

On 11/09/2017 01:40 PM, Nick Østergaard wrote:
> I didn't mean to indicate that one shall not write useful commit messages
> in the kicad source repo. The start of this topic was how to make sure to
> keep the doc up to date. This is what I was trying to comment on. Here it
> is better to track the work where it is to be done, in the kicad-doc repo.
> That does not hinder anyone from grepping the kicad commit log for new
> features, when one gets the urge to create documentation. This shall of
> course not hinder anyone who submits a feature to kicad to also submit
> documentation updates for it either.
> 
> When we release I expect a release note to be composed that will describe
> the new features as we did with http://kicad-pcb.org/post/release-4.0.0/
> 
> 2017-11-09 12:39 GMT+01:00 Kristoffer Ödmark :
> 
>> That doesnt sound like a good idea, when adding patches, just having to
>> add a line or two to the commit message seems best, and I imagine the news
>> or changelog file is just there to later help the kicad-doc repo to do a
>> proper changelog. Having to go to a new repo seems a bit more annoying.
>>
>> Or skip the file totally this time, and just enfore the commit messages.
>> This way this will not be such a hassle next time one wonders what have
>> changed between versions.
>>
>> On 11/09/2017 11:05 AM, Nick Østergaard wrote:
>>
>>> I think this might be better handled as bugs on the kicad-doc repo. Then
>>> everyone can contribute easily and we can track it for the documentation,
>>> where the info is to be used anyways. For now label them new_kicad_feature
>>> if it is.
>>>
>>> 2017-11-09 10:54 GMT+01:00 Kristoffer Ödmark <
>>> kristofferodmar...@gmail.com >:
>>>
>>>
>>> I think for this to start happen, a decision has to be made, and
>>> enforced by everyone with commit access to the repo.
>>>
>>> Bugfixes need not be tagged like this. Major changes only.
>>>
>>> I still think a we should start collect a list in the repo with
>>> changes from kicad 4 up to the point this commit message policy is
>>> set. I for one love reading changelogs when upgrading, and I think
>>> the users are expecting this as well, and it probably will be useful
>>> in the FOSDEM presentation :)
>>>
>>>
>>> On 11/04/2017 01:53 AM, Wayne Stambaugh wrote:
>>>
>>> On 11/3/2017 8:54 AM, Maciej Sumiński wrote:
>>>
>>> On 11/03/2017 11:30 AM, Kristoffer Ödmark wrote:
>>>
>>> I think starting small would be best in this case. The
>>> least needed
>>> would be a "News" File, that is always refering to kicad
>>> stable.
>>>
>>> I propose the same way that patches with policy errors
>>> are rejected,
>>> patches that introduces new functionality or change of
>>> existing
>>> functionality are required to add to the News file, max
>>> one line. Just
>>> something like this, I would like markdown formatting.
>>>
>>>
>>> Changes from Kicad 4
>>> =
>>>
>>> NEW: Pcbnew now supports clipboard copy/paste
>>> CHANGE: Delete button now removes entire trace, not just
>>> a segment
>>> CHANGE: Icons in toolbar are improved
>>> REMOVED: Autorouter no longer exists
>>>
>>>
>>> This style could also be applied in the git commit
>>> message, making it
>>> easy to compile by something such as 'git log | grep
>>> "NEW:"'
>>>
>>> But since that is lacking, I think starting a new file
>>> is best.
>>>
>>>
>>> I vote for git commit messages following a specific format
>>> (could be
>>> NEW:/CHANGE:/REMOVE: lines) to easily create change logs. It
>>> is much
>>> easier to see with git what has changed in a specific period
>>> of time.
>>> With NEWS file you would need at least put dates there to be
>>> able to do
>>> that (or see with git when a specific line has been added).
>>>
>>> I know that ideally the user documentation should be updated
>>> together
>>>   

Re: [Kicad-developers] when to release kicad-5.0

[Nick Østergaard]

There is no need. We already use the series thing. And one can specify
milestones to a series. But I don't have the required access rights to edit
this. I would be happy to help manage this.

Den 9. nov. 2017 16.03 <20%2017%2016%2003> skrev "Wayne Stambaugh" <
stambau...@gmail.com>:

> Hey Nick,
>
> The last time I looked, milestones could still not be linked to git
> repos, only bzr repos.  This is problematic since we have switched to
> git.  This may have changed recently.  I haven't looked.  Even if they
> could be linked to git repos, I'm not sure how much extra work it would
> be maintain them.  I'm at my bandwidth limit right now and I don't see
> that changing until after the stable 5 release.
>
> Cheers,
>
> Wayne
>
>
> On 11/9/2017 7:49 AM, Nick Østergaard wrote:
> > Hi Wayne
> >
> > It is hard to get any overview on how far from a branchout to a stable
> > v5 release. I propose that we start using the milestones on launchpad.
> > Then we can relate bugs to this and have an easier overview on what we
> > would like to get done before releasing v5. What do you think?
> >
> > Nick
> >
> > 2017-10-31 13:06 GMT+01:00 Wayne Stambaugh  > >:
> >
> > We are very close to a feature freeze and creating a 5 stable branch.
> > Once that is done, it typically takes a few months to make sure there
> > are no critical or major bugs before we can release.  The goal is to
> > have it released before FOSDEM 2018 so I have some good news to
> deliver
> > during the KiCad presentation.
> >
> > On 10/30/2017 8:56 PM, Bang He wrote:
> > > kicad-5.0 have developed for a long time. so i want to ask when the
> > > kicad-5.0 is going to release.
> > >
> > >
> > > ___
> > > Mailing list: https://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] [REQUEST] Default library install location

[Nick Østergaard]

Den 9. nov. 2017 16.09 skrev "Simon Richter" :

Hi,

On 08.11.2017 08:02, Oliver Walters wrote:

> For v5 release, can the default library install path be set to a user
> directory rather than program directory that may require administrator
> rights?

On Windows, there is a provision in the MSI standard for installing
software for the user only, which then doesn't require administrative
privileges. That will install both KiCad and the library into the user
home directory then, and the installation will not be available to any
other user on the system.

On Unix, no way.

What might work, but needs a bit of extra code, would be a per-user
library directory and automatically copying modified libraries there,
which then override the shipped library.


This is what the already existing copy on write feature do.

My expectation would be that
this would lead to a huge chaos unless we also get a proper library
manager, which I don't see happening before version 5.

What users need is a subset of

 - a standard library of readymade components so you can do quick
projects like "arduino plus five resistors" easily
 - an organization-wide library, possibly with inventory integration
 - a per-user library of things the user works with
 - a per-project library of things that were actually used and need to
be archived together with the project (copying footprints onto the PCB
doesn't count, because you cannot easily revert changes).

Which of these the user actually needs depends on whether they are doing
this for work or as a hobby, and on their working style.

   Simon


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

Re: [Kicad-developers] when to release kicad-5.0

[Wayne Stambaugh]

Hey Nick,

The last time I looked, milestones could still not be linked to git
repos, only bzr repos.  This is problematic since we have switched to
git.  This may have changed recently.  I haven't looked.  Even if they
could be linked to git repos, I'm not sure how much extra work it would
be maintain them.  I'm at my bandwidth limit right now and I don't see
that changing until after the stable 5 release.

Cheers,

Wayne


On 11/9/2017 7:49 AM, Nick Østergaard wrote:
> Hi Wayne
> 
> It is hard to get any overview on how far from a branchout to a stable
> v5 release. I propose that we start using the milestones on launchpad.
> Then we can relate bugs to this and have an easier overview on what we
> would like to get done before releasing v5. What do you think?
> 
> Nick
> 
> 2017-10-31 13:06 GMT+01:00 Wayne Stambaugh  >:
> 
> We are very close to a feature freeze and creating a 5 stable branch.
> Once that is done, it typically takes a few months to make sure there
> are no critical or major bugs before we can release.  The goal is to
> have it released before FOSDEM 2018 so I have some good news to deliver
> during the KiCad presentation.
> 
> On 10/30/2017 8:56 PM, Bang He wrote:
> > kicad-5.0 have developed for a long time. so i want to ask when the
> > kicad-5.0 is going to release.
> >
> >
> > ___
> > Mailing list: https://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] [REQUEST] Default library install location

[Simon Richter]

Hi,

On 08.11.2017 08:02, Oliver Walters wrote:

> For v5 release, can the default library install path be set to a user
> directory rather than program directory that may require administrator
> rights?

On Windows, there is a provision in the MSI standard for installing
software for the user only, which then doesn't require administrative
privileges. That will install both KiCad and the library into the user
home directory then, and the installation will not be available to any
other user on the system.

On Unix, no way.

What might work, but needs a bit of extra code, would be a per-user
library directory and automatically copying modified libraries there,
which then override the shipped library. My expectation would be that
this would lead to a huge chaos unless we also get a proper library
manager, which I don't see happening before version 5.

What users need is a subset of

 - a standard library of readymade components so you can do quick
projects like "arduino plus five resistors" easily
 - an organization-wide library, possibly with inventory integration
 - a per-user library of things the user works with
 - a per-project library of things that were actually used and need to
be archived together with the project (copying footprints onto the PCB
doesn't count, because you cannot easily revert changes).

Which of these the user actually needs depends on whether they are doing
this for work or as a hobby, and on their working style.

   Simon



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] fix MANDATORY_FIELDS comparisons

[Wayne Stambaugh]

Julius,

I cannot git am this patch.  Apparently, the extra info added by
launchpad is causing an issue.  Please resend this patch as an
attachment so I can get it merged.

Thanks,

Wayne

On 11/7/2017 4:31 AM, Julius Schmidt wrote:
> I found a few places where SCH_FIELD::GetId() is incorrectly (signed)
> compared to MANDATORY_FIELDS.
> I'm not sure all of these are bugs but at least the sch_component.cpp
> one triggers an assertion here when creating components with
> non-mandatory fields defined.
> 
> ---
>  eeschema/class_libentry.cpp    | 2 +-
>  eeschema/lib_field.cpp | 2 +-
>  eeschema/sch_component.cpp | 2 +-
>  eeschema/sch_legacy_plugin.cpp | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/eeschema/class_libentry.cpp b/eeschema/class_libentry.cpp
> index cfe3d99..fe6f8e1 100644
> --- a/eeschema/class_libentry.cpp
> +++ b/eeschema/class_libentry.cpp
> @@ -1096,7 +1096,7 @@ bool LIB_PART::LoadField( LINE_READER&
> aLineReader, wxString& aErrorMsg )
>  return false;
>  }
> 
> -    if( field->GetId() < MANDATORY_FIELDS )
> +    if( (unsigned) field->GetId() < MANDATORY_FIELDS )
>  {
>  LIB_FIELD* fixedField = GetField( field->GetId() );
> 
> diff --git a/eeschema/lib_field.cpp b/eeschema/lib_field.cpp
> index 26237bd..35f74a1 100644
> --- a/eeschema/lib_field.cpp
> +++ b/eeschema/lib_field.cpp
> @@ -264,7 +264,7 @@ bool LIB_FIELD::Load( LINE_READER& aLineReader,
> wxString& errorMsg )
>  }
> 
>  // fields in RAM must always have names.
> -    if( m_id < MANDATORY_FIELDS )
> +    if( (unsigned) m_id < MANDATORY_FIELDS )
>  {
>  // Fields in RAM must always have names, because we are trying
> to get
>  // less dependent on field ids and more dependent on names.
> diff --git a/eeschema/sch_component.cpp b/eeschema/sch_component.cpp
> index e03b077..d36cb55 100644
> --- a/eeschema/sch_component.cpp
> +++ b/eeschema/sch_component.cpp
> @@ -874,7 +874,7 @@ void SCH_COMPONENT::UpdateFields( bool aResetStyle,
> bool aResetRef )
> 
>  if( idx == REFERENCE && !aResetRef )
>  continue;
> -    if( idx < MANDATORY_FIELDS )
> +    if( (unsigned) idx < MANDATORY_FIELDS )
>  schField = GetField( idx );
>  else
>  schField = FindField( field.GetName() );
> diff --git a/eeschema/sch_legacy_plugin.cpp
> b/eeschema/sch_legacy_plugin.cpp
> index b7daee5..f70fdce 100644
> --- a/eeschema/sch_legacy_plugin.cpp
> +++ b/eeschema/sch_legacy_plugin.cpp
> @@ -2657,7 +2657,7 @@ void SCH_LEGACY_PLUGIN_CACHE::loadField(
> std::unique_ptr< LIB_PART >& aPart,
>  }
> 
>  // Fields in RAM must always have names.
> -    if( id < MANDATORY_FIELDS )
> +    if( (unsigned) id < MANDATORY_FIELDS )
>  {
>  // Fields in RAM must always have names, because we are trying
> to get
>  // less dependent on field ids and more dependent on names.

___
Mailing list: https://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] wxWidgets macOS 10.13 Patch

[Wayne Stambaugh]

Adam,

I pushed your patch to the master branch.  I'll keep an eye out for the
build doc update patch.

Thanks,

Wayne

On 11/6/2017 9:25 PM, Adam Wolf wrote:
> Hi folks,
> 
> Attached is a patch that adds a patch that helps wxWidgets build on
> the latest macOS 10.13 High Sierra.
> 
> Additionally, when folks build wxWidgets, they'll need to set the
> CPPFLAG of D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=1.
> 
> I'm working on updating the packaging scripts so folks can use those
> as a reference.
> 
> Adam Wolf
> 
> 
> 
> ___
> Mailing list: https://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] when to release kicad-5.0

[Nick Østergaard]

Hi Wayne

It is hard to get any overview on how far from a branchout to a stable v5
release. I propose that we start using the milestones on launchpad. Then we
can relate bugs to this and have an easier overview on what we would like
to get done before releasing v5. What do you think?

Nick

2017-10-31 13:06 GMT+01:00 Wayne Stambaugh :

> We are very close to a feature freeze and creating a 5 stable branch.
> Once that is done, it typically takes a few months to make sure there
> are no critical or major bugs before we can release.  The goal is to
> have it released before FOSDEM 2018 so I have some good news to deliver
> during the KiCad presentation.
>
> On 10/30/2017 8:56 PM, Bang He wrote:
> > kicad-5.0 have developed for a long time. so i want to ask when the
> > kicad-5.0 is going to release.
> >
> >
> > ___
> > Mailing list: https://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] [REQUEST] Default library install location

[Kristoffer Ödmark]

Personally I think this is a nice solution

http://1.bp.blogspot.com/-3u-eixTrMbI/VDWb25kPNkI/A-g/0qn7ehRq4Mo/s1600/ReadOnly.PNG

Very helpful, instead of the "Edit document" button, there could be 
something such as "Copy to user-library for edit".


- Kristoffer

On 11/09/2017 02:02 AM, Wayne Stambaugh wrote:

Would a dialog asking if you want to save a modified library that is
read only to a new folder be an acceptable solution?  If so, please file
a bug report and set its status to wish list.  I'm not sure when someone
will get around to it but at least we will have a record of it.

On 11/8/2017 7:07 PM, Simon Wells wrote:

i wouldn't particularly call it handholding but i do believe its something that 
should be automatically done by kicad if we are to continue bundling such a 
number of libraries. The extra command in the toolbar is not particularly 
obvious unless you already know about it or it is pointed out to you, i would 
almost prefer it to be something that is not a specific command and the code is 
only used when you go to save to a system library. although it should 
notify/warn that it is a system library and due to this will be copied into 
your local user library/dir



On 9/11/2017, at 13:04, Wayne Stambaugh  wrote:

Exactly how much hand holding is KiCad expected to do?  There is already
a "save the current library as" command in the file menu of both the
symbol and footprint library editors.  There is a small bug in that
grays out the command until you load a symbol but it allows you to save
any library to a folder that the user has write access to and modify it
at will without changing the originally installed libraries which IMO is
a good thing.  Of course you could do a good old fashion file copy or
git clone or ...  How many ways to we really need to perform this one
simple task or am I completely missing something.

On 11/08/2017 06:15 PM, Simon Wells wrote:

ideally if someone tried to save to a bundled library there should be something 
that pops up and says you can't/shouldn't and then offers to do most if not all 
of that for you, however i would prefer to see it only saving the footprint to 
userdir, i think you will find this is how most other software would handle a 
similar circumstance


On 9/11/2017, at 12:12, easyw  wrote:


I think it's a far more risky that a user makes accidental changes to the
bundled library. Simple users should not need to touch it, and should
rather copy or make a new part.


so if a user wants to add a missing parts to his/her library he/her needs to 
save it to a different location, close the i.e. fp editor, copy with 
administrative privileges the fp to the Admin folder and restart the sw to use 
it?
I don't think other sw are using this procedure...
This is just my opinion...


___
Mailing list: https://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] Update of KiCad documentation?

[Nick Østergaard]

I didn't mean to indicate that one shall not write useful commit messages
in the kicad source repo. The start of this topic was how to make sure to
keep the doc up to date. This is what I was trying to comment on. Here it
is better to track the work where it is to be done, in the kicad-doc repo.
That does not hinder anyone from grepping the kicad commit log for new
features, when one gets the urge to create documentation. This shall of
course not hinder anyone who submits a feature to kicad to also submit
documentation updates for it either.

When we release I expect a release note to be composed that will describe
the new features as we did with http://kicad-pcb.org/post/release-4.0.0/

2017-11-09 12:39 GMT+01:00 Kristoffer Ödmark :

> That doesnt sound like a good idea, when adding patches, just having to
> add a line or two to the commit message seems best, and I imagine the news
> or changelog file is just there to later help the kicad-doc repo to do a
> proper changelog. Having to go to a new repo seems a bit more annoying.
>
> Or skip the file totally this time, and just enfore the commit messages.
> This way this will not be such a hassle next time one wonders what have
> changed between versions.
>
> On 11/09/2017 11:05 AM, Nick Østergaard wrote:
>
>> I think this might be better handled as bugs on the kicad-doc repo. Then
>> everyone can contribute easily and we can track it for the documentation,
>> where the info is to be used anyways. For now label them new_kicad_feature
>> if it is.
>>
>> 2017-11-09 10:54 GMT+01:00 Kristoffer Ödmark <
>> kristofferodmar...@gmail.com >:
>>
>>
>> I think for this to start happen, a decision has to be made, and
>> enforced by everyone with commit access to the repo.
>>
>> Bugfixes need not be tagged like this. Major changes only.
>>
>> I still think a we should start collect a list in the repo with
>> changes from kicad 4 up to the point this commit message policy is
>> set. I for one love reading changelogs when upgrading, and I think
>> the users are expecting this as well, and it probably will be useful
>> in the FOSDEM presentation :)
>>
>>
>> On 11/04/2017 01:53 AM, Wayne Stambaugh wrote:
>>
>> On 11/3/2017 8:54 AM, Maciej Sumiński wrote:
>>
>> On 11/03/2017 11:30 AM, Kristoffer Ödmark wrote:
>>
>> I think starting small would be best in this case. The
>> least needed
>> would be a "News" File, that is always refering to kicad
>> stable.
>>
>> I propose the same way that patches with policy errors
>> are rejected,
>> patches that introduces new functionality or change of
>> existing
>> functionality are required to add to the News file, max
>> one line. Just
>> something like this, I would like markdown formatting.
>>
>>
>> Changes from Kicad 4
>> =
>>
>> NEW: Pcbnew now supports clipboard copy/paste
>> CHANGE: Delete button now removes entire trace, not just
>> a segment
>> CHANGE: Icons in toolbar are improved
>> REMOVED: Autorouter no longer exists
>>
>>
>> This style could also be applied in the git commit
>> message, making it
>> easy to compile by something such as 'git log | grep
>> "NEW:"'
>>
>> But since that is lacking, I think starting a new file
>> is best.
>>
>>
>> I vote for git commit messages following a specific format
>> (could be
>> NEW:/CHANGE:/REMOVE: lines) to easily create change logs. It
>> is much
>> easier to see with git what has changed in a specific period
>> of time.
>> With NEWS file you would need at least put dates there to be
>> able to do
>> that (or see with git when a specific line has been added).
>>
>> I know that ideally the user documentation should be updated
>> together
>> with the code, but on the other KiCad changes so fast, so
>> there might be
>> a lot of wasted time spent on changing the documentation and
>> updating
>> screens that might be invalid in a week or two. For sure the
>> documentation should be refreshed for a stable release.
>>
>> Regards,
>> Orson
>>
>>
>> I'm not opposed to this idea but it should be used sensibly.
>>Not all
>> new, changed, or removed code will require documentation
>> changes.  I
>> would also prefer it not be in the first line of the commit
>> message
>> unless the commit message is only one line.  It's already
>> difficult to

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

[Kristoffer Ödmark]

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 (perhaps all) footprint files in 
our official repo.

in case of option 2, the parser should be (obviously) able to understand the keyword  
"offset" (or
"anchor") to prepare the future.



___
Mailing list: https://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

[jp charras]

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 (perhaps all) footprint files in 
our official repo.

in case of option 2, the parser should be (obviously) able to understand the 
keyword  "offset" (or
"anchor") to prepare the future.

-- 
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] Update of KiCad documentation?

[Kristoffer Ödmark]

That doesnt sound like a good idea, when adding patches, just having to 
add a line or two to the commit message seems best, and I imagine the 
news or changelog file is just there to later help the kicad-doc repo to 
do a proper changelog. Having to go to a new repo seems a bit more annoying.


Or skip the file totally this time, and just enfore the commit messages. 
This way this will not be such a hassle next time one wonders what have 
changed between versions.


On 11/09/2017 11:05 AM, Nick Østergaard wrote:
I think this might be better handled as bugs on the kicad-doc repo. Then 
everyone can contribute easily and we can track it for the 
documentation, where the info is to be used anyways. For now label 
them new_kicad_feature if it is.


2017-11-09 10:54 GMT+01:00 Kristoffer Ödmark 
>:


I think for this to start happen, a decision has to be made, and
enforced by everyone with commit access to the repo.

Bugfixes need not be tagged like this. Major changes only.

I still think a we should start collect a list in the repo with
changes from kicad 4 up to the point this commit message policy is
set. I for one love reading changelogs when upgrading, and I think
the users are expecting this as well, and it probably will be useful
in the FOSDEM presentation :)


On 11/04/2017 01:53 AM, Wayne Stambaugh wrote:

On 11/3/2017 8:54 AM, Maciej Sumiński wrote:

On 11/03/2017 11:30 AM, Kristoffer Ödmark wrote:

I think starting small would be best in this case. The
least needed
would be a "News" File, that is always refering to kicad
stable.

I propose the same way that patches with policy errors
are rejected,
patches that introduces new functionality or change of
existing
functionality are required to add to the News file, max
one line. Just
something like this, I would like markdown formatting.


Changes from Kicad 4
=

NEW: Pcbnew now supports clipboard copy/paste
CHANGE: Delete button now removes entire trace, not just
a segment
CHANGE: Icons in toolbar are improved
REMOVED: Autorouter no longer exists


This style could also be applied in the git commit
message, making it
easy to compile by something such as 'git log | grep "NEW:"'

But since that is lacking, I think starting a new file
is best.


I vote for git commit messages following a specific format
(could be
NEW:/CHANGE:/REMOVE: lines) to easily create change logs. It
is much
easier to see with git what has changed in a specific period
of time.
With NEWS file you would need at least put dates there to be
able to do
that (or see with git when a specific line has been added).

I know that ideally the user documentation should be updated
together
with the code, but on the other KiCad changes so fast, so
there might be
a lot of wasted time spent on changing the documentation and
updating
screens that might be invalid in a week or two. For sure the
documentation should be refreshed for a stable release.

Regards,
Orson


I'm not opposed to this idea but it should be used sensibly. 
Not all

new, changed, or removed code will require documentation changes.  I
would also prefer it not be in the first line of the commit message
unless the commit message is only one line.  It's already
difficult to
fit a descriptive commit title with only 72 characters.

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



-- 
  -Kristoffer



___
Mailing list: https://launchpad.net/~kicad-developers

Post to     : kicad-developers@lists.launchpad.net

Unsubscribe : https://launchpad.net/~kicad-developers

More help   : 

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

[Kristoffer Ödmark]

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.


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.

On 9 Nov 2017 03:15, "jp charras" > wrote:

 Le 08/11/2017 à 11:05, Oliver Walters a écrit :
 > 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

 Hi Oliver,

 Looks like currently, Pcbnew stores 3D offset in inches, unlike any
 other value.
 This is very annoying, but we have to leave with that.

 Therefore the patch breaks compatibility with any other Pcbnew
 version, if 3D offset is not 0.


 --
 Jean-Pierre CHARRAS

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



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



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



--
 -Kristoffer

___
Mailing list: https://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] Update of KiCad documentation?

[Nick Østergaard]

I think this might be better handled as bugs on the kicad-doc repo. Then
everyone can contribute easily and we can track it for the documentation,
where the info is to be used anyways. For now label them new_kicad_feature
if it is.

2017-11-09 10:54 GMT+01:00 Kristoffer Ödmark :

> I think for this to start happen, a decision has to be made, and enforced
> by everyone with commit access to the repo.
>
> Bugfixes need not be tagged like this. Major changes only.
>
> I still think a we should start collect a list in the repo with changes
> from kicad 4 up to the point this commit message policy is set. I for one
> love reading changelogs when upgrading, and I think the users are expecting
> this as well, and it probably will be useful in the FOSDEM presentation :)
>
>
> On 11/04/2017 01:53 AM, Wayne Stambaugh wrote:
>
>> On 11/3/2017 8:54 AM, Maciej Sumiński wrote:
>>
>>> On 11/03/2017 11:30 AM, Kristoffer Ödmark wrote:
>>>
 I think starting small would be best in this case. The least needed
 would be a "News" File, that is always refering to kicad stable.

 I propose the same way that patches with policy errors are rejected,
 patches that introduces new functionality or change of existing
 functionality are required to add to the News file, max one line. Just
 something like this, I would like markdown formatting.


 Changes from Kicad 4
 =

 NEW: Pcbnew now supports clipboard copy/paste
 CHANGE: Delete button now removes entire trace, not just a segment
 CHANGE: Icons in toolbar are improved
 REMOVED: Autorouter no longer exists


 This style could also be applied in the git commit message, making it
 easy to compile by something such as 'git log | grep "NEW:"'

 But since that is lacking, I think starting a new file is best.

>>>
>>> I vote for git commit messages following a specific format (could be
>>> NEW:/CHANGE:/REMOVE: lines) to easily create change logs. It is much
>>> easier to see with git what has changed in a specific period of time.
>>> With NEWS file you would need at least put dates there to be able to do
>>> that (or see with git when a specific line has been added).
>>>
>>> I know that ideally the user documentation should be updated together
>>> with the code, but on the other KiCad changes so fast, so there might be
>>> a lot of wasted time spent on changing the documentation and updating
>>> screens that might be invalid in a week or two. For sure the
>>> documentation should be refreshed for a stable release.
>>>
>>> Regards,
>>> Orson
>>>
>>>
>> I'm not opposed to this idea but it should be used sensibly.  Not all
>> new, changed, or removed code will require documentation changes.  I
>> would also prefer it not be in the first line of the commit message
>> unless the commit message is only one line.  It's already difficult to
>> fit a descriptive commit title with only 72 characters.
>>
>> 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
>>
>>
> --
>  -Kristoffer
>
>
> ___
> Mailing list: https://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] Update of KiCad documentation?

[Kristoffer Ödmark]

I think for this to start happen, a decision has to be made, and 
enforced by everyone with commit access to the repo.


Bugfixes need not be tagged like this. Major changes only.

I still think a we should start collect a list in the repo with changes 
from kicad 4 up to the point this commit message policy is set. I for 
one love reading changelogs when upgrading, and I think the users are 
expecting this as well, and it probably will be useful in the FOSDEM 
presentation :)


On 11/04/2017 01:53 AM, Wayne Stambaugh wrote:

On 11/3/2017 8:54 AM, Maciej Sumiński wrote:

On 11/03/2017 11:30 AM, Kristoffer Ödmark wrote:

I think starting small would be best in this case. The least needed
would be a "News" File, that is always refering to kicad stable.

I propose the same way that patches with policy errors are rejected,
patches that introduces new functionality or change of existing
functionality are required to add to the News file, max one line. Just
something like this, I would like markdown formatting.


Changes from Kicad 4
=

NEW: Pcbnew now supports clipboard copy/paste
CHANGE: Delete button now removes entire trace, not just a segment
CHANGE: Icons in toolbar are improved
REMOVED: Autorouter no longer exists


This style could also be applied in the git commit message, making it
easy to compile by something such as 'git log | grep "NEW:"'

But since that is lacking, I think starting a new file is best.


I vote for git commit messages following a specific format (could be
NEW:/CHANGE:/REMOVE: lines) to easily create change logs. It is much
easier to see with git what has changed in a specific period of time.
With NEWS file you would need at least put dates there to be able to do
that (or see with git when a specific line has been added).

I know that ideally the user documentation should be updated together
with the code, but on the other KiCad changes so fast, so there might be
a lot of wasted time spent on changing the documentation and updating
screens that might be invalid in a week or two. For sure the
documentation should be refreshed for a stable release.

Regards,
Orson



I'm not opposed to this idea but it should be used sensibly.  Not all
new, changed, or removed code will require documentation changes.  I
would also prefer it not be in the first line of the commit message
unless the commit message is only one line.  It's already difficult to
fit a descriptive commit title with only 72 characters.

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



--
 -Kristoffer

___
Mailing list: https://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

[Mário Luzeiro]

> - It appears that the internal units for 3D model offset (mm) were being 
> multiplied by 25.4 incorrectly

In case (as discussed on this email thread) there are no changes in the file 
format,
it would be good just to left a comment in the sourcecode about this issue, so 
future coders will not get confused why it is magically multiplied by 25.4

Mario Luzeiro
___
Mailing list: https://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

[Nick Østergaard]

In my opinion we should not be afraid to bump that version on master when
we already have done it since the branch was branched last time. If this
was a fix on a stable branch it would be of a greater concern, but should
probably just be noted in the release notes and everything should be honky
dory for the next minor release. It is better to get these things ironed
out before the next major release than after. Staying locked by such
annoyances will just handcuff us.

I of course expect the latest to be able to open old files that uses the
old value pairs.

2017-11-09 0:55 GMT+01:00 Wayne Stambaugh :

> 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.
> >
> > On 9 Nov 2017 03:15, "jp charras"  > > wrote:
> >
> > Le 08/11/2017 à 11:05, Oliver Walters a écrit :
> > > 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
> >
> > Hi Oliver,
> >
> > Looks like currently, Pcbnew stores 3D offset in inches, unlike any
> > other value.
> > This is very annoying, but we have to leave with that.
> >
> > Therefore the patch breaks compatibility with any other Pcbnew
> > version, if 3D offset is not 0.
> >
> >
> > --
> > Jean-Pierre CHARRAS
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> > 
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [REQUEST] Default library install location

[Thomas Kindler]

On Thu, November 9, 2017 00:12, easyw wrote:
>> I think it's a far more risky that a user makes accidental changes to
>> the bundled library. Simple users should not need to touch it, and
>> should rather copy or make a new part.
>
> so if a user wants to add a missing parts to his/her library he/her needs
> to save it to a different location, close the i.e. fp editor, copy with
> administrative privileges the fp to the Admin folder and restart the sw to
> use it? I don't think other sw are using this procedure...

No, the workflow would be as follows:

1. User opens a bundled library from /usr/share

  * editor shows "read only"
  * so user knows he can't edit this library directly


2. User uses "Save as.." to save a modifiable copy either in the project
folder or in his ~/.kicad/library folder (or on the company file server if
configured in the path).

  * Editor can now edit and save the file because it's not read-only anymore
  * KiCad will use the search path to let the newly saved library override
the bundled one.


So no admin-privileges or restarts required. It's a pretty normal
workflow.. no KiCAD dialogs or assistants are required. It's like unix
config files -- don't like the defaults of /etc/bashrc? just copy it to
~/.bashrc and edit away!

-- 
Thomas Kindler

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