It is currently March 28th, 2024, 7:10 pm

problem hiding not existing cores per CPU measure

Get help with creating, editing & fixing problems with skins
Yue
Posts: 59
Joined: March 23rd, 2023, 1:10 pm

Re: problem hiding not existing cores per CPU measure

Post by Yue »

Yincognito » Today, 10:57 am
What do you mean by "in blocks"? You mean by item aka logical core instead of by category aka freqs-usages-temps? With lines [...] where values are grouped by the logical core they belong to? :???:
Exactly. I have no problem with jumping between categories back and forth since you aligned them all the same. But thinking of CPUs getting bigger and bigger eyes will have to jump long distances in the future that might become a problem one day. [thinking of the exponential technology development rates]. By the way using the colors on the values per category as you do in the small overview would make it even smoother when it comes to too many logical processors.
But that was just a spontanous thought when I looked at your screenshot, so never mind. :)
User avatar
Yincognito
Rainmeter Sage
Posts: 7025
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: problem hiding not existing cores per CPU measure

Post by Yincognito »

Yue wrote: May 12th, 2023, 7:00 pm Exactly. I have no problem with jumping between categories back and forth since you aligned them all the same. But thinking of CPUs getting bigger and bigger eyes will have to jump long distances in the future that might become a problem one day. [thinking of the exponential technology development rates]. By the way using the colors on the values per category as you do in the small overview would make it even smoother when it comes to too many logical processors.
How about this - what do you think?
ezgif.com-optimize.gif
I made two "core layouts" (one per "category", the other per "core"), toggled via middle click according to the user's preference. The coloring in the tooltip skins is mainly based on whether the part is an "title", "label", "value" or "unit" in the upper part of the tooltip, but I will take your suggestion into account, albeit that would probably raise some questions about how to apply it in the other tooltips, where the values are not limited to the 3 present here... :???:

Anyway, so far, your (implicit) suggestions have been excellent. Thanks! :rosegift:

P.S. I'll probably add a line showing the average over /and the time since the skin was loaded / refreshed in the upper part in most of the skins from my suite as well, since that helps in debugging stuff (or other skins) and overseeing their regular performance, for example when using a certain implementation over another (animations, I'm looking at you!). That will be a textual replacement of a histogram / line meter (like in SilverAzide's gadgets), but taking less space. I won't do that for cores, only for the main data in every skin, aka usages, transfer rates, etc. As of now, I only do this in the Rainmeter skin that monitors the CPU usage of Rainmeter, meaning that the code is already done, it just needs to be adjusted and implemented for the rest of the data in my skins.
You do not have the required permissions to view the files attached to this post.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
Yue
Posts: 59
Joined: March 23rd, 2023, 1:10 pm

Re: problem hiding not existing cores per CPU measure

Post by Yue »

Hi, my excueses, it has been a long weekend, I haven´t even seen my computer, but now...
Yincognito » May 12th, 2023, 8:42 pm
How about this - what do you think?
That looks good!
I would leave out the commata. The spaces between the values are good enough as a seperator and besides you get a greater space between the left and the right group in each line what would make the grouping more visual [besides the triangle you added]. Additionally, that saves space you might need on other tooltips with bigger content [don´t know, but you surely do].
I made two "core layouts" (one per "category", the other per "core"), toggled via middle click according to the user's preference. The coloring in the tooltip skins is mainly based on whether the part is an "title", "label", "value" or "unit" in the upper part of the tooltip, but I will take your suggestion into account, albeit that would probably raise some questions about how to apply it in the other tooltips, where the values are not limited to the 3 present here... :???:
The toggling is a great Idea. This way you can have both variants depending on what you want to compare or keep an eye on. In fact I planned something similar for my skins [but will do that later].

Regarding the colors - I thought so. I guess you do that by variables for the colors implemented by styles? Coloring in the tooltip equal to the way in the "menu" would make the design look more consistent and, since you always have two meters, one for the value, one for the unit, which would be combined in one meter then, I guess it would spare you nearly half the code lines on that. On the other hand it would be a big rework I guess...
Regarding the raising questions when there are more values I do not see the problem - the coloring [more or less] would be decided by the coloring in the menu.
Anyway, so far, your (implicit) suggestions have been excellent. Thanks! :rosegift:
You are very welcome. I am happy if the suggestions were of some help. :)
P.S. I'll probably add a line showing the average over /and the time since the skin was loaded / refreshed in the upper part in most of the skins from my suite as well [...]
Im excited what the part the post scriptum is about will look like. :)
User avatar
Yincognito
Rainmeter Sage
Posts: 7025
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: problem hiding not existing cores per CPU measure

