from:"David Godfrey"

Re: [Kicad-developers] Translation of dialog_bom_help.html

2018-07-12 Thread David Godfrey


  
  
Hi Wayne,
Out of interest, if formatted translated text is required in this
  dialogue would  it be easier to change from html to markdown?
  
  At least markdown is fairly easy for a translator to work with,
  although it doesn't provide all of the flexibility of html.


   Regards
  David Godfrey
  SB Tech Services
  mb: +61 437 286 200
  
chat:
  with dcg_mx at
  #sbts:matrix.org
  (Computer)
  #sbts:matrix.org
  (mobile Device)  
  
  

On 12/07/18 22:15, Wayne Stambaugh
  wrote:


  On 7/12/2018 8:59 AM, Simon Richter wrote:

  
Hi,

On 11.07.2018 21:51, Wayne Stambaugh wrote:



  This probably should have been done as a cpp string wrapped with the
translation macro _().  I'm not sure there is anything we can do to make
this translatable.  Anyone else have any ideas?



We could move the entire text to the user documentation, and make the
dialog point at it.

If the dialog is unusable without the documentation, then that is a
separate problem, but I doubt it's that bad.

   Simon

  
  
I completely missed the fact the html file is converted to a C string by
Html2C.cmake.  It would be easy enough to modify Html2C.cmake to wrap
the string with the _() macro.  The problem I see is the string (see
generated file eeschema/dialogs/dialog_bom_help_html.h) has a lot of
markup which I'm sure will make life miserable for translators.

We could try Simon's suggestion of moving the html text to the eeschema
user docs and provide a link using the help button.  We would have to
add code to point the help url to the translated version if it exists
but that shouldn't be too difficult (famous last words).  The contents
of the BOM dialog html file do not appear to exist anywhere in the
eeschema user doc.

In the future we should refrain from doing this so that all source
strings and documentation can be translated.

Wayne

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





  


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

Re: [Kicad-developers] pcbnew Append Board functionality not always available

2017-11-10 Thread David Godfrey


  
  
Hi Wayne, 

Replying to this particular response as your email didn't arrive
  on the list for me, Simon's did though.
I completely understand about not wanting to rush into enabling
  it, I just wanted to raise it to the surface of the teams
  attention again as it's probably the 3rd or 4th time it's come up
  recently that I've seen and I don't see everything ;-)


   Regards
  David Godfrey
  SB Tech Services
  mb: +61 437 286 200
  
chat:
  with dcg_mx at
  #sbts:matrix.org
  (Computer)
  #sbts:matrix.org
  (mobile Device)  
  
  

On 11/11/17 09:23, Simon Wells wrote:


  
  Speaking of append board causing crashes
  
  
  https://bugs.launchpad.net/kicad/+bug/1728096
  
  
  

  
On 11/11/2017, at 14:03, Wayne Stambaugh <stambau...@gmail.com>
  wrote:


  Hey David,

The main reason is that no one has had the time to look
into it.  I
don't just want to always enable appending a board only
to find out it
crashes kicad in the project mode so it would just take
(how much I do
not know) time for someone to look into it.

Cheers,

Wayne

On 11/10/2017 4:51 PM, David Godfrey wrote:
Hi Wayne,
  
  This just cropped up (again) on #kicad irc channel so
  I thought I'd
  check and see if there is a reason why
   File->Append Board
  is only accessible if PCBnew is run standalone (as
  compared to from the
  Project Interface)
  
  -- 
  Regards
      David Godfrey
  SB Tech Services
  
  chat: with /dcg_mx/ at
  #sbts:matrix.org <http://riot.im/app/#/room/#sbts:matrix.org>
  (Computer)
  #sbts:matrix.org <http://matrix.to/#/#sbts:matrix.org>
  (mobile Device)
  
  



___
Mailing list: https://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] pcbnew Append Board functionality not always available

2017-11-10 Thread David Godfrey


  
  
Hi Wayne,
This just cropped up (again) on #kicad irc channel so I thought
  I'd check and see if there is a reason why 
   File->Append Board
  is only accessible if PCBnew is run standalone (as compared to
  from the Project Interface)

-- 
   Regards
      David Godfrey
  SB Tech Services
  
chat:
  with dcg_mx at
  #sbts:matrix.org
  (Computer)
  #sbts:matrix.org
  (mobile Device)  
  
  

  


___
Mailing list: https://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] GitHub Plugin (my nemesis)

2017-10-01 Thread David Godfrey

version of the library is used to compile, at which point it's in
the hands of the developer, rather than the user.

Oliver

Regards
David Godfrey
SB Tech Services
mb: +61 437 286 200

On Thu, Sep 28, 2017 at 7:25 PM, Simon
Küppers <simon.kuepp...@rub.de>
wrote:

Thanks for your detailed description. I think it is a
nice way to go. However two remarks:
Does it simplify the maintenance of the kicad library by
the librarians? Is it github compatible? If not, we would
need to find another platform to host the libraries.

If I look for git submodule, there is a lot of different
opinions on why you should or should not use it. (e.g. https://www.google.de/amp/s/codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/amp/).
Does it apply in our case? What about git subtree?

Best regards

Simon

Am 28. September 2017 02:37:09 MESZ
schrieb David Godfrey <i...@sbts.com.au>:

Hi All

I have to agree with some of the other posters, why not use git as it
was intended?

Specifically I think the following makes sense.

- Keep the multiple repositories, this helps when a company only wants
to make certain sets of libs available to it's staff

- Have a master repository that includes all other repositories as
submodules.

- Have branches that are matched to kicad versions. This allows
footprint changes in a version safe way.

- Use standard "git clone" (initial download) and "git pull" (update) on
the main repo which provides the entire set of available libs without
actually downloading the content for all libs.

- When a specific lib is needed, do similar to what we do now, and use
"git submodule update --init --recursive $submoduleName" to just pull
that specific submodule

- Allow the "main" library repo URI to be altered. This enables a
companies fork of the repo to be used.

- Allow the "main" library repo URI to be ANY valid git URI. That means
a repo on a local fileserver rather than a http server can be used.
Along with various security options etc.

- Add a fairly simple scripted tool that's run "on release" to retrieve
a README.md (an possibly a descriptor/index file) from each actual
library repo and update those within the "main" repo. This removes the
need to have the current case where manual edits are required to keep
the "main" repo in sync with what's available in the individual lib's.

To add a new lib, it's then as simple as (from the main repo) doing
something like
- "git submodule add $URI"
- "./scripts/update-library-indexes.sh"
- "git commit -a -m $'added new module "modulename"\nupdated all module
descriptions and index'"
- "git push"

All of the above allows the Main repo to be forked by a company (or
individual) and have their own custom repo's added very easily.
It even allows libraries to be easily excluded or replaced, all using
extremely well developed management tools.

On a side note, git submodules are stored in the main repository
basically as URI that includes a commit reference.
That means it's easy to specify a specific library version to include in
a specific branch/tag of the main repo.

As for the person that said "git isn't available for windows", sorry,
that's bunkum.
There are many many development environments out there that ONLY run on
windows that have git integration.
A quick google search for "git for windows" will show what you need to
know there.

Finally, wrapping git to duplicate the effective API that's currently in
use should be relatively trivial, resulting in virtually no code changes
required to KICAD it's self.
Assuming the existing functionality is cleanly wrapped by an API, the
only real change to KICAD would be the swapout of the module, and
addition of an easy way to change the URI

I know I haven't covered everything in this email, but it should be a
good outline for further discussion

On 22/09/17 09:21, Oliver Walters wrote:
Hi all,

Ok, now that the website integration with the libraries is (pretty
much) done, and the licensing issue seems to be sorted, there is one
final puzzle piece to solve before I'm happy with the state of the
libraries for a v5 release.

*Goal: *Merge all footprint library repositories into a single repo to
solve the ongoing dramas of maintaining 100+ repos.

*Problem*: The *only* thing sta

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

2017-10-01 Thread David Godfrey

tories to manage.

Let's not make this an academic problem
and say "but it's possible to manage with this complex
set of tools"! From the perspective of a contributor,
and as the person who has to manage the libraries, the
simpler the better.

Oliver

On Thu, Sep 28, 2017 at 7:25
PM, Simon Küppers <simon.kuepp...@rub.de>
wrote:

Thanks for your detailed description.
I think it is a nice way to go. However two
remarks:
Does it simplify the maintenance of the kicad
library by the librarians? Is it github
compatible? If not, we would need to find another
platform to host the libraries.

If I look for git submodule, there is a lot of
different opinions on why you should or should not
use it. (e.g. https://www.google.de/amp/s/codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/amp/). Does it apply
in our case? What about git subtree?

Best regards

Simon

Am 28. September 2017 02:37:09
MESZ schrieb David Godfrey <i...@sbts.com.au>:

Hi All

I have to agree with some of the other posters, why not use git as it
was intended?

Specifically I think the following makes sense.

- Keep the multiple repositories, this helps when a company only wants
to make certain sets of libs available to it's staff

- Have a master repository that includes all other repositories as
submodules.

- Have branches that are matched to kicad versions. This allows
footprint changes in a version safe way.

- Use standard "git clone" (initial download) and "git pull" (update) on
the main repo which provides the entire set of available libs without
actually downloading the content for all libs.

- When a specific lib is needed, do similar to what we do now, and use
"git submodule update --init --recursive $submoduleName" to just pull
that specific submodule

- Allow the "main" library repo URI to be altered. This enables a
companies fork of the repo to be used.

- Allow the "main" library repo URI to be ANY valid git URI. That means
a repo on a local fileserver rather than a http server can be used.
Along with various security options etc.

I know I haven't covered everything in this email, but it should be a
good outline

Re: [Kicad-developers] Deleting layers.

2017-10-01 Thread David Godfrey


  
  
Thanks for the quick patch Wayne.
I'm focused on software dev right now, but will test when I can
  free up some cycles.


   Regards
  David Godfrey
  SB Tech Services
  mb: +61 437 286 200
  
chat:
  with dcg_mx at
  #sbts:matrix.org
  (Computer)
  #sbts:matrix.org
  (mobile Device)  
  
  

On 29/09/17 01:14, Wayne Stambaugh
  wrote:


  I recant my original position that it would not be a trivial fix.  I
just pushed the fix to the master branch.  Please test it and let me
know if you find any issues.  I will be out of town over the weekend so
I may not reply as quickly as I normally do.

Please note that this fix isn't ideal.  Since Pcbnew does not support
odd numbered copper layers, selecting front or back layer only
configuration in the layer select dialog will not remove objects from
the copper layers.  It will remove them from all other layers if they
are not part of a footprint.  Even though this isn't technically
correct, it will (should?) prevent any false positive DRC tests from
occurring because objects will only exist on layers that exist.  Keep in
mind that this operation cannot be undone so once you save the board
after removing layers, that information is lost.  If you are not sure
about the change, don't save the board.

I will now resume my previously scheduled symbol library table work.

Cheers,

Wayne

On 9/28/2017 3:18 AM, Kristoffer Ödmark wrote:

  
I agree as well, I've been hit by this bug once. And it was enough. I
was actually planning to try and fix it similar to the way you are
proposing right after the copypasta thingy is done.

( My ideal solution would be to add a "remove items on extra layers"
button to the dialog that would become enabled when removing layers, and
simultaneously disbling the OK button, and only by pressing that would
the OK button become enabled. )

On 09/28/2017 01:32 AM, David Godfrey wrote:


  Hi Wayne,

I'll back you on this decision.
It's more than once cost both time and money, to say nothing of
frustration to multiple users.

Personally, I've not been caught with sending a board to production in
this state, but I certainly have run into the problem and caught it
during routing (Obviously non connected pins that don't DRC)

If a layer is deleted, it's deleted, there simply shouldn't be any
leftovers of any description.
A clear warning that this is happening and confirmation dialog is
really all that is needed, especially if that dialog explicitly lists
the layers that are being removed.


On 27/09/17 22:08, Wayne Stambaugh wrote:

  
This bug[1] has reared it's ugly head again so I am going to fix it once
and for all before the stable 5 release.  We cannot continue storing
objects on deleted layers in the board file which cause the DRC to pass
connection tests when in reality there are failures.  I don't really
have the time so you should assume that this is going push back the
release.  It probably should be backported to the stable release but
given the code deviations, I don't see that happening unless someone
else feels motivated to do so.  I looked at the existing code and it's
not going to be a trivial fix.  I do not intend to do anything fancy
such as give the user the option to merge objects from deleted layers to
other layers.  I'm going to keep it simple by just warning the user and
removing all objects from the removed layers.  This includes non-copper
layers as well.  I don't see how keeping objects on layers that don't
exist in the board is valid.  I'm not really asking for comments but if
you have any suggestions outside what I have presented I am willing to
entertain them.

[1]: https://bugs.launchpad.net/kicad/+bug/893950

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


  
  Regards
David Godfrey
SB Tech Services
mb: +61 437 286 200 <tel:+61437286200>


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

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

2017-09-27 Thread David Godfrey

rsion - GitHub actually provides subversion API - 
https://www.seanw.org/blog/download-git-repo-subdirectory/



*Subversion*

In either case, I think that using the subversion tool to partially 
download the libraries would be a good approach (I assume quicker than 
using wget and the GitHub API).


1. Does anyone have any experience using the C API for SVN?
2. The Python bindings are pretty good - 
https://pypi.python.org/pypi/svn - and much easier to use. However, 
can we make the library download tools dependent on enabling the 
python plugin?
3. Is there a way to checkout a subversion remote to memory (to 
replicate the functionality of the current GitHub plugin)? If not, I'm 
not sure how to approach option b) above.



Feedback appreciated. I think that it is very important especially for 
new users that this is improved. The GitHub plugin is constantly 
causing headaches!


Cheers,
Oliver


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

Regards
David Godfrey
SB Tech Services
mb: +61 437 286 200 <tel:+61437286200>

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

2017-09-27 Thread David Godfrey


Hi Wayne,

I'll back you on this decision.
It's more than once cost both time and money, to say nothing of 
frustration to multiple users.


Personally, I've not been caught with sending a board to production in 
this state, but I certainly have run into the problem and caught it 
during routing (Obviously non connected pins that don't DRC)


If a layer is deleted, it's deleted, there simply shouldn't be any 
leftovers of any description.
A clear warning that this is happening and confirmation dialog is really 
all that is needed, especially if that dialog explicitly lists the 
layers that are being removed.



On 27/09/17 22:08, Wayne Stambaugh wrote:

This bug[1] has reared it's ugly head again so I am going to fix it once
and for all before the stable 5 release.  We cannot continue storing
objects on deleted layers in the board file which cause the DRC to pass
connection tests when in reality there are failures.  I don't really
have the time so you should assume that this is going push back the
release.  It probably should be backported to the stable release but
given the code deviations, I don't see that happening unless someone
else feels motivated to do so.  I looked at the existing code and it's
not going to be a trivial fix.  I do not intend to do anything fancy
such as give the user the option to merge objects from deleted layers to
other layers.  I'm going to keep it simple by just warning the user and
removing all objects from the removed layers.  This includes non-copper
layers as well.  I don't see how keeping objects on layers that don't
exist in the board is valid.  I'm not really asking for comments but if
you have any suggestions outside what I have presented I am willing to
entertain them.

[1]: https://bugs.launchpad.net/kicad/+bug/893950

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


Regards
David Godfrey
SB Tech Services
mb: +61 437 286 200 <tel:+61437286200>


___
Mailing list: https://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] Undo/Redo behavior across schematic

2017-04-19 Thread David Godfrey


  
  
Hi Wayne


On 19/04/17 03:34, Wayne Stambaugh
  wrote:


  Hey David,

On 4/18/2017 3:32 PM, David Godfrey wrote:

  It would also break re-usability. I I have
a schematic file that
represents an instrument amp, and use it as a sheet multiple times, I'd
then expect to modify the schematic once and have the change propagate
across all instances of that sheet. (eg: adding an additional filter cap)

  
  
I think that it is a pretty safe bet that this wont happen.  I would not
allow this change.  The usage you described is precisely why complex
hierarchies exist.
-- 


Yep, much as I'd expect from such a diligent and effective project
leader ;-)
I described the usage in the way I did to help clarify for those
that were thinking about different use-cases.


  
  Regards
  David Godfrey
  

  


___
Mailing list: https://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 2/2] Remove redundant statement in WRL2BASE::ReadNode

2017-04-13 Thread David Godfrey


  
  
I agree, 
  A patch to add explanatory comments would seem to be required
  here.
  Otherwise someone in the future is likely to make a similar change
  in a larger patch and it will likely be missed during review.

Regards
David G

On 13/04/17 21:34, Clemens Koller
  wrote:


  Hi!

These lines scream for some comments in the source...
I wouldn't get it, too.

Regards,

Clemens

On 2017-04-13 14:03, Wayne Stambaugh wrote:

  
Cirilo,

Thanks for the info.  The second call to ReadName() does look a bit odd
so I can understand Konrad's confusion.

Cheers,

Wayne

On 4/12/2017 6:12 PM, Cirilo Bernardo wrote:


  Do not accept this patch, it will break the parser. The statement
which was removed is not redundant.

- Cirilo

On Wed, Apr 12, 2017 at 8:01 PM, Konrad Beckmann
<konrad.beckm...@gmail.com> wrote:

  
---
 plugins/3d/vrml/v2/vrml2_base.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


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




-- 
  
  Regards
  David Godfrey
  
  

 mb:
  chat:   0437 286 200
  with dcg_mx at #sbts:matrix.org
  Chat is via matrix.org.
There are clients available for All Operating Systems and
Hardware devices.
Including Linux, Android, Windows, Mac, iOS
I'd recommend the multiplatform RIOT client as the best
starting point.
with RIOT web the easiest on any PC 

  

  


___
Mailing list: https://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] Bug 1677282 fix feedback.

2017-03-30 Thread David Godfrey

Hi,

I'd vote of #3 but with the addition of a "Don't show this dialog in the
future" option.
If the "don't show" has been set, then simply auto save (ie: #4)

Regards

David G


On 31/03/17 01:33, Wayne Stambaugh wrote:
> I have found and fixed the bug in this bug report:
>
> https://bugs.launchpad.net/kicad/+bug/1677282
>
> This bug creates invalid schematic files which sets the component unit
> flag to 0 and breaks the netlist generator.  The fix itself is simple.
> What is not simple is what to do about the invalid schematic files that
> have already been created.  I added code to schematic parser to fix this
> but this creates a dilemma.  Technically the schematic is modified which
> begs the question, what to do next.  None of the following choices are
> particularly appealing:
>
> 1) Do nothing and leave the file in an invalid status until the next
> time the user saves the schematic.  This is probably the most convenient
> but what about broken schematics being used by versions of kicad prior
> to this fix?
>
> 2) Set the schematic modified status which will trigger a save warning
> when eeschema is closed even if the user hasn't made any changes.  We
> already do this with SCH_SCREEN::SchematicCleanUp() that gets called
> lots of places outside of schematic editing.  The problem with this is
> that the user has no idea why they are getting a save warning when they
> didn't actually change anything.
>
> 3) Set the schematic modified status and inform the user that there was
> an error in their schematic file that was repaired on load and requires
> saving.  This is the most informative for the user but reeks of nagware.
>
> 4) Silently save the corrected schematic with no user interaction.  This
> will undoubtedly make VCS users unhappy.
>
> As much as I hate nagware, I like unexpected save warnings when I
> haven't changed anything even less so I'm leaning towards option 3.  Any
> feedback would be appreciated.
>
> Thanks,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>


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

