NSViewController and other view issues

  • I just discovered NSViewController a few days ago and noticed the
    comments about it being an NSResponder and the possibility of placing it
    into the responder chain.  I liked that idea and wanted to expand on it.

        First, let me say that the longer I have used Cocoa and Objective C, the
    more comfortable and even fond of them I have become.  However NSView (and
    NSResponder, for that matter) is a very bloated class, and doesn't even do a
    good job of partitioning its administrative tasks and content tasks.  Now,
    with animation, CALayers, etc. it is becoming even more bloated.

        MacApp's view class was also rather bloated, but the introduction of
    "behaviors" allowed event handling to be parceled out in a more modular
    fashion, as I showed in several articles I wrote for MacApp Digest.  By
    allowing events to be passed down a behavior chain, individual independent
    event handling capabilities could be easily mixed and matched as desired,
    while using very generic view classes.  (I even reorganized MacApp's
    textView to do this.)

        Unfortunately, I don't see a good way in NSView or NSResponder to
    intercept the event handling chain and implement something similar to
    "behaviors".  It looks like, with the viewController approach, it would be
    possible to chain event handlers, as subclasses of NSResponder, to operate
    after the view has a crack at it.  However, behaviors intercepted events
    after the subviews but before the view, with the last behavior in the chain
    calling back to the view's equivalents.

        I've thought about trying to implement the "post view" version, but have
    not yet delved into the animation issues and wonder if this might become an
    obstacle to doing what I want.
previous month december 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Go to today