On 10/30/2014 11:42 AM, Benoît Roehr wrote:
>
> On 30/10/2014 13:13, Wayne Stambaugh wrote:
>> On 10/30/2014 6:54 AM, Benoît Roehr wrote:
>>> On 30/10/2014 08:50, Marco Ciampa wrote:
On Thu, Oct 30, 2014 at 01:22:34AM +0100, Benoît Roehr wrote:
> Beware here, they are not footprint anymor
On 30.10.2014, at 22:40, Nick Østergaard wrote:
>
> Hmm, ok, but what I see on my side was tested with 5217 and wx 3.0.2.
> Should my build be newer?
No, thanks… No relevant changes in that area I guess. I have seen those things
already some months back when I tried my changes initially.
Th
2014-10-30 22:21 GMT+01:00 Bernhard Stegmaier :
>
>>> (2a) eeschema: Block Move:
>>> When doing a block move everything of the block is drawn in black, similar
>>> to “grab" from (1) but different to normal “move”.
>>
>> And this, the wires and the symbol is black here.
>>
>>> (2b) eeschema: Block
>> (2a) eeschema: Block Move:
>> When doing a block move everything of the block is drawn in black, similar
>> to “grab" from (1) but different to normal “move”.
>
> And this, the wires and the symbol is black here.
>
>> (2b) eeschema: Block Move:
>> When doing a block move original content is
2014-10-30 21:46 GMT+01:00 Bernhard Stegmaier :
> Hi all,
>
> I am reworking the WX_OVERLAY stuff for OS X in eeschema to (hopefully) get
> rid off the annoying redraw artifacts.
> Looks quite good now, but I stumbled over some different/inconsistent
> behaviors and I don’t know if these are due
Hi all,
I am reworking the WX_OVERLAY stuff for OS X in eeschema to (hopefully) get rid
off the annoying redraw artifacts.
Looks quite good now, but I stumbled over some different/inconsistent behaviors
and I don’t know if these are due to my changes or it is everywhere the same.
Maybe some Lin
2014-10-30 16:55 GMT+01:00 Adam Wolf :
> Thanks Jean-Paul. Do you remember the name of hte thread where this was
> discussed before, or is there an active bug in the bug tracker? I want to
> get up to speed on the issue.
The topic was "BUG in OSX Build", see:
https://lists.launchpad.net/kicad-de
My archiver is resolving the symlinks. Thanks folks!
Adam Wolf
On Thu, Oct 30, 2014 at 3:00 PM, Bernhard Stegmaier wrote:
> … I just did a quick non-scripting build of a clean head revision (5240).
> No problems, pcbnew starts from launcher and standalone… links and bundle
> structure also are
… I just did a quick non-scripting build of a clean head revision (5240).
No problems, pcbnew starts from launcher and standalone… links and bundle
structure also are created as it is intended to be.
Regards,
Bernhard
On 30.10.2014, at 20:51, Bernhard Stegmaier wrote:
> You can also check the
You can also check the structure of kicad.app in the bin folder.
This should be the *only* real app bundle, everything else must be a symbolic
link to inside kicad.app.
The overall kicad.app structure should be like that (from memory…):
kicad.app/
Contents/
Applications/
eeschema.app/
First, I'm going to grab the files from the bin/ directory, and compare
them with the ones in the dmg, just to be sure. Then I'll put the DMG on
Dropbox along with the build log.
Adam Wolf
Cofounder and Engineer
W&L
On Thu, Oct 30, 2014 at 2:23 PM, Bernhard Stegmaier wrote:
> Can you put the b
Can you put the build somewhere?
I would like to try it… maybe I can see something being wrong?
Regards,
Bernhard
On 30.10.2014, at 20:16, Adam Wolf wrote:
> In my build of 5236, after doing make install and running from the installed
> location, I can start PCBNew from Kicad.app but not from
I did some experiments some while back, but i didn’t have much of a success…
the facts from what I tried:
I definitely started to have the problem after I updated to Xcode6. All my
previous builds with Xcode5 didn’t show the problem on my machines and also my
builds didn’t show the problem for
In my build of 5236, after doing make install and running from the
installed location, I can start PCBNew from Kicad.app but not from
PCBNew.app.
Does this tell us anything about what went wrong?
Adam Wolf
On Thu, Oct 30, 2014 at 1:57 PM, Bernhard Stegmaier wrote:
> Yes.
> All the dependency r
Yes.
All the dependency relocation stuff is done in the install step.
You can run kicad launcher directly from build folder… it will use the
hardcoded path to *your* dependencies. So it will run on your machine but not
on other ones. Also, from within the launcher pcbnew, etc. will work.
The sta
… if eeschema works then something is not right.
The part of loading the dso’s is in common code… so I can’t imagine why it
should work for one but not the other.
But, as I said before… this argv
argv[0]:
'/Volumes/Kicad/Kicad/pcbnew.app/Contents/MacOS/pcbnew’
looks like you started the pcbnew bi
Yup. The packager Jenkins job takes the files from make install, the build
log, and the generated readme, and puts them in a template.dmg.
I will take a look at grabbing the intermediate files and seeing if they
work as well, or if there was an error in the build log that didn't kill
the job.
Ad
> On Oct 30, 2014, at 8:15 AM, Bernhard Stegmaier
> wrote:
>
> You *must* do a “make install” and use that binaries/links (also, all the
> bundling/relocatong of libs is only done on the binaries created during
> install)…
>
Slight swerve here, but ... I didn't realize that one needed to do
Patch applied to product branch r5240.
Thanks,
Wayne
On 10/29/2014 6:56 PM, Marco Ciampa wrote:
> Another patch:
>
> === modified file 'pcbnew/class_pcb_layer_widget.cpp'
> --- pcbnew/class_pcb_layer_widget.cpp 2014-09-14 15:34:37 +
> +++ pcbnew/class_pcb_layer_widget.cpp 2014-10-29 22:52:4
In response to a message written on 28.10.2014 20:59, from Wayne Stambaugh:
> I noticed that the Python scripts in pcbnew/scripting/examples do not
> get installed. Is there a reason we are not installing these files
> along with the rest of kicad?
Cause it's only examples, they acts more as som
Thanks Jean-Paul. Do you remember the name of hte thread where this was
discussed before, or is there an active bug in the bug tracker? I want to
get up to speed on the issue.
Thanks!
Adam Wolf
Cofounder and Engineer
W&L
On Thu, Oct 30, 2014 at 10:53 AM, Jean-Paul Louis wrote:
> Hi Adam and
Adam,
I do not have this problem with BZR5236. I will try the latest one and let you
know
Jean-Paul
AC9GH
On Oct 30, 2014, at 11:23 AM, Adam Wolf wrote:
> I did run make install, and then copied the files from bin/ into a dmg.
> Interestingly enough, EESchema, for example, from the same wo
Hi Adam and Bernhard,
This is indeed great news for the majority of users.
For me, I am still waiting for the “Eeschema RED SCREEN” bug to be fixed, as it
is a major annoyance that is still in the main branch of KiCad. I do not know
if it happen in Windows or Linux platform, but in OS X, it is u
Yes, excellent! If there are things people have to do we definitely need
it documented in there, and if they're actually *required* I will see about
doing them automatically.
I will be putting the nightly builds on Dropbox I think and sharing the URL
here on the dev list, certainly for a few days
On 30/10/2014 13:13, Wayne Stambaugh wrote:
On 10/30/2014 6:54 AM, Benoît Roehr wrote:
On 30/10/2014 08:50, Marco Ciampa wrote:
On Thu, Oct 30, 2014 at 01:22:34AM +0100, Benoît Roehr wrote:
Beware here, they are not footprint anymore when they are on the
board, have a value, a reference and s
Patch committed in product branch r5238. Thank you for your
contribution to KiCad.
Regards,
Wayne
On 10/29/2014 12:05 PM, Marco Ciampa wrote:
> On Wed, Oct 08, 2014 at 02:37:40AM -0400, Mark Roszko wrote:
>> So from what I remember, Kicad used to call alot of pcb footprints as
>> "modules". Som
I did run make install, and then copied the files from bin/ into a dmg.
Interestingly enough, EESchema, for example, from the same works fine as
standalone.
Adam Wolf
Cofounder and Engineer
W&L
On Thu, Oct 30, 2014 at 10:15 AM, Bernhard Stegmaier <
stegma...@sw-systems.de> wrote:
> Hi,
>
> yes,
Hi Adam,
great!
I collected what paths are now used for various things around the code.
I’ll write this down this weekend, you could then add this to the readme.
I guess this would be great help for someone setting it up the first time… it’s
not that easy when you don’t know where to put what.
Hi,
yes, it should work with all “standalone” apps (at least, it does for me).
The top-level apps are just links to the real app bundles sitting inside the
main bundle (kicad.app/Contents/Applications/pcbnew.app).
It is implemented in a way that it loads the kiface-dsos always relative to the
m
Great work OSX developers and packagers! It looks like we are finally
getting close to providing regular OSX bundles. Many thanks to all who
made this possible.
Wayne
On 10/30/2014 10:01 AM, Adam Wolf wrote:
> Hi folks,
>
> Things are progressing very well on the OS X packaging front!
>
> Eve
Hi folks,
On a current Mac build, are we supposed to be able to open PCBNew.app on
its own?
When I do, I get the following error:
The error is: 06:53:16: dlopen(/Volumes/Contents/PlugIns/_pcbnew.kiface,
10): image not found
06:53:16: IO_ERROR: Fatal Installation Bug
missing file:
'/Volumes/Conten
On Thu, Oct 30, 2014 at 08:37:35AM -0400, Wayne Stambaugh wrote:
> Marco,
>
> In the future, please send patches as attachments rather than in-line.
> It makes it easier for me view and apply them. My mail client is not a
> very good diff file viewer.
>
> Thanks,
>
> Wayne
I'll keep it in mind
Marco,
In the future, please send patches as attachments rather than in-line.
It makes it easier for me view and apply them. My mail client is not a
very good diff file viewer.
Thanks,
Wayne
On 10/29/2014 12:05 PM, Marco Ciampa wrote:
> On Wed, Oct 08, 2014 at 02:37:40AM -0400, Mark Roszko wro
On 10/27/2014 4:40 PM, Nick Østergaard wrote:
> 2014-09-27 0:09 GMT+02:00 Wayne Stambaugh :
>> I just committed revision r5149 which fails when wxWidgets is less than
>> version 3.0.0. I know that the wx3 is not without it's issues but it is
>> becoming too much of a burden to try to keep the code
On 10/30/2014 6:54 AM, Benoît Roehr wrote:
>
> On 30/10/2014 08:50, Marco Ciampa wrote:
>> On Thu, Oct 30, 2014 at 01:22:34AM +0100, Benoît Roehr wrote:
>>> Beware here, they are not footprint anymore when they are on the
>>> board, have a value, a reference and so on... They are components.
>>>
>
On 30/10/2014 08:50, Marco Ciampa wrote:
On Thu, Oct 30, 2014 at 01:22:34AM +0100, Benoît Roehr wrote:
Beware here, they are not footprint anymore when they are on the
board, have a value, a reference and so on... They are components.
Footprint is the right term for the standalone "print" a co
On Thu, Oct 30, 2014 at 01:22:34AM +0100, Benoît Roehr wrote:
> Beware here, they are not footprint anymore when they are on the
> board, have a value, a reference and so on... They are components.
>
> Footprint is the right term for the standalone "print" a component
> will drop on a PCB. You can
37 matches
Mail list logo
