[Drawkit] Object manipulation notification

[Linan Wang]

On Wed, Jul 2, 2008 at 1:42 AM, Graham Cox <graham.cox at bigpond.com> wrote:

>
> On 1 Jul 2008, at 7:32 pm, Linan Wang wrote:
>
>  Thank you for your response.
>> For object adding/removal issue, I think it would be great if it could
>> be implemented in KVO style, that is, programer can just observe the
>> "objects" key of any DKObjectOwnerLayer.
>>
>
>
> Agreed, and I have changed the code for DKObjectOwnerLayer so that it is
> fully KVC/KVO compliant for the 'objects' property. In addition, I added
> notifications for adding/removing objects, so you have the choice over which
> to use. Note that I may have to tweak the KVC stuff to be more efficient -
> at present when adding or removing multiple objects it sends a notification
> per object rather than grouping them (which requires manual KVO
> notification), which could cause a blizzard of notifications for some
> operations. All the existing methods for object adding/removal now call the
> KVO-compliant ones so any operation should be observable.
>
>  For object properties changing notifications: my program binds a
>> "building" object with each DKDrawableObject (I put it as userInfo), I
>> want to change the location/size/orientation properties of the objects
>> when user manipulates the DKDrawableObject, so that extra info will be
>> supplied to users to help them make design decisions.
>> I feel it could be only achieved effeciently by hook
>> postNotificationName:selector:object into methods which change the
>> DKDrawableObject properties.
>> Any thoughts?
>> Thanks
>>
>
>
> I overlooked a more obvious thing in my last reply - there is a
> notification: kDKDrawableDidChangeNotification (this may have gone by
> another name in the beta 3) which is broadcast from the -notifyVisualChange
> method of DKDrawableObject that will tell you that *something* changed -
> you'd obviously have to retrieve the object's properties of interest to find
> out what, so it's not very precise. The demo's Object Inspector taps into
> this for example.
>
Yes, it's changed to kGCDrawableDidChangeNotification. It solves my problem.
Thanks :)


>
> KVO is trickier. Unfortunately right now some of the most basic properties
> of a drawable are not KVC compliant (e.g. setting the object's position uses
> -moveToPoint: but retrieving it uses -location). This isn't so bad - I can
> add a -setLocation: method that the existing ones call for example. That's
> probably worth doing in general for the basic properties such as location,
> size, angle. I'd prefer this to adding individual notifications for every
> property because overall there are so many. Most properties of more specific
> classes are already KVC compliant, it's just these fundamental ones that
> aren't.
>
> It worries me a bit that you want to use these notifications just to update
> a piece of userInfo data. That sounds like trying to synchronise two copies
> of the same data which is almost always a bad idea. Of course if you are
> simple *presenting* that data to the user somehow that's another matter.
>
Agree. It's not a good idea to keep same data in more than one places, like
having two watches on hand so that have no idea what time it really is.
However, I want to expose my objects to a script engine while keep their
drawkit facade out of the sight. Anyway it's a problem I need to figure out.
cheers

>
>
> cheers, Graham
>
> _______________________________________________
> Drawkit mailing list
> Drawkit at lists.apptree.net
> http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net
>



-- 
Best regards

Linan Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20080703/514ecffa/attachment.htm>