On 02/24/2012 08:54 AM, Miguel Angel Ajo Pelayo wrote:
Ok, I changed the topic of this thread, to match the discussion, which
is about making Kicad fully scriptable in Javascript.
For speed reasons, and wide adoption, it seems that V8 must be
our preferred engine.
Hi Miguel,
Did you
On 10/08/2012 12:26 PM, Lorenzo Marcantonio wrote:
What would worry me is that an image of that kind would be probably
*huge* especially if at high resolution. Blitting it efficiently could
be tricky...
Assuming that Kicad will have an OpenGL drawing engine sometime, this
will not be a
On 12/13/2012 08:58 PM, Pinault Nicolas wrote:
Le 13/12/2012 20:33, Dick Hollenbeck a écrit :
On 12/13/2012 01:00 PM, Kaspar Bumke wrote:
In the .sch files the lines look like this
EESchema Schematic File Version 2 date Tue 11 Dec 2012 20:41:50 GMT
and
Date 11 dec 2012
I am pretty sure
On 04/12/2013 02:23 PM, Wayne Stambaugh wrote:
On 4/12/2013 1:28 AM, Lorenzo Marcantonio wrote:
On Thu, Apr 11, 2013 at 04:11:51PM -0500, Dick Hollenbeck wrote:
No, I don't agree, since it is behind an interface and only accessors
use it.
My question could be rephrased as: there is a need
On 04/12/2013 02:26 PM, Adam Wolf wrote:
CERN folks, I'd be glad to talk about #7 on your roadmap and see if
there's anything I/Wayne and Layne can do to help the situation.
Hi Adam,
This is great news!
The proposal we discussed with the main devs some time ago is to first
turn Kicad apps
On 04/16/2013 12:37 PM, Fabrizio Tappero wrote:
Hi there,
an other possible layer toolbar a little less colourful.
Hi Fabrizio,
Here's my 5 cents (sorry for quality of the drawing, it's just a quick
sketch). The idea is based on your proposal, with some extra stuff added:
- wide narrow mode
On 04/26/2013 04:08 PM, Simon Huwyler wrote:
One more thing: I agree that the additional numbers may confuse a bit.
So, why not just insert a check box named: Use layer based constraints?
Hi Simon,
I agree that such constraints are very useful, I use them frequently in
Altium, but this is
both is a python object that is visible to C++ that is stuffed at each distance
test point
in the DRC? At least one of the two members would need to be updated on each
compare.
Hi Dick,
I'm not sure, it might be the case if a single matching expression
refers to both items. A crude
On 04/29/2013 09:51 PM, Lorenzo Marcantonio wrote:
On Mon, Apr 29, 2013 at 09:03:32PM +0200, Tomasz Wlostowski wrote:
My 0.001 cent - It's much simpler: just don't use floating point.
That what's we try to do when possible, to avoid rounding issues and
have better numerical stability (more
On 05/01/2013 11:59 AM, Lorenzo Marcantonio wrote:
We talked about this the other day (when discussing the fully fixed
point implementation of the CERN geometric lib). I think that many
things with angle can't be 'detached' from floating point.
Hi Lorenzo,
Thanks for your analysis, I'll read
On 06/04/2013 09:44 PM, NHays Terrace wrote:
If pcbnew had direct support for rectangle flash objects outside of
modules, the mapping would be simple.
Hi Nate,
IMHO, adding new types of copper objects may be tricky - aside from just
drawing, you need to take care of DRC, hit testing,
On 06/04/2013 10:15 PM, Lorenzo Marcantonio wrote:
Generic grouping of objects is another common component of graphics
programs.
Too bad that pcbnew is a *pcb* program.
Lorenzo,
Too bad that Altium is also a PCB program, which happens to support
grouping objects. Imagine moving a big BGA
Hello,
Thanks to Orson, Camille, Vesa and others we now have the cool and
lightning-fast GAL-driven graphics view in pcbnew. Now it's time to make
it do some real work, that means editing operations.
Since the GAL does not allow XOR rendering, some significant refactoring
of the editing
On 08/10/2013 03:27 PM, Dick Hollenbeck wrote:
On 08/02/2013 12:10 PM, Tomasz Wlostowski wrote:
There is a demo available (kicad-gal-orson branch), that shows a simple
selection tool (Go to Edit-Selection tool with the GAL view enabled).
It's not yet useful for any practical purposes and very
On 08/10/2013 04:28 PM, Lorenzo Marcantonio wrote:
On Sat, Aug 10, 2013 at 08:27:26AM -0500, Dick Hollenbeck wrote:
a) If tools are extended from a base class, the persistent behaviours could be
inherited.
b) If tools are pushed on a stack when they become active, and if you have a
On 08/10/2013 11:34 PM, Dick Hollenbeck wrote:
Tom,
The other thing about your work is that it is important, very important.
The push and shove router is something I could have used today. Whatever
confidence I
used to have in freerouter is gone. It is not working for me very well on this
On 08/11/2013 06:39 PM, Dick Hollenbeck wrote:
I think that these doubt should be cleared thinking on 'what about if we
could have two views on the same board' (which, incidentally, could be
a good feature in the far future)
That is a fairly fundamental decision, sort of like the decision
On 08/12/2013 03:46 PM, Dick Hollenbeck wrote:
On 08/12/2013 04:19 AM, Tomasz Wlostowski wrote:
http://docs.wxwidgets.org/trunk/classwx_evt_handler.html#a78719e8b82c9f9c6e4056b3449df1943
The Connect() method lets you connect wxEvtHandlers together. Seems like the
base tool
clase should
On 08/12/2013 05:41 PM, Lorenzo Marcantonio wrote:
On Mon, Aug 12, 2013 at 10:58:31AM +0200, Tomasz Wlostowski wrote:
Thanks :) I didn't want to impose any particular way of writing
these FSMs, every programmers has his/her own taste, so he's free to
choose between coroutines, state-as-method
On 08/12/2013 06:30 PM, Lorenzo Marcantonio wrote:
On Mon, Aug 12, 2013 at 05:48:59PM +0200, Tomasz Wlostowski wrote:
Initially, I though about using boost::coroutine, but almost got
scared to death after seeing the example code. Finally I used
Like, almost everything in boost... never seen
On 08/12/2013 06:24 PM, Lorenzo Marcantonio wrote:
Did you evaluate some spatial index for the speed issue? AFAIK r-trees
are already available in boost, k-d trees are not *too* much difficult
to implement (did it one time years ago, but for points, not bigger
entities... I don't remember if
On 08/12/2013 04:24 PM, Dick Hollenbeck wrote:
Unfortunately, I guess I am losing my hope that we have a unified vision.
We apparently do not.
The project is based on wx. The portions of wx that are objectionable, to me
are:
Dick, Wayne,
I said I'd prefer to not use wxEvtHandler for
On 08/13/2013 05:48 PM, Lorenzo Marcantonio wrote:
On Tue, Aug 13, 2013 at 07:14:05AM -0500, Dick Hollenbeck wrote:
If you ignore the context of application, then this is the same thing as
guessing that a
mechanic hates his 5mm wrench when he goes to loosen a 11mm nut.
I think it more than
On 08/13/2013 06:43 PM, Dick Hollenbeck wrote:
On 08/13/2013 10:58 AM, Tomasz Wlostowski wrote:
On 08/13/2013 05:48 PM, Lorenzo Marcantonio wrote:
On Tue, Aug 13, 2013 at 07:14:05AM -0500, Dick Hollenbeck wrote:
If you ignore the context of application, then this is the same thing
On 09/03/2013 02:24 PM, Lorenzo Marcantonio wrote:
On Tue, Sep 03, 2013 at 05:29:12AM -0600, Brian F. G. Bidulock wrote:
See my other note. Just remember what layers things are on instead
of messing around with bitmasks. So, when you place pin 1, you place
it in the cells occupied by its
On 09/03/2013 12:33 PM, Brian F. G. Bidulock wrote:
Lorenzo,
On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote:
On Tue, Sep 03, 2013 at 04:21:59AM -0600, Brian F. G. Bidulock wrote:
5000 module descriptions to extract the 5000 pieces of placement
data is the horror of kicad's internal
On 09/16/2013 09:21 AM, Miguel Angel wrote:
I have drafted a blueprint, on how we could implement a pluggable IO
modules.
_https://blueprints.launchpad.net/kicad/+spec/pluggable-file-io_
If you have a moment, please give it a read, and comment on this thread
or edit over the draft if you feel
On 09/16/2013 03:54 PM, Miguel Angel wrote:
It really seems like a wx/MACOSX related bug to me,
Miguel,
Welcome to the wonderful world of cross-platform compatibility of
wxWidgets. This is exactly why we (me Orson) don't want to use any
sort of wx events in new tools.
Cheers,
Tom
On 09/18/2013 09:48 PM, Miguel Angel wrote:
I can only say *awesome*.
Thanks :)
I supposed that you were kidding with the VB /
Comic Sans... but you left me suffering for a moment...
Just one question, what's the license for GAL/geometry/tool framework?.
GPL V2. Only the router
Dear all,
After a long period of exhausting development, many unslept nights,
deadlines shifted several times and hundreds of liters of coffee and
sweat, we are proud to publish the initial version of the native push
and shove router for Kicad.
Today's release wouldn't have been possible
On 09/18/2013 10:14 PM, Javier Serrano wrote:
On Wed, Sep 18, 2013 at 10:00 PM, Martijn Kuipers
martijn.kuip...@gmail.com mailto:martijn.kuip...@gmail.com wrote:
Awesome work!
On Sep 18, 2013, at 8:50 PM, Tomasz Wlostowski
tomasz.wlostow...@cern.ch mailto:tomasz.wlostow...@cern.ch
On 09/19/2013 04:29 PM, Miguel Angel wrote:
Ok, summarizing all the feedback:
I'd defer this blueprint proposal, and switch it into something like:
* Making a generic system wide plugin load system,
(load/unload/reload/enumerate/instantiate). Supporting statically
loaded C++ plugins, and
On 09/19/2013 04:31 PM, Miguel Angel wrote:
Clarification: making it generic means that we share the base class for
KICAD_PLUGINs and that we share the code for the manager.
Not that I intend to load pcbnew plugins into eeschema, or the other way
around.. which wouldn't have much sense.
How
On 09/19/2013 05:35 PM, Dick Hollenbeck wrote:
On 09/19/2013 09:29 AM, Miguel Angel wrote:
Ok, summarizing all the feedback:
I'd defer this blueprint proposal, and switch it into something like:
* Making a generic system wide plugin load system,
(load/unload/reload/enumerate/instantiate).
On 10/08/2013 02:20 PM, Thomas Spindler wrote:
Hi Guys,
I had to do some tricky mechanical design around a pcb and generated a step
like file format. (See attached example)
If other users find it useful I will eventually integrate it into 3d-viewer.
Hi Thomas,
Great work! Did you generate
On 10/14/2013 11:58 PM, Dick Hollenbeck wrote:
On Oct 14, 2013 4:50 PM, Dick Hollenbeck d...@softplc.com
mailto:d...@softplc.com wrote:
On Oct 14, 2013 4:45 PM, Brian Sidebotham
brian.sidebot...@gmail.com mailto:brian.sidebot...@gmail.com wrote:
On 14 October 2013 22:36, Dick
On 10/20/2013 05:20 PM, jp charras wrote:
No it is not fixed and it will be not fixed.
This bug happens only with GCC 4.7.0, GCC 4.7.1 and GCC 4.7.2.
The guy who is working on boost polygon is not able to fix it, and he is
thinking this is a GCC bug, not a boost bug.
Hi Jean-Pierre,
Sorry
On 10/30/2013 04:51 PM, Simon Turner wrote:
Hello
I found the kicad autorouter today. Not bad but is has ploughed through
pre-existing tracks causing a massive short. It also does not make the
most obvious choices in routing and tracks seem to be placed within the
clearance limits of pads so it
On 11/01/2013 12:40 AM, Lorenzo Marcantonio wrote:
On Thu, Oct 31, 2013 at 11:24:39PM +0100, Maciej Suminski wrote:
Regarding LAYER_NUMs, if all the code uses LAYER_NUMs, then I do not see a
point in changing that in the contributed part. Again, if you have ready
patches and main developers
On 11/06/2013 01:40 PM, Edwin van den Oetelaar wrote:
wonderful, it is great to have push and shove!
Now I have played with it, don't want to work without it.
Hi Edwin,
Nice to hear that this stuff is useful :)
It is not without problems yet, I get segfault when moving a track
sometimes.
On 11/07/2013 08:30 PM, Dick Hollenbeck wrote:
On 11/07/2013 01:03 PM, Maciej Sumiński wrote:
On 11/07/2013 07:11 PM, Dick Hollenbeck wrote:
On 11/07/2013 11:59 AM, Wayne Stambaugh wrote:
On 11/7/2013 12:36 PM, Maciej Sumiński wrote:
On 11/05/2013 07:40 PM, Wayne Stambaugh wrote:
On
On 11/18/2013 07:11 PM, Lorenzo Marcantonio wrote:
On Mon, Nov 18, 2013 at 11:25:16AM -0600, Dick Hollenbeck wrote:
I find KiCad barely useable. I am in no way satisfied with KiCad. In my view
it is
however making progress, although more like 3 steps forward and 1 step back.
I do not agree
On 01/08/2014 04:39 PM, jp charras wrote:
Tracks do not store the net name but just the net code, because they are
expected to be connected to pads which store this info.
(this is the reason tracks and vias not connected to a pad lose their
net after loading a board, or reading a netlist)
On 01/15/2014 01:27 AM, Cirilo Bernardo wrote:
Hi folks,
I believe we can accommodate various types of 3D models with minimal
changes to the code base. Specifically, small changes to the class
S3D_MASTER and the GUI for associating 3D parts. I propose that we
allow the inclusion of other model
On 02/04/2014 12:57 PM, Brian Sidebotham wrote:
I suspect it's all just a documentation issue too as someone else
suggested because it's so easy to branch the code and generate a patch
using Bazaar.
Perhaps the best place for anyone who has decided Bazaar is dead (it
works for me by the way!)
On 02/06/2014 12:17 AM, Fabrizio Tappero wrote:
Dear Jean-Pierre,
since I believe you have not yet committed my previous icon patch,
please neglect it and used instead this new set. I have added few new ones.
Hi Fabrizio,
Great work! Would you be able to make one more icon for the PS router?
On 02/12/2014 09:34 AM, Henner Zeller wrote:
Hi,
Choosing components in the schematics editor is very cumbersome right now.
(...)
So I sat down and thought about how it _should_ be.
This is what I came up with, see patch:
- interactive search-as-you-type
Hi Henner,
I just compiled
On 02/13/2014 12:02 AM, Cirilo Bernardo wrote:
- Original Message -
From: Tomasz Wlostowski tomasz.wlostow...@cern.ch
To: Henner Zeller h.zel...@acm.org; KiCad Developers
kicad-developers@lists.launchpad.net
Cc:
Sent: Thursday, February 13, 2014 9:54 AM
Subject: Re: [Kicad-developers
On 02/15/2014 08:27 PM, Lorenzo Marcantonio wrote:
A more practical development issue: how you will handle the libcommon
which uses different internal units for each program (nano for pcbnews,
mils for eeschema and I don't remember gerbview)?
I guess it would be nice of somebody volunteers to
On 02/18/2014 08:40 AM, Henner Zeller wrote:
Hi,
This is an update patch to the new component chooser containing the
planned followup-change to display a mini-preview of the component.
Clicking on that box opens the 'big' component browser (Also fixes
[Bug 1280567]). (Since we already can
On 02/18/2014 08:28 PM, Wayne Stambaugh wrote:
On 2/18/2014 12:22 PM, Henner Zeller wrote:
I agree with your assessment about EDA_DRAW_PANEL being decoupled from
the frame window. My guess is that would be quite a significant
undertaking given the current design. If this is something you
On 02/19/2014 12:01 AM, Henner Zeller wrote:
On 18 February 2014 14:51, Tomasz Wlostowski tomasz.wlostow...@cern.ch wrote:
On 02/18/2014 08:28 PM, Wayne Stambaugh wrote:
On 2/18/2014 12:22 PM, Henner Zeller wrote:
I agree with your assessment about EDA_DRAW_PANEL being decoupled from
On 03/12/2014 05:57 PM, Dick Hollenbeck wrote:
On 03/12/2014 11:28 AM, David Novak wrote:
When building Pcbnew, I get an error message indicating that strtok_r is
being redefined. The offending code is in kicad_string.h.
#ifndef HAVE_STRTOKR
// common/strtok_r.c optionally:
extern C char*
On 03/14/2014 03:33 PM, Wayne Stambaugh wrote:
On 03/14/2014 10:24 AM, Adam Wolf wrote:
Hi folks,
I heartily agree with this. I've been trying to show some Kicad users
how to use new features in Kicad, and environment variables is turning
out to be a real turn-off for many of them.
That's a
On 04/03/2014 10:30 PM, Jean-Samuel Reynaud wrote:
Hi all,
Please find attached a quick view of 3 possibles frame on wxpython
project manager.
I'm not a specialist of ergonomics/design but it is some ideas I have.
Hi Jean-Samuel,
Nice try, I vote for option #2.
Have a look at this page:
On 25.04.2014 23:44, Lorenzo Marcantonio wrote:
On Fri, Apr 25, 2014 at 03:18:51PM -0500, inkblotter wrote:
algorithms; imagine a graph of all the nets and pads; sort of a live
netlist, with built in search and visiting algorithms. If I wasn't already
The 'live' thing could be a big problem;
On 06.05.2014 20:28, John Beard wrote:
I think it would be a good idea to allow unknown fields in the
s-expression formats so that an older KiCad doesn't choke on things it
doesn't understand, and doesn't need to.
For example, I was thinking that it might be helpful to add a field to
the
On 14.05.2014 22:08, Tomasz Wlostowski wrote:
Hi,
After even more coffee and sweat, we are proud to release an update the
PS router.
It looks like something ate the attachments. I temporarily placed the
example design and docs on Github:
https://github.com/twlostow/kicad-dev/tree/junk
On 19.05.2014 23:19, Edwin van den Oetelaar wrote:
Wow, just fantastic, I am so impressed it is hard to express!
Fantastic stuff. I have to show this to some friends now.
Greetings,
Edwin van den Oetelaar
Hi Edwin,
There is a manual available that explains the router modes and options:
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
On 04.06.2014 08:51, jp charras wrote:
Le 03/06/2014 19:27, Vesa Solonen a écrit :
While working on the footprint library convention, the lack of extended
mechanical and production aid layers got in the way. Why, how and
revealing pictures in [1].
We would like to get extended layers part
On 04.06.2014 13:59, Lorenzo Marcantonio wrote:
On Wed, Jun 04, 2014 at 12:13:42PM +0200, Tomasz Wlostowski wrote:
- board outline
PCB Edges, check.
- mounting/mechanical assembly holes
Drawings? check (...)
... 12 in total.
I'd say that would be two coupled pairs with behavious
On 04.06.2014 17:31, jp charras wrote:
Le 04/06/2014 12:13, Tomasz Wlostowski a écrit :
What would be the issue to add them to the sexpr file formats, that are
meant to be extensible?
First of all, my response was related to the current work on footprint
libraries refactor.
Hi Jean-Pierre
On 04.06.2014 19:00, jp charras wrote:
Le 04/06/2014 18:07, Tomasz Wlostowski a écrit :
On 04.06.2014 17:31, jp charras wrote:
The team which works on libraries has its own mailing list:
kicad-lib-committ...@lists.launchpad.net
Thanks :)
We are very happy to hear that compatibility
On 04.06.2014 21:35, Wayne Stambaugh wrote:
On 6/4/2014 2:33 PM, Lorenzo Marcantonio wrote:
On Wed, Jun 04, 2014 at 02:20:12PM -0400, Wayne Stambaugh wrote:
user confusion. Where would you save them in the old kicad_pcb file
format after you made changes? If Pcbnew where a read only
On 04.06.2014 23:59, Lorenzo Marcantonio wrote:
On Wed, Jun 04, 2014 at 10:48:18PM +0200, Tomasz Wlostowski wrote:
# defines the layers paired with us. User layers can be also paired.
(pairs-with canonical-name)
)
I proposed to do pairing on tag name, this is a more complex solution
On 05.06.2014 02:48, Jean-Paul Louis wrote:
Lorenzo and all,
I see in your last very descriptive email, that the number of copper
layers seems to be limited to 16.
Does that mean that my 20 layers backplane will have to use 4 custom
layers that really will be copper. Will the routing of those
On 05.06.2014 15:50, Wayne Stambaugh wrote:
On 6/4/2014 4:48 PM, Tomasz Wlostowski wrote:
On 04.06.2014 21:35, Wayne Stambaugh wrote:
On 6/4/2014 2:33 PM, Lorenzo Marcantonio wrote:
On Wed, Jun 04, 2014 at 02:20:12PM -0400, Wayne Stambaugh wrote:
user confusion. Where would you save them
On 05.06.2014 20:58, Matthew Berggren wrote:
Hi Folks,
Just jumping in and saying hi and letting you know I'm looking forward
to lending a hand. Spent the last ~15 years building, selling and
implementing closed-source desktop Schematic / PCB tools (at PCAD and
later Altium) and having left
On 06.06.2014 00:58, Cirilo Bernardo wrote:
I remember your earlier work with importing STEP model data for the VRML
viewer. My opinion on using STEP models + 3D view is that we should use
a separate tool for that job. This avoids adding yet another monstrous
dependency to KiCad (OpenCascade)
On 06.06.2014 07:57, Lorenzo Marcantonio wrote:
On Fri, Jun 06, 2014 at 01:15:28AM +0200, Tomasz Wlostowski wrote:
I can't agree here. One of the main reasons why we did the PS router was
lack of quality interactive router *integrated* in Kicad. We'd like to
achieve the same with STEP support
On 10.06.2014 15:22, Lorenzo Marcantonio wrote:
On Tue, Jun 10, 2014 at 08:15:44AM -0500, Dick Hollenbeck wrote:
I think we need to save that footprint in the PROJECT. Maybe put it there upon
wxFrame
destruction, and go get it upon wxFrame creation. That makes it project
specific.
On 10.06.2014 16:40, Dick Hollenbeck wrote:
I clicked send, replying to Lorenzo's comment right when your next
e-mail came. Sorry for that,
Thanks Tom, apology accepted.
Another thing we get by supporting multiple open projects and paste, is we are
only one
step away (i.e. COPY) from
On 11.06.2014 07:30, Dick Hollenbeck wrote:
On 06/10/2014 04:39 PM, Tomasz Wlostowski wrote:
On 10.06.2014 16:40, Dick Hollenbeck wrote:
I clicked send, replying to Lorenzo's comment right when your next
e-mail came. Sorry for that,
Thanks Tom, apology accepted.
Another thing we get
On 27.06.2014 17:13, Dick Hollenbeck wrote:
Jason,
Likely it will work without python.
Likely the _pcbnew.kiface cannot be loaded because something it needs cannot be
found.
While same path is used to find _pcbnew.kiface from kicad.exe, the technique
used to
load _pcbnew.kiface is done by
On 01.07.2014 17:16, Dick Hollenbeck wrote:
On 06/30/2014 02:34 PM, Javier Serrano wrote:
On Mon, Jun 30, 2014 at 7:48 PM, Lorenzo Marcantonio
l.marcanto...@logossrl.com
wrote:
I see the commits. Could have be useful to know before since both me and the
cern
people were already working on
On 11.07.2014 19:20, Dick Hollenbeck wrote:
In any case I think the CERN roadmap description for back annotation is over
designed.
There are simpler ways to handle this than the ECO described in that writeup.
I would recommend that this item be scrapped and simplified.
Dick,
I assume you
On 14.07.2014 11:55, Lorenzo Marcantonio wrote:
- eeschema writes netlist and reads netlist (detecting and incorporating
changes)
- cvpcb read netlist and write netlist (simply changes attributes)
- pcbnew read netlist and write netlist (saves its current states with
changes)
Lorenzo,
On 14.07.2014 13:53, Lorenzo Marcantonio wrote:
On Mon, Jul 14, 2014 at 01:12:48PM +0200, Tomasz Wlostowski wrote:
^^ all of this could be likely done by the same piece of code, that simply
compares the two netlists and generates the differences. This part is
generic. The way the differences
need much less information than what is stored
in them. That IMHO justifies the need for a generic NETLIST class,
understandable by both eeschema and pcbnew.
Cheers,
Tom
My $0.02,
Jean-Paul
AC9GH
On Jul 14, 2014, at 3:49 PM, Tomasz Wlostowski tomasz.wlostow...@cern.ch
wrote
On 15.07.2014 13:48, Andrew Zonenberg wrote:
Created a new module in the GAL module editor and made a pad, immediate
segfault. I think I was trying to open the pad properties when it
happened.
Using BZR 4996-product on Debian 7 amd64. I've saved a core dump
(/tmp/core.1386 on my machine... 682
On 15.07.2014 15:10, Andrew Zonenberg wrote:
If you're using wx 2.8 (same as me) Orson has managed to come up with a
reproducible test case and is investigating.
News from Orson: it looks like the order of redraw/canvas resize events
differs between wx versions (in 2.8 the compositor was
On 16.07.2014 11:01, Lorenzo Marcantonio wrote:
On Wed, Jul 16, 2014 at 10:33:06AM +0200, Maciej Sumiński wrote:
Are not they added as DRAWSEGMENTs on copper layers? I am willing to bet
that it is not handled by DRC.
I'm not accepting that bet :D
Why the track are not subclasses of segments
On 22.07.2014 17:32, Andrew Zonenberg wrote:
I've found three problems so far:
1) Pressing the insert blind via key when using the push-and-shove
router does not actually add a blind via.
2) In both avoid and shove mode, the router treats blind vias as
through-board vias and will move or avoid
On 22.07.2014 20:12, Andrew Zonenberg wrote:
The current code in the repo would silently convert all vias to standard
through-hole vias, my code makes it behave properly for blind/buried
vias. With some additional modifications it could support microvias too
but I haven't implemented that.
Hi
On 30.07.2014 12:03, Mário Luzeiro wrote:
Thank you for add it Jean-Pierre !
I will now be able to do some more improvements and take it from your revision.
I hope now more people can test it, special, openGL compatibility with older
systems and model files correctness parsing and rendering.
On 02.08.2014 20:30, Andrew Zonenberg wrote:
The attached patch parallelizes per-vertex normal calculation using
OpenMP. I see a nearly 4x speedup of model loading on my quad-core
machine.
Hi Andrew,
Caching the meshes including normals on disk could speed up loading even
further:
- take
On 20.08.2014 14:44, yann jautard wrote:
just FYI, 5084 does not compile any more.
void DIALOG_MODULE_BOARD_EDITOR::OnCancelClick( wxCommandEvent event )
{
TREE
EndQuasiModal( -1 );
===
ENDQUASIMODAL( -1 );
MERGE-SOURCE
}
Hi guys,
Sorry for asking dumb questions, but what is
Dear all,
We are planning to introduce some improvements to the PS router before
the first lightweight stable release of Kicad comes out. Here's are the
things we'd like to get done by the end of November:
1) Length tuning tool
An automatic tool generating accordions/meanders on a chosen
On 18.09.2014 23:12, Wayne Stambaugh wrote:
On 9/18/2014 12:04 PM, Tomasz Wlostowski wrote:
I assuming you are going to include the documentation for the new PS
router features as well since it is (or at least should be ) a
requirement for a stable release. Looks like interesting times ahead
On 18.09.2014 23:16, Wayne Stambaugh wrote:
On 9/18/2014 4:42 PM, Cirilo Bernardo wrote:
- Original Message -
From: Tomasz Wlostowski tomasz.wlostow...@cern.ch
To: Kicad Developers kicad-developers@lists.launchpad.net
Cc:
Sent: Friday, September 19, 2014 2:04 AM
Subject: [Kicad
On 22.09.2014 02:16, Andrew Zonenberg wrote:
Looks like the issue I mentioned previously is indeed a bug. The
attached patch fixes it and provides full support for
blind/buried/microvias in GAL.
Hi Andrew,
Thanks for the patch, We'll merge it with my changes improving layer
switching and
On 08.10.2014 15:36, Adam Wolf wrote:
Hi folks,'
This is something I was asked yesterday and I don't know the answer. Is
there a way to tell KiCad to compile for software rendering only, or do
we have a hard dependency on GPUs now?
I checked
On 20.10.2014 17:25, Marco Ciampa wrote:
On Mon, Oct 20, 2014 at 08:47:54AM -0400, Carl Poirier wrote:
I feel like we wouldn't use the last digit much in a triplet number
because, IIRC, backporting of fixes is not planned. That being said, I
would also begin with at least 2.1, as Cirilo said.
On 28.11.2014 14:54, Wayne Stambaugh wrote:
On 11/27/2014 12:44 PM, Tomasz Wlostowski wrote:
On 27.11.2014 17:18, jp charras wrote:
Le 27/11/2014 12:22, Torsten Hüter a écrit :
Hi Jean-Pierre,
Currently this in not the case in Pcbnew.
This is acceptable for microwave applications, which
Dear Kicad Devs,
I'm looking for a wx widget class implementing a transparent
always-on-top window that follows mouse cursor (like in the attached
drawing). The window will be used for displaying the current track
length/impedance/phase skew when routing/tuning (or any other information).
If
On 01.12.2014 16:41, Wayne Stambaugh wrote:
Hey Tom,
The closest thing I've seen to what you are looking for are the advanced
tooltip classes in the wxPython demo. Although none of them is what you
are looking for. What about using the message panel to show the matched
pair information
On 04.02.2015 17:15, Bob Gustafson wrote:
I can actually *see* footprints !! Thanks much.
Now, if I could get them to stick to the pcb, that would even be better.
Did you mean all you need to do now is to solder the components to your PCB?
Cheers,
Tom
, Tomasz Wlostowski
tomasz.wlostow...@cern.ch (mailto:tomasz.wlostow...@cern.ch) wrote:
On 13.01.2015 20:11, Wayne Stambaugh wrote:
This is a tricky issue that has been discussed before. The general
consensus in the past has been not to support forward compatibility. It
increases maintenance
On 20.01.2015 18:42, Wayne Stambaugh wrote:
On 1/20/2015 11:04 AM, LordBlick wrote:
In response to a message written on 20.01.2015, 16:19, from Wayne
Stambaugh:
I think that may be sufficient to add section [gal] to .pro file as
usual
project setting. In this way you can avoid the next
1 - 100 of 670 matches
Mail list logo
