Jason,
The other thing to keep in mind is that you cannot mix C++ compilers within the
pcbnew
process. So if you are using wxPython, which was compiled with a particular
C++
toolchain, you have to keep using that same exact toolchain for the rest of
KiCad.
The same limitation does not
,
Jason
On Sun, Jul 13, 2014 at 11:41 AM, Dick Hollenbeck d...@softplc.com
mailto:d...@softplc.com wrote:
No idea.
I don't see the crash in the output. It would be prudent to have the
crash text and the
debug text in the same stream if possible, that way it might infer
On 07/10/2014 01:34 PM, Lorenzo Marcantonio wrote:
On Thu, Jul 10, 2014 at 11:14:22AM -0500, Dick Hollenbeck wrote:
That last sentence seems like an oxymoron to me. Implementing in C++ should
always be no
more difficult than the design. The design is where the thinking should
happen
On 07/14/2014 09:51 AM, Maciej Sumiński wrote:
Dear Developers,
After a period of testing, the module-editor branch [1] has just been
merged to the product branch. Besides the conversion of the module
editor to GAL, we have also:
- added a basic context menu to handle zones
- added support
On 07/14/2014 03:30 AM, Tomasz Wlostowski wrote:
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
On 07/14/2014 12:21 PM, Wayne Stambaugh wrote:
On 7/14/2014 12:46 PM, Dick Hollenbeck wrote:
On 07/14/2014 11:26 AM, Dick Hollenbeck wrote:
On 07/14/2014 10:37 AM, Wayne Stambaugh wrote:
On 7/14/2014 11:19 AM, Tomasz Wlostowski wrote:
On 14.07.2014 13:53, Lorenzo Marcantonio wrote:
On Mon
On 07/14/2014 12:47 PM, Dick Hollenbeck wrote:
On 07/14/2014 12:21 PM, Wayne Stambaugh wrote:
On 7/14/2014 12:46 PM, Dick Hollenbeck wrote:
On 07/14/2014 11:26 AM, Dick Hollenbeck wrote:
On 07/14/2014 10:37 AM, Wayne Stambaugh wrote:
On 7/14/2014 11:19 AM, Tomasz Wlostowski wrote
On 07/14/2014 03:12 PM, Jean-Paul Louis wrote:
To me, the netlist is one representation of the design.
The schematic is an electrical engineering view of the netlist,
The BOARD is the physical instance of the netlist.
So the BOARD needs to know about the net list for connectivity of the
I'm still intending to combine CVPCB and PCBNEW into the same *.kiface file.
That can be
interpreted as just one step closer to killing it off, if you want, I don't
have a stand
on that. I just see a lot of common code, and with the modular nature coming
into play,
it should be less
:
[addr=].
[bind=FA8006F43760] Binding reference count-- = 1.
[FA80077D90F0] WskKnrCompleteRequest: complete irp with IO status =
c272.
On Sun, Jul 6, 2014 at 11:54 AM, Dick Hollenbeck d...@softplc.com
mailto:d...@softplc.com wrote:
On 07/05/2014 08:23 PM
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.
Having travelled through a philosophical evolution during my career,
On 07/11/2014 12:20 PM, 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.
Having
On 07/09/2014 05:32 PM, NhatKhai wrote:
Hi,
During using KiCAD, I found clarify menu should slightly improve for
the level of filtering items, and double click action did not carryout
due to the LocateItem... function in OnLeftClick. And have code that can
improve this, but I like to see
On 07/10/2014 10:34 AM, Lorenzo Marcantonio wrote:
On Thu, Jul 10, 2014 at 05:22:20PM +0200, Michael Heidinger wrote:
Sure that is a solution for me, but not a solution for a production
software.
(Other users will be confused, that's why I report that bug)
It's a vry old issue, that of
-- Forwarded message --
From: *Dick Hollenbeck* d...@softplc.com mailto:d...@softplc.com
Date: Wed, Jul 9, 2014 at 3:34 PM
Subject: Re: [PATCH] Request to apply patch for redirect console output to
single file
To: Nhat Khai nhatk...@gmail.com mailto:nhatk...@gmail.com
On 07
On 07/09/2014 05:04 PM, Nhat Khai wrote:
Don't get me wrong here guys!
I try to no overload my console when running the app. All this patch do is
redirect the
text from console to a file. The wxLog frame work is still use as it is and
was.
I think you all over react about it. This patch do
On 07/08/2014 02:10 PM, Nick Østergaard wrote:
Hello Dick
It seems like your latest commit (4986 switch back to original sexpr
usage of PTREE, add new DSNLEX...) cannot read pcb files anymore.
There is also a bug report on this topic [1].
Regards
Nick Østergaard
[1]
Ok, with the new information I see a number of problems. I left some stuff
unfinished
from yesterday.
Thanks for the info.
I am on it this afternoon.
Dick
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
On 07/07/2014 02:34 AM, jp charras wrote:
Le 07/07/2014 06:20, Dick Hollenbeck a écrit :
I added back annotation to Eeschema directly from Cvpcb when they are both
running under
Kicad.exe.
I could have done it row by row. Instead I did it as a group batch when you
save under
cvpcb
On 07/07/2014 11:41 AM, jp charras wrote:
Le 07/07/2014 14:48, Dick Hollenbeck a écrit :
On 07/07/2014 02:34 AM, jp charras wrote:
Le 07/07/2014 06:20, Dick Hollenbeck a écrit :
I added back annotation to Eeschema directly from Cvpcb when they are both
running under
Kicad.exe.
I could
On 07/05/2014 08:23 PM, Jason Whiteman wrote:
Team,
I've been using the printf method to identify the cause of a windows
exception on
close of pcbnew.exe (release) I have seen. However, all passed for as deep
to the end of
the program as I could identify.
I maintain about 6 out
On 07/06/2014 11:34 AM, Lorenzo Marcantonio wrote:
On Sat, Jul 05, 2014 at 06:19:26PM +0200, Lorenzo Marcantonio wrote:
Last thing about layers; is it correct that the names are:
F_CrtYd, B_CrtYd, F_Fab, B_Fab
instead of
F.CrtYd, B.CrtYd, F.Fab, B.Fab -
F.CrtYd, B.CrtYd, F.Fab,
Is there advice on how to get the debug to work w/winbuilder?
I don't know winbuilder. However I would guess that its usefulness for a
developer is
diminished after installation of the toolchain and the goodies.
After that you will have to become master of:
1) CMake,
2) bzr, and
3)
I added back annotation to Eeschema directly from Cvpcb when they are both
running under
Kicad.exe.
I could have done it row by row. Instead I did it as a group batch when you
save under
cvpcb, on the idea that if you were to abort cvpcb without saving, you would
not want to
affect your
On 07/05/2014 07:26 AM, Lorenzo Marcantonio wrote:
Looking around the new code... is there a reason for not having
assembly/courtyard in the non_cu array in PCBIO_format?
Those two layers could be added to non_cu[]
also why having
that array in the first place and simply using the enabled
On 07/05/2014 11:42 AM, John Beard wrote:
Hi,
I have made some changes to the helpers for the footprint wizards. There
is now a matrix-based transform stack that helps simplify calculations
that footprint wizards need to do. The patch attached is based on BZR
rev 4975.
There are also
On 07/01/2014 10:44 AM, Tomasz Wlostowski wrote:
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
On 07/02/2014 07:46 AM, Lorenzo Marcantonio wrote:
On Tue, Jul 01, 2014 at 10:16:06AM -0500, Dick Hollenbeck wrote:
JP, Wayne and I developed the following working blueprint and attached
spreadsheet.
Spreadsheet from JP.
OK pondered over this, here's what I think.
1) Wanted 32 CU layers
On 07/01/2014 10:44 AM, Tomasz Wlostowski wrote:
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
On 06/04/2014 07:48 PM, Jean-Paul Louis wrote:
I see
that the number of copper layers seems to be limited to 16.
Jean-Paul,
I have a couple of boards that need to get designed. Can I barter with you for
this
feature?
You do a board or two for me, I do the requested software
On 06/30/2014 01:04 PM, Vesa Solonen wrote:
Use Ubuntu 14.04 64b or thereabouts.
Add this PPA to the above and you don't have to worry about building
yourself:
https://code.launchpad.net/~js-reynaud/+archive/ppa-kicad
I believe it is also supported on Linux Mint in addition to strict
http://wxwidgets.org/news/2014/06/wxwidgets-3.0.1-released/
Is good news. I have seen quite a few bugs in the 3.0 release myself, and
stopped using
it after about a month. In my case, I simply use SVN HEAD.
Might be a good idea if winbuilder would use this 3.0.1 version.
Dick
On 06/28/2014 09:47 AM, Dick Hollenbeck wrote:
On 06/28/2014 08:47 AM, Michael McCormack wrote:
This might be a bit off topic - I would like to know what distro and what
branch is used
to Kicad development.
Background - I use Linux only for development of embedded systems, and would
like
On 06/28/2014 08:47 AM, Michael McCormack wrote:
This might be a bit off topic - I would like to know what distro and what
branch is used
to Kicad development.
Background - I use Linux only for development of embedded systems, and would
like to get
relatively recent copies of Kicad,
On 06/26/2014 04:14 PM, Jason Whiteman wrote:
Team,
I am new to the dev group and have compiled my first windows binaries
today based on
what was pulled using kicad-winbuilder-3.4 (Kicad BZR build 4955).
The binaries were created fine - and I was able to load kicad.exe using
wrote:
Le 27/06/2014 15:46, Dick Hollenbeck a écrit :
On 06/26/2014 04:14 PM, Jason Whiteman wrote:
Team,
I am new to the dev group and have compiled my first windows
binaries today
based on
what was pulled using kicad-winbuilder-3.4 (Kicad BZR build
On 06/27/2014 10:20 AM, Tomasz Wlostowski wrote:
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
On 06/27/2014 11:27 AM, Jason Whiteman wrote:
Paths are set as follows (newline inserted in every 25 chars - windows
console cut/paste):
Path=Y:\Kicad_Build\kicad-winbuilder-3.4\env\mingw-w64\mingw32\bin;Y:\Kicad_Buil
On 06/27/2014 12:01 PM, Brian Sidebotham wrote:
Hi Guys,
I should first say, this is not typical of Winbuilder. Both pcbnew and
cvpcb work fine for me on a fresh Windows 7 install using the github
fp-lib-table. So there's clearly something different about your setup.
Process monitor is
On 06/23/2014 02:45 AM, Lorenzo Marcantonio wrote:
On Mon, Jun 23, 2014 at 09:28:20AM +0200, jp charras wrote:
PAD_CONN type was initially just a PAD_SMD with no solder paste (just
because a edge connector pad needs only a NiAu plating).
PAD_CONN as a separate type IMHO has no reason to
On 06/23/2014 08:39 AM, Dick Hollenbeck wrote:
On 06/23/2014 02:45 AM, Lorenzo Marcantonio wrote:
On Mon, Jun 23, 2014 at 09:28:20AM +0200, jp charras wrote:
PAD_CONN type was initially just a PAD_SMD with no solder paste (just
because a edge connector pad needs only a NiAu plating
I don't have an opinion on this. That means I am not a road block and will
defer to the
judgement of others, including you Orson.
Dick
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
It will be fixed in the new dialog.
I am also in there making changes for *layers*.
This gives me incentive to commit my layer work soon. I don't want to do my
work twice in
that dialog, please.
If you have a better idea let me know.
___
Jean-Pierre
Line 741 in dialogs/dialog_pad_properties.cpp, revision 4755, broke my thermal
pads, as
well as edge connectors plating.
Some kind of fix is needed. At most this should be a warning, but I don't need
myself.
___
Mailing list:
Bernhard's patch was committed in 4945.
___
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
committed in 4946.
___
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
On 06/13/2014 08:15 AM, jp charras wrote:
Le 13/06/2014 09:43, Brian Sidebotham a écrit :
I know I had this same problem with the python console on Windows. I
don't t think this is something that changed, I think it's always been
there.
I can test on Windows tonight for you and let you know.
/06/2014 20:28, jp charras a écrit :
Le 13/06/2014 15:39, Dick Hollenbeck a écrit :
The problem is made more difficult by the wxWindow hierarchy chosen. I
don't know if it
would be possible and easier if everything except the console wxWindow had
a common
wxPanel parent. That wxPanel
libs don't link
to libpython
at all.
What do you think ?
Le 04/04/2014 19:15, Dick Hollenbeck a écrit :
I have try to find a solution by trace the library loading:
LD_DEBUG=all pcbnew
But the issue look to be due to a compilation option on some ubuntu
libs. Anyway I'm NOT sure
The keys I press when the focus is on the Python Scripting window seem to be
filtered by
some higher up handler in the pcbnew editor.
For example, the 'o' key, and the 'x' key do not make it to the python console.
They
cause a tool change in the pcbnew editor instead of allowing me add that
in CMakeCache.txt, only the include strings.
2014-06-12 23:27 GMT+02:00 Dick Hollenbeck d...@softplc.com:
This fails. A difference is wx 2.8.12.
Application: pcbnew
Version: (2014-06-12 BZR 4942)-product Debug build
wxWidgets: Version 2.8.12 (release,Unicode,compiler with C++ ABI 1002,GCC
4.8.2,wx
On 06/11/2014 02:36 AM, Tomasz Wlostowski wrote:
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
On 06/11/2014 02:07 PM, Dick Hollenbeck wrote:
On 06/11/2014 01:54 PM, Jean-Paul Louis wrote:
Thank you Bernhard.
I would much prefer to apply your patches to the last kicad BZR at least
until someone
from the dev team has a chance to look at those and approve them. Do you
mind telling
On 06/10/2014 03:18 AM, Maciej Sumiński wrote:
Hi,
I have found a few static variables in the module editor code that I
would like to remove, but I need to know your opinion. The variables are
used to keep the last edited module between editor invocations.
If we want to preserve such
On 06/10/2014 08:22 AM, 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 06/10/2014 08:47 AM, Tomasz Wlostowski wrote:
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
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 having copy and paste across projects, and
I wanted paste so I can grab text from a page like this
https://raw.githubusercontent.com/KiCad/Transistors_SMD.pretty/master/sc70-6.kicad_mod
or this
https://github.com/liftoff-sr/pretty_footprints/blob/master/100-LQFP.kicad_mod
from my browser using the browser's page COPY
On 06/10/2014 01:33 AM, Lorenzo Marcantonio wrote:
On Mon, Jun 09, 2014 at 03:42:23PM -0500, Dick Hollenbeck wrote:
You could also create a new constructor that actually takes an int64_t
bitmap, and use
For the builtin layers could work, however in general there could be
more than 64
The attached patch will give you an idea of proposed changes.
Regards,
Orson
We can kill two birds with one stone here.
I like your changes, but they are insufficient to preserve the current
behaviour. With a
little bit of work we can accomplish a couple of useful things.
I think
On 06/10/2014 11:41 AM, Maciej Sumiński wrote:
On 06/10/2014 06:02 PM, Dick Hollenbeck wrote:
The attached patch will give you an idea of proposed changes.
Regards,
Orson
We can kill two birds with one stone here.
I like your changes, but they are insufficient to preserve the current
On 06/10/2014 11:31 AM, Lorenzo Marcantonio wrote:
On Tue, Jun 10, 2014 at 10:04:36AM -0500, Dick Hollenbeck wrote:
1) mask: uint64_t
2) index (LAYER_NUM) enum, interchangeable with int in some contexts.
An enum IIRC is always implicitly convertable to an int.
These rules are really nasty
On 06/10/2014 11:31 AM, Lorenzo Marcantonio wrote:
On Tue, Jun 10, 2014 at 10:04:36AM -0500, Dick Hollenbeck wrote:
1) mask: uint64_t
2) index (LAYER_NUM) enum, interchangeable with int in some contexts.
An enum IIRC is always implicitly convertable to an int.
These rules are really nasty
boiled down a bit more, attached.
#include stdio.h
#include stdint.h
//#define __STDC_FORMAT_MACROS
#include inttypes.h
#include vector
#include bitset
enum LAYER_NUM
{
LAYER_CU_FRONT,
LAYER_CU_1,
LAYER_CU_2,
LAYER_CU_BACK,
};
typedef std::bitset64 BASE_SET;
class LSET :
On 06/10/2014 02:23 PM, Wayne Stambaugh wrote:
On 6/10/2014 12:41 PM, Maciej Sumiński wrote:
On 06/10/2014 06:02 PM, Dick Hollenbeck wrote:
The attached patch will give you an idea of proposed changes.
Regards,
Orson
We can kill two birds with one stone here.
I like your changes
On 06/10/2014 04:14 PM, Lorenzo Marcantonio wrote:
On Tue, Jun 10, 2014 at 08:58:04PM +0200, jp charras wrote:
when reopening an editor, reopen the latest document(s) previously
opened makes sense, and moreover is a common feature in many editors.
My text editor does that, and this feature
On 06/10/2014 04:07 PM, Lorenzo Marcantonio wrote:
On Tue, Jun 10, 2014 at 02:51:27PM -0500, Dick Hollenbeck wrote:
boiled down a bit more, attached.
Would break for more than 64 layers, so a bitset is not needed in the
first place...
Lorenzo,
You are on the cusp of failing, and losing
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 by supporting multiple open projects and paste
On 06/06/2014 03:22 PM, Lorenzo Marcantonio wrote:
On Fri, Jun 06, 2014 at 08:30:59PM +0200, Tomasz Wlostowski wrote:
Either use only C++ RTTI or a type ID field. Mixing both is ugly.
Or better yet trust your interfaces:P if you need to know the kind of
object you have, then there is a
We're in complete agreement then, let's switch to Cobol.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help :
On 06/09/2014 03:42 PM, Dick Hollenbeck wrote:
Attached are two that work using the set() function.
As a third choice:
You could also create a new constructor that actually takes an int64_t
bitmap, and use
GetLayerMask() to build it.
However I would rename GetLayerMask
Attached are two that work using the set() function.
As a third choice:
You could also create a new constructor that actually takes an int64_t bitmap,
and use
GetLayerMask() to build it.
However I would rename GetLayerMask() to something more concise:
const LAYER_SET
On 06/09/2014 03:50 PM, Dick Hollenbeck wrote:
On 06/09/2014 03:42 PM, Dick Hollenbeck wrote:
Attached are two that work using the set() function.
As a third choice:
You could also create a new constructor that actually takes an int64_t
bitmap, and use
GetLayerMask() to build
a revision of last one, prints in hex, simplifies.
something to play with.
#include stdio.h
#include stdint.h
//#define __STDC_FORMAT_MACROS
#include inttypes.h
#include vector
#include bitset
enum LAYER_NUM
{
LAYER_CU_FRONT,
LAYER_CU_BACK,
};
#define LMSK( x ) (1ULL (x))
#if 0
On 06/04/2014 03: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 in the old kicad_pcb file
format after you
On 06/04/2014 06:30 PM, Cirilo Bernardo wrote:
- Original Message -
From: Wayne Stambaugh stambau...@verizon.net
To: kicad-developers@lists.launchpad.net
Cc:
Sent: Thursday, June 5, 2014 5:35 AM
Subject: Re: [Kicad-developers] CERN work package 4 (Extend number of layers)
[snip]
On 06/04/2014 07:48 PM, 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.
Yes, not once in 20 years has KiCad supported more than 16 copper layers.
Sorry if this
is news. Did the user manual
On 06/03/2014 10:19 AM, Jean-Paul Louis wrote:
Thank you Dick.
As usual, you’re the one making my life easier.
As usual, you're one of few people that say that, and know how to say it well.
Fixed in 4916.
I am glad that this wasn’t OS X specific.
Jean-Paul
AC9GH
Thanks Barnhard for your OSX help.
The horsepower to noise ratio seems to be improving with your KiCad on OSX
involvement. I'd hoped that the OSX support team could be strengthened.
I won't be committing these, but I hope that somebody else does if there are no
objections
to them.
On
On 05/27/2014 12:45 AM, Lorenzo Marcantonio wrote:
On Tue, May 27, 2014 at 12:03:08AM -0500, Dick Hollenbeck wrote:
Is wx using --enable-stl?
Nope. This is the config line I used to build it (3.0.0). It's awful but
it's never clear what is the default in wx...
./configure --prefix=/usr
On 05/27/2014 02:43 AM, Lorenzo Marcantonio wrote:
On Tue, May 27, 2014 at 09:33:30AM +0200, Lorenzo Marcantonio wrote:
to pinpoint where the event loop is getting stuck... all the UI works
(menu opens and so on) but code is not getting dispatched.
OK, it was actually easier than I tought...
On 05/27/2014 08:53 AM, Dick Hollenbeck wrote:
On 05/27/2014 02:43 AM, Lorenzo Marcantonio wrote:
On Tue, May 27, 2014 at 09:33:30AM +0200, Lorenzo Marcantonio wrote:
to pinpoint where the event loop is getting stuck... all the UI works
(menu opens and so on) but code is not getting dispatched
Or did you mean missing schematic libraries :) ?
Ok, I've had some more thoughts on this. If the modal dialog is using a parent
wxFrame
which is not yet visible, then this make sense.
I think there's a bit of clean up needed the eeschema KIFACE_I derivative's
CreateWindow()
function,
On 05/26/2014 04:19 PM, Lorenzo Marcantonio wrote:
Done a full rebuild of kicad as stable/release, to test things.
From the project manager:
- pcbnew opens OK and seems to work
- cvpcb still OK, as above
- eeschema don't work :(
Doing a strace shows that eeschema starts a then sits there
a bit and found some cmake modules that should be able to
produce
portable application bundles… I’ll try to add/change that in the cmake
files… if I
succeed, I will of course propose a patch.
Thanks,
Bernhard
On 24.05.2014, at 04:16, Dick Hollenbeck d...@softplc.com
mailto:d...@softplc.com
On 05/23/2014 12:31 PM, Jean-Paul Louis wrote:
Hi Bernhard,
I am attaching my script to this email.
Some of the stuff in the script might not be needed anymore, but I will clean
it up when I have time.
After the “make” is finished, I skip the “make install” as it is not yet
capable to
Kicad is currently a moving target. The team doesn't provide stable builds
and the
whole system is liable to blow up at any time.
Yep, that is by choice. This is where the users get to pay me by being
testers. That way
I can actually use the software. Because when I cannot use the
Dick,
I am going to try to apply your patch if it is OK to do it after so many BZR
updates.
Do I have to go back to BZR4810 to test it? or can I apply that patch to
BZR4854?
Please let me know.
It would not apply cleanly.
So I forced it in, and committed it.
The parts that don't
On 05/09/2014 08:05 PM, Jean-Paul Louis wrote:
Marco,
The problem is the same for kicad, eeschema, cvpcb, pcbnew, gerbview,
pl_editor
I cannot figure out where to put the pdf files that are called by the “Help”
menu.
I have tried to put them in the app directory
On 05/06/2014 05:41 PM, Cirilo Bernardo wrote:
- Original Message -
From: John Beard john.j.be...@gmail.com To: Kicad Developers
kicad-developers@lists.launchpad.net Cc: Sent: Wednesday, May 7, 2014 4:28
AM
Subject: [Kicad-developers] Forward-compatibility in s-expression
Just keep those fields, that would allows the program to load ANY
legacy part without breaking the bank.
There is no bank.
That's exactly what I mean - older versions of KiCad should be able to
ignore, but retain, unknown data.
This sentence has two concepts in it. One is fools gold,
On 05/08/2014 01:21 PM, jp charras wrote:
Le 08/05/2014 18:28, Jean-Paul Louis a écrit :
Hi Developpers,
I found a weird error that I never noticed before. The screenshot below
was taken just after clicking on the last button on the right. As usual,
it does not work, but the message in the
On 05/08/2014 02:12 PM, Lorenzo Marcantonio wrote:
On Thu, May 08, 2014 at 07:31:47PM +0100, John Beard wrote:
it will show you what it can. You'd be annoyed if it didn't, it would be
like Flash needing the latest version to watch your video, without the
excuse that is necessary to implement
On 05/08/2014 01:31 PM, John Beard wrote:
On 08/05/14 15:53, Dick Hollenbeck wrote:
That's exactly what I mean - older versions of KiCad should be able to
ignore, but retain, unknown data.
This sentence has two concepts in it. One is fools gold, the other is
poorly expressed.
1
On 05/08/2014 02:18 PM, Dick Hollenbeck wrote:
On 05/08/2014 01:31 PM, John Beard wrote:
On 08/05/14 15:53, Dick Hollenbeck wrote:
That's exactly what I mean - older versions of KiCad should be able to
ignore, but retain, unknown data.
This sentence has two concepts in it. One is fools
On 05/08/2014 02:44 PM, Dick Hollenbeck wrote:
On 05/08/2014 02:18 PM, Dick Hollenbeck wrote:
On 05/08/2014 01:31 PM, John Beard wrote:
On 08/05/14 15:53, Dick Hollenbeck wrote:
That's exactly what I mean - older versions of KiCad should be able to
ignore, but retain, unknown data
On 05/08/2014 04:00 AM, Maciej Sumiński wrote:
On 05/08/2014 10:57 AM, Lorenzo Marcantonio wrote:
On Thu, May 08, 2014 at 10:53:50AM +0200, Maciej Sumiński wrote:
Currently class BOARD contains a lot of fields methods, so to make it a
bit lighter - what do you think about moving the tracks
On 05/08/2014 03:06 PM, Lorenzo Marcantonio wrote:
On Thu, May 08, 2014 at 02:44:58PM -0500, Dick Hollenbeck wrote:
Please include comparative benchmarks with your patch submission. If
there's no
appreciable performance hit, then you have a chance getting the patch
accepted.
Are we
, and not worth another
disagreement. And it
has nothing to do with graphics.
On 05/08/2014 04:26 PM, Lorenzo Marcantonio wrote:
On Thu, May 08, 2014 at 03:46:15PM -0500, Dick Hollenbeck wrote:
I think for the guy who does not trim down his fp-lib-table to an
interesting subset, may
soon be trying
On 05/08/2014 05:10 PM, Rick Walker wrote:
Hi Dick,
it because I don't care if my old software does not load new
footprints. (I type $ make, and I can load the new footprints.)
I know you are a code developer and have the highly idiosyncratic kicad
build process finely balanced at
101 - 200 of 1653 matches
Mail list logo
