It is currently March 28th, 2024, 2:14 pm

Custom Context Menus

Changes made during the Rainmeter 2.5 beta cycle and earlier.
Alex Becherer

Re: Custom Context Menus

Post by Alex Becherer »

i see what you mean.

an idea (i don't know wether it is possible in Windows):

similar to the dashes for a separator: let a ContextTitle leading with this character "✔" display a checkbox and this character "❍" display a radiobutton on the left. this should be enough to do some nifty things with variables.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Custom Context Menus

Post by jsmorley »

Alex Becherer wrote:i see what you mean.

an idea (i don't know wether it is possible in Windows):

similar to the dashes for a separator: let a ContextTitle leading with this character "✔" display a checkbox and this character "❍" display a radiobutton on the left. this should be enough to do some nifty things with variables.
I'm not sure I see the value. From my personal view, I would not want to implement any Windows "control" unless it worked and was used in a very standard way consistent with the behavior in any Windows "application". What is the sense of two radio buttons that don't understand what their purpose in life is, to be a logical single thing with multiple options with one "selected".

We in any case can't store or use the "state" of a checkbox or radio button today, and a refresh of the skin would just lose any changes made. Rainmeter in and of itself doesn't have any idea what a checkbox or radio button is. So unless we made this a lot more capable, (see my previous post about my hesitation on that) you would need to manually create a complex action that uses !SetOption / !SetVariable combined with some "toggle" of the value of something to react to the change in state, while using !WriteKeyValue to make the state "persistent". This feels a bit like a bag on the side of the machine to me.

Oh and by the way, nothing says you can't do the above now, at least in the sense of checkboxes, by just passing the checkmark as a part of the title and turning it off and on with !SetOption on the ContexTitleN. Still a horrible kludge in my view however...

There may be something here, just not sure what at this point. We will explore a bit as we go on.
Alex Becherer

Re: Custom Context Menus

Post by Alex Becherer »

there wouldn't be a "state" per se.

just a display of one if the ContextTitle starts with that character. the ContextTitle would of course be a variable or measure. so clicking on it would do what ever it does and also change the value of that Measure/variable from "✔Use Celsius" to "Use Celsius" for example.

all this is of course not adding any functionality to what it is already capable. it would just look more polished.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Custom Context Menus

Post by jsmorley »

Alex Becherer wrote:there wouldn't be a "state" per se.

just a display of one if the ContextTitle starts with that character. the ContextTitle would of course be a variable or measure. so clicking on it would do what ever it does and also change the value of that Measure/variable from "✔Use Celsius" to "Use Celsius" for example.

all this is of course not adding any functionality to what it is already capable. it would just look more polished.
Well, let's see what comes of any discussions about this in the team. I can see your point in the sense of an author-driven "visual" indicator as a check mark or selected radio button (although at least for radio button I think this is an abuse of the standard intent, a radio button generally is to chose one of two or more items, not a "toggle" of a single item), but I'm personally a bit uncomfortable that the actual functionality is not driven in any way by what will look like a Windows "control", but will in fact do absolutely nothing without a pretty complex ContextAction that reacts to the click, determines or toggles the "state" of something, (you clicked me, what does that mean I should do?) and has a way to make the change "persistent". I think this is a very "narrow" and to be honest "crippled" way of implementing, and would have appeal to only a really small percentage of the Rainmeter audience.

Another option is to allow a "user defined" icon for each item (ContextIconN=SomeIcon.ico), so you can have a check mark, a selected radio button, or a rainbow pony as the icon for an item and turn them on and off as you like. We initially rejected this idea as we will in fact end up with rainbow ponies, but I'll bring it up again to see what folks think.
User avatar
Active Colors
Moderator
Posts: 1251
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany
Contact:

Re: Custom Context Menus

Post by Active Colors »

Is it possible to create several custom context menus on different zones of one skin?
User avatar
smurfier
Moderator
Posts: 1931
Joined: January 29th, 2010, 1:43 am
Location: Willmar, MN

Re: Custom Context Menus

Post by smurfier »

Active Colors wrote:Is it possible to create several custom context menus on different zones of one skin?
http://rainmeter.net/forum/viewtopic.php?p=78131#p78131
User avatar
Akiyamka
Posts: 6
Joined: March 22nd, 2012, 4:40 am

Re: Custom Context Menus

Post by Akiyamka »

In my humble opinion, the result was too many items from the menu. Probably would have been correct to the possibility of creating a separate menu is bound to another mouse button (eg Mouse3). Or, as one of the options in the event to add custom menu items, turn off the main line into one.
1.jpg
User avatar
Infinimbal
Posts: 2
Joined: December 14th, 2013, 9:04 pm
Location: Colorado, USA
Contact:

Re: Custom Context Menus

Post by Infinimbal »

While the thread is admittedly a bit old, I thought this would be an appropriate place to post some tidbits I learned through a bit of tinkering with context menus today.

I decided that a skin I was working on could use an optional background to help define it on lighter wallpapers. Rather than have a totally separate variant for this purpose, I opted for a context menu item that would toggle the background on and off. However, since disabling one context menu option disables all of its successors, it's not really possible to set up a pair of context menu items that toggle each other's visibility - one inevitably breaks the other. Thankfully, I managed to put together a fairly simple solution with no more than a variable and a calc measure!

Code: Select all

[Rainmeter]
Update=1000
ContextTitle=Enable Background
ContextAction=!SetVariable BackgroundState 1

[Variables]
BackgroundState=0

[MeasureBackgroundState]
Measure=Calc
Formula=#BackgroundState#
IfBelowValue=1
IfBelowAction=[!SetOption MeterBackground Hidden 1][!SetOption Rainmeter ContextTitle "Enable Background"][!SetOption Rainmeter ContextAction "[!SetVariable BackgroundState 1]"]
IfAboveValue=0
IfAboveAction=[!SetOption MeterBackground Hidden 0][!SetOption Rainmeter ContextTitle "Disable Background"][!SetOption Rainmeter ContextAction "[!SetVariable BackgroundState 0]"]
DynamicVariables=1

[MeterBackground]
Meter=Image
W=100
H=100
SolidColor=100,000,100,120
DynamicVariables=1
Hidden=1

[MeterForeground]
Meter=Image
X=25
Y=25
W=50
H=50
SolidColor=155,255,255,255
Put simply, what's happening here is that the #BackgroundState# variable acts as a binary switch to tell the skin whether the background should be hidden (0) or visible (1). [MeasureBackgroundState] reads this variable and uses it to trigger the appropriate IfActions, setting [MeterBackground]'s hidden option and then changing the context menu to allow you to reverse the effect. Note that ContextTitle and ContextAction don't *need* to be explicitly set in the [Rainmeter] section (the IfActions will do that for you based on the initial value of #BackgroundState#), but they probably *should* be to prevent confusion if/when you include additional context menu items.
Context Menu Enable.jpg
Context Menu Disable.jpg
I imagine this sort of toggle could be used for all sorts of binary effects by people much smarter than I (I've only been using Rainmeter for about a week, so I may not even know about a better solution), but I figured I'd share my use case and solution here for those interested in making a context menu toggle switch. It's worth noting that Rainmeter 3.1's IfConditions may offer more intuitive language for this once that version goes live.
MikeG621
Posts: 87
Joined: March 18th, 2013, 1:59 pm

Re: Custom Context Menus

Post by MikeG621 »

You can omit the Calc altogether. If you invert the meaning of BackgroundState (so 1 is hidden, 0 is visible) under [MeterBackground] you can just use Hidden=#BackgroundState#, the ContextTitle can read "Toggle Background" so it never has to change, and then ContextAction can be "!SetVariable BackgroundState (#BackgroundState#-1)*-1" (so when it's hidden, it'll go to (1-1)*-1=0, and when visible it'll go to (0-1)*-1=1)

Code: Select all

[Rainmeter]
Update=1000
ContextTitle=Toggle Background
ContextAction=!SetVariable BackgroundState (#BackgroundState#-1)*-1

[Variables]
BackgroundState=1

[MeterBackground]
Meter=Image
W=100
H=100
SolidColor=100,000,100,120
DynamicVariables=1
Hidden=#BackgroundState#

[MeterForeground]
Meter=Image
X=25
Y=25
W=50
H=50
SolidColor=155,255,255,255
Now, this will produce a nesting effect on the String value of BackgroundState, so if you look in the Rainmeter>About>Skins>Variables listing after a few times it'll look like "(((((1-1)*-1-1)*-1-1)*-1-1)*-1-1)*-1", but it works.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Custom Context Menus

Post by jsmorley »

MikeG621 wrote:Now, this will produce a nesting effect on the String value of BackgroundState, so if you look in the Rainmeter>About>Skins>Variables listing after a few times it'll look like "(((((1-1)*-1-1)*-1-1)*-1-1)*-1-1)*-1", but it works.
You can do the same thing with a conditional formula, so you don't get that stacking up of the value of the variable.

Code: Select all

[Rainmeter]
Update=1000
ContextTitle=Toggle Background
ContextAction=[!SetVariable BackgroundState "(#BackgroundState# = 0 ? 1 : 0)"][!UpdateMeter MeterBackground][!Redraw]

[Variables]
BackgroundState=0

[MeterBackground]
Meter=Image
W=100
H=100
SolidColor=100,000,100,120
DynamicVariables=1
Hidden=#BackgroundState#

[MeterForeground]
Meter=Image
X=25
Y=25
W=50
H=50
SolidColor=155,255,255,255
The reason why this works, when things in the [Rainmeter] section cannot be "dynamic", is that !bangs (like !SetVariable) are always dynamic, no matter where they are used.
Post Reply