Date   

item based NSBrowser

Gerriet M. Denkmann
 

Xcode tells me that:
'matrix(inColumn:)' was deprecated in macOS 10.10: Use the item based NSBrowser instead

And when I use parentForItemsInColumn it crashes with:
parentForItemsInColumn: is not supported for browsers with matrix delegates.

NSBrowser.h says:
" Note: the matrix based NSBrowser is deprecated in Mac OS 10.10. New code should use the item based interface.”

These seem to be the "matrix based NSBrowser” methods:
- (NSInteger)browser:(NSBrowser *)sender numberOfRowsInColumn:(NSInteger)column;
- (void)browser:(NSBrowser *)sender createRowsForColumn:(NSInteger)column inMatrix:(NSMatrix *)matrix;

"Alternatively, implement all of the following methods”
- (NSInteger)browser:(NSBrowser *)browser numberOfChildrenOfItem:(nullable id)item API_AVAILABLE(macos(10.6));
- (id)browser:(NSBrowser *)browser child:(NSInteger)index ofItem:(nullable id)item API_AVAILABLE(macos(10.6));
- (BOOL)browser:(NSBrowser *)browser isLeafItem:(nullable id)item API_AVAILABLE(macos(10.6));
- (nullable id)browser:(NSBrowser *)browser objectValueForItem:(nullable id)item API_AVAILABLE(macos(10.6));


So I tried:

