Jerry;
Thanks for updating that info. Your info has helped a lot in my own
notarization efforts.
The Notarization system consists of two parts - the front end that our scripts
communicate with to request takes and get info, and a back-end that actually
does the notarization work. When we get
I would add that for those of us developing for the Mac platform, the security
sessions have been critical for the last two years. Without a good
understanding of the issues discussed in those sessions, I don’t see how a
developer's application could run properly on Catalina.
I see the WWDC
It seems like it would be easier to find the Build directory’s releases folder
and the find the built product somewhere inside. It’s relation to the Build
directory won’t change from build to build. Once you find that, just Notarize
it in place. You need to make sure that it is already
final product.
Once you get the hang of Notarization, you will find it isn’t difficult.
Getting there is, however.
Jack
> On Apr 25, 2020, at 6:23 PM, Jack Brindle via Cocoa-dev
> wrote:
>
> It seems like it would be easier to find the Build directory’s releases
> fold
Gabriel;
It appears you are trying to get NSUserDefaults to do something that Apple
doesn’t want it to do these days. Why not create your own defaults,
writing the data to a dictionary that is then written to a file that you save
in the ~/Library/Preferences folder, with a name of your choice?
e depreciated initWithUser: and added initWithSuiteName: around this same
> timeframe.
>
>
>> On Apr 4, 2021, at 12:15 AM, Jack Brindle via Cocoa-dev
>> wrote:
>>
>> Gabriel;
>>
>> It appears you are trying to get NSUserDefaults to do something
I agree with you, to an extent. NSUserDefaults is very good when used as a
single-level repository for settings data. When you want to categorize the
settings by using collections, it starts to show the same problems that a
regular file has, except slightly worse. Collections are saved as an
/Applications is owned by root, and has rwx privileges only for the system, and
rx for group (admin) and all. This means you will need to have your installer
(with root privileges) to create your company/application directory inside.
As an alternative, you can certainly place your directory in
Apple made a change in Catalina to add a system preference to Show Scroll Bars:
“Automatically based on mouse or trackpad”. This is now the default. I believe
you are wanting an alternate choice - “When scrolling”.
Note that the user makes the selection as they wish, so trying to force them to
From the code sign man page:
codesign --display --verbose=4 Terminal.app
replace Terminal.app with your application name (be sure to unzip first). The
information shown will tell you whether it is has a valid signature.
You might try it on a few other apps just to see what that looks like.
Be
What is the mouse, and is there any installed software involved that goes with
the mouse?
Jack
> On Apr 12, 2021, at 12:30 AM, IOS NACSPORT via Cocoa-dev
> wrote:
>
> Hi,
>
> I don't kown is the correct place, In a NSScroller, when I conect the
> external mouse, not apple's mouse, the
Quick followup:
Howard’s app: ArchiChect will do the job you need. The product page is at:
https://eclecticlight.co/32-bitcheck-archichect/
And it is free!
Jack
> On Apr 12, 2021, at 3:40 PM, Jack Brindle via Cocoa-dev
> wrote:
>
> From the code sign man page:
> cod
In 10.13 this is not a Notarization problem. It could be a quarantine problem,
though. Have him move the application to any directory other than the one where
he unzipped the app, then launch the app. That should remove the quarantine and
allow him to run the app if that was the problem. The
In Monterey, /tmp is now only writeable by root. It is quite possible that
Xcode couldn’t write there for the indexing.
When you changed to a new account, it probably changed where the derived data
went.
It used to be that /tmp was writeable by anyone. That change bit me recently as
well.
Instead of using NSOperationQueue, I would use GCD to handle the tasks. Create
a new Concurrent queue (dispatch_queue_create(DISPATCH_QUEUE_CONCURRENT)), then
enqueue the individual items to the queue for processing (dispatch_async(),
using the queue created above). Everything can be handled in
The NSScreen screen property is nullable. From the docs for NSWindow screen:
"The value of this property is the screen where most of the window is on; it is
nil when the window is offscreen."
I would go with Steve’s suggestion as much as possible, The NSScreen class has
the info you need.
I would agree with the use of Distributed Notifications, but there is a new
limitation that was added a few years ago. The receiver must be in the same
login. You can no longer use it to send notifications from one user app to a
different user’s app. This came to light for me when I was trying
17 matches
Mail list logo
