Dick Hollenbeck wrote:
I'll get started later this week. And then do the BOM fix at that time
also.
By the way, there's a subtle problem in the BOM format: lines like
#Cmp ( order = Reference )
also get translated into the local language. This means that you
can't reliably tell whether a BOM
Lorenzo Marcantonio wrote:
Only another playground... its the bounding tile of the component,
Hmm, but if you use it mainly for rework, adjacent components could
share the courtyard, no ? After all, you'll inspect or (de)solder
them one by one, not simultaneously.
Also, what do you do with
Dick Hollenbeck wrote:
[...] Installed (e.g. value=DNS) [...]
What would you think of elevating Installed (or whatever it
would be called in the end) to the rank of Footprint ? I.e., a
permanent field with an immutable name.
That way, eeschema could automaticaly flag absent components,
e.g., by
[ Belatedly changed the subject, to look better in that thread
hijacking trial. ]
Thanks for your description. Now I understand better where those
heavy symbols come from. Okay, not crazy. Not at all. But still
flawed ;-)
I agree that CPNs make things a lot easier, but managing them also
has a
Dick Hollenbeck wrote:
It arrives in the same slot and is shown in the
same slot as it did on my system. You may have to buy that symbol :)
Thanks for explaining ! So far, so good ...
Your template fieldnames, none of which probably exist in the symbol
when you receive it, will be pushed
Dick Hollenbeck wrote:
//C++ guarantees that operator delete checks its argument for null-ness
#ifndef SAFE_DELETE
#define SAFE_DELETE( p ) delete (p); (p) = NULL;
#endif
[...]
3) why cannot i put it after an if() statement (trick question)?
BTW, do you know this trick to make multiple
Torsten H?ter wrote:
AFAIK the Radeon 200 is based on the X300 Mobility; which is older than
5 years. It's true that there could be a better support for Linux, but
the newer products have a good OpenGL support - both ATI and NVIDIA
offer drivers, which have the same code base like their
Dick Hollenbeck wrote:
a) the personal libraries, and hopefully in the future
b) the project specific library, i.e. the schematic specific parts list.
Just curious: why do you consider project specific libraries to be
in the future ? I use them and see others use them all the time,
and things
Dick Hollenbeck wrote:
The concept of a *library file* is gone. [...] Each
component that we traditionally think of residing in a *library file* is
actually in its own file on disk in a directory (or repo or schematic).
That alone is a great idea :-) For projects with shared access, that's
Jerry Jacobs wrote:
The names are aliases for the corresponding layers:
Yes, the extensions I normally see are something like
g = Gerber
|t/b = Top/Bottom
||
.gbl
|
l = (copper) Layer
s = Solder mask
o = silk screen Overlay
p = solder Paste
r = Riddle ;-) (used
Chris Pavlina wrote:
> An external script was shared in IRC this morning that does this; I
> believe the author intends to share it publicly once it has a bit more
> polish. What sort of hints would you store?
I think you mean this:
Eldar Khayrullin wrote:
> Now eeshow search relative path relative current directory ($PWD) but should
> to search relative project file path. Errors if $PWD not equal to project
> file path.
Hmm, that seems to work here. For example:
~/t$ grep Lib test.pro
LibDir=y
LibName1=test
~/t$ ls
Eldar Khayrullin wrote:
> Conflicting of libgit2-dev (eeshow dependence) and libcurl4-openssl-dev
> (kicad dependence) packages in Ubuntu.
If you're on a "stable" installation (i.e., a base one should
reasonably expect to have no such issues), that would be something
you may want to report this
Eldar Khayrullin wrote:
> Now projects are opening from another places
Great !
> (maybe I was confused with
> message like this one "../kicad-gost-library/linear-gost.lib: not found")
Yes, there can be quite a lot of complaints like this, and they can
be confusing at times. I still need to tame
Eldar Khayrullin wrote:
> Some other issue with space between label and wire:
Yes, text sizing and spacing is one of the darker areas. Eeschema,
Cairo, Pango, and XFig each have own ideas about fonts and how
they are to be rendered, and many details aren't really documented.
If you look at the
is based on the previous one that added missing
parentheses.
- Werner
commit 3e0c715315ea46881d5be7a72c6daafd41360b52
Author: Werner Almesberger <wer...@almesberger.net>
Date: Thu Sep 8 15:44:41 2016 -0300
template/pagelayout_default.kicad_wks: synchronize with defaultPageLayout
..
c4a3b851729b4e1727221bc73d8ace642ebcb3b6
Author: Werner Almesberger <wer...@almesberger.net>
Date: Thu Sep 8 15:37:33 2016 -0300
template/pagelayout_{default,logo}.kicad_wks: add missing opening parentheses
diff --git a/template/pagelayout_default.kicad_wks b/template/pagelayout_default.kic
Roman Pavelka wrote:
> Tested on Fedora 24 on two bigger projects, no problems at all.
Great ! Added the Fedora prerequisites to the build instructions.
Thanks a lot !
- Werner
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
Eldar Khayrullin wrote:
> Does eeshow watch to User defined search path?
Ah yes, I hadn't implemented this. Now searching LibDir and the
default paths from common/gestfich.cpp:KicadDatasPath should work,
too.
The searching can be a bit too optimistic: if you've deleted or
moved a file, eeshow
19 matches
Mail list logo
