Re: [Kicad-developers] macos notarization status

[Bernhard Stegmaier]

OK, I see… this is weird.
My understanding from what I read in the documentation was, that it should sign 
everything in the top-level bundle (kicad.app) including sub-apps you might 
have in kicad.app/Contents/Applications.


Regards,
Bernhard

> On 3. Feb 2020, at 16:47, Adam Wolf  wrote:
> 
> I am not notarizing the DMGs.  While this is possible, it has not been
> necessary so far.
> 
> When I tried notarizing kicad.app but not the others, when I move to a
> new computer, it complains that eeschema.app is not notarized.
> 
> The problem is not putting the signed kicad.app into an unsigned dmg.
> 
> On Mon, Feb 3, 2020 at 8:11 AM Bernhard Stegmaier
>  wrote:
>> 
>> Hi Adam,
>> 
>> I am also no fan of the symlinks, but having a different approach will
>> be probably some work.
>> 
>>> I had someone ask if what we do would work during WWDC and I was told
>>> it would not work.  I consistently get "the signature is invalid" when
>>> signing while we have symlinks, and when I remove the symlinks and
>>> just sign KiCad.app this error goes away.
>> 
>> I don't doubt that the symlinks in the DMG don't work.
>> What you explained is exactly what I had in mind:
>> (1) Sign *only* kicad.app as is. No complete DMG with symlinks or
>> whatever.
>> (2) Create DMG with previously signed kicad.app and symlinks, libraries
>> and whatever you put into. Don't try to notarize this DMG, DMG is just
>> a container.
>> 
>> Doesn't that work?
>> kicad.app is signed and the DMG should just acts as some kind of zip
>> file then... ?
>> 
>> If the problem is putting the signed kicad.app into a (unsigned) DMG,
>> maybe just distributing via .zip would be also a viable way meanwhile?
>> Many other applications also do this...
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> Am 3.2.2020 14:46, schrieb Adam Wolf:
>>> Bernhard,
>>> 
>>> I have no personal vendetta against the symlinks.
>>> 
>>> I had someone ask if what we do would work during WWDC and I was told
>>> it would not work.  I consistently get "the signature is invalid" when
>>> signing while we have symlinks, and when I remove the symlinks and
>>> just sign KiCad.app this error goes away.
>>> 
>>> I am not sure if Apple gives themselves special entitlements that mere
>>> mortals don't get.  I'm not sure if I'm just not able to get it to
>>> work.
>>> 
>>> Nothing I have done so far relies on the symlinks going away, so if
>>> you think you can make it work, please let me know.
>>> 
>>> My personal suggestion for working around the symlinks issue was not
>>> to just copy things, but rather just have a single KiCad.app that
>>> would open itself in different ways of given a different type of file,
>>> but others on the bug tracker preferred trying to copy things first.
>>> 
>>> Frankly, it's exhausting spending all this time on things that users
>>> don't see, when there are so many interesting fun things we could be
>>> working on instead.
>>> 
>>> In terms of what I am signing and notarizing, I have tried signing and
>>> notarizing the app, the dmg, all the apps, basically every
>>> combination.  Apple's rules are extremely fickle here, and you could
>>> even notarize unsigned things.  They explicitly say the rules about
>>> what you can notarize are hidden from developers!
>>> 
>>> Adam
>>> 
>>> On Mon, Feb 3, 2020, 1:08 AM Bernhard Stegmaier
>>>  wrote:
>>> 
>>>> Hi Adam,
>>>> 
>>>> I still don’t get it:
>>>>> Our current
>>>>> strategy of symlinking into the kicad.app bundle does not work
>>>> with
>>>>> macOS signing.
>>>> 
>>>> Xcode has e.g. Instruments application in
>>>> Xcode.app/Contents/Applications/Instruments.app
>>>> If I symlink it (for example) to
>>>> /Applications/Instruments.app
>>>> It runs without any complaints when started via the symlink.
>>>> 
>>>> What do you notarize?
>>>> The overall dmg with the symlink?
>>>> Have you already tried to only notarize kicad.app (no dmg, no
>>>> symlinks) and put it into the dmg with symlinks afterwards?
>>>> Another quick fix could be some script that can be run to create the
>>>> symlinks on user machine?
>>>> 
>>>> A simple copy of the apps won’t work.
>>>> You ne

Re: [Kicad-developers] macos notarization status

[Bernhard Stegmaier]

Theoretically yes, I guess.
From cmdline it probably would solve the problem and the links together with 
those standalone-apps could be removed.

But, from a non-cmdline user perspective:
Is there a way to “wrap” (?) this call to main kicad.app with some parameter 
into a nice icon that just looks like a “normal” pcbnew/… app?


Regards,
Bernhard

> On 3. Feb 2020, at 15:51, Ian McInerney  wrote:
> 
> Adam (et al.),
> 
> If you didn't have to package the single top executable (e.g. eeschema, 
> pcbnew) would this allow you to remove the symlinks? We have been discussing 
> adding command line flags to the main kicad executable to launch the various 
> frames as standalone (e.g. `kicad --eeschema` would launch a standalone 
> eeschema instance instead of the manager frame), so then we wouldn't have to 
> actually have the single top executables for those anymore.
> 
> Would that fix your issue?
> 
> Thanks,
> -Ian
> 
> On Mon, Feb 3, 2020 at 2:12 PM Bernhard Stegmaier  <mailto:stegma...@sw-systems.de>> wrote:
> Hi Adam,
> 
> I am also no fan of the symlinks, but having a different approach will
> be probably some work.
> 
> > I had someone ask if what we do would work during WWDC and I was told
> > it would not work.  I consistently get "the signature is invalid" when
> > signing while we have symlinks, and when I remove the symlinks and
> > just sign KiCad.app this error goes away.
> 
> I don't doubt that the symlinks in the DMG don't work.
> What you explained is exactly what I had in mind:
> (1) Sign *only* kicad.app as is. No complete DMG with symlinks or
> whatever.
> (2) Create DMG with previously signed kicad.app and symlinks, libraries
> and whatever you put into. Don't try to notarize this DMG, DMG is just
> a container.
> 
> Doesn't that work?
> kicad.app is signed and the DMG should just acts as some kind of zip
> file then... ?
> 
> If the problem is putting the signed kicad.app into a (unsigned) DMG,
> maybe just distributing via .zip would be also a viable way meanwhile?
> Many other applications also do this...
> 
> 
> Regards,
> Bernhard
> 
> Am 3.2.2020 14:46, schrieb Adam Wolf:
> > Bernhard,
> > 
> > I have no personal vendetta against the symlinks.
> > 
> > I had someone ask if what we do would work during WWDC and I was told
> > it would not work.  I consistently get "the signature is invalid" when
> > signing while we have symlinks, and when I remove the symlinks and
> > just sign KiCad.app this error goes away.
> > 
> > I am not sure if Apple gives themselves special entitlements that mere
> > mortals don't get.  I'm not sure if I'm just not able to get it to
> > work.
> > 
> > Nothing I have done so far relies on the symlinks going away, so if
> > you think you can make it work, please let me know.
> > 
> > My personal suggestion for working around the symlinks issue was not
> > to just copy things, but rather just have a single KiCad.app that
> > would open itself in different ways of given a different type of file,
> > but others on the bug tracker preferred trying to copy things first.
> > 
> > Frankly, it's exhausting spending all this time on things that users
> > don't see, when there are so many interesting fun things we could be
> > working on instead.
> > 
> > In terms of what I am signing and notarizing, I have tried signing and
> > notarizing the app, the dmg, all the apps, basically every
> > combination.  Apple's rules are extremely fickle here, and you could
> > even notarize unsigned things.  They explicitly say the rules about
> > what you can notarize are hidden from developers!
> > 
> > Adam
> > 
> > On Mon, Feb 3, 2020, 1:08 AM Bernhard Stegmaier
> > mailto:stegma...@sw-systems.de>> wrote:
> > 
> >> Hi Adam,
> >> 
> >> I still don’t get it:
> >>> Our current
> >>> strategy of symlinking into the kicad.app bundle does not work
> >> with
> >>> macOS signing.
> >> 
> >> Xcode has e.g. Instruments application in
> >> Xcode.app/Contents/Applications/Instruments.app
> >> If I symlink it (for example) to
> >> /Applications/Instruments.app
> >> It runs without any complaints when started via the symlink.
> >> 
> >> What do you notarize?
> >> The overall dmg with the symlink?
> >> Have you already tried to only notarize kicad.app (no dmg, no
> >> symlinks) and put it into the dmg with symlinks afterwards?
> >> Another quick fix could be some script that can be run to create the
> >> s

Re: [Kicad-developers] macos notarization status

[Bernhard Stegmaier]

Hi Adam,

I am also no fan of the symlinks, but having a different approach will
be probably some work.


I had someone ask if what we do would work during WWDC and I was told
it would not work.  I consistently get "the signature is invalid" when
signing while we have symlinks, and when I remove the symlinks and
just sign KiCad.app this error goes away.


I don't doubt that the symlinks in the DMG don't work.
What you explained is exactly what I had in mind:
(1) Sign *only* kicad.app as is. No complete DMG with symlinks or
whatever.
(2) Create DMG with previously signed kicad.app and symlinks, libraries
and whatever you put into. Don't try to notarize this DMG, DMG is just
a container.

Doesn't that work?
kicad.app is signed and the DMG should just acts as some kind of zip
file then... ?

If the problem is putting the signed kicad.app into a (unsigned) DMG,
maybe just distributing via .zip would be also a viable way meanwhile?
Many other applications also do this...


Regards,
Bernhard

Am 3.2.2020 14:46, schrieb Adam Wolf:

Bernhard,

I have no personal vendetta against the symlinks.

I had someone ask if what we do would work during WWDC and I was told
it would not work.  I consistently get "the signature is invalid" when
signing while we have symlinks, and when I remove the symlinks and
just sign KiCad.app this error goes away.

I am not sure if Apple gives themselves special entitlements that mere
mortals don't get.  I'm not sure if I'm just not able to get it to
work.

Nothing I have done so far relies on the symlinks going away, so if
you think you can make it work, please let me know.

My personal suggestion for working around the symlinks issue was not
to just copy things, but rather just have a single KiCad.app that
would open itself in different ways of given a different type of file,
but others on the bug tracker preferred trying to copy things first.

Frankly, it's exhausting spending all this time on things that users
don't see, when there are so many interesting fun things we could be
working on instead.

In terms of what I am signing and notarizing, I have tried signing and
notarizing the app, the dmg, all the apps, basically every
combination.  Apple's rules are extremely fickle here, and you could
even notarize unsigned things.  They explicitly say the rules about
what you can notarize are hidden from developers!

Adam

On Mon, Feb 3, 2020, 1:08 AM Bernhard Stegmaier
 wrote:


Hi Adam,

I still don’t get it:

Our current
strategy of symlinking into the kicad.app bundle does not work

with

macOS signing.


Xcode has e.g. Instruments application in
Xcode.app/Contents/Applications/Instruments.app
If I symlink it (for example) to
/Applications/Instruments.app
It runs without any complaints when started via the symlink.

What do you notarize?
The overall dmg with the symlink?
Have you already tried to only notarize kicad.app (no dmg, no
symlinks) and put it into the dmg with symlinks afterwards?
Another quick fix could be some script that can be run to create the
symlinks on user machine?

A simple copy of the apps won’t work.
You need to change everything wrt shared libraries in KiCad code and
cmake script.

In the end, you will duplicate all libraries and support stuff.
Probably not a big deal for eeschema and the other small apps, but I
guess for pcbnew.
Means duplicating all the python, nags-ice, etc. stuff.
And also, all stuff like templates, scripts, etc.
Users shouldn’t fiddle around in the .app, but could get really
messy if they now put (template, python, spice?) stuff in kicad.app
or pcbnew.app and then something doesn’t work in one or the
other...

Regards,
Bernhard


On 3. Feb 2020, at 02:00, Adam Wolf

 wrote:


Hi folks!

Apple is changing how the lack of notarization looks like to users

on

Catalina starting tomorrow.  It is not clear what will happen when
folks download new versions of KiCad after tonight.

For the past two months I've been working hard--I've got a tech

demo

locally here that has signatures and notarization on macOS, but

it's

not ready for primetime.  For instance, I have removed the other

.apps

and just have kicad.app.  There's changes I made to kicad that
probably belong in kicad-mac-builder--and, well, let's just say

it's a

tech demo :)

The main things that remain are:
1) Figure out a good solution for the symlinked .apps.  Our

current

strategy of symlinking into the kicad.app bundle does not work

with

macOS signing.  I think the current contender is to copy instead

of

symlink.  I am not sure how much extra space that will take up but
it's a good try.  This is definitely something I can do, but since
it's something that can be done on its own, it's a prime contender

for

someone looking to help out.

2) Another issue is that there are strict rules about where in the
bundle code, data, and executable non-Mach-O files live.  For
instance, one of the signing blockers is ngspice, because it

mingles

scripts and Mach-O bina

Re: [Kicad-developers] macos notarization status

[Bernhard Stegmaier]

Hi Adam,

I still don’t get it:
> Our current
> strategy of symlinking into the kicad.app bundle does not work with
> macOS signing.


Xcode has e.g. Instruments application in
  Xcode.app/Contents/Applications/Instruments.app
If I symlink it (for example) to
  /Applications/Instruments.app
It runs without any complaints when started via the symlink.

What do you notarize?
The overall dmg with the symlink?
Have you already tried to only notarize kicad.app (no dmg, no symlinks) and put 
it into the dmg with symlinks afterwards?
Another quick fix could be some script that can be run to create the symlinks 
on user machine?

A simple copy of the apps won’t work.
You need to change everything wrt shared libraries in KiCad code and cmake 
script.

In the end, you will duplicate all libraries and support stuff.
Probably not a big deal for eeschema and the other small apps, but I guess for 
pcbnew.
Means duplicating all the python, nags-ice, etc. stuff.
And also, all stuff like templates, scripts, etc.
Users shouldn’t fiddle around in the .app, but could get really messy if they 
now put (template, python, spice?) stuff in kicad.app or pcbnew.app and then 
something doesn’t work in one or the other...


Regards,
Bernhard


> On 3. Feb 2020, at 02:00, Adam Wolf  wrote:
> 
> Hi folks!
> 
> Apple is changing how the lack of notarization looks like to users on
> Catalina starting tomorrow.  It is not clear what will happen when
> folks download new versions of KiCad after tonight.
> 
> For the past two months I've been working hard--I've got a tech demo
> locally here that has signatures and notarization on macOS, but it's
> not ready for primetime.  For instance, I have removed the other .apps
> and just have kicad.app.  There's changes I made to kicad that
> probably belong in kicad-mac-builder--and, well, let's just say it's a
> tech demo :)
> 
> The main things that remain are:
> 1) Figure out a good solution for the symlinked .apps.  Our current
> strategy of symlinking into the kicad.app bundle does not work with
> macOS signing.  I think the current contender is to copy instead of
> symlink.  I am not sure how much extra space that will take up but
> it's a good try.  This is definitely something I can do, but since
> it's something that can be done on its own, it's a prime contender for
> someone looking to help out.
> 
> 2) Another issue is that there are strict rules about where in the
> bundle code, data, and executable non-Mach-O files live.  For
> instance, one of the signing blockers is ngspice, because it mingles
> scripts and Mach-O binaries and then we put them in Contents/Plugins.
> For more details, see
> https://developer.apple.com/library/archive/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG201.
> The big change for KiCad itself is where the Python scripts are
> stored--I've fixed this in my branch, but now I have to go through and
> audit and fixup our partner packages, like OCE/OCC and ngspice.  If
> you want to help with this, it's going to be a big job but I'm willing
> to put in the time to teach if you're willing to put in the time to
> learn :)
> 
> I was really hoping I could get this done before Apple turned up the
> enforcement on notarization, but that's going to happen.  After
> tomorrow, it'll be clearer what Apple is doing.  There might be some
> quick changes to make that will improve things for our users without
> getting all of this done.
> 
> Adam Wolf
> 
> ___
> 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


___
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

Re: [Kicad-developers] macos dev environment

[Bernhard Stegmaier]

> On 8. Nov 2019, at 13:24, Jonatan Liljedahl  wrote:
> 
> On Thu, Nov 7, 2019 at 11:08 PM Adam Wolf  
> wrote:
>> 
>> Merging them in is blocked on the "eliminate symlinked bundles" task.
> 
> Is this about the symlinked eeschema.app etc in the main kicad folder?
> Are the plans to copy instead of symlink? Or could we instead move
> them, and make kicad.app able to find those apps, so something like
> "APP_BUNDLE_DIR/../eeschema.app”?

The symlink ist just there to have some simple access for the standalone apps.

IMHO you cannot just copy or move the standalone apps for this reason:
To best of my knowledge every macOS application is considered to be self 
contained, you can move it to any place you want and start it.
The standalone apps (eeschema, pcbnew, etc.) share a lot of libraries… KiCad 
internal stuff (the kiway libs) and other libraries like wxWidgets.
For the libraries linked you need to do this with a given (fixed) path during 
building.

If now users move e.g. eeschema.app around because it looks like it is a usual 
macOS application, it will never find it’s libraries from inside kicad.app (the 
search paths in the binaries won’t change if you move the application around).
Of course, you could require that the copied eeschema app always has to be in 
some certain relative place to kicad.app.
But, that would be some special KiCad limitation that doesn’t hold for other 
macOS applications and probably causes even more confusion.

Of course, you could just duplicate all libs for each standalone application, 
but it was a decision way back not to do it.

Best way (also has been discussed) would be if this standalone apps wouldn’t be 
needed at all, but you could just open single schematic/pcb files independent 
from a project from project manager (kicad.app) directly.


Regards,
Bernhard
 
___
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

Re: [Kicad-developers] macos dev environment

[Bernhard Stegmaier]

I don’t know about ngspice or Python scripting, I don’t use them.
Maybe you just need to supply a suitable path to cmake when building?

When you do a "make install" the binaries in the build folder are not usable 
directly any more.
The bundling process of a “make install” rewrites the library paths in all 
binaries/libs so that it only fits the layout of the bundle, but not the layout 
of the build folders.
So, it is expected that it crashes or some other bad things happen, because it 
won’t find libs any more.


Regards,
Bernhard

> On 8. Nov 2019, at 13:17, Jonatan Liljedahl  wrote:
> 
> First time, open the built kicad.app directly did work, except that it
> couldn't find ngspice (which I need, because it's the simulator UI I'm
> working on...). After make install, opening the kicad.app directly
> (not the installed one), it crashes when I click the eeschema button
> in the project window.
> 
> On Thu, Nov 7, 2019 at 11:05 PM Bernhard Stegmaier
>  wrote:
>> 
>> At least the last time I tried you don’t need to do a “make install” and 
>> build the bundle if you want to test something during development.
>> Just run needed KiCad binary directly from the build folder…
>> 
>> I don’t know about CLion, but that worked for me using Qt Creator without 
>> problems.
>> 
>> The only thing to remember is that if you do a “make install” once, it won’t 
>> run from build folder any more.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> On 7. Nov 2019, at 22:35, Jonatan Liljedahl  wrote:
>> 
>> Ok, I got it working by changing CMAKE_INSTALL_PREFIX to an absolute
>> path. So using "../bin" as it says in
>> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_osx
>> does not actually work.
>> 
>> Perhaps it would be a good idea to merge the kicad-mac-builder patches
>> instead of having to apply them each time? I know this was discussed
>> before, regarding the mismatch between KiCad version info string for
>> the macOS package, but I'm not sure what was decided.
>> 
>> Cheers
>> 
>> On Thu, Nov 7, 2019 at 10:07 PM Jonatan Liljedahl  wrote:
>> 
>> 
>> Thanks. I managed to get it building directly in my kicad source dir
>> by pointing it to the custom wxWidgets etc that was built by
>> kicad-mac-builder. However, make install fails during fixup bundle
>> (see below). I have the patches from kicad-mac-builder applied. I've
>> attached my CMakeCache.txt.
>> 
>> Install the project...
>> -- Install configuration: "Debug"
>> -- Removing existing application bundles...
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/kicad.app/Contents/Frameworks/libkicad_3dsg.2.0.0.dylib
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/kicad.app/Contents/Frameworks/libkicad_3dsg.dylib
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/MacOS
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/MacOS/eeschema
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources/eeschema_doc.icns
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources/eeschema.icns
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Info.plist
>> -- fixup_bundle
>> --   app='../bin/eeschema.app/Contents/MacOS/eeschema'
>> --   libs=''
>> --   dirs=''
>> --   ignoreItems=''
>> -- fixup_bundle: preparing...
>> warning: target '../bin/eeschema.app/Contents/MacOS/eeschema' is not 
>> absolute...
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
&g

Re: [Kicad-developers] macos dev environment

[Bernhard Stegmaier]

At least the last time I tried you don’t need to do a “make install” and build 
the bundle if you want to test something during development.
Just run needed KiCad binary directly from the build folder…

I don’t know about CLion, but that worked for me using Qt Creator without 
problems.

The only thing to remember is that if you do a “make install” once, it won’t 
run from build folder any more.


Regards,
Bernhard

> On 7. Nov 2019, at 22:35, Jonatan Liljedahl  wrote:
> 
> Ok, I got it working by changing CMAKE_INSTALL_PREFIX to an absolute
> path. So using "../bin" as it says in
> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_osx
>  
> 
> does not actually work.
> 
> Perhaps it would be a good idea to merge the kicad-mac-builder patches
> instead of having to apply them each time? I know this was discussed
> before, regarding the mismatch between KiCad version info string for
> the macOS package, but I'm not sure what was decided.
> 
> Cheers
> 
> On Thu, Nov 7, 2019 at 10:07 PM Jonatan Liljedahl  > wrote:
>> 
>> Thanks. I managed to get it building directly in my kicad source dir
>> by pointing it to the custom wxWidgets etc that was built by
>> kicad-mac-builder. However, make install fails during fixup bundle
>> (see below). I have the patches from kicad-mac-builder applied. I've
>> attached my CMakeCache.txt.
>> 
>> Install the project...
>> -- Install configuration: "Debug"
>> -- Removing existing application bundles...
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/kicad.app/Contents/Frameworks/libkicad_3dsg.2.0.0.dylib
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/kicad.app/Contents/Frameworks/libkicad_3dsg.dylib
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/MacOS
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/MacOS/eeschema
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources/eeschema_doc.icns
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Resources/eeschema.icns
>> -- Installing: 
>> /Users/lijon/Coding/kicad/build/debug/../bin/../bin/eeschema.app/Contents/Info.plist
>> -- fixup_bundle
>> --   app='../bin/eeschema.app/Contents/MacOS/eeschema'
>> --   libs=''
>> --   dirs=''
>> --   ignoreItems=''
>> -- fixup_bundle: preparing...
>> warning: target '../bin/eeschema.app/Contents/MacOS/eeschema' is not 
>> absolute...
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- warning: gp_resolved_file_type expects absolute full path for first
>> arg original_file
>> -- fixup_bundle: copying...
>> -- 1/24: *NOT* copying
>> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/MacOS/eeschema'
>> -- 2/24: linking
>> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau-3.0.0.4.0.dylib'
>> -> 
>> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau-3.0.0.dylib'
>> -- 3/24: linking
>> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau_gl-3.0.0.4.0.dylib'
>> -> 
>> '/Users/lijon/Coding/kicad/build/bin/eeschema.app/Contents/Frameworks/libwx_osx_cocoau_gl-3.0.0.dylib'
>> -- 4/24: copying '/usr/local/opt/cairo/lib/libcairo.2.dylib'
>> -- 5/24: copying '/usr/local/opt/fontconfig/lib/libfontconfig.1.dylib'
>> -- 6/24: copying 

Re: [Kicad-developers] knowing last commit included in a nightly build?

[Bernhard Stegmaier]

> On 10. Sep 2019, at 15:23, Wayne Stambaugh  wrote:
> 
> Adam,
> 
> I took a look at this patch set and I have some concerns.  The CMake
> changes seem acceptable but I'm curious as to why you had to add all of
> the python paths in pcbnew.cpp to get Python working under macos.  Does
> Python on macos not look in the install path for library paths like it
> does on other platforms.  If we have to do this to get python to work on

I don’t use Python scripting … so my knowledge may be very limited.
I guess this is needed due to two things:

1) Python is not *installed* into the bundle, but just *copied* from somewhere 
(see line 50 of 0001-… patch).
So, anything derived from original install path might not be valid any more.
I don’t know if you can compile Python in a way that all paths are only relative
to, e.g., some Python executable.

2) You can put the bundle (with Python inside) anywhere you want, it has no
fixed place/path. So, you can’t rely on some static compile time path to be 
the right one, but you need to set it dynamically (or, only relative).

AFAIK you could set environment variables via Info.plist to pull setting
of PYTHONPATH out of pcbnew executable. I don’t know if there
is enough Info.plist magic around to get the current (absolute) bundle path 
(there seems to be $EXECUTABLE_PATH, but apparently it is only relative, 
so it won’t help).

> macos, then at the very least we should at least not hard code the
> python version in the path strings and use a CMake configuration
> variable to generate them.  That way we wont have to modify pcbnew.cpp
> every time we update to a new version of python on macos.  Would one of
> our macos devs please take a look at this and work with Adam so we can
> come up with a solution so we don't have unknown git commit hashes in
> our version strings.
> 
> Thanks,
> 
> Wayne
> 
> On 9/5/19 11:45 AM, Adam Wolf wrote:
>> It would be awesome to have them merged into upstream.  They're all
>> very packaging specific.
>> 
>> Here is the current list:
>> 
>> * 
>> https://github.com/KiCad/kicad-mac-builder/tree/master/kicad-mac-builder/patches/kicad
>> 
>> Adam Wolf
>> 
>> On Thu, Sep 5, 2019 at 8:19 AM Jeff Young  wrote:
>>> 
>>> Yeah, it would be -really- nice if we could fix this somehow.  I’ve run 
>>> into it many times.
>>> 
>>> Cheers,
>>> Jeff.
>>> 
>>> 
 On 5 Sep 2019, at 14:07, Jonatan Liljedahl  wrote:
 
 On Thu, Sep 5, 2019 at 1:59 PM Nick Østergaard  wrote:
> 
> Does the sha listed in the version info from the runtime app not match?
 
 Unfortunately not. For example (5.1.4-60-ga2950354a)
 
 lijon-mbp:kicad lijon$ git branch
 * 5.1
 master
 lijon-mbp:kicad lijon$ git log --oneline | grep ga2950354a
 lijon-mbp:kicad lijon$
 
 
 --
 /Jonatan
 http://kymatica.com
 
 ___
 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
>>> 
>>> 
>>> ___
>>> 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
>> 
>> ___
>> 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
>> 
> 
> ___
> 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


___
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

Re: [Kicad-developers] macOS notarizing

[Bernhard Stegmaier]

Hi Adam,

I have some of the most important stuff of my (non-KiCad) Todo list done in the 
next couple of days.
I will have to update my build environment, find my developer ID, but then I 
wanted to try how this could work… I’ll drop you a note when I am ready…


Regards,
Bernhard

> On 29. Aug 2019, at 03:30, Adam Wolf  wrote:
> 
> Hi folks!
> 
> Does anyone want to help with the macOS notarization effort?  It would
> be a great way to learn about how everything goes together :)
> 
> Adam Wolf
> 
> ___
> 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


___
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

Re: [Kicad-developers] 5.1.4 release - release announcement/blog entry?

[Bernhard Stegmaier]

Yes, I did… and I still don’t really like this multi-application approach.
To be honest, I never tried to notarize something and I haven’t read very much 
about it.

Did you try to notarize the complete package/dmg including symlinks?

Or, only kicad.app on its own (without symlinks and all other stuff) and then 
just put the signed kicad.app and the symlinks into the dmg afterwards?
I just tried to create a symlink to Instruments inside Xcode and nothing 
complains when launching it via symlink.
I don’t know if it would satisfy Gatekeeper, but the dmg just as container 
shouldn’t need any notarizing?


Bernhard

> On 14. Aug 2019, at 00:10, Adam Wolf  wrote:
> 
> Oh hey, Bernhard, I didn't see it was you... yeah, you know what I'm
> talking about since you wrote a bunch of this CMake stuff, didn't you?
> :)
> 
> Adam
> 
> On Tue, Aug 13, 2019 at 5:06 PM Bernhard Stegmaier
>  wrote:
>> 
>> I see, the symlinks… yes, haven’t seen anything like that elsewhere.
>> 
>> On 14. Aug 2019, at 00:02, Adam Wolf  wrote:
>> 
>> I spent quite a long time on this maybe 18 months ago.  After I did a lot on 
>> my own, I was told by a few sources, one at Apple, that due to our symlinks, 
>> files were belonging to more than one .app, and it wasn't going to work.
>> 
>> Things may have changed, and they may have been wrong, so feel free to work 
>> on it again, but I really suspect the easiest way out is to make a better 
>> launcher that'll open the correct subapplication based on the argument/drop 
>> target.
>> 
>> On Tue, Aug 13, 2019, 4:54 PM Bernhard Stegmaier  
>> wrote:
>>> 
>>> What’s the problem with signing it?
>>> Xcode also has applications inside its main bundle and I guess it is signed?
>>> 
>>> Regards,
>>> Bernhard
>>> 
>>>> On 13. Aug 2019, at 21:53, Adam Wolf  wrote:
>>>> 
>>>> Builds can't be signed until
>>>> https://bugs.launchpad.net/kicad/+bug/1826649. I have everything in
>>>> place once that is complete.
>>>> 
>>>> Adam
>>>> 
>>>> On Tue, Aug 13, 2019 at 1:34 PM Andy Peters  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Aug 13, 2019, at 10:57 AM, Adam Wolf  
>>>>>> wrote:
>>>>>> 
>>>>>> macOS is ready!
>>>>> 
>>>>> Hola — downloaded and installed it, and got the complaint about 
>>>>> “unidentified developer.” I know how to work around that, but I thought 
>>>>> the builds were signed so the complaint doesn’t pop up?
>>>>> 
>>>>> -a
>>>>> ___
>>>>> 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
>>>> 
>>>> ___
>>>> 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
>>> 
>> 


___
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

Re: [Kicad-developers] 5.1.4 release - release announcement/blog entry?

[Bernhard Stegmaier]

I see, the symlinks… yes, haven’t seen anything like that elsewhere.

