Icons in Scripts

[zer0]

In this sea of script lines I only have a couple of things to say.

a) I don't like how a plus symbol ("+") adds a tick to the menu. I have a few scripts that add certain words in certain places so instead of a caption like "+ Whatever" I have a "Tick Whatever". Perhaps it's better to distinguish using either white space or double symbol, like with "&&" in captions.

b) The whole menu thing that was introduced today is confusing. Is it a stepping stone towards creating a submenu system with pull-out commands?

[admin]

BTW, the probably most easy way to get rid of the indent would be simply add {...} to the current syntax (aka #! SCRIPT_ENGINE = 1):

Code: Select all

"!Go C:\Temp|C:\Temp" {goto "C:\Temp";}
"_noIcons" {echo("Hasta la vista, icons! Mwahaha!");}
"Go Desktop|Desktop" {goto "Desktop";}
"Go XY exe|<xypath>\XYplorer.exe" {goto "<xypath>\XYplorer.exe";}
"-"
"Open With Photoshop|Photoshop" {openwith "Photoshop";}
"Open With Notepad|Notepad" {openwith "Notepad";}

This could be fed in a single line and still be parsed correctly.

[admin]

In this sea of script lines I only have a couple of things to say.

a) I don't like how a plus symbol ("+") adds a tick to the menu. I have a few scripts that add certain words in certain places so instead of a caption like "+ Whatever" I have a "Tick Whatever". Perhaps it's better to distinguish using either white space or double symbol, like with "&&" in captions.

b) The whole menu thing that was introduced today is confusing. Is it a stepping stone towards creating a submenu system with pull-out commands?

a) Will be changed in the next version (Flags..., or State)
b) It is one of the ideas here. (not mine)

[TheQwerty]

I don't see what's lost. You can easily build a string "item(...){...}item(...){...}item(...){...}" and load it to have a 3-item popup. This is not possible now that easily.

Well now the easiest thing to do is use Load with a list of labels. Will that still work? (It's not pretty but it's much better than "item(...){...}...item(...){...}".

My only goal at the moment is a syntax that gets rid of indenting as a means to structure the stuff. And a better handling of "caption|icon|flags" data as (caption, icon, flags).

If all you're after is removing the white-space and indenting requirements then yes converting our current format to blocks (just adding {} to the mix) is certainly the easiest.

I don't think what you're suggesting is really a good way to handle these flags since they'll generally have to be static. I can't see myself wanting to place a check mark before the item unless I can easily toggle it. The same (but to a lesser degree) with enabling/disabling the item.

b) The whole menu thing that was introduced today is confusing. Is it a stepping stone towards creating a submenu system with pull-out commands?

It's a proposal to fix a number of problems with the current methods. The menu system (and script files in general) was pieced together in response to the developing of scripting. As such the end result gives the feeling that it's not exactly something that was planned and that the foundation for script files could be much stronger.

For instance in script files we have to rely on white-space and indenting to separate scripts (not something that really bothers me) but there's a lot of advantage to having things separated into blocks, and it's helpful for others.

As the menu is tied so heavily to the script themselves it is more difficult to create dynamic menus which can be easily changed, and there is absolutely no way to create a true sub-menu. You can have a menu item call another menu, but to get back to the first menu you have to either use a while loop or a "Back" menu item.

We also have no concept of user functions and instead have to use sub-scripts and global variables to emulate them.


I'm proposing that we separate the menu construction and displaying from the actual script structure, which allows the creation of menus to be much more powerful, and provides a method to get proper sub-menus. In addition, we create a syntax that allows for user functions, and further a way to have global variables for the script without repeating Global() or GetKey() everywhere.


Yes, it's a lot of changes and it's a bit complex and confusing at first. For some simple scripts it might result in more code, but it opens up a lot more doors and makes the extremely difficult easier. I also think it's a more future-proof move than placing more pieces on the current foundation.

[j_c_hallgren]

After reading TheQwerty's comments in last couple of days, I must say that I'm quite impressed with the time and effort he's given to make scripting better for all...and jacky and others have made some valuable contributions as well...makes me feel like a bystander, which I basically am when it comes to scripting as I've decided to concentrate more on helping XY in other ways, like assisting newbies, promoting it, etc.

Just wanted to also say that TheQwerty's proposal generally made sense to me but I can see where it could be confusiing to some.

[admin]

I don't see what's lost. You can easily build a string "item(...){...}item(...){...}item(...){...}" and load it to have a 3-item popup. This is not possible now that easily.

