i hope it's not impossible to implement.
some kind of optional script language inside a skin xml would be nice.
like:
<description>move graphic id2</description>
<type>anim</type>
<id>2</id>
<posx_01>80</posx_01>
<posy_01>60</pos_01>
<wait>6</wait>
<posx_02>200</posx_02>
<posy_02>60</pos_02>
<loop>
<description>move bottons id1,2,8</description>
<type>anim</type>
<id>1,2,8</id>
<posx_01>0</posx_01>
<posx_02>100</posx_02>
no interest ?
i think with some kind of script a lot is possible.
little background anims, animated or interactive buttons, scrolling for buttons, ...
especially scrolling buttons would be needed by the growing features.
thats something i'd definatly like to see.
sounds interesting but a pain to skin... maybe for a scrolling menu in home.xml yes but... (i know it's been discussed before) flash-anim support would really make things more easy when it comes to anim support. and some kind of scripting to call on different textures for different actions. like in the retro skin the spinning disc in home could have one anim for moving upwards and another anim for moving downwards in main menu.
fex:
<onuptexture>myprogramsup.swf</onuptexture>
<ondowntexture>myprogramsdown.swf</ondowntexture>
and so on. in that way anims can be made with a good editor i.e macromedia flash and skinning can be used to place textures/anims and to control actions.
/floink
i think it could be done optional.
so if there isn't any anim script for buttons or something else in the skin-files there is nothing to do or to change for 'old' skins.
flash will be another story.
this will be very hard for skinners, and is not really needed.
some small script instructs will be hopefully enough.
scrolling buttons or graphics up/down or in/out will be very 'smart'.
(onkel bouncy @ april 12 2004,23:01 Wrote:i think it could be done optional.
so if there isn't any anim script for buttons or something else in the skin-files there is nothing to do or to change for 'old' skins.
ofcourse it would still be optional for a skinner to use and that still goes for flash files too. right?
Quote:flash will be another story.
this will be very hard for skinners, and is not really needed.
why will it be hard to use macromedia flash, except for the fact that u have to learn flash anim editing? why isn't flash support needed? if animaiton is needed i'd say flash support is as needed. why create your own system for animations when there are really good and well-tried ones out there?
look at the <buttonm> and how badly those works compared to fex gif anim. i'm just affraid that we'll end up with something similar to <buttonm> if this anim scripts functionality is pursued.
1. you need flash to create a flash anim.
2. you have to learn flash.
an optional flash support would be nice for some people, but
i think it's to hard for 90% of the skinners.
some simple commands in the skin files would be a start for all skinners.
the music-overlay shows some kind of this small anims.
would flash code need to be added to make .swf(for example) files to work?
is it available?
flash has a far better compression ratio than jpg even..so i can see the benefit in memory usage
moving an object with a script needs not much memory.
flash does the same.
only gif anims needs much memory.
great idea!
...but if coded the devs should wait to implemement it until
after xbmc 1.0 final code is set in stone and announced
this will look great...!
super idea bouncy...
... and don't forget about rotation of textures
if <effect> could take a indelay and outdelay variable in miliseconds that would be great (ie <effect time=1000 indelay=350 outdelay=1000> ) useful for fade in delays using conditions involving system.idletime
slides could make for some very fun animated skins. imo the most user friendly implimentation is to use two cordinates and move a->b
. if anyone was so inclined it could get fancy with acceleration and deceleration variables.
rotation could be done something like 'degrees=270' 'time=1000' and a 'rotatearound=0,0' cordinates. again fancy acceleration and deceleration are possible here as well.
scale in/out effect. not sure if x/y is the upper left or center of an image type control. the image would need maintain its center position during scaling. <effect> tag contains a variable for % scaling
so <indelay> would be the amount of ms to pause before starting the in effect?
and <outdelay> would be the amount of ms to pause before starting the out effect?
will have a think about the sliding ones. can't see much use for rotate/scale (and they're trickier to get right anyway)
might just look into effect="slideleft" (slides in from offscreen to the left) perhaps at first. don't want to clutter it up with too many position variables.
no eta ofcourse - just when i'm bored
cheers,
jonathan