Re: [Kicad-developers] libcurl.so.4: version 'CURL_OPENSSL_3' not found

[tiger12506]

Well. Scratch that. It has fixed itself somehow.

I think a reinstall of the libcurl3-gnutls package must have fixed it.
Can't say I completely understand it all, libcurl3-gnutls was installed 
previously, I think.


Sorry for the noise.
Tiger


 Forwarded Message 
Subject: 	[Kicad-developers] libcurl.so.4: version 'CURL_OPENSSL_3' not 
found

Date:   Sun, 25 Apr 2021 22:38:15 -0400
From:   tiger12506 
To: kicad-developers@lists.launchpad.net



Any attempt to run Debian Buster repo version of kicad (5.1.9), or 
attempting to compile (previously working on this machine some time ago) 
versions 5.1.8 or the newly created 5.1.10 result in this at runtime.


kicad: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' 
not found (required by kicad)




I'm an experienced linux/terminal user, software dev, etc. so any help 
getting this working would be grand. Googling this shows this popping up 
in projects absolutely everywhere, so I assume this is a kind of "oops" 
of the libcurl people, but obviously it could just be my mistake somehow.


I think it's pretty clear that it's not kicad's fault, I'm not pointing 
any fingers, just looking for some help from someone more knowledgeable. 
Maybe some update-alternatives, or symlink-ing... or... reconfigure some 
packages??


Anybody run into this? I can't run kicad until I find a solution for this.

Thanks,
Tiger


___
Mailing list: https://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] libcurl.so.4: version 'CURL_OPENSSL_3' not found

[tiger12506]

Any attempt to run Debian Buster repo version of kicad (5.1.9), or 
attempting to compile (previously working on this machine some time ago) 
versions 5.1.8 or the newly created 5.1.10 result in this at runtime.


kicad: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' 
not found (required by kicad)




I'm an experienced linux/terminal user, software dev, etc. so any help 
getting this working would be grand. Googling this shows this popping up 
in projects absolutely everywhere, so I assume this is a kind of "oops" 
of the libcurl people, but obviously it could just be my mistake somehow.


I think it's pretty clear that it's not kicad's fault, I'm not pointing 
any fingers, just looking for some help from someone more knowledgeable. 
Maybe some update-alternatives, or symlink-ing... or... reconfigure some 
packages??


Anybody run into this? I can't run kicad until I find a solution for this.

Thanks,
Tiger



___
Mailing list: https://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 to draw bitmaps in GAL canvases

[Tiger12506]

I know nothing about kicad's GAL, but I'd use one rectangle and give it 
a texture that is the bitmap. It's been too long since I've messed with 
it for me to provide an example, but maybe something like this page 
would help? https://open.gl/textures


On 7/26/2018 5:46 AM, jp charras wrote:

Hi, GAL gurus,

I wrote this fix that add the code to draw bitmaps that can be used in page 
layout editor and eeschema.
(Currently, this code is missing, and bitmaps used in page layout are shown in 
legacy canvas, but
not in GAL canvases)

I need a GAL guru to verify this patch (I am not a OpenGL or Cairo specialist).
I do not want to break something.

I am thinking the Cairo code is good.
In opengl canvas, I am using a "brute force" code to draw pixels as rectangles.
I tried other ways, but there did not work.

Thanks.


___
Mailing list: https://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] kicad windows file associations

[Tiger12506]

That's funny. I hope Eagle and others change their file extensions so 
they don't conflict with Kicad's. Just saying.


On 7/8/2018 3:31 AM, Nick Østergaard wrote:

Thank you.

Den søn. 8. jul. 2018 kl. 05.54 skrev Mark Roszko 
mailto:mark.ros...@gmail.com>>:


Rejoice, the windows installer now setups file associations, icons and
friendly names for kicad files.

https://i.imgur.com/EcgnKmz.png

I hope .sch and .pro get renamed to .kicad_sch and .kicad_pro in v6
To avoid conflicts with Eagle and others.

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

[Tiger12506]

No, '?' also means zero-or-one in RegEx syntax, it's just that it *also* 
happens to mean "make the previous quantity modifier non-greedy" if 
there is a previous quantity modifier. Notice the double-question mark 
regex in the documentation quote previously pasted. That one means make 
the zero-or-one quantifier non-greedy.


On 5/5/2018 5:58 PM, Jeff Young wrote:
Ahhh… I’m mixing up XPath and RegEx syntax.  ‘?’ is zero-or-one in 
XPath, not RegEx.


Thanks Shiv & Thomas.

Cheers,
Jeff


On 5 May 2018, at 15:37, Shivpratap Chauhan > wrote:


According to documentation at 
http://docs.wxwidgets.org/3.0/overview_resyntax.html


|*? +? ?? {m}? {m,}? {m,n}?| 	/Non-greedy/ quantifiers, which match 
the same possibilities, but prefer the smallest number rather than 
the largest number of matches (see Matching 
). 




There seems to be difference greedy vs non-greedy quantifiers!


Thanks,
Shiv



On Sat, May 5, 2018 at 6:49 PM, Jeff Young > wrote:


We have a couple of regular expressions of the form:

wxRegEx re( ".*?\\$\\{(.+?)\\}.*?", wxRE_ADVANCED );


Now perhaps I’m too old to remember this stuff correctly, but .*?
is redundant, isn’t it?

And shouldn’t .+? just be .*?  (And for that matter, shouldn’t it
really be [^}]*?)

Thanks,
Jeff.


Note that I’m looking at this because it needs to check for both
${…} and $(…) formatted envvars, which I think boils down to:

.*(\\$\\{([^}]*)\\})|(\\$\\(([^)]*)\\)).*

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

[Tiger12506]

I'm not a kicad dev, just an avid reader of the list, but I am pretty 
fluent in git.
Here are some aliases that you might find useful (that go in your 
~/.gitconfig)


[alias]
    co = checkout
    ci = commit
    st = status
    br = branch
    hist = log --all --abbrev-commit --graph --date=short 
--pretty=format:\"%h %C(yellow)%aN %C(green)| %C(cyan)%d%Creset%s\"
    histd = log --all --abbrev-commit --graph --date=short 
--pretty=format:\"%h %C(green)%ad %C(yellow)%aN%Creset | 
%C(cyan)%d%Creset%s\"
    ll = log --all --stat --abbrev-commit --graph 
--pretty=format:\"%C(green)%h %aN | %C(yellow)%d%C(green)%s\"

    type = cat-file -t
    dump = cat-file -p
    d = whatchanged -1 -p
    del = !git rm $(git ls-files --deleted)
    dc = diff --cached
    wd = diff --word-diff
    cw = diff --color-words
    b = blame -w


