ColorSelector

[Nookz]

I've done it! I finished my first skin!
A ColorPicker based on the original one by jsmorley, made to look and function more like the photoshop counterpart. It is however not using the HSBLib from the original ColorPicker. It is also extremely easy to integrate into any Skin or Suite and features a robust amount of functions.

colorselector.png

Features:
- Interactive interface
-Draggable sliders for every value
-Interactive H&V range selection
-MouseWheel interaction with Sliders and Input fields
-Adjustable Mousewheel increments
-3 level of zoom for the ColorPicker mode
-LivePreview mode to update your skin in real-time
-Various Hotkeys to facilitate interaction
-Various Toggles to customize the skin
-Manual interface
-Input fields for all values
-Copy values in one click
-Minimized Mode to save space and return quickly where you left off

Attribution & Plugins:
ColorPicker by jsmorley
CursorColor 1.3 by jsmorley
Mouse 3.2.0 by NighthawkSLO
Hotkey 1.0.0.12 by Brian Ferguson

colorselectorMini.png

Installation
1.Place the ColorSelector folder inside the Root folder of your skin/suite
2.Make sure YOUR Skin/Suite as a @Resources folder and a Variables.inc file. Make sure that the color variable(s) that you want to modify are stored inside that Variables.inc file.
3.Open the .ini file of YOUR skin and add these bangs to the the button/image/text/whateveryouwant that will trigger the ColorPicker:

Code: Select all

