XYplorer Beta Club

j_c_hallgren wrote:Hey, I'm not trying to argue just to be disagreable, but because the initial issue was where to put a built-in variant of a simple "Run Script - ::try" command, and if you have to do this command when done manually from "User" menu, then you would have to do the built-in one from the same place for that same reason that "you cannot just take stuff out of there and put it somewhere else", ok?

Yes, it's a variant of a simple "Run Script - ::try" command, but it is not a "Run Script - ::try" command.

admin wrote:Yes, it's a variant of a simple "Run Script - ::try" command, but it is not a "Run Script - ::try" command.

But it's still close enough, so based on initial description also, I still say it shouldn't be isolated into Tools, but could reside in a Scripting menu.

And just so y'all know, some of what y'all have written to convince me that I'm wrong actually supports my position instead, so that's why I've been unmoved thus far...but I'm almost ready to concede...not because I think my ideas are incorrect, but just cause it'd take too long (typing) to point out the inconsistencies in the arguements against it.

j_c_hallgren wrote:

admin wrote:Yes, it's a variant of a simple "Run Script - ::try" command, but it is not a "Run Script - ::try" command.

But it's still close enough, so based on initial description also, I still say it shouldn't be isolated into Tools, but could reside in a Scripting menu.

And just so y'all know, some of what y'all have written to convince me that I'm wrong actually supports my position instead, so that's why I've been unmoved thus far...but I'm almost ready to concede...not because I think my ideas are incorrect, but just cause it'd take too long (typing) to point out the inconsistencies in the arguements against it.

Same here!

Anyway, I already added the Scripting menu. And it's nice. All what I need now is a better term for "Enable Extended Scripting" (see my post somewhere above).

j_c_hallgren wrote:jacky, you and I may disagree on some parts of this but that's ok...

Sure is, we've done it before and probably will again in the future. Just know that when this happens, I'm always right

admin wrote:Another advantage: one could have a keyboard shortcut for toggling Step mode (for which now you have to invest a UDC).

Uh? Is someone forgetting about CKS: Miscellaneous / Scripting / Step Through Scripts (#1050;) ??

j_c_hallgren wrote:and if added, as you may have seen, I'd certainly expect "Run Script" and "Load Script" to be within that menu and not User...

Okay, I think this is where you're wrong, jc. You seem to think that the "Run Script" & "Load Script File" are script "commands" that have been conveniently put in the User menu, because if was fitting nicely, but that didn't actually belong there, and should there be a menu Scripting they should be moved in such menu.

That is simply not the case. The menu User is the place for UDC, and a UDC is a way for the user to create commands with user-defined "settings" or parameters. For Backup To it will be a destination, maybe a source too, for Rename a pattern, Go To a location, and for Run Script a script & Load Script File a file (path/)name (and maybe a label).

Those two (Run Sript/Load Script File) are nothing but pure standard UDC, and belong there regardless how what happens to Scripting.
Just like the Rename isn't put in the File|Rename Special menu, but under User. Because while it way be linked to the rename feature, it's not part of it, but of UDC: it's a way for users to create their own UDC, based on the Rename command.

Same goes for Run Script/LSF, they're not Scripting commands, but UDC interface to the scripting commands. Hence why they belong in User no matter what, and why Scripting-specific commands do not.

admin wrote:Now, "Enable Extended Scripting" is a stupid label. Hmmm, any better ideas anybody?

"Allow Scripting in Location Terms (using :: prefix)" ?

Damn, I was too slow (or you were too fast ) and I see you already did it, but I'd suggest a rename of "Enter Script..." to "Try Script...", seems more appropriate & has consistency with ::try

jacky wrote:Damn, I was too slow (or you were too fast ) and I see you already did it, but I'd suggest a rename of "Enter Script..." to "Try Script...", seems more appropriate & has consistency with ::try

Yes, not bad. "Enter script" sounded to mainway-like to me anyway...

jacky wrote:Uh? Is someone forgetting about CKS: Miscellaneous / Scripting / Step Through Scripts (#1050;) ??

Yep, I forgot for a second. In the next version #1050 will be removed.

jacky wrote:"Allow Scripting in Location Terms (using :: prefix)" ?

Don't like it.

admin wrote:

jacky wrote:"Allow Scripting in Location Terms (using :: prefix)" ?

Don't like it.

Well, I do And I sure think it's better than "Enable Extended Scripting" which don't really mean anything unless you already knew what it meant...

BTW I thought Catalog items only showed the Script icon when using "Go To" action, since that's the only time there can actually be a script. Either I was wrong, or it's not the case anymore. Either way I think it should only show the Script icon when there actually is a script...

PS: Script icon (on Catalog still) also still show the VF overlay when pipe is used (for a VF or not) and "Enable Extended Scripting" wasn't enabled at first (it's not "cleared").

hmm.. yeah ok it's even more messy actually. You can have a Catalog itemw with script (& action Go To) not show the Script icon if it's set on another action with "Extended Script" disable. Enable it, the Script icon is (rightly) not show. Then change its Action to Go To, the icon isn't updated with the Script icon (need to disable/enable the "Extended Script" to get that done)

Scripting via address bar (and similar) should be referred to as "Quick Scripting" to continue the convention already used by name searches and visual filters.

Thus the menu item should be called "Enable Quick Scripting".

TheQwerty wrote:Scripting via address bar (and similar) should be referred to as "Quick Scripting" to continue the convention already used by name searches and visual filters.

Thus the menu item should be called "Enable Quick Scripting".

I like that. I'll take it. Thanks.

EDIT1: well... until something better comes up. The "quick" does not make so much sense once the script is saved in the catalog or in a favorite... (neither does "quick" make a lot of sense in quick names searches). Hmmm

EDIT2: Forget EDIT1. I like it.

jacky wrote:

admin wrote:

jacky wrote:"Allow Scripting in Location Terms (using :: prefix)" ?

Don't like it.

Well, I do And I sure think it's better than "Enable Extended Scripting" which don't really mean anything unless you already knew what it meant...

BTW I thought Catalog items only showed the Script icon when using "Go To" action, since that's the only time there can actually be a script. Either I was wrong, or it's not the case anymore. Either way I think it should only show the Script icon when there actually is a script...

PS: Script icon (on Catalog still) also still show the VF overlay when pipe is used (for a VF or not) and "Enable Extended Scripting" wasn't enabled at first (it's not "cleared").

