It is currently April 23rd, 2024, 8:16 am

Parsed string from weather.com

Get help with creating, editing & fixing problems with skins
User avatar
jsmorley
Developer
Posts: 22629
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Parsed string from weather.com

Post by jsmorley »

Mor3bane wrote:I just noticed the statement that the WebParser is no longer a plugin but a measure.
I will edit for the future after consulting the RM Manual to ensure I am doing it right now.
It's not important, either way works exactly the same. WebParser has been changed from a plugin to a measure, but that is something that is only important to Rainmeter internally. The same code is executed in Rainmeter if you use the "plugin" or "measure" syntax in a skin. I am not a fan of making any kind of issue out of it with users, as the VAST majority of existing skins treat it as a plugin, and it is not our intention to make anyone think those should be changed or are in any way wrong.

[MyPluginMeasure]
Measure=WebParser

Is the technically most "correct" way to do it.

I have not moved it to the Measures area of the documentation for the same reason. I just don't think it is worth getting people in a lather that they are doing something wrong in their existing skins, and people are just used to finding WebParser under Plugins. This may change someday, but my inclination is to do so when we are done changing ALL built-in plugins into measures. Then only 3rd-party plugins will still be "plugins", and the distinction will be useful.
User avatar
Mor3bane
Posts: 943
Joined: May 7th, 2016, 7:32 am

Re: Parsed string from weather.com

Post by Mor3bane »

Am I doing this correctly? It doesnt seem to be working with either method shown below:

Code: Select all

[MeasureTimeStamp]
Measure=Plugin
Plugin=Plugins\WebParser.dll
Url=[MeasureCurrent]
StringIndex=15
UpdateDivider=50

[MeterTimeStamp]
Meter=String
MeasureName=MeasureTimeStamp
FontFace=#Font#
FontColor=#ColorZ#
FontSize=20
StringAlign=Center
X=168
Y=85
Text=%1
RegExpSubstitute=1
Substitute="^\[(.*) .*$":"\1"
AntiAlias=1

Code: Select all

[MeasureTimeStamp]
Measure=Plugin
Plugin=Plugins\WebParser.dll
Url=[MeasureCurrent]
StringIndex=15
RegExpSubstitute=1
Substitute="^\[(.*) .*$":"\1"
UpdateDivider=50

[MeterTimeStamp]
Meter=String
MeasureName=MeasureTimeStamp
FontFace=#Font#
FontColor=#ColorZ#
FontSize=20
StringAlign=Center
X=168
Y=85
Text=%1
AntiAlias=1
My DevArt Gallery

There are many ways to be different - there is only one way to be yourself - be amazing at it

The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.
User avatar
balala
Rainmeter Sage
Posts: 16162
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Parsed string from weather.com

Post by balala »

I doubt the first code would work properly, because the Substitute option (along with RegExpSubstitute) belongs to measures, not to meters. Adding them to a meter doesn't have effect on the shown string.
But not knowing the whole code, is hard to tell other, than general things. Could you please post the whole code, or at least the URL of the parent WebParser measure?
User avatar
balala
Rainmeter Sage
Posts: 16162
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Parsed string from weather.com

Post by balala »

jsmorley wrote:It's not important, either way works exactly the same. WebParser has been changed from a plugin to a measure, but that is something that is only important to Rainmeter internally. The same code is executed in Rainmeter if you use the "plugin" or "measure" syntax in a skin. I am not a fan of making any kind of issue out of it with users, as the VAST majority of existing skins treat it as a plugin, and it is not our intention to make anyone think those should be changed or are in any way wrong.

[MyPluginMeasure]
Measure=WebParser

Is the technically most "correct" way to do it.