[!DeactivateConfig "#ROOTCONFIG#\ColorSelector" "ColorSelector.ini"][!WriteKeyValue Variables CSN "#*Color1*#" #ROOTCONFIGPATH#\ColorSelector\@Resources\Variables.inc"][!WriteKeyValue Variables OldColor "#Color1#" #ROOTCONFIGPATH#\ColorSelector\@Resources\Variables.inc"][!WriteKeyValue Variables RGB #Color1# "#CURRENTPATH#\ColorSelector\@Resources\Variables.inc"][!ActivateConfig "#ROOTCONFIG#\ColorSelector" "ColorSelector.ini"]

4.Change all 3 instances of Color1 for the Name of your color variable.
ex: if the color variable that is inside your Variables.inc file is called MyVar, #*Color1*# would become #*MyVar*# and #Color1# would become #MyVar#. Do not modify anything else in here.
--You're done!

Optional:If you need to update multiple skin and want to handle that directly inside the ColorPicker code, open the ColorSelector.ini and locate the "CUSTOMIZABLE MEASURES" section near the top. For Both CONFIRMCOLOR and REVERTCOLOR, add the other config you want to update with the following this format: [!Setvariable [VarName] "#RGB#" #ROOTCONFIG#\YourOtherSkinName] for CONFIRMCOLOR and [!Setvariable [VarName] "#OldColor#" #ROOTCONFIG#\YourOtherSkinName] for REVERTCOLOR
**Command2 is also the place where you can add more actions to be taken when confirming the colors**
**By default the skin will close when clicking on CONFIRM. comment out Comand4 if you wish to disable this**


Download

ColorSelector_SampleSkin_1.0.1.rmskin

ChangeLog
1.0.1
-Minor bug fixes
-Simplified lua script
-Removed unnecessary WriteKeyvalue

Preview **Outdated**



Things to note
-If one of your monitor is scaled, you will need to open the Overlay.ini file and adjust the W value to the total width of all your monitors combined.
For example, if you have two monitors:
Monitor 1: 2560 width
Monitor 2: 3840 width
but your second monitor is upscale to 300%, Rainmeter will think that the total Width it's 3840 when it actually is 6400.
In this example you would change 'W=#VSCREENAREAWIDTH#' to 'W=6400'.
As far as I know this is a limit from Rainmeter and can't be automatically adjusted. If you known a way where I could automate this process, please let me know.

-When using the LivePreview, the modifications to your skin will not be permanent until you actually confirms them (with the button or by using ENTER)

-At first I was using a python script to generate a Range image on the fly based on the H value, but I figured that might not be ideal when comes times for other people to use the skin, so I opted to add the entire 360 Range as images. This makes for 3/4 of the size of the skin.. I think it still is reasonably low in size and ultimately only 1 of those is being used at all time, but if anyone thinks of a way to reduce this number, please let me know.

-As I mentioned in the beginning, this is my first skin. I tried my best to iron out all the bugs I found, but there might be things I didn't account for.. so let me know if you find any bugs and/or what I could Improve.
Special thanks to balala, Kurou, Yincognito and RicardoTM for helping me with the bug squashing!!

[balala]

2.Open the Plugin folder and copy paste the ones you need to your Rainmeter Plugin folder (usually C:\Program Files\Rainmeter\Plugins)

Good job and the skin looks well, however a few things should be added:

• The structure of your package is not the best one. When you create the .rmskin, you can upload the plugins using the Add plugin button:
  Installer.png
  When a user installs the package, the proper version of a such uploaded plugin, is copied into the appropriate folder. No need to let the users manually copy the needed file, because many users will make a mistake in copying the file.
• Rainmeter uses the C:\Program Files\Rainmeter\Plugins folder to keep the built-in plugins. The plugins added when installing skins are kept into the C:\Users\<YourName>\AppData\Roaming\Rainmeter\Plugins\ folder. This is an other reason why you shouldn't copy the plugins manually.
• The ColorPicker plugin, even if it is listed in your post, is not included into the package (into the ColorSelector\Plugins\ folder).

[Nookz]

Good job and the skin looks well, however a few things should be added:

• The structure of your package is not the best one. When you create the .rmskin, you can upload the plugins using the Add plugin button:
  Installer.png
  When a user installs the package, the proper version of a such uploaded plugin, is copied into the appropriate folder. No need to let the users manually copy the needed file, because many users will make a mistake in copying the file.
• Rainmeter uses the C:\Program Files\Rainmeter\Plugins folder to keep the built-in plugins. The plugins added when installing skins are kept into the C:\Users\<YourName>\AppData\Roaming\Rainmeter\Plugins\ folder. This is an other reason why you shouldn't copy the plugins manually.
• The ColorPicker plugin, even if it is listed in your post, is not included into the package (into the ColorSelector\Plugins\ folder).

Thks for the heads up! All updated now!^^

I didn't really use the ColorPicker Skin aside from as a general template as to what good colorpickers should do.
But I did use the CursorColor which I included in the skin as well as including it and the creator inside the options window
Unless I was unattentive and the colorpicker skin installed a other plugins that I've used? In this case please make sure to let me know. ^^

[balala]

I didn't really use the ColorPicker Skin aside from as a general template as to what good colorpickers should do.
But I did use the CursorColor which I included in the skin as well as including it and the creator inside the options window
Unless I was unattentive and the colorpicker skin installed a other plugins that I've used? In this case please make sure to let me know. ^^

The actual installer installs three plugins: CursorColor, HotKey and Mouse. This is alright as far as I can tell.
However not just to nitpick, but there is no need to add all those plugins one more into the root folder of your skin. I mean that the whole ColorSelector\Plugins\ folder is practically useless, because the plugins are stored into the Plugins folder on the root of the package, however the .dll files included into the ColorSelector\Plugins\ folder, even if not used, increase the size of the installer. I definitely would renounce to them, in order to get a package as small as possible.

[Nookz]

Again, very true. Updated the files and the first post accordingly.

[balala]

Again, very true. Updated the files and the first post accordingly.

Hope you don't mind, but I again saw some things in the code, which I have to mention:

• It is extremely, but extremely not recommended to refere to the @Resources folder by the #CURRENTPATH#@Resources\ expression. We always refere to this folder by the #@# variable. For instance your @Include option, added to the [Variables] section is looking this way: @include=#CURRENTPATH#@Resources\Variables.inc. Its better (and shorter) form is @include=#@#Variables.inc. Let Rainmeter to know what is the path of the folder. It definitely knows.
  Such form of the path of @Resources folder is used in many places along your code. Recommend to replace all of them.
• IfConditions have to be entirely numeric. This means that strings are not allowed in these options. In the IfCondition options of the [LoopCheck] measure you've used the value of measure itself (for instance IfCondition=LoopCheck=0). This doesn1t always work, you should have to include the name of the measure into brackets, to get it as a section variable (note that this requires to add the DynamicVariables=1 option to the measure as well). But instead of this, if you are absolutely positive that the measure is always returning numbers (and it seems it does, what it is returning being set by the OnUpdateAction option of the [Loop] measure, as numbers), you should have to convert this measure into a Calc measure, which would not require to use the name of the measure as section variable into the IfConditions:

  Code: Select all

  [LoopCheck]
  Measure=Calc
  Formula=0
  IfCondition=LoopCheck=0
  IfCondition2=LoopCheck=1
  IfCondition3=LoopCheck=2
  IfCondition4=LoopCheck=3
  IfCondition5=LoopCheck=4
  IfCondition6=LoopCheck=5
  IfCondition7=LoopCheck=6
  IfCondition8=LoopCheck=7
  IfCondition9=LoopCheck=8
  IfCondition10=LoopCheck=9
  IfTrueAction=[!SetVariable Invalid 0][!CommandMeasure MeasureInputHex    "ExecuteBatch ALL"][!SetOption MeterLPHighLight Hidden 1][!UpdateMeterGroup HighLight]
  IfTrueAction2=[!SetVariable Invalid 1][!Setvariable tmp2 "#R#"][!CommandMeasure MeasureInputR "ExecuteBatch ALL"]
  IfTrueAction3=[!SetVariable Invalid 2][!Setvariable tmp2 "#G#"][!CommandMeasure MeasureInputG "ExecuteBatch ALL"]
  IfTrueAction4=[!SetVariable Invalid 3][!Setvariable tmp2 "#B#"][!CommandMeasure MeasureInputB "ExecuteBatch ALL"]
  IfTrueAction5=[!SetVariable Invalid 4][!Setvariable tmp2 "#H#"][!CommandMeasure MeasureInputH "ExecuteBatch ALL"]
  IfTrueAction6=[!SetVariable Invalid 5][!Setvariable tmp2 "#S#"][!CommandMeasure MeasureInputS "ExecuteBatch ALL"]
  IfTrueAction7=[!SetVariable Invalid 6][!Setvariable tmp2 "#V#"][!CommandMeasure MeasureInputV "ExecuteBatch ALL"]
  IfTrueAction8=[!CommandMeasure MeasureInputESCAPE "ExecuteBatch ALL"][!SetOption MeterOKHighLight Hidden 0][!SetOption MeterLPHighLight Hidden 1][!UpdateMeterGroup HighLight]
  IfTrueAction9=[!CommandMeasure MeasureInputENTER "ExecuteBatch ALL"][!SetOption MeterREVERTHighLight Hidden 0][!SetOption MeterOKHighLight Hidden 1][!UpdateMeterGroup HighLight]
  IfTrueAction10=[!CommandMeasure MeasureInputLP "ExecuteBatch ALL"][!SetOption MeterLPHighLight Hidden 0     ][!SetOption MeterREVERTHighLight Hidden 1][!UpdateMeterGroup HighLight]
  IfConditionMode=1
  UpdateDivider=-1
  Disabled=1

  Along with this you have to replace the OnUpdateAction option of the [Loop] measure as well, in order to set the Formula option of the Calc measure, instead of the String formula of the String measure: OnUpdateAction=[!SetOption LoopCheck Formula "[Loop]"][!UpdateMeasure "LoopCheck"].
• Whenever are you using a well defined background image (in this case this is the BG.png image, used into the [MeterBG] meter), the DynamicWindowSize=1 option is useless in ther [Rainmeter] section, because the background sets the size of the skin and that is not changing. I'd remove this option.
• Why are you using such a low Update value in the [Rainmeter] section (Update=50)? Doesn't seem to be needed, unless I missed something. I rewrote it to the default Update=1000 and everything seems to be alright. A low Update value loads the processor completely uselessly.

[Nookz]

Hope you don't mind, but I again saw some things in the code, which I have to mention:

I absolutely do not mind at all.

--

• It is extremely, but extremely not recommended to refere to the @Resources folder by the #CURRENTPATH#@Resources\ expression. We always refere to this folder by the #@# variable. For instance your @Include option, added to the [Variables] section is looking this way: @include=#CURRENTPATH#@Resources\Variables.inc. Its better (and shorter) form is @include=#@#Variables.inc. Let Rainmeter to know what is the path of the folder. It definitely knows.
  Such form of the path of @Resources folder is used in many places along your code. Recommend to replace all of them.

I've used #CURRENTPATH# simply because the @Resources folder it is referring to is most likely not going to be in the Root folder. I was under the impression that the #@#Variables.inc refers to the Root-level @Resources folder (Is this not the case?). Since the skin is almost always going to be in a subfolder (unless used as a standalone), I found it better to make sure it would always access the correct @Resources folder.
--

Whenever are you using a well defined background image (in this case this is the BG.png image, used into the [MeterBG] meter), the DynamicWindowSize=1 option is useless in ther [Rainmeter] section, because the background sets the size of the skin and that is not changing. I'd remove this option.

Good to know. I'll remove it.
--

Why are you using such a low Update value in the [Rainmeter] section (Update=50)? Doesn't seem to be needed, unless I missed something. I rewrote it to the default Update=1000 and everything seems to be alright. A low Update value loads the processor completely uselessly.

Personal preferences. I don't really see any significant load when I set it low, but I do see a improvement in the responsiveness of dynamic meters. There's also the fact that most meters (if not all?) and most measures are updated manually only when the user takes a action + it's not really meant to be open and running all the time (the minimzed version update is at -1 for example). But I do agree that I should set it to a higher default value just so that it's more accessible for people who already have many skins loaded or that could see this as problematic in one way or a other. I'll update that too.
--

But instead of this, if you are absolutely positive that the measure is always returning numbers (and it seems it does, what it is returning being set by the OnUpdateAction option of the [Loop] measure, as numbers), you should have to convert this measure into a Calc measure, which would not require to use the name of the measure as section variable into the IfConditions:

I dont have the code to check right now but 1.Yes I'm sure it always returns a numerical value. 2.I think the LoopCheck can also be set by some InputMeters. (since you can't set a Loop at a specific number but only reset it, which is why I had to make the Loop and LoopCheck as 2 seperate measure 3. I'm not sure I understand what you mean, isn't it already a Calc? Either way, I'm not sure if this is a real problem or if you are simply suggesting alternative way of doing it?
--

But, again, thks for the time you're taking looking, finding and reporting on all the errors my newb self could not find. It is much appreciated.
I will update the code as soon as I can (probably tomorrow)

[balala]

I've used #CURRENTPATH# simply because the @Resources folder it is referring to is most likely not going to be in the Root folder. I was under the impression that the #@#Variables.inc refers to the Root-level @Resources folder (Is this not the case?). Since the skin is almost always going to be in a subfolder (unless used as a standalone), I found it better to make sure it would always access the correct @Resources folder.

The @Resources folder always has to be in the root folder (in fact the proper term is rootconfig) of your skin. But your folder is right there, its path being Skins\ColorSelector\@Resources\. Doesn't matter where a .ini file is placed into the rootconfig, Rainmeter always resolves the #@# variable and get the @Resources folder placed into the root of your config. For instance, using the #@# variable into any of the ColorSelector\ColorSelector.ini, ColorSelector\Minimized\Minimize.ini or ColorSelector\Overlay\Overlay.ini skin leds you to the ColorSelector\@Resources folder, which this way is shared by all skins included into the ColorSelector config. You can1t have more @Resources folder into a single config (fortunately).

Personal preferences. I don't really see any significant load when I set it low, but I do see a improvement in the responsiveness of dynamic meters. There's also the fact that most meters (if not all?) and most measures are updated manually only when the user takes a action + it's not really meant to be open and running all the time (the minimzed version update is at -1 for example). But I do agree that I should set it to a higher default value just so that it's more accessible for people who already have many skins loaded or that could see this as problematic in one way or a other. I'll update that too.

Yep, right, this is a solution as well. I see you have lot of UpdateDivider=-1 options added to lot of sections. About the load, how a skin is loading the CPU depends on many things, for instance on how many and which skins do you have activated at a moment, what other apps are running in background and so on. Obviously you can leave it this way (with Update=50).

I dont have the code to check right now but 1.Yes I'm sure it always returns a numerical value. 2.I think the LoopCheck can also be set by some InputMeters. (since you can't set a Loop at a specific number but only reset it, which is why I had to make the Loop and LoopCheck as 2 seperate measure 3. I'm not sure I understand what you mean, isn't it already a Calc? Either way, I'm not sure if this is a real problem or if you are simply suggesting alternative way of doing it?

Unfortunately the IfConditions seem not to work on String measures. I definitely would be tempted to replace the String measures by Calc ones.

[Nookz]

The @Resources folder always has to be in the root folder (in fact the proper term is rootconfig) of your skin. But your folder is right there, its path being Skins\ColorSelector\@Resources\. Doesn't matter where a .ini file is placed into the rootconfig, Rainmeter always resolves the #@# variable and get the @Resources folder placed into the root of your config. For instance, using the #@# variable into any of the ColorSelector\ColorSelector.ini, ColorSelector\Minimized\Minimize.ini or ColorSelector\Overlay\Overlay.ini skin leds you to the ColorSelector\@Resources folder, which this way is shared by all skins included into the ColorSelector config. You can1t have more @Resources folder into a single config (fortunately).

That's the thing tho. If I add it to a different skin, then the folder I want to reference will be in a different place. ex:Skins\MyNewSkin\ColorSelector\@Resources\. #@#Variables.inc would look for it in Skins\MyNewSkinr\@Resources\. wouldn't it?
That's why I'm using currentpath method. It assures me that wherever the ColorSelector folder is placed, he can still find his own Variables.inc to get the variables it needs, but can also writekeyvalue to the Main Skin Variables.inc file (to apply the color changes) which will always be at #@#Variables.inc

Maybe I'm misunderstanding the concept, but it has worked for the example skin I've made so I don't think I do.

Unfortunately the IfConditions seem not to work on String measures. I definitely would be tempted to replace the String measures by Calc ones.

I'll watch for that in the future, but the IfConditions on this one string measure (LoopCheck) are definitely working as expected. I'll probably leave it like that but I keep this in mind for future skins. ^^

And since the only mod I ended up doing is the DynamicWindowSize change, i'll wait to update the download file. I'm thinking maybe i'll work on a palette feature this weekend so you can store some colors. ^^

[balala]

That's the thing tho. If I add it to a different skin, then the folder I want to reference will be in a different place. ex:Skins\MyNewSkin\ColorSelector\@Resources\. #@#Variables.inc would look for it in Skins\MyNewSkinr\@Resources\. wouldn't it?

The @Resources folder has to be placed into the root config. This means that in case of the Skins\MyNewSkin\ColorSelector config, the @Resources folder has to be located as Skins\MyNewSkin\@Resources\, not as Skins\MyNewSkin\ColorSelector\@Resources\. Unfortunately you can't use @Resources folder as ColorSelector\@Resources\, or in fact you can, but this @Resources folder is not the @Resources folder of your config. Same way, since this folder is not the @Resources folder, you could use any name for it. For instance, its name could be ColorSelector\MyOwnResources\. Obviously in this case you have to take care to use the name appropriately whenever are you trying to use a file from this MyOwnResources folder. See the second paragraph here.

That's the thing tho. If I add it to a different skin, then the folder I want to reference will be in a different place. ex:Skins\MyNewSkin\ColorSelector\@Resources\. #@#Variables.inc would look for it in Skins\MyNewSkinr\@Resources\. wouldn't it?
That's why I'm using currentpath method. It assures me that wherever the ColorSelector folder is placed, he can still find his own Variables.inc to get the variables it needs, but can also writekeyvalue to the Main Skin Variables.inc file (to apply the color changes) which will always be at #@#Variables.inc

If your skin (the appropriate .ini file) is located not in the root config (for instance the skin is Skins\MyNewSkin\ColorSelector\MySkin.ini) the #CURRENTPATH#@Resources\Variables.inc expression refers to the Skins\MyNewSkin\ColorSelector\@Resources\Variables.inc file. This file, even if it is in a folder called @Resources, is not placed into the @Resources folder of your config. The path of your @Resources folder in this case is Skins\MyNewSkin\@Resources. As said, the @Resources folder has to be in the root config. The advantages of using a this way located @Resources folder are listed on the above link.
It's always recommended to use the "normal" @Resources folder, not to create other @Resources folder, into sub-configs of the root config. Rainmeter definitely doesn't use those @Resources folders as the real @Resources folder.

I'll watch for that in the future, but the IfConditions on this one string measure (LoopCheck) are definitely working as expected. I'll probably leave it like that but I keep this in mind for future skins. ^^

Alright, leave it, if you want.