Skin Variables / Conditional Labels
#16
@jonathan
I backed off the <constant> stuff - I wasn't aware we have something like this already <- shame on me

If we plan to move to push-based soon enough that surely I can drop that flag specyfing when it should be evaulated. Good point.

jmarshall Wrote:Lastly, if we want to consider aligning <onclick> stuff with this, then we'd have a "multiple variable" approach which instead of returning the first item returns all items that match. That's something to consider after the single return is implemented.
I don't think I want to handle that with skin vars? I see skin variable as way to define reusable dynamicly generated text (string), condition (bool) (or even color) and changes should affect mostly GUIInfoManager, CGUIInfoLabel/CGUIInfoBool/CGUIInfoColor and not affect anything else (hard to tell for sure yet - but that way I see it).

If someone want multiple onclicks he can use non-conditional include (if he want to reuse it) + (not yet in) conditional onclicks - I think so there is no need to mix skin variables here.

wyrm Wrote:Skin.SetVariable(variable-name,variable-value) and then access the the variable elsewhere in the skin with $VAR[variable-name]. Probably we would need to expand the checks against the variable as well, so something like IsEqual($VAR[variable-name],some-value). The other checks that would be handy would be IsNotEqual, IsGreaterThan, IsLessThan. Once again, just throwing the idea out there.
I didn't think of SetVariable builtin - You already have Skin.SetString for this - why do You want to double this functionality? As for checks - You will be able to use existing checks - SubString, StringCompare, IntegerGreaterThan. If You need more You should request new feature because this is not really concern of skin variables.

Thanks for input! and sorry for little technical talk with Jonathan (we live in completely different timezones - GMT+1/+2 vs GMT+12/+13 so hard to consult this on irc)
Always read the XBMC online-manual, FAQ and search the forums before posting.
Do NOT e-mail Team-XBMC members asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting, make sure you read this first

My previous forum/trac nickname: grajen3
Reply
#17
I was doing some code checking and now I think that we could even drop $VAR and just reuse $INFO for skin variables as well.
Always read the XBMC online-manual, FAQ and search the forums before posting.
Do NOT e-mail Team-XBMC members asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting, make sure you read this first

My previous forum/trac nickname: grajen3
Reply
#18
pieh Wrote:I was doing some code checking and now I think that we could even drop $VAR and just reuse $INFO for skin variables as well.

that would be confusing I think because they wouldn't be listed in the wiki and new skinners would go where the hell does that come from they need to be kept separate like
$INFO[]
$VAR[]
$CONSTANT[] <-- not used but should be
$LOCALIZE[]

BTW while we are on the topic of adding this sort of stuff I've always wanted to be able to fetch any value from any control like the current Control.GetLabel(id) does like $INFO[Control(id).property(blah)] eg:
PHP Code:
$INFO[Control(id).property(width)]
$INFO[Control(id).property(posx)]
$INFO[Control(id).property(texture)]
$INFO[Control(id).property(visible)] <-- comes back as true false 

And while I'm at it the ability to calculate things using $CALC[]
eg:
PHP Code:
<posx>$CALC[100]</posx>
<
posx>$CALC[$INFO[Control(10).Property(posx)] + $CONSTANT[ScreenOffset]]</posx

Rolleyes
As you can see it would be nice and easy to place things relative to other thing like to center an object on the screen in any resolution

PHP Code:
<posx>$CALC[($CONSTANT[ScreenWidth] / 2) - ($INFO[Control(10).Property(width)] / 2)]</posx

One can dream anyway Smile
Reply
#19
Jezz_X Wrote:As you can see it would be nice and easy to place things relative to other thing like to center an object on the screen in any resolution

Just need to say that android xml stuff have quite a nice system for handling relative objects.

It works by you defining a layout and then all items within that layout are relative to eachother.

