Re: [SOLVED, with reservations] Re: Turn off menu highlight in outline view?
Re: [SOLVED, with reservations] Re: Turn off menu highlight in outline view?
- Subject: Re: [SOLVED, with reservations] Re: Turn off menu highlight in outline view?
- From: Quincey Morris <email@hidden>
- Date: Mon, 17 Aug 2009 10:48:17 -0700
On Aug 17, 2009, at 09:30, Corbin Dunn wrote:
Hopefully customization has become easier, and frequently less
required (ie: the "source list" highlighting style, proper drag and
drop feedback, etc). Do you have specific examples of things that
are difficult to do which should be easier? I'm interested in
knowing what is difficult to customize, or work with.
Well, since you've opened things up like this ...
My guess is that I. S. wasn't referring to specific defects (though
there are those) but to the "Frankenstein's monster" nature of
NSTableView/NSOutlineView -- a lot of not-quite-matching pieces bolted
onto the corpse of a much simpler class that died about 15 years ago.
It's not so much about whether the current implementation has 9
fingers or 11 toes, but whether a new organism might do a better job.
I'd say that NSTableView and NSOutlineView are two of a small number
of very important classes that make developers' lives miserable, when
used for anything above the simplest of scenarios. (NSController and
its mutant offspring are in this number too, vid. another ongoing
discussion on this list regarding defective KVO notifications.)
Here are some of the issues, just off the top of my head:
-- The table/outline view class APIs have become so intricate,
especially in regard to what's implicit rather than explicit, that
they seem to be undocumentable. Consider the number of questions we
get on this list about how to do things, *from developers who've read
the documentation*, and consider how hard it is to answer the
questions correctly, because usually there are obscure conceptual
issues in the questions that need to be untangled first.
-- The proliferation of delegate methods, while it does enhance
customizability, suggests that bolt-on, ad-hoc solutions are being
favored over fundamental design evolution. It's not much use if the
monster has dozens of useful gizmos sticking out of its head, if it
can't lurch one step without falling over.
-- The conceptual divide between data-sourced and KVO-bound approaches
to providing content is vast. The distinction between customizations
that are done through subclassing and through delegation is
incomprehensible (cf. frameOfOutlineCellAtRow: vs.
outlineView:isGroupItem:). The determination of what can be customized
(through subclassing and delegation) and what cannot be customized,
seems random.
-- In the interests of compatibility, the source list style has ended
up having a "nudge, nudge, wink, wink" API. It's not available
directly, but just sort of happens as a lucky side-effect of patting
your head and rubbing your stomach simultaneously.
-- Etc.
To be honest, I'm amazed at the amount of very sophisticated
functionality in NSTableView/NSOutlineView. It does many, many things
I know I'd be unwilling to re-invent if they weren't handed to me for
free. However, I think you've proved that a general purpose table view
class is much more complicated than its original conception (however
many years ago that was). In effect, NSTableView and NSOutlineView and
NSObjectController and NSArrayController and NSTreeController have
been a long-running lab experiment that prove you *do* have the
technology to solve the problem. Perhaps the time will soon come when
you are willing to heave the experiment off a cliff, and turn your
weird science project into a consumer product.
FWIW.
_______________________________________________
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