Has anyone seen this?
https://misc.c4757p.com/dancing-posture.mp4
Known bug? It's really frustrating. No, I am not holding / there.
--
Chris
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Walk around.
On Mon, Jul 31, 2017 at 04:36:13PM +0200, Tomasz Wlostowski wrote:
> On 30.07.2017 19:31, Chris Pavlina wrote:
> > Has anyone seen this?
> >
> > https://misc.c4757p.com/dancing-posture.mp4
> >
> > Known bug? It's really frustrating. No, I am n
___
> 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
>From c69797f0d94d99f93
Yes
On Mon, Jul 31, 2017 at 12:27:37PM -0400, Wayne Stambaugh wrote:
> No problem. Is this patch against the stable 4 branch?
>
> On 7/31/2017 12:08 PM, Chris Pavlina wrote:
> > Wayne, while 4.0.7 is delayed again would you accept another small patch
> > (attached)? There a
Personally, I think your proposal sounds quite sensible, and I'm not
aware of any reason they _must_ be in a vector. Care to try it out and
see if it works?
On Tue, Aug 01, 2017 at 01:52:28AM +0530, Gaurav Juvekar wrote:
> Hi all,
>
> I was just playing around and found that the highlight net too
It's pretty difficult to get "real time" since the profiler significant
affects the timing. Personally I always use callgrind, with good
results.
On Tue, Aug 01, 2017 at 09:20:02PM +0530, Gaurav Juvekar wrote:
> Hi,
>
> > Personally, I think your proposal sounds quite sensible, and I'm not
> > aw
Hi,
Is someone still working on import/export for color schemes? This is
something I'd really like to have in 5.0 since we have the full RGB
colors now - if nobody is working on that anymore I might add it to my
list.
--
Chris
___
Mailing list: https:
masz Wlostowski wrote:
> On 19.08.2017 18:12, Chris Pavlina wrote:
> > Hi,
> >
> > Is someone still working on import/export for color schemes? This is
> > something I'd really like to have in 5.0 since we have the full RGB
> > colors now - if nobody is working on
Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
> > On 19.08.2017 18:12, Chris Pavlina wrote:
> > > Hi,
> > >
> > > Is someone still working on import/export for color schemes? This is
> > > something I'd really like to have in 5
Hello,
Here is a patch for eeschema that adds "Reset existing annotation, but do not swap
any units" to eeschema. This first compiles a list of multi-unit parts and all of
the components that comprise them, and then on annotation, annotates all of them as a
group. For example, if components we
In pcbnew, if you exit with a new (totally unsaved, but not empty) board
open, and click 'yes' in the save-on-exit box, an error is raised due to
passing an empty filename string to the save routine. Correct behavior
is to execute a 'save as' if the filename is still blank.
Attached is a patch
When the Hotkeys List was changed to non-modal, its OnCloseButtonClick()
was not changed to reflect the fact that modal and modeless dialogs have
to be closed differently in wx. Here's a patch to fix that, which should
work for all HTML_MESSAGE_BOXes whether or not they're modal.
Chris
diff -
Relatively simple proposals:
1. Rename 'copy' to 'duplicate' in eeschema to match pcbnew.
2. Rename 'save' to 'copy' in eeschema to match traditional usage.
3. Add default Ctrl-V keybinding to eeschema for 'paste' to match traditional
usage.
4. Add 'cut' to eeschema, on Ctrl-X:
- This differs
Ah, thank you for having a look. Yes, I clearly missed this use case.
D'oh...
I'll submit a new patch in a couple days that handles this. Any interest
in including it if I get it working properly?
Chris
On Sat, Mar 21, 2015 at 04:44:43PM +0100, jp charras wrote:
Thank for your contribution
Here is a fixed version of the patch. It handled perfectly any complex
hierarchies I could throw at it. Got anything worse to torture it with?
Chris
On Sat, Mar 21, 2015 at 04:44:43PM +0100, jp charras wrote:
Le 14/03/2015 00:11, Chris Pavlina a écrit :
Hello,
Here is a patch for eeschema
f anything else to test. I tried it on every combination
of hierarchical nastiness I could and it worked fine. Here's the latest
version, and final if you also can't think of anything else.
Thanks,
Chris
On Sun, Mar 22, 2015 at 04:06:57PM +0100, jp charras wrote:
Le 22/03/2015 03:18, C
Currently, if you try to edit the value of a power component in
eeschema, you get a "... is a power component and it's [sic] value
cannot be modified!" message. That message isn't completely accurate,
though. The edit box also allows you to change the *formatting*, which
is perfectly valid to
When loading an old schematic, it's fairly common for it to be broken,
if symbols have changed significantly in the libraries. An example:
https://i.imgur.com/7cVBneA.png
A workaround suggested by Wayne is to make a local copy of the
projname-cache.lib file, and add it to the project as a libr
n.
On Mon, Mar 23, 2015 at 11:52:48AM -0400, Chris Pavlina wrote:
When loading an old schematic, it's fairly common for it to be broken, if
symbols have changed significantly in the libraries. An example:
https://i.imgur.com/7cVBneA.png
A workaround suggested by Wayne is to make a lo
On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote:
On 3/23/2015 12:12 PM, Chris Pavlina wrote:
I like your idea - I proposed it myself, but it was not well received ;)
[[snip]]
Please see the discussion here on why this will not work.
https://bugs.launchpad.net/kicad/+bug
KiCad does not currently support standalone vias, and I think that would
be a necessity before a *clean* implementation of this could be done.
The only other options are to either place a /footprint/ as a via
(nasty), or place a web of traces along with the vias (terribly,
horribly filthy).
T
Any more thoughts on this from any other devs? If nobody objects, I
think I'll get started coding this up in the next day or so.
--
Chris
On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote:
On 3/23/2015 1:16 PM, Chris Pavlina wrote:
On Mon, Mar 23, 2015 at 01:07:33PM
Well, that was kind of the point - a stopgap for now, to keep the
current way the symbols were handled from confusing people too much. I
planned for it to become obsolete :D
On Mon, Mar 30, 2015 at 05:55:34PM +0200, Tomasz Wlostowski wrote:
On 30.03.2015 17:43, Chris Pavlina wrote:
[snip
ema documentation at
> https://github.com/ciampix/kicad-doc or have someone document it for
> you. What say the rest of you?
Yup, plan was to see it through. I'll document it as well - just let me get
these fixes implemented first.
> On 3/30/2015 11:43 AM, Chris Pavlina wrote:
&g
Does anyone know why kicad-install.sh does this?
for p in ${prerequisite_list}
do
sudo apt-get install $p || exit 1
done
Rather than something along the lines of this:
echo "${prerequisite_list}" | xargs -d"\n" sudo apt-get install
The long prompts for permission to install each package ha
134.html
2015-04-01 9:53 GMT+02:00 Nick Østergaard :
Search the mailing list archive. Try to also use the keyword fedora when
searching. I am currently not on a proper machine.
Den 01/04/2015 01.48 skrev "Chris Pavlina" :
Does anyone know why kicad-install.sh does this?
for p in ${pre
That's just part of the authentic Clippy experience!
On Thu, Apr 02, 2015 at 12:30:00AM +0200, Nick Østergaard wrote:
Noticed the commit and built it, but I was never able to run it. It
segfaulted for me. :(
2015-04-01 22:55 GMT+02:00 Wayne Stambaugh :
I can't believe no one commented on this
it. I've got git-bisect
compiles running in the background as I type.
On Fri, Apr 10, 2015 at 07:15:00PM -0400, Wayne Stambaugh wrote:
On 4/8/2015 8:48 PM, Chris Pavlina wrote:
Any more devs have an opinion on this?
I've already said it would be a good idea albeit a temporary o
The logical flow of the Text Properties dialog in pcbnew is vertical, not horizontal, but the wx
grid control naturally arranges the widgets horizontally and the tab order follows that. This means
that after "Size X", [tab] moves to "Position X", which is unlikely to be the
next desired control
Any more devs have an opinion on this?
On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote:
On 3/30/2015 1:58 PM, Chris Pavlina wrote:
On Mar 30, 2015 1:49 PM, "Wayne Stambaugh" mailto:stambau...@gmail.com>> wrote:
Please fix your coding style issues. I saw
The User Grid dimension dialog in the footprint editor is missing the calls to
update the grid in GAL, so the user grid doesn't update until you switch to a
different grid and back. Here's a patch.
Chris Pavlina
(Ref. bug #1426098: https://bugs.launchpad.net/kicad/+bug/1426098)
di
Tiny little bug in eeschema: when you set the height of a sheet pin text, it
actually sets the width, and vice versa.
diff --git a/eeschema/sheetlab.cpp b/eeschema/sheetlab.cpp
index 9f90792..8a10319 100644
--- a/eeschema/sheetlab.cpp
+++ b/eeschema/sheetlab.cpp
@@ -94,8 +94,8 @@ int SCH_EDIT_FR
When I submitted the patch to allow editing power component value text
properties, I didn't realize that the edit dialog base class was
subclassed /twice/ - I missed a required edit to the libedit subclass of
it, so the "Power component value text cannot be modified!" warning is
not properly hi
after populating the control before the dialog is shown.
There are examples of this in other kicad dialogs.
* Everyone please test this thoroughly if you have any old schematics so
we can be sure it's robust enough for the stable release.
Thanks,
Wayne
On 4/12/2015 1:57 PM, Chris Pavlina wro
Here's a patch that fixes a few minor coding style issues with lib-cache-rescue.
--
Chris
commit 18380f35788821b508c4a01a420f67d17eea4d37
Author: Chris Pavlina
Date: Sun May 3 12:26:55 2015 -0400
Fix coding style
Add space inside parentheses
diff --git a/eeschema/di
Here's a patch that sets the 'OK' button as default in the rescue dialog.
--
Chris
commit 028e30fb7d422ae2d1aa2a6bcd60c4962e7385e9
Author: Chris Pavlina
Date: Sun May 3 12:37:50 2015 -0400
Set default button in rescue dialog
diff --git a/eeschema/dialogs/dialog_re
(version Jun 5 2014)
+// C++ code generated with wxFormBuilder (version Mar 13 2015)
// http://www.wxformbuilder.org/
//
// PLEASE DO "NOT" EDIT THIS FILE!
diff --git a/eeschema/dialogs/dialog_rescue_summary.cpp b/eeschema/dialogs/dialog_rescue_summary.cpp
deleted file mode 100644
index cd68ed2..0
People recognize icons quickly by their silhouettes. This is already pretty hard with the
existing KiCad icon set, and you're making it harder, by making so many icons into a
"symbol on top of paper". I agree that the icons need work, but we've got to
keep good UI design practices in mind while
verify the component orientation against the rescued
library is correct. I'll commit this patch. If you find a bug, please
apply the patch against this patch.
Thanks,
Wayne
On 5/4/2015 1:30 PM, Chris Pavlina wrote:
I've got two changes here - they're a bit inadvertently inter
7 AM, Maciej Sumiński wrote:
Is it possible the problem is related to the recent diode pin swapping
in KiCad library?
Regards,
Orson
On 05/13/2015 05:35 PM, Chris Pavlina wrote:
Hi Wayne,
That's interesting. I can't really imagine what would cause that, and I
haven't seen anythin
and positions never changed. Here's a quick patch to
check the names too, so it'll pick up on A->K and fix diode symbols.
--
Chris
commit c2431899809769f2d0cd48d60c60b15c31a7deb9
Author: Chris Pavlina
Date: Sun May 24 11:10:01 2015 -0400
Correct symbol rescue - check pin names
Is there any real, important reason eeschema likes to go through and re-hide
references to which a # has been prefixed? As far as I know, this is done to
ensure power symbols don't have a visible reference, but those can be hidden
from libedit anyway. It's a bit annoying - I have a sheet which
-edit
the file, so I also edited the error message that is displayed to make it
perhaps a bit more helpful.
--
Chris
commit 779ab9528dc86fe16ccd4c411aa10ca04ef144d4
Author: Chris Pavlina
Date: Tue May 26 10:26:10 2015 -0400
Eliminate "PAD has no layer" warning for valid pads
Anyone have any thoughts on this? https://bugs.launchpad.net/kicad/+bug/1458083
I'm rather liking the idea of making it a bit clearer to a casual observer
whether or not a pin has been properly connected; wouldn't mind implementing
something like that. So, how would you prefer to see it?
--
Ch
Anyone notice this patch? It's rather imporant to maintain backwards
compatibility with old projects and the new libs.
--
Chris
On Sun, May 24, 2015 at 11:14:21AM -0400, Chris Pavlina wrote:
I originally didn't make lib-cache-rescue check pin names when testing whether a
symbo
Hi,
I've been having a look through some of the file I/O code in pcbnew, and I'm not really
comfortable with it. Despite the nice new structured s-exp format, we're still printing
data out by hand and parsing it back in similarly - rather a recipe for trouble, and at
least for inconsistent fil
I built using clang to see if that compiler would pick up any useful
warnings that gcc isn't. A few were, so I fixed them. You might not want
to apply this patch directly - it also "fixes" a few things that aren't
really problems, not sure if you'd rather leave them than hush up the
compiler. F
what changes you are
> proposing before I would be willing to give you the go ahead.
>
> Cheers,
>
> Wayne
>
> On 6/1/2015 12:29 AM, Chris Pavlina wrote:
> > Hi,
> >
> > I've been having a look through some of the file I/O code in pcbnew, and
> > I&
In GAL, an assertion (drawing_tool.cpp:925) will fail if you begin
drawing an arc, and then accidentally terminate the arc at zero angle
with the cursor /outside/ the arc radius. It seems that an attempt was
made to check for this but the conditional wasn't written quite right.
Here's a patch t
ards,
Orson
On 06/02/2015 05:44 PM, Chris Pavlina wrote:
In GAL, an assertion (drawing_tool.cpp:925) will fail if you begin
drawing an arc, and then accidentally terminate the arc at zero angle
with the cursor /outside/ the arc radius. It seems that an attempt was
made to check for this but the con
target after the connection is made) was best. Here's a
patch to do this.
IMO it makes the schematic look a lot cleaner in addition to helping
make sure the schematic is connected correctly :)
--
Chris
commit ecbf90b995f609c5eab550e9941d4d8ed27ce2ed
Author: Chris Pavlina
Date: Thu Jun 4
The assignment of footprints to schematic symbols is largely a KiCad
quirk. Many other tools consider a component to be a single package
containing symbol and footprint. In my own library I have a part per
actual electronic part (one called MMBT3904, for instance), which
already has the Footpri
On Fri, Jun 05, 2015 at 02:31:06PM -0400, Wayne Stambaugh wrote:
> On 6/5/2015 2:00 PM, Andy Peters wrote:
> >
> > *snip *
>
> *snip* Trying to provide a fully defined symbol
> for every transistor would be a huge under taking. Our solution may not
> be ideal but I'm not sure I want to sift thro
Thank you for saying this - op amps are the perfect example of why
relying on standard pinouts is a *terrible* idea!
Let's look at a few eight-pin DIP/SOIC/TSSOP dual op amps, shall we?
TL072? out in- in+ v- in+ in- out v+
LM358? out in- in+ v- in+ in- out v+
MC33078?out in- in+ v-
more immediately obvious
now that a part has been connected.
--
Chris
commit 175650781ec7dd5ec51f72bbeb8d6cf8c60677fc
Author: Chris Pavlina
Date: Sun Jun 7 15:18:27 2015 -0400
Refresh canvas after placing part to avoid graphic debris
diff --git a/eeschema/schframe.cpp b/eeschema/schfram
m not sure how much work
> would be involved. I'm surprised I never noticed that before or AFAIR
> no one has every said anything about it.
>
> On 6/4/2015 6:21 PM, Chris Pavlina wrote:
> > Recently a proposal was made on Launchpad for pins to indicate when they
> > are
If you try to load a kicad_pcb into pcbnew that refers to an invalid net
ID, pcbnew crashes after failing an assertion. It should display an
error indicating that the file is corrupt instead. I've changed
BOARD_CONNECTED_ITEM::SetNetCode() to be able to indicate whether the
code was valid, rath
commit e950b692b8985c1c5037999b3f6936f1d1c993d3
Author: Chris Pavlina
Date: Sun Jun 7 21:14:07 2015 -0400
Resolve clang overload conflict
diff --git a/eeschema/find.cpp b/eeschema/find.cpp
index 74801bf..2d4b55c 100644
--- a/eeschema/find.cpp
+++ b/eeschema/find.cpp
@@ -366,7 +366,7 @@ void
tch along with the refresh patch that
> goes along with it for now.
>
> On 6/7/2015 6:14 PM, Chris Pavlina wrote:
> > I could add this too.
> >
> > On Sun, Jun 07, 2015 at 05:44:09PM -0400, Wayne Stambaugh wrote:
> >> One thing I did notice is that bus entries
60617-3 allows a dotless junction (as in 03-02-06), but the same
connection can be represented with two 03-02-05; it is not a violation of
the standard to always use dots.
On Mon, Jun 08, 2015 at 08:48:12AM +0300, Vesa Solonen wrote:
> 08/06/15, 00:44, Wayne Stambaugh kirjoitti:
> > One thing I
een
>
> SCH_SHEET_LIST::GetSheet(const wxString, bool);
>
> and
>
> SCH_SHEET_LIST::GetSheet(int);
>
> How can these two definitions be ambiguous? Does using a reference to
> the wxString instead of passing the entire string on the stack fix the
> problem? If so, I w
user experience. If the goal is
> to make it obvious to the user (IMO a good thing) that a schematic
> connection is or is not made, then I would rather do what makes the best
> user experience rather than follow some standard generated by government
> body and/or committee.
>
n 6/8/2015 8:58 AM, Chris Pavlina wrote:
> > It can't and it shouldn't - gcc is the one at fault here. wxString
> > provides the constructor:
> >
> > wxString(char ch, size_t nRepeat=1)
> >
> > which is the one in question, I believe, as the integ
Nope, using a by-reference parameter does not appease clang; no idea about MSVC.
On Mon, Jun 08, 2015 at 09:15:16AM -0400, Wayne Stambaugh wrote:
> On 6/8/2015 8:58 AM, Chris Pavlina wrote:
> > It can't and it shouldn't - gcc is the one at fault here. wxString
> >
Yes, but "we" are not a small group, "we" are everybody who can
contribute. How can an open source project implement/follow a standard
when it can't make that standard available to its contributors?
On Mon, Jun 08, 2015 at 05:34:46PM +0300, Vesa Solonen wrote:
>
> I generally agree with both of
On Mon, Jun 08, 2015 at 11:28:08PM +0200, Heiko Rosemann wrote:
> > A given component should have exactly ONE available footprint. If
> > your opamp comes in PDIP-8 and SOIC-8, those are two different
> > components.
>
> Why? There's a good point for the opposite: Making different PCBs (SMD
> for
ris
commit a646e6c4b1a9ef624b4f56101d3a55f747558bf2
Author: Chris Pavlina
Date: Sun Jun 7 22:02:45 2015 -0400
Show targets on bus entries
diff --git a/eeschema/sch_bus_entry.cpp b/eeschema/sch_bus_entry.cpp
index 227f88a..6b3e3b6 100644
--- a/eeschema/sch_bus_entry.cpp
+++ b/eeschema/sch_bus_entry.cpp
@@ -35,6 +35,7 @@
#include
patch before I commit it?
>
> One other thing I noticed is the bus wires (and I'm guessing bus entries
> as well) do not have any segment end point connection indicators. It
> would be nice if they supported them as well.
>
> On 6/8/2015 5:38 PM, Chris Pavlina wrote:
> >
project is a
> good example of both behaviors. It's not that important but some users
> may wonder why the difference between wire and bus connections. It's
> something to think about.
>
> On 6/9/2015 2:30 PM, Chris Pavlina wrote:
> > I'm not sure about that
some improvement. Again, see
> the video demo. There are examples of both cases.
I don't see the problem, can you give me a more specific example?
>
> On 6/9/2015 3:24 PM, Chris Pavlina wrote:
> > No, I just mean things like this:
> >
> > http://misc.c4757p.com
nd test is in need of some improvement. Again, see
> the video demo. There are examples of both cases.
>
> On 6/9/2015 3:24 PM, Chris Pavlina wrote:
> > No, I just mean things like this:
> >
> > http://misc.c4757p.com/bus.png
> >
> > The bus is very freque
users will expect.
On Tue, Jun 09, 2015 at 07:44:37PM -0400, Wayne Stambaugh wrote:
> On 6/9/2015 4:45 PM, Chris Pavlina wrote:
> > Okay, I see what you're talking about in the video demo. Here's a quick
> > screenshot for those who want to follow along:
> >
> &
Bit of a bug in my pin target hiding code: junction dots on pins should
also hide the target. I forgot you can connect them that way.
http://misc.c4757p.com/target_hide_bug.png
This patch fixes that.
--
Chris
commit 7a5c65519bfa49ebc25a2c50c89d0f53ff2c86e4
Author: Chris Pavlina
Date: Wed
Recently I submitted a patch to catch an error that occurred when
loading a kicad_pcb containing invalid net IDs; I missed a couple spots.
Here's another patch to fix the rest of them.
--
Chris
commit 98126b8cfba53c52119f809b094cbae266b41b75
Author: Chris Pavlina
Date: Thu Jun 11 19:
There's a minor bug in lib_cache_rescue - if it fails to insert the new
library into the project, the error message for this is not displayed.
This patch adds the necessary ShowModal() call.
--
Chris
commit a2f938a9c25bf1273a9e7c8f8919a0e95b695ff3
Author: Chris Pavlina
Date: Sat Jun 13
wrt scripting and SWIG - SWIG's good for generating a low-level wrapper,
but if we'd like scripting to go anywhere, I really think we should come
up with a more scripting-friendly API and high-level wrapper. Something
with more proper iterables, fewer integer enums, fewer getters and
setters, o
Hi all,
I'm looking into prepopulating the list of BOM plugins in eeschema, and
further possibly cleaning up resource file access in general. Can I get
someone who's using kicad on Mac to run this script in the pcbnew Python
console to help me out a bit?
import wx; sp = wx.StandardPaths.Get()
ry,
> those are automatically checked by CI, and reported back to github.
>
> I haven't wrote any rules yet, but I really believe we should:
>
> 1) Document as we code
> 2) Write unit tests as we code
>
> So we avoid regressions and provide a very consistent API for
: Chris Pavlina
Date: Sun Jun 14 15:24:47 2015 -0400
Display pin targets while dragging components and bus entries
diff --git a/eeschema/sch_bus_entry.cpp b/eeschema/sch_bus_entry.cpp
index 6b3e3b6..b26d5d6 100644
--- a/eeschema/sch_bus_entry.cpp
+++ b/eeschema/sch_bus_entry.cpp
@@ -195,11
-
Chris
commit 6f3c07f0835898bb4cc022b45c586c4aecaef4b2
Author: Chris Pavlina
Date: Sun Jun 14 16:28:06 2015 -0400
Use new footprint selector for "Change Footprints"
diff --git a/pcbnew/xchgmod.cpp b/pcbnew/xchgmod.cpp
index 3ae43b8..a481419 100644
--- a/pcbnew/xchgmod.cpp
+++ b/pc
ear to the user that
a connection has not actually been made.
--
Chris
commit 04217c50d45ce0ed4e291c24e559da133aa4e181
Author: Chris Pavlina
Date: Mon Jun 15 11:05:25 2015 -0400
Show bus entry joining two wires as dangling
diff --git a/eeschema/sch_bus_entry.cpp b/eeschema/sch_bus_entry
On Mon, Jun 15, 2015 at 06:29:29PM +0200, jp charras wrote:
> [[snip]]
>
> keywords like UNDEFINED, INFO, WARNING , ERROR are widely used, the
> risk of collision is high.
> Usually I use something like:
> RPT_UNDEFINED, RPT_INFO , RPT_WARNING , RPT_ERROR
> to avoid this risk.
What about namespac
Can we Please, Please, Please stop using two different kinds of builds?
I can't even begin to describe how tiresome and infuriating it is to try
to help someone with a crash and find out that the backtraces are
completely useless. Especially with Heisenbugs that stop happening when
you get the
ma/autoplace_fields.cpp
new file mode 100644
index 000..a29ff1b
--- /dev/null
+++ b/eeschema/autoplace_fields.cpp
@@ -0,0 +1,256 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2015 Chris Pavlina
+ * Copyright (C) 2015 KiCad Devel
dd96f0dc6d831
Author: Chris Pavlina
Date: Tue Jun 16 11:36:51 2015 -0400
Workaround for autosave assertion failure
diff --git a/eeschema/files-io.cpp b/eeschema/files-io.cpp
index 4ef6572..39922f5 100644
--- a/eeschema/files-io.cpp
+++ b/eeschema/files-io.cpp
@@ -509,6 +509,9 @@ bool SCH_ED
is
commit c2a1607092013825312608a454f3861fd4b07547
Author: Chris Pavlina
Date: Tue Jun 16 17:59:28 2015 -0400
Preliminary fix for eeschema text bounding boxes
diff --git a/eeschema/class_libentry.cpp b/eeschema/class_libentry.cpp
index 2ba8989..81429c8 100644
--- a/eeschema/class_libentry.cpp
+++
this case) and move around some LIB_TEXT instances in a
component. The vertical axis is inverted, so that when you move the text
downwards, the bounding box grows upwards.
On Wed, Jun 17, 2015 at 05:35:43PM +0200, jp charras wrote:
> Le 17/06/2015 00:11, Chris Pavlina a écrit :
> > Hi
it a patch if there
really is a bug here, after I investigate further to figure out
/exactly/ what the problem is.
On Wed, Jun 17, 2015 at 06:29:56PM +0200, jp charras wrote:
> Le 17/06/2015 17:39, Chris Pavlina a écrit :
> > Yeah, I know that much - I'm just trying to figure ou
p charras wrote:
> Le 17/06/2015 17:39, Chris Pavlina a écrit :
> > Yeah, I know that much - I'm just trying to figure out where the
> > LIB_TEXT bounding boxes are going /wrong/. Try it - turn on the switch
> > to view the bounding boxes (sch_component.cpp line 382, reco
You probably saw my thread about the bounding boxes for LIB_TEXT and
LIB_FIELD, which were being merged with the main component bounding box
incorrectly. I tracked down what the bug was:
in ::GetBoundingBox(), the coordinates are inverted because "Y
coordinates for LIB_ITEMs are bottom to top".
ts in the schematic
+ * @param aRescuer - the active RESCUER instance
* @param aAskShowAgain - if true, a "Never Show Again" button will be included
*/
-int InvokeDialogRescueEach( SCH_EDIT_FRAME* aCaller, std::vector& aCandidates,
-std::vector& aComponents, bool
@ set( EESCHEMA_DLGS
)
set( EESCHEMA_SRCS
+autoplace_fields.cpp
annotate.cpp
backanno.cpp
block.cpp
diff --git a/eeschema/autoplace_fields.cpp b/eeschema/autoplace_fields.cpp
new file mode 100644
index 000..11ab31d
--- /dev/null
+++ b/eeschema/autoplace_fields.cpp
@
Oops, the same thing has to be applied in pcbnew. Patch attached.
On Thu, Jun 18, 2015 at 02:43:56PM -0400, Wayne Stambaugh wrote:
> Patch committed in product branch r5782. Thanks.
>
> On 6/16/2015 11:40 AM, Chris Pavlina wrote:
> > When eeschema attempts to autosave a schema
would
// represent maximum information hiding.
@@ -60,12 +59,10 @@ class SCH_EDIT_FRAME;
* This dialog asks the user which rescuable, cached parts he wants to rescue.
* Any rejects will be pruned from aCandidates.
* @param aCaller - the SCH_EDIT_FRAME calling this
- * @param aCandidates - the list of
ers who prefer using that
> instead. I promise you if we remove the footprint search dialog,
> someone will file a bug report about it shortly there after. :)
>
> Wayne
>
>
> On 6/18/2015 3:07 PM, Chris Pavlina wrote:
> > Hi all,
> >
> > It's
On Sat, Jun 20, 2015 at 09:14:14PM +0100, David J S Briscoe wrote:
> [snip] I'm afraid I will screw up the files on Github so probably
> better for me to do it the old fashioned way. Who can I send the edited
> files to?
If you do this, someone will have to convert them back to AsciiDoc *by
hand*
What is the license for the footprint libraries? These should probably
have a COPYING.txt in the individual repos - I'm sure I could find the
license if I searched around, but it should be right there.
___
Mailing list: https://launchpad.net/~kicad-de
No - I attached another in response to JP's recent mail about Coverity.
Here it is again:
Chris,
Is this patch good to go? I'm having trouble keeping up with the patch
volume so I want to make sure before I commit it.
Thanks,
Wayne
On 6/18/2015 3:07 PM, Chris Pavlina wrote:
> Hi
Since my recent change to hide dangling ends also responds to no-connect
markers, SCH_NO_CONNECT should be changed to correctly update dangling
ends after it is placed. This patch accomplishes that.
--
Chris
commit 32d30d6b24bc75bdfa300153d5e4430a15234456
Author: Chris Pavlina
Date: Mon Jun
Oh look, another stupid mistake. **hands in C++ card**
I'll get a patch in soon, working on fixing another bug right now. I see
the problem.
--
Chris
On Mon, Jun 22, 2015 at 12:35:35PM -0400, Wayne Stambaugh wrote:
> Chris,
>
> Would you please take a look at this when you get a chance?
>
> T
301 - 400 of 1122 matches
Mail list logo