I tend to use `git hist` and `git st` all the time. So that I can always 
see what's going on, I never use git pull, I always use git fetch 
instead. That seems to be in-line with what Wayne expects, since he says 
to rebase your changes. git pull would do a fetch and merge together, 
but you want to fetch and rebase -- you can set your .gitconfig to do 
the fetch and rebase, but I think it's easier to follow along with 
what's going on if you do the fetch separately and check the tree each 
time with git hist.



___
Mailing list: https://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] Rearrange Render panel of PcbNew layer widget; add spacers

[Tiger12506]

I agree 100% on separate file. As someone who puts kicad files in git, 
the most irritating thing in the world is having unrelated changes in 
your diff. Separate file gives you the flexibility to have either 
situation -- if you want the vcs to track it, you include the file, if 
you don't, your vcs ignores the file. It's unfortunate that there are 
already UI states in any of the files that represent a design.


Cheers. :)

On 2/22/2018 2:08 PM, Wayne Stambaugh wrote:

I'm agreeing with Andy on this one.  I really don't like the idea of
putting UI or print/plot state information in the board file.  Most of
the current state information was added by my predecessor.  I've never
liked the idea of UI state information being saved in the board file.
Andy pointed out that the same argument could be made for the project
file which makes sense to me.  An intermediate file seems like a
reasonable compromise.  I know this is one of those arguments that users
are going to disagree about.  I'll save everyone the hassle of arguing
about it by saying that as long as I am project manager, no additional
UI states are going to be added to any of the file formats.  If there
was some way I could remove them from the current board file format
without wrecking compatibility, I would.

Cheers,

Wayne

On 2/22/2018 1:07 PM, Andrzej Wolski wrote:

I agree. I think layer visibility data should be saved in board file
because that file should be independent of project file and any other
files. I would like to be able to send only pcb file via email, and have
all information contained there.

Some solution to problem Andy described might be not to mark board
modified if only layer visibility was changed.

Both Altium and Kicad have small hole here: board is not marked modified
if you flip view or enable high contrast mode, but it is marked if you
enable/disable some layer :)

Andrzej


On 02/22/2018 06:48 PM, Jon Evans wrote:

The tradeoff there is that other users will have a workflow that
involves setting up a nice set of layers displayed/hidden for working
on a board, and want to switch to another set for another board.
Maybe saving in the app preferences is okay in the short term, but I
think eventually it's best to be able to save custom display states
(including layer visibility and other options) in the project.
Other software has solved this problem by making multiple project
files, and having the idea of the "base" project file and the "user
settings" project file, with the latter explicitly not going in to
version control.

-Jon

On Thu, Feb 22, 2018 at 12:15 PM, Andy Peters mailto:de...@latke.net>> wrote:


 On Feb 22, 2018, at 7:58 AM, Jon Evans mailto:j...@craftyjon.com>> wrote:

 Currently some of the render visibility stuff is saved in the
 application preferences, and some is not saved.
 I think if there are layers related to board item visibility that
 aren't saved, saving them in the project or board makes more
 sense than saving in the app config.

 User perspective:

 Saving the render visibility in the project or pcb file “touches”
 that file, so Kicad will want to save the file when you close the
 project or PCB. And then your source-code control system thinks
 that the file has been modified (because it was!). This sort of
 change has nothing to do with the design, it is only a
 rendering/display detail.

 A common example: I often use pcbnew (or Altium, it has the same
 problem) to view a design, without intending to actually modify
 it. And when doing that, I often change layer visibility and such.
 When closing the pcb file, the user will be asked to save the
 file. “But all I did was look at different layers .. I didn’t
 change the design!”

 So, please, don’t keep layer visibility/rendering information in
 the pcb or project file!

 -a


 Re. 3, yes I think that same framework could be used to add some
 shortcuts for the "render" side pretty easily.

 Re. 2, seems reasonable, haven't looked at the code yet

 I can probably tackle this but can also leave it to Andrzej if
 you are interested in it.

 @Wayne I guess the first patch can be merged now if you are OK
 with it, since Jeff isn't worried about conflicts?

 -Jon

 On Thu, Feb 22, 2018 at 9:53 AM, Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:

 On 2/22/2018 9:10 AM, Andrzej Wolski wrote:
 > If some work on Render panel is still being done, I would
 have some
 > suggestions:
 > 1. "Text Front" and "Text Back" should be renamed to
 something like
 > "Footpr. Text Front" It is misleading now.

 I'm fine with this but please do not abbreviate the word
 footprint.

 > 2. "Bl/Bburied Via" and "Micro Via" could be hidden if they
 are disabled
 > in design settings.

 This makes sense as long as you do not couple the laye

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

[Tiger12506]

+1 on this approach, to me this is the obvious way that it should be 
done. However, my opinion is not important, I'm not a contributor. :)


On 9/27/2017 8:37 PM, David Godfrey wrote:

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





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

[Tiger12506]

I'm making more noise again.

Have all options been explored?

Sparse Checkout + clone depth = 1
https://stackoverflow.com/questions/180052/checkout-subdirectories-in-git

Using different branches to differentiate content in git. Seems weird... 
but why not?

https://stackoverflow.com/questions/466303/git-branches-with-completely-different-content

Maybe the svn approach being mentioned is the best, just trying to add 
ideas.


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

[Tiger12506]

As a user, I always move to the edge of my seat when this conversation 
comes up. I sit there, waiting for awesome new features like in-program 
diff and pull requesting for kicad libraries, and then I inevitably sit 
back down because (IMHO) kicad wanted to use the github api and start 
wget vs. curl w/openssl license issues or whatever it was that happened 
on the mailing list years ago when the feature got developed, instead of 
trying to use an actual git client to be... well... a git client, and 
because of all the work that went into it, it seems no one wants to 
scrap it.


And I wholeheartedly agree that the libraries should be in one repo, 
i.e. why were they separate to begin with... I've heard that git 
submodules is not awesome, but surely it would apply in this situation? 
You'd get one encompassing repo, and then the submodules that you 
specifically want, no more.


I'm sure everyone thoroughly thought through the design decisions 
involved, it just seems really weird and kicad-style quirky.


Sorry if this email offended anyone, it was only my excitement of 
getting the thought out there, I didn't mean to be rude.

JS

