Cleaning up condition syntax
#31
Jezz_X Wrote: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

+1
Reply
#32
Ok, for a start, I'm not planning on going all out just yet - let's keep it simple Smile

The first step is a common format for info retrieval as specified by Black earlier.

i.e. Control.IsVisible(50) would simply be Control(50).IsVisible.

Simply put: Any argument/parameter is stuck on the bit of the infolabel it actually affects - the 50 refers to Control 50, not the 50th IsVisible (whatever that means).

I'm also only considering boolean operations at the moment, as they're really the simplest.

However, some boolean operations are functions rather than properties:

isempty(foo)
stringcompare(foo,bar[,left|right])
integergreaterthan(foo,2)
system.date(value1[,value2])
system.time(value1[,value2])

It's not quite as obvious how these should be best formatted so that they're both obvious to skinners and easy to parse in the code. The last 2 for instance are completely non-obvious to me as there's no indication that value1 and value2 are there for comparison.

One option is to not distinguish between properties and functions in terms of syntax:

foo.isempty
foo.left(3).equals(bar)
system.time.inrange(value1,value2)

This would involve quite a shift in the way the code works internally (it would essentially move to an object orientated approach where each object has parameters, properties (which may be objects) and functions), but I do quite like the idea behind it.

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
#33
makes sense and sounds reasonable to me.

the only thing to worry about is if it's possible to get everything in the proposed
Category[(cat_params)].Info[(info_params)][.SubInfo[(subinfo_params)]] format.

this one seems tricky, at least to me:
foo.left(3).equals(bar)

in case of a window property, you'll get something like:
window.property(foo).left(3).equals(bar)

maybe this would make more sense:
window.property(foo,left(3)).equals(bar)



another thing i wonder about is a boolean like system.platform.linux...
will this become
a) system.platform(linux)
b) system.platform.equals(linux)
c) system.hasplatform(linux)
or
d) none of the above
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
#34
Quote:this one seems tricky, at least to me:
foo.left(3).equals(bar)

It means "take foo, then take only the left 3 characters, then see if it's equal to bar". Basically anything following a period is either a property of or a function that operates on whatever is before the period.

Quote:in case of a window property, you'll get something like:
window.property(foo).left(3).equals(bar)

maybe this would make more sense:
window.property(foo,left(3)).equals(bar)

The first makes most sense to me, as the left(3) operates on what preceeds it (window.property(foo)) and similarly, property operates on "window", and "equals" operates on the result of "window.property(foo).left(3)".

If we want to distinguish between functions and properties then we could use something like:

equals(left(window.property(foo),3),bar)
or
stringcompare(window.property(foo),bar,0,3)

i.e. a function is of the form:

function_name(parameters)

Quote:another thing i wonder about is a boolean like system.platform.linux...
will this become
a) system.platform(linux)
b) system.platform.equals(linux)
c) system.hasplatform(linux)
or
d) none of the above

I think a, b, or c would work, though b seems to be most useful should we go that way, as that means that system.platform is a string that returns "linux".

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
#35
Regarding window.property(foo) wouldn't it make sense to just do
Window.foo instead? and Window(another_window_id).foo if needed? I guess I'm thinking properties to be somewhat of a member variable of the "object" Window in this case.

So it would be Window.foo.Left(3).equals(bar)

My thinking is that then it would fit quite well with other stuff like System.Platform and perhaps Power.CanPowerdown as you kindof have Namespace.Property or Namespace.Function or Namespace.Property.Function etc. (You could easily switch namespace with category whichever naming works)

So I guess Control.foo would be short for Window.Control.foo (as Window resolves to current window), otherwise it would be Window(settings).Control(3).IsVisible
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
#36
We could potentially do that, yes - the advantage would be simplifying the syntax. The disadvantage I guess is that it removes some of the definitiveness of the "built in" properties. Not sure if this is a big deal or not though!

It would be nice if this had a natural translation into json - any ideas there?

I'm not sure if we have differentiation between "hasproperty" and "property" at the moment, but that distinction will have to be made somewhere if we're going to have object types (as window.foo would generally return a string by default for properties) - I should think that casting a string object to a boolean object should be natural enough (assumes isempty is the operator).

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
Cleaning up condition syntax0