[REQUEST] Tweens for lists - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32) +--- Forum: Skinning (https://forum.kodi.tv/forumdisplay.php?fid=12) +--- Thread: [REQUEST] Tweens for lists (/showthread.php?tid=101905) |
- BigNoid - 2011-07-18 I'm really impressed by how much difference this makes! With <scrollcorrection> set to false, holding down page up/down looks that much smoother. Also the ability to add tweeners to the scrolltime is very nice and works as expected with the latest setup you provided. I'll be waiting for this to get into master so I can merge a branch with adjusted scrolltimes. Thx pieh - pieh - 2011-07-21 pushed some additional changes/features to my repository github: https://github.com/pieh/xbmc/commits/container_tweak win32 installer: --- removed - some bugs there 1. <scrolltime tween="foo" easing="bar" pagescrolltime="1500">500</scrolltime> basic time of scrolling will be 500 and if container scolling distance will be more than size of 1 item - it will add extra time to compensate increased speed (if scrolling distance will be more or equal width/height of container (page) scrolltime will be 1500) 2. <scrollcorrection>method</scrollcorrection> method can be DEFAULT, AGGRESSIVE, LOOSE or DISABLED
It's hard to describe each method with words - it would be best if You test them Yourself (with very high value of scrolltime to actually see the difference). Personally I hate fact that I'm adding 4 methods here (actually I'd like to get rid of all these options and just keep 1 method) - `Black - 2011-07-21 Pagescrolltime works great. But I didn't notice any difference between aggres(s)ive, loose and disabled. Looks all the same to me and in my opinion the problem I described in #43 still remains. I think the old true/false was enough, maybe it could be Code: <scrolltime tween="foo" easing="bar" pagescrolltime="1500" [b]correction="true"[/b]>500</scrolltime> - pieh - 2011-07-21 repo updated, github: https://github.com/pieh/xbmc/commits/container_tweak win32 installer: http://michal.mexeo.pl/xbmc/container_tween/XBMCSetup-20110721-2dc3434-dx.exe I didn't actually pushed corrected commit from my laptop - "default" was just alias for "aggressive" in this previous one (and thanks for that aggres(s)ive typo ;p) To see difference between "loose" and "aggressive" go to some poster view (poster wrap / fanart in confluence f.e.) and move around with Page up/page down/home/end. Correction tag - eventually I would like to get rid of it totally - I'm just presenting You different options to chose from. As for #43 video I presume, in this case previous "default" method would fit best. But in poster views "aggressive" or "loose" seems a lot nicer (for me at least) than "default" (with "disabled" scrolling is getting out of control). You should try these options with different kind of views to get bigger picture. - jmarshall - 2011-07-21 Quote:eventually I would like to get rid of it totally - I'm just presenting You different options to chose from. Perfect I'm can't remember the reason why it's there to be honest - there must be a reason, but no idea what it is after all this time. Repeat after me: Document anything non-trivial. (On that count, I presume the scroll class thingee will be doxy'd up?) Cheers, Jonathan - pieh - 2011-07-22 jmarshall Wrote:(On that count, I presume the scroll class thingee will be doxy'd up?)Once skinners will be pleased with results (will they ever be? ), yes. Also I will do proper code refactoring and git rebasing when functionality will be ready - currently this is moving target, so can't really design it properly without knowing how it should work - pieh - 2011-07-22 I think I didn't describe what scroll correction actualy does and thus there might be some confussion about it. So I need to add some terms that will help explaining it: Container RenderArea - red rectangle on picture ScrollOffset - this is distance (measured in pixels) between left/top edge of container renderarea and left/top edge of first item in container (length of green arrow on picture) When we change selection in containers that initiate scrolling, container tries to correct ScrollOffset so selected item stays visible for the user - so this happens only when You press key (it won't try to correct ScrollOffset during scrolling if You're not holding key) --- Presentation of different scroll correction methods using slightly changed view in confluence:
PS. Yes I can see that weird things going on screen - this is dirty region related and I will need to check that later - jmarshall - 2011-07-23 The videos are great at showing the difference. Personally I prefer aggressive, but have no issues with Loose should that be preferred in general. Default and Disabled are too extreme in either direction. - pieh - 2011-07-24 I'm leaning toward aggressive mode too - if noone will be againast it - I'll prepare PR in few days. - `Black - 2011-07-25 I prefer disabled over aggressive because with aggressive there's absolutely no scroll out if I scroll left in my list (focused item is left aligned), stops immediately. Right is less than with disabled but I could live with that. Maybe you should left the options. - jmarshall - 2011-07-26 `Black: You mean if you scroll to the right, because the focused item is aligned on the left it never has the ramp down effect? If you scroll to the left, the focused item will move a bit off the left and ramp back to the left on finish? The problem isn't with the restriction, it's just the restriction doesn't make sense when the focused item is hard on the left or right (as there's no looseness there). A video might be useful Cheers, Jonathan - `Black - 2011-07-26 Maybe my explantation wasn't the best, will do a video. - pieh - 2011-07-26 do You mean that if <focusposition> is set to 0 and we go left - it will instatly select previous item without scrolling? this may not look good but this fits logic behind aggresive/loose scroll correction. what is Your proposition to handle it? extend "no correction area" so focused item can be "just outside" of container renderarea? (actually list and panel is doing it that way in aggressive mode) - `Black - 2011-07-26 Yes, focusposition is set to 0. If you scroll 1 item, it's ok but if your scrolling many items, there's no extra pagescrolltime as with disabled. I get why because the focused item doesn't get out of the container and stays left so it stops immediately... so I prefer disabled because there's no big difference in my view. Here are the videos: Disabled Aggressive - Hitcher - 2011-07-26 Maybe it's just me but I prefer the aggressive video personally. |