I have the same problem very often, never have been the type of "just three sentences".^^Yincognito » Today, 2:41 am
I think the length of my replies is the problem - I tend to make my posts longer than optimal in order to cover everything I want to transmit.
So, I'll keep it shorter this time, to make it easier: I don't think your suggestion about colors in the current form is the best idea for the tooltips of my skins, which is a real pity because otherwise similar coloring to the main skin makes perfect sense. (...) I just need to find a way to implement it properly, without potential drawbacks in other areas of the code.
The main obstacle here is, like explained in the other thread, the fact that regex doesn't care about the meaning of the pattern. Since the latter are so diverse because the data and its logic are also diverse in the tooltips, that would mean I'd have to use different patterns for tooltips of different skins, something I wanted to avoid all along (one tooltip with a very generalized and abstract structure is best in this case).
I understood that when you later wrote about how data is fetched. I only wanted to complete the first two suggestions in a no-way-to-missunderstand-anything clear way.
Regarding your code structure and your interest to avoid individual skin-based tooltips I wrote the suggestion in the end of my last post, instead of creating more diversity keeping colors more simple to fit different scenarios without drawbacks. Then there is no reason not to use the ones you already have in the menu, only they won´t resemble the same sort of output. But in that scenario it wouldn´t be a problem and just fit the style of the suite.
Stating the self-evident agin? No, I know, you wanted it to be crystal clear after I asked about it. Surely not only how I would do it. That wouldn´t be helpful. Those questions I approach by a cumulation of starting with what I would want and then extending to what else others "could" want (very much standard approach). So about your asked "what if" scenario also regarding your post before:Not necessarily how you would do it, but you'd like it to be if you were an user of such a skin. A "what if" scenario, if you like.
That much was clear, sure, but it irritated me you writing about "cores" so I asked to avoid missunderstandings.Yincognito » Yesterday, 9:08 pm
But let's put it another way, hopefully crystal clear
I agree on the "noscroll". It´s a short and overall view with all necessary data accessed quickly on the fly, which can be useful to everybody, no matter if it´s a standard user, gamer, programmer...In other words, if I would scroll through logical cores, I wouldn't display the whole list of logical core frequencies, usages and temperatures when I'm on the single / overall physical processor that we all have, but I would instead display each logical core data in its own "navigation page", if you will, according to the scrolling. For example...
- no scroll: tooltip made of logical core count, frequency, usage, temperature for the single (or overall) physical processor
- scroll once: tooltip made of current logical core number aka 1, frequency, usage, temperature for the logical core number 1
- scroll twice: tooltip made of current logical core number aka 2, frequency, usage, temperature for the logical core number 2
... and so on ...
The disadvantages, as I said, are not viewing all core data on the same page anymore, and the counter for the average and period over which the average is measured not starting until the said logical core is scrolled over. The advantages are multiple and significant, at least in terms of development and efficiency, so I'd prefer it, as the skin designer. My question was what would you prefer, as a hypothetical user? Do you think this (scrolling over logical cores this way) would be acceptable / illustrative / match expectations or user needs?
But I disagree on scrolling for each logical processor step by step.
I get the dilemma, because I suppose you would do that by changing the number of the logical processor to fetch per scrolling and regex [similar to how you helped me with my drives - and that much I get from your "Note"] and this method would reduce the code to 1/32 (since you wrote 32 is the maximum you want to do) besides the regex and scrollaction parts.
I cannot think of any reason why someone would want to look at one logical processor only. Maybe there are scenarios, but if so those would be very specialised (if I am forgetting about a common scenario maybe someone here can point it out) and I don´t think that´s the kind of users you´re adressing.
A seperated "single view" would deny the option to compare the utilization of logical processors, while a comparison would allow to imagine the processing of workloads better, maybe even unused capacities or small mistakes/damages (but that I don´t know about, that´s guessing, I would ask my trusted tech guru (I don´t have one anymore)). Possibly overclocking could be monitored easier (whether it´s working the way it should). All that by just one look.
And I would think of people who like keeping it minimal with your suite, but at the same time also find pleasure in the "Oh, look at this, that many (logical) processors I have - and there are their values", besides those idiots who like to brag about it (not knowing more cores (and therfore more logical processors) don´t always mean better performance), pretty much like "Hi, I am Ben and I have an iPhone".
I know, your suite is all about minimalism, distributing lot of information while keeping the visuals as small as possible (that´s why I agreed on not using graphs or something like that), but having a little glance here and there would be the thrill to some users.
I hope that helps at least a little thinking of a few perspectives.
Not overkill, but the, who doesn't like a skin made of just a couple of measures?