It is currently August 19th, 2022, 9:08 pm

[Feature] SendErrors=0

Report bugs with the Rainmeter application and suggest features.
User avatar
Jax
Posts: 95
Joined: June 7th, 2021, 11:46 am

[Feature] SendErrors=0

Post by Jax »

SendErrors=Bool would be applied to MeterStyles, Functions, Measures and Meters, which would prevent errors related to that object's ini syntax be hidden from the debug window. This would be particularly useful for skins like Droptop and JaxCore which has no way to prevent redundant errors due using inline functions and section references which does not update on the first tick of the skin. Let me know if you have any questions! :thumbup:
User avatar
Yincognito
Rainmeter Sage
Posts: 4778
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature] SendErrors=0

Post by Yincognito »

I'm all for this one, especially for unwanted errors related to whether images exist on the drive, or a correct regex failed, or an inactive skin is deactivated (not sure if the latter is an error or just a warning, but anyway).

An alternative would be to just uncheck showing errors or whatever in the About / Log window, but that unfortunately would also hide the actually relevant errors from the user...
User avatar
Active Colors
Moderator
Posts: 1173
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany

Re: [Feature] SendErrors=0

Post by Active Colors »

Yincognito wrote: July 27th, 2022, 8:04 am I'm all for this one, especially for unwanted errors related to whether images exist on the drive, or a correct regex failed, or an inactive skin is deactivated (not sure if the latter is an error or just a warning, but anyway).

An alternative would be to just uncheck showing errors or whatever in the About / Log window, but that unfortunately would also hide the actually relevant errors from the user...
"Unwanted" is a subjective and fragile concept. You might be a honest and skilled skin developer who can be sure which errors are necessary and which are not. But can I be sure in what you are sure? I don't want to go into the depths of phenomenology, but briefly speaking, your perception about what is "unwanted" is just yours only, and even if somebody shares your judgement, you can't be sure that they think the same way you think.

Other case: any skin creator, be they professional or beginner, might use this option to hide any crucial errors and warnings without knowing the consequences. Or maybe they poorly designed the skin that it shows numerous errors in the log; instead of fixing the errors they simply disable them in the skin.

Anyhow, nobody can't guarantee about how one uses this lever.

That said, in my opinion, giving a Ruling Ring is not safe in hands of unskilled developers. It is even worse in hands of those who are skilled.

I think it is better to deal with various (say, the ones that are the most popular) "unwanted errors" case by case.

There should be an elegant solution that would prevent things going wrong. As we all know, if something can go wrong, it will go wrong.

I understand that such "unwanted" errors create frictions while developing skins. I think the skins that are already released and final are meant to be used without looking at the log. And skins that are in development or in the process of debugging and fixing are meant to be examined through the log without hiding any warnings, even if those warnings are "undesired". They also motivate to find ways to prevent such errors (or write a bug report ;-) ).
User avatar
Yincognito
Rainmeter Sage
Posts: 4778
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature] SendErrors=0

Post by Yincognito »

Active Colors wrote: July 27th, 2022, 10:26 am "Unwanted" is a subjective and fragile concept. You might be a honest and skilled skin developer who can be sure which errors are necessary and which are not. But can I be sure in what you are sure? I don't want to go into the depths of phenomenology, but briefly speaking, your perception about what is "unwanted" is just yours only, and even if somebody shares your judgement, you can't be sure that they think the same way you think.

Other case: any skin creator, be they professional or beginner, might use this option to hide any crucial errors and warnings without knowing the consequences. Or maybe they poorly designed the skin that it shows numerous errors in the log; instead of fixing the errors they simply disable them in the skin.

Anyhow, nobody can't guarantee about how one uses this lever.

That's said, in my opinion, giving a Ruling Ring is not safe in hands of unskilled developers. It is even worse in hands of those who are skilled.

I think it is better to deal with various (say, the ones that are the most popular) "unwanted errors" case by case.

There should be an elegant solution that would prevent things going wrong. As we all know, if something can go wrong, it will go wrong.

