Binding NSTableView Column Headers vs Cells (was: Bindings & NSTableView: setting cell as 'editable'...)
Binding NSTableView Column Headers vs Cells (was: Bindings & NSTableView: setting cell as 'editable'...)
- Subject: Binding NSTableView Column Headers vs Cells (was: Bindings & NSTableView: setting cell as 'editable'...)
- From: Tim Lucas <email@hidden>
- Date: Thu, 2 Jun 2005 17:29:11 +1000
To the Cocoa Framework Developers, spurred by this post and many many
others:
On 02/06/2005, at 2:49 PM, Andrew White wrote:
Update: tested things out. Turns out that the column as a whole needs
to be set editable, at which point the editable / non-editable
settings of the cells flow through.
I see people (including myself) unintentionally doing this (binding to
cell instead of tablecolumn) *all the time*. Surely there's a better
way to do this?
What is the "value" of the tablecolumn? Surely we should be dealing
with the "value" of the cells, not the column?
I know that the cells are unaware of the tablecolumn they belong to, so
to implement this it would be a bit tricker than just overriding the
bind: call in the cell and setting up the tablecolumn+tableview
bindings, but surely IB could be a bit smarter about this stuff.
You've already had to get the "value" bindings of the cell to propagate
down into the bindings panel for the tablecolumn to make it
semi-logical, why not go the whole hog and make it completely logical
by putting a bit more thought into the UI? If refuse to change, then
why have the cell's "value" bindings appear in the cell's bindings
panel at all?
Another problem of the current UI is that is suggests for one tableview
you can bind tablecolumns to different arraycontrollers. IB doesn't
even give you an error or warning... it just fails at runtime.
This "magic" that everybody speaks of in terms of setting up tableview
bindings is, I think, because after setting up the bindings on the
tablecolumn its not possible to go and observe the tableview's "Table
Content" bindings that have been established for you. Good UI should
show cause and effect...
The UI for managing tableview bindings will probably need to be
different than your standard bindings palette, as in reality you are
dealing with bindings on the whole tableview, as well as bindings for
the columns and cells.
Users need to see the different bindings being established, it should
limit them to 1 arraycontroller per tableview, and deal with cells (and
their value) in a logical way.
It feels as though the new IB binding features haven't been thought out
nearly as much as the rest of IB was.
It's great that Xcode and Cocoa have had so much development in the
past OS X releases (kvo, kvb, coredata, qtkit, pdfkit), but now that
you've completed those rollouts will you be turning back to look at
continued development and improvement of Interface Builder? The visual
development tools are becoming much more important now with bindings +
CoreData.
- tim lucas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden