1. cocoa@apple-dev.groups.io
  2. Messages
   Date   
CoreData Migration for ClouidKit

Rick Aurbach
 

I am upgrading an existing (CoreData-based) iOS app to support CloudKit synchronization. This doesn't work because the app includes an ORDERED relationship.
 
I need to perform a migration from this ordered relationship to something else that supports both CloudKit and maintains ordering. 
 
The problem is less about WHAT I need to do to support my requirements as it is HOW to perform the migration (so that my existing customers don't lose data.) Have you encountered this problem? How did you solve it?
 
Re: Interface Builder Strangeness

Steve Mills
 

On Feb 20, 2023, at 03:50, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Thanks for the suggestions. I tried to look at the files in FileMerge - but it choked on them.
I then tried to open as source - and my Xcode didn’t have that as a menu option. The menu did however have an option to export as XIB ( the file was a NIB ) which I did. This export as XIB has fixed the problem !

All my files are NIBs - should they be XIBs ? I can’t find an explanation anywhere about the difference.
Yes, they should be xib. xib = XML (or Xcode) Interface Builder. nib = NeXT Interface Builder, a term that has its roots stretch far back to NeXT, hence the name. These days xib is the file you create in Xcode, and nib is the file Xcode generates as the final file in the output.

--
Steve Mills
Drummer, Mac geek
Re: Interface Builder Strangeness

Alex Zavatone
 

I think you can open the nib in a text editor.

On Feb 20, 2023, at 3:50 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Hi Jack

Thanks for the suggestions. I tried to look at the files in FileMerge - but it choked on them.
I then tried to open as source - and my Xcode didn’t have that as a menu option. The menu did however have an option to export as XIB ( the file was a NIB ) which I did. This export as XIB has fixed the problem !

All my files are NIBs - should they be XIBs ? I can’t find an explanation anywhere about the difference.

All the best

Peter



On 20 Feb 2023, at 05:15, Jack Brindle via groups.io <jackbrindle@...> wrote:

If you have a copy of the xib file before the changes were made, open it as a text file, and compare it to the version with the changes.
To open as source, right click on the xib in the Project source area, the select Open As… -> Source Code.
You can also compare the two files using a diff tool such as Xcode’s FileMerge. If you find that the files are indeed different, then you need to look for a different solution.
Perhaps there might be two xib files that are very similar, and you are not editing the one you think you are editing? This is very easy to do, and had bitten most of us.

The only real issue I have seen in IB over the past few years involves multiple NSTableViews in an NSView. They have a real problem with keeping their size, even when
the constraints are properly set.

Good luck with this one. This is the kind of problem that drives all of us up the wall.

Jack

On Feb 19, 2023, at 5:04 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Hi All

I have made some changes in a nib file in my application.
I deleted a box with some buttons etc in it and moved a few buttons around in a tab view.
The nib saves fine - when I open the nib up outside the project, my edits are all there.

When I build and run the application, what I get onscreen is the original pre-edited interface.

?

I’ve tried doing a clean build, dropped the nib into another project etc...

Any suggestions gratefully received !

All the best

Peter


macOS Monterey 12.6.3, Xcode 13.2
Re: Interface Builder Strangeness

Alex Zavatone
 

I’ve seen strangeness with the IB in that changes in IB aren’t compiled into the app until after the next 2 builds. I’d clear the build folder, quit and restart Xcode and see if that fixes it.

On Feb 19, 2023, at 5:04 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Hi All

I have made some changes in a nib file in my application.
I deleted a box with some buttons etc in it and moved a few buttons around in a tab view.
The nib saves fine - when I open the nib up outside the project, my edits are all there.

When I build and run the application, what I get onscreen is the original pre-edited interface.

?

I’ve tried doing a clean build, dropped the nib into another project etc...

Any suggestions gratefully received !

All the best

Peter


macOS Monterey 12.6.3, Xcode 13.2
Re: Interface Builder Strangeness

Peter Hudson
 

Hi Jack

Thanks for the suggestions. I tried to look at the files in FileMerge - but it choked on them.
I then tried to open as source - and my Xcode didn’t have that as a menu option. The menu did however have an option to export as XIB ( the file was a NIB ) which I did. This export as XIB has fixed the problem !

All my files are NIBs - should they be XIBs ? I can’t find an explanation anywhere about the difference.

All the best

Peter

On 20 Feb 2023, at 05:15, Jack Brindle via groups.io <jackbrindle@...> wrote:

If you have a copy of the xib file before the changes were made, open it as a text file, and compare it to the version with the changes.
To open as source, right click on the xib in the Project source area, the select Open As… -> Source Code.
You can also compare the two files using a diff tool such as Xcode’s FileMerge. If you find that the files are indeed different, then you need to look for a different solution.
Perhaps there might be two xib files that are very similar, and you are not editing the one you think you are editing? This is very easy to do, and had bitten most of us.

The only real issue I have seen in IB over the past few years involves multiple NSTableViews in an NSView. They have a real problem with keeping their size, even when
the constraints are properly set.

Good luck with this one. This is the kind of problem that drives all of us up the wall.

Jack

On Feb 19, 2023, at 5:04 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Hi All

I have made some changes in a nib file in my application.
I deleted a box with some buttons etc in it and moved a few buttons around in a tab view.
The nib saves fine - when I open the nib up outside the project, my edits are all there.

When I build and run the application, what I get onscreen is the original pre-edited interface.

?

I’ve tried doing a clean build, dropped the nib into another project etc...

Any suggestions gratefully received !

All the best

Peter


macOS Monterey 12.6.3, Xcode 13.2
Re: Interface Builder Strangeness

Jack Brindle
 

If you have a copy of the xib file before the changes were made, open it as a text file, and compare it to the version with the changes.
To open as source, right click on the xib in the Project source area, the select Open As… -> Source Code.
You can also compare the two files using a diff tool such as Xcode’s FileMerge. If you find that the files are indeed different, then you need to look for a different solution.
Perhaps there might be two xib files that are very similar, and you are not editing the one you think you are editing? This is very easy to do, and had bitten most of us.

The only real issue I have seen in IB over the past few years involves multiple NSTableViews in an NSView. They have a real problem with keeping their size, even when
the constraints are properly set.

Good luck with this one. This is the kind of problem that drives all of us up the wall.

Jack

On Feb 19, 2023, at 5:04 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Hi All

I have made some changes in a nib file in my application.
I deleted a box with some buttons etc in it and moved a few buttons around in a tab view.
The nib saves fine - when I open the nib up outside the project, my edits are all there.

When I build and run the application, what I get onscreen is the original pre-edited interface.

?

I’ve tried doing a clean build, dropped the nib into another project etc...

Any suggestions gratefully received !

All the best

Peter


macOS Monterey 12.6.3, Xcode 13.2
Re: Interface Builder Strangeness

Rick Aurbach
 

I've seen some weird behavior with Interface Builder in Xcode 13.2. Originally, it forced me to drop back to 13.1. However, I've recently tried the 13.3 beta download and it appears to work better. I'd suggest trying 13.3 beta and see if it helps.
Interface Builder Strangeness

Peter Hudson
 

Hi All

I have made some changes in a nib file in my application.
I deleted a box with some buttons etc in it and moved a few buttons around in a tab view.
The nib saves fine - when I open the nib up outside the project, my edits are all there.

When I build and run the application, what I get onscreen is the original pre-edited interface.

?

I’ve tried doing a clean build, dropped the nib into another project etc...

Any suggestions gratefully received !

All the best

Peter


macOS Monterey 12.6.3, Xcode 13.2
Re: Rust for Cocoa/XCode

Chris Ridd
 



On 19 Jan 2023, at 02:03, Jens Alfke <jens@...> wrote:



On Jan 17, 2023, at 2:43 AM, Dave <dave@...> wrote:

Does anyone know if there is a version of Rust that works with XCode and/or Cocoa?

There’s only one ‘version’ of Rust I know of, i.e. the official one.
By “works with Xcode” do you mean “does Xcode have a Rust compiler?” ⟶ No. If you want to work with Rust on a Mac, you’ll need to install the Rust dev tools from the official site, then either use them from the command line or via an IDE that does have support for Rust, like VS Code.
By “works with Cocoa” do you mean “is there a Rust library that binds the Cocoa APIs?” ⟶ No idea, but you’d need to look for a library, not something built into Rust.

There is a rust crate which adds Cocoa bindings. See https://crates.io/crates/cocoa

I’ve never tried it, but I’m sure they’d welcome fixes if you found anything wrong. https://github.com/servo/core-foundation-rs

Chris
Re: Retrieve all available Finder tags on Monterey and later

storewheels@...
 

Perhaps the updated list is cached and not written immediately to the file you are looking at.
 
Databases can do that.
 
Re: Rust for Cocoa/XCode

Jens Alfke
 



On Jan 17, 2023, at 2:43 AM, Dave <dave@...> wrote:

Does anyone know if there is a version of Rust that works with XCode and/or Cocoa?

There’s only one ‘version’ of Rust I know of, i.e. the official one.
By “works with Xcode” do you mean “does Xcode have a Rust compiler?” ⟶ No. If you want to work with Rust on a Mac, you’ll need to install the Rust dev tools from the official site, then either use them from the command line or via an IDE that does have support for Rust, like VS Code.
By “works with Cocoa” do you mean “is there a Rust library that binds the Cocoa APIs?” ⟶ No idea, but you’d need to look for a library, not something built into Rust.

—Jens
Re: Retrieve all available Finder tags on Monterey and later

storewheels@...
 

Perhaps the updated list is cached and not written immediately to the file you are looking at.

Databases can do that.



On Jan 15, 2023, at 9:12 PM, Leo <var@...> wrote:

[Edited Message Follows]

On Sun, Jan 15, 2023 at 02:42 PM, James Walker wrote:
sqlite3 ~/Library/SyncedPreferences/com.apple.kvs/com.apple.KeyValueService-Production.sqlite "SELECT writefile('path/to//tags.plist', ZPLISTDATAVALUE) FROM ZSYDMANAGEDKEYVALUE WHERE ZKEY = 'FinderTagDict';"

Fantastic! This works as expected. Thanks James - and Thomas, once again!
 
I'll also update the Stackoverflow question soon.
 
 
P.S.
 
What's interesting is that after evaluating the plist data, I found that it still does NOT provide the full list of available Finder tags.

EDIT: The conclusions about 14 tag limit below turned to be incorrect, however there still can be a discrepancy of unknown nature between this plist and the actual list of tags in the Finder.
 
The limitations are:
 
-Custom tags that have never been applied are not listed,
 
AND
 
-Only maximum of 14 tags are listed (that is, 7 standard tags + max of 7 custom tags).
 
Additional custom tags will not be listed whether they're applied or not.
 
 
For what it's worth, the pre-Monterey file also had a limitation of maximum of 11 tags listed no matter what.
 
 
Obviously, it's not critical and doesn't really affect the user experience in real world. I don't believe it's common for users to create as many as 7 custom tags - let alone more than that. So the found solution is perfect as it is. Therefore, the question of where the complete list of tags is stored isn't that important anymore - but still remains...
Re: Retrieve all available Finder tags on Monterey and later

Leo
 

On Sat, Jan 14, 2023 at 04:17 AM, Thomas Tempelmann wrote:
Oh, and out of courtesy to us all, please add an answer to the SO question once you've got working code: https://stackoverflow.com/q/41779969/43615
 
When I post the answer on SO (and couple other forums where this question was asked), I'd like to give credit to Thomas Tempelmann and  James Walker for the solution. However, if you object to mentioning your names, please let me know!
Rust for Cocoa/XCode

Dave
 

Hi All,

Does anyone know if there is a version of Rust that works with XCode and/or Cocoa?

All the Best
Dave
Re: Retrieve all available Finder tags on Monterey and later

Leo
 

On Mon, Jan 16, 2023 at 08:44 AM, James Walker wrote:
I added some new tags, never applied to anything, and when I opened the plist, the new tags were there, making a total of 15 tags.

Ha. I added a new tag - and indeed the plist file now contains 17 tags. 

However, I have 21 tags defined in the Finder.

So I'm not sure what it all means - but there definitely can be a discrepancy between this plist and the actual list of Tags in the Finder.
Re: Retrieve all available Finder tags on Monterey and later

James Walker
 

On Jan 15, 2023, at 9:12 PM, Leo <var@...> wrote:

What's interesting is that after evaluating the plist data, I found that it still does NOT provide the full list of available Finder tags.

The limitations are:

-Custom tags that have never been applied are not listed,

AND

-Only maximum of 14 tags are listed (that is, 7 standard tags + max of 7 custom tags).

Additional custom tags will not be listed whether they're applied or not.
I added some new tags, never applied to anything, and when I opened the plist, the new tags were there, making a total of 15 tags.
Re: Retrieve all available Finder tags on Monterey and later

Alex Zavatone
 

Yes, but why is this needed for Finder tags? Isn’t it massive massive overkill when a plist will do?

On Jan 16, 2023, at 10:09 AM, Ben Kennedy <ben-groups@...> wrote:

On Jan 16, 2023, at 10:43 AM, Alex Zavatone via groups.io <zav@...> wrote:

Why the hell Apple feels the need to store Finder tags in an SQL database is beyond me.

Is there a valid rationale behind this?
It’s a Core Data backing store.

-ben
Re: Retrieve all available Finder tags on Monterey and later

Sandor Szatmari
 

Alex

On Jan 16, 2023, at 11:09, Ben Kennedy <ben-groups@...> wrote:

On Jan 16, 2023, at 10:43 AM, Alex Zavatone via groups.io <zav@...> wrote:

Why the hell Apple feels the need to store Finder tags in an SQL database is beyond me.
Especially when the limit is 14 items…


Is there a valid rationale behind this?
It made sense to someone… consistency for API consolidation?

Sandor


It’s a Core Data backing store.

-ben
Re: Retrieve all available Finder tags on Monterey and later

Ben Kennedy
 

On Jan 16, 2023, at 10:43 AM, Alex Zavatone via groups.io <zav@...> wrote:

Why the hell Apple feels the need to store Finder tags in an SQL database is beyond me.

Is there a valid rationale behind this?
It’s a Core Data backing store.

-ben
Re: Retrieve all available Finder tags on Monterey and later

Alex Zavatone
 

Why the hell Apple feels the need to store Finder tags in an SQL database is beyond me.

Is there a valid rationale behind this?

On Jan 15, 2023, at 4:42 PM, James Walker <list2@...> wrote:



On Jan 15, 2023, at 1:22 AM, Leo <var@...> wrote:

ok I'm able to retrieve the data via:

sqlite3 ~/Library/SyncedPreferences/com.apple.kvs/com.apple.KeyValueService-Production.sqlite 'SELECT ZKEY, ZPLISTDATAVALUE FROM ZSYDMANAGEDKEYVALUE WHERE ZKEY = "FinderTagDict";'

which returns this thing (which is identical to what I see in DB Browser for SQLite, as far as I understand):
...
But for the life of me I couldn't convert this bplist stuff into anything useful no matter what I tried (plutil, NSPropertyListSerialization, NSKeyedUnarchiver, various conversion between NSString-NSData-NSDictionary etc.)
I looked around for information on extracting binary data from an SQLite database, and found this:

<https://stackoverflow.com/questions/15448373/how-to-dump-a-file-stored-in-a-sqlite-database-as-a-blob>

What I came up with was

sqlite3 ~/Library/SyncedPreferences/com.apple.kvs/com.apple.KeyValueService-Production.sqlite "SELECT writefile('path/to//tags.plist', ZPLISTDATAVALUE) FROM ZSYDMANAGEDKEYVALUE WHERE ZKEY = 'FinderTagDict';"

and it produced a plist file that Xcode was able to open.
1 - 20 of 1524