Menu item "Save..." should be "Save"

[vdhamer]

"Save..." by convention the 3 dots indicates a menu or more options follow, including the option of canceling. So this menu item probably should be labelled "Save" as long as there is no dialog box of some sort.

Minor detail. Thanks for the work you put into this app. Really appreciate it. Worth me making a review?

[Mini-Stef]

Hello again vdhamer, I'll solve this "..." at the same time as the other issue, that should be fairly simple :-) And yes, I'll appreciate if you do a review. Thanks a lot, Stef

[vdhamer]

Hi Stéfane,

I have a first draft review that is predominantly positive. But a) I want to make the text clearer. Review can be made stronger. b) I want to give you time to comment on the tickets. (“Comment on”, not trying to blackmail you to provide a “fix”)

Main points are: It is solid. And IMHO underpriced. (Although my app is open source) Only major concern: not being able to edit in both Xcode and in CDME. Round-trip editing gives issues. See both tickets. Right now I have to stick to one of the two for editing. Essentially I have to choose between losing constraints (and maybe more?) or losing control over layout coordinates. Tip: You may want to puzzle whether you want to expand to SwiftData in say a year or so: the market for CoreData tooling will shrink, and having a longer term goals to cover SwiftData gives CDME a target and a future - if that is worth your time.

Minor: colours are not saved, colours are not well chosen (think you simply didn’t finish what you were planning to do).

Made quick use of your tool earlier today: https://github.com/vdhamer/Photo-Club-Hub#the-data-model

Peter van den Hamer (in The Netherlands)

On 12 Jan 2024, at 17:50, Mini-Stef @.***> wrote:

Hello again vdhamer, I'll solve this "..." at the same time as the other issue, that should be fairly simple :-) And yes, I'll appreciate if you do a review. Thanks a lot, Stef

— Reply to this email directly, view it on GitHub https://github.com/Mini-Stef/Core-Data-Model-Editor/issues/2#issuecomment-1889637074, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGGUWDE4LKIPUFTJ5S5IALYOFSWBAVCNFSM6AAAAABBXLNMNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBZGYZTOMBXGQ. You are receiving this because you authored the thread.

[vdhamer]

I posted the review on the App Store. Don't see it myself yet. Text:

This MacOS app is roughly equivalent to the graphical editor for CoreData models that was included in Xcode until Sep 2022. And is a superset of the non-graphical editor that is provided in Xcode 14+. Each of these can be used for building MacOS, iOS, WatchOS, and VisionOS apps that use CoreData. Both Xcode and this App assume that you know CoreData or at least the CoreData features that you need: the app certainly doesn’t try to teach you what every model option does (but the same holds for Xcode’s editor). Strong points of this app is that it is lightweight and robust. And can tweak the layout of entities any way you like (and even give them colours, although that feature looks unfinished).

I started a discussion with the author (via Github) on the app’s interoperability with the existing non-graphical editor in Xcode itself. You should obviously be able to take an existing .xcdatamodeld file (made in Xcode) and edit it in this app (tip: via “Open with External Editor”) - without losing any model data. This is also the intention of the app. But in the reviewed version 1.1.1, any existing uniqueness “Constraints" are lost if you read the XML file through this app. Not everyone uses Constraints though. The author confirmed that this a bug, and it should be fixed soon.

In a related point, beware that the .xcdatamodel files that the app currently Saves are different from the Xcode files that it can read. Although both conform to the same syntax and XML schema. This is possible because XML files can serialise hierarchical data in alternative but equivalent orders. I care about such an obscure-sounding point for two reasons: 1) I failed when I tried to validate the app by doing a diff between the Xcode input file and the App’s output - the differences are so significant that normal diff tools choke on it. 2) Every time you switch editors between Xcode and this App, your version control system (usually git) will get confused. Again, the author is looking into what is feasible to reduce the differences to an acceptable level. But note that this is NOT a bug.

All in all, initial impressions of the app and its support are positive. For the long run, I hope that it will someday also cover SwiftData (given that SwiftData is said to be a layer on top of CoreData). I don’t know whether there are plans for this. It probably depends on the author’s own plans for adopting SwiftData in his own projects.