AlarmClock(Name,Command,Time[,silent])

pieh Wrote:after quick inspection: adding conditions (this doesn't seem really hard) would automaticly also allow using conditions in <onfocus>, <onclick>, <onleft>, new <onback> etc

Would these be checked like visibility conditions or like include condition, only when screen loads? In any case, this would be a very nice addition.

Big_Noid Wrote:Would these be checked like visibility conditions or like include condition, only when screen loads? In any case, this would be a very nice addition.

those would be evaluated when clicked - if they would work like conditional includes it would have much sense in adding them

ronie Wrote:just tell him he's wearing a smashing pair of socks or something...
that should do the trick :-)


in case he starts lecturing you on skin variables again,
just play dumb and commit anyway ;-)

skin variables is great idea but before doing them we need to make infomanager push based (well not need to - but doing it before would just double amount of work)

PS. If I'll be in trouble I'll try that socks advice

I can't believe the <onunload> tag was available all this time. just added it to dharma in DialogVideoScan and DialogMusicScan to run recently added onunload. Works really great

Hopefully someone will update the wiki.

ronie already updated wiki: http://wiki.xbmc.org/index.php?title=Window_Structure

I was looking in the wrong place - cheers ronie.

@pieh: IMO skin vars won't add any real overhead to the info manager (particularly this use of them), as the variables need only update at most once a frame, and usually much less than that. It's the better solution than adding a bunch of conditional stuff that skinners will have to change later to skin vars **.

Note that one potential issue is highlighted by this use though: Traditionally skin variables have been thought of as evaluating to a single value (i.e. the first value that matches it's condition). Here you want all values that much the condition. I suggest the best way to go is a pseudo-skin var, essentially add a class similar to GUIInfoLabel that reads in a bunch of common tags such as <onleft> and builds a vector of <conditionstring,actionstring> pairs. Then have a routine to grab the vector of strings that satisfy their condition strings. This keeps the conditional code out of the control classes so that any changes can happen independently.

Cheers,
Jonathan

** an alternative would be a way to transform <foo condition="bar">blah</foo> into a skin var.

I wasn't really connecting <onX condition="foo">bar</onX> to skin variables (this somehow got in this topic by accident) - as You said: conditions of all onXs need's to be evaluated.

From quick overview I was planning to use https://github.com/xbmc/xbmc/blob/master...scriptor.h that is used by onX if skinner specified text value (numeric values have seperate handling) to accept optional condition and add Execute method there that would check condition before executing. To unify it even more I think I could move numeric value handling there too - will need to check related code for that.

That would be fine, just place the vector inside whichever class you're gonna mess with - having it outside is a bit silly really (see OnExecute or whatever it is that takes a copy of the vector then passes through it etc. etc. - that should all be hidden away in the class ideally).

I'll let you make your own mind up regarding the utility of the existing ActionDescriptor class..

As for the numeric thing, nothing jumps out as being immediately difficult with it handled by the same class using the same vector (just store the id as a string and check for that in a routine that specifically asks for the next control to jump to - GetNextControlId() I think it is?)

Cheers,
Jonathan