On Dec 20, 2017, at 01:23 , Eric Matecki <eml...@wanadoo.fr> wrote: > > The sole purpose of my project is to learn how bindings works, it has no > practical application per se.
Bindings exist to support the use of NIB-based UI behavior. All bindings work the same way, in the sense that they tie together the values of properties in each of two objects, so that a change in one appears as a change in the other, in either direction. This sort of equivalent to mutual KVO-observation with mutual updating, except that only the property in the target object (the one bound *to*) is actually a property in the KVC sense. The “property” in the source object (the one bound *from*) is a notional identifier that may or may not correspond to a true property of the object. For example, when binding the content of a NSTextView, you bind the “value” binding to a NSString property of some other object. There is no “value” property, the binding name is meaningful only as a binding name. That means that all of the binding names have to be documented somewhere, and that happens to be the Cocoa Bindings Reference document, which is a long list of classes and the bindings that have been defined to exist in each. That tells you what any given binding is for (provided you can understand what the documentation says, which is more of a problem than it ought to be), but it doesn’t tell you when you should use the binding. That you kinda figure out by trial and error. You can figure out when you need to use the NSTextView “value” binding, for example, and you can probably figure out the font and point size bindings, but go look at the bindings for NSPopUpButton and you’re gonna be scratching your head. > I wonder how IB manages conflicts when merging your code back to the main > branch Ever since version <mumble mumble> of Xcode, IB manages this by using a XIB file as the source code of a compiled NIB file, and a XIB file is text in some kind of XML format. That means it can be diff’ed and merged, hence managed via source control. You can see this yourself by switching the assistant editor to show the version history, and the main view will switch from a graphic canvas to a long, long text description. > The original code used all the same three array controllers, with the exact > same subclassing of the target's one. This is where I take the fifth. When bindings were introduced, back in 10.3 or 10.4, then refined in 10.5, it looked very much like Apple was trying to sell a sort of data-manipulation “language” constructed out of bindings and NS…Controller classes. While this worked great for pushing glue code out of .m source files and into .nib files (this predated .xib files), it’s was too general, too inscrutable and too clumsy to have much wider appeal. In effect, the whole thing with bindings died at 10.5, except for the part where they were used within IB to hook up specific controls to specific properties. That part is really all we use today. This particular sample app comes from about the 10.4 era, ideologically if not actually. It illustrates how to do things no one really wanted to do after about 2005. Your current project is archeology, not development. > In the sample I have, I can't find any binding involving "selectionIndexes", > neither in the code nor in the NIB. > It still works without them. > Or, more precisely, without them being *explicitly* bound somewhere, and > that's the kind of magic I hate. Well, it’s not quite magic, but nearly. This *isn’t* documented anywhere, or (if it was) it was documented in an old version of the Table View Programming Guide that no longer exists. In a NSCell-based table view (the only kind at the time this sample app was written), when you bind table columns to a property of an array controller, something (the table view? the NIB-loading mechanism? IDK exactly) notices that the table view is missing its “content” binding and binds it to the array controller. Then it also binds the “selectionIndexes” binding. Most people don’t explicitly know that, because it just works and so they don’t have to think about it. It’s only when something is arranged differently (like using a table view without an array controller, or … what you’re doing) that anyone notices. This is one reason why we generally use XIB/NIB files instead of code — it allows us to let IB to worry about the magic, so we don’t have to. (FWIW, stuff like this is one reason why IB is huge, slow and buggy. Every tiny detail of every old NIB behavior in every macOS version has to be religiously preserved in IB.) > @property(readonly, copy) NSIndexSet *selectionIndexes; > So I can change a readonly property thru bindings ? It’s … um … not readonly. But the setter method looks like this: > - (BOOL)setSelectionIndexes:(NSIndexSet *)indexes; which is to say, it’s not exactly a setter because it returns a value. If, however, you squint and ignore the return value, it works just fine as a setter, making the property effectively readwrite, but not fitting the @property(readwrite…) pattern due to backward source compatibility requirements. Before you start sticking forks in your eyeballs, keep in mind that these APIs date from Obj-C version 1 days, when there were no formal properties, and no @property or dot syntax. Back then developers used to shape code with raw, meaty mastodon bones. > it explicitly states KV-observable, not KV-coding compliant It’s the same thing. “KVO-compliant” is the modern term, meaning the same as “observable using key-value observing”, and everything KVO-compliant is necessarily KVC-compliant. All of this (and there’s more: try figuring out placeholders and markers in bindings, for example) is why people are horrified when you try to do this kind of project. It’s a noble cause in one sense, but an utter waste of effort in another. _______________________________________________ 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
