(affini @ feb. 05 2006,15:33 Wrote:jm,
i know i mentioned it before but i'll throw it out there again...
cursor control / navigation
even if you decide not to impliment it in v2.0 (but i hope you do, i think the code could be ported from linkbox) please keep it in mind when coding the rest of the engine.
i think having a cursor avail would make navigation much nicer, no need to have left/right/up/down for everything if the skinner chose not to use it.
i'd like it avail for the python engine too since i want to create a script that has a complex interface but would seriously suck (and is what is stopping me from doing it) creating if needing manual navigation.
actually, ysbox already did it...check the linksboks svn for the code...it's a global thing too so it's not limited to just the links integration
it's time they merged if you ask me. (yes i know no one is going to ask me
but anyway)
maybe after v2.0 ? oh and is v2.0 going to be a point build ?
or is it just v2.0 for the skin system ?
(los93sol @ feb. 05 2006,14:53 Wrote: (affini @ feb. 05 2006,15:33 Wrote:jm,
i know i mentioned it before but i'll throw it out there again...
cursor control / navigation
even if you decide not to impliment it in v2.0 (but i hope you do, i think the code could be ported from linkbox) please keep it in mind when coding the rest of the engine.
i think having a cursor avail would make navigation much nicer, no need to have left/right/up/down for everything if the skinner chose not to use it.
i'd like it avail for the python engine too since i want to create a script that has a complex interface but would seriously suck (and is what is stopping me from doing it) creating if needing manual navigation.
actually, ysbox already did it...check the linksboks svn for the code...it's a global thing too so it's not limited to just the links integration
jm,
what do you think... maybe integrating the cursor since the code is already complete?
i have a question, the skinsystem works great for remote and controller users, but for remote users (origional xbox remotes) it is not possible to control volume up, down en mute.
is there a solution for. i like to add buttons in osd to tackle this problem.
sollie
(sollie @ feb. 06 2006,09:53 Wrote:i have a question, the skinsystem works great for remote and controller users, but for remote users (origional xbox remotes) it is not possible to control volume up, down en mute.
is there a solution for. i like to add buttons in osd to tackle this problem.
sollie
add this in <global> <remote> in your keymap.xml
and u will have volume control for your remote.
<one>volumedown</one>
<two>mute</two>
<three>volumeup</three>
thans hardc0r3,
but we have dicussed this before. keymap.xml is not a part of the skinsystem.
thats why i like the buttons in music an video osd and tackle the problem forever.
sollie.
there's one area i see had a little bit of work done recently, but is still very limited....sounds.xml....it would be awesome if we could extend this a bit by having a <sound> tag in the xml. i'd imagine it could work so that sounds.xml would be similar to references.xml in that it is just defaults...and if a sound tag is on a control then xbmc would use the sound for that control. to extend this a bit further even and allow the skinner to have the same sound "types" as animations would give the ultimate control so you could set a sound to follow animation types as well like unfocus, focus, vilibility change, visible, hidden, windowopen, windowclose. that would mean we could even have multiple sounds for each control depending on what's happening. then the icing on the cake would be to have effects for the sound tag just the normal ones like delay and time so you can sync it to your animations and other events in your skin....maybe even a volume attribute? i'm probably just dreaming, but this is one area of the skinning engine i feel is severely underestimated, with all these new animation controls you could really complete the experience for the end user with sounds to match. i'd imagine it would look something like this in the xml...
<control>
<description>media blade image on right</description>
<type>button</type>
<id>1</id>
<posx>598</posx>
<posy>0</posy>
<width>80</width>
<height>576</height>
<include>19009</include>
<font>font14</font>
<textcolor>ff000000</textcolor>
<aligny>top</aligny>
<textoffsetx>46</textoffsetx>
<textoffsety>163</textoffsety>
<angle>270</angle>
<onup>1</onup>
<ondown>1</ondown>
<onright>1</onright>
<onleft>1</onleft>
<pulseonselect>no</pulseonselect>
<visible allowhiddenfocus="true">control.hasfocus(1)</visible>
<animation effect="fade" delay="100" time="100">focus</animation>
<sound type="focus" delay="100" time="100">bladeslide3.wav</sound>
<texturefocus>blades-size3-right-nf.png</texturefocus>
<texturenofocus>-</texturenofocus>
<onfocus>xbmc.replacewindow(1112)</onfocus>
</control>
skin version has been bumped to 1.99. backward compatibility is still around. i am hoping this is the last bump until 2.0 - the only extra thing i want to add is the network dialog - other than that i only want bug fixes in at this point.
the changes are:
1. the "home page fading" code has been removed - use the controlgroup(group).hasfocus(id) if you want it similar to how pm3 handles it.
2. the render order of windows has changed to be more consistent. before what happened is that all controls that weren't in a control group were rendered first, then the control groups were rendered later. now, all controls are rendered in the order of the xml.
a couple of things have been fixed as well:
3. player.showcodec should work in slideshow when no music is playing.
4. controlgroup(group).hasfocus(id) should be working much nicer (ie correct initialization on home window start etc.)
as for the above comments:
1. i'm not planning on extending sounds at this point - we can look into it at a later date.
2. the cursor navigation is not an issue at this point as it doesn't effect the skin versioning system.
3. navigation is only halted during the windowclose animation. i could probably also halt it during windowopen, but the others are trickier and in general you don't actually want them to halt navigation as it just slows things down.
4. hardc0r3: you can position the context menu at will using the <origin> tags. see the online manual for more.
5. sollie: you can edit the skin however you like - that's the whole point of this
cheers,
jonathan
the new commit for <info> on remote control for videos.
how can we use the videoplayer.title/cover/genre etc.. tags without having the dialogseek bar popping up all the time? i thought you may have used a seperate xml for it as the open/close window animations from dialogseek will clash with the animation for video information will they not as they are in the same xml?
use a custom#.xml and use xbmc.activatewindow() to open the new custom window.
the dialogseekbar pops up due to it's visibility condition (player.showinfo + window.isactive(fullscreenvideo).
remove that and it won't pop up.
you can then use the video info stuff wherever (eg in videofullscreen.xml).
cheers,
jonathan
found a few issues lately.
1) an odd behavior with regards to the left joystick
right now it appears that it changes the currently focused id but it does not actually 'do' anything.
also the left joystick does not reset idletime
2) an image control whos texture is defined by the currently focused item in the list control has issues.
it appears 'delay' does not work properly. if you change focused item in the list before the delay as elapsed the image will never display.
3) <controlgroup> affects the order of rendering. it also appears that <include> inside of <controlgroup>'s can affect render order as well. as you (jm) have mentioned fixing the rendering order the other day, perhaps this is related? i am unsure. will test once other render order is commited
4) when animations are interupted sometimes the animation sort of 'panics' and animates a bunch of stuff in then out again.
how does xbmc currently handle animations that are reversed while they are still in motion on their 'way' to visible? it looks like xbmc may disregard the 'delay' tag in an attempt to finish all animations as fast as possible so as to start the hidden animations. perhaps we could have it complete any 'in motion' animations then reverse them. if a animation is still in a 'delay' stage disregard the animation that follows.
tanks
loto
about the "rotate" effect: in the manual its stated that entering a positive number for degrees of rotation rotates the control counter clockwise.
Quote:<animation effect="rotate" end="30" center="360,288" time="200">focus</animation>
i guess i could try this out but will negative numbers rotate it clockwise?
Quote:<animation effect="rotate" end="-30" center="360,288" time="200">focus</animation>
i don't know but, for me a positive number would feel more natural to give a clockwise rotation? or am i just picking on too small details here?
and also will the rotation on the control in the above example reset (like the slide effect) after it is out of focus or will it rotate 'another' 30 degrees next time it is focused? should the be an option like reset="false" or incremental="true"?
negative will go clockwise, yes. this is the standard for angle measure in the plane, so is probably the best way to deal with it.
and yes, it will reset if it becomes out of focus - the effect is applied at render time, and if it's no longer focused then the effect will not be applied. unfortunately having an incremental attribute would not really help - the engine is just not designed for that.
to do what you want, it'd be best to have multiple already rotated controls (not pretty, but at least it does what you require).
cheers,
jonathan
loto_bak:
1. will take a look at what is going on.
2. it could be that the allocation doesn't occur - i'll take a look into it. does it come back once you change focus again?
3. <include> just replaces the include tag with what is in includes.xml, so this shouldn't have an effect on render order, though perhaps it places the new controls as the last control in the group (can't recall offhand, so please test).
4. the logic is that if a "forward" animation is occuring when a "reverse" animation is queued, then it just reverses the forward animation - no reverse animation is performed for that control. if it's in the delayed state then nothing should occur, but there may well be bugs here (the calculation possibly doesn't take into account the delayed time). i'll take a look, but it'd be helpful to have some xml files for me to play with.
cheers,
jonathan