> On 14. Aug 2019, at 00:02, Adam Wolf  wrote:
> 
> I spent quite a long time on this maybe 18 months ago.  After I did a lot on 
> my own, I was told by a few sources, one at Apple, that due to our symlinks, 
> files were belonging to more than one .app, and it wasn't going to work.
> 
> Things may have changed, and they may have been wrong, so feel free to work 
> on it again, but I really suspect the easiest way out is to make a better 
> launcher that'll open the correct subapplication based on the argument/drop 
> target.
> 
> On Tue, Aug 13, 2019, 4:54 PM Bernhard Stegmaier  <mailto:stegma...@sw-systems.de>> wrote:
> What’s the problem with signing it?
> Xcode also has applications inside its main bundle and I guess it is signed?
> 
> Regards,
> Bernhard
> 
> > On 13. Aug 2019, at 21:53, Adam Wolf  > <mailto:adamw...@feelslikeburning.com>> wrote:
> > 
> > Builds can't be signed until
> > https://bugs.launchpad.net/kicad/+bug/1826649 
> > <https://bugs.launchpad.net/kicad/+bug/1826649>. I have everything in
> > place once that is complete.
> > 
> > Adam
> > 
> > On Tue, Aug 13, 2019 at 1:34 PM Andy Peters  > <mailto:de...@latke.net>> wrote:
> >> 
> >> 
> >> 
> >>> On Aug 13, 2019, at 10:57 AM, Adam Wolf  >>> <mailto:adamw...@feelslikeburning.com>> wrote:
> >>> 
> >>> macOS is ready!
> >> 
> >> Hola — downloaded and installed it, and got the complaint about 
> >> “unidentified developer.” I know how to work around that, but I thought 
> >> the builds were signed so the complaint doesn’t pop up?
> >> 
> >> -a
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers 
> >> <https://launchpad.net/~kicad-developers>
> >> Post to : kicad-developers@lists.launchpad.net 
> >> <mailto:kicad-developers@lists.launchpad.net>
> >> Unsubscribe : https://launchpad.net/~kicad-developers 
> >> <https://launchpad.net/~kicad-developers>
> >> More help   : https://help.launchpad.net/ListHelp 
> >> <https://help.launchpad.net/ListHelp>
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net 
> > <mailto:kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > <https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp 
> > <https://help.launchpad.net/ListHelp>
> 

___
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

Re: [Kicad-developers] 5.1.4 release - release announcement/blog entry?

[Bernhard Stegmaier]

What’s the problem with signing it?
Xcode also has applications inside its main bundle and I guess it is signed?

Regards,
Bernhard

> On 13. Aug 2019, at 21:53, Adam Wolf  wrote:
> 
> Builds can't be signed until
> https://bugs.launchpad.net/kicad/+bug/1826649. I have everything in
> place once that is complete.
> 
> Adam
> 
> On Tue, Aug 13, 2019 at 1:34 PM Andy Peters  wrote:
>> 
>> 
>> 
>>> On Aug 13, 2019, at 10:57 AM, Adam Wolf  
>>> wrote:
>>> 
>>> macOS is ready!
>> 
>> Hola — downloaded and installed it, and got the complaint about 
>> “unidentified developer.” I know how to work around that, but I thought the 
>> builds were signed so the complaint doesn’t pop up?
>> 
>> -a
>> ___
>> 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
> 
> ___
> 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


___
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

Re: [Kicad-developers] Debuggers, boost and std::deque

[Bernhard Stegmaier]

I wouldn’t try this.
macOS switched to libc++ long time ago.
I don’t know how it is today but I had a really hard time with unpredictable 
results/crashes/linking errors back when I started with KiCad and (due to not 
knowing anything about it) had libraries compiled with libstdc++ and libc++ 
mixed. Some stuff like strings were not compatible causing a lot of fun.


Regards,
Bernhard


> On 11. Jun 2019, at 21:53, Jeff Young  wrote:
> 
> I found this in a CLion blog:
> 
> This feature works in GCC, and in the case of Clang it works for libstdc++ 
> only. This requires the following setting to be added to CMakeLists.txt:
> 
> set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} -stdlib=libstdc++”)
> I’m not sure what the alternative to libstdc++ is.  Anyone know what we use?
> 
>> On 11 Jun 2019, at 19:21, Seth Hillbrand > > wrote:
>> 
>> On 2019-06-11 13:23, Jeff Young wrote:
>>> Do other folks debuggers have a hard time with these?  Mine won’t show
>>> me the contents of an OPT item, and it consistently lies about the
>>> size() of a std::deque.
>>> Cheers,
>>> Jeff.
>> 
>> Hi Jeff-
>> 
>> I use this [1] in gdb for STL containers.  Also, check out [2] for working 
>> with BOOST if your gdb is >7.0
>> 
>> Best-
>> Seth
>> 
>> 
>> [1] http://sourceware.org/ml/gdb/2008-02/msg00064.html 
>> 
>> [2] https://github.com/ruediger/Boost-Pretty-Printer 
>> 
> 
> ___
> 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

___
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

Re: [Kicad-developers] I've somehow broken my build...

[Bernhard Stegmaier]

The “sub-apps” shouldn’t have a Frameworks folder, but use the one from the 
“parent” Kicad.app (otherwise all the libs would be duplicated).

Did you maybe issue a “make install” in your build folder?
After that (I guess due to rewriting the paths, including all the dependencies, 
and all what happens while creating the bundle) the build folder is pretty 
borked.
I tried to continue to use it for usual development, but it had weird errors.
I usually just delete it after a “make install" and start from scratch.


Regards,
Bernhard

> On 26. May 2019, at 22:07, Jeff Young  wrote:
> 
> I can no longer run pl_editor.
> 
> It pukes trying to open dlls in 
> bin/Kicad.app/Contents/Applications/pl_editor.app/Contents/Frameworks/.
> 
> If I copy Frameworks/ from bin/Kicad.app/Contents/Frameworks/ then it works 
> fine (but nukes it the next time I build).
> 
> The other apps don’t have a Frameworks/ in their directory, but they seem to 
> work fine.
> 
> Any ideas?
> ___
> 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

___
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

Re: [Kicad-developers] 3D viewer only using lower-left quadrant?

[Bernhard Stegmaier]

Yes, it looks like that if you request to use full resolution but don’t get the 
backing scale stuff right (usually is 2, so you end up drawing only a quarter).

I’d guess that the rename of GetClientSize() to GetNativePixelSize() in 
HIDPI_GL_CANVAS wrapper is the bad guy… I don’t remember exactly, but I think 
this was an overload of some wx method to hide the backing scale stuff in 
Retina case from normal code.


Regards,
Bernhard

> On 17. Feb 2019, at 23:19, Nick Østergaard  wrote:
> 
> I think we also saw this a long time ago with hidpibdisplays. Maybe the 
> recent changes have undone something...
> 
> søn. 17. feb. 2019 23.17 skrev Tomasz Wlostowski  >:
> On 17/02/2019 23:04, Wayne Stambaugh wrote:
> > Looks fine on Linux.
> > 
> > On 2/17/19 4:50 PM, Jeff Young wrote:
> >> The 3D viewer on my machine is only using the lower-left quadrant.
> >>   Anyone else seeing this?
> 
> I noticed it a retina macbook too. Maybe a Retina-specific issue?
> 
> Tom
> 
> >>
> >>
> >> ___
> >> 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 
> >> 
> >>
> > 
> > ___
> > 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 
> > 
> 
> 
> ___
> 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 
> 
> ___
> 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

___
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

Re: [Kicad-developers] 5.0.1 Release Q

[Bernhard Stegmaier]

I did switch to Mojave almost all of my machines.
My (own) old builds run without any problem on all of the Mojave machines.

I just tried the latest nightly and it also works for me.
Only thing I have is that it sometimes doesn’t work on first start (nothing 
happens) but if I try again.
But, that’s something that I always had with the official builds… don’t know 
what the issues is here (I guess something with the security settings).

More details on this?


Regards
Bernhard

> On 29. Sep 2018, at 03:50, Adam Wolf  wrote:
> 
> I am not 100% up to speed on what's broken yet.
> 
> Just for clarifications, we have to compile our nightly builds with the 
> oldest SDK we want to support, not the newest.  The issues we've had when 
> 10.11, 10.12, and 10.13 came out were all issues where users on the new 
> version were unable to compile KiCad without special patches (either to KiCad 
> or to the dependencies)
> 
> I am surprised we have issues running our old binaries rather than in 
> compilation, but in computers, not only do things not work consistently, they 
> don't even break consistently! :)
> 
> 
> On Fri, Sep 28, 2018 at 8:40 PM Adam Wolf  > wrote:
> I've been out on business travel this week so I haven't been able to attend 
> to this at all.  This might not be a hard problem to fix, but sometimes it 
> takes a bit as it can be an issue in a dependency.
> 
> Between Seth and I this weekend I'm pretty sure we can get a good handle on 
> the problem, but solving it might take a few more days.
> 
> Adam
> 
> On Fri, Sep 28, 2018 at 4:16 PM Seth Hillbrand  > wrote:
> Hi Devs-
> 
> We currently have an issue where KiCad does not run at all on MacOS Mojave 
> that was just released.  It may just be a matter of re-running the full 
> compile using the Mojave SDK but we should get that running on our nightly 
> builds.
> 
> This normally might not be that big of an issue but the MacOS releases are 
> free downloads and get pushed pretty hard with pop-ups, so I expect many 
> users will upgrade soon with no downgrade path.
> 
> I know we were hoping to tag 5.0.1 this weekend but can we see if there need 
> to be any post-fixes to get the Mac building for Mojave before we do that?
> 
> Thanks-
> Seth
> ___
> 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 
> 
> ___
> 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

___
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

Re: [Kicad-developers] [KiCad/kicad-mac-builder] kicad-mac-builder-10.11-upload #75 failed (#206)

[Bernhard Stegmaier]

The changes I made to the old build scripts did automatically pull if there is 
something new.
I don’t know if those scripts are still in service…


Bernhard

> On 25. Aug 2018, at 20:00, Adam Wolf  wrote:
> 
> It may not pull from a tag.  It's actually easier for me to trigger a new 
> build from my phone than to browse the source. :P
> 
> Adam
> 
> On Sat, Aug 25, 2018, 12:01 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Oops.  Now pushed.
> 
>> On 25 Aug 2018, at 17:01, Bernhard Stegmaier > <mailto:stegma...@sw-systems.de>> wrote:
>> 
>> Did you push it?
>> I just looked an hour ago, but didn’t see any commit that added that…
>> 
>> @Adam:
>> Did you change to pull wxWidgets from a tag?
>> I didn’t know we have tags on our wxWidgets fork…?
>> Old scripts just checked for a change and pulled head of the branch.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 25. Aug 2018, at 17:10, Jeff Young >> <mailto:j...@rokeby.ie>> wrote:
>>> 
>>> BTW, do our build scripts do this automatically?
>>> 
>>>> On 25 Aug 2018, at 16:10, Jeff Young >>> <mailto:j...@rokeby.ie>> wrote:
>>>> 
>>>> Rats.  I meant to mention that folks on OSX will need to pull from our 
>>>> wxWidgets branch.
>>>> 
>>>> Cheers,
>>>> Jeff.
>>>> 
>>>>> On 25 Aug 2018, at 14:19, Adam Wolf >>>> <mailto:adamw...@feelslikeburning.com>> wrote:
>>>>> 
>>>>> Hi folks!
>>>>> 
>>>>> I saw this macOS build failure today.  Sometimes build failures are 
>>>>> flukes, but this looks like it might be legit.
>>>>> 
>>>>> Any thoughts?  I can dig into it more on Monday, but if someone wants to 
>>>>> take a look and see if something changed there, be my guest!
>>>>> 
>>>>> Adam Wolf
>>>>> 
>>>>> -- Forwarded message -
>>>>> From: wayneandlayneci >>>> <mailto:notificati...@github.com>>
>>>>> Date: Sat, Aug 25, 2018, 1:50 AM
>>>>> Subject: [KiCad/kicad-mac-builder] kicad-mac-builder-10.11-upload #75 
>>>>> failed (#206)
>>>>> To: KiCad/kicad-mac-builder >>>> <mailto:kicad-mac-buil...@noreply.github.com>>
>>>>> Cc: Subscribed >>>> <mailto:subscri...@noreply.github.com>>
>>>>> 
>>>>> 
>>>>> Build 'kicad-mac-builder-10.11-upload' is failing!
>>>>> 
>>>>> Last 50 lines of build output:
>>>>> 
>>>>> [...truncated 6.63 MB...]
>>>>> ==> default: 
>>>>> /usr/local/include/boost/ptr_container/detail/reversible_ptr_container.hpp:
>>>>> ==> default: 64:20: note: previous declaration is here
>>>>> ==> default: Container* cont;
>>>>> ==> default:^
>>>>> ==> default: 
>>>>> /vagrant/build/kicad/src/kicad/common/widgets/net_selector.cpp:184:27: 
>>>>> error: no member named 'OSXForceFocus' in 'wxListBox'
>>>>> ==> default: m_netListBox->OSXForceFocus();
>>>>> ==> default:   ^
>>>>> ==> default: 1 warning and 1 error generated.
>>>>> ==> default: make[6]: *** 
>>>>> [common/CMakeFiles/pcbcommon.dir/widgets/net_selector.cpp.o] Error 1
>>>>> ==> default: make[5]: *** [common/CMakeFiles/pcbcommon.dir/all] Error 2
>>>>> ==> default: make[4]: *** [all] Error 2
>>>>> ==> default: make[3]: *** [kicad/src/kicad-stamp/kicad-build] Error 2
>>>>> ==> default: make[2]: *** [CMakeFiles/kicad.dir/all] Error 2
>>>>> ==> default: make[1]: *** [CMakeFiles/package-kicad-nightly.dir/rule] 
>>>>> Error 2
>>>>> ==> default: make: *** [package-kicad-nightly] Error 2
>>>>> ==> default: Error while running make after rebuilding with a single job. 
>>>>> Please report this issue if you cannot fix it after reading the README.
>>>>> ==> default: build.py argument summary:
>>>>> ==> default: build_type: Debug
>>>>> ==> default: docs_tarball_url: 
>>>>> http://docs.kicad-pcb.org/master/kicad-doc-HEAD.tar.gz 
>>>>> <http://docs.kicad-pcb.org/master/kicad-doc-HEAD.tar.gz>
>>>>> ==> defa

Re: [Kicad-developers] [KiCad/kicad-mac-builder] kicad-mac-builder-10.11-upload #75 failed (#206)

[Bernhard Stegmaier]

Did you push it?
I just looked an hour ago, but didn’t see any commit that added that…

@Adam:
Did you change to pull wxWidgets from a tag?
I didn’t know we have tags on our wxWidgets fork…?
Old scripts just checked for a change and pulled head of the branch.


Regards,
Bernhard

> On 25. Aug 2018, at 17:10, Jeff Young  wrote:
> 
> BTW, do our build scripts do this automatically?
> 
>> On 25 Aug 2018, at 16:10, Jeff Young > > wrote:
>> 
>> Rats.  I meant to mention that folks on OSX will need to pull from our 
>> wxWidgets branch.
>> 
>> Cheers,
>> Jeff.
>> 
>>> On 25 Aug 2018, at 14:19, Adam Wolf >> > wrote:
>>> 
>>> Hi folks!
>>> 
>>> I saw this macOS build failure today.  Sometimes build failures are flukes, 
>>> but this looks like it might be legit.
>>> 
>>> Any thoughts?  I can dig into it more on Monday, but if someone wants to 
>>> take a look and see if something changed there, be my guest!
>>> 
>>> Adam Wolf
>>> 
>>> -- Forwarded message -
>>> From: wayneandlayneci >> >
>>> Date: Sat, Aug 25, 2018, 1:50 AM
>>> Subject: [KiCad/kicad-mac-builder] kicad-mac-builder-10.11-upload #75 
>>> failed (#206)
>>> To: KiCad/kicad-mac-builder >> >
>>> Cc: Subscribed >> >
>>> 
>>> 
>>> Build 'kicad-mac-builder-10.11-upload' is failing!
>>> 
>>> Last 50 lines of build output:
>>> 
>>> [...truncated 6.63 MB...]
>>> ==> default: 
>>> /usr/local/include/boost/ptr_container/detail/reversible_ptr_container.hpp:
>>> ==> default: 64:20: note: previous declaration is here
>>> ==> default: Container* cont;
>>> ==> default:^
>>> ==> default: 
>>> /vagrant/build/kicad/src/kicad/common/widgets/net_selector.cpp:184:27: 
>>> error: no member named 'OSXForceFocus' in 'wxListBox'
>>> ==> default: m_netListBox->OSXForceFocus();
>>> ==> default:   ^
>>> ==> default: 1 warning and 1 error generated.
>>> ==> default: make[6]: *** 
>>> [common/CMakeFiles/pcbcommon.dir/widgets/net_selector.cpp.o] Error 1
>>> ==> default: make[5]: *** [common/CMakeFiles/pcbcommon.dir/all] Error 2
>>> ==> default: make[4]: *** [all] Error 2
>>> ==> default: make[3]: *** [kicad/src/kicad-stamp/kicad-build] Error 2
>>> ==> default: make[2]: *** [CMakeFiles/kicad.dir/all] Error 2
>>> ==> default: make[1]: *** [CMakeFiles/package-kicad-nightly.dir/rule] Error 
>>> 2
>>> ==> default: make: *** [package-kicad-nightly] Error 2
>>> ==> default: Error while running make after rebuilding with a single job. 
>>> Please report this issue if you cannot fix it after reading the README.
>>> ==> default: build.py argument summary:
>>> ==> default: build_type: Debug
>>> ==> default: docs_tarball_url: 
>>> http://docs.kicad-pcb.org/master/kicad-doc-HEAD.tar.gz 
>>> 
>>> ==> default: footprints_ref: origin/master
>>> ==> default: jobs: 1
>>> ==> default: kicad_ref: origin/master
>>> ==> default: macos_min_version: 10.11
>>> ==> default: packages3d_ref: origin/master
>>> ==> default: release: False
>>> ==> default: release_name: None
>>> ==> default: retry_failed_build: True
>>> ==> default: symbols_ref: origin/master
>>> ==> default: target: ['package-kicad-nightly', 'package-extras', 
>>> 'package-kicad-unified']
>>> ==> default: templates_ref: origin/master
>>> ==> default: translations_ref: origin/master
>>> ==> default: Traceback (most recent call last):
>>> ==> default:   File "./build.py", line 218, in 
>>> ==> default: main()
>>> ==> default:   File "./build.py", line 214, in main
>>> ==> default: build(parsed_args)
>>> ==> default:   File "./build.py", line 186, in build
>>> ==> default: subprocess.check_call(make_command, env=dict(os.environ, 
>>> PATH=new_path))
>>> ==> default:   File 
>>> "/usr/local/Cellar/python@2/2.7.15_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
>>>  line 190, in check_call
>>> ==> default: raise CalledProcessError(retcode, cmd)
>>> ==> default: subprocess.CalledProcessError
>>> ==> default: : Command '['make', '-j1', 'package-kicad-nightly', 
>>> 'package-extras', 'package-kicad-unified']' returned non-zero exit status 2
>>> The SSH command responded with a non-zero exit status. Vagrant
>>> assumes that this means the command failed. The output for this command
>>> should be in the log above. Please read the output to determine what
>>> went wrong.
>>> Build step 'Execute shell' marked build as failure
>>> Archiving artifacts
>>> Recording fingerprints
>>> 
>>> Changes since last successful build:
>>> No changes
>>> 
>>> View full output 
>>> 
>>> —
>>> You are receiving this because you are subscribed to this thread.
>>> Reply to this email directly, view it on GitHub 
>>> 

Re: [Kicad-developers] KiCad v5 MacOS Library Editor - Error Cannot Load Aliases

[Bernhard Stegmaier]

Hi Andrey,

you might also want to check if you previously had some environment variables 
set in macOS itself to use libraries from a non-standard place.
If so, remove them and configure paths only via KiCad (Preferences => Configure 
Paths).


Regards,
Bernhard

> On 2. Aug 2018, at 06:32, Piotr Esden-Tempski  wrote:
> 
> Hey Andrey,
> 
> Do you happen to still have an old library index file? I had a similar issue 
> but not exactly the same one. I only had to delete/move 
> ~/Library/Preferences/kicad/fp-lib-table and things went back to normal. 
> Obviously I had to read my custom libraries that I had added before but it 
> was a quick fix to the problem. Manually editing the libraries in bulk using 
> the library manager was less appealing. :)
> 
> Hope this helps.
> 
> Cheers,
> Piotr
> 
> 
>> On Aug 1, 2018, at 9:14 PM, Andrey Kuznetsov > > wrote:
>> 
>> I asked here specifically because I kind of wanted to reach you, the guy who 
>> packaged macOS and knows kicad on mac.
>> 
>> It's a fresh install, I had old version, but I deleted them from 
>> Applications and from Application Support and then installed fresh.
>> I had no issued following the readme.
>> 
>> I'm confused why the Altera library is trying to load when it doesn't exist 
>> in application support library location :S
>> 
>> On Wed, Aug 1, 2018 at 9:10 PM, Adam Wolf > > wrote:
>> Hi Andrey!
>> 
>> In general, this list is not for user support.  Kicad.info 
>>  is a great
>> place for that.
>> 
>> This is not something I've seen before.
>> 
>> It would be good to know if you are migrating from a previous version
>> of KiCad, or starting fresh, and if you had issues following any of
>> the steps in the migration instructions for the README.
>> 
>> Adam
>> On Wed, Aug 1, 2018 at 10:54 PM Andrey Kuznetsov > > wrote:
>> >
>> > Hi,
>> >
>> > Just wanted to ping you guys, I got kicad installed on macOS and when I 
>> > opened the library editor I got hit with like 30 error messages, once for 
>> > each library saying Error cannot load aliases from library ***.
>> > Library like Altera, and a ton of others.
>> >
>> > Anyone know what's going on?
>> >
>> > This was on a new project.
>> >
>> > --
>> > Remember The Past, Live The Present, Change The Future
>> > Those who look only to the past or the present are certain to miss the 
>> > future [JFK]
>> >
>> > kandre...@gmail.com 
>> > Live Long and Prosper,
>> > Andrey
>> > ___
>> > 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 
>> > 
>> 
>> 
>> 
>> -- 
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the 
>> future [JFK]
>> 
>> kandre...@gmail.com 
>> Live Long and Prosper,
>> Andrey
>> ___
>> 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 
>> 
> ___
> 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

___
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

Re: [Kicad-developers] MacOS build issue with new geometry tests

[Bernhard Stegmaier]

Hi,

it’s not constexpr that breaks clang.
Usage of floating point isn’t valid in a constexpr (only literals allowed, 
floating point isn’t a literal)…
  https://en.cppreference.com/w/cpp/language/constexpr 



Regards,
Bernhard

> On 29. Jul 2018, at 17:34, John Beard  wrote:
> 
> ___

___
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

Re: [Kicad-developers] kicad version and install location

[Bernhard Stegmaier]

I wouldn’t rely on that.
You can set paths on macOS and at least I needed it to do in my setup before 
Wayne made the path configuration dialog.
So, I wouldn’t bet that there are no such macOS installs out there… :)


Regards,
Bernhard

> On 19. Jul 2018, at 06:07, Adam Wolf  wrote:
> 
> On Mac, we have the advantage of users not setting environment variables.  
> This makes me think this *could* potentially be feasible for 5.0, for MacOS.
> 
> However, I do not know if we would want this feature on one platform and not 
> the others. Thoughts?
> 
> On Mon, Jul 16, 2018, 12:40 PM Andy Peters  > wrote:
> On Jul 16, 2018, at 10:22 AM, Mark Roszko  > wrote:
> > 
> > Yeathats what I proposed too.
> > 
> > Every program on Windows that needs side-by-side installs just
> > versions both the config and install locations. Thats it.
> > 
> > EAGLE does it.
> > Visual Studio does.
> > Altium does it.
> > CLion does it.
> > All of Jetbrains other product do it.
> > Microsoft Word does it
> > Adobe does it.
> > Python does it.
> > MSSQL does it.
> > 
> > 
> > No need for crazy launcher args and extreme actions such as doing
> > something like RVM does
> > 
> > All that needs to be done, is find all instances of wxStandardPaths
> > being used for config location.
> > Replace it with a standard static function helper. In the helper, it
> > appends a version number to the location.
> > 
> > Thats it. Done. No need to require users to understand command line to
> > use a program.
> > 
> > It works for linux too.
> > /home/user/.kicad/
> > becomes
> > /home/user/.kicad/5.1/
> 
> And on the Mac that would be
> 
> /Users/andy/Library/Application Support/kicad 
> 
> becomes
> 
> /Users/andy/Library/Application Support/kicad/5.1
> 
> and /Users/andy/Library/Preferences/kicad 
> 
> becomes 
> 
> /Users/andy/Library/Preferences/kicad/5.1
> 
> -a
> ___
> 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

___
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

Re: [Kicad-developers] Jenkins e-mails?

[Bernhard Stegmaier]

Hmmm… just guessing, I just know what works for me…

AFAIK gmail strictly respects DMARC policies.

Jenkins mails come from "miguelan...@ajo.es <mailto:miguelan...@ajo.es>”.
ajo.es <http://ajo.es/> has a DMARC record, which enforces a 100% reject on 
“illegal” mails:
<<<
v=DMARC1;p=reject;pct=100
>>>
It also has a SPF entry
<<<
v=spf1 a:cpanel.optimizacionweb.es -all
>>>

Jenkins mails don’t have a DKIM signature at all.
So, I guess both DKIM and SPF checks will fail at gmail.
As a result, it will reject the mail as “spam”.


Regards,
Bernhard

> On 29. Jun 2018, at 18:35, Seth Hillbrand  wrote:
> 
> Thanks for digging into this.  I use GMail.  The last notification I received 
> from Jenkins was Dec 2017.  I see now that others have been receiving them as 
> I get the replies they send quoting the original.
> 
> The messages are not in Spam, so there's something else going on.  Does 
> anyone on the list using Gmail receive the messages?
> -S
> 
> Am Fr., 29. Juni 2018 um 09:24 Uhr schrieb Bernhard Stegmaier 
> mailto:stegma...@sw-systems.de>>:
> I checked and I also got the kicad-qa Jenkins mail Seth mentioned.
> 
> No, I don’t use gmail.
> I am running my own mail server.
> 
> I had a quick look into the mail headers and server logs for such a Jenkins 
> mail.
> I didn’t see anything suspicious that would prevent delivery (at least with 
> my config and spam filtering).
> 
> 
> Regards,
> Bernhard
> 
>> On 29. Jun 2018, at 16:56, Nick Østergaard > <mailto:oe.n...@gmail.com>> wrote:
>> 
>> Ok thanks, yes those are the ones. 
>> 
>> Do you use gmail, or what could possibly be the issue here? Clearly the 
>> emails reach the dev list.
>> 
>> fre. 29. jun. 2018 14.52 skrev Bernhard Stegmaier > <mailto:stegma...@sw-systems.de>>:
>> Just FYI… I do receive them, see attached.
>> Or, do you mean different ones?
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> 
>> 
>> 
>> -- Forwarded message --
>> From: Miguel Angel Ajo mailto:miguelan...@ajo.es>>
>> To: kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Cc: 
>> Bcc: 
>> Date: Fri, 29 Jun 2018 14:10:13 +0200 (CEST)
>> Subject: [Kicad-developers] Build failed in Jenkins: 
>> linux-kicad-full-gcc-head #3621
>> See 
>> <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/3621/display/redirect 
>> <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/3621/display/redirect>>
>> 
>> --
>> Started by upstream project "any-kicad-mirror-head" build number 2546
>> originally caused by:
>>  Started by remote host 91.189.89.26 with note: Something was pushed to the 
>> launchpad repo
>> Building remotely on docker-34ae3216798f61 on docker 
>> (docker_ubuntu-16.04_ssh) in workspace 
>> <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/ws/ 
>> <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/ws/>>
>> Cloning the remote Git repository
>> Cloning repository https://git.launchpad.net/kicad 
>> <https://git.launchpad.net/kicad>
>>  > git init <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/ws/ 
>> <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/ws/>> # timeout=10
>> Fetching upstream changes from https://git.launchpad.net/kicad 
>> <https://git.launchpad.net/kicad>
>>  > git --version # timeout=10
>>  > git fetch --tags --progress https://git.launchpad.net/kicad 
>> <https://git.launchpad.net/kicad> +refs/heads/*:refs/remotes/origin/*
>> ERROR: Error cloning remote repo 'origin'
>> hudson.plugins.git.GitException: Command "git fetch --tags --progress 
>> https://git.launchpad.net/kicad 
>> <https://git.launchpad.net/kicad>+refs/heads/*:refs/remotes/origin/*" 
>> returned status code 128:
>> stdout: 
>> stderr: remote: Counting objects: 1750   remote: Counting objects: 
>> 4345   remote: Counting objects: 7156   remote: Counting 
>> objects: 9611   remote: Counting objects: 12393   remote: 
>> Counting objects: 15719   remote: Counting objects: 20690   
>> remote: Counting objects: 21028   remote: Counting objects: 21302
>>remote: Counting objects: 21637   remote: Counting objects: 
>> 21840   remote: Counting objects: 22246   remote: Counting 
>> objects: 22441   remote: Counting objects: 22797   remote: 
&

Re: [Kicad-developers] Jenkins e-mails?

[Bernhard Stegmaier]

I checked and I also got the kicad-qa Jenkins mail Seth mentioned.

No, I don’t use gmail.
I am running my own mail server.

I had a quick look into the mail headers and server logs for such a Jenkins 
mail.
I didn’t see anything suspicious that would prevent delivery (at least with my 
config and spam filtering).


Regards,
Bernhard

> On 29. Jun 2018, at 16:56, Nick Østergaard  wrote:
> 
> Ok thanks, yes those are the ones. 
> 
> Do you use gmail, or what could possibly be the issue here? Clearly the 
> emails reach the dev list.
> 
> fre. 29. jun. 2018 14.52 skrev Bernhard Stegmaier  <mailto:stegma...@sw-systems.de>>:
> Just FYI… I do receive them, see attached.
> Or, do you mean different ones?
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> 
> -- Forwarded message --
> From: Miguel Angel Ajo mailto:miguelan...@ajo.es>>
> To: kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Cc: 
> Bcc: 
> Date: Fri, 29 Jun 2018 14:10:13 +0200 (CEST)
> Subject: [Kicad-developers] Build failed in Jenkins: 
> linux-kicad-full-gcc-head #3621
> See 
> <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/3621/display/redirect 
> <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/3621/display/redirect>>
> 
> --
> Started by upstream project "any-kicad-mirror-head" build number 2546
> originally caused by:
>  Started by remote host 91.189.89.26 with note: Something was pushed to the 
> launchpad repo
> Building remotely on docker-34ae3216798f61 on docker 
> (docker_ubuntu-16.04_ssh) in workspace 
> <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/ws/ 
> <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/ws/>>
> Cloning the remote Git repository
> Cloning repository https://git.launchpad.net/kicad 
> <https://git.launchpad.net/kicad>
>  > git init <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/ws/ 
> <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/ws/>> # timeout=10
> Fetching upstream changes from https://git.launchpad.net/kicad 
> <https://git.launchpad.net/kicad>
>  > git --version # timeout=10
>  > git fetch --tags --progress https://git.launchpad.net/kicad 
> <https://git.launchpad.net/kicad> +refs/heads/*:refs/remotes/origin/*
> ERROR: Error cloning remote repo 'origin'
> hudson.plugins.git.GitException: Command "git fetch --tags --progress 
> https://git.launchpad.net/kicad 
> <https://git.launchpad.net/kicad>+refs/heads/*:refs/remotes/origin/*" 
> returned status code 128:
> stdout: 
> stderr: remote: Counting objects: 1750   remote: Counting objects: 
> 4345   remote: Counting objects: 7156   remote: Counting 
> objects: 9611   remote: Counting objects: 12393   remote: 
> Counting objects: 15719   remote: Counting objects: 20690   
> remote: Counting objects: 21028   remote: Counting objects: 21302 
>   remote: Counting objects: 21637   remote: Counting objects: 
> 21840   remote: Counting objects: 22246   remote: Counting 
> objects: 22441   remote: Counting objects: 22797   remote: 
> Counting objects: 23552   remote: Counting objects: 23776   
> remote: Counting objects: 24005   remote: Counting objects: 24415 
>   remote: Counting objects: 24798   remote: Counting objects: 
> 24991   remote: Counting objects: 25547   remote: Counting 
> objects: 25818   remote: Counting objects: 26171   remote: 
> Counting objects: 26
>  496   remote: Counting objects: 26804   remote: Counting 
> objects: 27149   remote: Counting objects: 27670   remote: 
> Counting objects: 28076   remote: Counting objects: 29076   
> remote: Counting objects: 29664   remote: Counting objects: 30001 
>   remote: Counting objects: 31107   remote: Counting objects: 
> 31554   remote: Counting objects: 32159   remote: Counting 
> objects: 32707   remote: Counting objects: 33350   remote: 
> Counting objects: 33401   remote: Counting objects: 34225   
> remote: Counting objects: 37877   remote: Counting objects: 42433 
>   remote: Counting objects: 45342   remote: Counting objects: 
> 48789   remote: Counting objects: 52295   remote: Counting 
> objects: 55820   remote: Counting objects: 58656   remote: 
> Counting objects: 62159   remote: Counting objects: 65000   
> remote: Counting 
>  objects: 69185  

