[REQUEST] Tweens for lists

code updated on github that hopefully fixes both issues reported by Black`: https://github.com/pieh/xbmc/tree/container_tweak

in 30 minutes I'll post link to new win32 installer, so if You plan to test - hold on

`Black Wrote:Hmm don't know... Container.Scrolling should (and does) work as an indicator if someone is actually scrolling (holding down a key) or not ((repeatedly) press a key)... for example the scrollletter is displayed if Container.Scrolling is true. At the moment scrollletter pops up everytime you move left/right/down/up in a list because of the Container.Scrolling issue.

I wrongly understood timer used to provide that info - now it make much more sense - this *should* be fixed in next version (20 minutes to upload now)

updated win32 installer: http://michal.mexeo.pl/xbmc/container_tw...1f6-dx.exe

Works fine now. Cubic tweener with 400 or 500ms looks much better than with previous linear and 300ms. However after scrolling it looks better with 1000 or 1500ms but that's too slow if moving only by one item. Also you might change the scrolling animation after maybe 2 or 3 seconds to the old static looking "animation" because it's easier to see where you are in the list... for better explanation here is a short video.

1. So, there should be some way to dynamicly adjust scrolltime - what should it base on? Key holdtime isn't good candidate to take into account when calculating final_scrolltime (with same holdtime it *may* not scroll with same speed on all platforms). I would check how far (in pixels) behind focused item we actually are. I would increase timespeed up to the point we are container height/width behind focused item (maximum scrolltime).

<scrolltime tween="foo" easing="bar" maxscrolltime="1500">500</scrolltime>

or something like this.

2. I get what You mean - but instead of that I would add different approach to <scrollcorrection>:
- true: same as now (this actually checks if we are already scrolling over more than half width/height of container - and if it does it just jump to item)
- false: disabled
- minimal: just keep focused item visible (this will just keep selected item visible - it will keep item aligned to top/bottom/left/right edge of container - depending on orientation and scroll direction)

what You think?

To all testers:
If You tested it please: give me feedback (positive/negative doesn't matter).

pieh Wrote:- minimal: just keep focused item visible (this will just keep selected item visible - it will keep item aligned to top/bottom/left/right edge of container - depending on orientation and scroll direction)

I don't know how well this would work but I guess I would have to test it first. Maxscrolltime sounds good to me.

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

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

• DEFAULT - same as previous (limit distance from focused item to width/height of 25% items_per_fame - if list show 8 items on a page - we can go away for 2 * size_of_item (2 = 25% of 8) ) - unfortunately results differ on different type of containers (it will actually do work on list containers and fixed/wraplist with focusedposition set to 0)
• AGGRESSIVE:
  in lists and panels: limit distance to focused item to size width/height of 1 item,
  in fixedlists and wraplsits: just ensure focused item is visible (if you keep scrolling, jump page or go to top/bottom - new focused item will be aligned to appropiate edge of container and scrolling will start/continue from there)
• LOOSE:
  this is similiar in some ways to AGGRESIVE but it use last focused item instead of new one. If you scroll using cursors (up/down/left/right) there shouldn't be any difference. But using page up/down / scroll to top/bottom will just scroll from last focused position to new one
• DISABLED:
  just disable any form of scroll correction - xbmc won't try to keep focused item in sight

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)

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
so if someone wants scroll correction, he could add correction="true".

repo updated,
github: https://github.com/pieh/xbmc/commits/container_tweak
win32 installer: http://michal.mexeo.pl/xbmc/container_tw...434-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.

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