[pecinko]

From what I can tell he wants a more programmer approach, which I think sounds great.

So category is stuff like: Window, Control, MusicPlayer etc.
Info is stuff like position, offset etc.
Subinfo is stuff like .exists and such.

If that's the case and if I understood your examples, which I believe I did, it is a step in right direction, at least from my point of view. I pretty much expected this is how it works when I begun skinning and I was rather confused with inconsistencies.

However, probably some transition period or script to convert existing code should exist until we get used to new way and wiki is overhauled.

[Jezz_X]

Lol looks like we were all staying quiet because we didn't understand the last example

[topfs2]

I just use the tools that are provided to achieve what I want. It seems more logical to make everything consistent, I just don't want to rewrite every xml in the skin by hand just for consistency purposes ;-). Of course if a script can be made to do this, then I have no problem with this.

Can't make an omelet without breaking a few eggs but ideally backwards compat or ease to port is very important

I like the idea you put forward `Black, I think thats what jm wanted aswell.

[Window(id).]Control(id).SomeMethod(optional params) sounds like a great way to do it (have Window(id) == current window id the thing is written in). I do like the Control(X).IsVisible more than Control.IsVisible(X) personally. It might be weirder to do the Control(X, Y).IsVisible though, or perhaps not, not sure.

[topfs2]

Another thing I've been pondering which might be worth discussing? is the inconsistency between conditionals and just text.

In conditional you write Player.Something but in text you need to do $INFO[Player.Something] if you wish to get it, would it make sense to unify this and always assume it being more programmer oriented?

i.e. you need to write "something" instead of something in text stuff, and instead of $INFO[Player.Something] you can just write Player.Something as it will be interpreted as an info always.

Benefit with this would be same code all over and perhaps easier parsing. Downside is that its a giant change for skinners, even if we can do some backwards compat regarding it.

So if you want to combine strings in text you'd need to do "Currently playing: " + Player.WhateverNeededToGetTrack + " and it rocks!".

Benefit is that this would enforce some form of implicit typing in core which might be nice no matter. Would allow to do <visible>Player.TrackArtist</visible> as the string "" is resolved to false.

EDIT: It would probably include using something like Localize(1234) for non-hardcoded strings

thoughts?

[Jeroen]

Another thing I've been pondering which might be worth discussing? is the inconsistency between conditionals and just text.

In conditional you write Player.Something but in text you need to do $INFO[Player.Something] if you wish to get it, would it make sense to unify this and always assume it being more programmer oriented?

Sounds good, as long as we'd could still make things like

$INFO[ListItem.Year,, - ]$INFO[ListItem.Duration,, $LOCALIZE[12391]]$INFO[ListItem.Genre, - ]

work to show prefixes or suffixes only if they're available.

[topfs2]

Sounds good, as long as we'd could still make things like

$INFO[ListItem.Year,, - ]$INFO[ListItem.Duration,, $LOCALIZE[12391]]$INFO[ListItem.Genre, - ]

work to show prefixes or suffixes only if they're available.

Hmm, did not think of that. To me it sounds like a helper function almost
suffix(ListItem.Year, "-") which returns ListItem.Year+"-" if ListItem.Year resolves to true perhaps?

So your case would be

Code:

suffix(ListItem.Year, "-") + suffix(Listitem.Duration, Localize(12391)) + prefix(Listitem.Genre, "-")

Would make it closer to scripting almost

[BigNoid]

Another thing I've been pondering which might be worth discussing? is the inconsistency between conditionals and just text.

In conditional you write Player.Something but in text you need to do $INFO[Player.Something] if you wish to get it, would it make sense to unify this and always assume it being more programmer oriented?

i.e. you need to write "something" instead of something in text stuff, and instead of $INFO[Player.Something] you can just write Player.Something as it will be interpreted as an info always.

Benefit with this would be same code all over and perhaps easier parsing. Downside is that its a giant change for skinners, even if we can do some backwards compat regarding it.

So if you want to combine strings in text you'd need to do "Currently playing: " + Player.WhateverNeededToGetTrack + " and it rocks!".

Benefit is that this would enforce some form of implicit typing in core which might be nice no matter. Would allow to do <visible>Player.TrackArtist</visible> as the string "" is resolved to false.

EDIT: It would probably include using something like Localize(1234) for non-hardcoded strings

thoughts?

Isn't that what the <info> tag is for? I believe the $INFO tag is for advanced label formatting?

[topfs2]

Isn't that what the <info> tag is for? I believe the $INFO tag is for advanced label formatting?

Yeah for sure, I was mostly talking about combining them. so same way to do advanced as with simple.

I've always found it a bit confusing (the little skinning I've done) that you have both info and advanced label formatting

So old <info>TheInfo</info> would become <label>TheInfo</label> and if you want it advanced you just start adding stuff, i.e. <label>TheInfo + " and I rock!"</label>. Might make it more understandable for new skinners, and more maintainable for old?

[BigNoid]

I don't think the amount of effort this will take to implement outweigh the benefits plus personally I'm actually quite happy with the way things are now.

[mcborzu]

I taught myself atleast the basics of some languages and XBMC is definably easiest to learn. I hate to get too complicated and lose the ease of use XBMC coding has at the moment...

@topsf2


So in those example all regular text would need to be enclosed in quotations?

[ronie]

personally i don't see how changing (what we currently have):

PHP Code:

<label>[b]some text[/b]</label> 


to:

PHP Code:

<label>[b] + "some text" + [/b]</label> 


would make things more understandable for anyone?

but if there are any advantages (speed / code maintainability) it should be considered of course.

suffix(Listitem.Duration, Localize(12391))

if we drop the $INFO bit, then we might as well drop the need for $LOCALIZE ?

Code:

suffix(Listitem.Duration, 12391)

should work just as well, correct?

[pecinko]

Guys, you're going way too far.. :-)

@ronie

in this example

Code:

suffix(Listitem.Duration, 12391)

we would probably have a problem with info & non info strings mixtures?

I would vote for changes that would lead to:

Code:

a) ListItem.Duration(X)
b) ListItem.Duration(XL)
c) ListItem.Duration(DELUXE)

giving us

Code:

a) 124
b) 2:04:15
c) 124 Minutes       *Minutes being localized label*

and eliminating non necessary use of prefixes/ suffixes

The same goes for

Code:

ListItem.Description

returning us content based description - Plots, Album info etc.. with nice localized fallback label "No description available" included.

In other words - I would love to use design, not programing skills for skinning.

[topfs2]

@mcborzu

I'm c++ dev so anything closer to that paradigm I feel is easier, which is also why I might very well be clouded So why I only suggest it and would love skinners view on it I think it would be easier but that may in no way be true for those using it

and yes, anything non-localized and hardcoded text (which should be baaaad in official repo " related would need " encapsulation.

@ronie

Not sure we can drop the localize bit as then its impossible to deal with int types, i.e. say I want to do <label>Player.Artist + " I rock" + 1 + "!!!!"</label> redicoulus example I know but the 1 there should be a number 1 and not localized 1. So IMO better to be explicit?

Regarding the [b], I did not think of that at all. That doesn't fit into the thing I suggested one bit. The best way to do that consistently in how I suggested would be

Code:

bold("my awesome text " + Player.Artist + " : " Localize(1234))

@All
My suggestion was only something worth discussing, I personally think it might clean it up but that in no way reflect what jonathan and you guys may think, I just wanted to put it out there as I would be willing to put in some work and make it that way if there is interest for it

Cheers,
Tobias

[Hitcher]

I think the current labelling system -

PHP Code:

$INFO[], $LOCALIZE[], [b][/b], [color=][/color] 


- is fine and fairly understandable but the actual info could definitely do with a tidy up.

I think black was along the right lines of what Jonathan's suggesting -

Control(id).IsVisible
Window(id).IsVisible
ControlGroup(id).Item(id).HasFocus

[Jezz_X]

I got to agree with hitcher on this one the Layout stuff that is like a forums option is super easy to understand and powerful enough and the suffix and prefix stuff already works and works fine the only real changes to that I would like is to allow other infolabels to be a suffix or prefix for another
eg: $INFO[MusicPlayer.Artist,,- $INFO[MusicPlayer.Album]] will not work currently