Re: Cocoa-dev Digest, Vol 19, Issue 24
> 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 version of the app itself being 13.8 MB.) My app is also large Objective C project with 247 primary source files with the release version at 24.6 MB. Also using Xcode 13.3 running under macOS 12.3. > When I run the app in Xcode (whether in debug mode or not), the All Output > window produces the following: > > 2022-04-02 10:11:07.626094-0700 iData Pro 5.0.00[73856:2163752] > [logging-persist] cannot open file at line 45530 of [9ff244ce07] I was getting output like this several weeks ago but now it has stopped. Not sure why. My app uses CoreData but not a sandbox. https://stackoverflow.com/questions/56461441/sqlite3-open-cannot-open-file-at-line > 2022-04-02 10:11:07.626135-0700 iData Pro 5.0.00[73856:2163752] > [logging-persist] os_unix.c:45530: (0) open(/var/db/DetachedSignatures) - > Undefined error: 0 I was getting output like this several weeks ago. The file did not exist on my system. So I created one and never saw the message again. touch /var/db/DetachedSignatures https://developer.apple.com/forums/thread/131498 Richard ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Distributing Mac App to Registered Devices
> 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 development signing. Notarized builds are reserved for archiving. Just saying that Apple is steering everyone in that direction. Apple's answer to the problem is registering devices in your developer account. Except is does not work with mac devices. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Distributing Mac App to Registered Devices
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 a debug or release configuration version of the app with development signing they are presented with a malicious software warning. One way to open the app anyway is to go to System Preferences > Security & Privacy and click Open Anyway. Another way is for the developer to register the device UDID of the beta tester’s machine. However it does not work. The registered machine is still presented with a malicious software warning when opening the app. So has anyone gotten this to work? https://developer.apple.com/documentation/xcode/distributing-your-app-to-registered-devices --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Several different NSUserDefaults in the same app?
> 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 benefits? I have only ever been infuriated with this process during development. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Several different NSUserDefaults in the same app?
> 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 >> NSUserDefaults instance instead of using the shared one. >> >> So it appears that using alloc int does not return the shared instance. > > Where in the docs do you read that? The current NSUserDefaults docs say > contrary: Sorry for the confusion. It is older 10.9 documentation for the init method. Apple 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 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? > > 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. > Note that the system will still create the standard user defaults file for > you, to save things like window positioning. But, you can save these things > yourself in your own files. Just make sure you don’t use the same file name > as the system uses, or it will overwrite yours. You can modify it as you > suggested previously, though. So Jack I am curious, do you use alloc then init or initWithSuiteName:nil or initWithSuiteName:@“mySuiteName" to create your own defaults? --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Several different NSUserDefaults in the same app?
> 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 , Alloc init vs standard Userdefault https://stackoverflow.com/questions/36615260 --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Several different NSUserDefaults in the same app?
> 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"]; > > So, where is the kind of monitor encoded? > I mean, how does the code distinguish between the preferences of monitor1 and > monitor2? > > Can you explain to me, what is the difference between > [[NSUserDefaults alloc] init] > and > [NSUserDefaults standardDefaults] > ? > I didn't get that from Apple's docs. > 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 NSUserDefaults instance instead of using the shared one. So it appears that using alloc int does not return the shared instance. It would be up to you to determine the monitors attached to the computer using NSScreen and or CGDirectDisplay routines. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Several different NSUserDefaults in the same app?
> 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"] boolForKey:@"some > key"] How about something like this? NSUserDefaults *monitor1 = [[NSUserDefaults alloc] init]; [monitor1 setBool:YES forKey:@"MyKey”]; BOOL value = [monitor1 boolForKey:@"MyKey"]; --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to reposition subviews without Auto Layout
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 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to reposition subviews without Auto Layout
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 works and it indeed does. So it looks like simply overriding the > "layout" method and doing the positioning and sizing there is also possible > without using any Auto Layout features whatsoever... > > On 17.10.2020 at 16:30 Richard Charles wrote: > >> 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 should I reposition and resize those three >>> subviews when the NSWindow size changes? >>> >>> I see that NSView has a "layout" method that can be overridden but AFAIU >>> this is only to be used for Auto Layout. I don't want to use Auto Layout >>> because my whole layout is very simplistic and just involves those three >>> subviews which I can easily position and size manually. I just need to know >>> where to put the code that sets their new position and size... anyone? >>> >>> -- >>> Best regards, >>> Andreas Falkenhahn ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to reposition subviews without Auto Layout
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 should I reposition and resize those three subviews > when the NSWindow size changes? > > I see that NSView has a "layout" method that can be overridden but AFAIU this > is only to be used for Auto Layout. I don't want to use Auto Layout because > my whole layout is very simplistic and just involves those three subviews > which I can easily position and size manually. I just need to know where to > put the code that sets their new position and size... anyone? > > -- > Best regards, > Andreas Falkenhahn ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Drag and Drop of NSTokenField stopped working in Catalina
> 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 not > work anymore. > In Xcode I get the following message: > > ": There was an exception (There are 2 > items on the pasteboard, but 1 drag images. There must be 1 draggingItem per > pasteboardItem.) raised while processing drag. Ignoring…” The NSTokenField is used in the Mail application in the address field. Using the Mail app in Catalina, drag a token from the address field to a TextEdit document. Does that work? I would try it but my primary development machine is macOS Sierra. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Launching in fullscreen gives "Funk" sound sometimes
> 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 https://www.bignerdranch.com/blog/xcode-breakpoint-wizardry-for-debugging/ --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Screensaver can capture mouse events under Catalina
> 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 a macOS application with screen saver functionality. You could download it and try it out and see how they do things. What does the installer do. Does simply install an app or are there other pieces installed. Open up the app package and see what is inside. That might give you a hint. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode Archive builds Debug version?
> 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 uses the Release configuration when building an Archive. This is the same configuration used when Profiling. You can see all of this in Edit Scheme... --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode Build Location
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 an informative technical note on the subject. https://developer.apple.com/library/archive/technotes/tn2435/_index.html I appreciate the list responding to an Xcode question. The xcode-users list has been shut down and I have yet to acquire a taste for the new apple-dev groups. Thanks again. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode Build Location
> 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 the main project then it is so large it becomes cumbersome to work with. One library has over 1,100 source files. Using a workspace for this collection of projects on a daily basis is not fun at all. It is actually counter productive. > > btw, the 28 character string is a UUID. I’m not sure about its lifetime. > I don’t think these are a UUID. If a project is moved to another computer it has the same string appended to the project name in the build folder. If the build location is changed in Xcode preferences the appended string remains the same. The string does change if the name of the project enclosing folder is changed. So maybe I have answered my own question. The string appears to remain constant as long as the project name and enclosing folder remain unchanged. So perhaps there is nothing to be afraid of here with regards to this string being part of a link path during build. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Xcode Build Location
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 well but now with Xcode 11 there are some drawbacks. For example Clean Build Folder cleans the entire shared build folder not just the target. Also archiving has never worked and still does not work with this configuration. So now I have changed the Xcode setting from Shared Folder to Unique which apparently is the default. When using the Unique setting a 28 character string is appended to the project name in DerivedData. The string appears to be random characters but most likely is not. During build when linking to the dynamic libraries this 28 character string is in the file path. So if it ever changes then linking will fail. So my question is will this 28 character unique string always remain constant for a given project? Any insight would be appreciated. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Inconsistent fullscreen modes
> 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 = [self.window standardWindowButton:NSWindowZoomButton]; NSCell *cell = button.cell; [cell.target performSelector:cell.action]; Where self is the NSView object. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem in the creation of Graphics context(NSGraphicsContext)
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 review the code for creating ImageRep its here > https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/Eclipse%20SWT/cocoa/org/eclipse/swt/internal/graphics/ImageUtil.java#n38 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem in the creation of Graphics context(NSGraphicsContext)
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 = [NSGraphicsContext
graphicsContextWithBitmapImageRep:imageRep];
printf("Graphics Context %p\n", context);
Execute the above code and I get a graphics context when the window is in the
high resolution display. Move the window to the secondary normal resolution
display, execute the code, and I get another graphics context. You must be
doing something wrong.
Normally a graphics context is valid for a given display. When the window moves
from one display to another your app needs to detect this a pull another
context.
https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_contexts/opengl_contexts.html
"A renderer change can occur when the user drags a window from one display to
another or when a display is attached or removed.”
This might not be true with an offscreen context which might remain valid
regardless of the display.
--Richard Charles
> On Mar 3, 2020, at 11:19 PM, Sravan Kumar Lakkimsetti via Cocoa-dev
> wrote:
>
> Hi,
>
> In our product we use
> https://developer.apple.com/documentation/appkit/nsgraphicscontext/1529827-graphicscontextwithbitmapimagere?language=objc
> to create Graphics Context for drawing on top of image.
>
> This particular API returns null in some cases. One particular case is
> troubling us. Would like to know why this happens and how to resolve.
>
> Here is the problem.
> There are two monitors attached to Mac. Main display is retina display and
> secondary display is non-retina display. The application is moved from main
> display(retina display) to secondary display(non-retina display). In this
> case our application redraws the GUI(to use higher resolution images) In
> this process we are creating graphics context using the above api. This api
> returns null if the main display is retina and secondary display is
> non-retina.
>
> It would be helpful if anyone can suggest on how to identify why this api
> returns null
>
> Thanks
> Sravan
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Confusion about screen resolution
> 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 non-integral > amount — to the hardware physical pixel dimensions of the screen. Thank you Quincey for the excellent summary. NSWindow documentation for the backingScaleFactor indicates "The value of this property is 2.0 for high-resolution scaled display modes, and 1.0 for all other cases." I am just curious, have you actually seen a 3X backing store or is this just a surmise? --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Confusion about screen resolution
> 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 buffer. > I am curious as to why that doesn't cause any aliasing artefacts, or > anti-aliasing artefacts ... > > Best, G. > This is bizarre. When did this start, Catalina? It has been my experience that the default scale factor is 1.0 for normal displays and 2.0 for Retina displays. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Future of Cocoa #2
> 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 site where the tag line is "cross-platform". It would be interesting to know if this stuff really works. https://dotnet.microsoft.com/learn/dotnet/what-is-dotnet --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Future of Cocoa
> 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 Pierre Habouzit Senior Software Engineer at Apple and Duncan Exon Smith Engineering Manager, Clang Frontend Team at Apple So that is a great point. If Objective-C is dying why is Apple going to all the trouble of adding new language extensions for performance gains? --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Objective-C++
> 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 and what tools and frameworks they will be using. https://jobs.apple.com/en-gb/details/200013614/senior-software-engineer-windows-media-apps --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Future of Cocoa
> 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 thread. Although depreciated OpenGL and related dynamic libraries are still present in system frameworks on macOS Catalina. I have an app that depends on OpenGL and GLU and it runs fine on Catalina. OpenGL was release 27 years ago and is used extensively in many technical fields. Perhaps this is why Apple has not yet removed these libraries from the system and GPU vendors still support the OpenGL compatibility profile. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Future of Cocoa
> 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 you an educated guess about the remaining life of the Cocoa frameworks in Objective-C and the future of big apps on the Mac. Let us know if you hear back from him and what he tells you. https://academy.realm.io/posts/altconf-aaron-hillegass-eulogy-for-objective-c/ You could submit a developer technical support incident to Apple and ask them point blank how much longer they will be supporting the Cocoa frameworks in Objective-C. Let us know if you hear back from them assuming the answer is not under a non-disclosure agreement. > > It's all SwiftUI and Swift. > If I understand it correctly, there is a linkage between Swift and Objective-C. Apple devised a way to call the Cocoa frameworks written in Objective-C from the Swift language using the magic of the LLVM compiler. A great question would be is possible for Apple to pull the Objective-C rug out from underneath the Cocoa frameworks leaving only a Swift implementation? Carbon was a completely different animal. Apple pulled, so to speak, the core out of Foundation and came up with Core Foundation to give life and interoperability for the Carbon layer. However NOTHING of lasting value was built on the Carbon layer. The whole Carbon thing can be swept away and what difference does it make. When committing to 64 bit Apple said NO to Carbon but YES to Cocoa and YES to Core Foundation and YES to a lot of other stuff. The OS still has the XNU (Mach) Kernel and FreeBSD (written in C & C++), the Cocoa frameworks (base layer written in Objective-C), Swift and lots of other stuff. From my point of view I do not see Apple sweeping away Objective-C and the Cocoa frameworks any time soon. Essentially they said as much in their 64-Bit Transition Guide. https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/64bitPorting/HighLevelAPIs/HighLevelAPIs.html --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Objective-C++
> 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 APIs work and work together to get your code running - and many of > those assumptions simply weren't true when running in a Windows environment. > We spent a significant amount of time re-writing various APIs used by the > application because the RedBox ones we had access to simply didn't work. > > We won't go into the facts that every Windows font size is *exactly* 33% > bigger than they are on the Mac (Windows is 96 dpi, Mac is based on 72 dpi: > 96/72 = 4/3). Or that a mouse on Windows was less precise but targets were > smaller. Or the myriad of other "issues" that make a Windows app just "feel > different." > I am no expert, but I am a little confused. The Cocoa API provides a very broad surface area covering the hosting OS. In 1994 the OpenStep API (predecessor to Cocoa) ran on NeXTSTEP, Windows NT and Solaris. The Red Box, Blue Box, Yellow Box was 1997. Apple released iTunes for Windows in October 2003. Over the last 16 years would bet that a lot of spit and polish has gone into integrating Cocoa with Windows by the iTunes team. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Objective-C++
> 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 apps on the Mac platform. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Objective-C++
> 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 to outside developers? --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Objective-C++
> 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 examination of application files shows dlls for CoreFoundation, CoreText, Foundation, CoreGraphics, Objective-C, etc. This is a Cocoa application. Why can't Apple provide tools so that outside developers can also do this? --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on productivity
> 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 better presentation of Apple documentation than what Apple offers. Thanks for sharing. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on productivity
> 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 documentation with downloadable and searchable pdfs. Now all pdfs are gone and online documentation is like art on display in a museum. Great to look at but not very usable. I think you missed a step when learning Cocoa. A great way to start is with something like Cocoa Programming for Mac OS X by Aaron Hillegass. It has lots of examples to reinforce what you are learning. Hopefully the Feedback Assistant will bring better results than the Bug Reporter. Apple Developer Forums are perhaps like the current documentation. Nice to look at but not very useful. Interesting that this list has had somewhat of a resurgence in recent months. Apple sample code should compile and run on the current version of Xcode. Period. What good is sample code if it takes a day to get it up and running. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Not seeing rightMouseDown: - what are the docs actually saying ?
> 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 NSResponder documentation. "Prior to OS X v10.7, NSView did not pass unhandled rightMouseDown(with:) events up the responder chain. In macOS 10.7 and later, NSView passes rightMouseDown(with:) events up the responder chain if AppKit doesn’t find an associated context menu to display for the view. To avoid binary compatibility issues, this new behavior is enabled only for applications linked on macOS 10.7 or later." Sounds straight forward to me. Perhaps you need to read it again. I created a new app with Xcode 9.2 and linked to 10.13. Created a custom view and custom window with rightMouseDown logging. Built the app for 32 bit and 64 bit. An unhandled rightMouseDown is passed promptly from view to window in both cases. Also the NSView documentation states. "Because NSView changes the default behavior of the rightMouseDown: method, you should call super when implementing that method in your custom subclasses." Are you doing this? --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Not seeing rightMouseDown: - what are the docs actually saying ?
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. Too many changes to down grade from 64 to 32 bit. --Richard Charles > On Oct 18, 2019, at 3:10 PM, Aandi Inston via Cocoa-dev > wrote: > > I believe I may be seeing an effect described in the Cocoa docs for the > rightMouseDown: method. I am unsure exactly what the docs are saying however. > Symptom: compiled for 64-bits, an unhandled rightMouseDown: is eventually > sent to the NSWindow subclass, but compiled for 32-bits (and run on 10.11.6 > at least) the event never arrives. > > For NSView, we see "In macOS 10.7 and later, if the event is not handled, > this method passes it up the responder chain." For NSResponder we see "Prior > to OS X v10.7, NSView did not pass unhandled rightMouseDown: events up the > responder chain. In macOS 10.7 and later, NSView passes rightMouseDown: > events up the responder chain if AppKit doesn’t find an associated context > menu to display for the view. To avoid binarycompatibility issues, this new > behavior is enabled only for applications linked on macOS 10.7 or later." > > But what is the actual test for whether to do this? "Running on" and "linked > on" are both 10.11. Is it actually looking at the "Deployment target"? To > make matters worse, my code is running as a plug-in and I'm going to take a > guess that if a deployment target applies, it is the one selected in the main > executable (not under my control) rather than the plug-in... can anyone > explain what Cocoa would be looking at? > > And if it turns out that I'm not going to get rightMouseDown: sent directly > to my NSWindow, is there any alternative to subclassing any NSView or > descendent (including NSControls of various flavours) that might be the > initial responder? > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Need for Swift
> 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 documentation. "The class hierarchies are separate; a C++ class cannot inherit from an Objective-C class, and an Objective-C class cannot inherit from a C++ class." This may or may not help. I use the following inline macro for C++ prototypes in dual purpose headers. #ifdef __cplusplus #define CPP(x) x #else #define CPP(x) #endif That way you can import or include the same header into a .m or .mm source file. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Need for Swift
> 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. So if I understand correctly you have three choices for a native UI on the Mac. 1. Objective-C which would integrate nicely with your C++ business logic using Objective-C++. One problem is you have very little experience with the Cocoa frameworks. Another problem is you are hesitant to pursue this path fearful that down the road Apple may abandon Objective-C. 2. Another option is Swift but it has zero integration with C++. So this is really not a choice at all. 3. A third option would be to combine all three. Keep your business logic in C++ and combine with Objective-C using Objective-C++ and then bridge to Swift. That does sound like a nightmare. Looks like you are in a pickle. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Need for Swift
> 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 Chris Lattner who showed it to management and they loved the idea. It was made possible by the power and flexibility of the LLVM compiler. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> 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. There are high quality libraries that do much of the heavy > lifting, so writing ones usually are wiring glue code between the libraries. Multiple versions of an app possibly consisting of a browser base web app along with a high performance and convienent native desktop app (possibly native on Mac and Windows) and a native mobile app (possibly native on iOS and Android), a file based format for offline storage (native on Mac and Windows) and a cloud based format for online storage and colloraboration all working seamlessly together. Unless I am mistaken Adobe and Microsoft approach this with Creative Cloud and Office 360 apps. None but the biggest of companies can to this. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> 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. > > QuickBooks has gone that route. They still grudgingly sell desktop apps, > but really push people towards their cloud version. Besides all the > benefits you mention, it's a steady monthly income. Hence why Microsoft > and Adobe are also going that route. Apple too. If I understand this correctly. Microsoft Office Web apps (Word, Excel, PowerPoint) are simplified versions of desktops apps that run in a web browser along with a subscription service. Apple iWork web apps (Pages, Numbers, Keynote) are feature complete versions of desktop and mobile apps that run in a web browser. Apple has never released the details of how they do this. Adobe Creative Cloud apps (Lightroom and Photoshop) are native apps for desktop and mobile with cloud based storage and a subscription service. They are not cross-platform browser based web apps. None but the biggest of companies can do this. One alternative for native desktop apps is a Box Integration. https://support.apple.com/en-us/HT207876 --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> 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. > > https://developer.apple.com/xcode/swiftui/ > https://developer.apple.com/mac-catalyst/ What I meant to say was Cross-platform as in Microsoft Windows. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> 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 is Cross-platform. Under this tab the only choice available is "Cross-platform Game". 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. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa
> 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 serious > about it. Just a guess but perhaps management had an awakening when they found the time and effort expended to write the next even better version of Finder in Carbon was substantially more difficult and costly that the prior Cocoa version. > I still remember reading this thread, and feeling nervous about it: > > https://lists.apple.com/archives/cocoa-dev//2002/Jan/msg01366.html Yes this is a very interesting thread. Here is a post on the same thread written by Erik M. Buck. https://lists.apple.com/archives/cocoa-dev//2002/Jan/msg01329.html "Carbon will exist as long as Apple exists.” Apparently this is the same Erik M. Buck who coauthored the excellent book Cocoa Design Patterns with Donald Yacktman which came out in 2009. So apparently Mr. Buck saw the light and had a change of mind. Apparently a lot of individuals at Apple had a change of mind and saw the light as Cocoa demonstrated itself superior technology. I think that is what happened. > The common assumption among the more level-headed at the time was that Cocoa > was going to be gradually rewritten to sit on top of Carbon, with Carbon > sticking around as the lower-level, closer-to-the-metal API. My guess is maybe outside the company this may have been the common view but not to every one inside the company. Core Foundation made Carbon possible on the new OS. It was written by borrowing stuff from Cocoa not the other way around. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> 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 expensive macs vs linux servers because of the performance > increase. Pretty amazing if you think about it. They should be thrilled that Apple announced an optimized version of the 2019 Mac Pro for rack deployment. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> 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 lack of visible source. It was a "black box" that often required > trial-and-error to figure out. Yeah, the headers are visible, and Apple has > info online. But sometimes that was not sufficient to understand the actual > implementation details. > > When debugging, the stack trace inside Cocoa was just a bunch of > rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes, or > step through their C code. More mysteries and headaches. I agree reading assembly is horrid. Did you know that you can set a symbolic breakpoint on code inside the Cocoa frameworks? You can also swizzle a framework method to gain insight into what Apple is doing. You can also examine Cocotron source code for insight into what maybe going on behind the scenes. > I personally learned C++ while using the PowerPlant library from > Metrowerks. Its source files were totally exposed. Seeing comments and code > really helped. When designing or debugging, it was possible to step through > their code and see exactly how it functioned. Cocoa would be so much > easier to use if its source was accessible like that. > > In fact, why isn't Cocoa open source? Apple open-sources Swift and the > Darwin kernel. Surely the GUI can't be any riskier to expose to developers? Perhaps Apple does not want to give away the Crown Jewels. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa
> 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 Carbon > was there just as long as it was really needed, and not a minute longer. With > every early major releases (until 2007) of macOS, Apple put strong emphasis > in release notes which OS-bundled applications have gone from Carbon to Cocoa. I don’t think it was this clear. I remember reading an Apple employment advertisement roughly around 2005 that went something like this. "Join the engineering team and help us make the next Finder rewrite the absolute best ever with Carbon and C++.” It was reported that Apple had the 64 bit Carbon port done when the decision was made not to release the product but rather focus the company's resources and efforts on Cocoa instead. It appears there was a lot of internal turmoil within the company and the resistance to Cocoa was strong but eventually Cocoa won out the day because it is a superior technology. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa
> 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 thought. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
> 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 recently, but for what it is worth, I've come to realise this is one of > the better options available these days. YMMV. Interesting. > On Sep 30, 2019, at 7:00 PM, Jens Alfke wrote: > > If you don't mind coding in JavaScript, don't care about Mac UI guidelines, > and aren't shy about shipping a 200MB+ app that has an entire freakin' web > browser embedded in it… > > (Sorry for the grumpiness. I'm just sick of all the "Mac apps" that are just > Electron-based web pages, e.g. Slack.) Also interesting. I found John Gruber's comments on Electron and the Decline of Native Apps enlightening. https://daringfireball.net/2018/12/electron_and_the_decline_of_native_apps --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
> 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
> would damage or tank their hardware business. To a lesser degree, if it's
> just apps being ported and not the whole OS, but still significant I think.
>
> Porting your software crown jewels to run on commodity PC hardware is
> something only a failing company does, when it's throwing its own hardware
> business overboard. Consider NeXT and Be. (And I believe Amiga was planning
> something similar before they went under.)
>
> Anyway, these days Windows is only for cash registers, accountants, and
> basement-dwelling hardcore gamers. ;-)
There a lot of business users still on Windows. Adobe, AutoDesk, and other
large organizations have dual track development for Mac and Windows but this is
hard for a small developer.
The computer aided design software that Apple engineers use to design their
stuff is Unigraphics NX which runs on Windows and on the Mac under X11 because
NX has a Unix heritage. So I don't think you will ever see the day that the Mac
drops support for X11. The point is there are still business segments, users
and developers that benefit from cross platform high performance desktop apps.
In 1998 Apple was more than ready to give away the crown jewels with the
Rhapsody Yellow Box but Adobe made them change their mind when they refused to
port Photoshop. Subsequently Apple changed the focus with Mac OS X and removed
the cross platform offer. I think one of the major reasons was the amount of
time they spent writing Core Foundation and Carbon. Perhaps they didn’t want to
stretch their resources thin by also supporting Windows apps.
--Richard Charles
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
> 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 hard to debug > off-by-ones on the ref count. So we made those calls private, and replaced > them all with a stack-based watcher class. It adds a reference in the > constructor, and removes it in the destructor. Simpler, more reliable, and > exception-safe. > > It makes sense that Cocoa programmers much prefer ARC to MRC. Doing it > manually is easy to break and hard to debug. However, the fact that ARC is > not exception-safe concerns me. It suggests that Cocoa still manages ref > counts manually, somewhere under the hood. We've had two sets of mystery > deallocs that both involved NSTabView. From hard past experience, I would > bet there is a bug lurking somewhere inside there. Traditional Cocoa manual memory management relies on naming conventions and just a few basic rules. When combined with the Xcode static analyzer it is almost pain free. However it is not as Swift as latest thing. > In fact, assuming that Cocoa is written entirely in plain C, it may not > even be possible to avoid manual ref counts. No STL, no RAII, no native > exceptions. It makes sense to write kernels in C because speed is > important. But GUI frameworks are way more complex, and C may just not be > the right tool for them. Objective-C is plain C with a runtime and a few syntactic additions. The big and beautiful thing about Cocoa are frameworks which are written in Objective-C and now Swift. > I'm no fan of garbage collection, but those languages do make programming > easier. There's enough other stuff to worry about. It's why Java & Python > are so popular. > > C++ makes the programmer fully responsible for memory, but the modern STL > really helps. It's improving rapidly. Even when C++ breaks, it's easy to > debug object lifetimes. Just put a breakpoint in the destructor. If it's > dying too soon you'll see exactly what killed it. If a leak it will never > get there. > > Our company sells to construction companies. Our expertise is in > accounting, estimating and other construction business tasks. We need a > platform that lets us create apps quickly. Cocoa is not that. We've spent > 3 years so far on 64-bit porting via Cocoa. Best guess is another year or 2 > to get it perfect. Meanwhile, we should be adding features to keep up with > the Windows competition. It appears like your biggest challenge is porting a 32-bit C++ third party library and porting Carbon to Cocoa? Moving from 32 bit Cocoa to 64 bit Cocoa should not be a big deal. What I wish Apple would do is release a cross platform Objective-C (and Swift) solution. They already transitioned from PowerPC to Intel and ARM. iTunes at one time was released for Windows. One programmer almost did this single handedly with the Cocotron. It was so well written and comprehensive that Microsoft picked it up and started using it for their WinObjC framework. The Mac vs Windows war is over and long gone so why doesn’t Apple help out the small developer and release a cross platform solution. > I don't know if anyone from Apple is on this list, but I think Cocoa needs > a huge overhaul. It's 30 years old and showing its age. The problem is > not just memory management. The constraint system is extremely difficult- > we've spent many days futzing with it, and there are still mystery > problems. Pretty much everything else is more creaky and awkward than it > could be. > > Swift may be the solution, but it's built on a weak foundation. It makes > cross-platform development almost impossible. The TIOBE index shows Swift > declining (and Objective-C increasing). So, maybe it isn't. > > It would really help if programmers could write Macintosh apps in C++, > Python, etc. Apple did a language overhaul with Swift. My primary app requires integration with C++ so I have stuck with Objective-C and Objective-C++ and the traditional Cocoa frameworks. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Views without any layout constraints may clip their content or overlap other views
> 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. “Automatic” > implies that “translate autoresizing mask into constraints” is off when a > view affect by constraints in the storyboard or .xib file, but on if > unconstrained. (37352354) Is it just me? I found this very confusing. > On Sep 26, 2019, at 8:44 AM, Laurent Daudelin via Cocoa-dev > wrote: > > I just checked this Quincy. What I observe is that the top view in my windows > have the setting set to “Translates autoresizing mask into constraints” but > all the other subviews are set on “Automatic”. Should I leave it that way? > This is an old project predating the auto-layout, by the way. I also noticed the same thing. The content view of the window has a different behavior and default compared to the subviews. Previously Auto Layout was enabled or disabled per nib. Now the layout mode is per view and constraints can not be fully disabled. So the existing behavior is not present in Xcode 11. IB Auto Layout or constraints was introduced around the Xcode 4.2 timeframe. An IB document could enable or disable Auto Layout with a check box in the file inspector. Looking through the historical Xcode release notes you can see it took a long time to get it working properly. This may be why some developers opted out of Auto Layout. I have a large project with with Auto Layout turned off in each nib. I opened the project in Xcode 11 and started working my way through the nib warnings and then realized I don’t know what I am doing so I stopped. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Views without any layout constraints may clip their content or overlap other views
> 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 then select one of the objects in the file. It can be any object in the file such as the window, the first responder, the file's owner, etc. In the right side panel file inspector a section will appear titled "Interface Builder Document". In this section deselect "Use Auto Layout". --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: boundingRectWithSize gives wrong size
> 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 determine > the width/height of a two-line string. For multiple lines you need to use a framesetter. CTFramesetterCreateWithAttributedString() CTFramesetterSuggestFrameSizeWithConstraints() --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: boundingRectWithSize gives wrong size
> 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 is only a little bit > too wide, sometimes it is much too wide. I have had good results with CTLineGetTypographicBounds(). --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa window messages in app being ported from Carbon
> 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 not properly configured in the window. NSApplication dispatches a mouseDown event to NSWindow and the window dispatches the event to the NSView. The responder chain is not involved unless using the default implementation which simply passes the message to the next responder. The method acceptsFirstResponder does not play a roll in mouseDown. You could subclass NSWindow and override sendEvent: to see what is happening during a mouse down. #0 0x00011355 in -[MyView mouseDown:] #1 0x7fff8d7db24f in -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] () #2 0x7fff8d7d7a6c in -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] () #3 0x7fff8d7d6f0a in -[NSWindow(NSEventRouting) sendEvent:] () #4 0x7fff8d65b681 in -[NSApplication(NSEvent) sendEvent:] () #5 0x7fff8ced6427 in -[NSApplication run] () #6 0x7fff8cea0e0e in NSApplicationMain () --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa window messages in app being ported from Carbon
> 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 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Best Xcode machine mid-2019?
> 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 performance data. > On Jul 1, 2019, at 12:07 PM, Steve Mykytyn via Cocoa-dev > wrote: > > Looking at Activity Monitor during the build, all four CPU cores are > utilized symmetrically, the four hyper-threads somewhat less. I have an older Mac Pro (Quad-Core Intel Xeon) and the same thing happens. During build the CPU scores are heavily used but the hyper-threads somewhat less. I always thought the physical cores and hyper-threads were used the same amount, but that is not the case. Apparently the physical cores are more powerful than the virtual cores. I never knew that. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Notarization error: The signature algorithm used is too weak
> 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 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Is the list alive?
> 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 mystery why this list is still alive. Internally at Apple I would bet that most developers get their questions answered by asking another developer. The current documentation is very artistic but not very functional or useful for serious development. A lot of questions can be answered by looking in stackoverflow, perusing older documentation or searching the web. You can always submit a technical support incident but you will most likely be asked to submit a focused sample project demonstrating the issue. I need to take a look at co...@apple-dev.groups.io. It looks interesting. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Notarization error: The signature algorithm used is too weak
> 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: > https://developer.apple.com/library/archive/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG301 > > > -A search on this error didn't produce anything useful. > > -The tar.gz file in question is an eSellerate licensing framework. As many > people may know, it's been a popular licensing??platform for Mac software for > over a decade. While I switched to a different licensing platform some time > ago, I still have thousands of customers with eSellerate licenses (as I'm > sure is the situation with many other Mac developers). > > As far as I understand, this whole situation has to do something with signing > files inside tar.gz archives - on which I couldn't find any info either Looks to me like your eSellerate framework is signed with a version 1 signature. You need to resign the framework with a version 2 signature. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
