Re: [Kicad-developers] New lead developers

Congratulations fellow developers! You have received well deserved promotions, and I am glad to see your names in the kicad-product-committers group. Keep on rocking! Cheers, Orson On 03/01/2018 08:15 PM, Wayne Stambaugh wrote: > I am pleased to announce the promotion of three developers to the

Re: [Kicad-developers] Mac HighDPI performance

Thanks, I didn't know that, Open in Low Resolution definitely speeds up eeschema, I know kicad has this info on the website, however that fact that you have to go inside the package and set that to low res mode as far as I remember was not stated! The docs should be updated to properly show how

Re: [Kicad-developers] Mac HighDPI performance

Usually, Eeschema, Pcbnew, etc are links into the KiCad package. If you right-click and go to "Show Original", you will get the actual application. Get Info there will allow you to select "Open in Low Resolution" for that application. -S 2018-03-02 4:00 GMT+00:00 Andrey Kuznetsov

Re: [Kicad-developers] Mac HighDPI performance

Only KiCad app has Open in Low Resolution Mode, and I already had it enabled! On Thu, Mar 1, 2018 at 7: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

Re: [Kicad-developers] MacOS + OpenMP

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

Re: [Kicad-developers] Fabrication Outputs and Plot

Gentle reminder. Thanks, Diego On Tue, Feb 27, 2018 at 12:16 AM, Wayne Stambaugh wrote: > This looks fine to me. Does anyone else have any objections to this > change? > > On 02/25/2018 03:17 PM, Diego Herranz wrote: > >> Thanks for your replies. I think there's a

[Kicad-developers] [PATCH] Restore some missing visibility items from board file

I'm resending a patch from this thread: https://lists.launchpad.net/kicad-developers/msg34285.html I believe it should go into rc2? State of some recently added checkboxes to Render panel was not restored on file open. This patch fixes that. Andrzej >From

[Kicad-developers] New lead developers

I am pleased to announce the promotion of three developers to the KiCad lead development team. Their efforts since joining the project have really helped move KiCad forward. They have shown excellent technical skills and a willingness to cooperate with the development team. Please congratulate

Re: [Kicad-developers] '/' hotkey

On 3/1/2018 10:56 AM, jp charras wrote: > Le 01/03/2018 à 15:47, Wayne Stambaugh a écrit : >> On 3/1/2018 9:28 AM, Jon Evans wrote: >>> Here's a blog post from the developers of Atom editor talking about >>> solving this problem: >>>

Re: [Kicad-developers] MacOS + OpenMP

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

Re: [Kicad-developers] MacOS + OpenMP

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 shows expected result of 4

Re: [Kicad-developers] Alternative presentation of Symbol properties

Technically yes, but even the existing dialog only lets you edit both. > On 1 Mar 2018, at 16:23, Andy Peters wrote: > > > >> On Mar 1, 2018, at 5:29 AM, Jeff Young wrote: >> >> What do you guys think of this for displaying / editing symbol fields: >> >> >

Re: [Kicad-developers] Alternative presentation of Symbol properties

> On Mar 1, 2018, at 5:29 AM, Jeff Young wrote: > > What do you guys think of this for displaying / editing symbol fields: > > Don’t the text items have thickness and width attributes, not just one “size?” -a ___ Mailing list:

Re: [Kicad-developers] '/' hotkey

Le 01/03/2018 à 15:47, Wayne Stambaugh a écrit : > On 3/1/2018 9:28 AM, Jon Evans wrote: >> Here's a blog post from the developers of Atom editor talking about >> solving this problem: >> https://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboards.html > > I always new keyboard issues were

Re: [Kicad-developers] Alternative presentation of Symbol properties

Hey Jeff, I'll try to check it out this weekend if I can find the time. Cheers, Wayne On 3/1/2018 8:44 AM, Jeff Young wrote: > Hi Wayne, > > The table editor is already done. That wasn’t controversial (since it was > already a table-style presentation). You can play with that on my branch:

Re: [Kicad-developers] MacOS + OpenMP

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

Re: [Kicad-developers] MacOS + OpenMP

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 wrote: > > For now it would probably be fine to just restore the

Re: [Kicad-developers] '/' hotkey

You can get the untranslated key code using EVT_CHAR by calling GetRawKeyCode() and GetRawKeyFlags(). On 3/1/2018 9:52 AM, Jon Evans wrote: > sorry, meant KEY_DOWN / KEY_UP, got them mixed up.  Translated vs. > untranslated. > > On Thu, Mar 1, 2018 at 9:47 AM, Wayne Stambaugh

Re: [Kicad-developers] MacOS + OpenMP

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

Re: [Kicad-developers] MacOS + OpenMP

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

Re: [Kicad-developers] '/' hotkey

sorry, meant KEY_DOWN / KEY_UP, got them mixed up. Translated vs. untranslated. On Thu, Mar 1, 2018 at 9:47 AM, Wayne Stambaugh wrote: > On 3/1/2018 9:28 AM, Jon Evans wrote: > > Here's a blog post from the developers of Atom editor talking about > > solving this problem:

Re: [Kicad-developers] '/' hotkey

On 3/1/2018 9:28 AM, Jon Evans wrote: > Here's a blog post from the developers of Atom editor talking about > solving this problem: > https://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboards.html I always new keyboard issues were bad but I didn't think they were this bad. Someone needs

Re: [Kicad-developers] MacOS + OpenMP

The purpose is it works on Mac. But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part. Patch coming. Cheers, Jeff. > On 1 Mar 2018, at 14:09, Tomasz Wlostowski wrote: > > On 01/03/18 15:01, Jon Evans wrote: >> I missed that change to STL, oops!

Re: [Kicad-developers] MacOS + OpenMP

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

Re: [Kicad-developers] MacOS + OpenMP

On 01/03/18 15:26, Bernhard Stegmaier wrote: > 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

Re: [Kicad-developers] '/' hotkey

Here's a blog post from the developers of Atom editor talking about solving this problem: https://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboards.html I have not studied this at all yet but perhaps it is relevant (i.e. maybe we should be looking at EVT_CHAR too?) On Thu, Mar 1, 2018 at

Re: [Kicad-developers] MacOS + OpenMP

> 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: <<<

Re: [Kicad-developers] '/' hotkey

On 2/28/2018 3:46 PM, Wayne Stambaugh wrote: > On 2/28/2018 2:31 PM, jp charras wrote: >> Le 28/02/2018 à 17:45, Wayne Stambaugh a écrit : >>> In the process of attempting to fix this bug[1], I ran into an issue >>> with the '/' hotkey for all main frames. For some reason, the hotkey >>> help

Re: [Kicad-developers] MacOS + OpenMP

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)

Re: [Kicad-developers] MacOS + OpenMP

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. 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

Re: [Kicad-developers] MacOS + OpenMP

Once we figure out what is involved and any risks, we can make a decision at that point. I'm working under the assumption that this only applies to the raytracing. Wayne On 3/1/2018 8:41 AM, Bernhard Stegmaier wrote: > Currently, I fully agree with you. > > The only spot right now where it has

Re: [Kicad-developers] MacOS + OpenMP

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

Re: [Kicad-developers] MacOS + OpenMP

This seems like it is not critical for the upcoming V5 release, but that a strategy should be determined before we get too far into V6, right? Adam On Thu, Mar 1, 2018 at 7:41 AM, Bernhard Stegmaier wrote: > Currently, I fully agree with you. > > The only spot right now

Re: [Kicad-developers] MacOS + OpenMP

The zone filler was moved to STL. > On 1 Mar 2018, at 13: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

Re: [Kicad-developers] MacOS + OpenMP

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.

Re: [Kicad-developers] MacOS + OpenMP

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

Re: [Kicad-developers] MacOS + OpenMP

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 wrote: >

Re: [Kicad-developers] MacOS + OpenMP

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

Re: [Kicad-developers] MacOS + OpenMP

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

Re: [Kicad-developers] Alternative presentation of Symbol properties

Maybe I'm not seeing this correctly but your editor is only showing the fields for a single symbol. I thought you were replacing the current table editor where you could group symbols and edit field values for group of symbols rather than each symbol individually. I would like to see what you

Re: [Kicad-developers] Alternative presentation of Symbol properties

Hi Simon, I do. (Pin Table and Fields Editor too.) My guess is you tried to use a wxDataViewCtrl, which is a mess. These are based on the wxGrid. You can try out the pin table and fields editor (the spreadsheet icon at the top of a schematic window) at:

Re: [Kicad-developers] Alternative presentation of Symbol properties

Hi, On 01.03.2018 13:29, Jeff Young wrote: > What do you guys think of this for displaying / editing symbol fields: Do you have actual working code for that? I've tried getting this to work for editing pin type in the pin table, but got nowhere as widgets wouldn't be rendered and focus was all

[Kicad-developers] Alternative presentation of Symbol properties

What do you guys think of this for displaying / editing symbol fields: On the plus side it’s much more direct to edit stuff (without having to select the field first to get its properties set in the controls). On the minus side it is perhaps a bit more industrial

Re: [Kicad-developers] MacOS + OpenMP

Is there a complicated board design online I could download and test for comparison between macOS and windows? Someone people have used before for kicad verification for example. On Wed, Feb 28, 2018 at 11:40 PM, Bernhard Stegmaier < stegma...@sw-systems.de> wrote: > I had a quick look where