Wither the script menu?

[wootest]

The script menu seems to be gone. Do I simply need to move the Scripts folder to somewhere else in my Library?

[Patou]

Same thing here in sp6 and now sp7.

[JKT]

The correct location for Application scripts in Tiger is in ~/Library/Scripts/Applications/

For OmniWeb that will be ~/Library/Scripts/Applications/OmniWeb/

Then you need to activate the menubar Script icon using AppleScript Utility. When you are in OmniWeb, the scripts will be available.

HTH

[wootest]

Okay - that makes sense. But why no automatic migration from the old location ~/Library/Application Support/OmniWeb 5/Scripts/ ? Why isn't there even a message saying "your script menu's missing - to get it back, move the scripts here"?

I feel I should also say that making a new tab in SP7 (at least) is broken via AppleScript. Omni presumably knows about it and is working on it, but in case they didn't, now they know.

[Jon Hicks]

The correct location for Application scripts in Tiger is in ~/Library/Scripts/Applications/
For OmniWeb that will be ~/Library/Scripts/Applications/OmniWeb/
Then you need to activate the menubar Script icon using AppleScript Utility. When you are in OmniWeb, the scripts will be available.

HTH

Doesn't this enable the general applescript menu, rather than the Script menu that was a part of Omniweb??

[JKT]

Yes it does, but it lists Application specific scripts when you are using that Application. As far as I know, none of the Omni apps have ever had application specific Script menus under Tiger:

http://homepage.mac.com/jtyzack/.Pictures/screenshots/OWscriptmenu.jpg

[wootest]

I just had Omni's own Script menu (and not the general one, which I know exists but don't currently use) with 5.1.3. I literally quit it, copied over 5.5 and started, and was surprised to see it gone.

[JKT]

My bad then ;)

[Jon Hicks]

Yeah, it used to sit to the right of 'Help' in the menubar. I hope its not gone for good.

[Len Case]

Yeah, it used to sit to the right of 'Help' in the menubar. I hope its not gone for good.
In general, when apple provides a standard way to do something, we prefer not to duplicate the functionality ourselves.

I do agree that migration could be improved--we will have to consider working on that.

Also, in OmniOutliner, there is a way to attach scripts as toolbar items, would that be helpful? (no promises, just looking for feedback :) )

[marc]

In general, when apple provides a standard way to do something, we prefer not to duplicate the functionality ourselves.

Understandable, pity it's such a terrible decision that you're complying with. I (irrationally?!) loathe the System-wide scripts menu, I hate how it puts the fact that these things are 'scripts' ahead of their association with a particular app -- IMHO it's a step backwards.

Also, in OmniOutliner, there is a way to attach scripts as toolbar items, would that be helpful? (no promises, just looking for feedback :) )
Yes! Absolutely. In fact I recently requested this very thing! :)

There are some obvious, and compelling uses for this right off the bat. Don't hesitate, do it now!

[Len Case]

I should note that our goal in 5.5 is feature parity with 5.1 but with new WebKit rendering engine. Adding features (and even fixing bugs in 5.1.x) are not the priority though we will do them if we can.

Basically, if everything worked as well as it did in 5.1.3, we would ship right now and then work on fixing bugs and adding features (in the next release).

[marc]

I should note that our goal in 5.5 is feature parity with 5.1 but with new WebKit rendering engine. Adding features (and even fixing bugs in 5.1.x) are not the priority though we will do them if we can.

Basically, if everything worked as well as it did in 5.1.3, we would ship right now and then work on fixing bugs and adding features (in the next release).
Of course, I was just being a bit glib about it! I think we're all in support of getting a tight 5.5 out as soon as possible; 'ASAP' really means 'ASAP post 5.5.'! ;)

[JKT]

Understandable, pity it's such a terrible decision that you're complying with. I (irrationally?!) loathe the System-wide scripts menu, I hate how it puts the fact that these things are 'scripts' ahead of their association with a particular app -- IMHO it's a step backwards.
Yet, for those who use the system wide scripts, it makes more sense to just have one menu bar script icon than two (if and when an app decides to have one too). I don't see the problem myself - it actually makes the script menu a fixed target, it still retains its Application specific context and it actually reminds you that for some apps where you might make use of AS, you haven't got any scripts for them yet.

[marc]