They have many of these but some which are notable are LinearLayout (example http://developer.android.com/guide/topic...ayout.html)

In short you specify that everything in that layout is horizontal then you just add items with a fixed size and even if they alter size they will be horizontally placed with proper positions. Might be an even nicer way to deal with it?

The more advanced one is RelativeLayout http://developer.android.com/resources/t...ayout.html which essentially works by you state that a control A should be left of control B and so on, the layout will calculate everything for you and place it as you specify.

Anyways, something to think about perhaps.
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#20
@topfs
our grouplist is already equivalent to android LinearLayout (or at least it should be)

Layouts make things nice but might be problematic in our case because we have different nature of app (we often render overlaping controls etc instead of laying down controls in nice and clean way).
Always read the XBMC online-manual, FAQ and search the forums before posting.
Do NOT e-mail Team-XBMC members asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting, make sure you read this first

My previous forum/trac nickname: grajen3
Reply
#21
pieh Wrote:I was doing some code checking and now I think that we could even drop $VAR and just reuse $INFO for skin variables as well.
pieh,

That was kind of the point that I was trying to make in my previous post. If you really get down to it a skin string is just a persistent (value of variable survives a reboot due to being written into guisettings.xml) string variable. Although I don't think we could re-write your code example with a skin string as it stands at the moment, that was the general idea of what I thought you were purposing to do with skin variables.

Also agree with Jezz_x if you use $INFO, $VAR etc it would make it VERY clear what is going on in the code.

Guess the real question is "What do we want skin variable to do?"

For me I think being able to build up location strings for accessing media content (fanart, posters, banners, TV theme music files etc). Keeping track of how many times something has been accessed or displayed or whatever. Really would love to be able to do stuff like Jezz_x's $CALC example. And my example of changing what the <onclick> for a button does. So instead of "ActivateWindow(Videos,tvshowtitles,return)" I could change the variable to read "ActivateWindow(Videos,tvshowgenres,return)" and have my TV button in my home screen start in genres instead of titles. Another one that would be a lot easier would be changing the image shown for OSD repeat button (none, one, all). Two images easy, three gets harder and it just goes down hill from there.

Point is if you are going to the trouble of doing this, make it a worthwhile change, then stand back and watch what we can do with this.

Wyrm (xTV-SAF)
If required a FULL debug log can now be submitted from the skin in settings->skin settings->support. Or follow instructions here if you can't access skin settings.

FAQ's located at :- http://kodi.wiki/view/Add-on:AppTV
Reply
#22
I fail to understand what You're after - could you provide some sample code You would want to be able to run?

Skin variables may be missleading name for what this all is about - concept was named this way and I just reuse it - but I have no problem changing name to something that reflect its usage better. Maybe something like "Conditional info" or "Conditional label" fits better and is less confusing.
Always read the XBMC online-manual, FAQ and search the forums before posting.
Do NOT e-mail Team-XBMC members asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting, make sure you read this first

My previous forum/trac nickname: grajen3
Reply
#23
Centering objects relative to the screen (or relative to the group) is something I've wanted to do simply by allowing groups to handle that - it takes care of things like 4x3 vs 16x9 as you can simply tell a group of controls that they should be anchored in the center of it's parent and should keep aspect ratio (i.e. filling the width or height appropriately). This means you don't need any calculation in the skin and can still have dynamic layouts.

Utilizing grouplists with auto-width controls allows quite nice layout anyway - we need only extend this to some other controls that handle other things for us (eg buttons etc.) to achieve most of the layout possibilities that folk want.

Thus, I don't think we need calc stuff immediately - it's a nice to have but I think can be handled other ways in many cases.

As for skin variables, yes you could use $INFO[Skin.<variablename>] or some such - I don't see a problem with that, though it does mean the namespace for skin gets quite a bit larger as one presumes skin.string etc. could also be incorporated into that later on.

Setting up variables for what we already support (labels, colors, textures etc.) seems like the best place to start. We need to add a completely separate implementation if we want to handle floats.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#24
jmarshall Wrote:Thus, I don't think we need calc stuff immediately - it's a nice to have but I think can be handled other ways in many cases.
Jonathan,
Would be very nice, but you are right it is something that could come later.
Quote:As for skin variables, yes you could use $INFO[Skin.<variablename>] or some such - I don't see a problem with that, though it does mean the namespace for skin gets quite a bit larger as one presumes skin.string etc. could also be incorporated into that later on.

Setting up variables for what we already support (labels, colors, textures etc.) seems like the best place to start. We need to add a completely separate implementation if we want to handle floats.

Cheers,
Jonathan
Try this on for size.

1 - $VAR[string,value] == Skin.SetString(string,value),
$VAR[string] == Skin.String(string)
(alias this so you do not break current skins)

2 - Now when you perform your screen layout magic on the current .xml file, anywhere you see $VAR[foo] replace with the contents of $VAR[foo]. For example <texture>flagging/video/$VAR[filename_video_type].png</texture> would become <texture>flagging/video/dvd.png</texture> if you had previously set $VAR[filename_video_type] to "dvd". Bonus points if you implement "Dirty code" flag. If you set a variable you set the DC flag and relayout the screen (don't need to pull the reload skin trick to get screen relayed out as we currently do).

3 - Now you go thru and make changes to the various tags to allow for any problems that this may cause (can't really think of any, but then I don't know exactly how things are implemented)

Now unless I have missed how things work, this should be completely transparent to existing code. It allows the skinners to go thru and update to skin variables and the advantages that they give without breaking things. Pretty sure will allow you at a later date to include Jezz_x's $CALC idea as well.

Now feel free to point out the problems with the idea.

Wyrm (xTV-SAF)
If required a FULL debug log can now be submitted from the skin in settings->skin settings->support. Or follow instructions here if you can't access skin settings.

FAQ's located at :- http://kodi.wiki/view/Add-on:AppTV
Reply
#25
wyrm:
what I don't understand is how:
Code:
$VAR[string,value] == Skin.SetString(string,value),
$VAR[string] == Skin.String(string)
will improve anything? This is completely not what I have in mind and just allow using different syntax to get same effect. Please read first post again and see how I define skin variable there - it's based on conditions and not set by action. I don't see the reason to merge those too - what I'm missing here?
Always read the XBMC online-manual, FAQ and search the forums before posting.
Do NOT e-mail Team-XBMC members asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting, make sure you read this first

My previous forum/trac nickname: grajen3
Reply
#26
yeah I'm kind of lost there too seems like its the exact same thing with a different name
why not just use $INFO[Skin.String(string)] then

which brings me to why not use like we already have planned for onclicks
<label condition=""> </label>
<texture condition=""> </texture>
since its basically the same thing just not off location
Reply
#27
btw this example in the first post should work like an info label with prefix and postfix

your original code
PHP Code:
<texture>flagging/video/$VAR[filename_video_type].png</texture
should be
PHP Code:
<texture>$VAR[filename_video_type,flagging/video/,.png]</texture

or when the variable is empty you end up with log errors like
Quote:Unable to find texture: flagging/video/.png
Reply
#28
Now that I think about it what wyrm must be suggesting is he wants a way to set a value with a constant value eg: a background and then be able to override it with a skin setting thus making is a variable?

This sort of thing will be possible when/if skin settings get put into addon settings because they will have default values and other options
like the spinners for xbmc subtitle script
Quote: <setting id="Lang01" type="enum" label="30101" default="11" lvalues="30201|30202|30203|30204|30205|30206|30207|30208|30209|30210|30211|30212|30213|30247|30214|30215|30216|30217|30218|30219|30220|30221|30222|30224|30225|30226|30227|30228|30229|30230|30232|30233|30234|30235|30236|30237|30238|30239|30240|30242|30243|30244|30245|30246" />
Reply
#29
@wyrm
Are You looking for way to set default value of Skin.String?
Always read the XBMC online-manual, FAQ and search the forums before posting.
Do NOT e-mail Team-XBMC members asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting, make sure you read this first

My previous forum/trac nickname: grajen3
Reply
#30
Quote:<label condition=""> </label>
<texture condition=""> </texture>

I personally don't like that syntax though it is effectively the same as what is proposed, yes. The primary reason I don't like it is that it makes it difficult to separate the handling for variables from things that don't need to be variables. Essentially you'd have to check for multiple copies of the nodes where one or more has a condition attached and if so construct the variable, otherwise don't. The advantage of separating them out is that the parsing is trivial - you know you're always constructing a skin var. In addition it encourages re-use which is useful for efficiency.

Also, I'm not sure we need the prefix/postfix stuff, as the fallback could return nothing anyway? (After all, the prefix/postfix is just to detect the case where there's nothing returned by the infolabel, which could also be done by a conditional variable on that infolabel being empty).

For the same reason I don't like things like $IF[blah,foo,balasfd] as that presents the same problem. Keep things XML-ized so we can at least do some validation.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply

Logout Mark Read Team Forum Stats Members Help
Skin Variables / Conditional Labels0