• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSBrowser woes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSBrowser woes


  • Subject: Re: NSBrowser woes
  • From: Christopher Lloyd <email@hidden>
  • Date: Wed, 30 May 2001 02:11:24 -0400

At 06:35 PM 5/28/2001 -0700, you wrote:
Shouldn't NSBrowser have a similar api to NSTableView?

Heh, probably! The AppKit controls in general could use quite a bit of unification, but alas, the AppKit roots go way back and in the name of backward compatibility many of the controls have not had their API's significantly revamped since OpenStep, and even then many of them didn't change all that much. The API's for NSBrowser (nee NXBrowser) predate NSTableView (nee NXTableView nee DBTableView) by several years and each class grew out of different groups at NeXT for different purposes. So, from a historical perspective it makes sense they are very different beasts, but if you view the AppKit as a new thing, there are a lot of inconsistencies. My favorite is why is the API for NSComboBox so different than NSPopUpButton ??

EOF has a decent way to normalize controls with the EOAssociation system, but EOF is on the way out it appears. That's a whole other topic I won't ramble about :)

There seems to be no support for managing selections, editing and/or drag and drop.

When the user clicks in the browser, you are notified through the target/action system, then you can query the browser about the current selection and can change it if you wish.

Has anyone done anything real with NSBrowser other than the simple examples I've seen posted here?

Sure, but you typically don't want to do those "real" things with NSBrowser. An NSBrowser maintains a bunch of NSMatrix's for the columns. Most of the current functionality is in the NSMatrix class. If you want to extend NSBrowser with things like drag&drop and cell editing it usually makes sense to put it in an NSMatrix subclass. You can then set the matrix class that the browser uses for columns and away you go.

I tend to agree with the philosophy that the controls should be kept simple, the API's are big enough as they are and they don't need to be loaded up. It is pretty easy to extend them with your own subclasses... if you know the AppKit well.

ps. shouldn't it be called NSBrowserView? I get the feeling that this class hasn't gotten that much attention in the cocoa group.

I like NSPeruserView more :)

If you came on as a former NeXT developer, you'd think Cocoa as a whole is neglected technology! Nothing new&exciting in a long time. And DPS was replaced by a subset! Well, the OpenGL view is nice, but someone who now works at Apple had that working on NT long ago. AppleScript litter in Foundation is not my idea of advanced new features and only erodes the cross-platform spirit.

Hope this helps, or at least adds a little perspective,
Chris


  • Prev by Date: Key events in NSTextField
  • Next by Date: Re: Weird doc-based behaviour?
  • Previous by thread: NSBrowser woes
  • Next by thread: Message Queuing Question
  • Index(es):
    • Date
    • Thread