Re: [Kicad-developers] Icon policy

2017-03-22 Thread David Godfrey


  
  
Hi,
I know I mainly lurk, however occasionally I feel the need to
  make a suggestion or two. :-/
As a very long time user of KiCad I understand Chris's reluctance
  to merge in every Icon set change.
Changing the "look" of icons can slow down productivity if you
  are using those icons regularly as you have to retrain the brain
  to recognize them.
Rather than simply replacing the icons, can we add an icon
  "theme" and associated dir tree with each contribution getting
  it's own dir in the tree.
  I say tree, as you can then have a main theme in say
      /icon/hi-contrast
  then specific overrides in
      /icon/hi-contrast/joe-blogs
The joe-blogs dir may contain only some, or all of the
  replacement icons.
  Any that are missing are pulled from the dir layers above
I'd love to be able to contribute such an enhancement, but have
  too much going on here for the next few months.

On 23/03/17 00:34, Wayne Stambaugh
  wrote:


  I'm open to suggestion on this.  Image files are not my forte.  My main
concerns are that we keep images reasonably consistent and try not make
life too difficult for the devs who have to merge the changes.

On 3/22/2017 11:30 AM, Chris Pavlina wrote:

  
"[PATCH] 3 better icons" made me think of this:

Every once in a while we get patches from people redesigning a bunch of
icons. I think we should probably have some clear policy on icons so we
can have some consistency - it makes a bit of a mess when someone
redesigns half the icons every once in a while.

Wayne? Any thoughts on this? We should probably try to coordinate icon
edits.

PS. Fabrizio, I'm not saying your patch shouldn't be merged, I haven't
actually had a chance to look at it yet. It just made me think of a
problem we've had for a while.


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




-- 
  
  Regards
  David G
  


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

2016-10-29 Thread David Godfrey

Hi Wayne and others,

I've been loosely following various iterations of the via
  stitching discussion for quite a while now.
  Mainly as its a feature I really want as well.
To me, the preferred approach is probably more like this

  stitching should be a property of a any polygon or power plane
(collectively referred to as a pour below)

  stitching should be defined as between 2 or more layers (multi
select checkbox/list)
  any connected copper on included layers should be
automatically stitched to the configured pour.
  there should be 3 possible states for each layer configured
for stitching in a pour.

  None - (no stitching from that layer)

  Always - Stitch unless the target copper is set to None

  Maybe - Stitch if the target copper is also set to Always

  only pours that have "stitch" or "stitchable" and a matching
