Re: [PATCH] NSView frame and bounds notifications (Cocoa compatibility)

[Fred Kiefer]

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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev