[Suggestions] Two new settings

[ScreamerBG]

Hi,

I'd like to suggest two small but valuable features at least from my POV.

First is to add a setting that changes the doubleclick behavior of the Rainmeter tray icon, which would make major difference for "On desktop" users that use Rainmeter as desktop extension, rather than normal app.
Every time I want to access the Rainmeter settings I doubleclick the icon (the majority of users expect that the tray icon doubleclick would open the settings - Skype, MSN, NOD32, MS outlook... so many apps use this principle), and every time I do my whole desktop fades out and then fades in or, if I'm using a web browser like I am currently while writing this post, nothing happens at all.
The behavior has been changed with the latest beta (r955) and the configuration menu was removed on doubleclick. Which makes me to believe such option can be added in the Rainmetter settings.
Also, it's quite annoying to get all my desktop icons hidden, as at some point Rainmeter gets confused and I end up either having the desktop icons visible or I having the Rainmeter skins visible, but not both visible in the same time. The only way to correct this is to first show my desktop icons, quit Rainmeter and then start it again.

Second is to add a global "On desktop" option in Rainmeter settings, just like there is the "Disable dragging" global behavior.
Having tons of skins and using them in "On desktop" mode can take quite some time to configure all to be positioned on "On desktop".
I'm also hoping that this would fix the behavior that I have explained in my previous bug report, where the skins layer positioning (not the Z one, but between them) gets messed up and which can only be fixed by opening the menu, changing the load order from something else on one of the skins, then restoring the value (I guess that's forcing Rainmeter to re-render) and glosing the menu.

Thanks in advance.

[jsmorley]

Hi,

First is to add a setting that changes the doubleclick behavior of the Rainmeter tray icon, which would make major difference for "On desktop" users that use Rainmeter as desktop extension, rather than normal app.
Every time I want to access the Rainmeter settings I doubleclick the icon (the majority of users expect that the tray icon doubleclick would open the settings - Skype, MSN, NOD32, MS outlook... so many apps use this principle), and every time I do my whole desktop fades out and then fades in or, if I'm using a web browser like I am currently while writing this post, nothing happens at all.
The behavior has been changed with the latest beta (r955) and the configuration menu was removed on doubleclick. Which makes me to believe such option can be added in the Rainmetter settings.
Also, it's quite annoying to get all my desktop icons hidden, as at some point Rainmeter gets confused and I end up either having the desktop icons visible or I having the Rainmeter skins visible, but not both visible in the same time. The only way to correct this is to first show my desktop icons, quit Rainmeter and then start it again.

None of this is true with Rainmeter out of the box. I don't know what some skin / suite of skins is doing in your Rainmeter.ini, or if you are running some 3rd party utility that is effecting the system tray, but let me be clear. The Rainmeter tray icon works like this:

On a single or double click of the Rainmeter tray icon, the "Manage" panel will be opened. Nothing else will happen. Nothing will fade in or out. Rainmeter has nothing at all do do with "Desktop icons" and will not make them either visible or invisible, it doesn't know or care that you even have desktop icons like shortcuts, "My Computer" etc.

On a right click of the Rainmeter tray icon, the Rainmeter context menu will be popped up. Nothing else will happen.

None of this has been changed in any way in the new beta 2.2 of Rainmeter.

The first thing I would do is use the Rainmeter context menu, then "Edit Settings". See if there are any "TrayExecute" statements in the [Rainmeter] section of Rainmeter.ini. If there are, like "TrayExecuteL=!RefreshApp" or something, that is what is causing your behavior. If not, then I really don't know what else to say. The behavior you describe is not how Rainmeter works.

[poiru]

This is all due to Omnimo (the latest version of Omnimo "fixes" this feature/problem). You should follow jsmorley's advice to remove the TrayExecuteL= and TrayExecuteM= lines in Rainmeter.ini to restore default behaviour.

Having tons of skins and using them in "On desktop" mode can take quite some time to configure all to be positioned on "On desktop".

This will be added at some point.

[jsmorley]

In the meantime, doing this from the command line will work:

"C:\Program Files\Rainmeter\Rainmeter.exe" !ZPos -2 *

Or in a skin:

LeftMouseUpAction=!ZPos -2 *

Both will set all active, currently loaded skins to "On Desktop" with one command.

[ScreamerBG]

None of this is true with Rainmeter out of the box. I don't know what some skin / suite of skins is doing in your Rainmeter.ini, or if you are running some 3rd party utility that is effecting the system tray, but let me be clear. The Rainmeter tray icon works like this:

On a single or double click of the Rainmeter tray icon, the "Manage" panel will be opened. Nothing else will happen. Nothing will fade in or out. Rainmeter has nothing at all do do with "Desktop icons" and will not make them either visible or invisible, it doesn't know or care that you even have desktop icons like shortcuts, "My Computer" etc.

On a right click of the Rainmeter tray icon, the Rainmeter context menu will be popped up. Nothing else will happen.

None of this has been changed in any way in the new beta 2.2 of Rainmeter.

The first thing I would do is use the Rainmeter context menu, then "Edit Settings". See if there are any "TrayExecute" statements in the [Rainmeter] section of Rainmeter.ini. If there are, like "TrayExecuteL=!RefreshApp" or something, that is what is causing your behavior. If not, then I really don't know what else to say. The behavior you describe is not how Rainmeter works.

Hi again,

