[kraqh3d]

i like the idea of referencing something else, but make it more "xmlish" (to quote jmarshall's earlier comment.)  i'm thinking of a new construct to hold these referenced info items. here's a quick example:

<window>
...
<controls>
..
 <control>
    <id>1</id>
    <type>fadelabel</type>
    <visible>player.hasaudio</visible>
    ....
    <label>$ref(1)$ref(2)</label>
    <label>$ref(3)$ref(4)</label>
    <label>$ref(5)$ref(6) & $ref(7)$ref(8)</label>
 </control>
 ...
</controls>

<referencelist>
 <items>
   <item>
     <id>1</id>
     <label>12345</info>
     <!--time: --!>
   </item>
   <item>
     <id>2</id>
     <info>musicplayer.time</info>
   </item>
   <item>
     <id>3</id>
     <label>12346</info>
     <!--remaining: --!>
   </item>
   <item>
     <id>4</id>
     <info>musicplayer.duration</info>
   </item>
   <item>
     <id>5</id>
     <label>12347</info>
     <!--duration: --!>
   </item>
   <item>
     <id>6</id>
     <info>musicplayer.remaining</info>
   </item>
   <item>
     <id>7</id>
     <label>12348</info>
     <!--genre: --!>
   </item>
   <item>
     <id>8</id>
     <info>musicplayer.genre</info>
   </item>
 </referencelist>
</window>

[DanTm]

well the way i implemented it now (new working patch up at sourceforge, id 1200420)
is kinda similar to the way u suggest it, but requires less changes to existing skins, the only differance is that you suggest a global (to the window) sort of reference list, while i've implemented a reference list for each control, which is like it worked before basically, and therefore backwards compatible.

i don't think working with a long list of references makes it easier for the skinner, you have to resort to the list all the time for the id's to use. now they are defined within visible range.

nyway, as i said, i uploaded a tested and working patch which uses my latest suggested format, using localization both in info and in label and dynamic visibility for both label and fadelabel (fadelabel now uses multiple label tags to support this). for as far as i've tested everything is backwards compatible.

feel free to use it in the main cvs... or use those bits u like.. or don't use it at all

[kraqh3d]

the [1][2][3] solution just doesnt seem "right". its still order dependant, and its a little clumsy.  i tried to xml-ize it but it didnt really help.  it just made it more confusing.

if its going to be order dependant anyway, why not just make it as simple as possible by expand label to accept special tokens.  eventually, the use the info tag could be deprecated (but it could continue to be supported for just a single info manager item.)

example:
<label>$localize(12345) $info(musicplayer.time)/$info(musicplayer.duration)</label>

would output something like this:
time: 00:01/05:00

this is somewhat similar to something you proposed earlier.  i just made it more xbmc-like by combining the syntax of the xbmc-dot-commands with the id3 label formatting string.

this should not be difficult to allow backward compatibilty. the plain info tag would still function as it does today.  a label with just a number would function as it does today.  

if label is not a number, then parse it looking for tokens in the form of "$type(parameter)".  i used caps in my example so its easy to see, but the parser should ignore case.

type = localize, means lookup the parameter in strings.xml
type = info, means lookup the parameter from the infomanager

any other characters are just concatenated into the output, like the space and slash in the example.

i'd say if the type or parameter make no sense, then ignore the entire $type(parameter) block, but output a parse error in the log.  or maybe putting some indicator on the screen would be a good idea... maybe the bad $type(parameter) block as is, as if it was just a normal string?

and for completeness, $$ should means its not a token, so just copy the characters until the next $ is encountered.

[DanTm]

it's indeed quite similar to my earliest feature request
i think using a regex to find matches would be easiest.. just have to figure out the regex parser used by xbmc.
i'll look into it.. when i have time

[DanTm]

the parse function could also be used for all other controls which have a label (button etc)

[DanTm]

ok patch is up on sourceforge... works as mentioned in kraqh3d's last post.

if it gets into csv, use the label = parselabel(label) for all controls containing a label.

njoy!

d.

[kraqh3d]

cool. i'll take a look at it later today... and speaking of regexp engines, i stumbled upon this last night: http://www.pcre.org/

its a open source regexp library thats used by many other popular open source software such as python, apache, php, exim, and nmap. there's links to win32 compiled binaries in both .dll and .lib format. i downloaded them last night, along with the source, but i didnt get a chance to play with it yet.

[DanTm]

i didn't use a regex in the end.. using some simple string parsing was enough..
firstly cause the format is quite simple.. secondly.. cause i wasn't in the mood to figure out the regex engine currently used
i don't think a regex is faster in this case nyway (mm.. i'll use that as my excuse )

but drop me a line if u got ny questions 'bout it, or i might be on irc.

d.

[kraqh3d]

@DanTm

nice work! i like it. i just modified my musicviz skin file to concatenate some items in a single line.

[pike]

so it's in cvs now or ?

[DanTm]

oh.. when (or if) u put it into cvs.. don't forget to take out the debug line in parselabel, its was for my own purposes.. and writes a bit too often (for each render) to the log

[kraqh3d]

i didnt commit it yet.  i was playing with some error conditions and noticed something wierd.  it's not a problem with your code, just atoi returns zero for a string thats doesnt match the pattern criteria.  so for example, $localize(foo) prints "my programs".

this is because string 0 = "my programs" in strings.xml. i added a test condition to see if the item in parens is an integer greater or equal to zero.  but, really, i think we need to remove string zero from strings.xml as i'm sure this issue exists elsewhere. (i'm betting all the "ato", "strto", and "wto" functions work similarly.)

[DanTm]

yeah.. i already noticed the atoi behaviour.. but as it does not much harm in this case. it will only place a burden on the skinners to change the use of string id 0 if you remove that one.
for sake of correctness we can check for a valid number using cutil::isnaturalnumber(string).

nyway, lets see if there are more interesting things i can patch

[kraqh3d]

that's exactly what i did. as i said, it's not a fault with your patch. there's really no harm in it. you just get "my programs"

but, it would probably be a good idea to stop using string 0 to avoid unwanted conversion. this way you'll get a null string returned from the global string translator. changing the use of string zero isnt too much of a problem. a simple sed script should be able to replace them all.

[kraqh3d]

it's in cvs now...