I understand that such "unwanted" errors create frictions while developing skins. I think the skins that are already released and final are meant to be used without looking at the log. And skins that are in development or in the process of debugging and fixing are meant to be examined through the log without hiding any warnings, even if those warnings are "undesired". They also motivate to find ways to prevent such errors (or write a bug report ;-) ).
Yes, I agree with you 100%, I even wanted to mention the fact that such features could be abused, but for some reason forgot to do it. What's "unwanted" for some might be wanted by others indeed, I meant that from both a personal and an abstract point of view. Personal because some of the things producing those "errors" are actually intentional in my case, and showing them incorrectly induces the thought that something is functioning wrong which isn't the case. Abstract because some of those errors have less potential to be truly useful (in developing or in regular skin usage, doesn't matter), either way you look at them.

The simplest example I can think of is the error about a missing image. Now if that image is not the background one and controlling the size of the skin, the error can be unwanted and not critical in cases where, for example, you want to display an image only if exists or it has been downloaded from the internet, say for a weather radar, or some dynamic dock where you don't go bazooka to create dozens of "default" images for dock items or subitems that might not exist (since it's a dynamic dock in the first place).

Now that you mentioned it, it's not only "unwanted" that is being subjective, but "redundant" as well, at least to some extent. They might be redundant for Droptop or JaxCore or for any other similar skin (including some that we worked on, as you probably recall), but they might not be for a bunch of other cases. This is similar to how division by 0 is treated in Javascript, where it doesn't yield an error but produces the result of "Infinity" (a legit constant in JS) which is more or less accurate since the limit of such a division does indeed tend to (plus or minus) Infinity; some folks might consider such a division by 0 error redundant if that result is what they intentionally aimed for, other folks might not consider it redundant since it alerts the developer that an "impossible" (according to conventions, which again are subjective to some extent) operation has taken place and needs an exception handling routine.