Post by Yincognito »

Yue wrote: May 15th, 2023, 3:19 pm Regarding the colors - I thought so. I guess you do that by variables for the colors implemented by styles? Coloring in the tooltip equal to the way in the "menu" would make the design look more consistent and, since you always have two meters, one for the value, one for the unit, which would be combined in one meter then, I guess it would spare you nearly half the code lines on that. On the other hand it would be a big rework I guess...
Regarding the raising questions when there are more values I do not see the problem - the coloring [more or less] would be decided by the coloring in the menu.
Yes, the colors are controlled by variables that are applied in the styles, but the coloring in the "menu" (the little bar at the top, which is actually the main skin) is different from the coloring in the "tooltip" (the bigger skin at the bottom where details are shown on hover over the main skin's white title), because their structure is different. In the "menu" I have 4 or less meters that are sometimes merged depending on the length of what needs to be displayed in that skin (for the Processor one, these are the title, the usage, the temperature and the frequency, each with its own color), but in the "tooltip" there are only 3 meters irrespective of what "menu" I hover on (the icon image, the title and the content).

This means that the entire content in the "tooltip" (i.e. what's not the icon or the first line reserved for the tooltip title) is a single meter. The coloring is done via the String meter's inline options and - you guessed it, some regex -, and the alignment is done via the amount of spaces between "words" in the content string (which is why using a monospaced font is highly recommended in the tooltips, in order to not "break" the alignment there and require volatile spacing adjustments). I did this to avoid creating a tooltip skin for each main skin in the suite, and has nice benefits, since their layout is consistent with minimal effort. It's not a problem to change the coloring to a different system, since it's just about adjusting the few InlinePatternN options in the following style:

Code: Select all

[STooltipContentText]
ClipString=2
ClipStringW=#TooltipClipContentSize#
ClipStringH=#TooltipClipContentSize#
FontFace=#TooltipTextFace#
FontColor=#TooltipTertiaryValueTextColor#
StringEffect=#TooltipTertiaryValueTextEffect#
FontEffectColor=#TooltipTertiaryValueTextEffectColor#
FontSize=#TooltipTextSize#
AntiAlias=1
InlineSetting=Color | #TooltipPrimaryValueTextColor#
InlinePattern="(?siU)(?:^|\n|● +?)([^∆≡ ][^●[\x200B]\n]*)(?=  +?|\n|$)"
InlineSetting2=Color | #TooltipTitleTextColor#
InlinePattern2="(●|∆|≡)"
InlineSetting3=Color | #TooltipSecondaryValueTextColor#
InlinePattern3="(?siU)[\x200B]([^∆≡][^●[\x200B]\n]*)[\x200B]"
X=0r
Y=0R
Padding=#TooltipTextPaddingLeft#,#TooltipTextPaddingTop#,#TooltipTextPaddingRight#,#TooltipTextPaddingBottom#
the real problem is deciding on how to alternate colors in tooltips like this (especially the parts below the ● ● ● ● ● ● ● ● ● dividers):
Tooltip Skins.jpg
where the data being shown and its properties differ from each other considerably (yet they can be inserted into the same "framework", so to speak, due to the single tooltip skin being built in a such abstract and general manner, i.e. icon, title, content, from the start). Yes, I know that some of the parts below the dividers (like for memory or battery) could look better, but that's because Rainmeter still doesn't have a Justified alignment, so that's not under my control...
Yue wrote: May 15th, 2023, 3:19 pm I would leave out the commata. The spaces between the values are good enough as a seperator and besides you get a greater space between the left and the right group in each line what would make the grouping more visual [besides the triangle you added]. Additionally, that saves space you might need on other tooltips with bigger content [don´t know, but you surely do].
I wanted to leave out the commas to gain space as well, but while they can easily be removed, there won't be any space gained, because each of them will be replaced by a space (because of their format explained above). The reason is that I "reserve" 5 digit characters for the frequencies (99999 MHz seems like a reasonable maximum for quite some time, considering that the Guinness World Record for the highest CPU clock rate was "only" 8.42938 GHz in 2011 according to Wiki), 3 chars for the usage, and 3 chars for the temperatures, and they are all separated by two chars, of which one is a comma at this point. Removing the char for the comma entirely would leave just one char (now, a space) as the separator and that would be too less to avoid confusing one part with another (since one char is between the value and the unit as well).
Yue wrote: May 15th, 2023, 3:19 pm The toggling is a great Idea. This way you can have both variants depending on what you want to compare or keep an eye on. In fact I planned something similar for my skins [but will do that later].
Yeah, I was sure you'd like that - I like it too. Sometimes being undecided on layouts is a good thing, since you can provide different alternatives and let the user decide based on his needs.
Yue wrote: May 15th, 2023, 3:19 pm Im excited what the part the post scriptum is about will look like. :)
Well, it will be just another line in the text, but with a potential for improved observation because the variable nature of the data makes it difficult to estimate how much of an impact does something have on the CPU, GPU, and so on. Displaying averages along with the time they've been recorded is a way to solve that. I could add a histogram, but I'm more interested in functionality and purpose than in looks, especially in a minified suite, so the text based data will work just fine. I'll also probably add a Windows event log monitor and a network connections monitor to the suite in the future (I wanted to do them "real time" aka updated at 25 ms, but unfortunately it looks like I'll have to settle for a larger update interval of something like a couple of seconds).
You do not have the required permissions to view the files attached to this post.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
SilverAzide
Rainmeter Sage
Posts: 2588
Joined: March 23rd, 2015, 5:26 pm

