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

[Wayne Stambaugh]

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

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

[Simon Wells]

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

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

[Wayne Stambaugh]

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

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

[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

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

[Oliver Walters]

Not that I am advocating copying Eagle, how do they manage their standard
libs? Does anyone know?

On 9 Nov 2017 10:15 AM, "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

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

[Oliver Walters]

Not that I am advocating copying Eagle, how do they manage their standard
libs? Does anyone know?

On 9 Nov 2017 10:15 AM, "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

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

[Simon Wells]

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

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

[easyw]

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

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

[Thomas Kindler]

On Wed, November 8, 2017 23:17, easyw wrote:
>> This is even worse.. that way co-workers could (even accidentally)
>> change the library without any notice.
>
> different point of view in working strategies... IMO something that I can
> change with i.e. the component editor and not save unless copied to a
> different location is a wrong way of working... but as I said there are
> many working habits...
>

Agreed.

The standard way would be that the editor displays a "[read-only]" tag in
the title bar, and grays out all editing commands.

That way the user wouldn't be surprised on save.

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. Otherwise there will be confusing bug
reports and users that downloaded an official release some time ago, but
now have a slightly broken (perhaps auto-updated) library.

On the other hand -- if a users /wants/ to make changes, he needs a proper
GIT clone anyways.


>
> On 11/8/2017 10:54 PM, Thomas Kindler wrote:
>
>> On Wed, November 8, 2017 22:18, easyw wrote:
>>
>>> the two a) and b) points are a big issue I think and this
>>> configuration is normally not present in other installer programs on
>>> windows...
>>>
>>> In windows a common User Folder is called common doc folder;
>>> the var pointing to C:\Users\Public is %PUBLIC% in recent Windows
>>> https://installmate.com/support/im9/kb/kb50038.htm#commondoc
>>> Then placing the libraries models/modules in i.e.
>>> C:\Users\Public\kicad
>>> folder, will let All Users have access read/write to these folders
>>>
>>> [..]
>>>
>>
>> This is even worse.. that way co-workers could (even accidentally)
>> change the library without any notice.
>>
>>
>> I think there are two use cases:
>>
>>
>> 1) Simple users of KiCAD
>>
>>
>> For this use case, the library should be installed in a write-protected
>>  location where only install admins can change them (like it is now).
>>
>> As a simple user I would expect stable KiCAD releases to come with an
>> official sanctioned library for that release. Eagle and most other CAD
>> packages do the same bundling.
>>
>> Auto-updaters that just update the library will confuse simple users,
>> and may cause compatibility problems if the library requires new
>> features.
>>
>> The same goes for automagic copy-on-write features - It's better to
>> just document how a library can be copied locally and how to override
>> the official one.
>>
>>
>> 2) Advanced users that want to contribute to the library
>>
>>
>> Advanced users should just clone the library using GIT. That way it's
>> possible to update and send pull requests using a normal, non-magic
>> workflow.
>>
>> An option to skip bundled library installation would be nice, but is
>> optional.
>>
>>
>> Library overrides could be done using a prioritized search path:
>>
>>
>> 1. $PROJECT/library# very useful for project-specific
>> things 2. ~/.KiCAD/library# useful for contributor work
>> 3. /usr/share/KiCAD/library# default for simple users
>>
>>
>> Of course, users could insert their own location like a company file
>> server..
>>
>> best regards,
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 


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

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

[easyw]

This is even worse.. that way co-workers could (even accidentally) change the 
library without any notice.


different point of view in working strategies...
IMO something that I can change with i.e. the component editor and not 
save unless copied to a different location is a wrong way of working...

but as I said there are many working habits...

M


On 11/8/2017 10:54 PM, Thomas Kindler wrote:

On Wed, November 8, 2017 22:18, easyw wrote:

the two a) and b) points are a big issue I think and this configuration is
normally not present in other installer programs on windows...

In windows a common User Folder is called common doc folder;
the var pointing to C:\Users\Public is %PUBLIC% in recent Windows
https://installmate.com/support/im9/kb/kb50038.htm#commondoc
Then placing the libraries models/modules in i.e. C:\Users\Public\kicad
folder, will let All Users have access read/write to these folders

[..]


This is even worse.. that way co-workers could (even accidentally) change
the library without any notice.


I think there are two use cases:

