> On Apr 4, 2022, at 8:58 AM, Michal L. Wright via Cocoa-dev
> wrote:
>
> Hi,
>
> I have a rather large Objective C project that I'm building in Xcode 13.3,
> running under macOS 12.3.
> (98 .m files with matching .h files, and a dozen or so .h files containing
> defines, with the release
> On Jun 23, 2021, at 12:49 PM, James Walker via Cocoa-dev
> wrote:
>
> Notarize your beta builds, just like you should be doing with your release
> builds.
Yes, that is what I do now. However when upgrading to Xcode 12 it wants to
change the debug and release configuration to use
How do you distribute software (not on app store) to Mac beta testers and not
be presented with a malicious software warning?
When upgrading a project to Xcode 12.5 it wants to change the debug and release
configuration to use development signing.
However when a beta tester downloads and opens
> On Apr 4, 2021, at 12:15 AM, Jack Brindle via Cocoa-dev
> wrote:
>
> This does work in Big Sur, we use it ourselves. The down side is that you
> don’t have the nice (and infuriating) caching of defaults that the system
> provides.
Why does Apple cache the defaults, what are the positive
> On Apr 4, 2021, at 4:50 AM, Mike Abdullah wrote:
>
>> From the docs - init returns an initialized NSUserDefaults object whose
>> argument and registration domains are already set up. This method does not
>> put anything in the search list. Invoke it only if you’ve allocated your own
>>
> On Apr 3, 2021, at 9:56 AM, Gabriel Zachmann wrote:
>
> Sorry for asking: the shared instance is the one that is persistent, right?
Looks like an instance created from alloc init would not be useful in your
situation. It appears you would be in charge of persistence.
NSUserDefault ,
> On Apr 3, 2021, at 8:59 AM, Gabriel Zachmann wrote:
>
> Thanks a lot for your response!
>
>> How about something like this?
>>
>>NSUserDefaults *monitor1 = [[NSUserDefaults alloc] init];
>>[monitor1 setBool:YES forKey:@"MyKey”];
>>
>>BOOL value = [monitor1 boolForKey:@"MyKey"];
> On Apr 3, 2021, at 5:40 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> But what I would like to have is a mechanism that lets me manage different
> user defaults when the app is running on different monitors.
> Something like
>
> [ [NSUserDefaults userDefaultsWithName:@"monitor-name"]
So why not just do this.
[myView translatesAutoresizingMaskIntoConstraints:NO];
[myView setAutoresizingMask:myMask];
--Richard Charles
> On Oct 17, 2020, at 2:47 PM, Andreas Falkenhahn
> wrote:
>
> No, they are inserted programmatically.
>
>> On 17.10.2020 at 18:41 Richard Charles wrote:
Just curious if these three subviews are in a nib or xib file or are they
inserted into the content view programmatically?
--Richard Charles
> On Oct 17, 2020, at 9:46 AM, Andreas Falkenhahn
> wrote:
>
> Thanks, out of curiosity I've tried to override the "layout" method and see
> if it
You could call this method on your three views.
-[NSViewView setAutoresizingMask:]
--Richard Charles
> On Oct 17, 2020, at 6:57 AM, Andreas Falkenhahn via Cocoa-dev
> wrote:
>
> Hi,
>
> I have an NSView that I set as the content view of my NSWindow. The NSView
> has three subviews. Where
> On Jun 30, 2020, at 4:32 AM, Michael Kloske via Cocoa-dev wrote:
>
> Hello,
>
> in my application I have several NSTokenField - objects that are used to drag
> them into a text field to build up a string by some tokens.
> However, since Catalina dragging of those NSTokenField - objects does
> On Jun 24, 2020, at 10:57 AM, Gabriel Zachmann via Cocoa-dev wrote:
>
>>
>> Set a symbolic breakpoint on NSBeep and see whether it’s your code that’s
>> calling it.
>>
>
> Thanks, but how would I do that?
> I never use NSBeep in my code ..
>
> Best regards, Gabriel
Symbolic Breakpoints
> On May 25, 2020, at 6:39 AM, Gabriel Zachmann via Cocoa-dev wrote:
>
> Here is a screensaver (actually, screensaver builder) that can capture mouse
> events:
>
> https://iscreensaver.com
>
> Does anyone have an idea how they might be able to do it?
>
> Best regards, Gabriel
Looks like
> On May 24, 2020, at 2:47 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> I am confused: does Xcode really build the debug version when I make an
> Archive?
There are two build configurations Debug and Release. The default build
configuration is Debug when building and running.
Xcode
Thanks to everyone for your comments and suggestions.
I now have my app with embedded frameworks working as multiple individual
projects or combined into a single workspace. It all works in Xcode 9 or 11 and
archiving also works. The app was successfully notarized by Apple.
There is actually
> On May 7, 2020, at 10:04 PM, Rob Petrovec wrote:
>
> Have you considered using a workspace to handle building all of your
> individual projects? That should solve your file path & linking problem.
>
Some of the dynamically linked libraries are large. If they are put in a
workspace with
I have a project that has several large dynamically linked libraries which are
located in the application bundle. Each linked library is a separate project.
The setting in Xcode > Preferences > Locations > Advanced > Build Location is
set to use Shared Folder > Build. Historically has worked
> On May 1, 2020, at 12:34 PM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> Is there a way to switch programmatically to fullscreen (and back) by the app,
> and still get the same behavior as if the user clicked the green window
> button?
Something like this should work.
NSButton *button =
I do not know Java at all but my guess is that when createImageRep is called
the second time the new graphics context does not replace the static one saved
during the first execution.
--Richard Charles
> On Mar 9, 2020, at 3:59 AM, Sravan Kumar Lakkimsetti
> wrote:
>
> If some one wants to
I have a very similar setup. I tried the following.
NSBundle *bundle = [NSBundle mainBundle];
NSData *data = [NSData dataWithContentsOfFile:[bundle
pathForResource:@"AAScreenShot" ofType:@"jpg"]];
NSBitmapImageRep *imageRep = [NSBitmapImageRep imageRepWithData:data];
NSGraphicsContext *context =
> On Feb 22, 2020, at 7:34 PM, Quincey Morris via Cocoa-dev
> wrote:
>
> The way things are now, starting from the selected Displays pane point size,
> whatever that happens to be, the backing store is 2x or 3x — an integral
> scale *up* — and the result is scaled — typically *down* by a
> On Feb 22, 2020, at 8:02 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
>>
>> No, the default on recent Macs is scaled to slightly under 2x.
>>
>
> It is about ~ 1.7 .
>
> this means that every view has to be scaled by this odd factor, before
> writing its contents into the frame
> On Dec 10, 2019, at 10:55 AM, Turtle Creek Software via Cocoa-dev
> wrote:
>
> Thoughts?
>
What if Apple were to open source Foundation, Core Data, etc., most every thing
but the UI so that developers could more easily generate cross platform apps.
Recently visited this Microsoft web
> On Nov 20, 2019, at 3:16 PM, Jean-Daniel wrote:
>
> If Obj-C is dead, why is Apple still adding new language extensions (and not
> minor one) ?
>
> https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
>
This commit on GitHub was made on Nov 18, 2019 by
> On Nov 13, 2019, at 11:58 AM, Richard Charles wrote:
>
> Apple released iTunes for Windows in October 2003.
>
Apple just posted a job opening for a Senior Software Engineer- Windows Media
Apps. It would be interesting to know how they plan on porting the new macOS
media apps to Windows
> On Nov 19, 2019, at 6:24 PM, Pier Bover via Cocoa-dev
> wrote:
>
>> When/if Apple decides to deprecate Cocoa they will announce it many years
>> ahead of time
>>
>
> Like they did with 32 bits and OpenGL deprecation?
>
The 32 bit depreciation has had a lot of discussion on this
> On Nov 19, 2019, at 9:41 AM, Turtle Creek Software via Cocoa-dev
> wrote:
>
> I have been poking around on developer.apple.com, trying to get the big
> picture on the future of Cocoa for Mac. Ditto for the future of big apps.
>
Send an email to Aaron Hillegass. He might be able to give
> On Nov 13, 2019, at 8:47 AM, Glenn L. Austin via Cocoa-dev
> wrote:
>
> Having worked on an Apple cross-platform application that used the same APIs
> that iTunes use...
> ...was a nightmare.
>
> You'd think that it would be easy, but there are so many assumptions about
> *how* the
> On Nov 12, 2019, at 2:14 PM, Jean-Daniel via Cocoa-dev
> wrote:
>
> What would be the benefit for Apple to support public API for Windows ?
>
More applications available for the Mac.
Reduce the number of app developers abandoning the Mac platform.
Reduce the number of inferior electron
> On Nov 12, 2019, at 1:16 PM, GNDGN wrote:
>
> ‘It’s like giving a glass of ice water to somebody in hell’ - Jobs
>
Apple released iTunes for Windows in October 2003. Apparently Cocoa and any
supporting frameworks were ported to Windows 16 years ago. So what is the
problem providing this
> On Nov 11, 2019, at 6:05 PM, Turtle Creek Software via Cocoa-dev
> wrote:
>
> Unfortunately, software for any vertical or specialty market has to deal with
> Mac market share.
>
I just downloaded iTunes 12.10.2.3 (64 bit) for Windows 10 Pro. It runs great,
looks great, no crashes. An
> On Oct 24, 2019, at 1:29 PM, Jens Alfke wrote:
>
> Have you tried the app Dash*? It's a general-purpose documentation browser,
> and it will automatically index and search installed Apple docsets, much
> better than Xcode does. I can't live without it.
I did not know about Dash. Much
> On Oct 24, 2019, at 7:04 AM, Turtle Creek Software via Cocoa-dev
> wrote:
> Is there a way to fix this stuff?
> For the rest, Apple really needs to listen to developers more.
Some random thoughts.
Before September 2014 the developer documentation was excellent. Excellent
online
> On Oct 20, 2019, at 8:27 AM, Aandi Inston wrote:
>
> We have a workaround, which is to move our right click processing onto
> MouseUp, which is passed up the responder chain as we wish in both 32 and 64
> bit systems. But I remain curious as to what the docs are actually telling me.
From
Your email client line breaking makes for very difficult reading so I
reformatted. See below.
Why are you compiling a plugin for 32 bits?
Just tested a 64 bit app linked to 10.8 and an unhandled rightMouseDown is
passed promptly from view to window. Testing in 32 bits would be a lot of work.
> On Oct 15, 2019, at 11:27 AM, Turtle Creek Software via Cocoa-dev
> wrote:
>
> The basic language problem as I see it is in the headers. Classes are
> either Obj-C or C++ and can't be both. It turned out to be an enormous
> barrier that caused all sorts of pains.
>From older
> On Oct 15, 2019, at 7:57 AM, Turtle Creek Software via Cocoa-dev
> wrote:
>
> TurtleSoft has a big investment in C++ source code that's full of
> construction business logic. Unfortunately, with the death of Carbon its
> future value is in doubt.
I have found your comments enlightening.
> On Oct 11, 2019, at 9:09 PM, Kirk Kerekes via Cocoa-dev
> wrote:
>
> It is my inference that Swift arose out of a perceived need for a language
> that strongly inhibited bad/lazy/sloppy programming practices, and yet looked
> “normal”.
Here is my take. I think Swift came from the mind of
> On Oct 11, 2019, at 7:07 PM, 조성빈 wrote:
>
>> 2019. 10. 12. 오전 9:55, Richard Charles via Cocoa-dev
>> 작성:
>>
>> None but the biggest of companies can do this.
>
> That’s not true, web apps aren’t really complex if you get to use the npm
> ecosystem. T
> On Oct 11, 2019, at 1:14 PM, Turtle Creek Software via Cocoa-dev
> wrote:
>
>>> I know this is the Cocoa devs list... but why not make a website?
>>> It would be easier to develop, completely crossplatform, no app store
>>> complications, you would be in total control of your stack, etc.
>
> On Oct 11, 2019, at 4:46 PM, Jens Alfke wrote:
>
>> On Oct 11, 2019, at 12:22 PM, Richard Charles wrote:
>>
>> A second choice "Cross-platform Cocoa App" would be great for the small
>> developer who’s focus is on business applications. All whole world doesn’t
>> revolve around games.
>
> On Oct 11, 2019, at 11:21 AM, Jens Alfke via Cocoa-dev
> wrote:
>
> What you can do is give them feedback about your specific experience, as
> you're doing, and I hope that someone at Apple is reading this thread and
> taking notice.
When creating a new project in Xcode one of the choices
> On Oct 10, 2019, at 5:20 PM, Charles Srstka via Cocoa-dev
> wrote:
>
> Yes, they marketed Carbon as a first-class citizen, promoted as “the basis
> for all life,” and even rewrote the Finder and Dock—which already had Cocoa
> implementations from NeXT—in Carbon just to prove that they were
> On Oct 9, 2019, at 11:58 AM, Pier Bover wrote:
>
> For example Imagix is a company that does image transformation in the cloud
> and uses macs because of the high performance of CoreImage
> (https://photos.imgix.com/racking-mac-pros) It's still more cost effective
> for them to use
> On Oct 9, 2019, at 11:19 AM, Turtle Creek Software via Cocoa-dev
> wrote:
>
> Why is Cocoa source code hidden?
Because Apple does not want to expose Cocoa source source. It is proprietary
software.
> Many of the frustrations we had with the 64-bit update attempt were caused
> by Cocoa's
> On Oct 4, 2019, at 4:43 AM, Dragan Milić via Cocoa-dev
> wrote:
>
> Apple also strongly and clearly advised all new development should be done in
> Yellow Box/Cocoa. Sure it took Apple too quite some time to transition
> everything away from Carbon, but it was clear from the beginning that
> On Oct 2, 2019, at 11:14 AM, Turtle Creek Software via Cocoa-dev
> wrote:
>
> Sadly, we just decided to abandon the Cocoa update for our app.
Great historical overview from a small developers perspective. Perhaps you
should send this email to Tim Cook. It might some attention. Just a
> On Sep 30, 2019, at 5:57 PM, Sam Ryan wrote:
>
> I tried a completely new approach - Electron. I have found Electron to be
> surprisingly quick to prototype, easy to bridge to c++, and is cross platform
> (non mobile at least). I would not have recommended a non-native approach
> until
> On Sep 27, 2019, at 1:21 PM, Jens Alfke wrote:
>
> I was typing a lengthy answer, but it occurred to me it's basically the same
> reason why Apple didn't release macOS for generic PCs ('hackintoshes') and in
> fact actively made it difficult for anyone to port macOS. It's because it
>
> On Sep 27, 2019, at 6:19 AM, Turtle Creek Software via Cocoa-dev
> wrote:
>
> We used an object database called NeoAccess for our 32-bit C++ app. It had
> reference counting for objects retrieved from the database. Setting the
> ref count manually was extremely easy to screw up. It was
> Excerpt from Xcode 11 release notes originally quoted by Quincey Morris.
>
> NSView and UIView have a layout mode option in the Size inspector to
> explicitly opt into “translates autoresizing mask into constraints”. The
> default setting is “Automatic”, which is the existing behavior.
> On Sep 23, 2019, at 8:06 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> Recently, I am getting lots of warnings saying
> "Views without any layout constraints may clip their content or overlap other
> views"
> when I build my screen saver.
Try this. In Xcode navigator select the xib file
> On Sep 10, 2019, at 10:54 AM, Gabriel Zachmann wrote:
>
>> I have had good results with CTLineGetTypographicBounds().
>
> This seems to be suitable only for single lines of text.
> But , usually, I've got 2 lines of text.
>
> I looked at Core Text a bit further, but I could not find how to
> On Aug 28, 2019, at 1:33 PM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> I am trying to determine the size of a piece of text using
> boundingRectWithSize.
>
> The problem is that this method does not return the correct width. (The
> height seems to be about right.) Sometimes, the width
> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev
> wrote:
>
> I've just started implementing the Cocoa windows. The NSView subclasses
> involved are receiving drawRect: messages but are not receiving mouseDown:.
It seems to me like your window is not setup properly or the view is
> On Aug 10, 2019, at 3:21 PM, Rob Petrovec via Cocoa-dev
> wrote:
>
> So he needs to implement hitTest to get mouseDown events.
I just made a new Cocoa App project with a custom view. I did not implement
hitTest:. The view receives mouseDown events just fine.
--Richard Charles
> On Jun 28, 2019, at 9:39 PM, Dave Fernandes via Cocoa-dev
> wrote:
>
> Not a comprehensive list, but a start...
> https://github.com/ashfurrow/xcode-hardware-performance
Very interesting. Thanks for sharing.
I was surprised to see Custom Hackintosh machines contributing to the Xcode
build
> On May 28, 2019, at 8:18 PM, Leo via Cocoa-dev
> wrote:
>
> Can you please elaborate on this...
Perhaps this will help.
https://stackoverflow.com/questions/25152451/are-mac-app-store-code-sign-resource-envelopes-always-version-1
--Richard Charles
> On May 29, 2019, at 7:02 AM, Steve Mills via Cocoa-dev
> wrote:
>
> Supposedly, these lists are to be done away with at some point. Someone
> started co...@apple-dev.groups.io, which many of us have moved to. Or use the
> annoying and inferior dev forums.developer.apple.com.
It is a
> On May 28, 2019, at 3:43 PM, Leo via Cocoa-dev
> wrote:
>
> -I recently contacted Apple again and they pointed me to some resource page
> that was created back in 2016. It briefly mentions a similar error - but
> still without any info on how to solve it:
>
61 matches
Mail list logo