Re: problem hiding not existing cores per CPU measure

Post by SilverAzide »

Yincognito wrote: May 15th, 2023, 6:19 pm
Perhaps you could have every row of data showing in a different color of the rainbow... :lol:

/joking ;-)
Gadgets Wiki GitHub More Gadgets...
Yue
Posts: 59
Joined: March 23rd, 2023, 1:10 pm

Re: problem hiding not existing cores per CPU measure

Post by Yue »

Yincognito » Today, 6:19 pm
In the "menu" I have 4 or less meters that are sometimes merged depending on the length of what needs to be displayed in that skin (for the Processor one, these are the title, the usage, the temperature and the frequency, each with its own color), but in the "tooltip" there are only 3 meters irrespective of what "menu" I hover on (the icon image, the title and the content).
"Procesor One"? I did not look at the code for my suggestion, but I guess this is the overall usage of the CPU [like CPU=0]? Everything else wouldn´t make sense in my opinion.

For now: I didn´t think of it being applied this way ["all-in-one-meter"], because it shortens the code ultimately but on the disadvantage of changability and sperate control .
I yet have to look closer at the code you posted. I have not learned about the InlineSetting-option until now [manipulating the text is something I planned to add later], but I get you are managing different colors within one meter that way, using regex to determine what color to use when.
The only solution to change the coloring in your case, IF [!] you want to make it equal to the menu bars, I can think of is changing the regex options, because you won´t want to redo the complete structure.

the real problem is deciding on how to alternate colors in tooltips like this (especially the parts below the ● ● ● ● ● ● ● ● ● dividers):

Are you just stating the problem you have with it or do you like to get feedback?

I wanted to leave out the commas to gain space as well, but while they can easily be removed, there won't be any space gained, because each of them will be replaced by a space (because of their format explained above). The reason is that I "reserve" 5 digit characters for the frequencies [...], 3 chars for the usage, and 3 chars for the temperatures, and they are all separated by two chars, of which one is a comma at this point. Removing the char for the comma entirely would leave just one char (now, a space) as the separator and that would be too less to avoid confusing one part with another (since one char is between the value and the unit as well).

That´s another reason why I would change the coloring. If the coloring in the tooltip would be done as on the bars there would be no need of [more] extra spaces. You even could leave it to one char between value and value sign [like "76 %"] and wouldn´t have to think about changing that and even something like "just" two chars [what then would be the minimum of "more" space thinking of the char between value and sign] would be enough space
because the coloring creates a seperating effect for the eyes.
Three examples [compared to the big screenshot]...

1. example: corresponding to the cpu bar
-"Logical Cores","Utilization","Frequency", "Temperature" - title color as "CPU" on the bar, because they are titles.
-the percentage value and the percentage sign in blue [= bar]
-the temperature value and the temperature sign in green [= bar]
-the frequency value and the rate in this orange [= bar]

2. example: corresponding to the Memory bar
2.1 first solution:
-"RAM Memory", "Disk Pagefiles", "Total Memory" - title color as "CPU" on the bar, because they are titles.
-the same goes for "Kingston Kf..." and "C:\pagefile.sys"
-the value and the value sign [in this case MB and behind that the percentage with its sign] for the RAM memory in blue [= bar], for Total Memory in green [= bar] for Disk Pagefiles in orange [= bar]
-the same way for the RAM Memory and Pagefile values and signs under the ● ● ● -dividers
2.2 second solution:
-"RAM Memory" + values + value signs in blue [= bar], i.E. the whole line
-"Disk Pagefiles" + values + value signs in orange [= bar], i.E. the whole line
-"Total Memory" + values + value signs in green [= bar], i.E. the whole line
-the same way for the RAM Memory and Pagefile values and signs under the ● ● ● -dividers