Re: [Kicad-developers] Jenkins e-mails?

[Bernhard Stegmaier]

Just FYI… I do receive them, see attached.Or, do you mean different ones?Regards,Bernhard--- Begin Message ---
See 


--
Started by upstream project "any-kicad-mirror-head" build number 2546
originally caused by:
 Started by remote host 91.189.89.26 with note: Something was pushed to the 
launchpad repo
Building remotely on docker-34ae3216798f61 on docker (docker_ubuntu-16.04_ssh) 
in workspace 
Cloning the remote Git repository
Cloning repository https://git.launchpad.net/kicad
 > git init  # 
 > timeout=10
Fetching upstream changes from https://git.launchpad.net/kicad
 > git --version # timeout=10
 > git fetch --tags --progress https://git.launchpad.net/kicad 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git fetch --tags --progress 
https://git.launchpad.net/kicad +refs/heads/*:refs/remotes/origin/*" returned 
status code 128:
stdout: 
stderr: remote: Counting objects: 1750   remote: Counting objects: 4345 
  remote: Counting objects: 7156   remote: Counting objects: 
9611   remote: Counting objects: 12393   remote: Counting 
objects: 15719   remote: Counting objects: 20690   remote: 
Counting objects: 21028   remote: Counting objects: 21302   
remote: Counting objects: 21637   remote: Counting objects: 21840   
remote: Counting objects: 22246   remote: Counting objects: 22441   
remote: Counting objects: 22797   remote: Counting objects: 
23552   remote: Counting objects: 23776   remote: Counting 
objects: 24005   remote: Counting objects: 24415   remote: 
Counting objects: 24798   remote: Counting objects: 24991   
remote: Counting objects: 25547   remote: Counting objects: 25818   
remote: Counting objects: 26171   remote: Counting objects: 26
 496   remote: Counting objects: 26804   remote: Counting 
objects: 27149   remote: Counting objects: 27670   remote: 
Counting objects: 28076   remote: Counting objects: 29076   
remote: Counting objects: 29664   remote: Counting objects: 30001   
remote: Counting objects: 31107   remote: Counting objects: 31554   
remote: Counting objects: 32159   remote: Counting objects: 
32707   remote: Counting objects: 33350   remote: Counting 
objects: 33401   remote: Counting objects: 34225   remote: 
Counting objects: 37877   remote: Counting objects: 42433   
remote: Counting objects: 45342   remote: Counting objects: 48789   
remote: Counting objects: 52295   remote: Counting objects: 55820   
remote: Counting objects: 58656   remote: Counting objects: 
62159   remote: Counting objects: 65000   remote: Counting 
 objects: 69185   remote: Counting objects: 72640   remote: 
Counting objects: 77637   remote: Counting objects: 82726   
remote: Counting objects: 86684   remote: Counting objects: 90249   
remote: Counting objects: 97047   remote: Counting objects: 101580  
 remote: Counting objects: 105322   remote: Counting objects: 
110104   remote: Counting objects: 114827   remote: Counting 
objects: 120296   remote: Counting objects: 124368   remote: 
Counting objects: 128094   remote: Counting objects: 128517   
remote: Counting objects: 132214   remote: Counting objects: 136128 
  remote: Counting objects: 140115   remote: Counting objects: 
141826   remote: Counting objects: 144949   remote: Counting 
objects: 148695   remote: Counting objects: 151908   remote: 
Counting objects: 156485   remote: Counting objects: 157535
 , done.
remote: Compressing objects:   0% (1/45564)   remote: Compressing 
objects:   1% (456/45564)   remote: Compressing objects:   1% 
(867/45564)   remote: Compressing objects:   2% (912/45564)   
remote: Compressing objects:   3% (1367/45564)   remote: Compressing 
objects:   4% (1823/45564)   remote: Compressing objects:   4% 
(1927/45564)   remote: Compressing objects:   5% (2279/45564)   
remote: Compressing objects:   6% (2734/45564)   remote: Compressing 
objects:   6% (2835/45564)   remote: Compressing objects:   7% 
(3190/45564)   remote: Compressing objects:   8% (3646/45564)   
remote: Compressing objects:   8% (3885/45564)   remote: Compressing 
objects:   9% 

Re: [Kicad-developers] [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.

[Bernhard Stegmaier]

Adam, does the patch fix STEP export for both kicad.app and standalone pcbnew?
If not, if you like I could try to have a look at the weekend if we can add 
some check for standalone to get both working for v5 now.
I don’t know exactly, but I think there should be similar stuff in the code 
already…


Bernhard

> On 15. Jun 2018, at 18:39, Adam Wolf  wrote:
> 
> I would even commit to adding a comment saying "Adam says this is
> temporary and should be removed during the V6 development efforts", so
> folks can more easily shame me if it ends up staying around for longer
> than expected :)
> 
> Adam
> On Fri, Jun 15, 2018 at 11:34 AM Wayne Stambaugh  wrote:
>> 
>> I'm not opposed to this patch if it's merely a short tern solution to a
>> larger problem.  I would rather macos support STEP export for v5.
>> Hopefully a cleaner long term solution can be found as part of the v6
>> development as the patch adds some rather ugly #ifdef/#endif code.
>> 
>> Cheers,
>> 
>> Wayne
>> 
>> On 06/15/2018 10:13 AM, Seth Hillbrand wrote:
>>> Hi Adam/Bernhard-
>>> 
>>> Thanks for the excellent background and what looks like a good plan
>>> during v6.  If I understand correctly, the thought is that this patch is
>>> temporary for v5 and will be addressed with the rest of the paths during v6.
>>> 
>>> If that is correct, does anyone have objections to this patch for MacOS?
>>> 
>>> -S
>>> 
>>> Am Fr., 15. Juni 2018 um 05:04 Uhr schrieb Adam Wolf
>>> mailto:adamw...@feelslikeburning.com>>:
>>> 
>>>Thanks Bernhard for the clear responses.
>>> 
>>>1) The only current issue with signing is that the standalone
>>>launchers both live inside and outside the bundle.  With all the
>>>work I've done on packaging since V4, we can now give kicad.app a
>>>valid signature, but there's no way to sign the subbundles that
>>>allows them to be both external and internal to KiCad.app.
>>> 
>>>2) I have a few ideas for how to make it work for V6, but my primary
>>>one is the same as yours.  If kicad.app opened .pro files, but also
>>>.schs and .kicad_pcbs and other files, and used filenames or
>>>something in order to pick which mode to open up in, the signing
>>>problem goes away. As soon as V5 is out, I'm planning on opening a
>>>discussion on it here.
>>> 
>>>3) Thanks so much for your help on KiCad!
>>> 
>>>Regarding this patch, I think there are a few options.  We can do
>>>nothing, fix-up validation so you can only export STEP from either
>>>standalone or kicad.app.  We could make make some logical functions
>>>like isStandaloneExecutable and GetPathToKiCad or something like
>>>that.  We could add more comments, maybe even aiming people at this
>>>discussion?  We could rewrite it in a different way.  We could fix
>>>it in packaging--we could copy kicad2step to multiple directories,
>>>and make it work that way.  I can also leave the patch in the
>>>packaging scripts, but that leaves this broken for anyone who
>>>doesn't use them.
>>> 
>>>Some of these I like, others I don't, but no matter which one we
>>>choose, as soon as V5 is out the door, I'm taking it out.  I don't
>>>want it to be egregiously bad, since it'll probably live in the
>>>stable release for a while, but at the same point, I'm not married
>>>to any of the ideas.
>>> 
>>>Thanks everyone for the discussion.  Discussions like this help
>>>elucidate parts of the code that few people touch, and that helps
>>>make KiCad even better. We are really close to the best Kicad
>>>release yet!
>>> 
>>>Adam Wolf
>>> 
>>>On Fri, Jun 15, 2018 at 3:20 AM Bernhard Stegmaier
>>>mailto:stegma...@sw-systems.de>> wrote:
>>>> 
>>>> And, for the path stuff…
>>>> 
>>>> I think it needs a complete cleanup.
>>>> There are paths spread all over the code (directly or indirect by
>>>putting some path fragments together)… for plugins, templates,
>>>user-folders, help files, etc.
>>>> Worse, all those places are also full of platform #ifdef’s which
>>>doesn’t make it more easy…
>>>> 
>>>> I think it shouldn’t be allowed to have paths anywhere in the code.
>>>> Instead, everything should be in some cent

Re: [Kicad-developers] [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.

[Bernhard Stegmaier]

And, for the path stuff…

I think it needs a complete cleanup.
There are paths spread all over the code (directly or indirect by putting some 
path fragments together)… for plugins, templates, user-folders, help files, etc.
Worse, all those places are also full of platform #ifdef’s which doesn’t make 
it more easy…

I think it shouldn’t be allowed to have paths anywhere in the code.
Instead, everything should be in some central configuration class where they 
can be configured in a consistent way for all platforms.
I guess there shouldn’t be that much paths involved, otherwise no user will 
understand where to put things anyway (sometimes I feel that exactly this is 
happening at the moment).

I did cleanup some things for macOS when I did the packaging stuff long ago 
(only use things like GetOSXKicadDataDir() from common.cpp where appropriate).
But, I didn’t understand kicad and its intended (folder) structures (especially 
for Linux/Windows) enough at that point in time, so I gave up…


Regards,
Bernhard

> On 15. Jun 2018, at 06:58, Adam Wolf  wrote:
> 
> The symlinked subbundles date back to the original KiCad mac packaging
> work, before V4 came out.  There is a pretty massive amount of code in
> our CMake and KiCad already that support how this works.  I think
> Bernhard was the main driver of this work, but I am not sure.
> Specifically, the relative paths are already in KiCad source at least
> 2 other time.  I am not sure why kicad2step got added the way it did.
> I was not involved.
> 
> Removing all of the symlinked subbundles is actually part of my V6
> work, because KiCad.app is not signable until it doesn't have these,
> but that's not a small undertaking.
> 
> Maybe Bernhard can weigh in more?
> 
> Adam Wolf
> On Thu, Jun 14, 2018 at 10:27 PM Seth Hillbrand
>  wrote:
>> 
>> 
>> Hi Adam-
>> 
>> Is there a reason why the kicad2step is installed in the KiCad base 
>> application rather than the pcbnew application?  I didn't look into this in 
>> depth but I wonder if we can avoid code dealing with a specific packaging 
>> scenario?
>> 
>> Alternatively, we might put a variable in CMAKE defining where these 
>> applications are installed and reference that in the code.  Hard-coding the 
>> relative paths feels like asking for trouble.
>> 
>> Thoughts?
>> -S
>> 
>> 
>> Am Do., 14. Juni 2018 um 05:41 Uhr schrieb Adam Wolf 
>> :
>>> 
>>> Yeah, this is actually all over the source code.  I'm starting to collect a 
>>> list of them for V6... but I shall say no more until I'm ready with V5 :)
>>> 
>>> On Thu, Jun 14, 2018, 3:32 AM Nick Østergaard  wrote:
>>>> 
>>>> Ok.
>>>> 
>>>> 2018-06-14 9:37 GMT+02:00 Bernhard Stegmaier :
>>>>> 
>>>>> I didn’t test this patch, but… something like a install prefix path is 
>>>>> not valid for a bundle.
>>>>> A bundle is a self-contained entity and has no fixed location. You can 
>>>>> put it wherever you want.
>>>>> So, everything has to be relative to main binary or bundle location.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Bernhard
>>>>> 
>>>>> 
>>>>> On 14. Jun 2018, at 08:51, Nick Østergaard  wrote:
>>>>> 
>>>>> It seems a bit strange to be that relative paths like that has to be 
>>>>> used, can't some cmake install prefix path be used wheni is a bundle? Is 
>>>>> this also how it is done for other parts of kicad?
>>>>> 
>>>>> 2018-06-13 4:39 GMT+02:00 Adam Wolf :
>>>>>> 
>>>>>> Hi folks!
>>>>>> 
>>>>>> This patch is meant to fix a crash Seth found when exporting STEP from
>>>>>> standalone pcbnew on macOS.
>>>>>> 
>>>>>> Thanks!  My apologies for having this so late in the cycle.  this is
>>>>>> going to be an amazing release for everyone, especially macOS users!
>>>>>> 
>>>>>> Adam Wolf
>>>>>> 
>>>>>> ___
>>>>>> 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
>>>>>> 
>>>>> 
>>>>> ___
>>>>> Mailing list: htt

Re: [Kicad-developers] [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.

[Bernhard Stegmaier]

Yes, that’s more or less what I made long ago.

Basically everything is packed into the main kicad app.
This was done to have all the dependencies only in one place.

There is just one kicad app.
"Apps" like pcbnew are not really apps, but it is main kicad binary/executable 
(project manager) which loads the pcbnew.kiface “plugin”.
The “standalone” apps are not really standalone sub-bundles.
They just contain a single small standalone binary which again pull in the 
xxx.kiface plugins/libs.
You cannot move the “standalone" (sub-)applications like pcbnew out of this 
package as it would break (relative) linkage for the standalone case.

So, I think wrt this idea it is correct where things are right now.

This was a design decision back then and mimics what happens on Linux/Windows.
There, the pcbnew binary also is not really a standalone pcbnew binary, but 
just a small wrapper that loads the pcbnew.kiface.

Of course, you could make a completely self-contained version of the standalone 
pcbnew app.
But, this means pulling all dependencies and all needed kicad “plugins” into it.
This means that bundles will get way bigger as you duplicate basically 
everything… might not be a problem nowadays.

What I don’t like about it is that if you have real bundles you are also free 
to move the individual parts around.
I could imagine that users can create a mess keeping version x of pcbnew here, 
having version y of kicad there, and so on.

And, it could make things worse with something like plugins.
I don’t know if everything is already cleanly implemented that all user plugin 
stuff is taken from some single user folder (except supplied stuff).
I read posts where users put stuff into the bundle (which is equivalent to 
putting to /usr/share on Linux)… yes, it shouldn’t be done, but they will be 
totally confused why they have to put it into 2 bundles...

So, the kicad notion of the “standalone” apps doesn’t really fit that one of a 
single application per bundle.
I think the only solution has been mentioned already on the list.
In my opinion it would the cleanest way to ditch these “standalone” apps.
Instead, offer options to open a pcb/schematic from project manager without a 
project.
Then, there is just one application (kicad aka the project manager) and 
everything is fine.
I don’t know if this is feasible with current architecture of kiface plugins.

@Adam:
What aspect of the sub-bundles causes problems with signing?
The bundles themselves or just the links?
How do you plan to “fix” this?


Regards,
Bernhard


> On 15. Jun 2018, at 06:58, Adam Wolf  wrote:
> 
> The symlinked subbundles date back to the original KiCad mac packaging
> work, before V4 came out.  There is a pretty massive amount of code in
> our CMake and KiCad already that support how this works.  I think
> Bernhard was the main driver of this work, but I am not sure.
> Specifically, the relative paths are already in KiCad source at least
> 2 other time.  I am not sure why kicad2step got added the way it did.
> I was not involved.
> 
> Removing all of the symlinked subbundles is actually part of my V6
> work, because KiCad.app is not signable until it doesn't have these,
> but that's not a small undertaking.
> 
> Maybe Bernhard can weigh in more?
> 
> Adam Wolf
> On Thu, Jun 14, 2018 at 10:27 PM Seth Hillbrand
>  wrote:
>> 
>> 
>> Hi Adam-
>> 
>> Is there a reason why the kicad2step is installed in the KiCad base 
>> application rather than the pcbnew application?  I didn't look into this in 
>> depth but I wonder if we can avoid code dealing with a specific packaging 
>> scenario?
>> 
>> Alternatively, we might put a variable in CMAKE defining where these 
>> applications are installed and reference that in the code.  Hard-coding the 
>> relative paths feels like asking for trouble.
>> 
>> Thoughts?
>> -S
>> 
>> 
>> Am Do., 14. Juni 2018 um 05:41 Uhr schrieb Adam Wolf 
>> :
>>> 
>>> Yeah, this is actually all over the source code.  I'm starting to collect a 
>>> list of them for V6... but I shall say no more until I'm ready with V5 :)
>>> 
>>> On Thu, Jun 14, 2018, 3:32 AM Nick Østergaard  wrote:
>>>> 
>>>> Ok.
>>>> 
>>>> 2018-06-14 9:37 GMT+02:00 Bernhard Stegmaier :
>>>>> 
>>>>> I didn’t test this patch, but… something like a install prefix path is 
>>>>> not valid for a bundle.
>>>>> A bundle is a self-contained entity and has no fixed location. You can 
>>>>> put it wherever you want.
>>>>> So, everything has to be relative to main binary or bundle location.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Bernhard
>>>>&g

Re: [Kicad-developers] [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.

[Bernhard Stegmaier]

I didn’t test this patch, but… something like a install prefix path is not 
valid for a bundle.
A bundle is a self-contained entity and has no fixed location. You can put it 
wherever you want.
So, everything has to be relative to main binary or bundle location.


Regards,
Bernhard

> On 14. Jun 2018, at 08:51, Nick Østergaard  wrote:
> 
> It seems a bit strange to be that relative paths like that has to be used, 
> can't some cmake install prefix path be used wheni is a bundle? Is this also 
> how it is done for other parts of kicad?
> 
> 2018-06-13 4:39 GMT+02:00 Adam Wolf  >:
> Hi folks!
> 
> This patch is meant to fix a crash Seth found when exporting STEP from
> standalone pcbnew on macOS.
> 
> Thanks!  My apologies for having this so late in the cycle.  this is
> going to be an amazing release for everyone, especially macOS users!
> 
> Adam Wolf
> 
> ___
> 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 
> 
> 
> 
> ___
> 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

___
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

Re: [Kicad-developers] Copy/Paste Zones

[Bernhard Stegmaier]

No problem, I’ll file it.


Regards,
Bernhard

> On 26. Apr 2018, at 21:56, Seth Hillbrand <seth.hillbr...@gmail.com> wrote:
> 
> Ah, that makes sense.
> 
> It's easy enough to change but I think that there are probably use cases both 
> ways.  Let's put this in a wishlist for V6 to implement a "Paste Special" 
> where you can check/uncheck paste options.  Would you be up for filing this?
> 
> -S
> 
> Am Do., 26. Apr. 2018 um 11:10 Uhr schrieb Bernhard Stegmaier 
> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>>:
> Hi Seth,
> 
> no worries… :)
> 
> My mainuse-case is a GND-zone that connects (mainly decoupling) capacitor to 
> vias like this:
> 
> 
> 
> For the same package all those zones look the same and I usually just 
> copy/paste them.
> As it is now, I have to select every copy and assign the correct net 
> afterwards.
> 
> 
> Regards,
> Bernhard
> 
>> On 26. Apr 2018, at 19:58, Seth Hillbrand <seth.hillbr...@gmail.com 
>> <mailto:seth.hillbr...@gmail.com>> wrote:
>> 
>> ​Hi Bernhard-
>> 
>> Sorry this question got lost in the traffic.​  Currently all netcodes get 
>> cleared when pasting.  This makes sense for most items but maybe not for 
>> zones?  It seems this could go either way.  Do you have a use case in mind?
>> 
>> -S
>> 
>> 
>> Am So., 25. März 2018 um 02:43 Uhr schrieb Bernhard Stegmaier 
>> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>>:
>> Hi all,
>> 
>> if I copy/paste a zone, the pasted one doesn’t have a net assigned.
>> Is it intended this way?
>> I would expect that the pasted one gets the net of the original one.
>> 
>> 
>> Regards,
>> Bernhard
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
> 
> 

___
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

Re: [Kicad-developers] Copy/Paste Zones

[Bernhard Stegmaier]

Hi Seth,

no worries… :)

My mainuse-case is a GND-zone that connects (mainly decoupling) capacitor to 
vias like this:



For the same package all those zones look the same and I usually just 
copy/paste them.
As it is now, I have to select every copy and assign the correct net afterwards.


Regards,
Bernhard

> On 26. Apr 2018, at 19:58, Seth Hillbrand <seth.hillbr...@gmail.com> wrote:
> 
> ​Hi Bernhard-
> 
> Sorry this question got lost in the traffic.​  Currently all netcodes get 
> cleared when pasting.  This makes sense for most items but maybe not for 
> zones?  It seems this could go either way.  Do you have a use case in mind?
> 
> -S
> 
> 
> Am So., 25. März 2018 um 02:43 Uhr schrieb Bernhard Stegmaier 
> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>>:
> Hi all,
> 
> if I copy/paste a zone, the pasted one doesn’t have a net assigned.
> Is it intended this way?
> I would expect that the pasted one gets the net of the original one.
> 
> 
> Regards,
> Bernhard
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>

___
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

Re: [Kicad-developers] wxPython-gtk3 woes

[Bernhard Stegmaier]

> On 11. Apr 2018, at 19:18, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> On 4/11/2018 11:02 AM, Bernhard Stegmaier wrote:
>> 
>> 
>>> On 11. Apr 2018, at 16:40, Wayne Stambaugh <stambau...@gmail.com
>>> <mailto:stambau...@gmail.com>> wrote:
>>> 
>>>> 
>>>> Last point: Is there a list of issue detected with GTK3 ? Some bugs are
>>>> tagged with that ?
>>> 
>>> Not that I am aware of.  Some of the related bug reports may be tagged
>>> with gtk3 but I'm not sure.  If not, that would be a good thing so we
>>> can start correcting some of them during the v6 development cycle.
>> 
>> AFAIK gtk3 also doesn’t support XOR-drawing?
>> So, legacy canvases will probably be as bad or even worse than on macOS…
>> at least, regarding performance.
> 
> I believe (although I could be wrong) all that happened with regard to
> gtk3 is that wxDC == wxGCDC which draws on the advanced
> wxGraphicsContext object which AFAIK supports transparency so XOR
> drawing should not be an issue.  The perform issue can probably solved
> by drawing to a wxMemoryDC first and blitting it to the display.

The thing is how the wxGCDC is implemented on top of gtk? or other stuff.

macOS also uses the wxGCDC but although defined in wxGCDC in the 
backend/macOS-specific implementation the XOR is just not implemented (but 
mapped to some other function) because macOS doesn’t support it (it does 
support a XOR blending mode, but that is different from the logical XOR meant 
here).

I thought that I read somewhere (long time ago, when I tried to understand why 
it doesn’t work on macOS) that gtk3 also will not have a logical XOR, but maybe 
I just got that wrong or things have changed. I didn’t follow up on that.

As far as I can remember Orson made some changes not long ago to redraw 
everything every time in case of gtk3 (I tested the patch and it was bad for 
performance on macOS)… this shouldn’t be needed if XOR would work?


Regards,
Bernhard
___
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

Re: [Kicad-developers] wxPython-gtk3 woes

[Bernhard Stegmaier]

> On 11. Apr 2018, at 16:40, Wayne Stambaugh  wrote:
> 
>> 
>> Last point: Is there a list of issue detected with GTK3 ? Some bugs are
>> tagged with that ?
> 
> Not that I am aware of.  Some of the related bug reports may be tagged
> with gtk3 but I'm not sure.  If not, that would be a good thing so we
> can start correcting some of them during the v6 development cycle.

AFAIK gtk3 also doesn’t support XOR-drawing?
So, legacy canvases will probably be as bad or even worse than on macOS… at 
least, regarding performance.


Regards
Bernhard

___
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

[Kicad-developers] Copy/Paste Zones

[Bernhard Stegmaier]

Hi all,

if I copy/paste a zone, the pasted one doesn’t have a net assigned.
Is it intended this way?
I would expect that the pasted one gets the net of the original one.


Regards,
Bernhard
___
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

Re: [Kicad-developers] Build failure

[Bernhard Stegmaier]

First thing I did with QTCreator is to delete all of the default 
(build/release/etc) build configurations that it sets up when 
creating/importing a project.
Then, I created my own one with the settings I need for KiCad (especially build 
options and paths).
I didn’t have any problems since then.

I can send you my configuration later on, maybe it helps…


Regards,
Bernhard

> On 23. Mar 2018, at 01:33, Jeff Young  wrote:
> 
> Based on Seth’s "cache cruft" comment I whacked my CMakeCache.txt entirely, 
> and my cmd-line build is running again from kicad/build/.  
> 
> I’m afraid to run QTCreator again, though.
> 
>> On 23 Mar 2018, at 00:20, Jeff Young > > wrote:
>> 
>> I think used to do a “make install” inside kicad/build/.  But now it says it 
>> doesn’t have an install target.  (And if I do a “make” that’s when I get the 
>> OCE errors.)
>> 
>> “make install” works one level higher (in kicad/), but then spews out a 
>> whole bunch of CMakeFiles directories as siblings to build/ which pollute my 
>> git status.
>> 
>> 
>> 
>>> On 23 Mar 2018, at 00:14, Jeff Young >> > wrote:
>>> 
>>> It complains that it doesn’t have a CMake dialog available.
>>> 
>>> Could someone dump in their cmake command (and indicate what directory it 
>>> is executed from)?
>>> 
>>> Thanks
>>> Jeff.
>>> 
>>> 
 On 22 Mar 2018, at 23:32, Seth Hillbrand > wrote:
 
 Hi Jeff-
 
 I assume you have a populated cmake build directory.  If so, you can run 
 "make edit_cache" and you should be see what is toggled on and off and 
 adjust.  Then hit "c" to reconfigure and "g" to generate your makefiles.  
 You can also delete cache entries using this tool, in case there is cruft 
 from a previous config.
 
 You should only see that message if cmake thinks you are trying to enable 
 OCE.  I don't see any recent changes that would have affected this option. 
 (my OpenCascade patch is not in the tree yet)
 
 -S
 
 2018-03-22 16:20 GMT-07:00 Jeff Young >:
 No, I don’t have Seth’s patch (to my knowledge).  I assume it’s something 
 I would have had to install?
 
 I’m not sure what’s different.  I was trying to get it to build with 
 scripting on and the wheels came off…
 
 Cheers,
 Jeff.
 
 
> On 22 Mar 2018, at 23:09, Nick Østergaard  > wrote:
> 
> Do you have Seth's opencascade patch in your tree? Or what is different 
> from the usual? The build flag you are specifying shoulnd be correct IIRC.
> 
> 2018-03-22 23:56 GMT+01:00 Jeff Young  >:
> What does this mean:
> 
> By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
> asked CMake to find a package configuration file provided by "OCE", but
> CMake did not find one.
> 
> Could not find a package configuration file provided by "OCE" (requested
> version 0.16) with any of the following names:
> 
> OCEConfig.cmake
> oce-config.cmake
> 
> Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
> to a directory containing one of the above files. If "OCE" provides a
> separate development package or SDK, be sure it has been installed.
> 
> I thought I had avoided this stuff by specifying:
> 
> -DKICAD_USE_OCE=OFF \
> 
> but it seems to be back.
> 
> ___
> 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 
> 
> 
> 
 
 
 ___
 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 
 
 
 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> 
>>> Post to : kicad-developers@lists.launchpad.net 
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers 

Re: [Kicad-developers] Lib maintainers request help for reviewing installation script changes

[Bernhard Stegmaier]

What do you mean with “Xcode to build KiCad” (or, what do you want to do)?
Usually KiCad is built with clang from Xcode, so yes.

Xcode itself is only an IDE.
You definitely can use Xcode to edit source files or to debug KiCad built with 
usual cmake command line (just create an “empty" project which points to the 
binary).

I guess there is some way to tell Xcode to call an external builder (cmake) 
instead of managing building itself, but I never tried that.
You also could try to generate a Xcode project with cmake, but I also never 
tried that.

If you just want a free IDE the easy way, try QTCreator (due to its cmake 
support)...


Regards,
Bernhard

> On 22. Mar 2018, at 16:59, Jean-Paul Louis  wrote:
> 
> I Have a question for the OS X developers here.
> Are you using Xcode to build KiCAD? 
> I would like to get started on building KiCAD with Xcode, 
> so I am looking for some clues or advice if this is not
> possible/practical.
> 
> Thanks to all of you for a great product.
> 
> Jean-Paul
> N1JPL
> 
> 
>> On Mar 22, 2018, at 11:46 AM, Adam Wolf  
>> wrote:
>> 
>> This will break the nightlies for macOS, as the packaging scripts
>> currently work around the fact that they didn't previously work on
>> macOS with modifications.
>> 
>> Is this something Nick or I can adjust the current nightlies to over
>> the weekend, and then we make the cutover in the middle of next week?
>> 
>> Another option is that we just make the cutover now, and a few nights
>> of nightlies break.
>> 
>> Normally I'd be able to just make the change right away but I'm
>> spending all of my KiCad time trying to get the new macOS packaging
>> ready so I don't hold up V5.
>> 
>> Adam
>> 
>> On Thu, Mar 22, 2018 at 10:39 AM, Seth Hillbrand
>>  wrote:
>>> CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is a relatively recent addition
>>> to cmake.  Maybe 3.7 or so?  I'd hesitate using that in the install script
>>> yet but maybe that's overly cautious.  If you do use it, we need to bump the
>>> minimum version at the top as well.
>>> 
>>> -S
>>> 
>>> 
>>> 2018-03-22 7:20 GMT-07:00 Wayne Stambaugh :
 
 Looks fine to me but I would like one of our macos packagers to confirm
 the install path changes that are specific to macos before we merge them.
 
 On 3/22/2018 10:13 AM, Rene Pöschl wrote:
> Dear developers,
> 
> we lib maintainers might be good at checking symbols and footprints
> against datasheets, the KLC and industry standards but we are a bit lost
> with the requirements of installation scripts.
> 
> Could one of you take a look at the changes in the following pull
> requests?
> 
> 
> - https://github.com/KiCad/kicad-packages3D/pull/284
> 
> - https://github.com/KiCad/kicad-symbols/pull/409
> 
> - https://github.com/KiCad/kicad-footprints/pull/450
> 
> 
> ___
> 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
 
 ___
 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
>>> 
>>> 
>>> 
>>> ___
>>> 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
>>> 
>> 
>> ___
>> 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
> 
> 
> ___
> 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


___
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

Re: [Kicad-developers] CvPcb Save

[Bernhard Stegmaier]

On a second thought it is basically just another special “Symbol Table” edit 
dialog.

The problem of losing a lot of unsaved work in case of a crash is also there 
for the “Symbol Table” dialog.
I could hack in a lot of valuable data in custom fields and although this 
dialog has an “Apply” button, you can’t save there.
I don’t know if some autosave would take care of it…

So, however it is done wrt save/apply it should be the same for both “dialogs”.


Regards,
Bernhard

> On 20. Mar 2018, at 18:55, Jon Evans <j...@craftyjon.com> wrote:
> 
> Yeah I also agree that it should be basically a dialog of eeschema rather 
> than a separate program, so I guess it makes sense to write changes 
> immediately to the in-memory schematic, and mark it as unsaved for the user 
> to consciously hit the save button later if desired.
> 
> -Jon
> 
> On Tue, Mar 20, 2018 at 1:52 PM, Russell Oliver <roliver8...@gmail.com 
> <mailto:roliver8...@gmail.com>> wrote:
> I second Bernhard's comments. 
> I think it shouldn't seem like a separate program, just another dialog of 
> eeschema that takes the what you see is what you get approach. 
> As long as the footprint references are valid the schematic should be updated 
> when the dialog is closed, and marked modified if there was a change. 
> Saving the schematic to file is then done through eeschema proper. 
> 
> Russell 
> 
> On Wed, 21 Mar 2018 04:40 Bernhard Stegmaier, <stegma...@sw-systems.de 
> <mailto:stegma...@sw-systems.de>> wrote:
> Just my 2 cents…
> I would immediately write back any change in cvpcb to schematic. 
> I never understood why I have to hit the button to do that.
> There is no PCB preview or something like that in cvpcb, so I have to apply 
> all changes anyway to check them directly in the PCB.
> Then, keep the button and save schematic with it.
> 
> 
> Regards,
> Bernhard
> 
>> On 20. Mar 2018, at 18:28, Jon Evans <j...@craftyjon.com 
>> <mailto:j...@craftyjon.com>> wrote:
>> 
>> Why don't you like the idea of saving the schematic when you hit the save 
>> button? That seems like a reasonable expected behavior to me at least.
>> 
>> (I dislike nag dialogs especially when they seem to have no purpose)
>> 
>> -Jon
>> 
>> On Tue, Mar 20, 2018 at 1:26 PM, Jeff Young <j...@rokeby.ie 
>> <mailto:j...@rokeby.ie>> wrote:
>> CvPcb has a Save command (complete with disk icon).  Only it doesn’t do 
>> that.  (It simply writes the changes back to eeschema.)
>> 
>> If it were a dialog, I’d say that’s not good.  But this is CvPcb, where you 
>> could easily spend an hour making associations (hitting save every few 
>> minutes), only to have your machine and/or Kicad go down with all your 
>> changes.  That’s borderline horrific.
>> 
>> I don’t like the idea of blind-saving the eeschema document, but I think 
>> that would be better than what we have now.
>> 
>> Another idea would be to trigger an auto-save for each CvPcb save.  It’s not 
>> ideal because the user may think that there aren’t any changes in their 
>> eeschema file and therefore ignore the auto-save warning when restarting.
>> 
>> Yet another idea would be to foist the decision on the user with a “Save 
>> your schematic?” dialog every time you save in CvPcb.  That’s pretty hard to 
>> love, but with Orson’s new KIDIALOG we could at least have a “don’t ask me 
>> again” checkbox.  Maybe that’s not so bad….
>> 
>> Thoughts?
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers

Re: [Kicad-developers] CvPcb Save

[Bernhard Stegmaier]

Just my 2 cents…
I would immediately write back any change in cvpcb to schematic. 
I never understood why I have to hit the button to do that.
There is no PCB preview or something like that in cvpcb, so I have to apply all 
changes anyway to check them directly in the PCB.
Then, keep the button and save schematic with it.


Regards,
Bernhard

> On 20. Mar 2018, at 18:28, Jon Evans  wrote:
> 
> Why don't you like the idea of saving the schematic when you hit the save 
> button? That seems like a reasonable expected behavior to me at least.
> 
> (I dislike nag dialogs especially when they seem to have no purpose)
> 
> -Jon
> 
> On Tue, Mar 20, 2018 at 1:26 PM, Jeff Young  > wrote:
> CvPcb has a Save command (complete with disk icon).  Only it doesn’t do that. 
>  (It simply writes the changes back to eeschema.)
> 
> If it were a dialog, I’d say that’s not good.  But this is CvPcb, where you 
> could easily spend an hour making associations (hitting save every few 
> minutes), only to have your machine and/or Kicad go down with all your 
> changes.  That’s borderline horrific.
> 
> I don’t like the idea of blind-saving the eeschema document, but I think that 
> would be better than what we have now.
> 
> Another idea would be to trigger an auto-save for each CvPcb save.  It’s not 
> ideal because the user may think that there aren’t any changes in their 
> eeschema file and therefore ignore the auto-save warning when restarting.
> 
> Yet another idea would be to foist the decision on the user with a “Save your 
> schematic?” dialog every time you save in CvPcb.  That’s pretty hard to love, 
> but with Orson’s new KIDIALOG we could at least have a “don’t ask me again” 
> checkbox.  Maybe that’s not so bad….
> 
> Thoughts?
> ___
> 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 
> 
> 
> ___
> 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

___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

Hi again,

just wanted to share some of my OpenMP on macOS experience, FWIW:

I used both clang-5.0.1 and clang-6.0 from MacPorts.
KiCad builds fine with it.

It works fine on my build machine (b).
On my MacBook (a) such a build always crashes when ratsnest changes after I 
opened the PCB (e.g. move/update a footprint).
Initial ratsnest on opening the PCB is for whatever reason OK.
On a third machine (c) it crashes just like on (a).

There is some OpenMP stuff in the ratsnest code.
On my build machine I can stress the ratsnest code by moving a component around.
It is really using multiple threads according to CPU load.

That’s with clang-6.0.

A previous build with clang-5.0 doesn’t show this crash with ratsnest, but the 
3d-viewer hang/crash problems I asked about in the other mail.
Again, 3d-viewer in OpenGL mode doesn’t work on my MacBook, but perfectly works 
on my build machine (same PCB, of course).

In backtraces of crashes always libomp task stuff is involved.

(b) and (c) are still on macOS 10.12, (a) is on 10.13.
It doesn’t seem to be about macOS version, because on one 10.12 machine the 
build is working, on the other not.

Of course, all machines are different HW. 
(b) is a 2012 i7. The other machines are a 2012 i5 and i3.
I even did a local build of libomp on my MacBook to rule out that it might use 
some i7 specific stuff that doesn’t run on i5/i3.
Didn’t help, I get the same crashes.

At the moment, I don’t really know what’s going on.
I looked at the code both for the 3d-viewer problem and the ratsnest stuff, but 
I don’t see anything being obviously wrong.
Of course, I don’t claim that I have understood every detail of it and I am no 
OpenMP expert.
It obviously works on a lot of linux boxes, so I guess it can’t be that wrong.

If someone wants to try the build:
  https://drive.google.com/open?id=1rpuKYxpHZTk5YiWe8s3LhIssHxJ9Y1oh 
<https://drive.google.com/open?id=1rpuKYxpHZTk5YiWe8s3LhIssHxJ9Y1oh>
I’d be happy to hear if it works or not, especially with OpenGL 3d-viewer 
and/or the rats nest use-case.


Regards,
Bernhard

> On 3. Mar 2018, at 20:33, Bernhard Stegmaier <stegma...@sw-systems.de> wrote:
> 
> Hi all,
> 
> So, I played around a bit to get OpenMP and GCD into something like a 
> “parallel_for” wrapper which either uses OpenMP or GCD.
> Unfortunately, OpenMP seems to require that the “for” statement directly 
> follows the “#pragma omg for …”.
> That currently killed all my attempts to define such a “parallel_for” (as 
> function, #define, ?) so that the code will stay the same for both.
> One option would be to pull the “#pragma omp for …” into the wrapper, but I 
> guess this is not really acceptable (since you can’t specify any specific 
> schedule parameters any longer).
> 
> I will think about it some more just because of the challenge… but I am not 
> very optimistic at the moment to get something nice.
> If anyone else has a nice idea, I’d be very interested to learn freaky new 
> stuff… :)
> 
> On the other side, I looked at using a non-Xcode OpenMP capable clang.
> The only caveat seems to be not to mix standard C++ libraries (in the past 
> libc++/libstdc++ haven’t been compatible in some aspects - didn’t try to find 
> out if that is resolved).
> Default on macOS now is libc++, but it seems that at least MacPorts builds 
> clang with libstdc++ per default (no idea why).
> The MacPorts build can easily be switched to libc++.
> That clang-mp builds KiCad without problems even if dependencies have been 
> built with Xcode clang.
> Everything seems to work as expected, multithreading is there where it should 
> be.
> 
> So, for now it seems to be the most easy solution to switch to a suitable 
> non-Xcode clang for building packages - if we want to have OpenMP for macOS.
> 
> AFAIK our build machines use Homebrew.
> Seems as if Homebrew decides which standard library to use depending on macOS 
> version (https://docs.brew.sh/C++-Standard-Libraries 
> <https://docs.brew.sh/C++-Standard-Libraries>).
> So, if everything is recent enough it might not be a problem at all… like it 
> obviously also has been for Seth below.
> 
> 
> Regards,
> Bernhard
> 
>> On 1. Mar 2018, at 17:47, Seth Hillbrand <seth.hillbr...@gmail.com 
>> <mailto:seth.hillbr...@gmail.com>> wrote:
>> 
>> Hi All-
>> 
>> I was playing with this last night (don't normally compile on the mac) and 
>> found that using homebrew's llvm 3.8.1 seems to compile fine with -fopenmp.  
>> Running some OMP test code from 
>> https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5 
>> <https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5> 
>> shows expected result of 4 threads.  I didn't get OpenMP errors when 
>> compiling KiCad although I didn'

Re: [Kicad-developers] [PATCH] macOS CFBundleName

[Bernhard Stegmaier]

I guess it just is like that because the Linux binaries are also written like 
that and it has always been like that… :)


Regards,
Bernhard

> On 4. Mar 2018, at 23:37, Michael Kavanagh  wrote:
> 
> The attached trivial patch fixes the app menubar items to match the
> window titles, as well as when you "Quicklook" an executable, in
> activity monitor and probably some other places as well.
> 
> As a side is there any reason why the bundle/symlink names aren't
> capitalised/contain underscores instead of spaces? See attached
> screenshot.
> 
> Regards,
> Michael
> <0001-macOS-standardise-CFBundleName-to-application-names.patch> 2018-03-04 at 17.39.07.png>___
> 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


___
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

Re: [Kicad-developers] Jumpy canvas on other platforms?

[Bernhard Stegmaier]

Do a “fit to window” and then pan left/right… I use the touchpad.
After “fit to window” there is no scrollbar.
When the scrollbar comes back due to panning, I see almost always a small shift 
of the whole view down and then up again.
Sometimes, but not always if you just pan left/right it will make this small 
jump downwards every time you cross center, just as if it would “snap" to 
middle position.

> On 4. Mar 2018, at 21:25, Jon Evans  wrote:
> 
> Maybe I don't really understand what you mean, but I can't see any jumpiness 
> on Linux when panning around (with middle-mouse drag).
> What do you mean by "it automatically fits to window, so there's not really 
> any place to go"?  It does not do any kind of auto-fitting except for the 
> zoom-extents on file load on Linux, and I don't have my Mac machine handy to 
> compare.
> 
> On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young  > wrote:
> If I open an eeschema file on OSX and pan around (it automatically fits to 
> window, so there’s not really any place to go), the screen jumps around a 
> bit.  True also on other platforms, or Mac-specific?
> 
> Thanks,
> Jeff.
> ___
> 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 
> 
> 
> ___
> 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

___
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

Re: [Kicad-developers] Mac HighDPI performance

[Bernhard Stegmaier]

I would judge it wrt eeschema GAL conversion.
If that starts with v6, I don’t know if it is worth the effort.
If it is unsure when this will happen, it might be worth it.


> On 4. Mar 2018, at 20:30, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> Ughh!  I don't have a good answer for this one.  My best guess is to fix
> the wx macos code first and see what performance issues are left.  The
> problem with messing with any of this is that if you break something it
> will break all of the legacy canvas rendering not just the schematic
> editor.  I would move extremely carefully here.  I would prefer that we
> don't go too crazy this late in the v5 release cycle.  If the
> performance is truly not usable on macos, then we may have no choice.
> 
> On 03/04/2018 02:07 PM, Jeff Young wrote:
>> It turns out the fonts aren’t really the problem.
>> 
>> It starts with this gem in wxWidgets:
>> 
>>voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)
>> 
>>{
>> 
>>#if1
>> 
>>SetNeedsDisplay();
>> 
>>#else
>> 
>>//Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.
>> 
>>if(GetNeedsDisplay())
>> 
>>{
>> 
>>SetNeedsDisplay() ;
>> 
>>}
>> 
>>NSRectr=wxToNSRect([m_osxViewsuperview],*rect);
>> 
>>NSSizeoffset=NSMakeSize((float)dx,(float)dy);
>> 
>>[m_osxViewscrollRect:rby:offset];
>> 
>>#endif
>> 
>>}
>> 
>> 
>> SetNeedsDisplay() with no rectangle argument invalidates the entire window.
>> 
>> Even if you fix that (to scroll most of the window and only invalidate
>> the newly-exposed parts), you run into this:
>> 
>>voidwxWidgetCocoaImpl::drawRect(void*rect,WXWidgetslf,void*WXUNUSED(_cmd))
>> 
>>{
>> 
>>//preparingtheupdateregion
>> 
>>wxRegionupdateRgn;
>> 
>> 
>>
>> //sinceaddingmanyrectstoaregionisacostlyprocess,bydefaultusetheboundingrect
>> 
>>#if0
>> 
>>constNSRect*rects;
>> 
>>NSIntegercount;
>> 
>>[slfgetRectsBeingDrawn::];
>> 
>>for(inti=0;i<count;++i)
>> 
>>{
>> 
>>updateRgn.Union(wxFromNSRect(slf,rects[i]));
>> 
>>}
>> 
>>#else
>> 
>>updateRgn.Union(wxFromNSRect(slf,*(NSRect*)rect));
>> 
>>#endif
>> 
>> 
>> …which will /also/ cause the whole window to be repainted if there’s
>> both an invalidated horizontal strip and a vertical one.
>> 
>> And the latter turns out to be pretty much guaranteed by this one, which
>> batches repaints:
>> 
>>voidwxNonOwnedWindow::Update()
>> 
>>{
>> 
>>if(clock()-s_lastFlush>CLOCKS_PER_SEC/30)
>> 
>>{
>> 
>>s_lastFlush=clock();
>> 
>>m_nowpeer->Update();
>> 
>>}
>> 
>>}
>> 
>> 
>> But even Kicad isn’t blameless.  Once you fix all those there’s still no
>> checking in SCH_SCREEN::Draw() to see if the individual draw items
>> intersect the update region.  (Sure, the actually drawing is clipped in
>> the end, but you still go through a /lot/ of code to get there.)
>> 
>> All of these are fixable, and we’ve already crossed the Rubicon of
>> having our own OSX wxWidgets branch.  
>> 
>> But it’s still a reasonable amount of work, with a non-trivial risk
>> profile.  Should I continue?
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>> 
>>> On 4 Mar 2018, at 01:30, Bernhard Stegmaier <stegma...@sw-systems.de
>>> <mailto:stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>>> wrote:
>>> 
>>> No.
>>> 
>>>> On 4. Mar 2018, at 01:51, Andrey Kuznetsov <kandre...@gmail.com 
>>>> <mailto:kandre...@gmail.com>
>>>> <mailto:kandre...@gmail.com <mailto:kandre...@gmail.com>>> wrote:
>>>> 
>>>> Would it be an easy fix to change the text/font such that it does not
>>>> affect performance so significantly on MacOS?
>>>> 
>>>> On Sat, Mar 3, 2018 at 5:20 AM, Wayne Stambaugh <stambau...@gmail.com 
>>>> <mailto:stambau...@gmail.com>
>>>> <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> wrote:
>>>> 
>>>>On 03/03/2018 07:33 AM, Jeff Young wrote:
>>>> 
>>>>Hi Andrey,
>>>> 
>>>>I did some profi

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

Wayne, I am seeing the same funny stuff on my old Debian box.
I didn’t follow up, because I thought it might have to do something with my 
OpenGL setup… it’s an old Core2Duo which I usually don’t use, so it is not that 
good maintained.

But, the first picture is the OpenGL renderer, so this one is OK?


Bernhard

> On 4. Mar 2018, at 20:20, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> I'm not seeing any crash on Debian testing but there is some rather
> amusing artifacts on the rendering.  It looks like all of my 3D models
> have been deconstructed to tiny bits all over the model space.  Last
> time I checked it was fine on windows.
> 
> On 03/04/2018 02:06 PM, Maciej Suminski wrote:
>> Bernhard,
>> 
>> I suppose this is about raytrace rendering? Anyway, I see it crashing
>> even without any design loaded. 3D viewer passes the first phase so I
>> see the design rendered, but during 'Post processing shader' stage it
>> crashes.
>> 
>> Cheers,
>> Orson
>> 
>> On 03/04/2018 07:36 PM, Bernhard Stegmaier wrote:
>>> Hi all,
>>> 
>>> could please anybody test the following on a Windows/Linux OpenMP version?
>>> 
>>> I have a PCB with only components placed (via “Update from Schematic”), no 
>>> routing done yet.
>>> Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer.
>>> Now, edit a footprint (“e”) and do a “Update Footprint from Library” for 
>>> only this footprint (no changes in footprint needed).
>>> Open 3d-viewer again.
>>> 
>>> Or:
>>> Open PCB as above with only components and no routing yet.
>>> Make sure that 3d-viewer in OpenGL mode is fine, close 3d-viewer.
>>> Delete some of the components and reimport them vie “Update PCB from 
>>> Schematic”.
>>> Open 3d-viewer again.
>>> 
>>> In both cases my OpenMP builds (clang-5.0.1 with libomp-3.1) crash or hang 
>>> (all cores at 100%, grey window, nothing happens) 3d-viewer .
>>> It doesn’t hang/crash in my non-OpenMP builds.
>>> 
>>> If I save the PCB after the changes, close and reopen KiCad, then 3d-viewer 
>>> of OpenMP build is also fine again.
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
>>>> On 3. Mar 2018, at 20:33, Bernhard Stegmaier <stegma...@sw-systems.de> 
>>>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> So, I played around a bit to get OpenMP and GCD into something like a 
>>>> “parallel_for” wrapper which either uses OpenMP or GCD.
>>>> Unfortunately, OpenMP seems to require that the “for” statement directly 
>>>> follows the “#pragma omg for …”.
>>>> That currently killed all my attempts to define such a “parallel_for” (as 
>>>> function, #define, ?) so that the code will stay the same for both.
>>>> One option would be to pull the “#pragma omp for …” into the wrapper, but 
>>>> I guess this is not really acceptable (since you can’t specify any 
>>>> specific schedule parameters any longer).
>>>> 
>>>> I will think about it some more just because of the challenge… but I am 
>>>> not very optimistic at the moment to get something nice.
>>>> If anyone else has a nice idea, I’d be very interested to learn freaky new 
>>>> stuff… :)
>>>> 
>>>> On the other side, I looked at using a non-Xcode OpenMP capable clang.
>>>> The only caveat seems to be not to mix standard C++ libraries (in the past 
>>>> libc++/libstdc++ haven’t been compatible in some aspects - didn’t try to 
>>>> find out if that is resolved).
>>>> Default on macOS now is libc++, but it seems that at least MacPorts builds 
>>>> clang with libstdc++ per default (no idea why).
>>>> The MacPorts build can easily be switched to libc++.
>>>> That clang-mp builds KiCad without problems even if dependencies have been 
>>>> built with Xcode clang.
>>>> Everything seems to work as expected, multithreading is there where it 
>>>> should be.
>>>> 
>>>> So, for now it seems to be the most easy solution to switch to a suitable 
>>>> non-Xcode clang for building packages - if we want to have OpenMP for 
>>>> macOS.
>>>> 
>>>> AFAIK our build machines use Homebrew.
>>>> Seems as if Homebrew decides which standard library to use depending on 
>>>> macOS version (https://docs.brew.sh/C++-Standard-Libraries 
>>>> <https://docs.brew.sh/C++-Standard-Librarie

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

Orson,

no, the raytracing renderer is completely fine in that use-cases.

It is only the OpenGL renderer.
I first noticed the hang when I switched back from Raytracing to OpenGL 
(obviously after I did one of the 2 use-cases).

If it crashes, I get a backtrace of the crashing thread as follows
<<<
Thread 3 Crashed:
0   libomp.dylib0x000109c728e2 
__kmp_release_queuing_lock + 165
1   _pcbnew.kiface  0x000111a1aaa3 
CLAYER_TRIANGLES::AddToMiddleContourns(std::__1::vector<glm::tvec2<float, 
(glm::precision)0>, std::__1::allocator<glm::tvec2<float, (glm::precision)0> > 
> const&, float, float, bool) + 1011
2   _pcbnew.kiface  0x000111a1ad52 
CLAYER_TRIANGLES::AddToMiddleContourns(SHAPE_LINE_CHAIN const&, float, float, 
double, bool) + 546
3   _pcbnew.kiface  0x000111a1b228 .omp_outlined. + 248
4   libomp.dylib0x000109c81b93 
__kmp_invoke_microtask + 147
5   libomp.dylib0x000109c587b7 
__kmp_invoke_task_func + 156
6   libomp.dylib0x000109c57e88 __kmp_launch_thread 
+ 267
7   libomp.dylib0x000109c79e6f 
__kmp_launch_worker(void*) + 588
8   libsystem_pthread.dylib 0x7fff6735b6c1 _pthread_body + 340
9   libsystem_pthread.dylib 0x7fff6735b56d _pthread_start + 377
10  libsystem_pthread.dylib 0x7fff6735ac5d thread_start + 13
>>>

The main thread looks similar.
<<<
Thread 0:: Dispatch queue: com.apple.main-thread
0   libomp.dylib0x000109c728e2 
__kmp_release_queuing_lock + 165
1   _pcbnew.kiface  0x000111a1aaa3 
CLAYER_TRIANGLES::AddToMiddleContourns(std::__1::vector<glm::tvec2<float, 
(glm::precision)0>, std::__1::allocator<glm::tvec2<float, (glm::precision)0> > 
> const&, float, float, bool) + 1011
2   _pcbnew.kiface  0x000111a1ad52 
CLAYER_TRIANGLES::AddToMiddleContourns(SHAPE_LINE_CHAIN const&, float, float, 
double, bool) + 546
3   _pcbnew.kiface  0x000111a1b228 .omp_outlined. + 248
4   libomp.dylib0x000109c81b93 
__kmp_invoke_microtask + 147
5   libomp.dylib0x000109c587b7 
__kmp_invoke_task_func + 156
6   libomp.dylib0x000109c557dc __kmp_fork_call + 
4682
7   libomp.dylib0x000109c4d1fb __kmpc_fork_call + 
183
8   _pcbnew.kiface  0x000111a1b114 
CLAYER_TRIANGLES::AddToMiddleContourns(SHAPE_POLY_SET const&, float, float, 
double, bool) + 628
9   _pcbnew.kiface  0x000111a126ae 
C3D_RENDER_OGL_LEGACY::generate_holes_display_list(std::__1::list<COBJECT2D*, 
std::__1::allocator<COBJECT2D*> > const&, SHAPE_POLY_SET const&, float, float, 
bool) + 462
10  _pcbnew.kiface  0x000111a12d39 
C3D_RENDER_OGL_LEGACY::reload(REPORTER*) + 1545
11  _pcbnew.kiface  0x000111a16e02 
C3D_RENDER_OGL_LEGACY::Redraw(bool, REPORTER*) + 306
12  _pcbnew.kiface  0x000111a09124 
EDA_3D_CANVAS::OnPaint(wxPaintEvent&) + 628
>>>

I am not really familiar with OpenMP, but the AddToMiddleContourns methods look 
good in terms of synchronization (well, at first glance).


Regards,
Bernhard

> On 4. Mar 2018, at 20:06, Maciej Suminski <maciej.sumin...@cern.ch> wrote:
> 
> Bernhard,
> 
> I suppose this is about raytrace rendering? Anyway, I see it crashing
> even without any design loaded. 3D viewer passes the first phase so I
> see the design rendered, but during 'Post processing shader' stage it
> crashes.
> 
> Cheers,
> Orson
> 
> On 03/04/2018 07:36 PM, Bernhard Stegmaier wrote:
>> Hi all,
>> 
>> could please anybody test the following on a Windows/Linux OpenMP version?
>> 
>> I have a PCB with only components placed (via “Update from Schematic”), no 
>> routing done yet.
>> Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer.
>> Now, edit a footprint (“e”) and do a “Update Footprint from Library” for 
>> only this footprint (no changes in footprint needed).
>> Open 3d-viewer again.
>> 
>> Or:
>> Open PCB as above with only components and no routing yet.
>> Make sure that 3d-viewer in OpenGL mode is fine, close 3d-viewer.
>> Delete some of the components and reimport them vie “Update PCB from 
>> Schematic”.
>> Open 3d-viewer again.
>> 
>> In both cases my OpenMP builds (clang-5.0.1 with libomp-3.1) crash or hang 
>> (all cores at 100%, grey window, nothing happens) 3d-viewer .
>> It doesn’t hang/crash in my non-OpenMP builds.
>> 
>> If I save the PC

Re: [Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

[Bernhard Stegmaier]

Please note that the fix is only needed with a non-Xcode clang.
My cmake is 3.10.x, I had the problem both with clang-5.0.1 and clang-6.0 from 
MacPorts.
clang-6.0 only did work because it defaults to C++-14.

Xcode clang is fine without the change.


Bernhard

> On 4. Mar 2018, at 19:15, Seth Hillbrand <seth.hillbr...@gmail.com> wrote:
> 
> I see no issues on Mac OS.
> 
> -S
> 
> 
> 
> On Mar 4, 2018 10:00 AM, "Wayne Stambaugh" <stambau...@gmail.com 
> <mailto:stambau...@gmail.com>> wrote:
> I didn't notice any issues on linux builds.  Has anyone else confirmed
> this doesn't break anything on macos builds?
> 
> On 03/04/2018 07:26 AM, Bernhard Stegmaier wrote:
> > Hi,
> >
> > Attached patch fixes building on macOS with non-Xcode clang:
> > * To avoid problems make documentation suggest that 
> > cmake_minimum_required(...) has to be the very first statement directly 
> > followed by project(...)
> > * Policy CMP0025 must be set with min version <3.1 to NEW otherwise cmake 
> > will ignore CMAKE_CXX_STANDARD with non-Xcode clang
> >
> > Tested on macOS with native and non-Xcode clang.
> >
> >
> > Regards,
> > Bernhard
> >
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net 
> > <mailto:kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > <https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp 
> > <https://help.launchpad.net/ListHelp>
> >
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>
> ___
> 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

___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

Hi all,

could please anybody test the following on a Windows/Linux OpenMP version?

I have a PCB with only components placed (via “Update from Schematic”), no 
routing done yet.
Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer.
Now, edit a footprint (“e”) and do a “Update Footprint from Library” for only 
this footprint (no changes in footprint needed).
Open 3d-viewer again.

Or:
Open PCB as above with only components and no routing yet.
Make sure that 3d-viewer in OpenGL mode is fine, close 3d-viewer.
Delete some of the components and reimport them vie “Update PCB from Schematic”.
Open 3d-viewer again.

In both cases my OpenMP builds (clang-5.0.1 with libomp-3.1) crash or hang (all 
cores at 100%, grey window, nothing happens) 3d-viewer .
It doesn’t hang/crash in my non-OpenMP builds.

If I save the PCB after the changes, close and reopen KiCad, then 3d-viewer of 
OpenMP build is also fine again.


Regards,
Bernhard

> On 3. Mar 2018, at 20:33, Bernhard Stegmaier <stegma...@sw-systems.de> wrote:
> 
> Hi all,
> 
> So, I played around a bit to get OpenMP and GCD into something like a 
> “parallel_for” wrapper which either uses OpenMP or GCD.
> Unfortunately, OpenMP seems to require that the “for” statement directly 
> follows the “#pragma omg for …”.
> That currently killed all my attempts to define such a “parallel_for” (as 
> function, #define, ?) so that the code will stay the same for both.
> One option would be to pull the “#pragma omp for …” into the wrapper, but I 
> guess this is not really acceptable (since you can’t specify any specific 
> schedule parameters any longer).
> 
> I will think about it some more just because of the challenge… but I am not 
> very optimistic at the moment to get something nice.
> If anyone else has a nice idea, I’d be very interested to learn freaky new 
> stuff… :)
> 
> On the other side, I looked at using a non-Xcode OpenMP capable clang.
> The only caveat seems to be not to mix standard C++ libraries (in the past 
> libc++/libstdc++ haven’t been compatible in some aspects - didn’t try to find 
> out if that is resolved).
> Default on macOS now is libc++, but it seems that at least MacPorts builds 
> clang with libstdc++ per default (no idea why).
> The MacPorts build can easily be switched to libc++.
> That clang-mp builds KiCad without problems even if dependencies have been 
> built with Xcode clang.
> Everything seems to work as expected, multithreading is there where it should 
> be.
> 
> So, for now it seems to be the most easy solution to switch to a suitable 
> non-Xcode clang for building packages - if we want to have OpenMP for macOS.
> 
> AFAIK our build machines use Homebrew.
> Seems as if Homebrew decides which standard library to use depending on macOS 
> version (https://docs.brew.sh/C++-Standard-Libraries 
> <https://docs.brew.sh/C++-Standard-Libraries>).
> So, if everything is recent enough it might not be a problem at all… like it 
> obviously also has been for Seth below.
> 
> 
> Regards,
> Bernhard
> 
>> On 1. Mar 2018, at 17:47, Seth Hillbrand <seth.hillbr...@gmail.com 
>> <mailto:seth.hillbr...@gmail.com>> wrote:
>> 
>> Hi All-
>> 
>> I was playing with this last night (don't normally compile on the mac) and 
>> found that using homebrew's llvm 3.8.1 seems to compile fine with -fopenmp.  
>> Running some OMP test code from 
>> https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5 
>> <https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5> 
>> shows expected result of 4 threads.  I didn't get OpenMP errors when 
>> compiling KiCad although I didn't really notice a substantial difference in 
>> speed for the quick tests I was running.  Maybe with more involved 
>> operations.
>> 
>> I'm not sure if this will require us to distribute a different libstdc++ 
>> with KiCad.  Probably.  Does that seem feasible to the packing team?
>> 
>> -S
>> 
>> 2018-03-01 7:23 GMT-08:00 Bernhard Stegmaier <stegma...@sw-systems.de 
>> <mailto:stegma...@sw-systems.de>>:
>> Hmm?
>> You keep everything as is (especially creating threads), but just put the 
>> “#pragma …” before the for-loop.
>> So, there is one thread for the progress and one for the workers.
>> In the workers thread OpenMP (if there) takes care of adding additional 
>> threads for parallelising the loop?
>> 
>> Or, am I wrong with that?
>> 
>> > On 1. Mar 2018, at 16:11, Jeff Young <j...@rokeby.ie 
>> > <mailto:j...@rokeby.ie>> wrote:
>> >
>> > But then the progress reporter won’t work (and you’ve got no way to 
>> > cancel).
>> &g

[Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

[Bernhard Stegmaier]

Hi,

Attached patch fixes building on macOS with non-Xcode clang:
* To avoid problems make documentation suggest that cmake_minimum_required(...) 
has to be the very first statement directly followed by project(...)
* Policy CMP0025 must be set with min version <3.1 to NEW otherwise cmake will 
ignore CMAKE_CXX_STANDARD with non-Xcode clang

Tested on macOS with native and non-Xcode clang.


Regards,
Bernhard




0002-Fix-missing-C-11-compiler-flags-when-building-on-mac.patch
Description: Binary data
___
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

Re: [Kicad-developers] Mac HighDPI performance

[Bernhard Stegmaier]

No.

> On 4. Mar 2018, at 01:51, Andrey Kuznetsov <kandre...@gmail.com> wrote:
> 
> Would it be an easy fix to change the text/font such that it does not affect 
> performance so significantly on MacOS?
> 
> On Sat, Mar 3, 2018 at 5:20 AM, Wayne Stambaugh <stambau...@gmail.com 
> <mailto:stambau...@gmail.com>> wrote:
> On 03/03/2018 07:33 AM, Jeff Young wrote:
> Hi Andrey,
> 
> I did some profiling and I’d guess that the difference in eeschema and 
> pcbnew-legacy performance is down to there being more text in the schema.  
> Since we use a stroke font, there’s a lot of stroke segments in each letter.
> 
> @Devs,
> 
> I understand why we use a stroke font on the PCB, but there’s not much reason 
> in eeschema, is there?
> 
> This is possibly one of the things that I plan on changing after the new 
> schematic file format is written.  The new file format will support font 
> definitions so replacing the stroke font in Eeschema should be doable. 
> Whether or not I have time to make this change remains to be seen.
> 
> Wayne
> 
> 
> Cheers,
> Jeff.
> 
> 
> On 3 Mar 2018, at 08:18, Andrey Kuznetsov <kandre...@gmail.com 
> <mailto:kandre...@gmail.com> <mailto:kandre...@gmail.com 
> <mailto:kandre...@gmail.com>>> wrote:
> 
> The motherboard project is not very complex, I would say that performance 
> should be tolerable UP to that size complexity, if we set the bar any lower, 
> usability will suffer and people won't like KiCad because it's sluggish and 
> interface lag is the worst kind of lag.
> My project isn't finished and Chris' project is available now, is just the 
> right complexity and has layout that can be used for testing as well as a 
> schematic.
> 
> *LG 5K 27" display running 3200x1800 (the highest resolution without making 
> text blurry, using this for work every day, so it's extravagant, it's 
> practical)*
> 
> *Actions:* pan with middle mouse, zoom back and forth.
> 
> *eeschema:*
> Low Res - at least 2 times slower than would be considered normal, I would 
> have to guess ~400ms lag
> Normal - 4-5x slower compared to low res mode ~1700ms lag
> Even in low res mode, and removing 75% of the items from Chris' schematic, 
> the lag is still ~200-300ms, that's just not right. Additionally, I filed 
> https://bugs.launchpad.net/kicad/+bug/1753054 
> <https://bugs.launchpad.net/kicad/+bug/1753054> because the mouse zoom is 
> screwed up in eeschema, coupled with the lag, it's unusable. Maybe the pan 
> lag is related to the zoom, maybe there are multiple steps being rendered 
> when it should just jump to where the mouse ended up at, I don't know.
> 
> *pcbnew - **Normal Resolution:*
> Accelerated: No-AA, <50ms
> Fallback: 500-1000ms for panning, 300-600ms for zoom
> Legacy: 1300-1700ms for panning, 600ms for zoom
> Low Res mode: did not notice speed increase, except maybe Fallback was ~400ms 
> faster.
> 
> I'm not saying halt the horses, certain modes are obviously limited, ie 
> Legacy and Fallback by the nature of the task presented, but eeschema is 
> barely displaying 10% of the content pcbnew is but lagging so much worse!
> 
> Just thought I'd include rendering of the Accelerated Graphics (top to 
> bottom: Supersampling 4x, Subpixel AA (Ultra Quality), No AA)
> All 3 modes are responsive, probably <50-100ms lag, I'd consider this 
> performance great, considering the amount of elements on screen.
> 
> 
> How long should it take to delete this many selected elements in pcbnew?
> Answer: about 50x too long! I think it was like 3mins, perhaps ESC key should 
> be available to press anytime to undo the delete action and restore to 
> pre-delete screen when accidental actions are triggered that take forever to 
> complete?
> 
> 
> On Fri, Mar 2, 2018 at 9:53 AM, Bernhard Stegmaier <stegma...@sw-systems.de 
> <mailto:stegma...@sw-systems.de> <mailto:stegma...@sw-systems.de 
> <mailto:stegma...@sw-systems.de>>> wrote:
> 
> Hi,
> 
> to be honest, I don’t really know what this is about.
> 
> @Andrey:
> You looked for a very complex (foreign) project (Chris mainboard?)
> to prove that eeschema is slow on Mac?
> Well, we know that and we told you already some weeks/months ago
> why it is like it is (if memory serves me right).
> 
> Or, do you have an own project that is so ridiculously slow, that
> you can’t work with it?
> If so, please provide it so that we can analyse why this specific
> project behaves like that.
> If you can’t or don’t want to provide it we could tell you how to
> do some performance measurements so that we might see something.

Re: [Kicad-developers] V5 Version Info?

[Bernhard Stegmaier]

Yes, -dirty is clear.
I guess I didn’t explicitly pull tags since I first cloned the repo… didn’t 
know that they are not pulled per default.
Again learned something, thanks!

> On 3. Mar 2018, at 21:30, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> -dirty means you have code that is not in master.  You are either
> working in a different branch or you have made modifications to master.
> Given that your version string says 4.0.0-rc2, it also looks like you
> need to do a `git pull --tags` to fetch the latest tags.
> 
> Wayne
> 
> 
> On 03/03/2018 02:39 PM, Bernhard Stegmaier wrote:
>> Hi all,
>> 
>> just out of curiosity… all my builds from master claim to be a v4:
>> <<<
>> Application: kicad
>> Version: (4.0.0-rc2-4230-gaeae32b1a-dirty), release build
>>>>> 
>> 
>> According to git I have a clean source tree… I yesterday made a build on a 
>> Linux box with a completely fresh tree and it showed v5.
>> What’s wrong with my repo/branch?
>> 
>> 
>> Regards,
>> Bernhard
>> ___
>> 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
>> 
> 
> ___
> 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


___
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

[Kicad-developers] V5 Version Info?

[Bernhard Stegmaier]

Hi all,

just out of curiosity… all my builds from master claim to be a v4:
<<<
Application: kicad
Version: (4.0.0-rc2-4230-gaeae32b1a-dirty), release build
>>>

According to git I have a clean source tree… I yesterday made a build on a 
Linux box with a completely fresh tree and it showed v5.
What’s wrong with my repo/branch?


Regards,
Bernhard
___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

Hi all,

So, I played around a bit to get OpenMP and GCD into something like a 
“parallel_for” wrapper which either uses OpenMP or GCD.
Unfortunately, OpenMP seems to require that the “for” statement directly 
follows the “#pragma omg for …”.
That currently killed all my attempts to define such a “parallel_for” (as 
function, #define, ?) so that the code will stay the same for both.
One option would be to pull the “#pragma omp for …” into the wrapper, but I 
guess this is not really acceptable (since you can’t specify any specific 
schedule parameters any longer).

I will think about it some more just because of the challenge… but I am not 
very optimistic at the moment to get something nice.
If anyone else has a nice idea, I’d be very interested to learn freaky new 
stuff… :)

On the other side, I looked at using a non-Xcode OpenMP capable clang.
The only caveat seems to be not to mix standard C++ libraries (in the past 
libc++/libstdc++ haven’t been compatible in some aspects - didn’t try to find 
out if that is resolved).
Default on macOS now is libc++, but it seems that at least MacPorts builds 
clang with libstdc++ per default (no idea why).
The MacPorts build can easily be switched to libc++.
That clang-mp builds KiCad without problems even if dependencies have been 
built with Xcode clang.
Everything seems to work as expected, multithreading is there where it should 
be.

So, for now it seems to be the most easy solution to switch to a suitable 
non-Xcode clang for building packages - if we want to have OpenMP for macOS.

AFAIK our build machines use Homebrew.
Seems as if Homebrew decides which standard library to use depending on macOS 
version (https://docs.brew.sh/C++-Standard-Libraries 
<https://docs.brew.sh/C++-Standard-Libraries>).
So, if everything is recent enough it might not be a problem at all… like it 
obviously also has been for Seth below.


Regards,
Bernhard

> On 1. Mar 2018, at 17:47, Seth Hillbrand <seth.hillbr...@gmail.com> wrote:
> 
> Hi All-
> 
> I was playing with this last night (don't normally compile on the mac) and 
> found that using homebrew's llvm 3.8.1 seems to compile fine with -fopenmp.  
> Running some OMP test code from 
> https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5 
> <https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5> 
> shows expected result of 4 threads.  I didn't get OpenMP errors when 
> compiling KiCad although I didn't really notice a substantial difference in 
> speed for the quick tests I was running.  Maybe with more involved operations.
> 
> I'm not sure if this will require us to distribute a different libstdc++ with 
> KiCad.  Probably.  Does that seem feasible to the packing team?
> 
> -S
> 
> 2018-03-01 7:23 GMT-08:00 Bernhard Stegmaier <stegma...@sw-systems.de 
> <mailto:stegma...@sw-systems.de>>:
> Hmm?
> You keep everything as is (especially creating threads), but just put the 
> “#pragma …” before the for-loop.
> So, there is one thread for the progress and one for the workers.
> In the workers thread OpenMP (if there) takes care of adding additional 
> threads for parallelising the loop?
> 
> Or, am I wrong with that?
> 
> > On 1. Mar 2018, at 16:11, Jeff Young <j...@rokeby.ie 
> > <mailto:j...@rokeby.ie>> wrote:
> >
> > But then the progress reporter won’t work (and you’ve got no way to cancel).
> >
> > Non-pooling parallel threads are sufficient for zone filling, aren’t they?
> >
> >
> >> On 1 Mar 2018, at 15:00, Bernhard Stegmaier <stegma...@sw-systems.de 
> >> <mailto:stegma...@sw-systems.de>> wrote:
> >>
> >> For now it would probably be fine to just restore the pragma for the for 
> >> loop optimisation.
> >> Mac users are used to work single-threaded, all others would get back 
> >> multithreading here.
> >>
> >>> On 1. Mar 2018, at 15:58, Tomasz Wlostowski <tomasz.wlostow...@cern.ch 
> >>> <mailto:tomasz.wlostow...@cern.ch>> wrote:
> >>>
> >>> On 01/03/18 15:43, Jeff Young wrote:
> >>>> The purpose is it works on Mac.
> >>>>
> >>>> But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part.
> >>>>
> >>>
> >>> Thanks Jeff!
> >>>
> >>> Be aware that neither std::thread nor std::async have any concept of
> >>> thread pooling - we need to look for a suitable library or write or own.
> >>>
> >>> Cheers,
> >>> Tom
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers 
> >>> <https://launchpad.ne

[Kicad-developers] [PATCH] Fix clang-mp-6.0 compile error

[Bernhard Stegmaier]

Hi,Small patch to fix a compile error with (MacPorts) clang-6.0-mp.See  https://www.mail-archive.com/llvm-bugs@lists.llvm.org/msg20164.htmlRegards,Bernhard

0001-Fix-clang-mp-build-error-don-t-declare-const-variabl.patch
Description: Binary data
___
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

Re: [Kicad-developers] Zone filling (was: MacOS + OpenMP)

[Bernhard Stegmaier]

Hi,

you implemented multiple workers yourself now?
I’ll have to check in detail.

I thought of just using OpenMP for the for loop again like this.
<<<
diff --git a/pcbnew/zone_filler.cpp b/pcbnew/zone_filler.cpp
index 6fe40555a..408c5e7aa 100644
--- a/pcbnew/zone_filler.cpp
+++ b/pcbnew/zone_filler.cpp
@@ -118,6 +118,9 @@ void ZONE_FILLER::Fill( std::vector aZones 
)
 m_count_done = 0;
 std::thread fillWorker( [ this, toFill ]()
 {
+#ifdef USE_OPENMP
+#pragma omp for schedule(dynamic)
+#endif
 for( unsigned i = 0; i < toFill.size(); i++ )
 {
 SHAPE_POLY_SET rawPolys, finalPolys;
>>>

Currently compiling, but my (test) clang with OpenMP is pretty picky about 
other OpenMP stuff… :(


Regards,
Bernhard

> On 3. Mar 2018, at 18:50, Jeff Young  wrote:
> 
> Hi Tomasz & Bernhard,
> 
> If you have a chance could you guys please take a look at 
> https://git.launchpad.net/kicad/commit/?id=c77d13292b63a3ef7c28f004ee93f3ed93cca9f3
>  
> 
>  ?
> 
> It reinstates multi-threading (with thread pooling) to the zone filler.
> 
> Bernard is still looking for ways to make this a bit more elegant; this 
> version just uses brute force for now.
> 
> Cheers,
> Jeff.
> 
> 
>> On 1 Mar 2018, at 14:58, Tomasz Wlostowski > > wrote:
>> 
>> On 01/03/18 15:43, Jeff Young wrote:
>>> The purpose is it works on Mac.
>>> 
>>> But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part.
>>> 
>> 
>> Thanks Jeff!
>> 
>> Be aware that neither std::thread nor std::async have any concept of
>> thread pooling - we need to look for a suitable library or write or own.
>> 
>> Cheers,
>> Tom
> 
> ___
> 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

___
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

Re: [Kicad-developers] MacOS build missing frameworks

[Bernhard Stegmaier]

Yes… I have configured QTCreator to build debug/release into separate folders 
and I do my “production” builds via console.
QTCreator seems to have its own ideas how default folder structure should look 
like and I didn’t yet figure out in detail on how to configure it so that it 
doesn’t clash.


Bernhard


> On 3. Mar 2018, at 14:48, Jeff Young <j...@rokeby.ie> wrote:
> 
> Thanks, Bernhard.  I re-did mine to that scheme, but it didn’t help.  I think 
> it’s just QTCreator not quite following what’s going on.
> 
> 
> 
>> On 3 Mar 2018, at 12:45, Bernhard Stegmaier <stegma...@sw-systems.de 
>> <mailto:stegma...@sw-systems.de>> wrote:
>> 
>> Sure.
>> 
>> My work folder looks like that:
>>   kicad => git repo
>>   build => build folder
>>   wx-3.0 => wx binaries
>> 
>> In build folder, I use that cmake
>> <<<
>> cmake ../kicad -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ 
>> -DwxWidgets_CONFIG_EXECUTABLE=../wx-3.0/bin/wx-config -DKICAD_SCRIPTING=OFF 
>> -DKICAD_SCRIPTING_MODULES=OFF -DKICAD_SCRIPTING_WXPYTHON=OFF 
>> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_USE_OCE=ON 
>> -DOCE_DIR=/opt/local/Library/Frameworks/OCE.framework/Versions/0.17/Resources
>>  -DKICAD_SPICE=OFF -DCMAKE_INSTALL_PREFIX=../bin -DCMAKE_BUILD_TYPE=Release 
>> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.12
>> >>>
>> 
>> 
>> Bernhard
>> 
>>> On 3. Mar 2018, at 13:41, Jeff Young <j...@rokeby.ie 
>>> <mailto:j...@rokeby.ie>> wrote:
>>> 
>>> Interesting.  Could you share your cmake command?
>>> 
>>>> On 3 Mar 2018, at 12:19, Bernhard Stegmaier <stegma...@sw-systems.de 
>>>> <mailto:stegma...@sw-systems.de>> wrote:
>>>> 
>>>> You are sure that you have a clean build folder and don’t mix things from 
>>>> console builds, QTCreator, etc.?
>>>> In my build folder (built yesterday) I don’t have a “bin” or “debug” 
>>>> folder…
>>>> 
>>>> HackMini:build bstegmaier$ ls -l
>>>> total 200
>>>> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:43 3d-viewer
>>>> -rw-r--r--   1 bstegmaier  staff  41439 Mar  2 13:06 CMakeCache.txt
>>>> drwxr-xr-x  18 bstegmaier  staff612 Mar  2 13:43 CMakeFiles
>>>> -rw-r--r--   1 bstegmaier  staff  35407 Mar  2 13:06 Makefile
>>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 bitmap2component
>>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 bitmaps_png
>>>> -rw-r--r--   1 bstegmaier  staff   4235 Mar  2 13:06 cmake_install.cmake
>>>> -rw-r--r--   1 bstegmaier  staff907 Mar  2 13:06 cmake_uninstall.cmake
>>>> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:42 common
>>>> -rw-r--r--   1 bstegmaier  staff   1834 Mar  2 13:06 config.h
>>>> drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 cvpcb
>>>> drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 demos
>>>> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:06 eeschema
>>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 gerbview
>>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 kicad
>>>> -rw-r--r--   1 bstegmaier  staff277 Mar  2 13:06 kicad_build_version.h
>>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 lib_dxf
>>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 pagelayout_editor
>>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 pcb_calculator
>>>> drwxr-xr-x   9 bstegmaier  staff306 Mar  2 13:06 pcbnew
>>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 plugins
>>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 polygon
>>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 potrace
>>>> drwxr-xr-x   9 bstegmaier  staff306 Mar  2 13:06 qa
>>>> drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 template
>>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 tools
>>>> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:06 utils
>>>> 
>>>> 
>>>> 
>>>> Bernhard
>>>> 
>>>>> On 3. Mar 2018, at 12:38, Jeff Young <j...@rokeby.ie 
>>>>> <mailto:j...@rokeby.ie>> wrote:
>>>>> 
>>>>> When I do a build I get 3 copies of all the stand-alone apps:
>>>>> 
>>>>> build/
>>>>>bin/
>>>>>   eeschema.app
>>>>>debug/
>>>>>   eeschema/
>>>>&g

Re: [Kicad-developers] Mac HighDPI performance

[Bernhard Stegmaier]

Hi,

to be honest, I don’t really know what this is about.

@Andrey:
You looked for a very complex (foreign) project (Chris mainboard?) to prove 
that eeschema is slow on Mac?
Well, we know that and we told you already some weeks/months ago why it is like 
it is (if memory serves me right).

Or, do you have an own project that is so ridiculously slow, that you can’t 
work with it?
If so, please provide it so that we can analyse why this specific project 
behaves like that.
If you can’t or don’t want to provide it we could tell you how to do some 
performance measurements so that we might see something.

Obviously, there are a number of Mac users here and also over at the KiCad 
forum who might also be happy to get some more performance here and there, but 
who are in general reasonably able to work on their projects (including myself, 
on a 2012 Retina MacBook with only an i5).


Regards,
Bernhard

> On 2. Mar 2018, at 17:59, Andy Peters  wrote:
> 
> 
> 
>> On Mar 1, 2018, at 8:53 PM, Seth Hillbrand  wrote:
>> 
>> Andrey-
>> 
>> I'm moving this to a new thread so that we don't conflate the OpenMP 
>> discussion with this.
>> 
>> Can you test running Kicad with the "Open in Low Resolution" mode enabled?  
>> You can activate this by choosing "Get Info" on the main KiCad application 
>> and checking the option that says "Open in Low Resolution".  You may need to 
>> do the same for the other applications (Eeschema, pcbnew, etc) as well.
> 
> testing on my 2017” touch-bar MBP … 
> 
> Good g-d, low-res mode looks fuzzy and weird!
> 
> I don’t notice any specific differences in EESchema performance. Maybe my 
> schematic isn’t busy enough? I’m a fan of using more smaller sheets with less 
> info on each than one big sheet with everything.
> 
> I know, anecdote is not evidence.
> 
> -a
> 
> 
>> 
>> -Seth
>> 
>> ​​2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :
>> Hi,
>> 
>> So for now I've had a chance to test the motherboard project on my Retina 
>> macbook display.
>> eeschema: horrible zoom, feels like elastic band zoom and I have all scroll 
>> wheel accelerations and similar disabled, zoom response is super laggy, 
>> cannot work like this, will need to make schematics on windows.
>> pcbnew by order of slowness:
>> legacy - pretty slow, zoom lag is major, boo boo
>> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
>> modern (accelerated) - almost cannot feel the lag, very nice, nice zoom 
>> responsiveness
>> 
>> I'll report tomorrow on 5K LG display.
>> ​
> 
> 
> ___
> 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


___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

When I started with KiCad I had massive problems mixing gcc and clang depending 
on what dependency was built with which compiler (different libstdc, ABI, etc.) 
- even if everything should have been compatible in theory.
So, even if we decide to switch to our own toolchain and OpenMP I wouldn’t 
target that for v5.

For my taste, I would rather stick to a toolchain being as stock as possible.

> On 1. Mar 2018, at 18:00, Adam Wolf <adamw...@feelslikeburning.com> wrote:
> 
> I do not think it is feasible to distribute a different libstdc++ with
> V5 stable for macOS unless there's someone who wants to take that on.
> 
> Adam
> 
> On Thu, Mar 1, 2018 at 10:50 AM, Wayne Stambaugh <stambau...@gmail.com> wrote:
>> Just for clarification I think Tom was commenting that the changes hurt
>> the zone filling speed.  @Tom, is that what your were commenting on earlier?
>> 
>> On 3/1/2018 10:11 AM, Jeff Young wrote:
>>> But then the progress reporter won’t work (and you’ve got no way to cancel).
>>> 
>>> Non-pooling parallel threads are sufficient for zone filling, aren’t they?
>>> 
>>> 
>>>> On 1 Mar 2018, at 15:00, Bernhard Stegmaier <stegma...@sw-systems.de> 
>>>> wrote:
>>>> 
>>>> For now it would probably be fine to just restore the pragma for the for 
>>>> loop optimisation.
>>>> Mac users are used to work single-threaded, all others would get back 
>>>> multithreading here.
>>>> 
>>>>> On 1. Mar 2018, at 15:58, Tomasz Wlostowski <tomasz.wlostow...@cern.ch> 
>>>>> wrote:
>>>>> 
>>>>> On 01/03/18 15:43, Jeff Young wrote:
>>>>>> The purpose is it works on Mac.
>>>>>> 
>>>>>> But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part.
>>>>>> 
>>>>> 
>>>>> Thanks Jeff!
>>>>> 
>>>>> Be aware that neither std::thread nor std::async have any concept of
>>>>> thread pooling - we need to look for a suitable library or write or own.
>>>>> 
>>>>> Cheers,
>>>>> Tom
>>>>> 
>>>>> ___
>>>>> 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
>>>> 
>>> 
>>> 
>>> ___
>>> 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
>>> 
>> 
>> ___
>> 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
> 
> ___
> 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


___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

Hmm?
You keep everything as is (especially creating threads), but just put the 
“#pragma …” before the for-loop.
So, there is one thread for the progress and one for the workers.
In the workers thread OpenMP (if there) takes care of adding additional threads 
for parallelising the loop?

Or, am I wrong with that?

> On 1. Mar 2018, at 16:11, Jeff Young <j...@rokeby.ie> wrote:
> 
> But then the progress reporter won’t work (and you’ve got no way to cancel).
> 
> Non-pooling parallel threads are sufficient for zone filling, aren’t they?
> 
> 
>> On 1 Mar 2018, at 15:00, Bernhard Stegmaier <stegma...@sw-systems.de> wrote:
>> 
>> For now it would probably be fine to just restore the pragma for the for 
>> loop optimisation.
>> Mac users are used to work single-threaded, all others would get back 
>> multithreading here.
>> 
>>> On 1. Mar 2018, at 15:58, Tomasz Wlostowski <tomasz.wlostow...@cern.ch> 
>>> wrote:
>>> 
>>> On 01/03/18 15:43, Jeff Young wrote:
>>>> The purpose is it works on Mac.
>>>> 
>>>> But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part.
>>>> 
>>> 
>>> Thanks Jeff!
>>> 
>>> Be aware that neither std::thread nor std::async have any concept of
>>> thread pooling - we need to look for a suitable library or write or own.
>>> 
>>> Cheers,
>>> Tom
>>> 
>>> ___
>>> 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
>> 
> 


___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

For now it would probably be fine to just restore the pragma for the for loop 
optimisation.
Mac users are used to work single-threaded, all others would get back 
multithreading here.

> On 1. Mar 2018, at 15:58, Tomasz Wlostowski  wrote:
> 
> On 01/03/18 15:43, Jeff Young wrote:
>> The purpose is it works on Mac.
>> 
>> But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part.
>> 
> 
> Thanks Jeff!
> 
> Be aware that neither std::thread nor std::async have any concept of
> thread pooling - we need to look for a suitable library or write or own.
> 
> Cheers,
> Tom
> 
> ___
> 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


___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

I didn’t follow in detail, but from what I saw I guess the bad thing about it 
was to use OpenMP for
(1) parallelising for loop
  and
(2) creating individual threads for progress reporter and workers.

As soon as you don’t have OpenMP it didn’t work anymore… so maybe using OpenMP 
for (1) and usual STL threading stuff for (2) would be a compromise (even) if 
maybe clumsy.
At least, it would work also with non-OpenMP systems.


Regards,
Bernhard

> On 1. Mar 2018, at 15:09, Tomasz Wlostowski <tomasz.wlostow...@cern.ch> wrote:
> 
> On 01/03/18 15:01, Jon Evans wrote:
>> I missed that change to STL, oops!
>> In that case we should standardize on STL for all new code in the future
>> so that it will work on Mac.
> 
> Me too.
> 
> I don't understand the purpose of it - now all zone calculation (except
> for insulated copper island removal) works in a *single* worker thread
> (the main thread is just refreshing the progress dialog).
> 
> It means ~3.5x slower zone refilling on a 4-core CPU.
> 
> Can anybody comment on that?
> 
> Tom
> 
> 
>> There are already many edge cases I have found (or users have reported)
>> where KiCad is extremely slow, and we need to have a good story for
>> multiprocessing so that we can take advantage of it where it makes sense
>> to increase performance and/or responsiveness.
>> 
>> -Jon
>> 
>> On Thu, Mar 1, 2018 at 8:48 AM, Jeff Young <j...@rokeby.ie
>> <mailto:j...@rokeby.ie>> wrote:
>> 
>>There’s performance and there’s responsiveness.
>> 
>>The footprint loading and zone filling were moved to STL so that
>>progress reporting would work on Mac.
>> 
>>As long as we don’t introduce more OpenMP into core stuff, I’m not
>>that fixated on what we use for raytracing.
>> 
>>Cheers,
>>Jeff.
>> 
>> 
>>>On 1 Mar 2018, at 13:34, Tomasz Wlostowski
>>><tomasz.wlostow...@cern.ch <mailto:tomasz.wlostow...@cern.ch>> wrote:
>>> 
>>>On 01/03/18 14:29, Jon Evans wrote:
>>>>It is also used for zone filling and in my new eeschema connectivity
>>>>code that I'm hoping to get merged soon after V5 release.
>>>> 
>>>>I'm happy to help with research / testing of alternatives if we can't
>>>>use OpenMP on Mac. 
>>>> 
>>>I'd like to hear from a *single* Apple user who designs boards of
>>>sufficient complexity for the multithreading to really have an
>>>impact on
>>>performance. What's next, rewriting Kicad in Objective-C?
>>> 
>>>- my 5 cents
>>> 
>>>Tom
>>> 
>>> 
>>>>Jon
>>>> 
>>>>On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh <stambau...@gmail.com
>>>><mailto:stambau...@gmail.com>
>>>><mailto:stambau...@gmail.com>> wrote:
>>>> 
>>>>   Ughh!  Thank you Apple.  I'm not opposed to this idea if
>>>>OpenMP isn't a
>>>>   viable option on macos.  I would like to see our macos port be
>>>>on par
>>>>   with linux and windows ports.
>>>> 
>>>>   Wayne
>>>> 
>>>>   On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
>>>>>I did look around a bit.
>>>>>Looks like OpenMP isn’t a friend of Xcode clang, because Apple
>>>>>has its
>>>>>own Grand Central Dispatch (libdispatch) implementation/library
>>>>>doing
>>>>>similar things (at first glance, didn’t look into details).
>>>>>So, I guess OpenMP maybe won’t happen soon with stock toolchain
>>>>>or we
>>>>>would have to use non-stock toolchain (probably with all
>>>>>problems that
>>>>>come with that - I have seen bad things mixing compilers, etc.).
>>>>> 
>>>>>Seems to be quite easy to convert OpenMP for loop parallelisation
>>>>   to GCD:
>>>>><<<
>>>>>//#pragma omp parallel for
>>>>>//for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
>>>>>dispatch_queue_t queue =
>>>>>dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
>>>>>dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
>>>>>{
>>>>>...
>>>>>}
>>>>>);
>>>>>>>> 
>>>>>

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

> On 1. Mar 2018, at 15:28, Tomasz Wlostowski  wrote:
>> 
> Sure, I'm all in for STL - my only concern is that zone filling, as it
> is done now, does not benefit at all from multiple CPU cores. We need a

Welcome to the KiCad Mac world, citing you some mails ago:
<<<
I'd like to hear from a *single* Apple user who designs boards of
sufficient complexity for the multithreading to really have an impact on
performance.
>>>

Sorry, couldn’t resist… :)

> proper STL-based worker dispatcher for that to work.

Yes, that’s the problem.
std::async goes into that direction, but seems to pretty unusable in practice 
since it doesn’t impose any pooling, etc.


Regards,
Bernhard
___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

The zone filling code was the only spot which didn’t work by just simply 
replacing the for loop with dispatch_apply.
I’ll have to dig a little deeper on what has to be done there… I guess it is 
something about using variables outside the loop body in the clang block given 
to dispatch_apply.


Bernhard

> On 1. Mar 2018, at 14:29, Jon Evans <j...@craftyjon.com> wrote:
> 
> It is also used for zone filling and in my new eeschema connectivity code 
> that I'm hoping to get merged soon after V5 release.
> 
> I'm happy to help with research / testing of alternatives if we can't use 
> OpenMP on Mac. 
> 
> Jon
> 
> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh <stambau...@gmail.com 
> <mailto:stambau...@gmail.com>> wrote:
> Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
> viable option on macos.  I would like to see our macos port be on par
> with linux and windows ports.
> 
> Wayne
> 
> On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
> > I did look around a bit.
> > Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> > own Grand Central Dispatch (libdispatch) implementation/library doing
> > similar things (at first glance, didn’t look into details).
> > So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> > would have to use non-stock toolchain (probably with all problems that
> > come with that - I have seen bad things mixing compilers, etc.).
> >
> > Seems to be quite easy to convert OpenMP for loop parallelisation to GCD:
> > <<<
> > //#pragma omp parallel for
> > //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> > dispatch_queue_t queue =
> > dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> > dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> > {
> > ...
> > }
> > );
> >>>>
> >
> > I just naively replaced all of the OpenMP for loops like above and now
> > 3d-Viewer uses all cores.
> > On my i7-3770T rendering time decreased from about 100s to 30s.
> >
> > I also did it for the ratsnest loop but didn’t notice any difference
> > (maybe my test PCB was just to small).
> >
> > I could play around a bit to put that stuff into some nice syntax maybe
> > similar to what Microsoft has with concurrency::parallel_for_each
> >   https://msdn.microsoft.com/en-us/library/dd492857.aspx 
> > <https://msdn.microsoft.com/en-us/library/dd492857.aspx>
> > So, at least ugly #ifdef around each parallel for loop could be hidden.
> >
> > Don’t get me wrong, I don’t want to add just another parallelisation
> > library/mechanism.
> > And… I guess it won’t be possible to transparently cover all the OpenMP
> > pragma stuff maybe needed inside for loop body or maybe other stuff
> > needed for GCD (e.g. when writing to variables outside for body).
> >
> > Thoughts? Would this be an option?
> >
> > Oh, yes:
> > I did look into using STL std::async.
> > Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> > anything like thread pools, etc. on various platforms.
> > You probably don’t want to create that much threads… :) 
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 1. Mar 2018, at 08:40, Bernhard Stegmaier <stegma...@sw-systems.de 
> >> <mailto:stegma...@sw-systems.de>
> >> <mailto:stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>>> wrote:
> >>
> >> I had a quick look where OpenMP is used.
> >>
> >> I found it somewhere in the connectivity/ratsnest code.
> >> I don’t know of any complaints in that area and even on my old HW I
> >> had never a bad experience.
> >>
> >> And then, 3D-Viewer.
> >>
> >> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> >> if user experience will be that bad without OpenMP.
> >> IMHO it’s only the Raytracing view, which isn’t intended to be used
> >> for normal viewing stuff anyway.
> >>
> >> If I find some time over the weekend I will also try… but I don’t
> >> think it will be worth it.
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >>> On 1. Mar 2018, at 00:50, Jeff Young <j...@rokeby.ie 
> >>> <mailto:j...@rokeby.ie>
> >>> <mailto:j...@rokeby.ie <mailto:j...@rokeby.ie>>> wrote:
> >>>
> >>> Or rip it out and use STL?
> >>>
> >>>> On 28 Feb 2018, at 23:38, Jon Evans <j...@craftyjon.com 
&

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

I did look around a bit.
Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its own 
Grand Central Dispatch (libdispatch) implementation/library doing similar 
things (at first glance, didn’t look into details).
So, I guess OpenMP maybe won’t happen soon with stock toolchain or we would 
have to use non-stock toolchain (probably with all problems that come with that 
- I have seen bad things mixing compilers, etc.).

Seems to be quite easy to convert OpenMP for loop parallelisation to GCD:
<<<
//#pragma omp parallel for
//for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
dispatch_queue_t queue = 
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
{
...
}
);
>>>

I just naively replaced all of the OpenMP for loops like above and now 
3d-Viewer uses all cores.
On my i7-3770T rendering time decreased from about 100s to 30s.

I also did it for the ratsnest loop but didn’t notice any difference (maybe my 
test PCB was just to small).

I could play around a bit to put that stuff into some nice syntax maybe similar 
to what Microsoft has with concurrency::parallel_for_each
  https://msdn.microsoft.com/en-us/library/dd492857.aspx 
<https://msdn.microsoft.com/en-us/library/dd492857.aspx>
So, at least ugly #ifdef around each parallel for loop could be hidden.

Don’t get me wrong, I don’t want to add just another parallelisation 
library/mechanism.
And… I guess it won’t be possible to transparently cover all the OpenMP pragma 
stuff maybe needed inside for loop body or maybe other stuff needed for GCD 
(e.g. when writing to variables outside for body).

Thoughts? Would this be an option?

Oh, yes:
I did look into using STL std::async.
Doesn’t seem to be a good idea, because it usually doesn’t seem to use anything 
like thread pools, etc. on various platforms.
You probably don’t want to create that much threads… :) 


Regards,
Bernhard

> On 1. Mar 2018, at 08:40, Bernhard Stegmaier <stegma...@sw-systems.de> wrote:
> 
> I had a quick look where OpenMP is used.
> 
> I found it somewhere in the connectivity/ratsnest code.
> I don’t know of any complaints in that area and even on my old HW I had never 
> a bad experience.
> 
> And then, 3D-Viewer.
> 
> So, in my opinion it is basically only about 3D-Viewer… I don’t know if user 
> experience will be that bad without OpenMP.
> IMHO it’s only the Raytracing view, which isn’t intended to be used for 
> normal viewing stuff anyway.
> 
> If I find some time over the weekend I will also try… but I don’t think it 
> will be worth it.
> 
> 
> Regards,
> Bernhard
> 
>> On 1. Mar 2018, at 00:50, Jeff Young <j...@rokeby.ie> wrote:
>> 
>> Or rip it out and use STL?
>> 
>>> On 28 Feb 2018, at 23:38, Jon Evans <j...@craftyjon.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> Does anyone have a working build setup for getting OpenMP-enabled KiCad out 
>>> of MacOS?
>>> If so, please share how -- I tried for a bit but couldn't get it going (I'm 
>>> not super familiar with the MacOS toolchain yet).
>>> 
>>> We should make sure that the 5.0 release is built with OpenMP, otherwise 
>>> our Mac users are going to have a slower user experience.
>>> 
>>> -Jon
>>> ___
>>> 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
>> 
>> 
>> ___
>> 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
> 
> 
> ___
> 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

___
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

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

I had a quick look where OpenMP is used.

I found it somewhere in the connectivity/ratsnest code.
I don’t know of any complaints in that area and even on my old HW I had never a 
bad experience.

And then, 3D-Viewer.

So, in my opinion it is basically only about 3D-Viewer… I don’t know if user 
experience will be that bad without OpenMP.
IMHO it’s only the Raytracing view, which isn’t intended to be used for normal 
viewing stuff anyway.

If I find some time over the weekend I will also try… but I don’t think it will 
be worth it.


Regards,
Bernhard

> On 1. Mar 2018, at 00:50, Jeff Young  wrote:
> 
> Or rip it out and use STL?
> 
>> On 28 Feb 2018, at 23:38, Jon Evans  wrote:
>> 
>> Hi all,
>> 
>> Does anyone have a working build setup for getting OpenMP-enabled KiCad out 
>> of MacOS?
>> If so, please share how -- I tried for a bit but couldn't get it going (I'm 
>> not super familiar with the MacOS toolchain yet).
>> 
>> We should make sure that the 5.0 release is built with OpenMP, otherwise our 
>> Mac users are going to have a slower user experience.
>> 
>> -Jon
>> ___
>> 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
> 
> 
> ___
> 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


___
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

Re: [Kicad-developers] [PATCH] Pcbnew menu bar

[Bernhard Stegmaier]

I can’t tell, I didn’t look for that bug.
I didn’t follow the restructuring on the ML.
My comment was just about the “Preferences” menu entry in KiCad menu.
I did search it for some time before the restructuring and wondered a bit that 
it still like that after.

> On 21. Feb 2018, at 19:13, Michael Kavanagh <mich...@michaelkavanagh.me> 
> wrote:
> 
> Bernhard, do you mean this bug [1] existed before the 3b085f0 "Pcbnew new 
> menubar structure" commit?
> 
> [1] https://bugs.launchpad.net/kicad/+bug/1750494 
> <https://bugs.launchpad.net/kicad/+bug/1750494>
> 
> On 21 February 2018 at 13:07, Bernhard Stegmaier <stegma...@sw-systems.de 
> <mailto:stegma...@sw-systems.de>> wrote:
> > Hi,
> >
> > Just to mention… it has been like this before the patches.
> > At least on macOS, there is still a “Preferences” menu entry below the
> > “KiCad” menu bar entry (the “General Settings” dialog).
> > Then, there is the “Preferences” menu… without those “General Setting”.
> >
> > Because there is a “Preferences” menu bar entry I didn’t look anywhere else
> > for the general settings.
> > Took me quite a while to find them in the “KiCad” menu bar entry.
> >
> > Any plans to change this?
> >
> >
> > Regards,
> > Bernhard
> >
> > On 20. Feb 2018, at 08:17, Nick Østergaard <oe.n...@gmail.com 
> > <mailto:oe.n...@gmail.com>> wrote:
> >
> > Hello Michael and Jeff,
> >
> > It seems like we got our first small regression from this patch series.
> > Could you have a look. Please note it looks like it is window manager
> > dependent.
> > https://bugs.launchpad.net/kicad/+bug/1750494 
> > <https://bugs.launchpad.net/kicad/+bug/1750494>
> >
> > Nick
> >
> > 2018-02-18 23:03 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com 
> > <mailto:stambau...@gmail.com>>:
> >>
> >> Indeed I did forget.  Thanks for the reminder.  Thank you Jeff for the
> >> patches.
> >>
> >>
> >> On 02/18/2018 03:02 PM, Michael Kavanagh wrote:
> >>>
> >>> Thanks Wayne. Please don't forget to merge Jeffs dialog changes which
> >>> complete the Pcbnew menubar modifications. I have reattached them to
> >>> this email for convenience.
> >>>
> >>> Cheers,
> >>> Michael
> >>>
> >>> On 18 February 2018 at 19:16, Wayne Stambaugh <stambau...@gmail.com 
> >>> <mailto:stambau...@gmail.com>>
> >>> wrote:
> >>>>
> >>>> Michael,
> >>>>
> >>>> I figured out why we are not using IS_ACCELERATOR for these menu
> >>>> entries.
> >>>> AddHotkeyName() adds a "+Alt+" to the hotkey so this is *not* what we
> >>>> want
> >>>> so I used the original 0003 patch.  I apologize for the confusion.  I
> >>>> merged
> >>>> this and you 0004 patch.  We can make any tweaks to it if it's not
> >>>> exactly
> >>>> what we want.  Thank you for your contribution to KiCad.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Wayne
> >>>>
> >>>>
> >>>> On 02/18/2018 10:10 AM, Michael Kavanagh wrote:
> >>>>>
> >>>>>
> >>>>> In every other app New, Open, Save, Save As and Print are standard
> >>>>> hotkeys and not accelerators. They don't have the modifier key, so are
> >>>>> the "standard" keyboard shortcuts.
> >>>>>
> >>>>> Nevertheless, please find attached new patches for review. These
> >>>>> accompany both of Jeffs dialog patches. Hopefully I didn't break
> >>>>> anything, implementing the sketch modes removed from the dialogs
> >>>>> involved fiddling with the GAL tools framework.
> >>>>>
> >>>>> Cheers,
> >>>>> Michael
> >>>>>
> >>>>> On 17 February 2018 at 17:27, Wayne Stambaugh <stambau...@gmail.com 
> >>>>> <mailto:stambau...@gmail.com>>
> >>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>> It should be.  We really need to get out of the bad habit of having
> >>>>>> toolbar only access to tools and settings.  I'm sure there are some in
> >>>>>> the schematic editor, symbol editor, and footprint editor as well.
>

Re: [Kicad-developers] [PATCH] Pcbnew menu bar

[Bernhard Stegmaier]

Hi,

Just to mention… it has been like this before the patches.
At least on macOS, there is still a “Preferences” menu entry below the “KiCad” 
menu bar entry (the “General Settings” dialog).
Then, there is the “Preferences” menu… without those “General Setting”.

Because there is a “Preferences” menu bar entry I didn’t look anywhere else for 
the general settings.
Took me quite a while to find them in the “KiCad” menu bar entry.

Any plans to change this?


Regards,
Bernhard

> On 20. Feb 2018, at 08:17, Nick Østergaard  wrote:
> 
> Hello Michael and Jeff,
> 
> It seems like we got our first small regression from this patch series. Could 
> you have a look. Please note it looks like it is window manager dependent.
> https://bugs.launchpad.net/kicad/+bug/1750494 
> 
> 
> Nick
> 
> 2018-02-18 23:03 GMT+01:00 Wayne Stambaugh  >:
> Indeed I did forget.  Thanks for the reminder.  Thank you Jeff for the 
> patches.
> 
> 
> On 02/18/2018 03:02 PM, Michael Kavanagh wrote:
> Thanks Wayne. Please don't forget to merge Jeffs dialog changes which
> complete the Pcbnew menubar modifications. I have reattached them to
> this email for convenience.
> 
> Cheers,
> Michael
> 
> On 18 February 2018 at 19:16, Wayne Stambaugh  > wrote:
> Michael,
> 
> I figured out why we are not using IS_ACCELERATOR for these menu entries.
> AddHotkeyName() adds a "+Alt+" to the hotkey so this is *not* what we want
> so I used the original 0003 patch.  I apologize for the confusion.  I merged
> this and you 0004 patch.  We can make any tweaks to it if it's not exactly
> what we want.  Thank you for your contribution to KiCad.
> 
> Cheers,
> 
> Wayne
> 
> 
> On 02/18/2018 10:10 AM, Michael Kavanagh wrote:
> 
> In every other app New, Open, Save, Save As and Print are standard
> hotkeys and not accelerators. They don't have the modifier key, so are
> the "standard" keyboard shortcuts.
> 
> Nevertheless, please find attached new patches for review. These
> accompany both of Jeffs dialog patches. Hopefully I didn't break
> anything, implementing the sketch modes removed from the dialogs
> involved fiddling with the GAL tools framework.
> 
> Cheers,
> Michael
> 
> On 17 February 2018 at 17:27, Wayne Stambaugh  >
> wrote:
> 
> It should be.  We really need to get out of the bad habit of having
> toolbar only access to tools and settings.  I'm sure there are some in
> the schematic editor, symbol editor, and footprint editor as well.
> 
> On 02/17/2018 06:16 AM, Jeff Young wrote:
> 
> The Fill/Outline stuff is included.  Not sure about High Contrast mode,
> but it probably should be.
> 
> On 17 Feb 2018, at 06:58, Gaurav Juvekar  >
> wrote:
> 
> Hi all,
> 
> Probably not too relevant, but can we have a workaround of
> https://bugs.launchpad.net/kicad/+bug/1575097 
>  (hidden icons) by adding
> View -> High Contrast (Checkable like the "Flip board view")
> View -> Tracks -> Outline (Radio button like the canvas selector)
> -> Fill
> View -> Vias   -> Outline
> -> Fill
> View -> Pads   -> Outline
> -> Fill
> 
> to the menu entries?
> 
> --
> Regards,
> Gaurav Juvekar
> 
> ___
> 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 
> 
> 
> 
> 
> ___
> 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 
> 
> 
> 
> ___
> 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 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : 

Re: [Kicad-developers] Is eeschema's Symbol Table supposed to be editable?

[Bernhard Stegmaier]

Yes, seems as if it is completely broken on macOS.
Seems to be fine on other platforms.

It did somewhat work a while ago.
At least, I was able to change some cells/values when clicking multiple times…


Regards,
Bernhard

> On 9. Feb 2018, at 19:13, Jeff Young  wrote:
> 
> There’s a Symbol Table dialog in eeschema (from the "Edit symbol fields” 
> button in the top toolbar) with Apply Changes and Revert Changes buttons, 
> suggesting that it should be editable.  Yet there are no other buttons, and 
> neither right-clicking or double-clicking on the list does anything.
> 
> Mac-only issue, or broken for everyone, or just never implemented?
> ___
> 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


___
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

Re: [Kicad-developers] Another performance patch....

[Bernhard Stegmaier]

Worst part for macOS is that we still need the patched overlay stuff for the 
legacy canvases.
There has been something added to master recently, but it unfortunately doesn’t 
work (it does, but is slow as hell).
I would be surprised if this gets usable for 3.1.

So, getting rid of legacy canvases (in pcbnew and eeschema) is probably the 
biggest step for also being able to use a stock wxWidgets an macOS.
The remainder is more or less just “cosmetic” stuff that will eventually get 
fixed (hopefully)...

wxPython is the next story then, as Adam said.


Regards,
Bernhard

> On 9. Feb 2018, at 15:37, Adam Wolf  wrote:
> 
> Part of the issue with wx is that we are using a legacy version of
> wxpython.  I know there has been some motion towards getting the new
> version of wxpython working with KiCad, but it does not seem like it
> will be super easy.  There is no real guarantee that the next version
> of wx will work with the legacy/non-maintained version of wxpython
> we're using.
> 
> I consider getting away from this legacy version of wxpython
> relatively critical so we don't get in trouble--for instance, if some
> new OS release doesn't work with the legacy wxpython.
> 
> Adam Wolf
> 
> On Fri, Feb 9, 2018 at 8:27 AM, Wayne Stambaugh  wrote:
>> On 2/9/2018 1:41 AM, Carsten Schoenert wrote:
>>> Am 09.02.2018 um 01:35 schrieb Jeff Young:
 Ping.
 
 Any thoughts on patching wxWidgets for other platforms?
>>> 
>>> If you are talking about other Linux platforms then please do this in a
>>> way the user hasn't to deal with changes to system folders, this isn't
>>> really possible nor usable on systems which using package managers for
>>> dealing with installed software. And I know only LFS (Linux from
>>> Scratch) which hasn't a package manager.
>>> 
>>> And, please upstream any changes, if upstream don't want to accept your
>>> changes they probably have strong and good reasons to not apply your
>>> changes (at least for this specific released version).
>>> 
>> 
>> I second this motion.  We really shouldn't be in the business of
>> maintaining our own custom version of wxWidgets.  I relaize macos is a
>> problem child for wx but we should be helping ourselves by getting wx to
>> accept and maintain any issues that have not already been fixed
>> upstream.  Hopefully the next release of wx will be a bit more usable on
>> macos than the 3.0 branch and that the current situation of maintaining
>> our own wx branch for macos is temporary.
>> 
>> ___
>> 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
> 
> ___
> 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


___
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

Re: [Kicad-developers] wxGTK3 patches

[Bernhard Stegmaier]

Yes, did see the button (synced today).
But it didn’t seem to change anything.
Where should I see it?

> On 7. Feb 2018, at 19:39, Jeff Young <j...@rokeby.ie> wrote:
> 
> The crosshairs should be available again in a current build.  Do you see the 
> toolbar button on the left?
> 
>> On 7 Feb 2018, at 17:36, Bernhard Stegmaier <stegma...@sw-systems.de> wrote:
>> 
>> … yes, no good.
>> It seems to be OK when just panning around.
>> But, it gets very laggy while e.g. dragging/moving symbols around (even on a 
>> not so big schematic I had at hand).
>> 
>> It is fine if you take out the Refresh() quoted below on macOS.
>> I didn’t see any obvious things on a quick check with the remaining changes 
>> (might be due to the fact that crosshair is still disabled on macOS?).
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 7. Feb 2018, at 17:32, Bernhard Stegmaier <stegma...@sw-systems.de> 
>>> wrote:
>>> 
>>> … USE_WX_GRAPHICS_CONTEXT is on per default on macOS.
>>> 
>>> I will check tonight, but I guess/fear that the part
>>> <<<
>>> +#ifdef USE_WX_GRAPHICS_CONTEXT
>>> +// Screen has to be updated on every operation, otherwise the cursor 
>>> leaves a trail (when xor
>>> +// operation is changed to copy) or is not updated at all.
>>> +Refresh();
>>> +#endif
>>>>>> 
>>> will make it slow (might cause double painting every time because of how it 
>>> is already handled right now without the extra refresh).
>>> 
>>> I’ll report (if no other macOS guy is faster than me… :) )
>>> 
>>> 
>>> Bernhard
>>> 
>>>> On 7. Feb 2018, at 15:38, Maciej Sumiński <maciej.sumin...@cern.ch> wrote:
>>>> 
>>>> Two patches to fix some troubles occurring on wxGTK3. The first one
>>>> displays a warning when it detects that KiCad is being built against
>>>> wxGTK3. The second one makes eeschema functional, just a bit slower when
>>>> compared to wxGTK2. The only thing that is really broken is pcbnew
>>>> printing, but there are also some other glitches (e.g. black background
>>>> in eeschema printing preview, though the actual printouts are ok).
>>>> 
>>>> I have tested the patch under Linux and Windows and noticed no influence
>>>> on wxMSW/wxGTK2, as expected. I would love to hear from OSX users that
>>>> there are no new issues introduced in the patch.
>>>> 
>>>> Unfortunately, it does not resolve the recent wxpython-gtk3 issue on
>>>> Arch Linux. The problem occurs when KiCad is linked against wxGTK2, but
>>>> wxPython uses wxGTK3. In such case KiCad loads wxGTK2 libraries on start
>>>> and when wxPython is initialized - it tries to load wxGTK3 causing
>>>> symbol conflicts. I guess there is not much we can do about it, apart
>>>> from detecting such situation and informing the user about the problem
>>>> cause. Any other ideas?
>>>> 
>>>> Cheers,
>>>> Orson
>>>> <0001-GTK3-Display-a-warning-and-enable-wxGraphicsContext.patch><0002-wxWidgets-GTK3-compatibility-fixes-for-eeschema.patch>___
>>>> 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
>>> 
>>> 
>>> ___
>>> 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
>> 
>> 
>> ___
>> 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
> 


___
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

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

Wayne,

I don’t think so.

I use a stock MacPorts boost since long before you removed boost from KiCad 
build.
This might not be representative, but I didn’t see any problems.

I had a quick look into Adams build scripts and I didn’t see that he is 
building his own boost (with the patches) somewhere.


Regards,
Bernhard

> On 30. Jan 2018, at 21:58, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> Bernhard,
> 
> What about the macos boost and context patches?  Do we still need to
> keep them?
> 
> Thanks,
> 
> Wayne
> 
> On 1/29/2018 1:23 PM, Bernhard Stegmaier wrote:
>> Wayne,
>> 
>> yes, from my side you can delete them.
>> Even if deleted they are in git anyway, so we can restore them if really
>> needed.
>> I’ll try to change documentation ASAP.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 29. Jan 2018, at 19:15, Wayne Stambaugh <stambau...@gmail.com 
>>> <mailto:stambau...@gmail.com>
>>> <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> wrote:
>>> 
>>> Bernhard,
>>> 
>>> Am I safe deleting the macos patches from the source repo or do I need
>>> to hold off until the dust has settle on the new wx repo?
>>> 
>>> Thanks,
>>> 
>>> Wayne
>>> 
>>> On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
>>>> The full original soname patch seems to fix the issue in my builds (I
>>>> did apply only half of it to our fork because of the comments in
>>>> wxWidgets trac).
>>>> I pushed it to the fork.
>>>> The next build should pick it up automatically and be good again… sorry
>>>> for not having checked this before.
>>>> 
>>>> I also did set the bug to “Fix Committed”.
>>>> 
>>>> 
>>>> BTW @Adam:
>>>> There are still 2 wxPython macOS patches:
>>>> (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
>>>> stuff for wxWidgets.
>>>> (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as
>>>> far as I can see and it seems to be fine without?
>>>>   => Still needed?
>>>> 
>>>> 
>>>> Regards,
>>>> Bernhard
>>>> 
>>>> 
>>>>> On 29. Jan 2018, at 13:47, Bernhard Stegmaier
>>>>> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de> 
>>>>> <mailto:stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>>
>>>>> <mailto:stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>>> wrote:
>>>>> 
>>>>> Just a short status…
>>>>> I just tried the compile_wx.sh script and it generally seems to be fine.
>>>>> 
>>>>> But, I can see that obviously the wxPython installer duplicates libs
>>>>> instead of symlinking them.
>>>>> Maybe the original soname patch we had is needed for that one to work
>>>>> correctly.
>>>>> I’ll check…
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Bernhard
>>>>> 
>>>>> 
>>>>>> On 29. Jan 2018, at 00:32, Adam Wolf <adamw...@feelslikeburning.com 
>>>>>> <mailto:adamw...@feelslikeburning.com>
>>>>>> <mailto:adamw...@feelslikeburning.com 
>>>>>> <mailto:adamw...@feelslikeburning.com>>
>>>>>> <mailto:adamw...@feelslikeburning.com 
>>>>>> <mailto:adamw...@feelslikeburning.com>>> wrote:
>>>>>> 
>>>>>> I think I see it now.  I can probably fix this tonight.  Thanks!
>>>>>> 
>>>>>> Adam
>>>>>> 
>>>>>> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
>>>>>> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>
>>>>>> <mailto:stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>> 
>>>>>> <mailto:stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>>>
>>>>>> wrote:
>>>>>> 
>>>>>>Quick look into the build… seems to pull in wrong wxWidgets libs.
>>>>>>The build in question includes some 3.0.0 wxWidgets libraries
>>>>>>which I guess come from wxPython download.
>>>>>>The fork should create 3.0.4 libraries...
>>>>>> 
>>>>>>>

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

Wayne,

yes, from my side you can delete them.
Even if deleted they are in git anyway, so we can restore them if really needed.
I’ll try to change documentation ASAP.


Regards,
Bernhard

> On 29. Jan 2018, at 19:15, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> Bernhard,
> 
> Am I safe deleting the macos patches from the source repo or do I need
> to hold off until the dust has settle on the new wx repo?
> 
> Thanks,
> 
> Wayne
> 
> On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
>> The full original soname patch seems to fix the issue in my builds (I
>> did apply only half of it to our fork because of the comments in
>> wxWidgets trac).
>> I pushed it to the fork.
>> The next build should pick it up automatically and be good again… sorry
>> for not having checked this before.
>> 
>> I also did set the bug to “Fix Committed”.
>> 
>> 
>> BTW @Adam:
>> There are still 2 wxPython macOS patches:
>> (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
>> stuff for wxWidgets.
>> (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as
>> far as I can see and it seems to be fine without?
>>   => Still needed?
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> 
>>> On 29. Jan 2018, at 13:47, Bernhard Stegmaier <stegma...@sw-systems.de
>>> <mailto:stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>>> wrote:
>>> 
>>> Just a short status…
>>> I just tried the compile_wx.sh script and it generally seems to be fine.
>>> 
>>> But, I can see that obviously the wxPython installer duplicates libs
>>> instead of symlinking them.
>>> Maybe the original soname patch we had is needed for that one to work
>>> correctly.
>>> I’ll check…
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
>>> 
>>>> On 29. Jan 2018, at 00:32, Adam Wolf <adamw...@feelslikeburning.com 
>>>> <mailto:adamw...@feelslikeburning.com>
>>>> <mailto:adamw...@feelslikeburning.com 
>>>> <mailto:adamw...@feelslikeburning.com>>> wrote:
>>>> 
>>>> I think I see it now.  I can probably fix this tonight.  Thanks!
>>>> 
>>>> Adam
>>>> 
>>>> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
>>>> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de> 
>>>> <mailto:stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>>> wrote:
>>>> 
>>>>Quick look into the build… seems to pull in wrong wxWidgets libs.
>>>>The build in question includes some 3.0.0 wxWidgets libraries
>>>>which I guess come from wxPython download.
>>>>The fork should create 3.0.4 libraries...
>>>> 
>>>>>On 29. Jan 2018, at 00:05, Bernhard Stegmaier
>>>>><stegma...@sw-systems.de <mailto:stegma...@sw-systems.de> 
>>>>> <mailto:stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>>> wrote:
>>>>> 
>>>>>I just had a quick look and it looks fine.
>>>>> 
>>>>>Also my first guess is that maybe something got messed up in the
>>>>>folder hierarchy when copying wxPython/wxWidgets together, so
>>>>>that e.g. here
>>>>>  WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
>>>>>some wrong wxWidgets (not the one of the fork) gets pulled in.
>>>>> 
>>>>>    Too late here already to check just by review, will try tomorrow… :)
>>>>> 
>>>>>>On 29. Jan 2018, at 00:00, Adam Wolf
>>>>>><adamw...@feelslikeburning.com <mailto:adamw...@feelslikeburning.com>
>>>>>><mailto:adamw...@feelslikeburning.com 
>>>>>> <mailto:adamw...@feelslikeburning.com>>> wrote:
>>>>>> 
>>>>>>Yeah.  The previous build script downloaded a wxpython tarball,
>>>>>>which included wxwidgets.
>>>>>> 
>>>>>>All my update did was move the wxpython subdirectory into a git
>>>>>>checkout of the wxwidgets tree, and build that way.
>>>>>> 
>>>>>>One quick thing would be to just do a diff between the
>>>>>>wxwidgets included with wxpython 3.0.2.0, and the tree.  At
>>>>>>this point, nothing would surprise me :)

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

The full original soname patch seems to fix the issue in my builds (I did apply 
only half of it to our fork because of the comments in wxWidgets trac).
I pushed it to the fork.
The next build should pick it up automatically and be good again… sorry for not 
having checked this before.

I also did set the bug to “Fix Committed”.


BTW @Adam:
There are still 2 wxPython macOS patches:
(1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay stuff 
for wxWidgets.
(2) I don’t know about the “…_multiarch.patch”. You don’t apply it as far as I 
can see and it seems to be fine without?
  => Still needed?


Regards,
Bernhard


> On 29. Jan 2018, at 13:47, Bernhard Stegmaier <stegma...@sw-systems.de> wrote:
> 
> Just a short status…
> I just tried the compile_wx.sh script and it generally seems to be fine.
> 
> But, I can see that obviously the wxPython installer duplicates libs instead 
> of symlinking them.
> Maybe the original soname patch we had is needed for that one to work 
> correctly.
> I’ll check…
> 
> 
> Regards,
> Bernhard
> 
> 
>> On 29. Jan 2018, at 00:32, Adam Wolf <adamw...@feelslikeburning.com 
>> <mailto:adamw...@feelslikeburning.com>> wrote:
>> 
>> I think I see it now.  I can probably fix this tonight.  Thanks!
>> 
>> Adam
>> 
>> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier" <stegma...@sw-systems.de 
>> <mailto:stegma...@sw-systems.de>> wrote:
>> Quick look into the build… seems to pull in wrong wxWidgets libs.
>> The build in question includes some 3.0.0 wxWidgets libraries which I guess 
>> come from wxPython download.
>> The fork should create 3.0.4 libraries...
>> 
>>> On 29. Jan 2018, at 00:05, Bernhard Stegmaier <stegma...@sw-systems.de 
>>> <mailto:stegma...@sw-systems.de>> wrote:
>>> 
>>> I just had a quick look and it looks fine.
>>> 
>>> Also my first guess is that maybe something got messed up in the folder 
>>> hierarchy when copying wxPython/wxWidgets together, so that e.g. here
>>>   WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
>>> some wrong wxWidgets (not the one of the fork) gets pulled in.
>>> 
>>> Too late here already to check just by review, will try tomorrow… :)
>>> 
>>>> On 29. Jan 2018, at 00:00, Adam Wolf <adamw...@feelslikeburning.com 
>>>> <mailto:adamw...@feelslikeburning.com>> wrote:
>>>> 
>>>> Yeah.  The previous build script downloaded a wxpython tarball, which 
>>>> included wxwidgets.
>>>> 
>>>> All my update did was move the wxpython subdirectory into a git checkout 
>>>> of the wxwidgets tree, and build that way.
>>>> 
>>>> One quick thing would be to just do a diff between the wxwidgets included 
>>>> with wxpython 3.0.2.0, and the tree.  At this point, nothing would 
>>>> surprise me :)
>>>> 
>>>> Adam
>>>> 
>>>> 
>>>> 
>>>> On Jan 28, 2018 4:54 PM, "Bernhard Stegmaier" <stegma...@sw-systems.de 
>>>> <mailto:stegma...@sw-systems.de>> wrote:
>>>> Sure.
>>>> I’ll have a look tomorrow and try to build wxWidgets/wxPython the same way 
>>>> the script does.
>>>> 
>>>>> On 28. Jan 2018, at 23:44, Nick Østergaard <oe.n...@gmail.com 
>>>>> <mailto:oe.n...@gmail.com>> wrote:
>>>>> 
>>>>> You don't need to revert it. I can just choose the latest workin hash in 
>>>>> the jenkins job. I would rather we fix it somehow. :)
>>>>> 
>>>>> @Bernhard, the build scripts in question are 
>>>>> https://github.com/wayneandlayne/KiCadMacOSPackaging 
>>>>> <https://github.com/wayneandlayne/KiCadMacOSPackaging>
>>>>> 
>>>>> Maybe you can have a got at it?
>>>>> 
>>>>> 2018-01-28 23:41 GMT+01:00 Nick Østergaard <oe.n...@gmail.com 
>>>>> <mailto:oe.n...@gmail.com>>:
>>>>> I assume this is the bug you are talking about:
>>>>> https://bugs.launchpad.net/kicad/+bug/1745868 
>>>>> <https://bugs.launchpad.net/kicad/+bug/1745868>
>>>>> 
>>>>> 2018-01-28 23:14 GMT+01:00 Adam Wolf <adamw...@feelslikeburning.com 
>>>>> <mailto:adamw...@feelslikeburning.com>>:
>>>>> I was able to get the wxwidgets stuff switched over but there's a bug in 
>>>>> the big tracker saying it didn't wo

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

Just a short status…
I just tried the compile_wx.sh script and it generally seems to be fine.

But, I can see that obviously the wxPython installer duplicates libs instead of 
symlinking them.
Maybe the original soname patch we had is needed for that one to work correctly.
I’ll check…


Regards,
Bernhard


> On 29. Jan 2018, at 00:32, Adam Wolf <adamw...@feelslikeburning.com> wrote:
> 
> I think I see it now.  I can probably fix this tonight.  Thanks!
> 
> Adam
> 
> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier" <stegma...@sw-systems.de 
> <mailto:stegma...@sw-systems.de>> wrote:
> Quick look into the build… seems to pull in wrong wxWidgets libs.
> The build in question includes some 3.0.0 wxWidgets libraries which I guess 
> come from wxPython download.
> The fork should create 3.0.4 libraries...
> 
>> On 29. Jan 2018, at 00:05, Bernhard Stegmaier <stegma...@sw-systems.de 
>> <mailto:stegma...@sw-systems.de>> wrote:
>> 
>> I just had a quick look and it looks fine.
>> 
>> Also my first guess is that maybe something got messed up in the folder 
>> hierarchy when copying wxPython/wxWidgets together, so that e.g. here
>>   WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
>> some wrong wxWidgets (not the one of the fork) gets pulled in.
>> 
>> Too late here already to check just by review, will try tomorrow… :)
>> 
>>> On 29. Jan 2018, at 00:00, Adam Wolf <adamw...@feelslikeburning.com 
>>> <mailto:adamw...@feelslikeburning.com>> wrote:
>>> 
>>> Yeah.  The previous build script downloaded a wxpython tarball, which 
>>> included wxwidgets.
>>> 
>>> All my update did was move the wxpython subdirectory into a git checkout of 
>>> the wxwidgets tree, and build that way.
>>> 
>>> One quick thing would be to just do a diff between the wxwidgets included 
>>> with wxpython 3.0.2.0, and the tree.  At this point, nothing would surprise 
>>> me :)
>>> 
>>> Adam
>>> 
>>> 
>>> 
>>> On Jan 28, 2018 4:54 PM, "Bernhard Stegmaier" <stegma...@sw-systems.de 
>>> <mailto:stegma...@sw-systems.de>> wrote:
>>> Sure.
>>> I’ll have a look tomorrow and try to build wxWidgets/wxPython the same way 
>>> the script does.
>>> 
>>>> On 28. Jan 2018, at 23:44, Nick Østergaard <oe.n...@gmail.com 
>>>> <mailto:oe.n...@gmail.com>> wrote:
>>>> 
>>>> You don't need to revert it. I can just choose the latest workin hash in 
>>>> the jenkins job. I would rather we fix it somehow. :)
>>>> 
>>>> @Bernhard, the build scripts in question are 
>>>> https://github.com/wayneandlayne/KiCadMacOSPackaging 
>>>> <https://github.com/wayneandlayne/KiCadMacOSPackaging>
>>>> 
>>>> Maybe you can have a got at it?
>>>> 
>>>> 2018-01-28 23:41 GMT+01:00 Nick Østergaard <oe.n...@gmail.com 
>>>> <mailto:oe.n...@gmail.com>>:
>>>> I assume this is the bug you are talking about:
>>>> https://bugs.launchpad.net/kicad/+bug/1745868 
>>>> <https://bugs.launchpad.net/kicad/+bug/1745868>
>>>> 
>>>> 2018-01-28 23:14 GMT+01:00 Adam Wolf <adamw...@feelslikeburning.com 
>>>> <mailto:adamw...@feelslikeburning.com>>:
>>>> I was able to get the wxwidgets stuff switched over but there's a bug in 
>>>> the big tracker saying it didn't work.  I will continue to look into it as 
>>>> I can.  I should be over this illness by the end of this week, it looks 
>>>> like.
>>>> 
>>>> I can revert the packaging change so the next builds will work again.
>>>> 
>>>> Sorry folks, I have lost weeks and weeks of productivity and am trying to 
>>>> do my best.
>>>> 
>>>> Adam
>>>> 
>>>> ___
>>>> Mailing list: https://launchpad.net/~kicad-developers 
>>>> <https://launchpad.net/~kicad-developers>
>>>> Post to : kicad-developers@lists.launchpad.net 
>>>> <mailto:kicad-developers@lists.launchpad.net>
>>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>>> <https://launchpad.net/~kicad-developers>
>>>> More help   : https://help.launchpad.net/ListHelp 
>>>> <https://help.launchpad.net/ListHelp>
>>>> 
>>>> 
>>>> 
>>>> ___

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