On 9/21/2017 9:26 PM, Jon Evans wrote:
I think it would make the most sense to do option (a), possibly also 
leaving open the possibility of changing the updates source location 
(for example, it's conceivable to have a mirror server at 
kicad-pcb.org  that contains snapshots of the 
libraries that are compiled from the Git repo whenever it's updated 
using a Jenkins job).


-Jon

On Thu, Sep 21, 2017 at 9:21 PM, 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 standing in the way of just doing this
is that some users like the GitHub plugin and previous instruction
is that this functionality cannot be removed.

The GitHub plugin functions by downloading a .zip file of a
.pretty repo. If we merge all footprint libs into a single repo
with multiple subdirectories, this will not work anymore (as
GitHub dosen't allow you to download a .zip of a single subdirectory).

Merging the repos is the *right thing to do*. But how to proceed?

*Options:*
*
*
/a) Drop github plugin feature, replace with library-download tool/

I don't think it is a good idea to live-load library data from
GitHub (a lot of other users agree too). It's slow, and a waste of
bandwidth to re-download the libs all the time.

We drop support for loading libraries direct from GitHub. However,
we add a tool for downloading libraries from GitHub and storing to
disk. Users can update as they like. This can be integrated in
KiCad and new users can run this tool when they first install
KICad. This means that no libs need to distributed with the
installer and users can update to latest libs whenever they want.

/b) Improve github plugin to allow subdirectory traversal/

This is difficult and will only result in the plugin being slower.
There are two ways I can see to do this:

i. Use Git API - tools exist that use this functionality -
https://github.com/KinoLien/gitzip

ii. Use subversion - 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

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

[Tiger12506]

My opinion doesn't matter, but how about this for a comment...

// ReadName has a side-effect of incrementing the parser, so it should 
indeed be called twice.


I certainly agree with you that people shouldn't change something they 
don't understand, but I also don't think it's unreasonable for someone 
to think that a function named ReadName might be a harmless read-only 
function.


Or if that comment doesn't accurately describe what's happening, provide 
an example of what's getting parsed by that line in a comment.


Just a thought.


On 4/13/2017 6:06 PM, Cirilo Bernardo wrote:

On Thu, Apr 13, 2017 at 1:34 PM, Clemens Koller  wrote:

Hi!

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

Regards,

Clemens


What sort of comment: "this is really supposed to have two sequential
calls to the same function, so don't change it"?  For me that makes no
sense. If anyone is going to play with parsers they should be familiar
with the standard that is being implemented; making changes without
understanding the specification (and without understanding what the
parser is doing) cannot possibly be a good thing. Programmers should
also check that they are fixing a demonstrable problem and if they don't
understand the code then it should be left alone. At any rate there is a
comment only a few lines back about how the unimplemented features
PROTO and EXTERNPROTO are to be treated and from this the fact
that PROTO and EXTERNPROTO code are different and in two distinct
blocks should suggest that they really should not be the same code.
In the past when other developers have seen code that they don't
immediately understand but which looks a little strange to them, they
at least ask for comments rather than making blind changes. If people
don't read an obvious comment block a few lines up I don't see why they
would read comments immediately surrounding code either. How much
hand-holding are we expected to do?

- Cirilo



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

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

[Tiger12506]

I swear the dev the list has completely and utterly hashed this out 
before. Maybe about when the footprint table came into effect. I mean, I 
know you can decide to change things now, but it was long and bitter and 
there was a decision made, I'm sure of it.



On 3/23/2017 8:34 AM, Wayne Stambaugh wrote:

I'm going to weigh in on this because this has been on my radar with the
symbol library table work I've been doing.  I do agree that we need to
pick one term and use it consistently.  My preference is the term symbol
because in my mind this is a component[1] and this is symbolic
representation[2] of a component ergo symbol.  However, I spent some
time this week checking out the documentation for all of the major and
quite a few minor EDA applications and they *all* use the term component
when talking about libraries.  This makes me think that for the sake of
uniformity with other EDA applications, we should use the term
component.  While I'm not a proponent of doing something just because
that's what everyone else is doing, in this case using the term
component may make users coming from other EDA apps a bit more
comfortable.  Personally, I'm comfortable with either term but maybe we
should not stray to far from the norm here.

[1]:
http://www.digikey.com/product-detail/en/stackpole-electronics-inc/CF14JT10K0/CF14JT10K0TR-ND/1741265
[2]: https://commons.wikimedia.org/wiki/File:Resistor_symbol_America.svg

On 3/23/2017 7:52 AM, Thor-Arne Hovland wrote:

Symbol has been used as long as I can remember.

The proper names should probably be defined to avoid confusion.

In my book:
A "symbol" is a generic repesentation for drawing a schematic,
and that is whats used in eeschema right now.

A "footprint" is the pads and silkscreen ++ used in pcbnew.

A "housing" is the physical package i.e. the 3D model.

The current way of doing things is a bit confusing and causes
many "symbols" to be reused in the library.
This is not effective when someting is to be changed.

It could be a good idea to introduce a "part" that stores all the needed
information like symbol, footprint, pin connections between symbol and
footprint,
3D modell, documentation.

This might be more intuitive for new user who I see repeatedly trying to
match a symbol
with pins "G-S-D" to a footprint with pins "1-2-3".

Just my 2 cent

-Original Message- From: Chris Pavlina
Sent: Thursday, March 23, 2017 3:30 AM
To: Simon Wells
Cc: KiCad Developers
Subject: Re: [Kicad-developers] UI improvements

Are we calling them "symbols" now? Internally they are called with
"components" or "parts" depending on whether they are on a schematic...

On Thu, Mar 23, 2017 at 03:25:03PM +1300, Simon Wells wrote:

just a slight segue is it not better to refer to symbols rather
than components? as with the footprints being seperated from the
symbols i don't see the justification for calling it a component (will
also require renaming other stuff)

On 23 March 2017 at 12:12, Chris Pavlina  wrote:

On Wed, Mar 22, 2017 at 11:53:40PM +0100, Clemens Koller wrote:

Hello, Fabrizio!

The horizontal + vertical justify radio buttons could possibly be
improved by showing the alignment visually as it's done in [1] by

using >> a 3 x 3 radio button matrix. It can also reduce the number of
clicks to >> 1 to adjust hor + vert simultaneously.

The timestamp is not human readable. It seems strange to me to dump

it >> as hex-number on the UI. (WTF!?)

I'm struggling to think of a use for this. Maybe for power users, to
jump quickly to the component in the raw sch file by searching for it -
but why not just search for the reference?

I wonder how many people would complain if I took that out.


The Component/Chip Name thingy seems to be lost a bit on the lower
left. Maybe some sorting of the elements based on the usage/setup
procedure as well as logic dependency could do some good.

