Kodi Community Forum

any idea when 2.0 will be complete? and is there any chance of a list of changes, not explanation, just a list of changes that you can think of. not right now but as soon as you have finalized the 2.0 changes. this would help a ton! in the mean time i think i may look into a new xml engine besides the one i coded. mine is unable to read anything but the code and all notes are ignored and not saved. this is not a good thing for those that keep notes. i may even include a notes section for each control.

a couple more changes went in, that are fairly minor, but as many of you have already released v1.85 skins, i figured i should bump the version up again (it's completely backward compatible)

version now is 1.86.

changes are:

1. all slide starting positions (startx and starty attributes) are now relative to the control (or window) origin. this actually makes things easier in most cases to work out the slide. subtracting off the posx and posy values in your 1.85 skins will take care of this.

2. the volume bar and volume label are now handled by the new infolabel player.volume - the id's no longer matter.

3. new infolabel player.volume (both integer for slider, and label including the db string)

4. new built in functions player.mute and player.setvolume(percent).

5. dialogs can now have different origins for different base windows. it works as follows:

<coordinates>
<system>1</system>
<posx>50</posx>
<posy>50</posy>
<origin x="100" y="100">window.isactive(home)</origin>
<origin x="500" y="400">window.isactive(myvideos)</origin>
</coordinates>

this will cause the dialog to normally be displayed at (50,50), but on the home window it'll display at (100,100) and on the myvideos window it'll display at (500,400).

the origin's are evaluated in the order given - the first one matching takes priority. the conditionals can be whatever you like, though window.isactive() seems to be the most useful.

you can also do <origin x="50" y="50">true</origin> in place of the <posx> and <posy> tags.

the future

i'm toying with the idea of splitting up the animation effect from the visibility condition. this will allow more effects in the future (such as a focus effect, and separate window start and window end effects) plus will clean it up a little bit. one thought i had was something like this:

<visible allowhiddenfocus="true">conditions for visibility</visible>
<animation effect="fade" time="2000">visible</animation>
<animation effect="slide" time="1000" start="-40,-40" end="40,40">start</animation>
<animation effect="slide" time="1000" start="40,40" end="50,50">focus</animation>

the above defines 3 animations for the control.

on window start, it's slided from offset (-40,-40) to offset (40,40). on focus, it slides from offset (40,40) to (50,50), and if it's hidden at any stage due to the visibility condition, it'll fade out over 2 seconds. all animations are reversible - ie if it becomes visible again due to a change in visibility it'll fade back in, when it loses focus it'll return to (40,40), and on window exit it'll go back to (-40,-40).

as you can appreciate, it's a reasonably large change, so thought needs to be taken to get it right! opinions are wanted.

cheers,
jonathan

jm,
i know you are busy but can you take a quick look at the images and home.xml i posted to see if you can figure out why my images are not being loaded? i think you may find a bug had been working fine for almost year with the same images.

also, if you can look at the text offset issue. it definitely does not act the way you said it did. i verified and posted a screenshot on my last post.

btw... i like all the ideas you posted.

thanks bro!

there's no textoffset stuff in the button scroller, thus the problem. not sure how easy it will be to add, either.

will see if i have time to look into the images later on.

will try the new infolabel "player.volume" and "player.setvolume(percent)" could use it in my skin, also would like the new animation effects.. aswell. thanks

thanks jm, the changes sound great. i will just work on a new xml engine until the full release and then i will update the editor to the 2.0 version and release.

yep, tnx jonathan and happy new year!
to evereybody

1. all slide starting positions (startx and starty attributes) are now relative to the control (or window) origin. this actually makes things easier in most cases to work out the slide. subtracting off the posx and posy values in your 1.85 skins will take care of this.


does this mean that the start position will now be scaled properly so the start positions will be where they are supposed to?

starting positions as of 1.90 (new anim system going in then) will be scaled correctly.

the new animation system is currently being tested for backwards compatibility + will hopefully be stable in a day or so, then it'll be in cvs.

once again fully backward compatible.

another thing i thought i'd do is extend the controlgroup concept. the idea is to make it an actual control (with id + visibility effects) and have a default control id etc.

you will then be able to have control groups of control groups and the like, and have all the controls animate as one.

a couple of things to work through, but i'm interested in your suggestions.

cheers,
jonathan

(jmarshall @ dec. 30 2005,19:21 Wrote:starting positions as of 1.90 (new anim system going in then) will be scaled correctly.

the new animation system is currently being tested for backwards compatibility + will hopefully be stable in a day or so, then it'll be in cvs.

once again fully backward compatible.

another thing i thought i'd do is extend the controlgroup concept.  the idea is to make it an actual control (with id + visibility effects) and have a default control id etc.

you will then be able to have control groups of control groups and the like, and have all the controls animate as one.

a couple of things to work through, but i'm interested in your suggestions.

cheers,
jonathan

if your controlgroups are along the vein of what i was talking about where you could define a group with attributes in a common location like skin.xml and then just associate control(s) with group(s) using a new <group> tag... then all i have to say is... sweet!

id like to be able to assign below a controlgroup and visible and animation tags, overriden by separate ones in the control group this would save me alot of time repeating the same vis codes for all steps and espically good now it has relative x and y pos

i had a few problems.. but they are :fixed: now.

i'd like to be able to define sounds in a control so we can get past just having navigation sounds and the sounds would follow the same attributes as any additional tags you have added to that control.

smoke,
can you do me another favor (since you were so great on the last one! and test out my images that are not showing up since i rev'd to skin ver 1.8.

the images have not changed for almost a year and were working fine with the same home.xml.

images.zip link

i'm wondering if multiple paths are possible with "imagepath" in multiimage controls, if not... i could use it very much.

like this example...

Quote:<imagepath>home-photos,f:/pictures,e:/pictures</imagepath>

@ affini : will test it on my own pm3 and let you know if i find anything.