Sure.
I’ll have a look tomorrow and try to build wxWidgets/wxPython the same way the 
script does.

> On 28. Jan 2018, at 23:44, Nick Østergaard  wrote:
> 
> You don't need to revert it. I can just choose the latest workin hash in the 
> jenkins job. I would rather we fix it somehow. :)
> 
> @Bernhard, the build scripts in question are 
> https://github.com/wayneandlayne/KiCadMacOSPackaging 
> 
> 
> Maybe you can have a got at it?
> 
> 2018-01-28 23:41 GMT+01:00 Nick Østergaard  >:
> I assume this is the bug you are talking about:
> https://bugs.launchpad.net/kicad/+bug/1745868 
> 
> 
> 2018-01-28 23:14 GMT+01:00 Adam Wolf  >:
> I was able to get the wxwidgets stuff switched over but there's a bug in the 
> big tracker saying it didn't work.  I will continue to look into it as I can. 
>  I should be over this illness by the end of this week, it looks like.
> 
> I can revert the packaging change so the next builds will work again.
> 
> Sorry folks, I have lost weeks and weeks of productivity and am trying to do 
> my best.
> 
> Adam
> 
> ___
> 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 
> 
> 
> 
> 
> ___
> 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

___
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

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

That seems to be the same error as when the former so-name patch was not 
applied and original wxWidgets build stuff rewrites library names.
The bundle is corrupt then, because the bundling code fails to create symlinks 
and copies libs instead multiple times.