Regards,

Clemens

[1] https://wiki.openoffice.org/wiki/File:WG9-9.png




On 2017-03-22 10:32, Fabrizio Tappero wrote:

hi guys,
I am looking at some new icons that were introduced in kicad by

the >> > people who made the related functionalities and at the user

experience in general. If any of you guys has any feedback about
possible (aesthetic) UI improvements I would love to know.

Specifically I am looking at this menu.

Inline image 1

the section "Chip Name" is a part that I use a lot and I find a
little "mysterious". Before going further with a possible patch

to >> > improve a little the usability of it I would like to know if
there is >> > any of you interesting in giving an opinion. I would
love to know >> > from the person who made it what exactly is the Chip
Name section >> > for. I feel it is not so evident to the user.

cheers
Fabrizio




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

Re: [Kicad-developers] Version strings in window titles

[Tiger12506]

I like it that way. But I'm only one person.


On 9/9/2016 11:37 PM, Chris Pavlina wrote:

Along the lines of the version strings - is anyone particularly attached
to having them in the window titles? It's a bit odd, no other
applications seem to do that. I kinda want to take them out, if just to
make things a bit more "normal"...




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

[Tiger12506]

I was really confused for a minute when someone verbosely said git log 
master..origin/master


Here's my current aliases. Aliases really make git awesome. Pay 
particular attention to `git hist` and `git ll` and `git d`


[alias]
co = checkout
ci = commit
st = status
br = branch
hist = log --all --pretty=format:\"%h %aN | %C(yellow)%d%Creset%s\" 
--abbrev-commit --graph --date=short

type = cat-file -t
dump = cat-file -p
ll = log --stat --abbrev-commit
d = whatchanged -1 -p
del = !git rm $(git ls-files --deleted)
wd = diff --word-diff
cw = diff --color-words
b = blame -w

Most of these are not my derivation, personally, but are collected from 
various tutorials.


Also, I like gitolite, but that's probably too fine-grained and 
configurable for a project like this, and the downside would be it would 
have to be hosted somewhere. Not trying to influence, just mentioning it 
since no one had.



On 8/8/2016 1:02 PM, Chris Pavlina wrote:

Well, I can't help with getting email notifications, but I don't
understand why logs are being grepped either. Getting a summary of
changes since the last update should be as simple as 'git fetch'
followed by something like 'git log master..origin/master', and you'll
get it in a nice summary form :P

Personally I'd go insane if I got an email for every commit ^_^


On Mon, Aug 08, 2016 at 12:48:27PM -0400, Wayne Stambaugh wrote:

On 8/8/2016 12:23 PM, Chris Pavlina wrote:

Well, we're not looking at Github anymore, right? Just Git on Launchpad?
So the pull request thing doesn't matter.

We use Stash (Bitbucket) at work, it seems to give much better control.
GitLab is also popular. I really, really want to see us switch to git,
as do many others, but I don't really care about GitHub and I think I'm
not entirely alone. Git is wonderful; GitHub is just a git service, and
honestly a bit of a mediocre one.

I think there is an advantage to us being on GitHub which is the
community exposure, since it's large and popular. The pull requests are
a side effect of that, one comes with the other. I think we wouldn't
really have a problem closing out frivolous PRs anyway. Also, there are
multiple bots that you can use to "disable" PRs by automatically closing
them, if you really want.

I'm not sure what sort of notifications you're talking about, but
there's probably already an easy way to do whatever it is you want with
git, without tedious log-grepping. What are Launchpad's notifications
like?

Anyone subscribed to lp:kicad will get an email notification of the
commit log entry and if the diff is less than 10K (I think) will also
get the diff as an attachment when a commit to lp:kicad.  The last time
I looked at the implementation status of git on LP, that still wasn't
complete unless I am misunderstanding what work they still have left to do.


On Mon, Aug 08, 2016 at 12:09:34PM -0400, Wayne Stambaugh wrote:

The last time I looked, notifications of repo commits still were not
implemented.  This is a show stopper for me.  I don't want to have to
constantly grep the git commit log to see what changed.  If change
notifications are working correctly, then I'm OK with moving forward on
this if you can get the bug fix linking working.  We definitely should
do some testing before we go live with this.

Before every starts beating the GitHub drum, I have one major issue with
GitHub and that is control.  There is no way that I know of to moderate
a project on github.  Anyone with a github account can submit a pull
requests at anytime even if they are not part of the dev team.  As
project leader, this is an issue.  I'm already a my limit with the
development team we have in place and I really don't want to deal with a
wide open code hosting.  I also have no way of removing someone from the
list should I need to.  I know it hasn't happened yet but I am not naive
enough to think that it wont happen.  At this time, I am more
comfortable with LP until something better comes along or we take full
control a provide our own hosting.

On 8/8/2016 3:58 AM, Maciej Sumiński wrote:

Apparently we have not discussed git transition for a long time now, so
I felt it is the right time to raise the subject again to keep our routine.

Launchpad now supports merge proposals [1] and it looks like they are
still improving git integration. The only missing feature are links
between bug fixing commits and respective bug reports (bzr commit ...
--fixes=lp:123456). It is not supported by git itself, but might be
resolved using webhooks [2] and appropriate keywords in commit messages
(e.g. "Fixed a memory leak [fixes #123456]"). If this is the only
obstacle, then I volunteer to provide code for the hook.

What do you think? Is there anything else that prevents transition?

Regards,
Orson

1. https://help.launchpad.net/Code/Git
2. https://help.launchpad.net/API/Webhooks



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

Re: [Kicad-developers] KiCad New Main Icon proposal

[Tiger12506]

Again, my opinion doesn't matter. I'm merely commenting

I find the pencil superfluous. No offense, truly, but a pencil on the 
icons makes me feel like I'm a fifth grader using a mac in grade school. 
I'm sure there *are* fifth graders using kicad to do cool things, but I 
can just about guarantee that if they are, they don't need the pencil.


Also,  I'll just throw an idea into the mix -- differentiate the the 
library editors somehow, but be consistent. In my head, I envision the 
schematic library editor as a book in (for example) isometric projection 
where the cover has a schematic symbol on it (op amp is good), and the 
footprint editor as a book in same projection with whatever footprint 
image you decide on it. DIP-8 looks good, but I'd try to keep it as 
distinct as possible from the appearance of track/traces that would 
denote pcbnew.


The two editors, the library editor and the footprint editor are 
distinct from my perspective because they are part of initializing the 
project to be ready for schematic capture, and pcb layout. That's my 
thought process, anyhow.


