Custom Context Menus

[Kaelri]

As of today's Rainmeter 2.4 Beta, a skin can now add custom items to the context menu. Alongside the standard items that appear for every skin ("Edit", "Refresh", "Unload", etc), skins can now show up to 15 user-defined items.

Example

Code: Select all

[Rainmeter]
Update=1000
ContextTitle=Run Notepad
ContextAction=["Notepad.exe"]
ContextTitle2=Run Calculator
ContextAction2=["Calc.exe"]

Usage

ContextTitleN may be any string of text, up to 30 characters. Longer titles will be clipped with trailing ellipsis (...).

ContextActionN may be any valid action option, including bangs, such as those used in mouse actions and IfActions. Both ContextTitle and ContextAction are required for each custom item, except for separators (see below).

Some other rules:

• Both ContextTitleN and ContextActionN fully support dynamic variables, including the new section variables. Titles will use the current value of a variable at the time the context menu is opened. Actions will use the current value when the item is clicked. (Watch out for this if you're using the same variable in both a title and an action, since the value may change between opening the context menu and clicking the item.)
• 3 or fewer custom items appear in the "top-level" menu, under a heading of "Custom skin actions." 4 or more custom items appear in a submenu called "Custom skin actions."
• ContextTitleN and ContextActionN may be changed with !SetOption, as in !SetOption Rainmeter ContextTitleN "New Title". If a ContextTitleN or ContextActionN option is set as blank, as in !SetOption Rainmeter ContextTitleN "" or simply ContextTitleN=, the item is disabled, as are all subsequent items. In other words, if ContextTitle3 is blank, then ContextTitle4, ContextTitle5, etc. will not be shown.
• If ContextTitleN contains only dashes, such as ContextTitle3=-----, the item will appear as a separator. Separators are not shown with 3 or fewer items, and they do count toward the 15-item limit. Separators do not require a corresponding ContextActionN.

Guidelines

While there are no formal restrictions on either titles or actions, we encourage skin authors to use custom context menu items wisely, in order to avoid confusing users. For example, you should not use item names that are already used in Rainmeter's built-in context items, such as "Edit settings" or "Exit".

Documentation

This feature is fully documented in the beta manual, which includes a working example skin.

[jsmorley]

One nice feature of this that may not be intuitive at first is that !SetOption can be used to create "meter specific" skin context menu items:

Code: Select all

[Rainmeter]
Update=1000

[MeterOne]
Meter=Image
W=45
H=45
SolidColor=217,252,255,255
MouseOverAction=[!SetOption Rainmeter ContextTitle "Run Notepad"][!SetOption Rainmeter ContextAction """["Notepad.exe"]"""]

[MeterTwo]
Meter=Image
Y=4R
W=45
H=45
SolidColor=255,254,222,255
MouseOverAction=[!SetOption Rainmeter ContextTitle "Run Calculator"][!SetOption Rainmeter ContextAction """["Calc.exe"]"""]

one.jpg

two.jpg

[Brian]

Although this isn't too terribly useful, you can also set a "Menu Access Key" to run your action from the keyboard by adding a "&" before the character you want to run the action.

For example:

Code: Select all

[Rainmeter]
ContextTitle=Run &Notepad
ContextAction=["Notepad.exe"]

When the menu is open, if you press the "N" key on your keyboard, the associated context action is ran. If your menu has more then 3 items, then the submenu also needs to be open to use menu access keys on those actions as well.

Menu Access Key.png

Note: Starting in Windows 7, menu access keys are hidden by default. Open the "Ease of Access Center" and select the "Make keyboard easier to use" option. Then select the "Underline keyboard shortcuts and access keys" option.

Ease of Access.PNG

-Brian

[Alex Becherer]

just began playing with it. really nice feature. thanks for that.

is the maximum width for entries on purpose? long entries are clipped here.

Untitled-1.jpg

[jsmorley]

just began playing with it. really nice feature. thanks for that.

is the maximum width for entries on purpose? long entries are clipped here.

Untitled-1.jpg

Yes, while we are a bit flexible as to what the maximum length should be, it is something we want to restrict to keep folks from creating monstrosities and distributing them and having Rainmeter make a bad first impression with ugly non-standard context menus that take up half the screen when opened.

Just think of it like Twitter... You need to be short and "pithy".

Perhaps there is a shorter German word to imply "Settings"?

[jsmorley]

just began playing with it. really nice feature. thanks for that.

is the maximum width for entries on purpose? long entries are clipped here.

Untitled-1.jpg

You could trick it with something like this:

Code: Select all

[Rainmeter]
Update=1000
ContextTitle="--Settings--"
ContextAction=[]
ContextTitle2="Colors"
ContextAction2=["SomeAction"]
ContextTitle3="Font Colors"
ContextAction3=["SomeAction"]
ContextTitle4="GMail Account"
ContextAction4=["SomeAction"]
ContextTitle5="Weather Code"
ContextAction5=["SomeAction"]
ContextTitle6="RSS URL"
ContextAction6=["SomeAction"]

temp.jpg

Or this:

Code: Select all

[Rainmeter]
Update=1000
ContextTitle="MySkin Settings"
ContextAction=[]
ContextTitle2="---"
ContextTitle3="Font Colors"
ContextAction3=["SomeAction"]
ContextTitle4="Font Names"
ContextAction4=["SomeAction"]
ContextTitle5="GMail Account"
ContextAction5=["SomeAction"]
ContextTitle6="Weather Code"
ContextAction6=["SomeAction"]
ContextTitle7="RSS URL"
ContextAction7=["SomeAction"]

temp.jpg

[Alex Becherer]

good tip. thank you.
would be nice if the "Action=[]" would be unclickable.

now that the entries are no longer clipped, i noticed something else:

it doesn't display a single "&" character (due to Menu Access Key). i know i can use "&&" (maybe add this to the docs) but as the displayed variable is also used on other parts of the skin i'll have to change it.

looking forward on what will happen to this menu in the future. things like radiobuttons and checkboxes could be really cool.

[Alex Becherer]

leaving out some numbers breaks it.

Code: Select all

ContextTitle="#MenuConfigure#"
ContextAction=[]
ContextTitle11="#ButtonSettingsLocal#"
ContextAction11=["#@#settings\local.txt"]
ContextTitle12="#ButtonSettingsMail#"
ContextAction12=["#@#settings\mail.txt"]

[jsmorley]

leaving out some numbers breaks it.

Code: Select all

ContextTitle="#MenuConfigure#"
ContextAction=[]
ContextTitle11="#ButtonSettingsLocal#"
ContextAction11=["#@#settings\local.txt"]
ContextTitle12="#ButtonSettingsMail#"
ContextAction12=["#@#settings\mail.txt"]

You must not use "1" as the number for a context menu item. Use just ContextTitle, then ContextTitle2. The vanilla "ContextTitle" is the implied "1". This behavior is the same as MeasureName / MeasureName2 on a meter.

Also, In general remember that this is driven by the "number" on ContextTitle / ContextAction. Any missing number will cause all items with a number greater to not display. This is the intended behavior, to allow "turning off" the menu by simply setting the ContextTitle of an item to "", or using !SetOption to remove it, and all items below it (logically, above it in number) will be disabled.

[jsmorley]

looking forward on what will happen to this menu in the future. things like radiobuttons and checkboxes could be really cool.

It is not our intention to extend this into those kinds of areas at this time. Aside from the complexities of storing and using the "states" of those kinds of controls in a persistent way in the context menu, we are hesitant to build too much functionality into the menus and have this get out of control in the sense of what Rainmeter is and does. We see the context menus as an extension of the "launcher" concept that is one of the things Rainmeter does really well, and not more at this time.

This goes back to the discussions about adding things like drag and drop and pull-down menus and radio buttons and slider controls to the core Rainmeter. It is our contention that Rainmeter is not an application development environment, and that we risk having to change in a drastic (and maybe not good) way to support some kind of "event driven" paradigm instead of the "update driven" model Rainmeter lives in.

You never know what the future holds though...