Committed, plus a few changes to initWithCoder: Thank you Fred
Quentin Mathé schrieb: > Hi, > > Here is a small patch to make NSView posts both frame and bounds > notifications without having to explicitly invoke > -setPostsBoundsChangedNotifications: and -setPostsFrameChangeNotification:. > Although this behavior is not documented in the Cocoa API reference, it is > detailed in the View Programming Guide at section 'Repositioning and > Resizing Views > Notifications' : < > http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/WorkingWithAViewHierarchy/WorkingWithAViewHierarchy.html > > To make the NSView notification behavior works exactly as documented in the > Cocoa API doc is bit more work. > The expected behavior is explained here: > < > http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html#//apple_ref/occ/instm/NSView/setPostsBoundsChangedNotifications:> > > and > < > http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html#//apple_ref/occ/instm/NSView/setPostsFrameChangedNotifications:>. > > > I think two flags _wasBoundsChanged and _wasFrameChanged need to be added. > Methods like -setFrameOrigin:, -setFrameRotation:, -translateOriginToPoint: > etc.would be changed to set the right flag to YES. Then > -setPostsBoundsChangedNotification: and -setPostsFrameChangedNotification: > can respectively check _wasBoundsChanged and _wasFrameChanged: to decide > whether notifications have to be synthetized and posted immediately. > > However I'm not sure these flags should be standalone ivars or put inside > _rFlagsType. Why two ways exist to store boolean ivars in NSView? > If these flags are introduced, they have to be archived, but... Is NSCoder > support still required for new features or is NSKeyedArchiver enough? If > non-keyed arching must be supported, should introducing a new class version > be delayed until the release is ready? My reasoning is that other ivars > could removed/added in the meantime and extra class versions should be > avoided. > > Cheers, > Quentin. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gnustep-dev mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
