gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Quentin Mathé
Subject: [PATCH] NSView frame and bounds notifications (Cocoa compatibility)
Date: Wed, 12 Aug 2009 12:10:36 +0200

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.

Attachment: NSView-bounds-frame-notif.m.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]