So when I did it before, I could sign kicad.app just fine, but none of
the subapps would be signed, and then when you manually dequarantined
them by right clicking open, there would be a conflict in kicad.app
because all files were signed but some were dequarantined and some
weren't. I suspect
When I tested this, notarization didn't exist, and I think it's a subset of
what we need for signing. We may be able to notarize now, actually!
Adam
On Tue, Aug 13, 2019, 5:21 PM Bernhard Stegmaier
wrote:
> Yes, I did… and I still don’t really like this multi-application approach.
> To be
Right now the addition of the Close item for the non-main windows is
scattered in the menu creation functions. This means it is easy to leave
out the accelerator key entry when adding a new one (yes, I forgot that in
cvpcb...). This patch will push the creation of the menu item into a common
The switch statement for choosing which frame to launch in Pcbnew had an
extra nested switch inside of it. It appears that the original performance
enhancement reason for doing that has been modified, so now there was no
benefit to having the nested switches. This patch removes the nesting.
-Ian
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
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
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
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
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
Jeff,
This change would not affect the handling of the menu action events, it
would simply be in charge of updating the UI of the menus/taskbars to
reflect the current state of the tools. I think the biggest advantage for
doing it this way is to unify the method by which the state of all
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
Hi JP-
This looks like a good addition. I'm happy to see it being developed.
A few notes:
- "dielectric_constrains" maybe could be "dielectric_constraints"
- It would be nice to see this replace the "Layers" panel in Board
setup. We also set pcb thickness there as well as have our add/remove
> 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
Thanks Adam! I just pushed the website updates so 5.1.4 is officially
released. Thank you again everyone.
Cheers,
Wayne
On 8/13/19 1:57 PM, Adam Wolf wrote:
> macOS is ready!
>
> Adam
>
> On Mon, Aug 12, 2019 at 10:43 PM Adam Wolf
> wrote:
>>
>> Hi folks!
>>
>> 5.1.4 is up for macOS. It's
On 2019-08-13 10:50, Wayne Stambaugh wrote:
On 8/13/19 2:13 AM, jp charras wrote:
Le 12/08/2019 à 21:54, Wayne Stambaugh a écrit :
Sounds like a plan. If there are not bug reports against this over
the
next month, I'll will cherry-pick it into 5.1.
Wayne
I am not sure this issue exists in
macOS is ready!
Adam
On Mon, Aug 12, 2019 at 10:43 PM Adam Wolf
wrote:
>
> Hi folks!
>
> 5.1.4 is up for macOS. It's in two versions, like last time. 10.12
> and 10.13 use
> https://kicad-downloads.s3.cern.ch/osx/stable/kicad-unified-5.1.4-0.dmg,
> and 10.14 uses
>
Indeed,
there is actually a plan to improve this in the future. Personally, I
even wrote down a very rough idea myself:
https://github.com/pointhi/kicad-python/wiki/swig-interface-idea
I was able to compile eeschema with swig binding
JP,
I took a look at your patch and I have a few comments.
Shouldn't the stack up dialog just be another panel the the board setup
dialog? I would think this information is part of the board setup but I
could be wrong.
If the stack up information is part of the board setup then it should be
in
Hi,
On Tue, Aug 13, 2019 at 05:43:02PM +0200, Ian McInerney wrote:
> Smart pointers would definitely have been nicer to use, but the issue we
> have with the board objects is they are passed out through SWIG to Python
> currently, and SWIG doesn't seem to support unique_ptr, so I am not sure
>
Smart pointers would definitely have been nicer to use, but the issue we
have with the board objects is they are passed out through SWIG to Python
currently, and SWIG doesn't seem to support unique_ptr, so I am not sure
how it would react if we gave it a deque of unique_ptrs. Anyone know if
that
Hi,
On Tue, Aug 13, 2019 at 10:50:10AM -0400, Wayne Stambaugh wrote:
> Maybe we should have used boost::ptr_deque instead. You get heap
> allocation cleanup for free.
Or a deque of smart pointers. Without range-based for, that was annoying to
use because you needed the double dereference
On 8/13/19 2:13 AM, jp charras wrote:
> Le 12/08/2019 à 21:54, Wayne Stambaugh a écrit :
>> Sounds like a plan. If there are not bug reports against this over the
>> next month, I'll will cherry-pick it into 5.1.
>>
>> Wayne
>
> I am not sure this issue exists in 5.1.
>
> AFAIK it comes from
Hi Johannes,
The the new file format work is in progress and should be done in a few
months. The UI support for moving pin name and number text will happen
some time after that. I cannot say when for sure as the new file
formats add a lot of new features which will require a significant
amount
Le 12/08/2019 à 21:54, Wayne Stambaugh a écrit :
> Sounds like a plan. If there are not bug reports against this over the
> next month, I'll will cherry-pick it into 5.1.
>
> Wayne
I am not sure this issue exists in 5.1.
AFAIK it comes from moving code from our DLIST to std::deque, only in
24 matches
Mail list logo