hmm.. yeah ok it's even more messy actually. You can have a Catalog itemw with script (& action Go To) not show the Script icon if it's set on another action with "Extended Script" disable. Enable it, the Script icon is (rightly) not show. Then change its Action to Go To, the icon isn't updated with the Script icon (need to disable/enable the "Extended Script" to get that done)

Ah yes, Ah yes, Ah yes. Should be fixed in next version.

"Allow Scripting in Location Terms (using :: prefix)" ... is quite long, and I think "in Location Terms" is somehow wrong (?).

admin wrote:

TheQwerty wrote:Scripting via address bar (and similar) should be referred to as "Quick Scripting" to continue the convention already used by name searches and visual filters.

Thus the menu item should be called "Enable Quick Scripting".

I like that. I'll take it. Thanks.

EDIT1: well... until something better comes up. The "quick" does not make so much sense once the script is saved in the catalog or in a favorite... (neither does "quick" make a lot of sense in quick names searches). Hmmm

EDIT2: Forget EDIT1. I like it.

For what it's worth, I do agree with EDIT1.

By itself the command doesn't make sense, but I think it's important to keep it consistent with those "Quick" features, and once the user is familiar with what we mean by "Quick ..." they'll have no problem. That goes back to what jacky said about the name being descriptive, once they know what "Enable Awesomely Cool Scripting Abilities" means it's no longer an issue, but until then or if they forget, what then?

Perhaps it's worth considering renaming all three features to something more descriptive at this point? I keep thinking their names should include "location" (since they are being executed when parsing a location value) but I'm afraid that might get users thinking it's location specific when it doesn't have to be.

TheQwerty wrote:

admin wrote:

TheQwerty wrote:Scripting via address bar (and similar) should be referred to as "Quick Scripting" to continue the convention already used by name searches and visual filters.

Thus the menu item should be called "Enable Quick Scripting".

I like that. I'll take it. Thanks.

EDIT1: well... until something better comes up. The "quick" does not make so much sense once the script is saved in the catalog or in a favorite... (neither does "quick" make a lot of sense in quick names searches). Hmmm

EDIT2: Forget EDIT1. I like it.

For what it's worth, I do agree with EDIT1.

By itself the command doesn't make sense, but I think it's important to keep it consistent with those "Quick" features, and once the user is familiar with what we mean by "Quick ..." they'll have no problem. That goes back to what jacky said about the name being descriptive, once they know what "Enable Awesomely Cool Scripting Abilities" means it's no longer an issue, but until then or if they forget, what then?

Perhaps it's worth considering renaming all three features to something more descriptive at this point? I keep thinking their names should include "location" (since they are being executed when parsing a location value) but I'm afraid that might get users thinking it's location specific when it doesn't have to be.

I'm for "Quick" because being descriptive is not the point. With menu captions you always have to learn and remember what they actually mean. The caption should just help you remember the meaning. "Quick" does the job.

admin wrote:"Allow Scripting in Location Terms (using :: prefix)" ... is quite long, and I think "in Location Terms" is somehow wrong (?).

hmm... yeah, and looking at it I may have meant something more like "Allow Scripting in Go To locations", because that's the key element here : the Go To part, since it's supported everywhere a goto pattern is accepted (Catalog, Go To, AB, etc) (and you can ditch the prefix mention, that was only to make it all obvious without anything else needed...)


Quick note on the so-called "Quick" features : funny thing, I had never heard of that term before ! And I agree with EDIT1, no need for a "Quick" in front of the term Name Search. And for VF, describing using GoTo with pipe as a way to quickly set a VF, sure, but why call it "Quick VF", it's the real deal, a full VF with all of its features -- unlike a Name Search, which is limited to Name filter & doesn't affect the FF settings.

So I'm not sure putting a similarity for those two things is so good, because they're really not the same...

jacky wrote:

admin wrote:"Allow Scripting in Location Terms (using :: prefix)" ... is quite long, and I think "in Location Terms" is somehow wrong (?).

hmm... yeah, and looking at it I may have meant something more like "Allow Scripting in Go To locations", because that's the key element here : the Go To part, since it's supported everywhere a goto pattern is accepted (Catalog, Go To, AB, etc)


Quick note on the so-called "Quick" features : funny thing, I had never heard of that term before ! And I agree with EDIT1, no need for a "Quick" in front of the term Name Search. And for VF, describing using GoTo with pipe as a way to quickly set a VF, sure, but why call it "Quick VF", it's the real deal, a full VF with all of its features -- unlike a Name Search, which is limited to Name filter & doesn't affect the FF settings.

So I'm not sure putting a similarity for those two things is so good, because they're really not the same...

Quick refers to the entering procedure, not to the execution.

Not the same but similar: In CSS there are techniques of squeezing several commands into on line; they call it "shorthand". "Quick" makes the same point but better, because you use a shorthand method to be quicker. You enter a script directly into the address bar to be quicker. That XY can store location terms in various ways (favs, catalog) is only a secondary effect.