1) Simple users of KiCAD

   For this use case, the library should be installed in a write-protected
location where only install admins can change them (like it is now).

As a simple user I would expect stable KiCAD releases to come with an
official sanctioned library for that release. Eagle and most other CAD
packages do the same bundling.

Auto-updaters that just update the library will confuse simple users, and
may cause compatibility problems if the library requires new features.

The same goes for automagic copy-on-write features - It's better to just
document how a library can be copied locally and how to override the
official one.


2) Advanced users that want to contribute to the library

   Advanced users should just clone the library using GIT. That way it's
possible to update and send pull requests using a normal, non-magic
workflow.

An option to skip bundled library installation would be nice, but is
optional.


Library overrides could be done using a prioritized search path:

   1. $PROJECT/library# very useful for project-specific things
   2. ~/.KiCAD/library# useful for contributor work
   3. /usr/share/KiCAD/library# default for simple users

Of course, users could insert their own location like a company file server..

best regards,



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

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

[Thomas Kindler]

I just sent a duplicate list-mail using the wrong sender address.. sorry
for the noise!


On Wed, November 8, 2017 22:18, easyw wrote:
> the two a) and b) points are a big issue I think and this configuration is
> normally not present in other installer programs on windows...
>
> In windows a common User Folder is called common doc folder;
> the var pointing to C:\Users\Public is %PUBLIC% in recent Windows
> https://installmate.com/support/im9/kb/kb50038.htm#commondoc
> Then placing the libraries models/modules in i.e. C:\Users\Public\kicad
> folder, will let All Users have access read/write to these folders
>
> [..]

This is even worse.. that way co-workers could (even accidentally) change
the library without any notice.


I think there are two use cases:

1) Simple users of KiCAD

  For this use case, the library should be installed in a write-protected
location where only install admins can change them (like it is now).

As a simple user I would expect stable KiCAD releases to come with an
official sanctioned library for that release. Eagle and most other CAD
packages do the same bundling.

Auto-updaters that just update the library will confuse simple users, and
may cause compatibility problems if the library requires new features.

The same goes for automagic copy-on-write features - It's better to just
document how a library can be copied locally and how to override the
official one.


2) Advanced users that want to contribute to the library

  Advanced users should just clone the library using GIT. That way it's
possible to update and send pull requests using a normal, non-magic
workflow.

An option to skip bundled library installation would be nice, but is
optional.


Library overrides could be done using a prioritized search path:

  1. $PROJECT/library# very useful for project-specific things
  2. ~/.KiCAD/library# useful for contributor work
  3. /usr/share/KiCAD/library# default for simple users

Of course, users could insert their own location like a company file server..

best regards,
-- 
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

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

[easyw]

the two a) and b) points are a big issue I think and this configuration 
is normally not present in other installer programs on windows...


In windows a common User Folder is called common doc folder;
the var pointing to C:\Users\Public is %PUBLIC% in recent Windows
https://installmate.com/support/im9/kb/kb50038.htm#commondoc
Then placing the libraries models/modules in i.e. C:\Users\Public\kicad 
folder, will let All Users have access read/write to these folders


I'm not enough familiar in Unix, but I think it would be possible to 
just change folder permission during the installation, so the folder 
'\usr\share\kicad' could remain the default folder, but it will become 
writable by normal users... similar option for osx...

Maurice

On 11/8/2017 2:15 PM, Oliver Walters wrote:

Wayne,

I think you're right that a deeper understanding of how people are using 
and managing the libraries is required.


However, there still seems to be one of two options if KiCad installs 
libs into a location where users cannot write:


a) Users are not able to update the libraries or otherwise edit them
b) Users have to duplicate the library data to somewhere they *do* have 
access and then reassociate all the library tables


I think there is scope for improvement here. I'm not confident enough to 
say *what* that improvement should be.


On Thu, Nov 9, 2017 at 12:12 AM, Wayne Stambaugh > wrote:


What is the purpose of this change?  In what way will it improve the
user experience?  Before we ask the package devs to do a lot of work, we
might want to dig deeper into the library management issue.  I fail to
see how installing and likely duplicating the entire KiCad library in
the user's home folder solves any of the underlying library management
issues in KiCad other than having write access to modify the installed
libraries which has its own set of issues.  In some respects this has
the potential to complicate things even further.  I suspect the real
issue is out library editing and management tools.  I suggest we wait
until Orson pushes the symbol library editor to see if this improves the
library management situation.  Given what I know about it I suspect that
it will improve things significant on the library management side of
things.

