Re: Creating NSTableView programmatically
Re: Creating NSTableView programmatically
- Subject: Re: Creating NSTableView programmatically
- From: Quincey Morris <email@hidden>
- Date: Wed, 20 Dec 2017 02:23:21 -0800
On Dec 20, 2017, at 01:23 , Eric Matecki <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden