XYplorer Beta Club

Coming in after the party, but let me add my "wow" to the mix !

Yeah, this looks really good. Very nicely done TheQwerty !

I just started to play with scripts & script files, but the possibilities seem endless, that's some really impressive thing we got there!!
Don, you're amazing!

j_c_hallgren wrote:

TheQwerty wrote:Maybe we need an attachment mod for phpBB so that instead of inlining scripts we could just attach them.

I just took a look at the phpBB site and see that attachments are available in vers 3 of the forum software, but for now, I think we'd maybe just want to make one or a few stand-alone threads in this sub-forum to hold these (or pointers to download locations), and they could be marked as "sticky"'s...

The advantage would be that they could be updated as needed should coding need to be changed, where attachments seem to be more fixed in contents...and they could also be then stored on XY site as downloads for ease in retrieval, if desired, as Don seems to have already done for one.

I could see a set of these being included in XY package, similar to TOTD, and/or a page on XY site listing available scripts for download.

Yes, I could set up a page where you could download scripts. There would be a short description for each script plus mention of the author.

I'm still thinking about a newbie-proof way of plugging them in. Up to now we only have the loadscriptfile command which is not very newbie-friendly. Of course, I could scan for any XYS files in .\scripts\ and list them in a new menu "Scripts", but it lacks elegance...

BTW, conc. those XYS files. Did I get you folks right that you want to enter just ::loadscriptfile filebase and XY should auto-append the .xys when attempting to open those files?? Could be done.
BUT: I'm still thinking about the value of the XYS file idea. There's also a downside to it. At least for me, I dislike when software introduces new file formats (and a new extension looks like a new format). It also does not go well with the notion of portability... And I think it's a good message that the powerful scripts can reside in simple TXT files. It says: "It's not hard, there are no secrets, you can do it too."

Ok, here's my $.02 worth:

1) The loadscriptfile as present isn't that bad, but if it was predefined that they would exist only in "\Scripts" (given that they have to be within XY appl folder anyway, true?) that would make sense to me...listing them in menu Scripts could be confusing as it may lead user to think one was directly executable when it may need setup by another one, maybe?

2) Yes, that was the intent that XYS would be auto-appended.

3) Ok, so it's not really a new file format, but it can only be used by XY anyway...and still can be edited by any text editor, as can many INI files, for example...there are other examples I've run into that are just TXT but are named differently so as to make clear the function/usage...and regarding portability: We know we can open/edit them with NotePad or similar, so what's the problem? Some text editor is almost always available, right? And about the "secrets": Documentation!!!!

Addendum: Maybe...they really could be named ".TXT" files IF they had to be stored only in the Scripts folder? That would make them easier to open by any editor but still keep them isolated somewhat.

Uploaded new version of

http://www.xyplorer.com/download/RegExp-Both.xys

that conforms to the new syntax...

With regards to an attachment mod, I'm sure Don could write a decent interface for allowing us to share them, but I think we'd all agree his time is better spent on XY directly. I suggested the mod only half-seriously. I think a fine method would be a separate sub-forum. That way each script can have its own thread and separate dialog, and if needed a sticky thread could be created to act as an index to everything.

admin wrote:I'm still thinking about a newbie-proof way of plugging them in. Up to now we only have the loadscriptfile command which is not very newbie-friendly. Of course, I could scan for any XYS files in .\scripts\ and list them in a new menu "Scripts", but it lacks elegance...

I had considered this as well and you're right it's lacking. What do you think of a new UDC "Execute Script File," which is just putting a pretty name and interface on a goto UDC with location of "::loadScriptFile [file]"?

admin wrote:BTW, conc. those XYS files. Did I get you folks right that you want to enter just ::loadscriptfile filebase and XY should auto-append the .xys when attempting to open those files?? Could be done.

That was one thought with it. The loadScriptFile function could be updated to first check for the exact file provided and if not found try with an appended .xys. Or check for xys first, I'm not sure which might be better.

admin wrote:BUT: I'm still thinking about the value of the XYS file idea. There's also a downside to it. At least for me, I dislike when software introduces new file formats (and a new extension looks like a new format). It also does not go well with the notion of portability... And I think it's a good message that the powerful scripts can reside in simple TXT files. It says: "It's not hard, there are no secrets, you can do it too."

Well, let's not take it that far. Let's treat it as a suggested file extension which XY is aware of and automatically checks for, but does not require (at least not for the time being).

The way I feel is the downsides you list are valid, but rather abstract. The use of an "official" extension provides a number of concrete benefits to the user.

It makes the scripts immediately easier to identify (if a user wants to register it as a known extension they can use a custom icon for scripts).
Because they are easy to identify we can easily locate and apply color filters to the files within XY.
It will allow us to create syntax definitions for the text editors that support syntax highlighting.
It allows the users to keep things much better organized and will make it easier for us to know the purpose of the file and what program uses it.
By officially supporting an extension now, you cut off the possibility of script writers choosing different extensions individually and causing unnecessary confusion.


I think the number of users that are frustrated by new formats is probably in the minority and of that they'll be more accepting of it when they realize it's just a text file with a different extension. They can edit it however they want, and even write their own programs to create/modify/use them.

To be honest I think the concept and syntax of scripting will scare users away long before an extension would. And I don't see how it affects the portability unless you register it as a known file type, which could be optional like '"XYplorer" in shell context menu.'


Again, just to be clear, you do not need to require the extension, but it would be extremely helpful if you at least support an extension officially.



Now with that long post out of the way, I'm going to update the first post for the new syntax.

TheQwerty wrote:With regards to an attachment mod, I'm sure Don could write a decent interface for allowing us to share them, but I think we'd all agree his time is better spent on XY directly. I suggested the mod only half-seriously. I think a fine method would be a separate sub-forum. That way each script can have its own thread and separate dialog, and if needed a sticky thread could be created to act as an index to everything.

Yes, I agree. I'm not even sure we need a new forum, at least not for now. There's a "Tips & Tricks" already, and it suits the present needs quite fine I would say. If we were to see lots of scripts being posting, then a new separated forum might come in handy, but not even required yet I would say.


About a GUI for the scripts, I think TheQwerty's idea of using a new UDC for loadscriptfile is just great : it very simple & easy to use, it allows a user to have his scripts listed on a menu, it doesn't clutter the Go to category, and if you don't want (all) your scripts showing up there, you can have it. You decide.

Regarding the extension : I agree that it might be a good thing, for all the reasons TheQwerty already explained. And you can say that .XYS is the default/recommended extension for scripts, without making it a requirement nor registering it, hell no! It's just an "alternative" extension to TXT that allows easy recognition of those files, should be be for text editor and script highlight, or even us to define a color filter !
No need to touch the registry, just have XY come with a default Portable File Association : "xys>notepad"

TheQwerty wrote:I think the number of users that are frustrated by new formats is probably in the minority and of that they'll be more accepting of it when they realize it's just a text file with a different extension. They can edit it however they want, and even write their own programs to create/modify/use them.

More importantly, this isn't really a new format. I mean :
- the file is nothing but a plain text file, editable with any text editor. No need for a specific additional tool or anything. And no registry changes.
- yes, there's a syntax. Even if we use TXT files, that syntax remains the same, quite obviously !

TheQwerty wrote:

admin wrote:BTW, conc. those XYS files. Did I get you folks right that you want to enter just ::loadscriptfile filebase and XY should auto-append the .xys when attempting to open those files?? Could be done.

That was one thought with it. The loadScriptFile function could be updated to first check for the exact file provided and if not found try with an appended .xys. Or check for xys first, I'm not sure which might be better.

I would say check for <name>.XYS first, if it fails look for <name> - Besides, is one wants to load "foobar" he can just say so: "::loadscriptfile foobar."

Of course, this actually leaves "the" question : what is an extension ? I mean, how would XY deal with "some script" (no ext), "some script.txt", and "some script v1.1" ?

Plus, it shouldn't mess with the relative syntax support. So maybe it would be simple, like : when a name only (ie. no path, or no "") is given it will be tried first in subfodler "Scripts" with extension .XYS auto-added. If it fails, or when there's a path, it's tried like today using relative syntax.


