Icons in Scripts

[TheQwerty]

Some preliminary thoughts:
Essentially, I think we need to get to separating the menu from the sub-scripts.
We also need user functions.
And it would be nice if we had a less cumbersome way for some vars that are truly global to the entire script file.

Example Structure:

Code: Select all

#! SCRIPT_ENGINE = 2
/*	SHEBANG!
	To keep backwards compatibility this will be required and specifies
	the version of the script engine to use. Eventually the current engine
	could be removed, but this allows for a smoother transition to the new one.

	We should probably require it be the first line, first column as well.
*/


[GLOBALS]
	/*	GLOBAL VARS (Script File Level)
		We nearly have this, but ideally these variables could be referenced
		like normal variables and not require the use of GetKey() or Global().

		Using the INI format we should be able to leverage SetKey() to keep
		them updated if we want to, otherwise they'd be used for static values.
	*/
G_SCRIPT_NAME = "blah blah"
G_DEFAULT_MENUITEM_STATE = 0


def FunctionName (arg1, arg2="") {
	/*	USER FUNCTIONS
		Essentially a normal script with args and returns.

		Arg1 is required.
		Arg2 is optional with a default value of "".
		Required arguments must always preceed optional ones.

		Use "return [expression]" to return a value.
		If expression or the return command is omitted 1 should be returned.
	*/
}

1. When the file is loaded:
2. If a caption is specified and it matches a functionName (or is an index): Execute "caption"
3. Else If a function is named "main": Execute "main"
4. Else: Execute first function.

How do we handle menus? With three new commands (similar to AutoIt or AHK):

1. MenuItem "MenuName"[, "Action", "Caption", "Description", "Icon", "State"];
2. MenuSub "MenuName", "SubMenu"[, "Caption", "Description", "Icon", "State"];
3. DisplayMenu "Menus"[, "Description"];

Details:
1. MenuItem "MenuName"[, "FunctionName|SimpleScript", "Caption", "Description", "Icon", "State"];
This adds an item or separator to the menu named "MenuName".

• Required Args:
  • MenuName
    • This is the name of the menu to add items to.
• Optional Args:
  • Action
    • This is the function name or a small script to execute when this item is selected.
    • If omitted, a separator is inserted.
  • Caption
    • Text to display in the menu for this item. Using & for accelerators.
  • Description
    • A brief description of the item for display in the status bar.
  • Icon
    • Path to an icon to display for this item.
  • State
    • State of this item.
    • Combination of the following OR-ed:
      • 1 = Default
      • 2 = Checked
      • 4 = Disabled

2. MenuSub "MenuName", "SubMenu"[, "Caption", "Description", "Icon", "State"];
This adds a submenu to the menu named "MenuName".

• Required Args:
  • MenuName
    • This is the name of the menu to add a submenu to.
  • SubMenu
    • This is the name of the menu to add as the submenu.
    • You should create the submenu before you add it to another menu.
• Optional Args:
  • Caption
    • Text to display in the menu for this item. Using & for accelerators.
  • Description
    • A brief description of the item for display in the status bar.
  • Icon
    • Path to an icon to display for this item.
  • State
    • State of this item.
    • Combination of the following OR-ed:
      • 1 = Default
      • 2 = Checked
      • 4 = Disabled

3. DisplayMenu "Menus"[, "Description"];
This displays the specified menu(s).

• Required Args:
  • Menus
    • This is the name of the menu to display.
    • This can be a list of menus separated by "|" to join them into a single menu.
• Optional Args:
  • Description
    • A brief description that is displayed on the status bar, when the menu is displayed, or not item is highlighted.

EDIT: Corrected DisplayMenu, definition.

[j_c_hallgren]

The obvious other candidate is function.

Guess I'm too used to that word being associated with a section of code smaller than a subroutine or a predefined built-in, as in Excel, to see it work in this context...sorry...that's why I suggested a combo-word since using just "menu" would imply that it's the entire set of options vs just one appearing on a menu.