func browser(_ browser: NSBrowser, numberOfChildrenOfItem item: Any?) -> Int { 5 }
func browser(_ browser: NSBrowser, child index: Int, ofItem item: Any?) -> Any { "test” }
func isLeafItem(_ item: Any?) -> Bool { false }
func browser(_ browser: NSBrowser, objectValueForItem item: Any?) -> Any? { item }

But when I run this, I get:

*** Illegal NSBrowser delegate (<TestBrowser.AppDelegate: 0x600003c19300>). Must implement browser:willDisplayCell:atRow:column: and either browser:numberOfRowsInColumn: or browser:createRowsForColumn:inMatrix:

and my browser is completely empty.

So: how do I create an "item based NSBrowser" with a delegate using "item data source methods” ?

Gerriet.


Re: Core Graphics: creating an image mask from a PDF?

Jim
 

On Dec 14, 2020, at 8:17 PM, Graham Cox <graham@mapdiva.com> wrote:

I am using Core Graphics. I have an image as a PDF resource that I want to use as a mask - specifically, the PDF only contains black and white graphics as vectors. I have code that can turn that into a CGImageRef as a normal bitmap (to any desired size I want, which is why I start with a PDF file), but the bitmap image I end up with is, of course, black and white. I actually want to draw that in any colour I choose by using a mask image and a fill colour.

Core Graphics has a function CGImageMaskCreate(), which takes a bunch of the usual parameters but only works with a data provider. There is no PDF data provider (AFAIK).

The bitmap image code works by creating a CGBitmapImageContext, drawing the PDF into it, then using CGBitmapContextImageCreate() to obtain the bitmap. But there’s no mask equivalent of this approach. There is also no function to create a mask image from a bitmap image.

Can anyone think of a solution here? Either to create a mask image from a PDF, or a way to draw a black and white bitmap colourised at will. The latter may be possible using CGImageCreateWithMaskingColors(), but the documentation isn’t very clear and the Quartz drawing guide seems to suggest it’s more for background removal than what I need here. If anyone has an example of how to use it (if it’s even appropriate here) that would be great too.
I’ve used CoreImage (CIBlendWithMask filter) to use a mask.

https://developer.apple.com/library/archive/documentation/GraphicsImaging/Reference/CoreImageFilterReference/index.html#//apple_ref/doc/filter/ci/CIBlendWithMask

CoreImage makes it easy to create solid-color images as well.

CIImage *bkgImage = [CIImage imageWithColor:[CIColor colorWithRed:0 green:0 blue:0 alpha:0]];

Alternatively, if you want to stick with the CoreGraphics functions, you can use ImageIO to create a data output of your CGImageRef bitmap that you should be able to feed into CGImageMaskCreate().

Jim Crate


Core Graphics: creating an image mask from a PDF?

Graham Cox
 

Hi all,

I am using Core Graphics. I have an image as a PDF resource that I want to use as a mask - specifically, the PDF only contains black and white graphics as vectors. I have code that can turn that into a CGImageRef as a normal bitmap (to any desired size I want, which is why I start with a PDF file), but the bitmap image I end up with is, of course, black and white. I actually want to draw that in any colour I choose by using a mask image and a fill colour.

Core Graphics has a function CGImageMaskCreate(), which takes a bunch of the usual parameters but only works with a data provider. There is no PDF data provider (AFAIK).

The bitmap image code works by creating a CGBitmapImageContext, drawing the PDF into it, then using CGBitmapContextImageCreate() to obtain the bitmap. But there’s no mask equivalent of this approach. There is also no function to create a mask image from a bitmap image.

Can anyone think of a solution here? Either to create a mask image from a PDF, or a way to draw a black and white bitmap colourised at will. The latter may be possible using CGImageCreateWithMaskingColors(), but the documentation isn’t very clear and the Quartz drawing guide seems to suggest it’s more for background removal than what I need here. If anyone has an example of how to use it (if it’s even appropriate here) that would be great too.


—Graham


Re: Ensure Framework Links to static lib not dylib

Sandor Szatmari
 

Thanks Jack, yes, your point is well taken… but, these are in house production apps/frameworks and we have a long running well establish deployment design that works well…

The structure is as follows

Cocoa App/Frameworks… (with statically linked external libs) are hosted on /Network/Applications and /Network/Frameworks. These shares are pushed out via the OpenDirectory master. Then all clients who are part of the domain automagically have all the components they need with deployment being limited to a single point. Keeping the frameworks out of the apps means replacing one copy of the framework if making a change that does not require pushing out the apps too. I know it’s mostly a moot point… and certainly the horse is dead at this point. We do embed our frameworks within app for qc purposes for updates/new features. This makes an encapsulated bundle for testing that finds it’s frameworks internally before looking at the other runtime framework search paths.

For external libraries that can change version based on an OS update/Security Update, I link them statically so there is no question the frameworks/apps are using the correct external resources for which QA/testing has been performed and certified. So, this is the point at which we embed, albeit statically linked embedding, code from one source inside another source.

Sandor

On Dec 10, 2020, at 14:29, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

I wonder if you might want to embed the library in your application. That might make it more future-proof.

Jack


On Dec 10, 2020, at 11:14 AM, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

Thanks for everyone’s thoughts… I really appreciate it.

I would think, that’s where I went wrong apparently :D, that Xcode should respect explicit configurations, which is what I thought I had done, and that this should be possible.

I’ll examine the linker logs… I’ll try the explicit, full path, linker flag and see if that works. Short of that I’ll just modify the installation of the external lib.

I agree Alex, there’s got to be some special sauce to add here.

Sandor

On Dec 10, 2020, at 13:34, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:
If we have more than one of us manually adding .a, there probably must be a process that does this automatically that we don’t know about.

Any ideas?

On Dec 10, 2020, at 12:15 PM, James Walker <list2@jwwalker.com> wrote:



On Dec 10, 2020, at 9:18 AM, Sak Wathanasin <sw@network-analysis.ltd.uk> wrote:


On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
I fell over this the other day. If you have both the .a and .dylib in the same directory, Xcode will link in the .dylib even if you've explicitly added the .a to your "Link with ..." in the build phases of your project. If you look in the build log, you will see that the linker cmd line that Xcode generates for (say) libFoo.a is something like:

ld .... -lFoo ....

with the result that you (& I) have found. I tried adding various linker-extra flags to force it to use the .a, but in the end, I gave up and put the .a and .dylibs in separate directories (and changed the library search paths as needed).
In the Other Linker Flags build setting, you can add the full path to a library instead of something like -lFoo, ensuring that you get the right one.















Re: Ensure Framework Links to static lib not dylib

Jack Brindle
 

I wonder if you might want to embed the library in your application. That might make it more future-proof.

Jack

On Dec 10, 2020, at 11:14 AM, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

Thanks for everyone’s thoughts… I really appreciate it.

I would think, that’s where I went wrong apparently :D, that Xcode should respect explicit configurations, which is what I thought I had done, and that this should be possible.

I’ll examine the linker logs… I’ll try the explicit, full path, linker flag and see if that works. Short of that I’ll just modify the installation of the external lib.

I agree Alex, there’s got to be some special sauce to add here.

Sandor

On Dec 10, 2020, at 13:34, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

If we have more than one of us manually adding .a, there probably must be a process that does this automatically that we don’t know about.

Any ideas?

On Dec 10, 2020, at 12:15 PM, James Walker <list2@jwwalker.com> wrote:



On Dec 10, 2020, at 9:18 AM, Sak Wathanasin <sw@network-analysis.ltd.uk> wrote:


On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
I fell over this the other day. If you have both the .a and .dylib in the same directory, Xcode will link in the .dylib even if you've explicitly added the .a to your "Link with ..." in the build phases of your project. If you look in the build log, you will see that the linker cmd line that Xcode generates for (say) libFoo.a is something like:

ld .... -lFoo ....

with the result that you (& I) have found. I tried adding various linker-extra flags to force it to use the .a, but in the end, I gave up and put the .a and .dylibs in separate directories (and changed the library search paths as needed).
In the Other Linker Flags build setting, you can add the full path to a library instead of something like -lFoo, ensuring that you get the right one.











Re: Ensure Framework Links to static lib not dylib

Sandor Szatmari
 

Thanks for everyone’s thoughts… I really appreciate it.

I would think, that’s where I went wrong apparently :D, that Xcode should respect explicit configurations, which is what I thought I had done, and that this should be possible.

I’ll examine the linker logs… I’ll try the explicit, full path, linker flag and see if that works. Short of that I’ll just modify the installation of the external lib.

I agree Alex, there’s got to be some special sauce to add here.

Sandor

On Dec 10, 2020, at 13:34, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

If we have more than one of us manually adding .a, there probably must be a process that does this automatically that we don’t know about.

Any ideas?

On Dec 10, 2020, at 12:15 PM, James Walker <list2@jwwalker.com> wrote:



On Dec 10, 2020, at 9:18 AM, Sak Wathanasin <sw@network-analysis.ltd.uk> wrote:


On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
I fell over this the other day. If you have both the .a and .dylib in the same directory, Xcode will link in the .dylib even if you've explicitly added the .a to your "Link with ..." in the build phases of your project. If you look in the build log, you will see that the linker cmd line that Xcode generates for (say) libFoo.a is something like:

ld .... -lFoo ....

with the result that you (& I) have found. I tried adding various linker-extra flags to force it to use the .a, but in the end, I gave up and put the .a and .dylibs in separate directories (and changed the library search paths as needed).
In the Other Linker Flags build setting, you can add the full path to a library instead of something like -lFoo, ensuring that you get the right one.








Ensure Framework Links to static lib not dylib

Jonathan Prescott
 



Begin forwarded message:

From: Jonathan Prescott <jprescott12@...>
Subject: Re: [cocoa-dev] Ensure Framework Links to static lib not dylib
Date: December 10, 2020 at 1:50:14 PM EST

Put the “Other Linker Flags” variable (OTHER_LDFLAGS) in an .xcconfig file, if I understand what you mean by “a process that does this automatically”.  
Jonathan

On Dec 10, 2020, at 1:31 PM, Alex Zavatone via groups.io <zav@...> wrote:

If we have more than one of us manually adding .a, there probably must be a process that does this automatically that we don’t know about.

Any ideas?

On Dec 10, 2020, at 12:15 PM, James Walker <list2@...> wrote:



On Dec 10, 2020, at 9:18 AM, Sak Wathanasin <sw@...> wrote:



On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@...> wrote:

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project


I fell over this the other day. If you have both the .a and .dylib in the same directory, Xcode will link in the .dylib even if you've explicitly added the .a to your "Link with ..." in the build phases of your project. If you look in the build log, you will see that the linker cmd line that Xcode generates for (say) libFoo.a  is something like:

ld .... -lFoo ....

with the result that you (& I) have found. I tried adding various linker-extra flags to force it to use the .a, but in the end, I gave up and put the .a and .dylibs in separate directories (and changed the library search paths as needed).

In the Other Linker Flags build setting, you can add the full path to a library instead of something like -lFoo, ensuring that you get the right one.










Re: Ensure Framework Links to static lib not dylib

Alex Zavatone
 

If we have more than one of us manually adding .a, there probably must be a process that does this automatically that we don’t know about.

Any ideas?

On Dec 10, 2020, at 12:15 PM, James Walker <list2@jwwalker.com> wrote:



On Dec 10, 2020, at 9:18 AM, Sak Wathanasin <sw@network-analysis.ltd.uk> wrote:



On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
I fell over this the other day. If you have both the .a and .dylib in the same directory, Xcode will link in the .dylib even if you've explicitly added the .a to your "Link with ..." in the build phases of your project. If you look in the build log, you will see that the linker cmd line that Xcode generates for (say) libFoo.a is something like:

ld .... -lFoo ....

with the result that you (& I) have found. I tried adding various linker-extra flags to force it to use the .a, but in the end, I gave up and put the .a and .dylibs in separate directories (and changed the library search paths as needed).
In the Other Linker Flags build setting, you can add the full path to a library instead of something like -lFoo, ensuring that you get the right one.




Re: Ensure Framework Links to static lib not dylib

James Walker
 

On Dec 10, 2020, at 9:18 AM, Sak Wathanasin <sw@network-analysis.ltd.uk> wrote:



On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project
I fell over this the other day. If you have both the .a and .dylib in the same directory, Xcode will link in the .dylib even if you've explicitly added the .a to your "Link with ..." in the build phases of your project. If you look in the build log, you will see that the linker cmd line that Xcode generates for (say) libFoo.a is something like:

ld .... -lFoo ....

with the result that you (& I) have found. I tried adding various linker-extra flags to force it to use the .a, but in the end, I gave up and put the .a and .dylibs in separate directories (and changed the library search paths as needed).
In the Other Linker Flags build setting, you can add the full path to a library instead of something like -lFoo, ensuring that you get the right one.


Re: Ensure Framework Links to static lib not dylib

Sak Wathanasin
 



On 10 Dec 2020, at 15:32, Sandor Szatmari <admin.szatmari.net@...> wrote:

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project


I fell over this the other day. If you have both the .a and .dylib in the same directory, Xcode will link in the .dylib even if you've explicitly added the .a to your "Link with ..." in the build phases of your project. If you look in the build log, you will see that the linker cmd line that Xcode generates for (say) libFoo.a  is something like:

ld .... -lFoo ....

with the result that you (& I) have found. I tried adding various linker-extra flags to force it to use the .a, but in the end, I gave up and put the .a and .dylibs in separate directories (and changed the library search paths as needed).

Regards
Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


Ensure Framework Links to static lib not dylib

Sandor Szatmari
 

I have a Framework and am adding support to it from code located in an external library.

I have added the ‘.a’ version of the lib to the project (build phase link to…) I dragged it to the project navigator and added to appropriate target

I have added include and search paths in target’s build settings

Note: Both the ‘.a’ and dylib versions for the external resource are located in /usr/local/lib

Everything builds and runs fine either in xcode or launched from outside xcode on the dev machine

However, when I deploy the Framework to a non-dev machine it complains about the dylib not being present???

This surprised me because I specifically added the ‘.a’ (static) lib to the xcode project

Am I ‘doing it wrong’? How do I ensure the xcode target links my Framework to the static lib and not the dylib?

Thanks in advance,
Sandor


Re: Many new warnings after Xcode upgrade

Alex Zavatone
 

On Oct 29, 2020, at 7:16 PM, Quincey Morris <quinceymorris@rivergatesoftware.com> wrote:

I don’t have any special insights, but I think the warning is correct in that there has for some time been an (unwritten?) rule that the #imports *inside* a framework header should use angle brackets — for self-preservation.

Again with no special knowledge, that makes sense to me because imports with double-quotes will search the framework *client’s* include paths first, and that’s almost certainly wrong if there are any symbol conflicts with what’s defined in the framework.

That makes perfect sense. Is the header the umbrella header for the framework? Is so, then the < > brackets would make more sense since they would restrict searching for headers inside the framework (if I understand this correctly.)

In that case, I’d expect just replacing the quotes with < > and rebuilding may be just what is needed.

Cheers.

Alex Zavatone


Re: Many new warnings after Xcode upgrade

Quincey Morris
 

I don’t have any special insights, but I think the warning is correct in that there has for some time been an (unwritten?) rule that the #imports *inside* a framework header should use angle brackets — for self-preservation.

Again with no special knowledge, that makes sense to me because imports with double-quotes will search the framework *client’s* include paths first, and that’s almost certainly wrong if there are any symbol conflicts with what’s defined in the framework.

OTOH, it’s hard to predict the effect of “fixing” the bracketing, because Xcode’s behavior here is somewhat inscrutable.

All that said, my suggestion is as follows:

1. Commit your project as-is to the repository.

2. Apply all the “Double-quoted include …” warning fixits automatically.

3. Build and run the project.

If that works, don’t lose any sleep. If something blows up, discard changes and silence the warnings, and don’t lose any sleep. :)