layer should be stitched together (this allows pours to not be
stitched to a larger pour if required)
  a stitching pattern should be able to be specified, eg

  grid (selectable size)
  rings (from the center with radius increments, and degree
or mm spacing around each ring
  # vias
  pattern from a bitmap

  Obviously, stitching should only occur between copper with the
same assigned net.

I'd  think that stitching vias should be always ripped-up and
  re-poured along with the copper

These are just rough thoughts, there are likely corner cases that
haven't been considered.

What it does do however, is provide stitching as a hands off, but
still customizable option

Oh, and the same capability could be applied to layer/net
combinations too.

Regards
David G

On 29/10/16 12:58, Heikki Pulkkinen
  wrote:

  Hi Wayne,
  I think that there is two places when user is "wrong"
wit his/her will. One is when there are not at least two pours
to connect with and second is that there must be at least one
pad in connection chain. If antennas are user will, it is better
create component. I might be wrong, but that is how I think it.
I did some experimental development in my code which now keeps
vias netcodes Steven's ideas way, and take care of that there is
connected pad. These two videos show how that works. I try more
other things when I am back home again.
  Regards
  Heikki
  https://youtu.be/wXdVl4WXCJ8
https://youtu.be/5qe-XnVJwXs

27.10.2016 1.47 "Wayne Stambaugh" 
  kirjoitti:
  I'm just
not comfortable with the connection algorithm reassigning
via
net codes to a zone's net code based on the zone/via
intersection.  This
puts the responsibility of the connection on the project
rather than the
user.  I'm OK if we suggest a net when the user is placing
vias but the
user has the final say and the via net code does not change
unless the
user explicitly changes it.  I don't now how to make it any
clearer than
that.  Someone would have to make a really impressive
argument (read
doctoral thesis) as to why we should allow kicad to
determine
connectivity rather than the user.

On 10/25/2016 1:54 AM, Heikki Pulkkinen wrote:
> Thanks Wayne to look at this and Steven for asking
about connection logic.
>
> It is good to try explain what did you thought  last
summer. It clearer
> things.
>
> There are main rule which connects top and bottom layer
and second rule
> connecting inner layers. And now I think that main rule
is useless,
> because second rule do all this connecting via to first
two zones with
> same netcode. This works well as far as zones are up
the date. And that
> is not always true. For example in DRC, if you forgot
to refill zones
> before running DRC, vias can corrupted to wrong net.
Thats why running
> first refilling zones in DRC, keeps vias right
connected.
> I found two another, and there might be more, situation
when user can
> accidentally damage connection. Cleanup and saving a
board. Saving is
> not that broblem, but opening is. But I have solution
of them. Just
> running zone filling algorithm before running

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

2016-04-13 Thread David Godfrey

Hi Chris,

A rotation of the selection is not the same as a rotation of the
individual components.
Consider you already have the components roughly in a grid, and you need
to rotate them by 20 degrees.
Rotating the selection means you have to do major repositioning of every
component to get them back in the correct area.

However rotating the components within the selection means they are
still in about the right position, so only minor placement adjustments
are required.
These minor adjustments can likely be made using the align and
distribute tools

I Agree half-implemented features are bad, better to update them and
properly implement.

Regards
David G

On 13/04/16 08:53, Chris Pavlina wrote:
> GAL already has this. Block or multi select, Ctrl-M for "move exactly" (or use
> the context menu), and type an angle. Just rotates the whole selection, then
> you can place your rotated resistors.
>
> Considering legacy is on its way out, I'd rather not keep crusty old
> half-implemented legacy features around to require maintenance.
>
>
> On Wed, Apr 13, 2016 at 08:50:38AM +0800, David Godfrey wrote:
>> Hmm,
>>
>> I'v not used it on Kicad but the ability to change the orientation of an
>> arbitrary selection of footprints is something I've used many times in
>> Altium.
>>
>> Ideally you want to be able to set an absolute orientation, and also a
>> relative (to current) angle adjustment.
>>
>> This is especially useful when designing boards like LED matrices and
>> wanting to put all resisters on a specific angle (eg: 21.3deg).
>> You can then do an array alignment with the same outer limit you used
>> for your LED alignment.
>> Then move the group of resistors into position relative to the LED's.
>>
>> Now running your tracks becomes trivial.
>>
>> Without the ability to auto adjust the orientation on a selection of
>> parts the job becomes long and tedious.
>> Some of the PCB's I've done this on have over 1000 LED's and resistors,
>> and generally you need to orient both the resistors and the LED's
>>
>> So in summary, I'd like to keep the ability to do this, but on a
>> selection instead of globally.
>> And being able to alter it as an absolute angle, or as a relative to
>> current (prefix the new angle with + or - to get relative movement)
>> would be beneficial.
>>
>> Regards
>> David G
>>
>> On 13/04/16 06:40, Chris Pavlina wrote:
>>> I wonder how many of you are even aware of DIALOG_ORIENT_FOOTPRINTS. It's
>>> hidden in the Secret Menu in pcbnew (the spread-and-place) one, menu item
>>> Orient All Footprints. The code hasn't been touched since 2010 except a few
>>> cleanups, and it seems really simplistic and useless to me. I was going to
>>> upgrade it to floating-point angle entry like everything else, but
>>>
>>> Does _anybody_ even use this? It seems utterly useless. I have no idea when
>>> you'd want to globally apply an orientation to footprints. Can I just tear 
>>> it
>>> out?  :P
>>>
>>
>>
>> ___
>> Mailing list: https://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] DIALOG_ORIENT_FOOTPRINTS

2016-04-12 Thread David Godfrey

Hmm,

I'v not used it on Kicad but the ability to change the orientation of an
arbitrary selection of footprints is something I've used many times in
Altium.

Ideally you want to be able to set an absolute orientation, and also a
relative (to current) angle adjustment.

This is especially useful when designing boards like LED matrices and
wanting to put all resisters on a specific angle (eg: 21.3deg).
You can then do an array alignment with the same outer limit you used
for your LED alignment.
Then move the group of resistors into position relative to the LED's.

Now running your tracks becomes trivial.

Without the ability to auto adjust the orientation on a selection of
parts the job becomes long and tedious.
Some of the PCB's I've done this on have over 1000 LED's and resistors,
and generally you need to orient both the resistors and the LED's

So in summary, I'd like to keep the ability to do this, but on a
selection instead of globally.
And being able to alter it as an absolute angle, or as a relative to
current (prefix the new angle with + or - to get relative movement)
would be beneficial.

Regards
David G

On 13/04/16 06:40, Chris Pavlina wrote:
> I wonder how many of you are even aware of DIALOG_ORIENT_FOOTPRINTS. It's
> hidden in the Secret Menu in pcbnew (the spread-and-place) one, menu item
> Orient All Footprints. The code hasn't been touched since 2010 except a few
> cleanups, and it seems really simplistic and useless to me. I was going to
> upgrade it to floating-point angle entry like everything else, but
>
> Does _anybody_ even use this? It seems utterly useless. I have no idea when
> you'd want to globally apply an orientation to footprints. Can I just tear it
> out?  :P
>

___
Mailing list: https://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] 3D file relative paths

2016-04-12 Thread David Godfrey

Hi Wayne and Cirilo,

I have to agree with Wayne here.
The use of Env Vars is the only sensible and portable method that can be
used.
If using relative paths that are relative to the project dir, and I want
to put a collection of footprints (etc) in some other dir, perhaps on a
server share, the relative path model then fails.
However there is no reason why I can't have appropriate Env Vars set in
the Configure Paths dialog to facilitate that, or even more complex
arrangements.

I think both use and editing of File location should handle env vars
sensibly.
If editing, I would expect to be able to enter any env var, and get a
warning (but only a warning) on saving the change if the env var is not set.
Display of the File Location should show the uninterpreted env var. ie
${ProjDir}/demo.pcb

Regards
David G

On 13/04/16 07:02, Wayne Stambaugh wrote:
> It's not necessary to define environment variable at the system wide or
> user level.  You can define them at the application level using the
> "Configure Paths" dialog.  This way you can set any environment variable
> you want and it will be available in the currently running process.
> Configured properly, it should allow you to make your projects portable
> across systems and platforms assuming you can access all of your
> libraries on a given system.  This is how I do it.
>
> On 4/12/2016 5:32 PM, Cirilo Bernardo wrote:
>> Hi Wayne,
>>
>>  The new resolver will expand variable names; any path specified in a
>> kicad pcb file or footprint file will be interpreted in exactly the same
>> way as with the older system. The only difference with the new system is
>> that there is no need for environment variables (but they will be
>> interpreted if present). The idea was that users could use the GUI to
>> specify the search paths and give those paths names (aliases) which are
>> analogous to the environment variables, except that they aren't
>> environment variables. I think this is a Good Thing because fiddling
>> with environment variables on MSWin and OSX is a nuisance. I imagine
>> some Linux users might find env vars a nuisance as well, especially if
>> they launch kicad from a desktop UI.
>>
>>  I'll check out the issue with the software rejecting ${ENV_VAR} in the
>> file name editor.
>>
>>  If we agree that a "../" style of relative path can only be interpreted
>> as relative to the current project directory then I think that style of
>> relative path may in fact be better in many ways than an absolute path
>> (until a user moves the project directory).  Some users prefer that
>> style of relative path for their particular workflow so I can implement
>> that if there are no objections.
>>
>>  The other differences between the new resolver and the old system:
>> a. a partial path like "path/to/my/file.wrl" will be interpreted as a
>> path within the current working directory (new behavior) and if it
>> doesn't exist there then it will be interpreted as a path within the
>> ${KISYS3DMOD} directory (old behavior).
>> b. due to the new behavior in (a), there is no need for "${KIPRJMOD}" -
>> a partial path will always be checked against the current project directory.
>>
>> So a summary of the new resolver:
>> a. env vars are not needed, but still supported (except for the issue
>> mentioned in the filename editor)
>> b. multiple model root paths are supported via aliases rather than env
>> var; an aliased name appears to the user as
>> "alias_name:my/partial/path/to/mymodel.wrl"; within the PCB file the
>> alias itself appears as ":alias_name:my/partial/path/to/mymodel.wrl".
>>
>> - Cirilo
>>
>> On Tue, Apr 12, 2016 at 10:54 PM, Wayne Stambaugh > > wrote:
>>
>> Hey Cirilo,
>>
>> Does the new 3D file path resolve no longer support environment variable
>> expansion?  If it doesn't, it should.  We've have had so many issues
>> with relative paths in the past that I'm reluctant to allow them.
>> That's the primary reason we support environment variable expansion in
>> the fp-lib-table and the old 3D file path code because it's infinitely
>> more portable than relative and absolute paths.  I know this is not the
>> easiest issue to resolve but the best solution I've seen is how
>> fp-lib-table handles them.  If someone has any better ideas, I'm open to
>> suggestion.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 4/12/2016 2:18 AM, Cirilo Bernardo wrote:
>> > Hi folks,
>> >
>> >  The current behavior of the 3D filename resolver is to use
>> > an absolute path in instances where a specified path is
>> > not a descendant of a path within the aliased paths list
>> > (that is, the filename cannot be shortened using an existing
>> > alias). This decision was originally made to avoid ambiguous
>> > relative paths such as "../../some/path" (what is it
>> > relative to?).  The obvious down side of course is that
>> > absolute paths are not

Re: [Kicad-developers] New pcbnew features and versioning

2016-04-11 Thread David Godfrey

Hi Wayne,

Nice concise response and good direction, exactly what is needed from a
Project Leader.

Regards
David G

On 12/04/16 07:32, Wayne Stambaugh wrote:
> I'm going to put on my project leader hat and try to respond to all of
> the issues discussed thus far rather than reply to each concern
> individually.  I'll start off by saying that many of you are going to
> disagree with me but I'm OK with that.  At the end of the day, I'm
> responsible for the code that ends up in KiCad so my opinion counts just
> a little so here it goes.
>
> As for providing the ability to save older file versions, I have very
> little interest in asking any of our developers to provide this given
> the project's limited manpower.  Comparing KiCad to LibreOffice shows a
> lack of understanding in just how few developers contribute to KiCad.
> There are many paid full time developers working on LO, and hundreds of
> volunteers.  KiCad has two very part time paid developers, a couple of
> regular contributors, and a handful of occasional contributors.  This
> does not mean that I do not care about our users.  On the contrary, I
> prefer to use our limited manpower resources to get the most bang for
> our buck.  I believe we have much bigger issues to resolve than being
> able to save to old file formats.
>
> Any changes to the file format, parser, and output formatter will be
> heavily scrutinized to ensure they meet the following criteria: the file
> format must be human readable without being overly verbose and the file
> parser and output formatter code must well designed, easy to understand,
> and easy to extend.  Everything I have seen discussed thus far runs
> counter to these design goals.  I am not saying that I will not allow
> any changes but these design goals are in play.  This means you should
> assume that the bar is going to be very high for any changes to this
> code and/or the file format.
>
> That being said, we should attempt to provide some type of file version
> information to help the user figure out what to do when they have file
> version issues so I propose we do the follow:
>
> * Use Chris' time stamp version number patch.
>
> * Allow the file to be parsed as is.
>
> * If the file fails to parse and the file header information is valid
> use the version number to determine if the file is corrupt (<= build
> file version) or the file may have failed because it contains features
> not available ( > build file version).
>
> * If the header was not successfully read, warn the user that the file
> does not appear to be a kicad board file.  If the file does parse
> successfully and the file version is > than the current build version,
> warn the user that the file was created with a newer version of KiCad
> which may result in data corruption and/or loss and see if they want to
> continue.
>
> * If the file version is <= the build file version than all is well.
> This should cover most of the file parsing cases and give the user some
> useful information on what steps they may or may not want to take to
> resolve their file version issues.
>
> This may not satisfy everyone's goal but it's far better than what we
> are doing currently without making a mess of our file format, parser,
> and output formatter.
>
> Cheers,
>
> Wayne
>
>
> On 4/11/2016 12:00 AM, David Godfrey wrote:
>> Hi All,
>>
>> On 11/04/16 07:37, Wayne Stambaugh wrote:
>>> Let's slow down and think about this a bit.  I'm not sure that this is
>>> the best way to resolve this.  Let me chew on it a bit and I will get
>>> back to you.  I've been busy today so hopefully by tomorrow I'll have an
>>> answer.
>> Wayne,
>> Off the cuff I'd propose a single "used features" block in the file format.
>> This would purely be a list of features that are used by this file. then
>> it's easy for the loading software to confirm what it supports
>> eg: roundrect-1, angletext-33
>> the appended number can be used to differentiate between non backwards
>> compatible versions of a feature
>>
>> This would be fairly easy to implement, and trivial to test at file load
>> The hardest part would be spending the time to go through and define the
>> struct to the project that records every feature we care about.
>> Although that could be done by only adding features to that struct when
>> a change is made from now on.
>>
>> Regards
>> David G
>>> Thanks,
>>>
>>> Wayne
>>>
>>> On 4/10/2016 12:36 PM, jp charras wrote:
>>>> Le 10/04/2016 16:11, Chris Pavlina a écrit :
>>>>> I like the idea. It'll take some work to implement properly, though.

Re: [Kicad-developers] New pcbnew features and versioning

2016-04-10 Thread David Godfrey

Hi All,

On 11/04/16 07:37, Wayne Stambaugh wrote:
> Let's slow down and think about this a bit.  I'm not sure that this is
> the best way to resolve this.  Let me chew on it a bit and I will get
> back to you.  I've been busy today so hopefully by tomorrow I'll have an
> answer.
Wayne,
Off the cuff I'd propose a single "used features" block in the file format.
This would purely be a list of features that are used by this file. then
it's easy for the loading software to confirm what it supports
eg: roundrect-1, angletext-33
the appended number can be used to differentiate between non backwards
compatible versions of a feature

This would be fairly easy to implement, and trivial to test at file load
The hardest part would be spending the time to go through and define the
struct to the project that records every feature we care about.
Although that could be done by only adding features to that struct when
a change is made from now on.

Regards
David G
> Thanks,
>
> Wayne
>
> On 4/10/2016 12:36 PM, jp charras wrote:
>> Le 10/04/2016 16:11, Chris Pavlina a écrit :
>>> I like the idea. It'll take some work to implement properly, though. I can
>>> start working on it, but it will likely be at least a week before I have
>>> anything.
>> Thanks you to make me very happy ...
>>
>>> On Sun, Apr 10, 2016 at 04:05:42PM +0200, jp charras wrote:
 Le 10/04/2016 15:31, Chris Pavlina a écrit :
> So - would you be happy with me just changing that to a warning that can 
> be
> clicked through instead of an error, and rewriting the message a bit to 
> agree?
>
 I'll be more happy.

 But I'll be really very happy if a dynamic version numbering is also 
 added, rather a fixed arbitrary
 number.

 Currently the version is 4.
 If a method is added (something like GetMinimalVersionNumber()) to all 
 board items (tracks, texts
 footprints, pads...), each item can return the needed minimal version to 
 be read in file.
 Currently they could return 4, but for a pad, if its type is rounded rect 
 it will return 20160410,
 and therefore its footprint parent returns 20160410 (or 4 if no rounded 
 rect pad is found)

 Before writing the file, just run BOARD::GetMinimalVersionNumber() to know 
 the actual needed version.

 -- 
 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] Slow performance in pcbnew (PNS/GAL only) on high-fanout nets

