While I completely agree that the skinner shouldn't have to care about this stuff, the problem is the disconnect in that the built in function parser receives only a string to parse. By the time it gets it the string is already formed by piecing together the info labels that the skinner uses. Thus, if the string isn't already suitably escaped, the built-in parser is going to get it wrong.
I can't recall the exact details, but I'm fairly sure that there wasn't an (easy) alternative, else ofcourse I would have done it. I'll take another look - no promises on how long it'll take to do this, as I'm quite busy atm.
thanks for feedback. Few comments from my side
$ESC moves parsing string logic to the last instance that has nothing to do with coding - UI design. I don't know what are the reasons why XBMC is parsing strings inside $INFO and not taking it verbatim, I don't know why comma is being used as parameter separator inside $INFO. The way I see it is that this all should be handled before reaching skin. I have no idea what's going in background and I don't really want to know. I would like to _design_ if possible leaving all non related things to programmers as I have no control and knowledge about them.
I'm following commits through RSS ATM and yes it's far from ideal but bigger problem is that even if I see them I may interpreting them in a wrong way. For instance:
https://github.com/xbmc/xbmc/pull/124 - I have read as not concerning me as I don't use skin.properties in that way.
Let's be honest - there is almost a zero chance that any skinner would think as: hey I'm trying to solve recently added layout on home screen, but wait.. I've seen commit about $ESC some months ago. Hmm.. This I better use because some character could decide to use comma in his path and since that's probably being hidden in this <onclick>PlayMedia("$INFO[Window.Property(LatestMovie.5.Path)]")</onclick> I'll better use them.
Last but not least I would like to be sure when skin related part ends and XBMC code begins for trouble shooting purposes. It is already very messy and confusing for user as they are often sent from skin thread to script and/or xbmc code threads and back again in order to find where their problems are coming from.
On 28. 2. 2012, at 20:52, ronie wrote:
On 28-02-12 11:27, Predrag Mitić wrote:
> Use $ESCINFO rather than $INFO
> When was this changed? Consider me dumb, but except for recently added example I have no idea where else should it be used?? I just don't get it.
> Do skins really need to think about this kind of issues?
> Why don't we post such things to forum? It is very hard to follow this list as info gets mixed with code.
$ESCINFO was added about 10 months ago:
some info on why it was added can be found on the PR:
the usecase is not only passing an infolabel to playmedia, basically it should be used when you pass an infolabel
that may contain either quotes or commas, to a built-in function.
i stumbled upon this issue last year when i was trying to copy an infolabel to a windowproperty.
for example: SetProperty(MoviePlot,$INFO[ListItem.Plot])
since the movie description is likely to contain a comma, the built-in function will fail in this case
as it will interpret it as multiple arguments being passed to it.
it's likely this info never hit the forum, as i either only used trac to report the issue or discussed it
with some of the devs on irc... can't remember :-)
currently the best way to stay up-to-date with skin engine changes is to keep an eye on the commits on git
or check the timeline on trac. i understand many skinners consider this to be far from ideal, so i'm planning
to start a thread in the skin-dev forum after eden, where we can collect all skin related changes for frodo.
that way, everyone should have an easy overview of what's new and which things have changed.
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
Xbmc-addons mailing list