On Oct 29, 2020, at 05:45 , Jim Adams via groups.io <jim.adams@...> wrote:

I was wondering about that myself. I have header files that are internal to the framework so shouldn’t be public.
 
From: <cocoa@apple-dev.groups.io> on behalf of "Graham Cox via groups.io" <graham@...>
Reply-To: "cocoa@apple-dev.groups.io" <cocoa@apple-dev.groups.io>
Date: Wednesday, October 28, 2020 at 8:02 PM
To: "cocoa@apple-dev.groups.io" <cocoa@apple-dev.groups.io>
Subject: [cocoa-dev] Many new warnings after Xcode upgrade
 
EXTERNAL
I just updated to XCode 12.1, and my project is throwing a lot of new warnings about “double-quoted include in framework header”. This appears to be because of the build setting “Quoted include in Framework Header”, which is now a recommended setting. 
 
I can turn that off again, but what is this treally trying to tell me? These warnings appear to be bogus, in that yes, I’m building several frameworks as part of my workspace, but surely the files within those framework sources should be simple double quotes, not refer to the framework headers - after all, it’s the framework I’m building!
 
I’m confused, but perhaps it’s because my project structure is incorrect. But I don’t want to go and change a whole bunch of stuff before I properly understand what should be done here.
 
Example errors in the output — note, this framework is one I just use “as is”, I’m not even building it (Sparkle).
 