2016-02-02 Thread David Godfrey



On 03/02/16 01:19, Jean-Paul Louis wrote:
> Checking for overlapping courtyard areas should be the first task of DRC,
> as there is no point checking for any other type of error if parts overlap
> (non manufacturable).
> But that feature will also need a switch to turn it off on very specific
> instances.
I agree here, there are cases where overlapping components may make a
lot of sense.
Consider a mechanical object like a heatsink or mounting bracket that
"needs" to be a footprint on the pcb as it is part of an electrical
connection.
The component that the heatsink cools could well overlap the heatsink.

Another case would be perhaps placing a thermistor inside a toroid
mounted on the pcb.
I am sure that there are a large number of similar uses for overlapping
courtyards.

Another thing to consider would be handling  the case where you want
overlapping footprints to allow 2 different versions of a component to
be fitted.
To use a very simple example the use of 3 holes for both 0.1" and 0.2"
radial capacitors. You would only ever fit one, but due to supply issues
you may need to be able to fit either.

Another good example would be narrow and wide IC packages that have the
same pitch, common in both DIP and SOIC packages

Of course you could create special footprints for these cases, but if
it's just one component on your board, and you only need to do it
occasionally it's simpler to just overlap the footprints.
Regards
David G
> Just my $0.02,
> Jean-Paul
> N1JPL
>
>
>> On Feb 2, 2016, at 5:05 AM, jp charras  wrote:
>>
>> Le 02/02/2016 10:31, Tomasz Wlostowski a écrit :
>>> On 02.02.2016 10:29, Maciej Sumiński wrote:
 Pads on the same net overlapping are *not* a DRC error.
> (Only overlapping holes could be a DRC error, although I am not
> sure)
>>> Hi Jean-Pierre,
>>>
>>> I would refine that:
>>> - overlapping pads within the same component are not an error
>>> - overlapping pads between different components is an error
>>>
>>> Cheers,
>>> Tom
>>>
>> Yes I agree.
>>
>> However, testing overlapping pads could be made only after
>> moving/placing a footprint (or changing a clearance value).
>> Checking the courtyard layers (feature to do ...) could be a good
>> complement.
>>
>> -- 
>> 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] Linux dependencies for building from source

2016-01-04 Thread David Godfrey


  
  

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tom, Maciej

On 04/01/16 17:47, Maciej Sumiński wrote:
> Hi Tom,
  >
  > Thank you for noticing, a pull request to correct this has
  already been
  > sent.
  >
  > BTW: I have just noticed we keep two documents describing the
  compiling
  > process - on the website and in the source repository
  > (Documentation/development/compiling.md). How about getting
  rid of the
  > latter one?
Could I argue against removing the doc in the source.
If I need to work out how to compile something, I always use local
docs from the repository at (in theory) they should be correct for
that exact version of source.