Since we're on that subject, one thing I might find interesting would be a parameter for loadscriptfile to execute the script, as in no menu. What I mean is, when you work on a "complicated" script, or just one with more than 2 commands, you might want to use an XYS. It's just much better to use, especially with tabs, comments and all. But you might also want to be able to execute that script by one click on you Catalog for example (or one key, thanks to an UDC). Right now it pops up a menu with one item (the script).
Or instead of a paramater it could depend on the content of the file ? Like if there's no caption and only one "script batch" then execute ?

jacky wrote:Plus, it shouldn't mess with the relative syntax support. So maybe it would be simple, like : when a name only (ie. no path, or no "") is given it will be tried first in subfodler "Scripts" with extension .XYS auto-added. If it fails, or when there's a path, it's tried like today using relative syntax.

This seems best solution thus far...thus IF one wanted to name their scripts as .TXT (to make editing a tiny bit easier via built-in edit associations), they could do so, but just would need to add that onto LoadScript cmds.

jacky wrote:Since we're on that subject, one thing I might find interesting would be a parameter for loadscriptfile to execute the script, as in no menu. What I mean is, when you work on a "complicated" script, or just one with more than 2 commands, you might want to use an XYS. It's just much better to use, especially with tabs, comments and all. But you might also want to be able to execute that script by one click on you Catalog for example (or one key, thanks to an UDC). Right now it pops up a menu with one item (the script).
Or instead of a paramater it could depend on the content of the file ? Like if there's no caption and only one "script batch" then execute ?

Agreed! This would make it appear closer to a direct XY function as compared to a sub-function. I don't see any downside to this.

Oh, and about the forum issue: Couldn't we just have a sticky thread with info about available ones and then actually store them on the Wiki as alternative? It would then provide for files that can be downloaded and yet can be easily updated/revised without Don's intervention...the forum thread would just be a alternate way of locating and documenting them, and this would only require one or possibly two sticky threads so overhead on forum would be minimal....

Speaking of the wiki: When will someone add some of the script stuff there? I'd almost started making a page myself using some of the data I'd built for blog entries which may lend itself to wiki adaptation.

Getting back to the idea of a Scripts menu.
How about having this menu, which would be dynamically built on startup based on the content of one special XYS file.
Let's say, if the file /Sripts/ScriptMenu.xys exists, its content is put in the Scripts menu - and here we are with everybody's personal plugin collection. Furthermore the install package could come with a template file with some nice scripts for newbies.

I'm just curious about one thing for now: If most of us are using a sub-folder "\Scripts" to keep them out of the general XY folder, and which seems to be a good, logically organized method/scheme, why isn't that being reflected in the LoadScript syntax now? Since we've now made the default extension as XYS, and many of the comments made here seem to use the \Scripts idea, shouldn't this be made a 'standard' before things get too out of control?

Part of this is parallel to something I think about for some months: it's good to keep scripts out of XY-root-directory - but for security etc I would like to keep all modifyable files (that is .ini as well) out of XA-root! As I would prefer if XY-root only could be modified by user with admin-rights! (While .ini, for example, must be writable by any user working with XY.)

So I really would like all such files to be in a (or several) subdirectories of XY (or somewhere else)! Files there could be allowed to be modified (and created) by every user.
Still better: a XYpathes.ini (or so) *in* XY-root, (that is: made by PC-admin!) allowing to direct some of these modifyable directories to other directory, as %homepath%\xy\ini or such - this would make the ability to have user-specific configurations.
(Where configuration can be any aspect: from MRU about colors to general settings.)

Sorry to be a bit offtopic here, but I think this (or something alike) could add some more interesting abilities to XY, but expecially make it a bit more secure.

RalphM wrote:Getting back to the idea of a Scripts menu.
How about having this menu, which would be dynamically built on startup based on the content of one special XYS file.
Let's say, if the file /Sripts/ScriptMenu.xys exists, its content is put in the Scripts menu - and here we are with everybody's personal plugin collection. Furthermore the install package could come with a template file with some nice scripts for newbies.