Cheers,

Wayne

On 11/8/2017 2:02 AM, Oliver Walters wrote:
 > To the package maintainers:
 >
 > For v5 release, can the default library install path be set to a user
 > directory rather than program directory that may require
administrator
 > rights?
 >
 > e.g. instead of
 >
 > C:\Program Files\KiCad\share\...
 > or
 > /usr/share/kicad/...
 >
 > something like;
 >
 > C:\Users\Oliver\KiCad\...
 >
 > /home/Oliver/KiCad
 >
 > (Not necessarily those paths but something like that).
 >
 > A lot of users are reporting issues with being able to download or
 > modify library files, due to user privileges.
 >
 > How attainable is such a change before v5 release?
 >
 > Thanks,
 > Oliver
 >
 >
 > ___
 > Mailing list: https://launchpad.net/~kicad-developers

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

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

 > More help   : https://help.launchpad.net/ListHelp

 >

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

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

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

More help   : https://help.launchpad.net/ListHelp





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

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

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

[Oliver Walters]

José,

I think this is the correct approach

On 9 Nov 2017 02:56, "José Ignacio"  wrote:

> Doing a one-time copy from the system, copy on write like Nick suggested
> or just having kicad download the libraries itself would be the only real
> solutions IMO. Having the installer write to user directories is a no-no
> specially since there can be new users added to the system after kicad gets
> installed, who will have a "broken" install. The copying system in kicad
> also needs to offer at least the most rudimentary mechanism for upgrading
> the user's copies of the library when the system library gets updated (when
> kicad gets upgraded). That should NOT be an automatic process though, as it
> would be useful and expected that the user could review the change before
> touching the libraries.
>
> Also, for users like me that do not use the kicad library, if kicad
> doesn't get installed with libraries none of this copying would happen
> anyway.
>
> On Wed, Nov 8, 2017 at 7:15 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Wayne,
>>
>> I think you're right that a deeper understanding of how people are using
>> and managing the libraries is required.
>>
>> However, there still seems to be one of two options if KiCad installs
>> libs into a location where users cannot write:
>>
>> a) Users are not able to update the libraries or otherwise edit them
>> b) Users have to duplicate the library data to somewhere they *do* have
>> access and then reassociate all the library tables
>>
>> I think there is scope for improvement here. I'm not confident enough to
>> say *what* that improvement should be.
>>
>> On Thu, Nov 9, 2017 at 12:12 AM, Wayne Stambaugh 
>> wrote:
>>
>>> What is the purpose of this change?  In what way will it improve the
>>> user experience?  Before we ask the package devs to do a lot of work, we
>>> might want to dig deeper into the library management issue.  I fail to
>>> see how installing and likely duplicating the entire KiCad library in
>>> the user's home folder solves any of the underlying library management
>>> issues in KiCad other than having write access to modify the installed
>>> libraries which has its own set of issues.  In some respects this has
>>> the potential to complicate things even further.  I suspect the real
>>> issue is out library editing and management tools.  I suggest we wait
>>> until Orson pushes the symbol library editor to see if this improves the
>>> library management situation.  Given what I know about it I suspect that
>>> it will improve things significant on the library management side of
>>> things.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 11/8/2017 2:02 AM, Oliver Walters wrote:
>>> > To the package maintainers:
>>> >
>>> > For v5 release, can the default library install path be set to a user
>>> > directory rather than program directory that may require administrator
>>> > rights?
>>> >
>>> > e.g. instead of
>>> >
>>> > C:\Program Files\KiCad\share\...
>>> > or
>>> > /usr/share/kicad/...
>>> >
>>> > something like;
>>> >
>>> > C:\Users\Oliver\KiCad\...
>>> >
>>> > /home/Oliver/KiCad
>>> >
>>> > (Not necessarily those paths but something like that).
>>> >
>>> > A lot of users are reporting issues with being able to download or
>>> > modify library files, due to user privileges.
>>> >
>>> > How attainable is such a change before v5 release?
>>> >
>>> > Thanks,
>>> > Oliver
>>> >
>>> >
>>> > ___
>>> > Mailing list: https://launchpad.net/~kicad-developers
>>> > Post to : kicad-developers@lists.launchpad.net
>>> > Unsubscribe : https://launchpad.net/~kicad-developers
>>> > More help   : https://help.launchpad.net/ListHelp
>>> >
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> ___
>> Mailing list: https://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

