Re: ASScriptMenuManager
Re: ASScriptMenuManager
- Subject: Re: ASScriptMenuManager
- From: Ron Fleckner <email@hidden>
- Date: Sun, 22 Jul 2007 23:50:34 +1000
On 22/07/2007, at 10:28 PM, has wrote:
Ron Fleckner wrote:
I've developed an Objective-C class which creates and manages a
Scripts menu for Cocoa apps.
Nice. Like the hierarchical and organisation support. FWIW, the
demo project works fine here on G4/10.4.10 and i386/10.4.9.
has, thanks very much for looking at this and for your encouragement.
One bug I noticed: if I put a non-script file in the Scripts
folder, some menu items may not show up (which ones depends on the
file's name)
egads, you're right. I thought this line would stop it processing
non-script files:
if ([fileType isEqualToString:@"'osas'"] || [fileType
isEqualToString:@"'APPL'"])
// process file
but apparently not.
and the Add/Remove Script Menu doesn't work correctly either:
2007-07-22 13:26:35.244 ASScriptMenuManager demo[536] *** -
[NSCFString substringFromIndex:]: Range or index out of bounds
The add/remove has worked fine for me, but I think now I may have
been lucky. I get this warning after a build:
/usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding
may result in errors or different symbols being used
The warning appeared after I'd set the project to build a universal
binary. I guess the warning means that it may use the wrong object
at some point and your line about NSCFString getting a substring out
of range during removal of the menu suggests that. Unfortunately,
I'm unsure how to use -bind_at_load. A search of the docs gives me
no hits.
Your comment about what happens if the user puts a non-script file in
the Scripts folder is fair enough and is news to me. But guarding
against such a case seems excessive. Why would the user do that?
Then again, bullet-proofing is good.
Also, a couple suggestions, one to improve user interaction and one
to extend its appeal:
1. At the moment, addition/removal of scripts while the app is
running isn't automatically detected - users need to restart the
menu/app for changes to take effect. It'd be nice if menu refreshes
were done automatically (e.g. when the user opens a menu/submenu),
though you would need to watch for performance issues - e.g.
Apple's system-wide script menu frequently stalls while opening as
it checks [presumably] the entire file hierarchy, but maybe if you
just refresh individual [sub]menus only as they're needed it'd
perform ok.
Yes, I gave that some thought and decided that it would be a good
thing. However, I really wanted to get some feedback after
(surprisingly for me) getting the thing to work at all. Not sure how
to implement it, but your suggestion would be a good place to start.
2. You might consider adding support for Python/Perl/Ruby/shell/
etc. scripts as well as OSA scripts. There are several languages
that have good Apple event support but whose OSA support isn't
currently sufficient to permit OSA attachability. Being able to
execute, say, a .rb file directly would allow users to invoke such
scripts from your menu without having to wait for a full Ruby OSA
component to become available. The only thing you need to do is
avoid blocking the client app's main event loop while the script is
running (either by detaching the interpreter subprocess or by
having a background thread manage it) so that you don't get a
deadlock if the subprocess tries to send Apple events back to the
parent app.
Sounds good. At this point, though, I have to tell you I'm really
just a beginner/dilettante with no formal training in computer
science and only a basic mastery of C and AppleScript under my belt.
Cocoa and Xcode and Mac OS neXt have opened a whole world to me which
I wouldn't have been able to see under OS 8/9. But like your other
suggestions I can see that it is a good one.
I really, sincerely, appreciate your interest and I will certainly be
looking into implementing your suggestions, the first of which I'd
already considered.
Thanks a lot,
Ron
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden