On Tuesday, November 13, 2007, at 04:09PM, <[EMAIL PROTECTED]> wrote:
>-- (void)fileView:(FileView *)aFileView willDisplayContextMenu:(NSMenu *)menu
>forIconAtIndex:(NSUInteger)anIndex {
>+// shouldn't this method return a menu rather than modifying one?
>+- (NSMenu *)fileView:(FileView *)aFileView contextMenu:(NSMenu *)menu
>forIconAtIndex:(NSUInteger)anIndex {
I debated this with myself, but ended up thinking of it more as
-menuNeedsUpdate: than -menuForEvent: (I couldn't recall the method signature
so the name didn't reflect that). Either way works, but I think returning and
passing as a parameter is redundant; if returning a menu and adding its
contents to the original is easier, that's fine with me.
Not sure what menu stuff you wanted to include in FileView? The Open With...
menu would be nice to have in FileView directly, but I didn't want to include
stuff that's already in BD. The safari/preview/skim menu stuff is too
specialized. OTOH, putting that into a BibEditor-specific FileView subclass
would be fine. BibEditor has a huge amount of URL-related code.
I can sort of see what this does, but a comment would be helpful...it's
removing items that don't validate?
while (i--) {
if ([[menu itemAtIndex:i] isSeparatorItem]) {
if (wasSeparator)
[menu removeItemAtIndex:i];
} else if ([self validateMenuItem:[menu itemAtIndex:i]]) {
wasSeparator = NO;
} else {
[menu removeItemAtIndex:i];
}
}
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bibdesk-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