[jp charras]

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

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

[José Ignacio]

Doing a one-time copy from the system, copy on write like Nick suggested or
just having kicad download the libraries itself would be the only real
solutions IMO. Having the installer write to user directories is a no-no
specially since there can be new users added to the system after kicad gets
installed, who will have a "broken" install. The copying system in kicad
also needs to offer at least the most rudimentary mechanism for upgrading
the user's copies of the library when the system library gets updated (when
kicad gets upgraded). That should NOT be an automatic process though, as it
would be useful and expected that the user could review the change before
touching the libraries.

Also, for users like me that do not use the kicad library, if kicad doesn't
get installed with libraries none of this copying would happen anyway.

On Wed, Nov 8, 2017 at 7:15 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Wayne,
>
> I think you're right that a deeper understanding of how people are using
> and managing the libraries is required.
>
> However, there still seems to be one of two options if KiCad installs libs
> into a location where users cannot write:
>
> a) Users are not able to update the libraries or otherwise edit them
> b) Users have to duplicate the library data to somewhere they *do* have
> access and then reassociate all the library tables
>
> I think there is scope for improvement here. I'm not confident enough to
> say *what* that improvement should be.
>
> On Thu, Nov 9, 2017 at 12:12 AM, Wayne Stambaugh 
> wrote:
>
>> What is the purpose of this change?  In what way will it improve the
>> user experience?  Before we ask the package devs to do a lot of work, we
>> might want to dig deeper into the library management issue.  I fail to
>> see how installing and likely duplicating the entire KiCad library in
>> the user's home folder solves any of the underlying library management
>> issues in KiCad other than having write access to modify the installed
>> libraries which has its own set of issues.  In some respects this has
>> the potential to complicate things even further.  I suspect the real
>> issue is out library editing and management tools.  I suggest we wait
>> until Orson pushes the symbol library editor to see if this improves the
>> library management situation.  Given what I know about it I suspect that
>> it will improve things significant on the library management side of
>> things.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 11/8/2017 2:02 AM, Oliver Walters wrote:
>> > To the package maintainers:
>> >
>> > For v5 release, can the default library install path be set to a user
>> > directory rather than program directory that may require administrator
>> > rights?
>> >
>> > e.g. instead of
>> >
>> > C:\Program Files\KiCad\share\...
>> > or
>> > /usr/share/kicad/...
>> >
>> > something like;
>> >
>> > C:\Users\Oliver\KiCad\...
>> >
>> > /home/Oliver/KiCad
>> >
>> > (Not necessarily those paths but something like that).
>> >
>> > A lot of users are reporting issues with being able to download or
>> > modify library files, due to user privileges.
>> >
>> > How attainable is such a change before v5 release?
>> >
>> > Thanks,
>> > Oliver
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://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

[Oliver Walters]

Wayne,

I think you're right that a deeper understanding of how people are using
and managing the libraries is required.

However, there still seems to be one of two options if KiCad installs libs
into a location where users cannot write:

a) Users are not able to update the libraries or otherwise edit them
b) Users have to duplicate the library data to somewhere they *do* have
access and then reassociate all the library tables

I think there is scope for improvement here. I'm not confident enough to
say *what* that improvement should be.

On Thu, Nov 9, 2017 at 12:12 AM, Wayne Stambaugh 
wrote:

> What is the purpose of this change?  In what way will it improve the
> user experience?  Before we ask the package devs to do a lot of work, we
> might want to dig deeper into the library management issue.  I fail to
> see how installing and likely duplicating the entire KiCad library in
> the user's home folder solves any of the underlying library management
> issues in KiCad other than having write access to modify the installed
> libraries which has its own set of issues.  In some respects this has
> the potential to complicate things even further.  I suspect the real
> issue is out library editing and management tools.  I suggest we wait
> until Orson pushes the symbol library editor to see if this improves the
> library management situation.  Given what I know about it I suspect that
> it will improve things significant on the library management side of
> things.
>
> Cheers,
>
> Wayne
>
> On 11/8/2017 2:02 AM, Oliver Walters wrote:
> > To the package maintainers:
> >
> > For v5 release, can the default library install path be set to a user
> > directory rather than program directory that may require administrator
> > rights?
> >
> > e.g. instead of
> >
> > C:\Program Files\KiCad\share\...
> > or
> > /usr/share/kicad/...
> >
> > something like;
> >
> > C:\Users\Oliver\KiCad\...
> >
> > /home/Oliver/KiCad
> >
> > (Not necessarily those paths but something like that).
> >
> > A lot of users are reporting issues with being able to download or
> > modify library files, due to user privileges.
> >
> > How attainable is such a change before v5 release?
> >
> > Thanks,
> > Oliver
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://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

[Wayne Stambaugh]

What is the purpose of this change?  In what way will it improve the
user experience?  Before we ask the package devs to do a lot of work, we
might want to dig deeper into the library management issue.  I fail to
see how installing and likely duplicating the entire KiCad library in
the user's home folder solves any of the underlying library management
issues in KiCad other than having write access to modify the installed
libraries which has its own set of issues.  In some respects this has
the potential to complicate things even further.  I suspect the real
issue is out library editing and management tools.  I suggest we wait
until Orson pushes the symbol library editor to see if this improves the
library management situation.  Given what I know about it I suspect that
it will improve things significant on the library management side of things.

Cheers,

Wayne

On 11/8/2017 2:02 AM, Oliver Walters wrote:
> To the package maintainers:
> 
> For v5 release, can the default library install path be set to a user
> directory rather than program directory that may require administrator
> rights?
> 
> e.g. instead of 
> 
> C:\Program Files\KiCad\share\...
> or
> /usr/share/kicad/...
> 
> something like;
> 
> C:\Users\Oliver\KiCad\...
> 
> /home/Oliver/KiCad
> 
> (Not necessarily those paths but something like that).
> 
> A lot of users are reporting issues with being able to download or
> modify library files, due to user privileges. 
> 
> How attainable is such a change before v5 release?
> 
> Thanks,
> Oliver
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] [PATCH] wxWidgets macOS 10.13 Patch

[Wayne Stambaugh]

Thanks Adam!

On 11/7/2017 10:07 PM, Adam Wolf wrote:
> I'll prep a patch for the build doc in the next few days.
> 
> Adam
> 
> On Tue, Nov 7, 2017 at 7:06 AM, Wayne Stambaugh  wrote:
>> My preference would be add it to the kicad build doc.  It would be
>> easier to find this information in the kicad build document than the
>> developers mailing list and easier to point someone to the build docs.
>> It may be a while before wx 3.0.4 is available and I imagine even longer
>> until folks stop creating osx builds with 10.13 and wx 3.0.3.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 11/7/2017 7:50 AM, Adam Wolf wrote:
>>> No problem.  More details about the CPPFLAG are here:
>>>
>>> https://trac.wxwidgets.org/ticket/17929
>>>
>>> Once 3.0.4 is out, it'll be handled inside of wxwidgets, so it's just
>>> a transitory thing for folks looking to build on High Sierra now.
>>>
>>> Honestly, I'm not sure we need to to add it to any docs or anything,
>>> but if people come knocking asking for help on building KiCad on 10.13
>>> in the next few months, maybe they'll find this message.
>>>
>>> Adam Wolf
>>>
>>> On Tue, Nov 7, 2017 at 1:59 AM, Maciej Sumiński  
>>> wrote:
 Hi Adam,

 Thank you for the (meta)patch. Would you give some more details about
 the required CPPFLAG? Perhaps we could do something on our side? I would
 rather avoid adding one more requirement to the way wxWidgets building
 process, unless there is really no other method.

 Regards,
 Orson

 On 11/07/2017 03:25 AM, 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
>>>
>>
>> ___
>> Mailing list: https://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] Eeschema automatic manage junctions

[Nick Østergaard]

For that specific issue with the junction drawing, there is a patch in the
thread "[Kicad-developers] [PATCH] Draw junctions last"

2017-11-03 13:12 GMT+01:00 Jon Evans :