<image001.png>
 
—Graham
 
 



Re: Many new warnings after Xcode upgrade

Jim Adams
 

I was wondering about that myself. I have header files that are internal to the framework so shouldn’t be public.

 

From: <cocoa@apple-dev.groups.io> on behalf of "Graham Cox via groups.io" <graham@...>
Reply-To: "cocoa@apple-dev.groups.io" <cocoa@apple-dev.groups.io>
Date: Wednesday, October 28, 2020 at 8:02 PM
To: "cocoa@apple-dev.groups.io" <cocoa@apple-dev.groups.io>
Subject: [cocoa-dev] Many new warnings after Xcode upgrade

 

EXTERNAL

I just updated to XCode 12.1, and my project is throwing a lot of new warnings about “double-quoted include in framework header”. This appears to be because of the build setting “Quoted include in Framework Header”, which is now a recommended setting.

 

I can turn that off again, but what is this treally trying to tell me? These warnings appear to be bogus, in that yes, I’m building several frameworks as part of my workspace, but surely the files within those framework sources should be simple double quotes, not refer to the framework headers - after all, it’s the framework I’m building!

 

I’m confused, but perhaps it’s because my project structure is incorrect. But I don’t want to go and change a whole bunch of stuff before I properly understand what should be done here.

 

Example errors in the output — note, this framework is one I just use “as is”, I’m not even building it (Sparkle).

 

 