On the other hand, a version of the doc kept on a website is very
likely not correct for that version of source.
It can only present a single method that is correct for a given
version. (unless you want to complicate it with lots of [do this for
ver:X but not ver:Y] statements.
As (using git) I could decide to install branch "master" or go back
in time and install branch "0.6" it is likely that the web
instructions will be wrong for one or both methods, while the docs
in the source tree should be correct or close to correct at least.

Regards
David G
>
  > Regards,
  > Orson
  >
  > On 12/30/2015 07:42 PM, Tom Andrews wrote:
  >> Hi,
  >>
  >> Just a quick one for the website, under the Linux build
  from source page,
  >> the dependencies are missing packages: libglm-dev and
  libcurl4-openssl-dev
  >>
  >> Thanks,
  >>
  >> Tom
  >
  >
  >
  >
  > ___
  > Mailing list: https://launchpad.net/~kicad-developers
  > Post to : kicad-developers@lists.launchpad.net
  > Unsubscribe : https://launchpad.net/~kicad-developers
  > More help   : https://help.launchpad.net/ListHelp

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWikYUAAoJEKtnf+w62ZJXsm8H/0C12D6GCQWhQpR5kSRV0Dai
bzCoNJ3IgCCycQ1qIFo6B9GiEtHDwGI4xb97ZPxKxXkugSvp24dRxL6DnotuR2ny
1ukyc3cRthixRCDL5Nw0unwwEn0cRUzUZWW7mWyi0FNDodF3MU3U8j+xeZRG4s9b
5I5YmmG1TdKhBHstD3nVAMrEbkPeS7kVVZvu+QHYmXE492ZdpaZhV9t7ZHcOKIfY
oguyEX9mgO+EucSBDnZGH4A52HBn3Rg8JB5zAloQUS46IqdXJCDFkSLOiNNcvnDw
jO1/YPGvS4H8hLvYxTTLNlwnLfeMpliHsuzLXUcfwwE1fB7fJLg+O79HR5GvaRM=
=+HKt
-END PGP 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

[Kicad-developers] Interesting Discussion Re: [RFC] Wildcard and/or regex support in the component chooser

2015-12-20 Thread David Godfrey


  
  
Hi Erik,

Some interesting discussion on different search options happening on
Kicad mailing list.
It raises these questions, 

  are we using postgres LIKE, SIMILAR TO, or ~ (posix regex)
when allowing a user to enter search information?
  Do we allow the user a choice of search types (regex vs sql
patterns vs other) on a global or per user basis?
  
  Do we inform the user (on each search screen) what can be used
to create patterns?
ie: % matches any number of chars, _ matches a single char,
there is an implied % before and after the pattern

Regards
  David G
On 19/12/15 04:56, Wayne Stambaugh
  wrote:


  On 12/18/2015 2:22 PM, Chris Pavlina wrote:

  
Thanks, and I don't mean to sound grouchy about it. I don't want to try 
to be a backseat driver and start insisting we do things My Way, or 
anything like that. It's just that my proposed change is really quick 
and simple, and would scratch a massive itch of mine - I'd definitely 
not object to adding even more stuff, but I've been really limited on 
time lately... fuzzy matching sounds kinda interesting, and it'd be cool 
to see it added. It just wouldn't do anything for the reason I wanted to 
add wildcard matching, and as much as I wish I had time to spend coding 
cool things that _don't_ help me... I don't have any. :(

  
  You're allowed sound grouchy!  You're the one who's implementing it so
you get the lion's share of the say.  That's not to say other devs input
isn't useful but at the end of the day, you're one writing the code.
Here is my 2 cents.  From an advanced users point of view, wildcard and
regex searching is great so I'm all for it.  However, how many users
really know how to use regex or even simple wildcard searches?
Experience has taught me that very few actually do.  In fact, the only
users I know that know how to use them are developers.  We (myself
included) should always keep that in mind when writing code.  One simple
option might to create and abstract pattern matching base class
(EDA_PATTERN_MATCH) and only implement a wildcard and/or regex
implementation.  That way in the future, if someone feels really
ambitious, they can create any number of fancy pattern matching
algorithms without having to rewrite the code that utilizes it.



Can I suggest using the time honoured method of a set of
  radio buttons (or dropdown list) allowing selection of what type
  search you want to perform.
  mcedit (midnight commander editor) has a good example of this in
  it's text user interface
  
  
  
  I think in the long run we may want to support
  

  Normal
      unless enclosed in /'s or ~'s it is a
  simple substring search with implied wild cards at start and
  end of the pattern

  Wildcard
  Regex
  Fuzzy / Smart search

There should be a help popup associated with a small ?
button alongside each option.
  
I also think we should change our existing default search
type to include the implied wildcards at start and end of the
pattern.
This would go a long way to helping non technical (from a
programming perspective) users find the parts they want.
We could also assume that (if the selected type is "normal")
  

  if the pattern is enclosed in a pair of /'s it is a
  regex
  if the pattern is enclosed in a pair of ~'s it is a
  fuzzy search (once implemented)

  if it is not a regex or fuzzy search and contains a
  wildcard [*?] then it is a simple wildcard match

Use of / or ~ to identify a regex or fuzzy pattern should
not be required, as the user could have overridden this by
making a manual selection of the type.
  
By requiring that a regex or fuzzy pattern be enclosed in
/ or ~ chars for auto type selection (if entered in the search
box) it allows any pattern type to contain these characters even
as the first character of the pattern by simply selecting the
pattern type from the radio or dropdown list.
  
This is not all of the solution, but should allow extra
capabilities to be added during the life of the software
supporting both normal users and users with more knowledge.
Also it helps to educate users that there are other ways of
searching that may be more useful.
  
The tilde (~) is often used to indicate approximation (in
the world outside programming) hence the suggestion it is used
to denote a fuzzy search.
This does conflict with a common programming use of the tilde to
indicate a regex, but as regexes are often (think grep and awk)
wrapped in /'s it is a good compromise.
  

  
So, if Wayne  don't

Re: [Kicad-developers] [RFC] Wildcard and/or regex support in the component chooser

2015-12-20 Thread David Godfrey

Hi Chris,

In fact, no, I didn't realise that all of that had been argued over, nor
that the patch was finished.
The thread I posted on didn't mention anything about some of those
points, nor that it was already done!

Also I don't think my comments were resurrecting an old thread
considering that your previous post was only about 32 hours earlier than
mine.

Regards
David G

On 20/12/15 13:56, Chris Pavlina wrote:
> You do realize we've already argued over pretty much all the points you 
> made, and _finished_ the patch already?
>
> On Sun, Dec 20, 2015 at 01:17:07PM +0800, David Godfrey wrote:
>>Wow, 2 posts from me in the same day!
>>That is unprecedented ;-)
>>
>>Comments inline.
>>
>>On 19/12/15 04:56, Wayne Stambaugh wrote:
>>
>>  On 12/18/2015 2:22 PM, Chris Pavlina wrote:
>>
>>  Thanks, and I don't mean to sound grouchy about it. I don't want to try
>>  to be a backseat driver and start insisting we do things My Way, or
>>  anything like that. It's just that my proposed change is really quick
>>  and simple, and would scratch a massive itch of mine - I'd definitely
>>  not object to adding even more stuff, but I've been really limited on
>>  time lately... fuzzy matching sounds kinda interesting, and it'd be cool
>>  to see it added. It just wouldn't do anything for the reason I wanted to
>>  add wildcard matching, and as much as I wish I had time to spend coding
>>  cool things that _don't_ help me... I don't have any. :(
>>
>>  You're allowed sound grouchy!  You're the one who's implementing it so
>>  you get the lion's share of the say.  That's not to say other devs input
>>  isn't useful but at the end of the day, you're one writing the code.
>>  Here is my 2 cents.  From an advanced users point of view, wildcard and
>>  regex searching is great so I'm all for it.  However, how many users
>>  really know how to use regex or even simple wildcard searches?
>>  Experience has taught me that very few actually do.  In fact, the only
>>  users I know that know how to use them are developers.  We (myself
>>  included) should always keep that in mind when writing code.  One simple
>>  option might to create and abstract pattern matching base class
>>  (EDA_PATTERN_MATCH) and only implement a wildcard and/or regex
>>  implementation.  That way in the future, if someone feels really
>>  ambitious, they can create any number of fancy pattern matching
>>  algorithms without having to rewrite the code that utilizes it.
>>
>>
>>Can I suggest using the time honoured method of a set of radio buttons (or
>>dropdown list) allowing selection of what type search you want to perform.
>>mcedit (midnight commander editor) has a good example of this in it's text
>>user interface
>>
>>I think in the long run we may want to support
>>
>>  • Normal
>>unless enclosed in /'s or ~'s it is a simple substring search with
>>implied wild cards at start and end of the pattern
>>  • Wildcard
>>  • Regex
>>  • Fuzzy / Smart search
>>
>>There should be a help popup associated with a small ? button alongside
>>each option.
>>
>>I also think we should change our existing default search type to include
>>the implied wildcards at start and end of the pattern.
>>This would go a long way to helping non technical (from a programming
>>perspective) users find the parts they want.
>>We could also assume that (if the selected type is "normal")
>>
>>  • if the pattern is enclosed in a pair of /'s it is a regex
>>  • if the pattern is enclosed in a pair of ~'s it is a fuzzy search (once
>>implemented)
>>  • if it is not a regex or fuzzy search and contains a wildcard [*?] then
>>it is a simple wildcard match
>>
>>Use of / or ~ to identify a regex or fuzzy pattern should not be required,
>>as the user could have overridden this by making a manual selection of the
>>type.
>>
>>By requiring that a regex or fuzzy pattern be enclosed in / or ~ chars for
>>auto type selection (if entered in the search box) it allows any pattern
>>type to contain these characters even as the first character of the
>>pattern by simply selecting the pattern type from the radio or dropdown
>>list.
>>
>>This is not all of the solution, but should allow extra capabilities to be
>>added during the life of the software supporting both normal users and
>>users with more knowledge.
>>Also it helps to educate us

Re: [Kicad-developers] Interesting Discussion Re: [RFC] Wildcard and/or regex support in the component chooser

2015-12-20 Thread David Godfrey


  
  
Hi All, 

Sorry for the accidental post to the list, forgot to delete the list
address before forwarding to a dev on another project

On 20/12/15 16:11, David Godfrey wrote:


  
  Hi Erik,
  
  Some interesting discussion on different search options happening
  on Kicad mailing list.
  It raises these questions, 
  
are we using postgres LIKE, SIMILAR TO, or ~ (posix regex)
  when allowing a user to enter search information?
Do we allow the user a choice of search types (regex vs sql
  patterns vs other) on a global or per user basis?

Do we inform the user (on each search screen) what can be
  used to create patterns?
  ie: % matches any number of chars, _ matches a single char,
  there is an implied % before and after the pattern
  
  Regards
David G
  


  


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

Re: [Kicad-developers] [RFC] Reorganize eeschema options a bit

2015-12-20 Thread David Godfrey


  
  
Hi Chris,

I agree with keeping tab names short, but if the widget set allows I
normally set a tooltip for the tab that shows the longer form of the
name (where appropriate)

Regards
David G

On 20/12/15 01:06, Chris Pavlina wrote:


  
On Dec 19, 2015 12:04 PM, "Attila Kinali" 
wrote:
>
> On Sat, 19 Dec 2015 10:07:28 -0500
> Chris Pavlina 
wrote:
>
> > Nah, I'd love to, but I can't afford travel right now
:(
>
> Doh!
>
> > I like your organization - if Wayne's okay with this,
I'll probably go
> > with that, then. I have one comment: in the current
setup, the major
> > categories are tabs, so I'd probably shorten the names
a bit - with
> > things like "Keyboard and Mouse", the tab set is going
to get too long,
> > too fast. I'd probably rename "Keyboard and Mouse"
-> "Controls", and
> > "Text and Line" -> "Graphics" or "Display". I
actually think your names
> > are "better" purely by themselves, but I do have to
make sure the tabs
> > fit too :)
>
> Hmm.. Wouldn't this result in tabs with just 3-4 settings?
  Nothing is reorganized, I just renamed your heading
:P
  >
>                         Attila Kinali
>
> --
> It is upon moral qualities that a society is ultimately
founded. All
> the prosperity and technological sophistication in the
world is of no
> use without that foundation.
>                  -- Miss Matheson, The Diamond Age, Neil
Stephenson
  
  
  
  
  ___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



  


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

Re: [Kicad-developers] [rfc] actual sexpression parsing

2015-12-19 Thread David Godfrey


  
  
Hi,

I don't often post here, but I will add my ~30 years of experience
with binary file formats.
THEY ARE EVIL EVIL THINGS !!

  They tend to be extremely fragile, any change and something is
likely to break.
  They require parsers that suck to maintain
  In most cases general purpose parsers *CAN NOT* be used,
requiring a custom parser.
  
  it is *VERY* difficult to keep compatibility with an older
version of the format.
Essentially you need to keep multiple copies of the parser and
have some form of VersionID that can be used to select between
parsers.
  To all intents it is *IMPOSSIBLE* to handle forward
compatibility.
ie: open a file with version 1.1 that was written with version
1.1a
  A permanent and accurate copy of documentation is required to
be maintained for *EVERY* version of the parser ever written
  Parser VersionID magic must uniquely identify the parser
version and be the first entry in the file.
NOTE: other locations are possible, but cause significant
problems with extracting the version
  The more involved the protocol the worse all of these issues
get.
  Documentation is hard to write, and even harder to read and
understand sufficiently to code against.
  
  Debugging read/write issues is an absolute nightmare.
You either have to provide a reference to test against by either

  hand encode or decode a file
  have an independent programmer write a "clean room"
implementation of the parser
This requires the previously mentioned documentation to be
correct for this version
It can introduce additional bugs (you now have 2 parsers to
debug)

  
  Many potential developers of addons or core code may

  be scared off by the complexity
  accidentally introduce bugs or incompatibilities that
don't show up until a user looses data

  
  Inadvertently force full or partial Vendor Lock In. 
If a protocol (file format) is 

  too hard to implement
  too hard to keep up with changes
  too prone to breakage (fragile)
  too obscure (poorly documented or the documentation is not
easily available)
  

Then other vendors won't put in the effort to support the
protocol (file format)
  

I could go on with a lot more points but you get the picture.

Binary file formats made a lot of sense back in the days of 

  low speed serial communications
  very small storage devices
  expensive data links (anyone remember gprs @ 10c per kilo
byte?)

  Expensive GPRS lead to WAP which was (roughly) a tokenised
binary HTML/XML
It was not widely used due to some of the above problems,
and it also scared off content developers
  

  
  memory constrained systems like

  Old PC's (486 and earlier)
  old microcontrollers were short on memory and clock speed
  some modern microcontrollers can be affected here, but
only the lower end ones

  
  slow radio links (bluetooth and wifi are not slow)

They do make sense when used internally to a compression
  algorithm or an encryption scheme. 
  They don't make sense in (almost) all other cases today.
  (No flames here please, I am not trolling, just making a
  very generalized statement)


For a format like .png binary is not so bad, the format is unlikely
to change much if ever (even so there are at least 6 different png
formats out there, some of them ascii and some binary), but it is a
simple format to describe and implement. Any program that works with
png's needs to implement support for all versions of png, or clearly
explain to the user what is and is not supported with appropriate
error messages. Any png programs that don't support all versions
tend to fall into disuse and die a slow death.

Text based formats on the other hand, if well designed, are (to a
fair extent)

  human readable
  self documenting (although good documentation is *ALWAYS*
recommended
  general purpose parsers can be used allowing our code to focus
on using the information, not extracting it
  
  tolerant of extra nodes (features)
  tolerant of missing nodes
  often a newer version of a parser can parse older versions of
a file without problem.
It is trivial for a newer version to cater for specific version
based variations in a protocol.
  If the protocol is well designed new versions will only add
nodes to the

Re: [Kicad-developers] Full integration to Github

2015-12-08 Thread David Godfrey

Hi Guys,

Just to throw in my 2 cents.

It may be worth contacting github support to see if they would be
willing to assist importing issues.
It is possible that they would temporarily disable rate limiting, and
block notification email for a one-off import.

If they will, I would suggest a modified import script during testing
that mangles email addresses so it doesn't trigger the mailer.
Also, it needs to be slow enough to not trigger rate limiting.

Once we are happy that the import is as we want it, get github to
disable rate limiting and notification on the real project.
Run the import, verify it, get rate limiting and notification re-enabled.

Lots of open source projects migrate to github with all of there
history, so it has to be possible in a sane fashion.

Regards
David G

On 07/12/15 22:37, Mark Roszko wrote:
> So I did just a import of "open" issues from launchpad.
> https://github.com/marekr/kicad-issue-test/issues?page=7=is%3Aissue+is%3Aopen
>
> 1. Github's API rate limiting is extreme, they trip on "abuse
> detection" really really often so it took ~24 hours just to get 700
> issues and only partial comments
> 2. I stopped it because I had people complaining github was spamming
> them with notifications. This is because the @ mentions from launchpad
> were being copied. You would think they would be smart enough to
> disable notifications for API posted issues or make it an option to
> silence it.
>
>
>
>
>
> So what can I say:
> 1. Importing the entire set (open and closed) of issues would take a
> very long time with the rate limiting. I would say all the closed
> issues on LP are honestly useless and don't need to be moved as they
> can stay archived there forever, god forbid anyone every needs to look
> at one.
> 2. "Syncing" GH to LP open bugs would require a script/bot to keep
> checking and posting comments between the two.
>
>
>
>
>
> Personally what I would suggest:
> 1. We don't have to use github issues, it is an option to disable them.
> 2. There's always the option to self host our own bug tracker
> separately from source control, with JIRA no longer melting the kicad
> website server, perhaps something as simple as Trac could run on it?
> Then you get a bug tracker that's arguably more user friendly than
> launchpad and more fleshed out than github (they even calls their
> lightweight so).
> a. we can shove in a github login plugin :D
> b. there's a plugin to sync launchpad to trac.
>
>
>
>
> Otherwise, we can just import like I did and call it a day.
>
> ___
> Mailing list: https://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] suggested resolution (and other specs)

2015-10-14 Thread David Godfrey


While we are talking about graphics

Has any testing been done within Virtual Machines?
I believe we should support win/lin/mac hosts running VirtualBox, 
VMware, Parallels and at least linux as a guest.

Also Xen should be supported.

In my specific case, I am moving (all be it slowly) to have each major 
"role" running in a VM on xen.
There are a number of reasons for this, including the "appliance" 
benefits such as install once, use on multiple machines, and rapid 
disaster recovery in the event of hardware failure.
It also allows targeted selection of OS/distro based on what works best 
for a given use.
Even Better is the ability to have an appliance on a usb stick that can 
be handed to a client with completed designs that they can boot without 
any knowledge (as long as a VM solution is available).
On a couple of occasions I have even provided remote access to a VM so a 
client can have a look at a design.
Obviously for security reasons, you wouldn't just allow a client access 
to your normal system. :)


The last fulltime role I was in  required my constant use of Altium 
(designer 10 from memory) and while running it in a Virtual Box VM had 
some minor drawbacks, it had more benefits than drawbacks. Including 
every time it crashed, I only had to reboot that VM and nothing else was 
effected.


I believe that most Virtualisation platforms allow OpenGL passthrough in 
some form so it may be trivial to do some tests and tweak our codebase 
to deal with any quirks.



BTW: I'm moving back to a Kicad only site as I nolonger have any clients 
requiring Altium, the are all happy to use Kicad now.



Regards
David G

On 14/10/15 15:18, Lorenzo Marcantonio wrote:

On Wed, Oct 14, 2015 at 08:53:32AM +0200, Marco Ciampa wrote:

Have you done some tests? May we use KiCad with a 1024x768 screen?
All functions? And 800x600, less? More?

Reporting! :P

No hope for 800x600, it's just not designed for that. Maybe in
emergency...

1024x768 pretty much usable, especially if you tweak the code (removing
spacers between buttons, mostly). You lose a couple icons but nothing
vital (accessible thru menu and/or keyboard)

1600x1200 on a 21 inches is glorious :D suitable for full time work.


Suggested (actual) graphic cards for Win/Linux/Mac?
Minum requirements on DirectX / OpenGL?

Keep in mind that the target is OpenGL 2, you *need* hardware shaders to
work with pcbnew in opengl mode. I *think* it's more or less shader
model 9, but I'm not sure... anyway check the opengl specs of the card
(PS Intel lies)

No experience with NVidia.

Radeon works fine even with the APUs (GPU in the main processor). It's
something like an A2 or A3, from memory...

No hope with Intel pre-HD. The GM945 simply doesn't have the hardware,
for example. For reference Intel HD 4400 works fine (until it overheats,
but that's a design issue of this laptop, probably).

For the wx/GDI/GDK part I'd say everything with at least an AGP will
work:P *except* maybe the radeon with the free driver (notorious bug!
was it fixed?); if it's slow (people usually notice it with the grid on)
use the proprietary driver (need some patches with the newer kernels...)




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

Re: [Kicad-developers] KiCad scripting supported in the release or not

2015-10-04 Thread David Godfrey

Rather than doing this at compile time, can it be done at run or install 
time instead.
ie: if the relevant python support is available enable the scripting 
features dynamically, otherwise leave them disabled.
This could be done using 2 shared libraries (.so or .dll etc) one has 
all of the scripting hooks in it that are functional, the other has 
dummy hooks that either do nothing, or raise errors as appropriate.


David G

On 03/10/15 23:56, Wayne Stambaugh wrote:

Shamelessly pilfered from the movie "Karate Kid",

build config tools rule #1: Always check for features, not platforms.
build config tools rule #2: go back and learn rule #1.

Yes we could check for msys but it is possible (however painful) that
someone may have actually patched, built, and installed python on mingw
(in fact the msys2 folks and Brian's kicad-winbuilder have kindly done
that for us) so testing for existence of python is a more robust test
which will work on every platform.  However, the existence of python on
the build system does not ensure it's existence on the install target
system unless you use a system that has some kind of package manager
that ensures the dependencies are met.

On 10/2/2015 11:12 PM, David Godfrey wrote:

Surely it would be possible to detect which msys version is available,
and automatically enable scripting if msys2 is found?


On 03/10/15 02:32, Wayne Stambaugh wrote:

This cannot be done because of the old msys1/mingw32 builds which
require Brian's kicad-winbuilder in order to build all of the
dependencies correctly.  Build python and wxpython on msys1/mingw32 is a
major hassle which has been eliminated with the new msys2/mingw32/64.
For the stable release, I would prefer that packagers enable scripting
on a case by case basis.  We certainly can discuss turning it on by
default after the stable release and dumping support for the old
msys1/mingw32 platform.

On 10/2/2015 2:24 PM, Nick Østergaard wrote:

Hello

Since we have been discussing the python scripting stuff recently, I
would like to hear if it is supposed to be officially supported or
not.

The thing is that it is by default OFF in the build scripts. This is
choice likely to affect many linux distributions build configuraiton.

I would actually suggest that we enable it by default. Any comments?

Regards
Nick

___
Mailing list: https://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] 3D model relative path dialog

2015-09-27 Thread David Godfrey


I agree with Nick on this.

Make it easy for the user to select one of the PATH variables in the 
dialog and have it saved in the stored reference.
This way we can easily choose if we want absolute (maybe from a company 
server), relative to the base installation (default libs), or relative 
to a project (customised parts such as enclosures, heatsinks, sub 
assemblies, etc )


A simple dropdown of available variables with an "insert" button on the 
dialog is one option.
Another option would be a tooltip that prompts you to use the right 
click menu where a submenu lists all available variables. eg:


PopupMenu -> Path Variables ->
  KISYS3DMOD - 3d Module Direcory
  KIPROJMOD  - Project directory
     - User configured Library Path Variable




Regards
David G

On 28/09/15 00:56, Nick Østergaard wrote:

No, that is not a good design IMHO. You should be able to use every
option in a single project if you wish to. But I like to be explicit.

A suggestion I have have somewhere before is to use theese variables
in the path. So i you want ti projecet relaive use KIPRJMOD if you
want "global" models, use the KISYS3DMOD variable, and make it easy
for the user to enter even with browsing.

2015-09-27 18:48 GMT+02:00 Thor-Arne :

I think the absolute adressing should be good enough for those special
cases.
Special cases shouldn't affect the "normal" cases.

-Original Message- From: Mark Roszko
Sent: Sunday, September 27, 2015 6:38 PM
To: Thor-Arne
Cc: KiCad Developer mail-list

Subject: Re: [Kicad-developers] 3D model relative path dialog

I am advocating only for people who don't want to globalize their
models that might be super specific. If I have a custom extruded
heatsink model(because custom heatsinks are dirtcheap) that is
literally only made for one board, why would I
want to put that in the global folder?

On Sun, Sep 27, 2015 at 12:32 PM, Thor-Arne  wrote:

Relative to board file is a bad idea, it will require 3D models to be
duplicated for each project.
Perhaps this should be handeled by the File->Export->VRML (not that I've
tried that one).

And, yes. Please apply this patch. ;)

-Original Message- From: Mark Roszko
Sent: Sunday, September 27, 2015 6:19 PM
To: Simon Wells
Cc: KiCad Developers
Subject: Re: [Kicad-developers] 3D model relative path dialog


Relative to the board file seems like a better idea btw. In case you
want to package 3d models with a PCB when distributing the source.

On Sun, Sep 27, 2015 at 7:46 AM, Simon Wells 
wrote:


When you add a 3d model for a footprint

If the model file is inside the KISYS3DMOD directory then it is
automatically made relative path
If the model file is outside the KISYS3DMOD directory then you get a
dialog
as to whether it should
be relative or not,

If the model file is not in the KISYS3DMOD directory it seems like a bad
idea to make the model
have a relative path because if you move either the KISYS3DMOD directory
or
the model it
requires changing the path, whereas if its absolute then you only need to
update the path if you
move the model file.

I have created a branch with a patch to remove the dialog and if theres
consensus then i will submit
a merge request with it. (the branch is lp:~xzcvczx/kicad/relpath-dialog)


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




--
Mark

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




--
Mark

___
Mailing list: https://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] Stackup heights and length tuning PoC

2015-08-20 Thread David Godfrey




On 20/08/15 22:36, Tomasz Wlostowski wrote:

On 20.08.2015 16:29, Jeppe Johansen wrote:

Hi,

I've been working on adding support for entering stackup information and
using that info when length tuning traces.

Some screenshots:
http://j-software.dk/kicad/thickness.png
http://j-software.dk/kicad/length.png

Patch here(warning, back up any .kicad_pcb files before you save. The
format is changed to include layer heights):
http://j-software.dk/kicad/kicad_stackup.patch

Getting it into the meander placer required a bit of hacking to process
vias and find all segments connecting to it. That part is a bit ugly,
but it works. Also the length calculation is duplicated for each tool
variant. Unifying those in a single place would be great. For now my
patch only modifies the single trace length tuner.

Hi Jeppe,

Thanks for the patch.

I'm not sure if we should define separate layers for cores/prepregs,
though. How are they going to be stored in .kicad_pcb file? What if
there is more than one layer of dielectric between each two adjacent
layers? Maybe a new dialog for defining the complete stackup (including
dielectric factors, losses, etc) would be a better idea?

Regards,
Tom




Hi All,

I agree with Tom.
A new dialog that allows definition of the layer stack with all 
paramaters including dielectric characteristics would be preferable.
In the future we could use this information to auto calculate impedance 
of striplines etc as well.


Regards
David

___
Mailing list: https://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] Translation of dialog_bom_help.html

Re: [Kicad-developers] pcbnew Append Board functionality not always available

[Kicad-developers] pcbnew Append Board functionality not always available

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

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

Re: [Kicad-developers] Deleting layers.

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

Re: [Kicad-developers] Deleting layers.

Re: [Kicad-developers] Undo/Redo behavior across schematic

Re: [Kicad-developers] [PATCH 2/2] Remove redundant statement in WRL2BASE::ReadNode

Re: [Kicad-developers] Bug 1677282 fix feedback.

Re: [Kicad-developers] Icon policy

Re: [Kicad-developers] Via Stitching

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

Re: [Kicad-developers] 3D file relative paths

Re: [Kicad-developers] New pcbnew features and versioning

Re: [Kicad-developers] New pcbnew features and versioning

Re: [Kicad-developers] Slow performance in pcbnew (PNS/GAL only) on high-fanout nets

Re: [Kicad-developers] Linux dependencies for building from source

[Kicad-developers] Interesting Discussion Re: [RFC] Wildcard and/or regex support in the component chooser

Re: [Kicad-developers] [RFC] Wildcard and/or regex support in the component chooser

Re: [Kicad-developers] Interesting Discussion Re: [RFC] Wildcard and/or regex support in the component chooser

Re: [Kicad-developers] [RFC] Reorganize eeschema options a bit

Re: [Kicad-developers] [rfc] actual sexpression parsing

Re: [Kicad-developers] Full integration to Github

Re: [Kicad-developers] suggested resolution (and other specs)

Re: [Kicad-developers] KiCad scripting supported in the release or not

Re: [Kicad-developers] 3D model relative path dialog

Re: [Kicad-developers] Stackup heights and length tuning PoC

30 matches

Site Navigation

Mail list logo

Footer information