On 7/6/2016 7:27 AM, Maciej Sumiński wrote:

I am in favor of pencil removal too. What do you think about keeping the
page with a folded corner as the icon base, and depending on the editor:

- a part of schematic (like we have now)
- a single component
- a part of layout (like we have now)
- a single footprint

to show what is the editor target. Perhaps for a single
component/footprints there could be dimension lines (as usual in
blueprints) shown to stress the single instance.

Regards,
Orson

On 07/06/2016 12:21 PM, Fabrizio Tappero wrote:

Hi Wayne,
I would strongly advise to get rid of the idea of having to put a pencil to
teach people that the program that they are going to open is going to be an
"editing" software and not a "viewing" software. In my opinion this
differentiation is not necessary and quite old style. Just click on the
Linux Menu button and have a look around.

Using the same reasoning, it might not be really necessary to teach people
that the library icon is a symbol library icon and not some sort of
library. You are right, we do have two kind of library editors (symbol and
footprint) and that is a little problematic. Ideally we should have only
one icon (one program) that allows to do both editing. But we dont.
Naturally the look of these two icons might have to look similar. I find
the footprint editor a bit of secondary editor since packages are less
prone to change. I get your point anyway.

Human footprint is a little inappropriate. Maybe this example could be more
likable.


cheers
Fabrizio






On Wed, Jul 6, 2016 at 11:22 AM, Wayne Stambaugh 
wrote:


On 7/6/2016 3:20 AM, Fabrizio Tappero wrote:

Dear All,
few years have passed since the last main Kicad icon restyling. In my
opinion, the current icons are serving us quite well except for very few
which could use a little face lift.

The few icons that make me particularly itchy are the main Kicad icons
for which this very imposing pencil does not play very well. I know that
some of your really want a pencil to suggest that those tools are for
editing. The truth is that now a days icons can be a little more subtle.

I'd like to propose these new set of icons for the main KiCad toolbar.
Please let me know what you think and please if there is anybody who
wants to help out please, now is the moment.

Cheers
Fabrizio


Fabrizio,

The symbol library editor bitmap is too generic.  We have two library
editors, a symbol library editor and a footprint library editor.  Your
proposed symbol library editor icon is ambiguous (it just an icon for a
library metaphor).  If it had a symbol such as and op-amp superimposed
over the top of the books, that may be more clear.  I may also need some
edit metaphor (such as the pencil in the current icon) as well because
it could be confused as library viewer rather than and editor.  Although
our current icon is also ambiguous.  It looks like you are going to open
a text editor.

Your footprint library editor icon could be confusing as well.  Most PCB
layout users are familiar with the concept of component footprints.
It's what they do.  The human footprint may be more familiar to
non-technical users but I don't think that is relevant for KiCad users.
There is also no edit metaphor.  Perhaps you should use your symbol
library editor icon with a component footprint and some edit metaphor
(pencil?) superimposed over top of it for the footprint library editor
icon.

Cheers,

Wayne

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




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

Re: [Kicad-developers] KiCad New Main Icon proposal

[Tiger12506]

*My opinion doesn't matter*, but I would like to _remark_ that I find 
these examples much more intuitive than the current icons.


With the current icons I get confused, often opening the footprint 
editor when expecting pcbnew, etc. I've come to accept that an open book 
or diary implies somehow the "Library Editor" which doesn't immediately 
register in my mind is for editing schematic symbols.


The screenshot you attached was much clearer to me -- however -- I 
wonder if "human footprint" makes the same connection as "component 
footprint" in the variety of human languages that kicad serves.


I guess I'm not really saying anything conclusive, except that your 
attachment basically helped to put in to words what I felt about the 
current icons.


Also, a slight spacing between the groups of icons would be helpful, I 
would think. Right now all icons have the same spacing between them, 
however if there were space between library editor and pcbnew, and space 
between footprint editor and the "extra tools" then I think it would be 
even clearer.


On 7/6/2016 3:20 AM, Fabrizio Tappero wrote:

Dear All,
few years have passed since the last main Kicad icon restyling. In my 
opinion, the current icons are serving us quite well except for very 
few which could use a little face lift.


The few icons that make me particularly itchy are the main Kicad icons 
for which this very imposing pencil does not play very well. I know 
that some of your really want a pencil to suggest that those tools are 
for editing. The truth is that now a days icons can be a little more 
subtle.


I'd like to propose these new set of icons for the main KiCad toolbar. 
Please let me know what you think and please if there is anybody who 
wants to help out please, now is the moment.


Cheers
Fabrizio



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


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

Re: [Kicad-developers] libkicad_3dsg.so.2.0.0

[Tiger12506]

Okay, thank you for that information.

On 4/19/2016 11:46 PM, Cirilo Bernardo wrote:

This issue is due to a required shared library being installed to
a path which is not currently checked by ldconfig. In your case
the path is /usr/local/lib.  You will need to configure ldconfig to
look for shared libraries in /usr/local/lib, then run ldconfig to
update its cache.  This is not a bug, it is an issue that needs to
be addressed by package maintainers and users who build and
install from source. Since different Linux systems manage the
ldconfig configuration in different ways it makes no sense for
KiCad developers to attempt to manage this configuration via the
CMake install scripts.

- Cirilo


On Wed, Apr 20, 2016 at 1:20 PM, Tiger12506 <mailto:tiger12...@gmail.com>> wrote:


A little problem when I compiled the latest bazaar revision.

A kicad that runs, but trying to open pcbnew results in error.
Also occurs when trying to run pcbnew standalone.

See attachments
--

Application: kicad
Version: (2016-04-19 BZR 6703)-product, release build
Libraries: wxWidgets 3.0.2
   libcurl/7.38.0 OpenSSL/1.0.1k zlib/1.2.8 libidn/1.29
libssh2/1.4.3 librtmp/2.3
Platform: Linux 3.16.0-4-amd64 x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.55.0
Curl: 7.38.0
KiCad - Compiler: GCC 4.9.2 with C++ ABI 1002
Settings: USE_WX_GRAPHICS_CONTEXT=OFF
  USE_WX_OVERLAY=OFF
  KICAD_SCRIPTING=OFF
  KICAD_SCRIPTING_MODULES=OFF
  KICAD_SCRIPTING_WXPYTHON=OFF
  USE_FP_LIB_TABLE=HARD_CODED_ON
  BUILD_GITHUB_PLUGIN=ON


    --
Tiger12506 mailto:tiger12...@gmail.com>>