—Graham

 

 


Re: Many new warnings after Xcode upgrade

Alex Zavatone
 

I’d check to see why it expects < > angle brackets but it seems as if you’ve done all the research.

This seems to point in the right direction.


There are several links on that page that point to cases where people have resolved this.

Cheers,
Alex Zavatone

On Oct 28, 2020, at 7:01 PM, Graham Cox <graham@...> wrote:

I just updated to XCode 12.1, and my project is throwing a lot of new warnings about “double-quoted include in framework header”. This appears to be because of the build setting “Quoted include in Framework Header”, which is now a recommended setting.

I can turn that off again, but what is this treally trying to tell me? These warnings appear to be bogus, in that yes, I’m building several frameworks as part of my workspace, but surely the files within those framework sources should be simple double quotes, not refer to the framework headers - after all, it’s the framework I’m building!

I’m confused, but perhaps it’s because my project structure is incorrect. But I don’t want to go and change a whole bunch of stuff before I properly understand what should be done here.

Example errors in the output — note, this framework is one I just use “as is”, I’m not even building it (Sparkle).

<Screen Shot 2020-10-29 at 10.53.51 am.png>

—Graham




Many new warnings after Xcode upgrade

Graham Cox
 

I just updated to XCode 12.1, and my project is throwing a lot of new warnings about “double-quoted include in framework header”. This appears to be because of the build setting “Quoted include in Framework Header”, which is now a recommended setting.