3. example: corresponding to the Player bar
-leave artist, album and title as they are [already = bar]
-everything beneath the ● ● ● -dividers I would turn white [= title] because it would give more focus on the details what is being played.
[by the way I liked how you integrated a few player options on mouse actions there]

If you imagine this, it´s irrelevant whether there is a comma or a triangle or nothing - or just two empty chars.
While reading this now and then you might have thought of using the "title" coloring more wouldn´t look that nice since the title would lose visual focus.
My first idea would be to use a[n additional] style on top of a style [the title style] or a totally new one to change one option or add one more.
Of course, at the moment I cannot replicate your structure using InlineSetting and regex, but I am sure you will get what I mean when I use an abstract example that "takes the long course", since it only would be a little addition to your regex line as far as I can imagine it right now:

Code: Select all

[style1]
fontname=[#Font1]
fontsize=[#Font1Size]
fontcolor=[#TitleColor]
StringStyle=Normal
StringAlign=left

[NewStyle]
fontcolor=[#StatColor]

[Meter.Title]
Meter=String
MeterStyle=style1
text=[#TitleName]

[Meter.OtherStat]
Meter=String
MeterStyle=style1 | NewStyle
Text=[OtherStat]
If that is not an option, whatever the reason, why not creating a new style and in order not to make it too colorful, using a light grey for "OtherStats"?
Yeah, I was sure you'd like that - I like it too. Sometimes being undecided on layouts is a good thing, since you can provide different alternatives and let the user decide based on his needs.
Confirmed. Totally parallel way of thinking here. ;-)
Well, it will be just another line in the text, but with a potential for improved observation because the variable nature of the data makes it difficult to estimate how much of an impact does something have on the CPU, GPU, and so on. Displaying averages along with the time they've been recorded is a way to solve that. I could add a histogram, but I'm more interested in functionality and purpose than in looks, especially in a minified suite, so the text based data will work just fine. I'll also probably add a Windows event log monitor and a network connections monitor to the suite in the future (I wanted to do them "real time" aka updated at 25 ms, but unfortunately it looks like I'll have to settle for a larger update interval of something like a couple of seconds).
Who cares if it´s "just another line"? I´m interested. Simple like that.
And sometimes a simple line or a number can be the result of big effort in the background. At least here I suppose there are many users who can tell about it.^^
I also have thought about averages and whether they can be useful. But in my case that´s too far away from my state of creating skins. There are too many other things I should do before even thinking about that any further.
By the way I don´t think something like a histogram would fit your suite, since it is ultra-minimalistic and relinquishes any big visual effect. It´s not about big design but details in short. A histogram would be discrepancy. As you wrote: "Text based data".

ps: Don´t ask me why my text sometimes becomes italic. I don´t know since I didn´t set that modifier...
Yue
Posts: 59
Joined: March 23rd, 2023, 1:10 pm

Re: problem hiding not existing cores per CPU measure

Post by Yue »

SilverAzide » Today, 9:00 pm
Perhaps you could have every row of data showing in a different color of the rainbow... :lol:
/joking ;-)
In my opinion...too modern.^^ But I remember someone who released a suite with bars which could look like a rainbow...what´s the name? ...something like "gadgets"... :Whistle
User avatar
Yincognito
Rainmeter Sage
Posts: 7025
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: problem hiding not existing cores per CPU measure

Post by Yincognito »

SilverAzide wrote: May 15th, 2023, 8:00 pm Perhaps you could have every row of data showing in a different color of the rainbow... :lol:

/joking ;-)
Nice one! :lol: I'll be like a nice color wheel...
Image
... when I'm done with them. :rofl:

Joking aside, I like your gadgets too much to copy their looks. Plus, data separation is not always by line in my skins. But yeah, why not, any suggestion is welcomed, it might spur better ideas, since I am aware that's an area that could benefit improvement. ;-)
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Yincognito
Rainmeter Sage
Posts: 7025
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: problem hiding not existing cores per CPU measure

Post by Yincognito »

Yue wrote: May 15th, 2023, 10:31 pm "Procesor One"?
[...]
ps: Don´t ask me why my text sometimes becomes italic. I don´t know since I didn´t set that modifier...
Yep, the Processor skin displays the overall CPU data, while its tooltip skin adds a couple more details to it, including core data - that's the same for all skins, according to their subject. Changeability is not a disadvantage in tooltips, it's actually easier this way (I could modify anything in the text or add any other meter if I wanted to), but separate control is indeed (but then, for monospaced text is irrelevant since I can replicate separation, while control is not needed because there are no mouse actions or anything requiring that in tooltips, they just receive and display textual data in a single measure called [MS_Rainmeter_PopulateTooltip] that's present in every main skin).

The feedback on colors is much appreciated, there are some very good ideas I'll have to think about. Guess I didn't capture the problem completely though - the question was what do I do with tooltip fields that are not displayed in the main skin, i.e. what color do I assign to them since there's no existing equivalent in the main skin (this happens mainly below the divider, hence my earlier mentioning).

Other than that, in the current implementation, the coloring in tooltips was meant to emphasize what the value is about (thus the blue of the "labels"), the value itself (thus the orange of the "value") and to separate it visually from the unit next to it (thus the green of the "unit") and make it more obvious. What I call "title" is actually the description of the skin (i.e. what the skin is about) and it's always the leftmost column / meter in the main skin and the topmost row / meter in the tooltip - it is colored white because what the skin / tooltip is about is the most important thing (a good analogy would be like a heading in MS Word, thus the title moniker). But yeah, your coloring logic makes sense... except for fields that don't have an equivalent in the main skin, as said above. For the record, colors are configurable, like most of the things in the skins, i.e. they're not hardcoded to white, blue, orange and green, they can be anything, but they should be only 4, unless I modify the Settings skin, something I'd like to avoid since it's the biggest one in the lot (lots of configurable variables and shit).

Agreed on the averages.

As for the style of your reply, the italic is because of this, by the way. You use square brackets instead of round ones to express afterthoughts, and when an opening square bracket is right before an i character, the italic formatting is applied, irrespective if it's not a single i between those brackets.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
Yue
Posts: 59
Joined: March 23rd, 2023, 1:10 pm

Re: problem hiding not existing cores per CPU measure

Post by Yue »

Yincognito » Today, 12:11 am
(...) Changeability is not a disadvantage in tooltips, it's actually easier this way (...), but separate control is indeed (...).
That was no criticism. I wrote that because I might miss something that isn´t or is possible with your approach when suggesting ideas since I like things more flexible but on the disadvantage of more code lines, of course.
what do I do with tooltip fields that are not displayed in the main skin, i.e. what color do I assign to them since there's no existing equivalent in the main skin (this happens mainly below the divider, hence my earlier mentioning).
There were two suggestions in my last post (described in the second example): I would use something that´s not as eyecatching as the title color and while you don´t want to get too colorful (expecially since you stated you don´t want to have a resemblance with SilverAzide´s Gadgets) I would use a color that´s going soft on the eyes (yeah, no red^^) like grey. A more neutral color (or at least as you already mentioned not more than another color) would divide the output - at the top the shortened details from the menu bar in full length in the tooptip, easy to recognize by using the same colors, on the other hand additional information at the bottom, easy to recognize be the fourth color not being so intrusive. I know your intention is to seperate different parts of contents there to ease the visual access. But too many color changes could have the opposite effect because of eyes then concentrating on these changes instead of what they resemble.
Other than that, in the current implementation, the coloring in tooltips was meant to emphasize what the value is about (thus the blue of the "labels"), the value itself (thus the orange of the "value") and to separate it visually from the unit next to it (thus the green of the "unit") and make it more obvious.
Sure. But you already have them seperated by the spacing char between value and sign and since they are aligned at the same x-position in each line, the same signs are all on one vertical axis. This vertical "repeating block" the eye recognizes automatically. Realising the sign in a different color is additonal work for the brain. So the key is the spacing char you already have. The eye then focuses automatically on the difference - the changing values, what is exactly your intention.
Those were the ideas I got on the fly. Maybe they can help you a little with your decisions. If you like an opinion on changes, feel free to ask. :)
What I call "title" is actually the description of the skin (i.e. what the skin is about) and it's always the leftmost column / meter in the main skin and the topmost row / meter in the tooltip - it is colored white because what the skin / tooltip is about is the most important thing
Now that you stated the obvious...thanks! :D Funny is, I do it same way.^^
As for the style of your reply, the italic is because of this [...]
Oh, great....then I will stick to the rounded ones to avoid that, although I don´t like them much. Thanks!