I have not moved it to the Measures area of the documentation for the same reason. I just don't think it is worth getting people in a lather that they are doing something wrong in their existing skins, and people are just used to finding WebParser under Plugins. This may change someday, but my inclination is to do so when we are done changing ALL built-in plugins into measures. Then only 3rd-party plugins will still be "plugins", and the distinction will be useful.
I know for compatibility purposes, these measures must have to work even as plugin measures, but since they, in the newer versions of Rainmeter, are measures, I think this details should have to be mentioned in the help. It would be a good idea to the new users, to get used to create not WebParser plugin measures, but WebParser measures.
My opinion...
User avatar
fonpaolo
Moderator
Posts: 1387
Joined: April 11th, 2013, 8:08 pm
Location: Italy

Re: Parsed string from weather.com

Post by fonpaolo »

balala wrote:I know for compatibility purposes, these measures must have to work even as plugin measures, but since they, in the newer versions of Rainmeter, are measures, I think this details should have to be mentioned in the help. It would be a good idea to the new users, to get used to create not WebParser plugin measures, but WebParser measures.
My opinion...
I concur with balala, maybe, just start with "better use this syntax instead of that" and slowly start adding from now on, it's deprecated...
Exactly what happened to what's now deprecated.
User avatar
jsmorley
Developer
Posts: 22629
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Parsed string from weather.com

Post by jsmorley »

Here is my take on it.

First, it's important to remember that it doesn't make a bit of difference to Rainmeter if you use the Measure=Plugin / Plugin=WebParser or the Measure=WebParser syntax. The result is exactly the same.

We could move the documentation for WebParser from ..Plugins\WebParser to ..Measures\WebParser. Then we can start reminding folks about the change when we help on the forums. Mind you, we have no right to bug people about this as long as our advice conflicts with the documentation.

The upside

1) It would technically be the correct thing to do.
2) It might eliminate some very rare confusion when WebParser doesn't work as expected and the user says "Oh, the .dll is missing from the ..Rainmeter\Plugins folder on my system! How do I get it back?"

The downside

1) There are probably 10,000 links in the forums, hundreds of links internally in the documentation, and an unknown number of links other places that all point to ..Plugins\WebParser. Every one of those will break if we don't do some work to deal with it.
2) When someone is learning Rainmeter, they almost always use existing skins as the starting point. Guess what the syntax is going to be in those?
3) Are we really going to nag every single new user, and virtually every existing user, who writes or changes a skin using WebParser?
4) Since the syntax for every existing skin a user tears apart is going to be ..Plugins\WebParser, where in the docs are they likely to look for it?

My suggestion

We have changed a handful of plugins into measures. There is some benefit internally in Rainmeter, both from an efficiency and code-maintenance standpoint. However, it doesn't matter either way to end-users.

It is our intention that eventually all "built-in" plugins will be changed to measures, and only "3rd-party" plugins will remain plugins. I agree that measures should be under measures and plugins under plugins in the documentation. However, this is an ongoing process. I'd rather do the work required to deal with the boatload of links in the forums, reddit, deviantART and everywhere else one time, not make it a career.

When we are done converting everything, I'd rather do one big push to make it clear that now plugins are ALWAYS about "3rd-party", and that is what the entire plugin idea is about. I'm not in favor of doing this piecemeal, nagging them about WebParser and NowPlaying now, and starting to nag them about the next one we change then. The forums are going to become annoying to the point of hostility.

I'm not even going to say which ones have been converted and which ones haven't, as I'd rather not add more chum to the water...;-)

So I suggest that we ignore this entire issue, until we are ready to make the change, all at once, in a logical way.

It's not up to me, but personally, I still use Measure=Plugin / Plugin=WebParser any time I'm helping on the forums, and in any skins I distribute. It's just not a discussion I want to have every single time I'm helping someone, and I just find it distracting from the real problem I'm trying to help with. That is what I intend to continue doing until we complete the process of changing plugins to measures.

As I said, it's not up to me really, and if the majority want to attack this as the changes are made, changing the documentation, dealing with the links, and addressing this with users as we help them, then so be it. I can see the argument for doing that. I would vote against it myself.
User avatar
fonpaolo
Moderator
Posts: 1387
Joined: April 11th, 2013, 8:08 pm
Location: Italy