___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   : https://help.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] libkicad_3dsg.so.2.0.0

[Tiger12506]

A little problem when I compiled the latest bazaar revision.

A kicad that runs, but trying to open pcbnew results in error. Also occurs when 
trying to run pcbnew standalone.

See attachments
--

Application: kicad
Version: (2016-04-19 BZR 6703)-product, release build
Libraries: wxWidgets 3.0.2
   libcurl/7.38.0 OpenSSL/1.0.1k zlib/1.2.8 libidn/1.29 libssh2/1.4.3 
librtmp/2.3
Platform: Linux 3.16.0-4-amd64 x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.55.0
Curl: 7.38.0
KiCad - Compiler: GCC 4.9.2 with C++ ABI 1002
Settings: USE_WX_GRAPHICS_CONTEXT=OFF
  USE_WX_OVERLAY=OFF
  KICAD_SCRIPTING=OFF
  KICAD_SCRIPTING_MODULES=OFF
  KICAD_SCRIPTING_WXPYTHON=OFF
  USE_FP_LIB_TABLE=HARD_CODED_ON
  BUILD_GITHUB_PLUGIN=ON


-- 
Tiger12506 
23:13:50: libkicad_3dsg.so.2.0.0: cannot open shared object file: No such file 
or directory
23:13:50: IO_ERROR: Fatal Installation Bug. File:
'/usr/local/bin/_pcbnew.kiface'
could not be loaded
Perhaps a shared library (.dll or .so) file is missing.
>From command line: argv[0]:
'/usr/local/bin/pcbnew'

from kiway.cpp : KiFACE() : line 223
___
Mailing list: https://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 plugin for STEP/IGES via OCE

[Tiger12506]

I have no authority in what happens, nor should you necessary take my 
advice, of course, but it might be wise to carefully consider how you 
want to store large binary data in git.


If the diffs do not make sense, and are large, then you are using 
version control about as inefficiently as you possibly can, and your 
fetch (part of pull) operation is going to get huge, fast.


One of the solutions for this (one at random that comes to mind, not 
endorsing it) is git-annex.


The time to think about this, IMHO, is before you create the repo.

On 3/10/2016 6:10 PM, Cirilo Bernardo wrote:
I suggested splitting the 3D models long ago but there was some 
resistance even though
I really can't imagine how 3D models belong in a directory structure 
with schematic symbols.


Some thought would need to go into the organization of the 
repositories and how these
would look like as an offline directory structure for users who prefer 
to pull the repositories.
I think any STEP and IGES files should be compressed; their data 
structure results in very
high compression (often as much as 10:1). Although this would result 
in crazy diffs, git
will not complain. Crazy diffs on modifying STEP or IGES files is 
inevitable anyway.


I think ultimately a hosted solution with features similar to Altium's 
"vault" is the way to
go; however that requires some hosting infrastructure and development 
of the API and

any code/scripts to make it all happen.

- Cirilo




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

[Tiger12506]

This email is merely a suggestion.

I would personally approach it by having each plugin determine the 
file's eligibility to be parsed. After all, who can know better than the 
parser author whether or not a file will be successfully parsed by a 
plugin? I would NOT suggest having any assumptions made by the calling 
code -- one email I think hinted that you could read a section of file 
and then pass in a string to the plugin function -- but NO, because who 
knows how far to read in to the file but the author of the plugin? Who 
knows what encoding that file is in? The person in the best position to 
answer that question is the plugin author.


If a plugin writer does not provide an implementation for that function, 
then the base class can do whatever you want it to do -- make an 
educated guess, rely entirely on file types, prompt the user, anything 
you want.


I doubt that testing file types is going to be your most computationally 
intensive task when loading imported files.


Perhaps the one true answer (lol) is a mixture of the two. Why not order 
the plugins to test against based on the file extension? Though file 
extensions are not the best indicators of a file type, it should narrow 
it down to a couple plugins. Each could open,read a dozen bytes,close in 
a milliseconds.


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

[Tiger12506]

Cool. :)


> Dots are also coming to the GAL. Some people prefer lines, some other
> dots, they will be selectable.
> 
> 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

Re: [Kicad-developers] Grid in pcbnew

[Tiger12506]

Ok, thanks -- is it just on my machine that the colors aren't very pronounced? 
Notice the difference (or apparent lack thereof) between "white" for the 
ratsnest and darkest gray that isn't black for the grid...

I think I'm falling into the "liked the dots better" camp... haha


On Tue, 1 Mar 2016 00:11:12 +0100
Tomasz Wlostowski  wrote:

> On 29.02.2016 23:55, Tiger12506 wrote:
> > I follow the list and skim over every email. I seem to recall there were 
> > some changes made to the grid in pcbnew due to an os x problem somewhat 
> > recently.
> > 
> > Attached I have an image from BZR 6601 running on Debian MATE that seems 
> > extremely grid heavy to me. Is there any way to change this? I don't 
> > remember it being this pronounced.
> 
> Hi,
> 
> You can change the grid color to a darker one (click on the color
> indicator in the layer widget).
> 
> Tom


-- 
Tiger12506 
___
Mailing list: https://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 delete hot key behavior.

[Tiger12506]

On 2/29/2016 3:29 PM, Wayne Stambaugh wrote:

On 2/29/2016 3:25 PM, Tiger12506 wrote:

I'm always accidentally deleting components when trying to cleanup a
track that i didn't route correctly.

I don't know if one is a good idea over the other, but I can certainly
understand why someone would think that.

Perhaps, but Ctrl-Z is much faster than selecting the track tool,
deleting track(s), selecting the previous tool your were using to resume
your work just to prevent accidental deletes.

True. I personally would probably go for something more like what Simon 
suggested. But I'm just one user out of thousands. :)


"""
in that case is it worth making the clarify menu used, and being able to 
select which one you want with a number key to avoid having to move the 
mouse and maybe order it in terms of whats most likely, aka most 
likely is track then label(s) and so forth


"""


___
Mailing list: https://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 delete hot key behavior.

[Tiger12506]

I'm always accidentally deleting components when trying to cleanup a 
track that i didn't route correctly.


I don't know if one is a good idea over the other, but I can certainly 
understand why someone would think that.


On 29.02.2016 21:41, Wayne Stambaugh wrote:

Does anyone really think limiting hot keys to the currently
selected tool is a good idea?





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

[tiger12506]

I've set my default pull behaviour to rebase, so I can just leave
submitted patches in my master branch -- if any one of them gets merged,
the rebase will remove my local commit, and I have an excellent overview
of which patches are merged.

Simon