I can turn that off again, but what is this treally trying to tell me? These warnings appear to be bogus, in that yes, I’m building several frameworks as part of my workspace, but surely the files within those framework sources should be simple double quotes, not refer to the framework headers - after all, it’s the framework I’m building!

I’m confused, but perhaps it’s because my project structure is incorrect. But I don’t want to go and change a whole bunch of stuff before I properly understand what should be done here.

Example errors in the output — note, this framework is one I just use “as is”, I’m not even building it (Sparkle).


—Graham



Re: Document versions browser shows windows in wrong stacking order/position

Steve Mills
 

On Oct 19, 2020, at 14:26:32, Steve Mills via groups.io <sjmills=mac.com@groups.io> wrote:

I'm trying to figure out why the versions browser is doing this weird thing with my windows. A video is linked below. The top-left corner of each window contains a timestamp for when the window gets created and the mod date of the actual file the document reads from. Notice how it ends up showing the oldest document on top after it loads all the version windows. Then as I go back through the versions, it keeps that oldest one on top. Then it starts showing the correct timestamps as I come back forward through versions. Any idea what I might be doing wrong? I'm letting NSDocument do nearly everything, and having changed any properties on the window that would screw this up.

https://www.armpitstudios.com/av/ScreenRecordingVersionsBrowserHorked.mov
Turning off "Allow debugging during browsing versions" helps this work like it should, but still not perfectly. The windows tend to appear in the right order and location, but their rendering is still out of whack. I can't tell if "Enable user interface debugging" also makes a difference.

--
Steve Mills
Drummer, Mac geek


Document versions browser shows windows in wrong stacking order/position

Steve Mills
 

I'm trying to figure out why the versions browser is doing this weird thing with my windows. A video is linked below. The top-left corner of each window contains a timestamp for when the window gets created and the mod date of the actual file the document reads from. Notice how it ends up showing the oldest document on top after it loads all the version windows. Then as I go back through the versions, it keeps that oldest one on top. Then it starts showing the correct timestamps as I come back forward through versions. Any idea what I might be doing wrong? I'm letting NSDocument do nearly everything, and having changed any properties on the window that would screw this up.

https://www.armpitstudios.com/av/ScreenRecordingVersionsBrowserHorked.mov

--
Steve Mills
Drummer, Mac geek


Re: iCloud question: CloudKit vs. NSFileManager

Leo
 

Ok perfect - thanks Jens - that's exactly what I needed to know.

Leo


Re: iCloud question: CloudKit vs. NSFileManager

 



On Oct 12, 2020, at 10:19 PM, Leo <leo.r@...> wrote:

As far as I understand, there are two ways to implement iCloud: CloudKit and NSFileManager iCloud methods.

I would use NSFileManager. CloudKit is for storing a server-side database that supports queries, indexes and sharing … that's overkill for a simple settings file.

Also, I believe if you use the NSFileManager API the user will be able to see the settings file in the Files app (or the Finder), which could be convenient.

—Jens

101 - 120 of 1423