Cleaning up condition syntax
#1
Hi guys,

I'm currently rewriting the way the infomanager works (to make it more efficient) and have come across a whole heap of inconsistent stuff.

Currently we have the following syntax for boolean conditions:

1. Category and info:
Code:
player.ispaused

2. Category and info, with a single parameter:
Code:
system.hasalarm(name_of_alarm)

3. Category and info with two parameters (second may be optional):
Code:
system.date(date1[,date2])
skin.string(foo[,bar])

4. Category and two parameters (second may be optional):
Code:
isempty(info1)
stringcompare(info1,info2)

5. Category with (optional) id and info:
Code:
container(2).onnext
listitem(1).isfolder
listitem.isfolder

6. Category with (optional) id and info with id:
Code:
container(10).row(3)
container.column(4)
controlgroup(2).hasfocus(10)

7. Category with (optional) id, info with (optional) id, and subinfo:
Code:
container(10).listitem(offset).isfolder
container.listitem.isfolder

8. Category, info with id, subinfo:
Code:
musicplayer.offset(2).exists
musicplayer.position(3).hasnext

9. Category with (optional) id, info with string parameter:
Code:
listitem(4).property(foo)
listitem.property(bar)

10. Category with (optional) parameter, info with string parameter:
Code:
window.property(foo)
window(Home).property(foo)

11. Category and info with id:
Code:
control.hasfocus(10)
control.isenabled(11)

It seems to me that we might be able to clean this up somewhat. In particular, the last one might be better written using syntax #5:

Code:
control(10).hasfocus

i.e. the basic overriding idea would be that the id or parameter is directly attached to the thing it represents. Similarly the string compare ones (syntax 5) could be rolled into syntax 10 by adding the "string" category:
Code:
string(info1).equals(info2)

So we'd basically drop everything down to the form:
Code:
Category[(cat_params)].Info[(info_params)][.SubInfo[(subinfo_params)]]

Thoughts?

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
#2
I understood everything except last example :-) Seams to me as more logical way.

I suppose there will be backward compatibility for Dharma or is this meant as clean table fresh start?
My skins:

Amber
Quartz

Reply
#3
All the current ones are similar forms that will be supported in the future - we'll just be cleaning things up somewhat for the future (i.e. some forms will be depreciated).

I'm not quite sure how to handle some of them - for instance listitem(4) vs listitemposition(4) vs listitemnowrap(4) seem quite messy as they are - particularly the nowrap one. Ideas?

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
#4
Sounds like a much cleaner, understandable way of doing things to me and I'm sure a script could be written that 'finds and replaces' all of the old style to the new.

I'm curious though - what's 'listitemnowrap'?
Reply
#5
Exactly my point :p

Currently listitemnowrap(1) will get the next item from the current, but only if the current item is not the last item.

listitem(1) on the last item, however, will grab the first item (i.e. by default it wraps). Personally I think this is rather odd - it seems to be something that should not wrap by default unless you are actually using a wraplist as the underlying container.

I'd look at changing the syntax to container(foo).item(bar) and container(foo).position(bar) and drop the nowrap version.

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
#6
How long have we had that info label?

I could have done with in the past.
Reply
#7
I've just tried using ListItemNoWrap(n) but every offset Icon (ListItemNoWrap(1), ListItemNoWrap(2), etc) displayed the focused Icon.
Reply
#8
I would have thought this would have gotten more input from skinners to be honest.

@ JM, what time scale are we looking at here?
Reply
#9
to be honest the bottom example has me confused Smile I think a real world example of Old way vs New way in the examples he did post would go a long way to getting feed back. I'd do it but like I said it confuses me Smile
Reply
#10
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.

Could go so far as to make it object based almost?

Player.GetActiveList().offset(2).exists
Could almost even do it transperant.
Code:
<visible>Player.GetActiveList().offset(2)</visible>
(in this example null becomes bool behind the scene.)

System.Date.Now.toString("HH:mmConfuseds")

And enforce some common stuff like equals.
System.Date.Now.Equals("22:10")
Perhaps even CompareTo
Code:
<visible>System.Date.Now.CompareTo("22:00") > 0</visible>

Not sure if it makes sense or perhaps its better to keep it more function based (closer to python?)

EDIT: When I think of it since xml isn't really object based it might not make sense to make it so Smile
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
#11
Hitcher Wrote:I would have thought this would have gotten more input from skinners to be honest.

agreed and imo this also applies to several other proposals that have been posted lately. many of them don't get the proper feedback they deserve.

problem is skinners and devs speak a different language and discussions between them tend to get a little too technical for the 'avarage' skinner (me) quickly.

what we need to do is find some common ground to discus things on,
and as Jezz_X already suggested, some very basic real-world examples would certainly help in this regard :-)


btw, does anyone know what container.subitem() does?
it's missing in the wiki and i'd like to add it.
Do not PM or e-mail Team-Kodi members directly asking for support.
Always read the Forum rules, Kodi online-manual, FAQ, Help and Search the forum before posting.
Reply
#12
Isn't that always the problem, to gap the language barrier Smile Happens between the devs too, each dev is usually very deep down in his field so can be hard to have discussions at times.

I think the best review and best starting point to clean it up would be from skilled skinners to say how they like the info system to behave, with examples and such. How to clean it up to get an API which is easier to understand and easier to manage and more consistent. Since you guys use it I'm sure you have a better idea on how you would have wanted it to behave rather than how it does behave.
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
#13
ronie Wrote:problem is skinners and devs speak a different language and discussions between them tend to get a little too technical for the 'avarage' skinner (me) quickly.

I concur Smile I would have liked to give some feedback on this but to be honest I didn't think it would add much as I get the general gist of the proposal, which I like, but translating that last example to "real world" usage didn't really come to me yet Rolleyes

But topfs2's examples are helping Smile

edit: on a related (?) note, one thing that would save me a lot of code would be to combine related conditions into one statement.
So instead of:
PHP Code:
Control.IsVisible(50) | Control.IsVisible(51)| Control.IsVisible(52

a shorthand version along the lines of:
PHP Code:
Control.IsVisible(50,51,52
Reply
#14
At the moment some conditions are inconsistent, e.g. we have Container(id).IsStacked, Control.IsVisible(id) or Window.IsVisible(id)... all conditions should have the same form, so (I think) it would be Control(id).IsVisible and Window(id).IsVisible then... also for ControlGroup it could be ControlGroup(id).Item(id).HasFocus instead of ControlGroup(id).HasFocus(item_id).

There wouldn't be a massive change I guess but things would be more consistent overall and follow the same form... It also would be easier to remember for us skinners.
Image
Reply
#15
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.
Reply

Logout Mark Read Team Forum Stats Members Help
Cleaning up condition syntax0