Oh wow! I didn't know one could do that. Thank you, sir!

In retrospect, this was obvious, but thanks anyways!!!

___
Mailing list: https://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 FIXED: Opening pcbnew from kicad: ImportError: No module named pcbnew

[tiger12506]

  
  
I've heard Phoenix mentioned twice now.

http://wiki.wxpython.org/ProjectPhoenix

This language here

```
Phoenix is the code name of
for the new version of wxPython. I called this the Phoenix project
because in the process of doing this project wxPython's
implementation will be utterly destroyed and then reborn in a new
and marvelous way, much like the mythical Phoenix rising from the
ashes of its former self. For wxPython many things about how the
wrapper/bindings code is produced will be changing, and we'll also
be eliminating some other crud along the way
```

makes me wonder how compatible it will be with anything wxpython for
python 2.

On 1/12/2016 9:32 PM, Blair Bonnett
  wrote:


  Thanks Wayne.


For anybody else wondering, there is a rewrite of wxPython
  underway, Project Phoenix. Not clear how close it is to being
  usable though.


Blair
  
  
On 13 January 2016 at 15:15, Wayne
  Stambaugh 
  wrote:
  On 1/12/2016 8:38 PM, Blair Bonnett wrote:
  > On 13 January 2016 at 13:02, Clemens Koller  c...@embeon.de>>
  wrote:
  >
  >
  >     So, it looks that we are fine from Python 2.7 up
  to Python 3.5.1
  >
  >
  > (Slight hijack of the thread follows).
  >
  > The main CMakeLists.txt file requires Python 2.x (2.6
  or 2.7 if I am
  > reading it correctly). Is there some incompatibility
  with Python 3 that
  > anyone is aware of? SWIG claims to support Python 3
  -- do some of our
  > bundled scripts only work with 2.x, or is this
  requirement a hangover
  > from before SWIG could handle Python 3?
  >
  > Cheers
  > Blair
  
wxPython has not been ported to Python 3.  If you
want wxPython support,
it's Python 2 or nothing.  If you just want Python scripting
without
wxPython, then Python 3 may work.  I don't know that it's
been tested.
IFAIR, the build configuration will only look for Python 2.

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


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

  


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



  


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

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

[tiger12506]

Ok. I see. Sorry for the noise.


Not sure how storing base64 would help.


Namely file size savings and sanity. Instead of all those ridiculous X
number of hex bytes on each line split with spaces, you have a single
quoted entry that's a base64ed.
And you can actually manually edit that, god forbid someone wants to
do that then.



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

[tiger12506]

Not disagreeing with you on this one, but I would have to question why...

Why change this when what is already there means something more than 
what you're proposing...
KiCad doesn't have to do internally what "every other browser, 
application, and tool" does, if it doesn't help anything.

Not sure how storing base64 would help.

*backs away slowly*

On 12/17/2015 11:20 PM, Mark Roszko wrote:

I just saw this:
http://i.imgur.com/H8VxD3Z.png

storing a bitmap as hex values.

Next proposal item to add: storing binary data(bitmaps) as base64
quoted strings like every other browser, application and tool.

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



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

Re: [Kicad-developers] OSX glm include dir incorrect

[tiger12506]

A random thread-jacking...

If there are any vim fans out there, I have this in my .vimrc
nmap rr :%s/\s\+$//g

so that if I want to remove trailing whitespace, I just ESC to normal 
mode double-tap 'r' and hit enter.

number of substitutions appears in the status bar. :)


On 12/9/2015 3:47 PM, Wayne Stambaugh wrote:

Cirilo,

I was looking at the original commit and there is a bunch of trailing
white space in FindGLM.cmake.  I didn't check the cpp source changes for
trailing white space.  I'll clean it up this time.  In the future,
please clean up your trailing white space.

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

Re: [Kicad-developers] Drawing arcs broken in pcbnew and footprint editor?

[tiger12506]

I shouldn't really be hijacking your thread -- but I hate the 
center->start->end ordering for drawing arcs.
I think it should always be start->end->(center). It's really hard to 
make an arc meet up with other line drawings if I have to calculate and 
click on the center first.


Jacob

On 10/20/2015 1:39 AM, Bernhard Stegmaier wrote:

Hi,

I already mentioned it in the OS X graphics performance thread…
Is drawing arcs working as expected on Windows/Linux for pcbnew and footprint 
editor?

For OS X it doesn’t seem right for me…
In eeschema I draw by clicking start->end->3rd point (if I remember correctly), in 
OpenGL canvas it is center->start->end.
In default canvas it seems that I can click only 2 times (center and some other 
point) and I only get 90° arcs.
Similar for footprint editor, but here I additionally get drawing artefacts in 
form of two concentric arc fragments I don’t get in pcbnew.


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



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

Re: [Kicad-developers] [Patch] Add gitlab support to github plugin

[tiger12506]

"A vendor neutral git API"
Yeah, a git executable client.

I'm not sure why it wasn't made to use a git client in the first place. 
I like the idea of KiCad being smart about retrieving the footprints 
from github, I'm just not sure why it needed to use the github APIs that 
only work with github. (Does it?)
Seems to me that the repo system to use could easily be a list of git 
clone URLs


Like, I said, I have no stock in this myself, and I don't really know 
how it works currently.
I am curious, though, why it wasn't chosen to work that way in the first 
place.


On 8/17/2015 3:39 PM, Matthew Beckler wrote:
Getting back to the question about adding gitlab support to the github 
plugin, does anyone know if there is any vendor-neutral git API that 
could be used on any publicly-accessible git repository? Perhaps it 
wouldn't be too difficult to refactor the github plugin into a generic 
git plugin? I will try to look into the github plugin to see how it 
works.


Cheers,
Matthew




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

Re: [Kicad-developers] [Patch] Add gitlab support to github plugin

[tiger12506]

I don't really have any stock in this, but *yes* to what this guy said.

On 8/17/2015 2:52 PM, Matthew Beckler wrote:
It seems very strange to target our software at specific 
implementations of git front-end websites. It seems even stranger to 
suggest to end users to install a web server to act as a proxy to 
improve performance.


It seems like a simpler approach would be to support local git 
repositories in the filesystem. This would be vendor-neutral and would 
support any and all git front-ends like GitHub and GitLab. If users 
want to update their footprints, a simple git pull will do the trick, 
no need to embed that functionality into KiCad I think. I'm not sure 
of the benefits of having KiCad directly query git repositories online.


Just my two cents, please feel free to ignore me.

-Matthew Beckler




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

[tiger12506]

