Skin Variables / Conditional Labels
#31
Jonathan,
I personally agree with Your points but also sympathise with skinners (as they will make use of it). If we will make it non-comfortable they will continue to copy controls as for them this is quick and easy solution to get things working. I wouldn't worry about reusability of variables (we can add check if we already have defined exact same variable earlier and link against it). I don't say that those proposed are best way to allow "local" variable, but we shouldn't disallow it in general IMO

prefix/postfix stuff would be bonus of reusing CGUIInfoLabel - don't think we should disallow it "just because".
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
#32
pieh Wrote: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?
pieh,

purely readability. Easier to read $VAR[foo] than $INFO[Skin.String(foo)] when it is in a string as you first showed in your example. Now that Jezz_x pointed out that it should be as you now show it I understand what you are offering.

To me a variable is a scratch pad to store a piece of info that you change as needed (a constant is the same thing that you can not change).

What you are offering up here is what I would call a "CASE" block (kind of sorta) that assigns a value to a string based on a list of conditions. To me it would be better to call it $CASE instead of $VAR, but I guess I can understand now where you get the $VAR from.

While I can see it being useful, can't we already achieve this with a series of conditional includes (very much like my first example)?

Please excuse the misunderstandings, but as an Australian, English is a second language for me (Strine is very similar to but not quite English)Big Grin

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
#33
Yes, as I already said - Skin Variable isn't good name for this. And no - You can't get this functionality with series of includes because includes are determined when You load window and this feature will change Text as soon as conditions would change (f.e. You can't use conditional includes in example from 1st post because at time when includes are resolved we have no information about ListItem.FileNameAndPath)

And for any missunderstandings I should propably take the blame here. My unability to clearly express thoughts always cause troubles Sad
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
#34
In a thinly veiled attempt to keep this thread front and centre...

Any update on this?
Reply
#35
Waiting in the queue - don't worry I didn't forgot about it.
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
#36
Much appreciated :-)
Reply
#37
Need some feedback:

Code:
<variable name="A">
[..]
</variable>

<variable name "B">
  <value condition="somecondition">using other variable: $VAR[a]</value>
</variable>

This is pretty straight-forward to support - problems start when definition of variable B would be placed before definition of variable A. Add to that situation when variable A depends on variable B and we have circular dependency.

There are two solutions on that:
  1. It's skinner responsibility to order variable definitions properly - if variable B depends on variable A, variable A should be defined before variable B. If A wasn't defined earlier then $VAR[a] will simply become empty string (+ xbmc will log it in Debug Log so skinner know he need to re-order definitions).
  2. Let xbmc handle this. This tripples (or more) amount of code needed and make support for this much more complex. Initial code addition isn't problem here - I'm bit worried about potential bugs and future maintenance of this feature.

Now question is: could You live with requirement that You need to take care of proper variable definitions ordering (option 1.)?
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
#38
pieh Wrote:Now question is: could You live with requirement that You need to take care of proper variable definitions ordering (option 1.)?

Yes, would be absolutely no problem for me. Smile
Image
Reply
#39
pieh Wrote:Now question is: could You live with requirement that You need to take care of proper variable definitions ordering (option 1.)?

Uhm, isn't the variable evaluated on each process (or when its changed later). Unless I have missed something (or you are refering to constant variables) they can change whenever? Thus the order of their definition is rather irrelevant as they still need to be evaluated after define?
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
#40
A bit of a practical question (partly) about the utilization of skin variables. One thing I would like to do with containers and grouplists would be something like this:

PHP Code:
<height>$VAR[A]</height>

<
variable name "A">
  <
value condition="Control.IsVisible(1) | Skin.HasSetting(Foo)">600</value>
  <
value condition="!Control.IsVisible(1) | Skin.HasSetting(Bar)">500</value>
</
variable

syntax is probably weird, but I hope you get what I mean

This probably goes beyond just using variables though.
Reply
#41
initially <height> <width> <posx> <posy> and other numeric "properties" of controls are out of luck (we don't have numeric control properties hooked to infomanager yet). But this is defenitely something I will pursue in next steps
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
#42
Good to hear it's planned, cheers Smile
Reply
#43
This has been pushed in the latest nightly (30/09) and works perfectly - I'm already using it.

Thanks.
Reply
#44
sweet Big Grin
Thanks Pieh and everyone involved!
Reply
#45
Awesome. Smile
This is a very big improvement and will save a lot of code in certain situations.
Image
Reply

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