If you can send me where to find the current state, I can have look into it 
tomorrow.
I could imagine that it has to do with how wxPython is built… I have seen 
similar library rewrite stuff in some python build scripts (which the patch 
doesn’t fix).

However, shouldn’t make any difference, the fork contains all the stuff we had 
in the patches before.


Regards,
Bernhard

> On 28. Jan 2018, at 23:41, Nick Østergaard  wrote:
> 
> I assume this is the bug you are talking about:
> https://bugs.launchpad.net/kicad/+bug/1745868 
> 
> 
> 2018-01-28 23:14 GMT+01:00 Adam Wolf  >:
> I was able to get the wxwidgets stuff switched over but there's a bug in the 
> big tracker saying it didn't work.  I will continue to look into it as I can. 
>  I should be over this illness by the end of this week, it looks like.
> 
> I can revert the packaging change so the next builds will work again.
> 
> Sorry folks, I have lost weeks and weeks of productivity and am trying to do 
> my best.
> 
> Adam
> 
> ___
> 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 
> 
> 
> 
> ___
> 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

___
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

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

Which bug?


Bernhard

> On 28. Jan 2018, at 23:14, Adam Wolf  wrote:
> 
> I was able to get the wxwidgets stuff switched over but there's a bug in the 
> big tracker saying it didn't work.  I will continue to look into it as I can. 
>  I should be over this illness by the end of this week, it looks like.
> 
> I can revert the packaging change so the next builds will work again.
> 
> Sorry folks, I have lost weeks and weeks of productivity and am trying to do 
> my best.
> 
> Adam
> ___
> 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


