On Jun 1, 2009, at 7:40 PM, Keary Suska wrote:

You can know when the customization palette is invoked, so all you need to check for is when it is closed and then check for changes. You could take a snapshot at -runCustomizationPalette:, then set a timer that checks -customizationPaletteIsRunning until it returns NO, at which time you check for changes. You are still polling, but at least it is relatively lightweight.

Yes, that what I am doing now.

I tried overriding _endCustomizationPalette:(id), but that method doesn't seem to be called at all, or I didn't manage to override it...

- (void)checkCustomizationChange:(NSTimer*)theTimer
{
  if (! [self customizationPaletteIsRunning])
    { [theTimer invalidate];
      [self customizationDidChange];
    }
}
- (void)runCustomizationPalette:(id)sender
{
  [super runCustomizationPalette:sender];
  [NSTimer scheduledTimerWithTimeInterval: (float)0.1 target: self
                                 selector: @selector (checkCustomizationChange:)
                                 userInfo: nil repeats: YES];
}


On Jun 1, 2009, at 9:20 PM, Peter Ammon wrote:

In addition to what Keary said, you can also set a timer to fire after toolbarWillAddItem:. Not ideal, but better than nothing.

I tried that first, since it would have been more light-weight, but this message is not sent if toolbar items are just moved around.


On Jun 1, 2009, at 10:12 PM, Graham Cox wrote:

It might be useful if you could explain why you need to do this. The design of toolbars is intended to avoid you needing this, since the content and layout of toolbars is something that the user is in charge of. Normally, where an item is sitting in the toolbar is of little interest to the app.

Normally it shouldn't be, but Emacs (Aquamacs: http://aquamacs.org ) has to mediate between Emacs Lisp code and Cocoa. The user's changes need to be percolated to the Lisp side, especially since we're updating the toolbar regularly from the internal (Lisp-level) representation. [Also we don't use the NS defaults system due to cross-platform maintenance requirements, so we need to implement persistency, even though this doesn't have to be synchronously of course.] I hope that makes it clear.

Thanks everyone for your replies.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to