Re: Parsed string from weather.com

Post by fonpaolo »

jsmorley wrote:...
It's not up to me, but personally, I still use Measure=Plugin / Plugin=WebParser any time I'm helping on the forums, and in any skins I distribute. It's just not a discussion I want to have every single time I'm helping someone, and I just find it distracting from the real problem I'm trying to help with. That is what I intend to continue doing until we complete the process of changing plugins to measures.
...
I still do the same all the time. :17denial :lol:
...however, before or after, we'll have to reach a point where using the "correct" syntax would start confusion for the reason we've used a measure instead of a plugin and why.
User avatar
balala
Rainmeter Sage
Posts: 16162
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Parsed string from weather.com

Post by balala »

Just one more thought, if allowed.
Things around us are evolving. Same way, Rainmeter is evolving, too. That's a normal process. That's why I say that slowly - slowly, we should have to evolve together with Rainmeter and should have to start using the new syntax, even if the old one is still supported and probably still will be, for long time. The compatibility requires this.
A warning could be posted in the help to tell users that WebParser, NowPlaying and/or eventually the other plugins (when will be actual) became measures. If we, who are helping people here on the forum (excuse me I included myself into this category, but I hope it's true), don't start to use the new syntax, then who will do it? How the usual users will get used to use it?
Even on post here on the forum, I definitely use the new Measure=WebParser syntax, instead of the plugin syntax. I consider this a better solution, to show the users the new way of using this measure / plugin.
Sorry, I didn't want to be un-polite, but this is my opinion.
User avatar
fonpaolo
Moderator
Posts: 1387
Joined: April 11th, 2013, 8:08 pm
Location: Italy

Re: Parsed string from weather.com

Post by fonpaolo »

Yes, after all, how many times we've seen skins posted, still using all the deprecated syntax from long ago?
All those !Rainmeter... and so on. :17what
User avatar
Mor3bane
Posts: 943
Joined: May 7th, 2016, 7:32 am

Re: Parsed string from weather.com

Post by Mor3bane »

Thanks for the loads of advice on what syntax to use.

However, the regexp is in the below code:

Code: Select all

[MeasureCurrent]
Measure=Plugin
Plugin=Plugins\WebParser.dll
UpdateDivider=80
Url=http://wxdata.weather.com/wxdata/weather/local/#Location#?cc=*&unit=f&dayf=1
RegExp="(?siU).*<locale>(.*)</locale>.*<ut>(.*)</ut>.*<ud>(.*)</ud>.*<us>(.*)</us>.*<up>(.*)</up>.*<ur>(.*)</ur>.*<loc id="(.*)">.*<dnam>(.*)</dnam>.*<tm>(.*)</tm>.*<lat>(.*)</lat>.*<lon>(.*)</lon>.*<sunr>(.*)</sunr>.*<suns>(.*)</suns>.*<zone>(.*)</zone>.*<cc>.*<lsup>(.*)</lsup>.*<obst>(.*)</obst>.*<tmp>(.*)</tmp>.*<flik>(.*)</flik>.*<t>(.*)</t>.*<icon>(.*)</icon>.*<bar>.*<r>(.*)</r>.*<d>(.*)</d>.*<wind>.*<s>(.*)</s>.*<gust>(.*)</gust>.*<d>(.*)</d>.*<t>(.*)</t>.*<hmid>(.*)</hmid>.*<vis>(.*)</vis>.*<uv>.*<i>(.*)</i>.*<t>(.*)</t>.*<dewp>(.*)</dewp>.*<moon>.*<icon>(.*)</icon>.*<t>(.*)</t>.*<ppcp>(.*)</ppcp>.*"
Seeing no reason to create a shorter version, since I continually add features to my weather widgets nb- the timestamp im working on now. I just do not need the date or the region code. :)
My DevArt Gallery

There are many ways to be different - there is only one way to be yourself - be amazing at it

The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.