___
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

Re: [Kicad-developers] macos patch removal.

[Bernhard Stegmaier]

I guess so.
AFAIK Adam has the patches for his build setup anyway.
Anyway, would be good to get that confirmed… @Adam?

I still have to adjust the build instructions (I also try to do that this 
weekend).
So, if you remove them now maybe someone new won’t find them according to the 
docs.


Regards,
Bernhard

> On 27. Jan 2018, at 14:22, Wayne Stambaugh  wrote:
> 
> Is it safe for me to remove the wx macos patches from the source tree?
> I would like to get that done this weekend.
> 
> Cheers,
> 
> Wayne
> 
> ___
> 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


___
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

Re: [Kicad-developers] Update PCB from Schematic dialog issues

[Bernhard Stegmaier]

Thanks, Jeff.

So, this brings up a very general question:
How far do we want to go with patching wxWidgets in our fork?

Don’t get me wrong… the patch looks sane and I guess it then will look on macOS 
like it does on Linux/Windows - for whatever reason (bug, intended?) it didn’t 
look like that before.
Opinions?
Wayne?

From a pure user perspective I guess it would be more important to have it 
look/behave the same on all platforms (as long as it doesn’t break OS specific 
GUI stuff).
So, I am not opposed to apply such patches and all that might come in future...


Regards,
Bernhard

> On 23. Jan 2018, at 22:30, Jeff Young <j...@rokeby.ie> wrote:
> 
> Thanks, Bernhard.  I tried that, but it didn’t help.
> 
> I ended up taking out a pretty big hammer: I overrode the setFrameOrigin 
> method for radioButtons.  When radio buttons are created in a column-oriented 
> radio box, they now get a wxLEFT style.  The setFrameOrigin override bangs 
> the x value back to 8 if that flag is set.
> 
> Patch in https://bugs.launchpad.net/kicad/+bug/1745026 
> <https://bugs.launchpad.net/kicad/+bug/1745026>.
> 
> Cheers,
> Jeff.
> 
> 
>> On 23 Jan 2018, at 16:24, Bernhard Stegmaier <stegma...@sw-systems.de 
>> <mailto:stegma...@sw-systems.de>> wrote:
>> 
>> In wxWidgets master there are a couple of alignment fixes like this one:
>>   
>> https://github.com/wxWidgets/wxWidgets/commit/5aa66ffd936d00d101f12d6e8305a0d2f6c82cc2#diff-4c33f04f2d98bef24c5f526f6fa79d33
>>  
>> <https://github.com/wxWidgets/wxWidgets/commit/5aa66ffd936d00d101f12d6e8305a0d2f6c82cc2#diff-4c33f04f2d98bef24c5f526f6fa79d33>
>> 
>> I don’t know if some of them fix that problem.
>> My last wxWidgets master build shows the same behaviour but I don’t know for 
>> sure if those fixes were already in.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 23. Jan 2018, at 15:40, Jeff Young <j...@rokeby.ie 
>>> <mailto:j...@rokeby.ie>> wrote:
>>> 
>>> Yeah, it’s just most noticeable in Read Netlist, but in fact it’s all radio 
>>> buttons in a box sizer:
>>> 
>>> 
>>> 
>>>> On 23 Jan 2018, at 14:35, Jeff Young <j...@rokeby.ie 
>>>> <mailto:j...@rokeby.ie>> wrote:
>>>> 
>>>> Note: I’ve split the dialog issues out into a separate thread.
>>>> 
>>>> Hi Wayne, 
>>>> 
>>>> It still happens.  I have wxFormBuilder running, but none of the settings 
>>>> affect the centering.  I suspect it’s just how the wxWidgets team 
>>>> implemented it on OSX.
>>>> 
>>>> I might light at it again while putting my flame-suit on over Undo. ;)
>>>> 
>>>> Cheers,
>>>> Jeff.
>>>> 
>>>> 
>>>>> On 23 Jan 2018, at 14:19, Wayne Stambaugh <stambau...@gmail.com 
>>>>> <mailto:stambau...@gmail.com>> wrote:
>>>>> 
>>>>> Jeff,
>>>>> 
>>>>> Is this still an issue.  This dialog looks fine on windows and linux so
>>>>> I have no way of confirming that any changes to the wxformbuilder
>>>>> settings would fix it.  Any of our macos devs have wxformbuilder on
>>>>> their system so they can fix this?
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Wayne
>>>>> 
>>>>> On 1/18/2018 1:17 PM, Jeff Young wrote:
>>>>>> It’s not center vs. left alignment, but rather that the radio button
>>>>>> group is centered within the staticTextBox.  Note in particular the
>>>>>> alignment of the two radio button groups in the left column:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 18 Jan 2018, at 17:23, Nick Østergaard <oe.n...@gmail.com 
>>>>>>> <mailto:oe.n...@gmail.com>
>>>>>>> <mailto:oe.n...@gmail.com <mailto:oe.n...@gmail.com>>> wrote:
>>>>>>> 
>>>>>>> What do you mean by centered? I don't see anything centered, I just
>>>>>>> see them left aligned. Looks ok to me unless I am looking at the wrong
>>>>>>> thing.
>>>>>>> 
>>>>>>> 2018-01-14 <tel:20%2018%2001%2014 <tel:20%2018%2001%2014>> 0:02 
>>>>>>> GMT+01:00 Jeff Young
>>>>>>> <j...@rokeby.ie <mailto:j...@rokeby.ie> <mailto:j...@rokeby.ie 
>>>>>>> <mailto:j...@rokeby.ie>>>

Re: [Kicad-developers] Update PCB from Schematic

[Bernhard Stegmaier]

… one of the problems with wxformbuilder.
Last time I tried (well, some while back) the best version I found for OSX was 
too old and didn’t work.

Lost a couple of days and finally made the changes on my work (Windows) laptop… 
:(


Regards,
Bernhard

> On 23. Jan 2018, at 15:19, Wayne Stambaugh  wrote:
> 
> Jeff,
> 
> Is this still an issue.  This dialog looks fine on windows and linux so
> I have no way of confirming that any changes to the wxformbuilder
> settings would fix it.  Any of our macos devs have wxformbuilder on
> their system so they can fix this?
> 
> Cheers,
> 
> Wayne
> 
> On 1/18/2018 1:17 PM, Jeff Young wrote:
>> It’s not center vs. left alignment, but rather that the radio button
>> group is centered within the staticTextBox.  Note in particular the
>> alignment of the two radio button groups in the left column:
>> 
>> 
>> 
>>> On 18 Jan 2018, at 17:23, Nick Østergaard >> > wrote:
>>> 
>>> What do you mean by centered? I don't see anything centered, I just
>>> see them left aligned. Looks ok to me unless I am looking at the wrong
>>> thing.
>>> 
>>> 2018-01-14  0:02 GMT+01:00 Jeff Young
>>> >:
>>> 
>>>This is a shortcut for eeschema Annotate + eeschema Write Netlist
>>>+ pcbnew Read Netlist, right?
>>> 
>>>Is there a reason the Update PCB from Schematic dialog doesn’t
>>>include the “keep/delete” options we have in the Read Netlist dialog?
>>> 
>>>(It appears to mostly do a delete, but not
>>>entirely: https://bugs.launchpad.net/kicad/+bug/1682970
>>> )
>>> 
>>>(Are the Read Netlist dialog radio buttons really meant to be
>>>centered?  They look distinctly odd.)
>>> 
>>> 
>>> 
>>>___
>>>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
>>>
>>> 
>>> 
>> 
>> 
>> 
>> ___
>> 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
>> 
> 
> ___
> 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


___
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

Re: [Kicad-developers] Update PCB from Schematic dialog issues

[Bernhard Stegmaier]

In wxWidgets master there are a couple of alignment fixes like this one:
  
https://github.com/wxWidgets/wxWidgets/commit/5aa66ffd936d00d101f12d6e8305a0d2f6c82cc2#diff-4c33f04f2d98bef24c5f526f6fa79d33
 


I don’t know if some of them fix that problem.
My last wxWidgets master build shows the same behaviour but I don’t know for 
sure if those fixes were already in.


Regards,
Bernhard

> On 23. Jan 2018, at 15:40, Jeff Young  wrote:
> 
> Yeah, it’s just most noticeable in Read Netlist, but in fact it’s all radio 
> buttons in a box sizer:
> 
> 
> 
>> On 23 Jan 2018, at 14:35, Jeff Young > > wrote:
>> 
>> Note: I’ve split the dialog issues out into a separate thread.
>> 
>> Hi Wayne, 
>> 
>> It still happens.  I have wxFormBuilder running, but none of the settings 
>> affect the centering.  I suspect it’s just how the wxWidgets team 
>> implemented it on OSX.
>> 
>> I might light at it again while putting my flame-suit on over Undo. ;)
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 23 Jan 2018, at 14:19, Wayne Stambaugh >> > wrote:
>>> 
>>> Jeff,
>>> 
>>> Is this still an issue.  This dialog looks fine on windows and linux so
>>> I have no way of confirming that any changes to the wxformbuilder
>>> settings would fix it.  Any of our macos devs have wxformbuilder on
>>> their system so they can fix this?
>>> 
>>> Cheers,
>>> 
>>> Wayne
>>> 
>>> On 1/18/2018 1:17 PM, Jeff Young wrote:
 It’s not center vs. left alignment, but rather that the radio button
 group is centered within the staticTextBox.  Note in particular the
 alignment of the two radio button groups in the left column:
 
 
 
> On 18 Jan 2018, at 17:23, Nick Østergaard  
> >> wrote:
> 
> What do you mean by centered? I don't see anything centered, I just
> see them left aligned. Looks ok to me unless I am looking at the wrong
> thing.
> 
> 2018-01-14 > 0:02 GMT+01:00 
> Jeff Young
>   >>:
> 
>   This is a shortcut for eeschema Annotate + eeschema Write Netlist
>   + pcbnew Read Netlist, right?
> 
>   Is there a reason the Update PCB from Schematic dialog doesn’t
>   include the “keep/delete” options we have in the Read Netlist dialog?
> 
>   (It appears to mostly do a delete, but not
>   entirely: https://bugs.launchpad.net/kicad/+bug/1682970 
> 
>    > )
> 
>   (Are the Read Netlist dialog radio buttons really meant to be
>   centered?  They look distinctly odd.)
> 
> 
> 
>   ___
>   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 
> 
>    >
> 
> 
 
 
 
 ___
 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 
 
 
>>> 
>>> ___
>>> 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 
>>> 
>> 
>> 

Re: [Kicad-developers] KiCad (macOS) wxWidgets fork

[Bernhard Stegmaier]

Hi Jeff,

that’s what I use:

../wxWidgets-KiCad/configure --prefix=/Volumes/OSXData/bstegmaier/KiCad/wx-3.0 
--with-opengl --enable-aui --enable-utf8 --enable-html --enable-stl 
--with-libjpeg=builtin --with-libpng=builtin --with-regex=builtin 
--with-libtiff=builtin --with-zlib=builtin --with-expat=builtin 
--without-liblzma --with-macosx-version-min=10.12 --enable-macosx_arch=x86_64 
CC=clang CXX=clang++

Seems to be pretty identical.
The —enable-universal-binary is different… is this correct?

Wrt .gitignore:
Yes, I didn’t create one.
I don’t know if there is one, didn’t look for it.
I usually build in parallel folder, so I don’t have any compile things in 
source folder.


Regards,
Bernhard

> On 20. Jan 2018, at 14:43, Jeff Young <j...@rokeby.ie> wrote:
> 
> Hi Bernhard,
> 
> Could you share the config command you used to set up wxWidgets?  I used:
> 
> ../configure \
> --prefix=`pwd`/../wx-bin \
> --with-opengl \
> --enable-aui \
> --enable-utf8 \
> --enable-html \
> --enable-stl \
> --enable-debug \
> --enable-debug-gdb \
> --with-libjpeg=builtin \
> --with-libpng=builtin \
> --with-regex=builtin \
> --with-libtiff=builtin \
> --with-zlib=builtin \
> --with-expat=builtin \
> --without-liblzma \
> --with-macosx-version-min=10.13 \
> --enable-universal-binary=x86_64 \
> CC=clang \
> CXX=clang++
> 
> but I’m getting a make error:
> 
> make: *** No rule to make target `../include/wx/osx/cocoa/stdpaths.h', needed 
> by `basedll_appbase.o'.  Stop.
> 
> I assume I’m on the right branch:
> 
> Jeffs-MBP:build jeff$ git status
> On branch kicad/macos-wx-3.0
> Your branch is up-to-date with 'origin/kicad/macos-wx-3.0’.
> 
> Thanks,
> Jeff.
> 
> PS: I also seem to be missing a .gitignore file.  Is that not in yet, or is 
> that a symptom of something else?
> 
> 
>> On 19 Jan 2018, at 16:49, Bernhard Stegmaier <stegma...@sw-systems.de 
>> <mailto:stegma...@sw-systems.de>> wrote:
>> 
>> Hi,
>> 
>>> On 15. Jan 2018, at 10:39, Carsten Schoenert <c.schoen...@t-online.de 
>>> <mailto:c.schoen...@t-online.de>> wrote:
>>>> 
>>>> We should make it obvious that it is a branch of wxwidgets for kicad
>>>> specifically patched for macos to avoid any confusion.
>>> based on my experiences in other projects I suggest to use topic and
>>> prefixed branch names. I'd avoid the usage of capital letters.
>>> 
>>> e.g.
>>> kicad/macos-10
>>> kicad/macos-11
>>> kicad/wx-3.0.3
>> 
>> Good proposal, I like that.
>> So, I created a branch
>> 
>>   kicad/macos-wx-3.0
>> 
>> based on the original WX_3_0_BRANCH.
>> If at some point patches for other OS (e.g., the mingw patches) should go 
>> in, we can still rename it and remove the macOS part.
>> 
>>>> 2) Commits
>>>> The branch should always be rebased to wxWidgets changes, so all
>>>> patches will stay at the top.
>>> Rethink about rebasing to hold the branches in sync with upstream as
>>> this breaks clones of your branches due smashed SHA IDs and people would
>>> need to do a hard reset. Just merge any upstream changes as usual into
>>> your branches, in case you want to address / forward your work to
>>> upstream you also would do a merge request then. That's the typicall
>>> workflow I know in such cases.
>> 
>> Thanks for the reminder, I tend to forget that.
>> So, no rebasing but merging.
>> 
>>>> I still find it somehow difficult to see where original branch ends
>>>> and own changes start.> Should we add some prefix “KiCad: …” to all commit 
>>>> messages?
>>> 
>>> I see no need to do so as you work on "your" branch and merge commits
>>> are visible as that they are, I personally do some prefixing in my work
>>> in the subject for the file, component, part, OS (...) the commit is about.
>> 
>> I decided to prefix every change with “macOS: “, just in case the branch 
>> gets used for other OS in future.
>> 
>> 
>> I reviewed all the patches and only applied what was still needed/valid.
>> See end of the mail for details.
>> For me, it compiles on macOS 10.12 and 10.13 (with macosx-version-min from 
>> 10.13 down to 10.7).
>> 
>> The branch should be ready to use now.
>> All macOS devs please test if you see any problems or if anything is missing.
>> 
>> As soon as Adam has integrated it into the daily builds also the current 
>> build errors should be

Re: [Kicad-developers] KiCad (macOS) wxWidgets fork

[Bernhard Stegmaier]

Hi,

> On 15. Jan 2018, at 10:39, Carsten Schoenert  wrote:
>> 
>> We should make it obvious that it is a branch of wxwidgets for kicad
>> specifically patched for macos to avoid any confusion.
> based on my experiences in other projects I suggest to use topic and
> prefixed branch names. I'd avoid the usage of capital letters.
> 
> e.g.
> kicad/macos-10
> kicad/macos-11
> kicad/wx-3.0.3

Good proposal, I like that.
So, I created a branch

  kicad/macos-wx-3.0

based on the original WX_3_0_BRANCH.
If at some point patches for other OS (e.g., the mingw patches) should go in, 
we can still rename it and remove the macOS part.

>> 2) Commits
>> The branch should always be rebased to wxWidgets changes, so all
>> patches will stay at the top.
> Rethink about rebasing to hold the branches in sync with upstream as
> this breaks clones of your branches due smashed SHA IDs and people would
> need to do a hard reset. Just merge any upstream changes as usual into
> your branches, in case you want to address / forward your work to
> upstream you also would do a merge request then. That's the typicall
> workflow I know in such cases.

Thanks for the reminder, I tend to forget that.
So, no rebasing but merging.

>> I still find it somehow difficult to see where original branch ends
>> and own changes start.> Should we add some prefix “KiCad: …” to all commit 
>> messages?
> 
> I see no need to do so as you work on "your" branch and merge commits
> are visible as that they are, I personally do some prefixing in my work
> in the subject for the file, component, part, OS (...) the commit is about.

I decided to prefix every change with “macOS: “, just in case the branch gets 
used for other OS in future.


I reviewed all the patches and only applied what was still needed/valid.
See end of the mail for details.
For me, it compiles on macOS 10.12 and 10.13 (with macosx-version-min from 
10.13 down to 10.7).

The branch should be ready to use now.
All macOS devs please test if you see any problems or if anything is missing.

As soon as Adam has integrated it into the daily builds also the current build 
errors should be gone.

Next step would be to adapt KiCad compile documentation and to remove the 
patches from KiCad source.
@Wayne: Is it OK for you to remove the patches?


Regards,
Bernhard

=

Patches applied as in KiCad repository:
  wxwidgets-3.0.0_macosx.patch
  wxwidgets-3.0.0_macosx_bug_15908.patch
  wxwidgets-3.0.0_macosx_staticbox_tabbing.patch
  wxwidgets-3.0.2_macosx_magnify_event.patch
  wxwidgets-3.0.2_macosx_retina_opengl.patch

Applied with changes:
  wxwidgets-3.0.0_macosx_soname.patch
==> See wxWidget ticket
  wxwidgets-3.0.2_macosx_data_view_ctrl.patch
==> See wxWidget ticket, changed to strip out styles in question
  wxwidgets-3.0.2_macosx_quasimodal.patch
==> Corrected version with missing header

No longer needed (already applied or other fix):
  wxwidgets-3.0.0_macosx_scrolledwindow.patch
  wxwidgets-3.0.2_macosx_unicode_pasteboard.patch
  wxwidgets-3.0.2_macosx_high_sierra.patch
  wxwidgets-3.0.2_macosx_sierra.patch
  wxwidgets-3.0.2_macosx_yosemite.patch

Additional patches (not yet in KiCad repository)
  https://bugs.launchpad.net/kicad/+bug/1692352 



___
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

[Kicad-developers] KiCad (macOS) wxWidgets fork

[Bernhard Stegmaier]

Hi all,

after the discussion [1] some while ago (sorry, have been busy since then) Nick 
created a fork of wxWidgets in KiCad GitHub.
Before I start to create an (at least initial) branch, I’d like to get some 
agreements/opinions.

1) Branch name
wxWidgets has a lot of branches (I’ll see if we can delete what we don’t need).
To be consistent to the usual development flow, I’d propose to add the patches 
new branches.
I’d name them 
  KiCad_
If we want to emphasise that this is only for macOS, we could also use
  KiCad_macOS_
Opinions, decisions (@Wayne)?

2) Commits
The branch should always be rebased to wxWidgets changes, so all patches will 
stay at the top.
I still find it somehow difficult to see where original branch ends and own 
changes start.
Should we add some prefix “KiCad: …” to all commit messages?

3) Patches to add
I know what patches are mandatory, but didn’t follow 3.0.x for quite a while.
Especially, I don’t know what patches Adam currently uses for the official 
builds.
So, I need some feedback here (most important @Adam).

Last but not least… if someone else wants to help maintain it, please tell Nick 
to get write access…


Regards,
Bernhard

[1] 
https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg27348.html 



___
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

Re: [Kicad-developers] Do we have a wxWidgets branch yet?

[Bernhard Stegmaier]

Yes… sorry, I didn’t have time yet to start it.
I’ll put some questions to agree on in a mail hopefully this evening…

Regards,
Bernhard

> On 14. Jan 2018, at 13:35, Jeff Young  wrote:
> 
> I had forgotten who was doing it.  My second patch is for a bug he reported, 
> so perhaps this will give him some extra incentive. ;)
> 
>> On 14 Jan 2018, at 12:08, Nick Østergaard > > wrote:
>> 
>> No, but I think Bernhard wanted to maintin it. I have not seen him push 
>> anything.
>> 
>> Den 14. jan. 2018 13.03 skrev "Jeff Young" > >:
>> I’ve got a couple of patches that need to go into it.
>> 
>> [1] wxwidgets-3.0.2_macosx_quasimodal.patch  
>> (https://bugs.launchpad.net/kicad/+bug/1741881 
>> )
>> [2] wxwidgets-3.0.2_macosx_setLevel.patch  
>> (https://bugs.launchpad.net/kicad/+bug/1692352 
>> )
>> 
>> ___
>> 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 
>> 
>> 
> 
> ___
> 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

___
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

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

[Bernhard Stegmaier]

I know… I just wanted to check that it is still OK after your patch.
Jeff already did, so everything fine.