JKT, I can understand your perspective, and your points are reasonable within the current context, but I'm fired up over it (light-heartedly) because I believe there are better solutions, and for me, I've found this to be a negative change. :(

Yet, for those who use the system wide scripts, it makes more sense to just have one menu bar script icon than two
Well, I'm not so sure; having a script menu within an app's context gives the developer some control, and the ability to add other functionality (e.g. Nisus' 'Macro' menu allows you to run 'menu', Perl and AS), but more importantly (IMHO) the application context is maintained, with all relevant functionality physically collocated, not shoved over on the other side of the screen 'cause it's easy to make Menu Extras! It's a disjointed, and inelegant solution (or an elegant hack, YMMV.) :)

IMHO if the scripts really are System-wide they should be available from the Apple menu (we go there often enough for Recent Items, to Log Out etc. that it would hardly be hidden.) Application-specific scripts should arguably be available from the Application menu -- but now I've strayed into Apple territory, and made them second level menus...

(if and when an app decides to have one too).
For me, that's part of the problem; with the System menu I have to check each app, to see if it's got any scripts, whereas the strength of an app-specific Script menu is that (depending on implementation) its presence indicated that the app was scriptable, that there were scripts installed, and available for use (a potential argument against a Script menu in the Application menu.)

I don't see the problem myself - it actually makes the script menu a fixed target
That's true of course, and a very valid point. Giving myself the license to redesign the OS X interface (!) moving scripts to the Apple menu would do likewise. :p

...it still retains its Application specific context and it actually reminds you that for some apps where you might make use of AS, you haven't got any scripts for them yet.
I guess it depends on your involvement with, and exposure to Scripts -- I'd argue that most 'real' users that I see aren't at your level in that regard, they either haven't enabled the optional Script menu, or generally ignore it, as they're not drawn to the menu by the interface of any app... it can just sit quietly up there, and never introduce the user to the possibility of scripting their app (realistically, installing scripts from elsewhere) that the former implementation offered.

Finally, from my personal perspective (since I used such strong wording before!) I guess one of my main complaints is that I have no choice in the matter any more; if I want to use scripts in a couple of apps, or even just the one, I'm forced to use the system menu, which crowds my 'menu extra' area, and is full of scripts with zero relevance to the task at hand.

I'm not arguing that system-wide scripting should be obscured, or de-emphasised at all, I just feel that the current solution is 'sub-optimal' ;) and that there is valuable functionality and usability that's been sacrificed by Apple to start with, and by Omni for following their lead, in good faith, of course.

[wootest]

I appreciate the explanations, and I'm buying your arguments - there's no real upside to having two script menus. It remains to be seen if the keyboard shortcut I set on my few scripts via the System Preferences still 'take' in the script menu's menu. That's one reason why toolbar scripts wouldn't do it for me personally, by the way, and the other's that I keep the toolbar hidden when I don't need it.

Which reminds me - in some situations where the location bar would auto hide after address entering, it doesn't anymore (usually when a new tab is opened by javascript).

[bewebste]

The main disadvantage (for me at least) of the Apple script menu is that you can't assign keyboard shortcuts to scripts in the menu using System Preferences. In OmniWeb, for example, I have a script for "Select first tab", which selects the topmost tab in the drawer, with command-shift-up arrow assigned to it. I've also got shortcuts for "Select last tab", "Reload all tabs", and "Stop loading all tabs". I've been using the keyboard shortcuts for these for so long that I kind of forgot they weren't actually built-in OmniWeb commands, and have been missing them in the sneakypeek.

[iNik]

in OmniOutliner, there is a way to attach scripts as toolbar items, would that be helpful? (no promises, just looking for feedback :) )

I would LOVE to see this functionality added. I have a couple scripts I use frequently to deal with workspaces and another one to subscribe to current pages in NetNewsWire. Being able to access them from the toolbar would be fantastic.

Heck, I'd like to see that in every application, whether or not it's from OmniGroup!

Also, let me just say "thanks" for getting rid of the OmniWeb script menu. I use FastScripts Lite (so I can hit a keyboard shortcut to save and cycle my workspaces) for all my script menu needs, so having its functionality duplicated is a bother and a waste of menu space. Having a single script menu for all apps is a ton easier than a hybrid between the two.

[wootest]

If bewebste is right, there's no support for keyboard shortcuts in the Apple script menu. In this case, couldn't the 'old' script menu stay put where it was if there are any scripts in the old script folder, and just disappear if there aren't?

(I do realize this means keeping code in you could otherwise have thrown away and that this is a burden, but there seem to be other legitimate reasons for keeping the built-in menu too - saving menu bar space for those than don't have it active otherwise, for example.)

[MinutiaeMan]

One tidbit that I love about the new Tiger-wide script menu: You can file away scripts for specific applications into sub-folders (inside the ../Applications/[app name] folder), so they only appear when the current application is in the foreground. I've been using the menu a lot more since Tiger, because there's a lot less clutter that I have to search through.

Personally, instead of moving the Scripts menu to become a sub-menu of the Apple menu, I'd much rather have Services be moved to join or sit next to the Scripts menu. I never use the Services because they're a pain in the ass to get to.

[afb]

Also, in OmniOutliner, there is a way to attach scripts as toolbar items, would that be helpful? (no promises, just looking for feedback :) )

I would also appreciate this feature. Looking at the relatively few scripts that I use in OW, I then thought that one of them could just be incorporated into the app itself: how about an "Open Page/Link in >" menu in the contextual menu that brings up applications (mirrored as "Open Image in" etc.)? *dreaming*

While on the subject of applescripting, I've wanted to write a script to save PDFs of all browser tabs, but not the (unfortunately useless for printing) "Save as PDF" rather the OS print to PDF. *more dreaming*

And an indirect bump for another applescript issue.

[marc]

Personally, instead of moving the Scripts menu to become a sub-menu of the Apple menu, I'd much rather have Services be moved to join or sit next to the Scripts menu. I never use the Services because they're a pain in the ass to get to.
I agree, that's the Achilles heel of the whole thing, the balance between 'logical' categorisation and organisation, and the desire for commands closely at hand. I've often thought the same about the Services menu, which BTW can be done with ICeCoffEE (http://www.macupdate.com/info.php/id/8852)