After quick investigation of the issue I figured the source of the problem - the Omnimo skin was using the tray click handlers of Rainmeter to hide/unhide the desktop icons. After removing the handlers the behavior you described has restored and now works flawlessly, thank you for that.
Also, thanks for the !Zpos hint which I will probably bind to the background skin and make it so all accidental clicks would invoke it.
And I'm also hoping that you would add the "On desktop" option some time soon.

[ScreamerBG]

In the meantime, doing this from the command line will work:

"C:\Program Files\Rainmeter\Rainmeter.exe" !ZPos -2 *

Or in a skin:

LeftMouseUpAction=!ZPos -2 *

Both will set all active, currently loaded skins to "On Desktop" with one command.

Using your trick I was finally able to reproduce the problem I described here http://rainmeter.net/forum/viewtopic.php?f=14&t=9942
You can reproduce it by doing the following:
1) Load few skins, preferably the default which comes with Rainmeter
2) Notice their load order. If you're using the illustro theme, then the clock should be at the bottom of the load list and the welcome message should be at the top (right click the Rainmeter icon, it should show them)
3) Edit the most bottom skin by adding this "LeftMouseUpAction=!ZPos -2 *" in the [Rainmeter] section (in the default case illustro/Clock)
4) Move the most top skin over the most bottom which you just edited (drag illustro/Welcome over illustro/Clock)
5) You should notice that the most bottom skin (illustro/Clock) fonts are getting dark grey as it's in the bottom
6) Click over the most bottom skin and then repeat step 4
7) It's visible that the most bottom skin is now on top of the ex-most top one (illustro/Clock over illustro/Welcome) as the fonts appear as they are usually - very much white to me

I made a little video which uses the exact steps listed above http://www.youtube.com/watch?v=e9DqtuU6QC0
Now, an interesting fact is that the LoadOrder is not taken into account either.

Hope this helps

[jsmorley]

LoadOrder
This determines the order in which the configs are loaded. Values can be positive or negative. Configs will load starting with the one with the lowest value for LoadOrder, ending with the highest. Configs loaded first are below those loaded last, for example: Three configs having LoadOrder=-1, LoadOrder=2 and LoadOrder=5 would load the configs in that order, with the config with LoadOrder=-1 appearing beneath the one with LoadOrder=2 which is in turn beneath the config containing LoadOrder=5. If two configs have the same value for LoadOrder, they are then loaded in alphabetical order. LoadOrder must be set manually in Rainmeter.ini by selecting "Edit Settings..." from the tray context menu.

Note: The value of LoadOrder has no bearing on what the position of the config is, i.e. "On Desktop", "Normal, "Topmost", etc. Configs in these positions will continue to appear in the same manner, with LoadOrder only affecting how skins in the same position interact with each other. That is to say, configs set to "Topmost" will always appear above configs set to "Normal", but two configs in "Topmost" will layer themselves according to their LoadOrder value.

If you have skins that sit on top of each other, the most reliable way to set the Z position they are loaded in (assuming all are set to "On Desktop" is to use the LoadOrder= setting for each. This can be done in Manage for the skin or by Edit Settings in the Rainmeter context menu.

Just set any skins that should be "behind" to a LoadOrder=-1 and leave ones that are either alone or should be in "front" to LoadOrder=0 (the default).

[ScreamerBG]

[snip]

If you have skins that sit on top of each other, the most reliable way to set the Z position they are loaded in (assuming all are set to "On Desktop" is to use the LoadOrder= setting for each. This can be done in Manage for the skin or by Edit Settings in the Rainmeter context menu.

Just set any skins that should be "behind" to a LoadOrder=-1 and leave ones that are either alone or should be in "front" to LoadOrder=0 (the default).

Just tried it by setting the clock to LoadOrder -1 and then setting the welcome message to LoadOrder 0.
Then repeated everything I described earlier and the issue still remains - the Clock appears on top of the Welcome message after invoking "!ZPos -2 *" from any skin.
Again, the load order is not taken to account after "!ZPos -2 *" no matter if it has negative or positive values.
It's like it's rendering it all backwards on "!ZPos -2 *" and then corrects itself if you open the menu of any skin and just change its Load Order to anything and then return the previous value.

[jsmorley]

Just tried it by setting the clock to LoadOrder -1 and then setting the welcome message to LoadOrder 0.
Then repeated everything I described earlier and the issue still remains - the Clock appears on top of the Welcome message after invoking "!ZPos -2 *" from any skin.
Again, the load order is not taken to account after "!ZPos -2 *" no matter if it has negative or positive values.
It's like it's rendering it all backwards on "!ZPos -2 *" and then corrects itself if you open the menu of any skin and just change its Load Order to anything and then return the previous value.

You might need to send a !RefreshApp after you set the ZPos that way, so it reloads the skins and uses the LoadOrder for them.

[ScreamerBG]

You might need to send a !RefreshApp after you set the ZPos that way, so it reloads the skins and uses the LoadOrder for them.

Isn't it supposed that Rainmeter would show constant behavior after invoking a command? Currently as it seems after ZPos modification Rainmeter stays in quite "uncertain" state.
If you restart it, then it will be okay. If you modify a skin ZPos manually (through the Edit menu), it will still be okay too.
But if you decide to change the ZPos internally (!ZPos -2 *) it won't. It would fail to restore its normal behavior and unless you do something like the described above it would remain bugged.
It's another questionnaire is why it bugs when the ZPos initially was -2 to both skins and so _no_ ZPos values have been changed.
Just something about the ZPos procedure fails badly.