> On 9. Jan 2018, at 18:28, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
> 
> OSX/macOS has built-in scaling for those, other operating systems don't.
> 
> On Tue, Jan 09, 2018 at 02:40:20PM +0100, Bernhard Stegmaier wrote:
>> Hi Chris,
>> 
>> can you show a screenshot what this patch fixes?
>> I have a Retina MacBook and for my taste the toolbar icons are pretty OK 
>> without any patch…
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 9. Jan 2018, at 14:27, Maciej Sumiński <maciej.sumin...@cern.ch> wrote:
>>> 
>>> Hi Chris,
>>> 
>>> The patch does not apply cleanly on the current master, would you rebase
>>> it? Thanks in advance.
>>> 
>>> Cheers,
>>> Orson
>>> 
>>> On 01/09/2018 03:43 AM, Chris Pavlina wrote:
>>>> Hi,
>>>> 
>>>> As discussed with Wayne earlier, I've attached a patch which adds simple
>>>> toolbar icon scaling so the toolbars are readable on high-DPI systems.
>>>> 
>>>> This is meant as a stopgap for 5.0, with plans to add proper scaled
>>>> icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
>>>> works like KiBitmap() except it scales the bitmap according to the
>>>> calling window's font size. Controls have been added to all the main
>>>> applications to let the user select scaling manually (these were omitted
>>>> from smaller apps that didn't already have a place to put them).
>>>> 
>>>> In addition, in eeschema only, the pixel height of the system font is
>>>> shown in the options dialog for diagnostics. This is only for collecting
>>>> feedback before 5.0 release from users with different displays and will
>>>> be removed.
>>>> 
>>>> I would like to push this fairly soon, as I want to get as much user
>>>> feedback as possible before release. I have a limited number of systems
>>>> to test this on myself.
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> Mailing list: https://launchpad.net/~kicad-developers 
>>>> <https://launchpad.net/~kicad-developers> 
>>>> <https://launchpad.net/~kicad-developers 
>>>> <https://launchpad.net/~kicad-developers>>
>>>> Post to : kicad-developers@lists.launchpad.net 
>>>> <mailto:kicad-developers@lists.launchpad.net> 
>>>> <mailto:kicad-developers@lists.launchpad.net 
>>>> <mailto:kicad-developers@lists.launchpad.net>>
>>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>>> <https://launchpad.net/~kicad-developers> 
>>>> <https://launchpad.net/~kicad-developers 
>>>> <https://launchpad.net/~kicad-developers>>
>>>> More help   : https://help.launchpad.net/ListHelp 
>>>> <https://help.launchpad.net/ListHelp> <https://help.launchpad.net/ListHelp 
>>>> <https://help.launchpad.net/ListHelp>>
>>>> 
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers> 
>>> <https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>>
>>> Post to : kicad-developers@lists.launchpad.net 
>>> <mailto:kicad-developers@lists.launchpad.net> 
>>> <mailto:kicad-developers@lists.launchpad.net 
>>> <mailto:kicad-developers@lists.launchpad.net>>
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers> 
>>> <https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>>
>>> More help   : https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp> <https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp>>

___
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

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

[Bernhard Stegmaier]

Hi Chris,

can you show a screenshot what this patch fixes?
I have a Retina MacBook and for my taste the toolbar icons are pretty OK 
without any patch…


Regards,
Bernhard

> On 9. Jan 2018, at 14:27, Maciej Sumiński  wrote:
> 
> Hi Chris,
> 
> The patch does not apply cleanly on the current master, would you rebase
> it? Thanks in advance.
> 
> Cheers,
> Orson
> 
> On 01/09/2018 03:43 AM, Chris Pavlina wrote:
>> Hi,
>> 
>> As discussed with Wayne earlier, I've attached a patch which adds simple
>> toolbar icon scaling so the toolbars are readable on high-DPI systems.
>> 
>> This is meant as a stopgap for 5.0, with plans to add proper scaled
>> icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
>> works like KiBitmap() except it scales the bitmap according to the
>> calling window's font size. Controls have been added to all the main
>> applications to let the user select scaling manually (these were omitted
>> from smaller apps that didn't already have a place to put them).
>> 
>> In addition, in eeschema only, the pixel height of the system font is
>> shown in the options dialog for diagnostics. This is only for collecting
>> feedback before 5.0 release from users with different displays and will
>> be removed.
>> 
>> I would like to push this fairly soon, as I want to get as much user
>> feedback as possible before release. I have a limited number of systems
>> to test this on myself.
>> 
>> 
>> 
>> ___
>> 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 
>> 
>> 
> 
> 
> ___
> 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 
> 
___
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

Re: [Kicad-developers] Patches consistency

[Bernhard Stegmaier]

Do you mean
  https://github.com/KiCad <https://github.com/KiCad>
with kicad org or something else?

If someone sets up a fork (with 3.0.x first and possibility for 3.x/master 
later), I could help maintaining it.


Regards,
Bernhard

> On 30. Dec 2017, at 00:45, Nick Østergaard <oe.n...@gmail.com> wrote:
> 
> We could have a fork of wx in the kicad org with a branch where we rebase the 
> patches to. Then it is easy to fetch for others. The osx devs could maintain 
> this. But having it in the kicad org gives more visibility and we don't need 
> to habe them directly in the kicad source. 
> 
> This is just an idea, this proposal might need some more thought.
> 
> Den 29. dec. 2017 23.36 skrev "Wayne Stambaugh" <stambau...@gmail.com 
> <mailto:stambau...@gmail.com>>:
> This seems like a reasonable solution.  Although pointing macOS
> developers to the repo might be an issue.
> 
> On a related note, I was just updating the compiling.md 
> <http://compiling.md/> file and noticed
> that there seem to be quite a few of the macos wxWidgets patches not
> mentioned in the "Building KiCad on macOS" section.  I'm guessing this
> needs to be updated.
> 
> On 12/29/2017 05:27 PM, Bernhard Stegmaier wrote:
> > To be honest, I don’t like the patches as is at all.
> > You never know if patches are still need if there are new versions or if 
> > they still do apply.
> >
> > IMHO it would be a better solution if someone would maintain a fork of 
> > wxwidgets (e.g., on GitHub) with all the needed patches applied, so that 
> > someone who really wants to build just has to sync this… ?
> > For myself, I do this quite some time so I don’t have to apply all the 
> > patches every time (for wxWidgets master).
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 29. Dec 2017, at 22:07, Adam Wolf <adamw...@feelslikeburning.com 
> >> <mailto:adamw...@feelslikeburning.com>> wrote:
> >>
> >> I think the main reason why this happens is that most of those patches
> >> are not created by KiCad devs, but rather taken from upstream mailing
> >> lists, and I have always just preserved the patch as is, but I don't
> >> have a strong opinion on keeping it like it is or changing it to be
> >> more consistent.
> >>
> >> I don't mind how it would get changed, as long as, if it gets changed,
> >> it gets more consistent between the different patches and between the
> >> patches and the docs.
> >>
> >> Adam Wolf
> >>
> >> On Fri, Dec 29, 2017 at 2:37 PM, Wayne Stambaugh <stambau...@gmail.com 
> >> <mailto:stambau...@gmail.com>> wrote:
> >>> Any of our osx devs have an opinion on this?  It doesn't impact me so I
> >>> would rather the devs who have to use this make the call.
> >>>
> >>> On 12/29/2017 03:33 PM, Anton Shevchenko wrote:
> >>>> Hi all,
> >>>>
> >>>> Looking through the code style guide (i'm new here) I didn't find a word 
> >>>> about how a patch file should reference source code file. By patch file 
> >>>> I mean *.patch file located in kicad/patches folder.
> >>>>
> >>>> Being on macOS I'm trying to apply all the patches required for building 
> >>>> wxWidgets and have found that there are 2 different styles in use.
> >>>> First style references source code files without prefix. To apply such a 
> >>>> patch one has to run 'patch -p0'.
> >>>> The other style uses a/ and b/ prefixes which is used with 'patch -p1' 
> >>>> option.
> >>>> In my opinion the last one is more common (and if you run 'git diff' you 
> >>>> will see a/ and b/ prefixes).
> >>>>
> >>>> I would like to fix macOS patches stuff to be able to actually follow 
> >>>> the guide 
> >>>> (http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_osx
> >>>>  
> >>>> <http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_osx>)
> >>>>  in order to build KiCad for macOS.
> >>>>
> >>>> Any comments?
> >>>>
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers 
> >>> <https://launchpad.net/~kicad-developers>
> >>> Post to : kicad-developers@lists.launchpad.net 
> >>> <mailto:kicad-developers@lists

Re: [Kicad-developers] Patches consistency

[Bernhard Stegmaier]

It won’t be that easy to switch to wx3.1:
* They added (previously non-existing) overlay code. It does basically work but 
is slow as hell - and quite different from the overlay patch we have. I didn’t 
have time yet to see whether it is more easy to fix or just replace by our 
patch (which is also in the bug tracker, don’t know why they didn’t take it as 
is).
* Currently all dialogs don’t close when you hit enter in a text box. I also 
didn’t have time to investigate… :(

And still some other patches needed (e.g., Retina support).


Regards,
Bernhard

> On 30. Dec 2017, at 13:04, Jeff Young  wrote:
> 
> Some of them are already up-stream, but we would have to move to wxWidgets 
> 3.1 (when it comes out in a month or so) to get them.  The wxWidgets folks 
> won’t back-port header changes, for instance.
> 
> I don’t know how many of the existing patches are in 3.0.3, but I don’t think 
> very many (IIRC only 1 or 2 of them failed when I tried to apply them to 
> 3.0.3).
> 
> Cheers,
> Jeff.
> 
> 
>> On 30 Dec 2017, at 11:58, Carsten Schoenert  wrote:
>> 
>> Hi,
>> 
>> Am 30.12.2017 um 00:45 schrieb Nick Østergaard:
>>> We could have a fork of wx in the kicad org with a branch where we
>>> rebase the patches to. Then it is easy to fetch for others. The osx devs
>>> could maintain this. But having it in the kicad org gives more
>>> visibility and we don't need to habe them directly in the kicad source.
>> 
>> in a longterm it's never a good idea to maintain such patches as this
>> always costs time and energy, has some someone tried to upstream these
>> patches? That what I normally would do.
>> 
>> -- 
>> Regards
>> Carsten Schoenert
>> 
>> ___
>> 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
> 
> 
> ___
> 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


___
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

Re: [Kicad-developers] Patches consistency

[Bernhard Stegmaier]

To be honest, I don’t like the patches as is at all.
You never know if patches are still need if there are new versions or if they 
still do apply.

IMHO it would be a better solution if someone would maintain a fork of 
wxwidgets (e.g., on GitHub) with all the needed patches applied, so that 
someone who really wants to build just has to sync this… ?
For myself, I do this quite some time so I don’t have to apply all the patches 
every time (for wxWidgets master).


Regards,
Bernhard

> On 29. Dec 2017, at 22:07, Adam Wolf  wrote:
> 
> I think the main reason why this happens is that most of those patches
> are not created by KiCad devs, but rather taken from upstream mailing
> lists, and I have always just preserved the patch as is, but I don't
> have a strong opinion on keeping it like it is or changing it to be
> more consistent.
> 
> I don't mind how it would get changed, as long as, if it gets changed,
> it gets more consistent between the different patches and between the
> patches and the docs.
> 
> Adam Wolf
> 
> On Fri, Dec 29, 2017 at 2:37 PM, Wayne Stambaugh  wrote:
>> Any of our osx devs have an opinion on this?  It doesn't impact me so I
>> would rather the devs who have to use this make the call.
>> 
>> On 12/29/2017 03:33 PM, Anton Shevchenko wrote:
>>> Hi all,
>>> 
>>> Looking through the code style guide (i'm new here) I didn't find a word 
>>> about how a patch file should reference source code file. By patch file I 
>>> mean *.patch file located in kicad/patches folder.
>>> 
>>> Being on macOS I'm trying to apply all the patches required for building 
>>> wxWidgets and have found that there are 2 different styles in use.
>>> First style references source code files without prefix. To apply such a 
>>> patch one has to run 'patch -p0'.
>>> The other style uses a/ and b/ prefixes which is used with 'patch -p1' 
>>> option.
>>> In my opinion the last one is more common (and if you run 'git diff' you 
>>> will see a/ and b/ prefixes).
>>> 
>>> I would like to fix macOS patches stuff to be able to actually follow the 
>>> guide 
>>> (http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_osx)
>>>  in order to build KiCad for macOS.
>>> 
>>> Any comments?
>>> 
>> 
>> ___
>> 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
> 
> ___
> 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


___
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

Re: [Kicad-developers] OSX dev environments

[Bernhard Stegmaier]

For my taste for KiCad the best I tried is QTCreator.
Works practically out-of-the-box perfectly with cmake and everything you would 
expect from an IDE (like debugging, etc.).


Regards,
Bernhard

> On 25. Dec 2017, at 03:47, Oliver Walters  
> wrote:
> 
> I followed this guide to set-up eclipse environment. 
> 
> https://gist.github.com/johnbeard/895bad60e4716f7f9c77 
> 
> 
> On 25 Dec 2017 12:37, "Tomasz Wlostowski"  > wrote:
> On 25/12/17 02:03, Jeff Young wrote:
> > I was going to ask you guys for an Xcode project file for Christmas, but 
> > I’ve come to the conclusion that I absolutely hate Xcode.
> >
> > I’ve used Eclipse before, and was no big fan of it either.  I did really 
> > like IntelliJ, though, and I see they’ve got a C version too (CLion).  Has 
> > anyone used it to build KiCad?
> >
> Hi Jeff,
> 
> I tried CLion. After a ~10 minute-long freeze (indexing the code) it
> crashed due to lack of memory. With a 6 GB java heap the project loaded,
> but the editor was veeery slow.
> 
> IMHO Get Atom if you need something easy to use on a Mac or Visual
> Studio (if you like "big" C++ IDEs).
> 
> Cheers,
> Tom
> 
> ___
> 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 
> 
> ___
> 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

___
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

Re: [Kicad-developers] Modeless dialog action buttons

[Bernhard Stegmaier]

… same for the new remap dialog in eeschema.

Regards,
Bernhard

> On 23. Dec 2017, at 17:28, Andy Peters  wrote:
> 
> 
>> On Dec 23, 2017, at 9:17 AM, Jeff Young  wrote:
>> 
>> Found another one: Drill Files Generation.
> 
> In pcbnew, the netlist import dialog has a “cancel” button, which is useful 
> for when you decide you don’t want to do the import, but once the import has 
> completed, that button should change to “close.”
> 
> I’m not sure that the position of the “cancel” button in that dialog makes 
> sense; perhaps it should be at the bottom of the buttons.
> 
> -a
> 
> 
> 
>> 
>>> On 21 Dec 2017, at 14:33, Wayne Stambaugh  wrote:
>>> 
>>> They should be "Close".  I'll will try to get them fixed soon.
>>> 
>>> On 12/21/2017 8:00 AM, Jeff Young wrote:
 There are several modeless dialogs in pcbnew (for instance, Exchange 
 Footprint and Plot) which have action buttons and a “Cancel” button.
 
 These shouldn’t be called “Cancel” as they don’t cancel the action.  They 
 should be either “Done” or “Close”.
 
 Comments?
 
 (Resending to fix bogus thread link.)
 ___
> 
> ___
> 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


___
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

[Kicad-developers] [PATCH] Fi build error on macOS

[Bernhard Stegmaier]

Hi,

Attached patch fixes 2 build errors on macOS.
Just fixed the build error, no test of the plugin.


Regards,
Bernhard



0001-Fix-Eagle-plugin-build-errors-on-macOS.patch
Description: Binary data


___
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

Re: [Kicad-developers] macOS 3d-viewer improvements

[Bernhard Stegmaier]

nst wxGLAttributes& dispAttrs,
>  ^~
>  wxVisualAttributes
> common/CMakeFiles/pcbcommon.dir/build.make:180: recipe for target
> 'common/CMakeFiles/pcbcommon.dir/__/pcbnew/basepcbframe.cpp.o' failed
> make[2]: ***
> [common/CMakeFiles/pcbcommon.dir/__/pcbnew/basepcbframe.cpp.o] Error 1
> CMakeFiles/Makefile2:400: recipe for target
> 'common/CMakeFiles/pcbcommon.dir/all' failed
> make[1]: *** [common/CMakeFiles/pcbcommon.dir/all] Error 2
> Makefile:151: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> 
> On 12/11/2017 06:52 AM, Bernhard Stegmaier wrote:
>> Hi,
>> 
>> Attached patches improve 3d-viewer on macOS a bit.
>> 
>> Patches (1)+(2) add Retina support to 3d-viewer just like it was already 
>> there for GAL canvas.
>> I pulled out all the ugly #ifdef stuff into a new base class, so now all 
>> Retina related code for GAL and 3d-viewer is in one class.
>> I put it into the gal folder… if you think it shouldn’t be there, please 
>> move it to a better spot or tell me where to put it.
>> 
>> Patch (3) is only a cleanup wrt pinch-to-zoom and enables pinch-to-zoom 
>> again when using newer wxWidgets.
>> 
>> Tested only on macOS, shouldn’t have any impact on other platforms.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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
>> 
> 
> ___
> 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

___
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

[Kicad-developers] macOS 3d-viewer improvements

[Bernhard Stegmaier]

Hi,

Attached patches improve 3d-viewer on macOS a bit.

Patches (1)+(2) add Retina support to 3d-viewer just like it was already there 
for GAL canvas.
I pulled out all the ugly #ifdef stuff into a new base class, so now all Retina 
related code for GAL and 3d-viewer is in one class.
I put it into the gal folder… if you think it shouldn’t be there, please move 
it to a better spot or tell me where to put it.

Patch (3) is only a cleanup wrt pinch-to-zoom and enables pinch-to-zoom again 
when using newer wxWidgets.

Tested only on macOS, shouldn’t have any impact on other platforms.


Regards,
Bernhard



0001-Create-HIDPI_GL_CANVAS-wrapper-for-transparent-wxGLC.patch
Description: Binary data


0002-Merge-HIDPI_GL_CANVAS-wrapper-with-OPENGL_GAL-implem.patch
Description: Binary data


0003-Fix-macOS-pinch-to-zoom-for-3d-viewer.patch
Description: Binary data




___
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

Re: [Kicad-developers] macOS & New Zone Filling?

[Bernhard Stegmaier]

Hi Tom,

Sorry for the delay… no, doesn’t fix it.
Just hangs in the progress dialog at zero progress/time, no way to close it.


Regards,
Bernhard

> On 9. Dec 2017, at 20:13, Tomasz Wlostowski  wrote:
> 
> On 09/12/17 18:30, Seth Hillbrand wrote:
>> Tom-
>> 
>> I can confirm that this fixes the issue for me on MacOS 10.13
>> 
> 
> Hi Seth & Bernhard,
> 
> Could you try the attached patch?
> 
> Tom, in the process of getting a macintosh...
> <0001-WX_PROGRESS_REPORTER-possible-fix-for-freeze-on-OSX.patch>


___
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

Re: [Kicad-developers] macOS & New Zone Filling?

[Bernhard Stegmaier]

Hi Tom,

Yes, looks good.
No progress window, but it fills and doesn’t get stuck.


Bernhard

> On 9. Dec 2017, at 03:56, Tomasz Wlostowski <tomasz.wlostow...@cern.ch> wrote:
> 
> On 09/12/17 01:33, Bernhard Stegmaier wrote:
>> Some sites say that.
>> I tried to manually compile a test program from one of those, but my
>> clang doesn’t even recognise -fopenmp.
>> The other thing mentioned is clang-omp, but that seems not to be
>> maintained any longer.
>> Didn’t try further…
> 
> Hi Bernhard,
> 
> Could you try this:
> 
> in zone_filler.cpp, after lines 92-93:
> 
> void ZONE_FILLER::Fill( std::vector<ZONE_CONTAINER*> aZones )
>   {
> 
> put:
>   m_progressReporter = nullptr;
> 
> recompile and try filling zones to check if it still freezes.
> 
> Tom
> 
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 8. Dec 2017, at 16:50, Simon Wells <swel...@gmail.com
>>> <mailto:swel...@gmail.com>> wrote:
>>> 
>>> I thought it did if you can find the right lib as it was only the lib
>>> that was missing?
>>> 
>>>> On 9/12/2017, at 3:48 AM, Bernhard Stegmaier <stegma...@sw-systems.de
>>>> <mailto:stegma...@sw-systems.de>> wrote:
>>>> 
>>>> … I looked around a bit and from that it seems to be pretty sure that
>>>> stock Xcode Apple clang (which I use) doesn’t support OpenMP.
>>>> 
>>>> 
>>>> Regards,
>>>> Bernhard
>>>> 
>>>>> On 8. Dec 2017, at 14:05, Bernhard Stegmaier
>>>>> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>> wrote:
>>>>> 
>>>>> Hi Tom,
>>>>> 
>>>>>> On 8. Dec 2017, at 13:59, Tomasz Wlostowski
>>>>>> <tomasz.wlostow...@cern.ch <mailto:tomasz.wlostow...@cern.ch>> wrote:
>>>>>> 
>>>>>> Wonderful.
>>>>>> 
>>>>>> I thought a workaround for Windows OpenMP/wxWidgets support will be
>>>>>> sufficient. Time to get a macbook...
>>>>>> 
>>>>>> Bernard, could you try building kicad with OpenMP disabled?
>>>>> 
>>>>> Hmm… how do I do this?
>>>>> 
>>>>> I get from cmake
>>>>> <<<
>>>>> …
>>>>> -- Performing Test COMPILER_SUPPORTS_WSUGGEST_OVERRIDE
>>>>> -- Performing Test COMPILER_SUPPORTS_WSUGGEST_OVERRIDE - Failed
>>>>> -- Performing Test COMPILER_SUPPORTS_WSHADOW
>>>>> -- Performing Test COMPILER_SUPPORTS_WSHADOW - Success
>>>>> -- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS
>>>>> OpenMP_C_LIB_NAMES) (found version "1.0")
>>>>> -- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS
>>>>> OpenMP_CXX_LIB_NAMES) (found version "1.0")
>>>>> -- Found wxWidgets:
>>>>> -L/Volumes/OSXData/bstegmaier/KiCad/wx-master/lib;;;-framework
>>>>> IOKit;-framework Carbon;-framework Co
>>>>> …
>>>>>>>> 
>>>>> 
>>>>> So I always thought it doesn’t use OpenMP?
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Bernhard
>>>>> 
>>>>> ___
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>> <mailto:kicad-developers@lists.launchpad.net>
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>> 
>>>> ___
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to : kicad-developers@lists.launchpad.net
>>>> <mailto:kicad-developers@lists.launchpad.net>
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>> 
> 


___
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

Re: [Kicad-developers] macOS & New Zone Filling?

[Bernhard Stegmaier]

Some sites say that.
I tried to manually compile a test program from one of those, but my clang 
doesn’t even recognise -fopenmp.
The other thing mentioned is clang-omp, but that seems not to be maintained any 
longer.
Didn’t try further…


Regards,
Bernhard

> On 8. Dec 2017, at 16:50, Simon Wells <swel...@gmail.com> wrote:
> 
> I thought it did if you can find the right lib as it was only the lib that 
> was missing?
> 
>> On 9/12/2017, at 3:48 AM, Bernhard Stegmaier <stegma...@sw-systems.de 
>> <mailto:stegma...@sw-systems.de>> wrote:
>> 
>> … I looked around a bit and from that it seems to be pretty sure that stock 
>> Xcode Apple clang (which I use) doesn’t support OpenMP.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 8. Dec 2017, at 14:05, Bernhard Stegmaier <stegma...@sw-systems.de 
>>> <mailto:stegma...@sw-systems.de>> wrote:
>>> 
>>> Hi Tom,
>>> 
>>>> On 8. Dec 2017, at 13:59, Tomasz Wlostowski <tomasz.wlostow...@cern.ch 
>>>> <mailto:tomasz.wlostow...@cern.ch>> wrote:
>>>> 
>>>> Wonderful.
>>>> 
>>>> I thought a workaround for Windows OpenMP/wxWidgets support will be
>>>> sufficient. Time to get a macbook...
>>>> 
>>>> Bernard, could you try building kicad with OpenMP disabled?
>>> 
>>> Hmm… how do I do this?
>>> 
>>> I get from cmake
>>> <<<
>>> …
>>> -- Performing Test COMPILER_SUPPORTS_WSUGGEST_OVERRIDE
>>> -- Performing Test COMPILER_SUPPORTS_WSUGGEST_OVERRIDE - Failed
>>> -- Performing Test COMPILER_SUPPORTS_WSHADOW
>>> -- Performing Test COMPILER_SUPPORTS_WSHADOW - Success
>>> -- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) 
>>> (found version "1.0")
>>> -- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS 
>>> OpenMP_CXX_LIB_NAMES) (found version "1.0")
>>> -- Found wxWidgets: 
>>> -L/Volumes/OSXData/bstegmaier/KiCad/wx-master/lib;;;-framework 
>>> IOKit;-framework Carbon;-framework Co
>>> …
>>> >>>
>>> 
>>> So I always thought it doesn’t use OpenMP?
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> Post to : kicad-developers@lists.launchpad.net 
>>> <mailto:kicad-developers@lists.launchpad.net>
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp>
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
> 

___
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

Re: [Kicad-developers] macOS & New Zone Filling?

[Bernhard Stegmaier]

… I looked around a bit and from that it seems to be pretty sure that stock 
Xcode Apple clang (which I use) doesn’t support OpenMP.


Regards,
Bernhard

> On 8. Dec 2017, at 14:05, Bernhard Stegmaier <stegma...@sw-systems.de> wrote:
> 
> Hi Tom,
> 
>> On 8. Dec 2017, at 13:59, Tomasz Wlostowski <tomasz.wlostow...@cern.ch 
>> <mailto:tomasz.wlostow...@cern.ch>> wrote:
>> 
>> Wonderful.
>> 
>> I thought a workaround for Windows OpenMP/wxWidgets support will be
>> sufficient. Time to get a macbook...
>> 
>> Bernard, could you try building kicad with OpenMP disabled?
> 
> Hmm… how do I do this?
> 
> I get from cmake
> <<<
> …
> -- Performing Test COMPILER_SUPPORTS_WSUGGEST_OVERRIDE
> -- Performing Test COMPILER_SUPPORTS_WSUGGEST_OVERRIDE - Failed
> -- Performing Test COMPILER_SUPPORTS_WSHADOW
> -- Performing Test COMPILER_SUPPORTS_WSHADOW - Success
> -- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) 
> (found version "1.0")
> -- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES) 
> (found version "1.0")
> -- Found wxWidgets: 
> -L/Volumes/OSXData/bstegmaier/KiCad/wx-master/lib;;;-framework 
> IOKit;-framework Carbon;-framework Co
> …
> >>>
> 
> So I always thought it doesn’t use OpenMP?
> 
> 
> Regards,
> Bernhard
> 
> ___
> 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

___
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

Re: [Kicad-developers] macOS & New Zone Filling?

[Bernhard Stegmaier]

Hi Tom,

> On 8. Dec 2017, at 13:59, Tomasz Wlostowski  wrote:
> 
> Wonderful.
> 
> I thought a workaround for Windows OpenMP/wxWidgets support will be
> sufficient. Time to get a macbook...
> 
> Bernard, could you try building kicad with OpenMP disabled?

Hmm… how do I do this?

I get from cmake
<<<
…
-- Performing Test COMPILER_SUPPORTS_WSUGGEST_OVERRIDE
-- Performing Test COMPILER_SUPPORTS_WSUGGEST_OVERRIDE - Failed
-- Performing Test COMPILER_SUPPORTS_WSHADOW
-- Performing Test COMPILER_SUPPORTS_WSHADOW - Success
-- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) (found 
version "1.0")
-- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES) 
(found version "1.0")
-- Found wxWidgets: 
-L/Volumes/OSXData/bstegmaier/KiCad/wx-master/lib;;;-framework IOKit;-framework 
Carbon;-framework Co
…
>>>

So I always thought it doesn’t use OpenMP?


Regards,
Bernhard

___
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

[Kicad-developers] macOS & New Zone Filling?

[Bernhard Stegmaier]

Hi,

anybody tried a current version with the new zone filling on macOS?

The version I compiled just an hour ago only shows this dialog:


Then, it just hangs… Cancel doesn’t work (it is grey in the screenshot because 
I already pressed it), can’t close the dialog or do anything else.
Looking close at the PCB seems that it didn’t do anything (or, just no update).


Regards,
Bernhard




___
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

Re: [Kicad-developers] Simulator towards 5.0

[Bernhard Stegmaier]

… I wouldn’t bet that some program/package with various compile options has the 
same set of features activated on Debian, Arch, whatever other Linux 
distribution…
At least, that’s my experience with some packages I used.


Regards,
Bernhard

> On 7. Dec 2017, at 17:59, kristoffer Ödmark  
> wrote:
> 
> I still think this is strange reasoning, so the version 5 will be built 
> differently on every system? I thought v5 should include the spice simulator?
> 
> Are you saying there is no recommended way to deliver kicad? So when I send a 
> file to my friend on windows, he might not be able to do the same things as I 
> can on ubuntu, or on arch or whatever?
> 
> I understand that there are optional dependencies, but basically having the 
> option to turn them off still seems better than having the option to turn 
> them on. At least when turning them off I will understand why they are not in 
> kicad. And a new developer might find this easier as well.
> 
> Can we at least have an update to the build docs that reflects what is deemed 
> non-experimental or a line stating that everything should be turned on?
> 
> - Kristoffer
> 
> On 2017-12-07 16:53, Wayne Stambaugh wrote:
>> I hope users are no longer building kicad from source.  We tried that
>> already and it was a disaster.  The build options should reflect the
>> dependencies available on the platform it's being built on.  Whether or
>> not an optional feature is ready for release is not relevant.  For
>> example if ngspice was not built with the --with-libngspice option
>> (which apparently on arch linux it is not), setting KICAD_SPICE=ON will
>> fail during build config.  It is up to the system package developer to
>> determine if kicad should be built with spice support.
>> 
>> On 12/6/2017 9:04 AM, Kristoffer Ödmark wrote:
>>> Are we not in feature freeze, the features that I enabled by default is
>>> from my understanding the ones that will be built into the official
>>> ones. And yes, the people that are compiling a non-standard install
>>> shuld be savvy enough to be change the compilation settings. That is why
>>> i think the default build should reflect the ones being run by the less
>>> savvy users.
>>> 
>>>  -Kristoffer
>>> 
>>> On 12/06/2017 11:31 AM, Simon Richter wrote:
 Hi,
 
 On 06.12.2017 11:12, Kristoffer Ödmark wrote:
 
> I do not see why anyone is even objecting to this? Where is the logic at
> having a default build that does not correspond to any of the official
> packages?!
 That usually happens because the nightly builds enable all the
 experimental features to allow people to test them, but the default is
 still "disabled" because they introduce extra dependencies and make life
 difficult for people compiling from source.
 
 The default for new options needs to be decided before the release, I
 think, and "release" packages should go with that.
 
 Simon
 
 
 
 ___
 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
 
>>> ___
>>> 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
>> ___
>> 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
> 
> 
> ___
> 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


___
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

Re: [Kicad-developers] Symbol library table remapping question

[Bernhard Stegmaier]

> On 7. Dec 2017, at 00:27, Wayne Stambaugh  wrote:
>>> 
>> 
>> Well, technically this is the same library.
>> It is only reachable by 2 different paths (the real and the symlinked one).
> 
> I could check for symlinks.  I'm not sure how much trouble it would be.
> I'll take a look at it as soon as I get a chance.

I never tried, but maybe using realpath(…) on both sides of the comparison 
could just do the trick.
And maybe eliminates also other weird path constructs…?


Regards,
Bernhard


___
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