[marc]

Originally Posted by Len Case

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.

Originally Posted by Len Case

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]

Originally Posted by 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).

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]

Originally Posted by marc

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. :(

Originally Posted by JKT

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...

Originally Posted by JKT

(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.)

Originally Posted by JKT

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

Originally Posted by JKT

...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]

Originally Posted by Len Case

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.