+1 - Just a user here, Thank You for this.

On 8/4/2015 5:32 PM, Chris Pavlina wrote:

In any case, here's the patch to make undo configurable. I can edit it
to change the default if you like.





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

[tiger12506]

  
  
Just one minor detail, I would probably choose to have all selected
as the default. Users don't like to read, and the less action they
have to take, the happier they will be.

Otherwise, you might have a lot of users with an empty table.




  

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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[tiger12506]

I have no weight in the discussion, but I really like Tom's suggestion here.

It allows you to use them as if they were units. 10 * mm is almost 
syntactically identical to 10mm.
And they don't get in the way with a bunch of boilerplate, like some of 
the other suggestions do.


~JS

On 1/24/2015 3:55 PM, Tomasz Wlostowski wrote:

On 16.01.2015 18:43, Miguel Ángel Ajo wrote:

The user shouldn’t need to know what an IU is unless he really wants, for some
reason.


Hi Miguel,

Why make things complicated here? Given that the choice of IUs in pcbnew
is very reasonable and easy to understand, I see no reason for hiding
that knowledge from script writers. A nanometer after all, is just
one-millionth of a millimeter. No rocket science here...

On the other hand, we need to provide a sensible way of
inputting/presenting values with units. For hardcoded values, defining
units could be just multiplying by a fixed scalefactor:

from pcbnew import mm, inch, mils

#pcbnew.mm = 100
#pcbnew.inch = 2540
#pcbnew.mils = 25400

p = Point(10 * mm, 12 * mm)

Concerning UI input/output (dialogs) - recently I had to do some dialogs
for P&S with lots of values in mm/inches, so to avoid repeatable unit
conversion code, I developed a class tiny called WX_UNIT_BINDER [1]. It
binds together a WX text control with an unit label:

class MyDialog : public dialog_generated_by_wxfb_base {
WX_UNIT_BINDER m_myValueInUnits;
};

MyDialog::MyDialog() :
m_myValueInUnits ( m_myValueText, m_myValueUnitLabel )
{
m_myValueInUnits.SetValue ( value_in_iu_here )
// x = m_myValueInUnits.GetValue();
}

All unit conversion is done inside the binder class, according to the
current units setting. All the user needs to do is to get/set the value
in IUs. Maybe a similar method could be used in the scripting API?

Cheers,
Tom

[1]
https://github.com/twlostow/kicad-dev/blob/tmp-crap/include/wx_unit_binder.h

___
Mailing list: https://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] First board shipped with the new P&S router

[tiger12506]

I like the P&S router, too-- you mentioned that it needs some practice 
in 'convincing' it to go the way you want.


I've noticed that the P&S completely ignores the '/' hotkey which in 
normal view allows you to change orientation of a track

That would be terrifically useful.


On 9/8/2014 4:39 AM, Lorenzo Marcantonio wrote:

OK, admittedly an easy board (about half eurocard and 300 pins) but with
seven segment display common stitching (I hate that, you know when you
multiplex the digits... i.e. every time :D)

Done in about 30% time of the estimation. The router works well but it
needs some practice in 'convincing' it to go the way you want. Also
sometimes pushes track slightly off grid, but nothing serious.

The amount of clean up afterwards is comparable with the one needed with
other P&S routers (didn't tried many others however)... only a little
more than with full hand routing.

All in all a good experience (too bad for the opengl display and some
yet unimplemented things)

Keep on the good work




___
Mailing list: https://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] Edge.Cuts layer in the module editor

[tiger12506]

Excellent suggestions.  This seems like a reasonable path forward.  I
really like the snapping idea as an easy way to close the vertices.  I
always have to manually go back and use the segment properties to make
sure each vertex ends at the same point if I don't get them right the
first time.  Should I add this to the road map?  It seems like a good
candidate.




(just a user here...)

Hip hip, hoorah!!! (raises mug.)

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

[tiger12506]

I would like to put in my two cents here.

Before it was restricted to > 2 copper layers in the UI, I would set it 
to one copper layer in order to enforce the one routing layer constraint 
for freeroute.


Since that has changed, I now have to manually remove one of the layers 
in the board file in order to force freeroute to only use one layer. If 
there is a better way to do this, I'm all ears.


~Jacob

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

[tiger12506]

Uhhh, or you could just split it up, like people do in other languages.

ip = s1.Intersect(s_next);
if (ip != 0) {
}


On 6/3/2014 2:18 AM, Heiko Rosemann wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/03/2014 04:49 AM, tiger12506 wrote:

This is a guess (i'm not OP), but it's pretty common to shun
assignment within an if condition. The second line probably just
masks the warning from the compiler -- the check that triggers the
warning probably isn't exhaustive enough to check within the
parentheses for assignment.

Probably the way to do this formally correct and without relying on
implicit integer-boolean conversion would be the following:
if( (ip = s1.Intersect( s_next )) != 0 )

Heiko


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

[tiger12506]

This is a guess (i'm not OP), but it's pretty common to shun assignment 
within an if condition.
The second line probably just masks the warning from the compiler -- the 
check that triggers the warning probably isn't exhaustive enough to 
check within the parentheses for assignment.



On 6/2/2014 6:32 PM, Tomasz Wlostowski wrote:

On 02.06.2014 19:52, Bernhard Stegmaier wrote:

Hi,

building with clang (at least on OSX) and -Wall is really noisy so that
you can hardly see what’s going wrong.
So, I decided to fix the warnings… attached are 3 patches I prepared
(against rev. 4911):

*** clang-warnings-1.diff:
Everything that probably should be fixed:\


Hi Bernhard,

-if( ip = s1.Intersect( s_next ) )
+if( (ip = s1.Intersect( s_next )) )

What upsets clang in the first line? I'm asking because I'm unable to 
get Kicad to build with clang on Linux (wx 3.0) due to compilation 
errors in wx...


Tom

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



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

Re: [Kicad-developers] PPA help: Write bzr-dch

[tiger12506]

On 5/21/2014 9:37 AM, Adam Wolf wrote:

Hi folks,

People keep asking about how to help with packaging.

One of the remaining tasks for the Debian and Ubuntu PPAs for KiCad 
that needs to be done is a tool that will update the debian changelog 
file based on the bzr commit log.


These tools exist for svn and git, but the bzr one just adds

 * Changes


"the bzr one" -- do you have a link? I'm not familiar with the deb 
making tools, so if that is a stupid question, please say so.


Sorry if you've already found this, but is there a reason this wouldn't 
work?


https://code.launchpad.net/~evgeni/bzr-builddeb/dch


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