Funny thing is that I used "unwanted" just to decribe how the errors looked from someone making such a suggestion ... trying to avoid the subjectivity of calling them "redundant" (which has a stronger conotation). Guess it didn't make that much of a difference in the end, LOL - although I agree with what you said, of course. :D
And of course, any developer decision on whether to implement such a feature or not is also subjective to a degree. Obviously, in theory only users can be subjective, a product (whether it's a skin or even Rainmeter) is always what it is and developers can freely decide how it should look and feel... except for cases where they can't because of other products or partially subjective decisions. :sly:
User avatar
Active Colors
Moderator
Posts: 1173
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany

Re: [Feature] SendErrors=0

Post by Active Colors »

Yincognito wrote: July 27th, 2022, 12:29 pm Yes, I agree with you 100%, I even wanted to mention the fact that such features could be abused, but for some reason forgot to do it. What's "unwanted" for some might be wanted by others indeed, I meant that from both a personal and an abstract point of view. Personal because some of the things producing those "errors" are actually intentional in my case, and showing them incorrectly induces the thought that something is functioning wrong which isn't the case. Abstract because some of those errors have less potential to be truly useful (in developing or in regular skin usage, doesn't matter), either way you look at them.

The simplest example I can think of is the error about a missing image. Now if that image is not the background one and controlling the size of the skin, the error can be unwanted and not critical in cases where, for example, you want to display an image only if exists or it has been downloaded from the internet, say for a weather radar, or some dynamic dock where you don't go bazooka to create dozens of "default" images for dock items or subitems that might not exist (since it's a dynamic dock in the first place).

Now that you mentioned it, it's not only "unwanted" that is being subjective, but "redundant" as well, at least to some extent. They might be redundant for Droptop or JaxCore or for any other similar skin (including some that we worked on, as you probably recall), but they might not be for a bunch of other cases. This is similar to how division by 0 is treated in Javascript, where it doesn't yield an error but produces the result of "Infinity" (a legit constant in JS) which is more or less accurate since the limit of such a division does indeed tend to (plus or minus) Infinity; some folks might consider such a division by 0 error redundant if that result is what they intentionally aimed for, other folks might not consider it redundant since it alerts the developer that an "impossible" (according to conventions, which again are subjective to some extent) operation has taken place and needs an exception handling routine.

Funny thing is that I used "unwanted" just to decribe how the errors looked from someone making such a suggestion ... trying to avoid the subjectivity of calling them "redundant" (which has a stronger conotation). Guess it didn't make that much of a difference in the end, LOL - although I agree with what you said, of course. :D
And of course, any developer decision on whether to implement such a feature or not is also subjective to a degree. Obviously, in theory only users can be subjective, a product (whether it's a skin or even Rainmeter) is always what it is and developers can freely decide how it should look and feel... except for cases where they can't because of other products or partially subjective decisions. :sly:
Yes I totally understand that by "unwanted" you meant "redundant" and I agree about them being redundant to some extent. What I don't agree with is simply letting users hide those errors. Although it is very simple to make an option which would suppress all skin errors, it is quite inadequate to hide errors.
  • The error with deactivating an inactive config — Rainmeter is technically not wrong that the config is not running at the moment, but it is not a fatal error because the config actually exists.
  • The error with an image that has not been downloaded yet — Rainmeter is technically not wrong that the image is absent at the moment, but it is not a fatal error because it is being downloaded.
Rainmeter at the moment does not make difference between "fatal error" and "not fatal error". A fatal error would be when you would make a mistake in the file name and Rainmeter wouldn't be able to locate it.

That's why I proposed that these situations should be resolved case by case.
  • When unloading an existing but inactive config - instead of the fatal error that the config is not found, Rainmeter should show a notice that the config actually exists but is not running. A fatal error would be when you make a mistake in the config name and Rainmeter can't find it.
  • When downloading an image which doesn't exist yet - instead of the fatal error that the image is not found, Rainmeter should show a notice that the image is downloading.
Maybe not with the exact same wording, but with the idea that by teaching Rainmeter to understand the situations better - it would provide better logs.

I described this idea in the related thread https://forum.rainmeter.net/viewtopic.php?t=41055.
User avatar
Yincognito
Rainmeter Sage
Posts: 4778
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature] SendErrors=0

Post by Yincognito »

Active Colors wrote: July 27th, 2022, 5:47 pm Yes I totally understand that by "unwanted" you meant "redundant" and I agree about them being redundant to some extent. What I don't agree with is simply letting users hide those errors. Although it is very simple to make an option which would suppress all skin errors, it is quite inadequate to hide errors.
  • The error with deactivating an inactive config — Rainmeter is technically not wrong that the config is not running at the moment, but it is not a fatal error because the config actually exists.
  • The error with an image that has not been downloaded yet — Rainmeter is technically not wrong that the image is absent at the moment, but it is not a fatal error because it is being downloaded.
Rainmeter at the moment does not make difference between "fatal error" and "not fatal error". A fatal error would be when you would make a mistake in the file name and Rainmeter wouldn't be able to locate it.

That's why I proposed that these situations should be resolved case by case.
  • When unloading an existing but inactive config - instead of the fatal error that the config is not found, Rainmeter should show a notice that the config actually exists but is not running. A fatal error would be when you make a mistake in the config name and Rainmeter can't find it.
  • When downloading an image which doesn't exist yet - instead of the fatal error that the image is not found, Rainmeter should show a notice that the image is downloading.
Maybe not with the exact same wording, but with the idea that by teaching Rainmeter to understand the situations better - it would provide better logs.

I described this idea in the related thread https://forum.rainmeter.net/viewtopic.php?t=41055.
Ah, yes, making those errors warnings is perfectly reasonable. For most people, an error is a problem that causes a program (or a skin, in this case) to not being able to continue, or at least not within the related section. I guess I'm on the error = fatal side of things. Anyway, for me personally it's more of a nuissance, I would only be concerned if I had tons of users on my skins, something I almost intentionally avoided to minimize the hassle in trying to please everyone...