Before I could post this, TheQwerty came up some really good ideas!

The only thing I'd suggest is some way to make the 1+2+4 into some labels, such as Dft/Chk/Dis or combined as DftChk or similar.

[jacky]

The obvious other candidate is function.

I would have gone for [menu]item, function doesn't seem that obvious to me : those aren't really functions (they don't accept parameters not return anything) but definition of menu items : caption, icons, check/bold, all that refer to the menu item, hence item was be more obvious to me...

[TheQwerty]

The only thing I'd suggest is some way to make the 1+2+4 into some labels, such as Dft/Chk/Dis or combined as DftChk or similar.

Indeed, I didn't update that, but I'd think instead of the numbers it should be some abbreviation. B (Bold/Default), C (Checked), D (Disabled).

[admin]

Some preliminary thoughts:...

OK, interesting! I don't know AHK myself, but I know it's popular and probably good. So it is indeed a potential model.

How would this menu definition look in the syntax your are proposing?

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";

[TheQwerty]

How would this menu definition look in the syntax your are proposing?

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";

Well I'm not sure which way I'd go about it, but you'd certainly have a number of options..
(I'd probably lean towards method 2 in this case.)

Method 1 (Straight forward):

Code: Select all

#! SCRIPT_ENGINE = 2

def main() { //Construct and Display the Main Menu
	MenuItem "MainMenu", 'goto "C:\Temp";', "Go C:\Temp",, "C:\Temp", "B";
	MenuItem "MainMenu", 'goto "Desktop";', "Go Desktop",, "Desktop";
	MenuItem "MainMenu", "goto ""<xypath>\XYplorer.exe"";", "Go XY exe",, "<xypath>\XYplorer.exe";
	MenuItem "MainMenu";
	MenuItem "MainMenu", 'openwith "Photoshop"', "Open With Photoshop",, "Photoshop";
	MenuItem "MainMenu", 'openwith "Notepad"', "Open With Notepad",, "Notepad";
	DisplayMenu "MainMenu";
}

def noIcons() { //Display a funny message.
	echo("Hasta la vista, icons! Mwahaha!");
}

Method 2 (Outsouce adding goto menu items):

Code: Select all

#! SCRIPT_ENGINE = 2

def main() { //Construct and Display the Main Menu
	GoItem("C:\Temp",, "B");
	GoItem("Desktop");
	GoItem(, "Go XY exe");
	MenuItem "MainMenu";
	MenuItem "MainMenu", 'openwith "Photoshop"', "Open With Photoshop",, "Photoshop";
	MenuItem "MainMenu", 'openwith "Notepad"', "Open With Notepad",, "Notepad";
	DisplayMenu "MainMenu";
}

def GoItem($path="<xypath>", $caption="", $state="", $menu="MainMenu") { //Add menu items for goto scripts.
	$caption = ($caption) ? $caption : "Go $path";
	MenuItem "$menu", "goto ""$path"";", "$caption",, "$path", "$state"
}

def noIcons() { //Display a funny message.
	echo("Hasta la vista, icons! Mwahaha!");
}

Method 3 (separate menu, so final display can be more customizable):

Code: Select all

#! SCRIPT_ENGINE = 2

def main() { //Construct and Display the Main Menu
	MenuItem "MainMenu";
	MenuItem "MainMenu", 'openwith "Photoshop"', "Open With Photoshop",, "Photoshop";
	MenuItem "MainMenu", 'openwith "Notepad"', "Open With Notepad",, "Notepad";
	DisplayMenu GoMenu() . "|MainMenu"; //Concatenate the menu created by GoMenu to the MainMenu.
}

def GoMenu($menu="GoMenu") { //Create a menu of just the Goto Items.
	GoItem("$menu", "C:\Temp",, "B");
	GoItem("$menu", "Desktop");
	GoItem("$menu",, "Go XY exe");
	return "$menu";
}

def GoItem($menu="MainMenu", $path="<xypath>", $caption="", $state="") { //Add menu items for goto scripts.
	$caption = ($caption) ? $caption : "Go $path";
	MenuItem "$menu", "goto '$path';", "$caption",, "$path", "$state"
}

def noIcons() { //Display a funny message.
	echo("Hasta la vista, icons! Mwahaha!");
}

Method 4 (Using sub-menus instead of groups and a separator):

Code: Select all

#! SCRIPT_ENGINE = 2

def main() { //Construct and Display the Main Menu
	MenuSub "MainMenu", GoMenu(), "Go Submenu";
	MenuSub "MainMenu", OWMenu(), "Open With Submenu";
	DisplayMenu "MainMenu";
}

def GoMenu($menu="GoMenu") { //Create a menu of just the goto items.
	GoItem("$menu", "C:\Temp",, "B");
	GoItem("$menu", "Desktop");
	GoItem("$menu", , "Go XY exe");
	return "$menu";
}

def GoItem($menu="MainMenu", $path="<xypath>", $caption="", $state="") { //Add menu items for goto scripts.
	$caption = ($caption) ? $caption : "Go $path";
	MenuItem "$menu", "goto '$path';", "$caption",, "$path", "$state"
}

def OWMenu() { //Create a menu of just Open With items.
	MenuItem "OWMenu", 'openwith "Photoshop"', "Open With Photoshop",, "Photoshop";
	MenuItem "OWMenu", 'openwith "Notepad"', "Open With Notepad",, "Notepad";
	return "OWMenu";
}

def noIcons() { //Display a funny message.
	echo("Hasta la vista, icons! Mwahaha!");
}

[jacky]

How would this menu definition look in the syntax your are proposing?

If I got it right, I guess it could look something like this:

Code: Select all

#! SCRIPT_ENGINE = 2

function main()
{
	MenuItem 'mnuMain', goto 'C:\Temp', 'Go C:\Temp',, 'C:\Temp', 1;
	MenuItem 'mnuMain', goto 'Desktop', 'Go Desktop',, 'Desktop';
	MenuItem 'mnuMain', goto "<xypath>\XYplorer.exe", 'Go XY exe',, "<xypath>\XYplorer.exe";
	MenuItem 'mnuMain';
	MenuItem 'mnuMain', openwith 'Photoshop', 'Open With Photoshop',, 'Photoshop';
	MenuItem 'mnuMain', openwith 'Notepad', 'Open With Notepad',, 'Notepad';
	DisplayMenu 'mnuMain';
}
function noIcons() { echo("Hasta la vista, icons! Mwahaha!"); }

It might mean more work to do the same, but the idea here is also to keep the old (easier/quicker to use) syntax for simple stuff, and through the "magic header" enable a more "advanced" script file syntax: no "auto-menu" but special commands (with more power) & user-functions!

A couple of things I noticed looking into this:
- Yeah, I think I like "function" better than "def"
- It is "odd" that here we set action first, caption then, while it is the opposite in the current script syntax. I wonder if this shouldn't be switched, to make it less confusing.
- I'm not sure how that whole "Action" parameter would work. It can't just be a script, otherwise there's no way to use a coma for parameters since they could refer to both command within this script, or command menuitem. I think it might be easier to just say this arg must be a function name (or maybe a script but within { } then, though that could lead to odd-looking things maybe...).
- Nothing to do with this, but I'd disagree with no "return" means returning TRUE (1). I'd say no "return" (or no return value) means returning nothing/empty string.

[admin]

How would this menu definition look in the syntax your are proposing?

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";

Well I'm not sure which way I'd go about it, but you'd certainly have a number of options..
(I'd probably lean towards method 2 in this case.)
...

Wow, impressive, but a bit too extreme for my taste. I have a knack for keeping it simple (and a bit dirty). For example, I think I could parse this (now taking item as keyword), and it would get rid of indent and white space dependency:

Code: Select all

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

[TheQwerty]

If I got it right, I guess it could look something like this:

Yep pretty much that's one way.

- Yeah, I think I like "function" better than "def"

*shrugs* I used def because I like Python but function is fine as well.

- It is "odd" that here we set action first, caption then, while it is the opposite in the current script syntax. I wonder if this shouldn't be switched, to make it less confusing.

The reason I ordered them this way is because the caption is optional, and it's generally less confusing if required parameters come before optional ones. I wouldn't object to changing it, but I think if we did it would work better if the caption was required as well then.

- I'm not sure how that whole "Action" parameter would work. It can't just be a script, otherwise there's no way to use a coma for parameters since they could refer to both command within this script, or command menuitem. I think it might be easier to just say this arg must be a function name (or maybe a script but within { } then, though that could lead to odd-looking things maybe...).

Yes, it's tricky in the same way that Load is if you try to pass it a script as a string. My thoughts was it would usually be the name and arguments of a function, but this argument will probably require quotes most of the time.

Nothing to do with this, but I'd disagree with no "return" means returning TRUE (1). I'd say no "return" (or no return value) means returning nothing/empty string.

I chose TRUE because in my mind if you don't perform any return the function should have completed successfully (you generally break out of it if there is an error), returning nothing or an empty string means it returns FALSE. That's a non-issue to me, either way. Especially if we are given ! as an inverter some time soon!

[jacky]

The reason I ordered them this way is because the caption is optional, and it's generally less confusing if required parameters come before optional ones. I wouldn't object to changing it, but I think if we did it would work better if the caption was required as well then.

Yeah I figured as much, but I just kept finding it odd (and checking back) that it was reversed of the usual/current way, where caption comes first even though it is optional...

@Don: Yeah, but the major advantage of TheQwerty's proposal is user-functions!! Sure it has cool things for menus, but also user functions!!

[admin]

The reason I ordered them this way is because the caption is optional, and it's generally less confusing if required parameters come before optional ones. I wouldn't object to changing it, but I think if we did it would work better if the caption was required as well then.

Yeah I figured as much, but I just kept finding it odd (and checking back) that it was reversed of the usual/current way, where caption comes first even though it is optional...

@Don: Yeah, but the major advantage of TheQwerty's proposal is user-functions!! Sure it has cool things for menus, but also user functions!!

Oh, I have user functions as well. Here's the corrected version of my last proposal:

Code: Select all

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

All I need to add for real user functions is arguments and returns, of course. But this is independent of the multi-script/menu syntax.

[TheQwerty]

Code: Select all

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

I'm not entirely understanding how you are using item here. Could it be called within a function?
Or for instance how would your script toggle a menu item that is using the check mark?

How would we go about creating dynamic menus or sub-menus?

[admin]

Code: Select all

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

I'm not entirely understanding how you are using item here. Could it be called within a function?
Or for instance how would your script toggle a menu item that is using the check mark?

How would we go about creating dynamic menus or sub-menus?

item is a construct that cannot be called from anywhere, only loaded as part of a script resource. It just defines a menu item. Toggling a checkmark, difficult unless you directly work on the script resource before loading it. This indeed calls for more...

Dynamic menus or sub-menus? I never said I'd plan that.

[TheQwerty]

Dynamic menus or sub-menus? I never said I'd plan that.

Well without Dynamic menus your version is a step backwards as far as menus are concerned. The ability to disable, define a default, and barely use checkmarks isn't worth losing the ability to change the menu on the fly.

You really should be considering both of these, I doubt I'm the only one that is wishing for them; especially proper sub-menus.

EDIT: Correction, I'm not wishing for dynamic menus, we already have them to a degree. I just wish they could do more and were easier to manipulate.

[admin]

Dynamic menus or sub-menus? I never said I'd plan that.

Well without Dynamic menus your version is a step backwards as far as menus are concerned. The ability to disable, define a default, and barely use checkmarks isn't worth losing the ability to change the menu on the fly.

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.

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