I come back to this when scripting is safe enough for newbies...

j_c_hallgren wrote:I'm just curious about one thing for now: If most of us are using a sub-folder "\Scripts" to keep them out of the general XY folder, and which seems to be a good, logically organized method/scheme, why isn't that being reflected in the LoadScript syntax now? Since we've now made the default extension as XYS, and many of the comments made here seem to use the \Scripts idea, shouldn't this be made a 'standard' before things get too out of control?

Hmm, that's doppeltgemoppelt (good guess, it's german). I'd say either XYS or scripts/.

PeterH wrote:Part of this is parallel to something I think about for some months: it's good to keep scripts out of XY-root-directory - but for security etc I would like to keep all modifyable files (that is .ini as well) out of XA-root! As I would prefer if XY-root only could be modified by user with admin-rights! (While .ini, for example, must be writable by any user working with XY.)

So I really would like all such files to be in a (or several) subdirectories of XY (or somewhere else)! Files there could be allowed to be modified (and created) by every user.
Still better: a XYpathes.ini (or so) *in* XY-root, (that is: made by PC-admin!) allowing to direct some of these modifyable directories to other directory, as %homepath%\xy\ini or such - this would make the ability to have user-specific configurations.
(Where configuration can be any aspect: from MRU about colors to general settings.)

Sorry to be a bit offtopic here, but I think this (or something alike) could add some more interesting abilities to XY, but expecially make it a bit more secure.

What dangers are you thinking of?
And which interesting abilities would be added?

PeterH wrote:Part of this is parallel to something I think about for some months: it's good to keep scripts out of XY-root-directory - but for security etc I would like to keep all modifyable files (that is .ini as well) out of XA-root! As I would prefer if XY-root only could be modified by user with admin-rights! (While .ini, for example, must be writable by any user working with XY.)

While that may work for your setup, it wouldn't at all for me, as I run 99% of the time with a user acct and only resort to admin when I absolutely have to...plus, I'm not sure how you'd be able to restrict that from within XY...BTW, I use "Run As" to do installs while in user acct to further reduce the time spent as admin.

As written before, I do agree with the concept of scripts out of XY root...

Update: I see that jacky has been busy adding scripts to the wiki...good job thus far! I'll be reviewing it for any English bugs/oddities...

What dangers are you thinking of?

One danger is that a dflt-user (in German it's Benutzer-profile, in contrast to Hauptbenutzer or Administrator, don't know how they are named in English) must have the right to change files (like .ini) and as such must be allowed to write to the program directory of XY.
When I surf the internet I use a user with Benutzer-rights, so that any possible virus cannot affect my program-directories. But if this user should be able to fully work with XY, I must allow XY-program directoy to be changed by user - and as such allow a virus to attack xyplorer.exe...
As far as I know microsoft advices programmers not to modify program directories in any way, just for this reason,.
If all files you write to would be in a subdir of XY, I could allow this subdir as "modify" for Benutzer, without any risk for XY itself. The risk of any change would be reduced to the XY-parameters for all users.

And which interesting abilities would be added?

If the path to the (or to some) parameter-files for XY could be configured, they could point to user-specific directories (c:\Dokumente und Einstellungen\peter\...) - that is, different users could work with different "views" of XY. For example, my admin-user, my normal user and my internet user do quite different things. So admin might wish to see system files and folders, while the others might not. Admin works with install-directories, user with my photos - so it would be fine if they have different MRU-lists.

@j_c It seems our use of different users doesn't differ so much. For installation of "real windows-programs" (writing to registry, maybe to shared program files etc) I always use an administrative user, while for installation of XY I use Run As admin.
So I don' understand why someone beside admin should have a right to modify XY or other program directory?
Years ago many programs used to write .ini etc into their program directories - and then had problems with authorities of simple users.

It's correct: if a program is installable on a stick, it's parms shpuld somehow be "connected" to the install-directory - but why imbedded and not in a subdirectory?

I hope I could explain a part of what I think - maybe we should continue this discussion a bit further...