The Arc Menu Launcher

[closer2thelung]

Hey everyone. Just wanted to get some feedback on my latest skin.

You can view it here: http://www.deviantart.com/art/The-Arc-Menu-Launcher-V-1-2-453991154

I posted it a while ago on deviant art but never here. I just updated the file and figured I would share it with everyone.

Any comments, suggestions or criticisms are welcome! Thanks!

[TweaknFreak]

Straight down to business.

Advantages-
1. Nice concept, overall.
2. Offers users to change editable options in the .inc file.

Disadvantage-
1. Config coding is tremendously long, as a result of which CPU usage bumps up. This is highly non-user friendly especially when the Update is set to 1000.

Remedy-
Break the total config in small parts. That menu.ini had 1068 lines ! That is huge. Split the CPU,RAM usage roundlines to a different config, the launcher to another. Then you can define MeterStyle s and create meters from there. That would reduce the number of lines to a great extent. Moreover the measures that need to be Updated only on Refresh, add UpdateDivider=-1 to them. The measures that need to be updated not that often put a moderate UpdateDivider on them. After reding this post go through the Rainmeter Manual again and lookup the key points I told. I think that it will help you.

BTW, try to have a look at Enigma. You will learn a lot about how much modular you can make your configs.

[jsmorley]

Really, having one 1000-line skin or 5 200-line skins makes no difference at all as far as how much CPU the overall effort uses in Rainmeter. I'm not opposed to breaking up big skins into smaller ones based on functionality, in fact I strongly encourage it, but that is mostly to make the skins easier to understand and maintain. Not much to do with optimization.

I also caution that going too far with the concept of skin "granularity", with tons of .ini and especially .inc files can actually end up making a suite far, far harder to understand and maintain, with minimal or no benefit. There is a fine line where you can end up putting things in @Include files just because you can, and it can make for a suite that at the end of the day only you can ever modify, since untangling the Christmas lights is just more than a new user is capable of, and experienced users just won't bother with it.

The suggestion to use UpdateDivider to ensure that measures are only updating when they really need to is the most effective way to optimize a complicated skin or set of skins.

[closer2thelung]

Hey I took your suggestions and played around with the update values and processor bar. It runs sooo much faster now. I re-uploaded the fixed skin. I am still a novice with rainmeter so I really appreciate all the help! Thanks!

[TweaknFreak]

I'm not opposed to breaking up big skins into smaller ones based on functionality, in fact I strongly encourage it, but that is mostly to make the skins easier to understand and maintain. Not much to do with optimization.

But don't you think that breaking up in small Configs gives the user a greater choice to disable the ones that are more CPU polling. One can always bring 'em up by MouseOverAction or Click actions, and then deactivate them. This results in less meters and measures updating simultaneously, thereby saving resources.

[jsmorley]

But don't you think that breaking up in small Configs gives the user a greater choice to disable the ones that are more CPU polling. One can always bring 'em up by MouseOverAction or Click actions, and then deactivate them. This results in less meters and measures updating simultaneously, thereby saving resources.

Assuming you are going to have some running and some not at any given time, and that you will want some user interaction to "enable" or "disable" them, then sure. For me, that would be annoying to the point of useless. I just want my skins that monitor things to be there on my desktop, as if they were just an active part of the wallpaper, and stay out of my grill. I certainly don't want to have to hover over or click on things to see what is what.

It all depends on what your skins are doing and is almost 100% personal preference though. There are a couple of skins I run that normally display minimal information, then display more details when moused over. However, I have no interest in my skins requiring any "work" in order to have them be of value. Then they just wouldn't meet my needs.

With the exception of that dock / launcher at the bottom of my screen, not one of my skins is anything like an "app" that I have any interest in having to interact with to get value out of them.

2014-06-29_174829.jpg

2014-06-29_180624.jpg

I break my skins up into:

- Clock
- System Info
- Network Info
- Hardware Temperatures
- Weather
- GMail
- Recyle Bin
- Dock / Launcher

Breaking up into separate skins by functionality is a very good thing, as I said before. There can be times, depending on how you want things to behave, that it even can make things use less resources, as you say. For me, breaking them up is mostly about making them easier to maintain and position separately. Not so much for any performance gain.