> I looked at fixing this and some other related things, and decided to just
> wait for the GAL port. There will need to be huge refactoring of the
> eeschema draw code as part of that effort, so putting much effort into
> making the wxDC drawing better seems not worth it.
>
> -Jon
>
> On Nov 3, 2017 00:08, "Kevin Cozens"  wrote:
>
> On 2017-11-02 06:31 PM, Seth Hillbrand wrote:
>
>> Please let me know if there are any additional issues or suggestions for
>> improvement.
>>
>
> How difficult would it be to have junctions draw last on schematics? There
> is a minor negative visual effect when you have a component with one end
> joined to a wire by a junction and you replace the component.
>
> When you replace the component the pin of the component is now seen
> extending through the round disc of the junction to the center of the
> junction. I prefer to always see just the full round disc of a junction
> mark even if I have replaced a component since placing the junction.
>
> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   |"Nerds make the shiny things that
> distract
> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
> | powerful!"
> #include  | --Chris Hardwick
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

[Adam Wolf]

This wouldn't be difficult on macOS.  It is already kinda set up like that
with the split installer already..

Adam Wolf

On Nov 8, 2017 1:02 AM, "Oliver Walters" 
wrote:

> To the package maintainers:
>
> For v5 release, can the default library install path be set to a user
> directory rather than program directory that may require administrator
> rights?
>
> e.g. instead of
>
> C:\Program Files\KiCad\share\...
> or
> /usr/share/kicad/...
>
> something like;
>
> C:\Users\Oliver\KiCad\...
>
> /home/Oliver/KiCad
>
> (Not necessarily those paths but something like that).
>
> A lot of users are reporting issues with being able to download or modify
> library files, due to user privileges.
>
> How attainable is such a change before v5 release?
>
> Thanks,
> Oliver
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

[Oliver Walters]

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
From 4cfd526944dccf41b89c921ef45f5b6b07a23f35 Mon Sep 17 00:00:00 2001
From: Oliver 
Date: Wed, 8 Nov 2017 20:56:57 +1100
Subject: [PATCH] Fixes for 3D model offset

- Display offset units in 3D preview window (inches or mm)
- Fix offset in 3D renderer
- Fix offset in Raytracing renderer
- Fix offset in STEP export
- Fix offset in VRML export
---
 3d-viewer/3d_cache/dialogs/panel_prev_3d_base.cpp  | 15 +++--
 3d-viewer/3d_cache/dialogs/panel_prev_3d_base.fbp  | 16 +++---
 3d-viewer/3d_cache/dialogs/panel_prev_3d_base.h|  5 +-
 3d-viewer/3d_cache/dialogs/panel_prev_model.cpp| 67 +++---
 .../3d_render_ogl_legacy/c3d_render_ogl_legacy.cpp |  4 +-
 .../c3d_render_createscene.cpp |  6 +-
 pcbnew/class_module.h  |  8 +++
 pcbnew/exporters/export_vrml.cpp   | 10 ++--
 utils/kicad2step/pcb/kicadmodel.cpp|  5 +-
 utils/kicad2step/pcb/oce_utils.cpp |  7 +--
 10 files changed, 89 insertions(+), 54 deletions(-)

diff --git a/3d-viewer/3d_cache/dialogs/panel_prev_3d_base.cpp b/3d-viewer/3d_cache/dialogs/panel_prev_3d_base.cpp
index f7b9fca..826e189 100644
--- a/3d-viewer/3d_cache/dialogs/panel_prev_3d_base.cpp
+++ b/3d-viewer/3d_cache/dialogs/panel_prev_3d_base.cpp
@@ -1,5 +1,5 @@
 ///
-// C++ code generated with wxFormBuilder (version Aug  4 2017)
+// C++ code generated with wxFormBuilder (version Mar 22 2017)
 // http://www.wxformbuilder.org/
 //
 // PLEASE DO "NOT" EDIT THIS FILE!