Well now the easiest thing to do is use Load with a list of labels. Will that still work? (It's not pretty but it's much better than "item(...){...}...item(...){...}".

Oh, the labels are the actual function name; I had left them out because my original test case had no labels either. Here are two items with labels and one without:

Code: Select all

item gotemp("Go C:\Temp", "C:\Temp", 1) {goto "C:\Temp";}
item godesk("Go Desktop", "Desktop") {goto "Desktop"};
item("Open With Photoshop", "Photoshop") {openwith "Photoshop";}

Sure I agree that submenus and a better way to popup menus would be nice. The day will come.

[jacky]

My only goal at the moment is a syntax that gets rid of indenting as a means to structure the stuff. And a better handling of "caption|icon|flags" data as (caption, icon, flags).

Well in that case I would say just add the brackets to the current syntax (instead of indenting), but keep TheQwerty's proposal somewhere for when you move scripting to the next version, including user functions, etc.

(BTW something that hasn't been addressed here is the difference between commands & functions, but I think that if we're gonna (when we will do so) talk about a script engine v2 or whatever, it might be good to talk about it. Cause if we could get the substr, strpos & other readurl to behave as functions as well, it would be really appreciated. (Those are only commands cause there were no functions at the time, correct?)
So, I wonder if there couldn't be a way to get the two syntax/uses to co-exists (e.g. when used as a function is returns a value, when as a command it uses an additional first parameter to set the returning value), or maybe the new script engine should drop those as commands and turn them into functions. But of course I can hear you say: Later... )

[admin]

My only goal at the moment is a syntax that gets rid of indenting as a means to structure the stuff. And a better handling of "caption|icon|flags" data as (caption, icon, flags).

Well in that case I would say just add the brackets to the current syntax (instead of indenting), but keep TheQwerty's proposal somewhere for when you move scripting to the next version, including user functions, etc.

(BTW something that hasn't been addressed here is the difference between commands & functions, but I think that if we're gonna (when we will do so) talk about a script engine v2 or whatever, it might be good to talk about it. Cause if we could get the substr, strpos & other readurl to behave as functions as well, it would be really appreciated. (Those are only commands cause there were no functions at the time, correct?)
So, I wonder if there couldn't be a way to get the two syntax/uses to co-exists (e.g. when used as a function is returns a value, when as a command it uses an additional first parameter to set the returning value), or maybe the new script engine should drop those as commands and turn them into functions. But of course I can hear you say: Later... )

Later...

About substr, strpos etc. yes, this is really awful, I will see if I can turn them into functions without breaking old user code.

[zer0]

Stepping away from all those great things that scripting will potentially have...and returning to the topic of the thread.

I'd like to include icons in my scripts, but one either has to choose those of registered apps or get creative with an icon editor. Those are not exactly great options, are they?

To battle the former I've set up a thread in TTQ&A, but it did not take off like I hoped. Don, like when you created a function to pull properties info from media files, would you mind including a list (or a link to) of a those registered names please?

To combat the latter, it'd be nice to set up a gallery where people can upload their XY icons to share. After all, the scaling (up or down) in XY isn't something to write home about and having to resort to 3rd party software to customise XYplorer isn't ideal either. User-created content should play a bigger role than it currently does (just scripts).

[admin]

Stepping away from all those great things that scripting will potentially have...and returning to the topic of the thread.

I'd like to include icons in my scripts, but one either has to choose those of registered apps or get creative with an icon editor. Those are not exactly great options, are they?

To battle the former I've set up a thread in TTQ&A, but it did not take off like I hoped. Don, like when you created a function to pull properties info from media files, would you mind including a list (or a link to) of a those registered names please?

To combat the latter, it'd be nice to set up a gallery where people can upload their XY icons to share. After all, the scaling (up or down) in XY isn't something to write home about and having to resort to 3rd party software to customise XYplorer isn't ideal either. User-created content should play a bigger role than it currently does (just scripts).

You missed the easy part: Any file or folder can be used as icon resource. Just enter the path of it...

[zer0]

You missed the easy part: Any file or folder can be used as icon resource. Just enter the path of it...

...and you missed an obvious part: tying an icon to a local resource removes the portability aspect of it. What happens if that file/folder is moved/deleted? Currently, icons aren't embedded so a person using the portable version has to carry them around as well. At the moment, that's the best solution. Using the registered application's name is the 2nd best alternative.

[admin]

You missed the easy part: Any file or folder can be used as icon resource. Just enter the path of it...

...and you missed an obvious part: tying an icon to a local resource removes the portability aspect of it. What happens if that file/folder is moved/deleted? Currently, icons aren't embedded so a person using the portable version has to carry them around as well. At the moment, that's the best solution. Using the registered application's name is the 2nd best alternative.

There are a couple of files you carry around with the portable version. Make a little subfolder "icons" and put your files there. No problem.

[zer0]

There are a couple of files you carry around with the portable version. Make a little subfolder "icons" and put your files there. No problem.

Quite. That's what I do. However, the issue of obtaining those icons in the first place and lack of knowledge in terms of registered names remain unsolved.

[jacky]

There are a couple of files you carry around with the portable version. Make a little subfolder "icons" and put your files there. No problem.

Right, so how long before one wishes for embedded icons within script file (as base64-encoded resources or something) ?

[jacky]

However, the issue of obtaining those icons in the first place and lack of knowledge in terms of registered names remain unsolved.

I don't think Don can give you a list of registered names, simply because it depends on your system. For example I'm pretty sure "Photoshop" is a registered name for Don, but it ain't for me... (Same goes for registered app usable with run/openwith/PFA/etc)

As for free icon resources, I'm sure there are some good ones out there on the Interwebs (I think Don might have mentioned some in the changelog over the years, using some for TB icons or something), though I couldn't name you one...