Re: NSBrowser: so very, very broken
Re: NSBrowser: so very, very broken
- Subject: Re: NSBrowser: so very, very broken
- From: "John C. Randolph" <email@hidden>
- Date: Fri, 24 Jan 2003 16:49:03 -0800
On Friday, January 24, 2003, at 12:04 AM, The Amazing Llama wrote:
Why are NSBrowser and its component parts so broken?
- it should be named NSBrowserView
It predates that naming convention. Note that NSMatrix isn't called
NSMatrixView, either.
- there is no drag and drop support anywhere; implementing it is
ridiculously complicated.
? It's the same as implementing Drag and Drop in any other NSView.
- when NSBrowser creates new columns, it doesn't check - matrixClass
to see what matrix to fill it with.
- when NSMatrix creates new cells, it doesn't check + cellClass to see
what cells to fill it with.
Not when it has a prototype cell, no. This works as documented: the
prototype cell supersedes +cellClass, which lets you be more specific
about setting the attributes of new cells.
- more understandably, it doesn't check NSBrowser's +cellClass,
either.
There's a search order going on, here. When NSBrowser needs to create
a new cell in one of its column's NSMatrix instances, it checks:
1) The prototype cell of the matrix (if found, it gets copied)
2) the prototype cell of the browser
3) the Matrix's +cellClass (if not nil, gets +alloc/-init)
4) the Browser's +cellClass.
- when NSBrowserCell is displayed, it doesn't check - title to see
what it's title should be.
No, it uses the cell's -stringValue.
- when NSBrowserCell is displayed, it doesn't check - image to see
what it's image should be.
- the naming conventions are ____InIndex and ____InColumn instead of
Cocoa's more standard ____AtIndex and ____For____
I don't see and NSBrowser or NSMatrix methods or delegate methods that
have the word "InIndex" in them.
- NSBrowser uses its delegate as it's data source, and there is no way
to separate the two, as there is in NSTableView and NSOutlineView
They were separated out in NSTableView because tableviews
NSBrowser is one of my favorite features of OSX as a User, but now
that I tried to implement one, I can see quite clearly why they're not
everywhere they could be.
Is this just me, or is it the general feeling that these classes are
flawed? I understand that the origins of this class are different than
most of AppKit, but shouldn't it have been simplified a bit by now?
There's a bit of a problem with simplifying the API of an existing
class like NSBrowser, since doing so has the danger of breaking
existing code.
-jcr
John C. Randolph <email@hidden> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.