@@ -40,7 +40,7 @@ PANEL_PREV_3D_BASE::PANEL_PREV_3D_BASE( wxWindow* parent, wxWindowID id, const w
 	fgSizerScale->Add( m_staticText2, 0, wxALIGN_CENTER_VERTICAL|wxLEFT, 5 );
 	
 	yscale = new wxTextCtrl( vbScale->GetStaticBox(), wxID_ANY, wxEmptyString, wxDefaultPosition, wxDefaultSize, 0 );
-	fgSizerScale->Add( yscale, 0, wxALIGN_CENTER_VERTICAL|wxLEFT, 5 );
+	fgSizerScale->Add( yscale, 0, wxALIGN_CENTER_VERTICAL|wxBOTTOM|wxLEFT|wxTOP, 5 );
 	
 	m_spinYscale = new wxSpinButton( vbScale->GetStaticBox(), wxID_ANY, wxDefaultPosition, wxDefaultSize, wxSP_ARROW_KEYS|wxSP_VERTICAL );
 	fgSizerScale->Add( m_spinYscale, 0, wxALIGN_CENTER_VERTICAL, 5 );
@@ -53,7 +53,7 @@ PANEL_PREV_3D_BASE::PANEL_PREV_3D_BASE( wxWindow* parent, wxWindowID id, const w
 	fgSizerScale->Add( zscale, 0, wxALIGN_CENTER_VERTICAL|wxBOTTOM|wxLEFT, 5 );
 	
 	m_spinZscale = new wxSpinButton( vbScale->GetStaticBox(), wxID_ANY, wxDefaultPosition, wxDefaultSize, wxSP_ARROW_KEYS|wxSP_VERTICAL );
-	fgSizerScale->Add( m_spinZscale, 0, wxALIGN_CENTER_VERTICAL, 5 );
+	fgSizerScale->Add( m_spinZscale, 0, wxALIGN_CENTER_VERTICAL|wxBOTTOM, 5 );
 	
 	
 	vbScale->Add( fgSizerScale, 1, wxEXPAND, 5 );
@@ -100,7 +100,7 @@ PANEL_PREV_3D_BASE::PANEL_PREV_3D_BASE( wxWindow* parent, wxWindowID id, const w
 	#else
 	yrot->SetMaxLength( 9 );
 	#endif
-	fgSizerRotate->Add( yrot, 0, wxALIGN_CENTER_VERTICAL|wxLEFT, 5 );
+	fgSizerRotate->Add( yrot, 0, wxALIGN_CENTER_VERTICAL|wxBOTTOM|wxLEFT|wxTOP, 5 );
 	
 	m_spinYrot = new wxSpinButton( vbRotate->GetStaticBox(), wxID_ANY, wxDefaultPosition, wxDefaultSize, wxSP_ARROW_KEYS|wxSP_VERTICAL );
 	fgSizerRotate->Add( m_spinYrot, 0, wxALIGN_CENTER_VERTICAL, 5 );
@@ -121,7 +121,7 @@ PANEL_PREV_3D_BASE::PANEL_PREV_3D_BASE( wxWindow* parent, wxWindowID id, const w
 	fgSizerRotate->Add( zrot, 0, wxALIGN_CENTER_VERTICAL|wxBOTTOM|wxLEFT, 5 );
 	
 	m_spinZrot = new wxSpinButton( vbRotate->GetStaticBox(), wxID_ANY, wxDefaultPosition, wxDefaultSize, wxSP_ARROW_KEYS|wxSP_VERTICAL );
-	fgSizerRotate->Add( m_spinZrot, 0, wxALIGN_CENTER_VERTICAL, 5 );
+	fgSizerRotate->Add( m_spinZrot, 0, wxALIGN_CENTER_VERTICAL|wxBOTTOM, 5 );
 	
 	
 	vbRotate->Add( fgSizerRotate, 1, wxEXPAND, 5 );
@@ -129,7 +129,6 @@ PANEL_PREV_3D_BASE::PANEL_PREV_3D_BASE( wxWindow* parent, wxWindowID id, const w
 	
 	bSizerLeft->Add( vbRotate, 0, wxEXPAND, 5 );
 	
-	wxStaticBoxSizer* vbOffset;
 	vbOffset = new wxStaticBoxSizer( new wxStaticBox( this, wxID_ANY, _("Offset") ), wxVERTICAL );
 	
 	wxFlexGridSizer* fgSizerOffset;
@@ -152,7 +151,7 @@ PANEL_PREV_3D_BASE::PANEL_PREV_3D_BASE( wxWindow* parent, wxWindowID id, const w
 	fgSizerOffset->Add( m_staticText22, 0, wxALIGN_CENTER_VERTICAL|wxLEFT, 5 );
 	
 	yoff = new wxTextCtrl( vbOffset->GetStaticBox(), wxID_ANY, wxEmptyString, wxDefaultPosition, wxDefaultSize, 0 );
-	fgSizerOffset->Add( yoff, 0, 

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

[Nick Østergaard]

Have you tried to use the copy on write feature already available with the
fp lib table at least?

Den 8. nov. 2017 10.00 skrev "José Ignacio" :

What about installing it in a system directory. and have kicad copy them
over to the user directory on first boot? that would probably work well for
multiuser systems, otherwise you'd have to copy it on every user of the
machine, even future ones.

On Wed, Nov 8, 2017 at 2:46 AM, Nick Østergaard  wrote:

> It is problematic in various ways. There may be some way to achieve this
> in the windows installer, but I need to investigate this. I don't know
> about the macos installer.
>
> On linux, I don't know how this should be done if we want to provide
> normal packages for this. I think it would be better if we integrate a
> better downloaded (AND UPDATER) kicad to handle this. Alternatively it
> could be a user script, for example a python script which we should be able
> to make quite portable, also given that we are sort of sure we have the
> python env for a proper kicad installation.
>
> 2017-11-08 <20%2017%2011%2008> 8:02 GMT+01:00 Oliver Walters <
> oliver.henry.walt...@gmail.com>:
>
>> To the package maintainers:
>>
>> For v5 release, can the default library install path be set to a user
>> directory rather than program directory that may require administrator
>> rights?
>>
>> e.g. instead of
>>
>> C:\Program Files\KiCad\share\...
>> or
>> /usr/share/kicad/...
>>
>> something like;
>>
>> C:\Users\Oliver\KiCad\...
>>
>> /home/Oliver/KiCad
>>
>> (Not necessarily those paths but something like that).
>>
>> A lot of users are reporting issues with being able to download or modify
>> library files, due to user privileges.
>>
>> How attainable is such a change before v5 release?
>>
>> Thanks,
>> Oliver
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://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

[José Ignacio]

What about installing it in a system directory. and have kicad copy them
over to the user directory on first boot? that would probably work well for
multiuser systems, otherwise you'd have to copy it on every user of the
machine, even future ones.

On Wed, Nov 8, 2017 at 2:46 AM, Nick Østergaard  wrote:

> It is problematic in various ways. There may be some way to achieve this
> in the windows installer, but I need to investigate this. I don't know
> about the macos installer.
>
> On linux, I don't know how this should be done if we want to provide
> normal packages for this. I think it would be better if we integrate a
> better downloaded (AND UPDATER) kicad to handle this. Alternatively it
> could be a user script, for example a python script which we should be able
> to make quite portable, also given that we are sort of sure we have the
> python env for a proper kicad installation.
>
> 2017-11-08 8:02 GMT+01:00 Oliver Walters :
>
>> To the package maintainers:
>>
>> For v5 release, can the default library install path be set to a user
>> directory rather than program directory that may require administrator
>> rights?
>>
>> e.g. instead of
>>
>> C:\Program Files\KiCad\share\...
>> or
>> /usr/share/kicad/...
>>
>> something like;
>>
>> C:\Users\Oliver\KiCad\...
>>
>> /home/Oliver/KiCad
>>
>> (Not necessarily those paths but something like that).
>>
>> A lot of users are reporting issues with being able to download or modify
>> library files, due to user privileges.
>>
>> How attainable is such a change before v5 release?
>>
>> Thanks,
>> Oliver
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://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]

It is problematic in various ways. There may be some way to achieve this in
the windows installer, but I need to investigate this. I don't know about
the macos installer.

On linux, I don't know how this should be done if we want to provide normal
packages for this. I think it would be better if we integrate a better
downloaded (AND UPDATER) kicad to handle this. Alternatively it could be a
user script, for example a python script which we should be able to make
quite portable, also given that we are sort of sure we have the python env
for a proper kicad installation.

2017-11-08 8:02 GMT+01:00 Oliver Walters :

> To the package maintainers:
>
> For v5 release, can the default library install path be set to a user
> directory rather than program directory that may require administrator
> rights?
>
> e.g. instead of
>
> C:\Program Files\KiCad\share\...
> or
> /usr/share/kicad/...
>
> something like;
>
> C:\Users\Oliver\KiCad\...
>
> /home/Oliver/KiCad
>
> (Not necessarily those paths but something like that).
>
> A lot of users are reporting issues with being able to download or modify
> library files, due to user privileges.
>
> How attainable is such a change before v5 release?
>
> Thanks,
> Oliver
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp