[BigNoid]

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]

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)

[`Black]

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>

so if someone wants scroll correction, he could add correction="true".

[pieh]

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.

[jmarshall]

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]

(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]

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:

• DEFAULT - http://www.youtube.com/watch?v=cyLEVLk25k8
  this is what is used in dharma/master now - scrolling is done on limited distance
  
• AGGRESIVE - http://www.youtube.com/watch?v=iehTooQ6U-Y
  we only ensure that focused item is kept in container RenderArea - in video focused item is aligned to right border of container when holding key
  
• LOOSE- http://www.youtube.com/watch?v=Q1JtcQ3pGqM
  we only ensure that previously focused item is kept in container RenderArea subtracted by size of single item on both ends (it's marked by blue lines on picture) - so if we are scrolling by holding up/down/left/right - it will keep selected item in RenderArea (same as aggresive), but if we use page up/down / scroll to top/bottom - it won't correct scroll offset presenting some nice effect
  
• DISABLED - http://www.youtube.com/watch?v=PbDHTU6Ev7s
  as tittle say - we don't do any scroll correction - selected item can go out of RenderArea
  

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]

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]

I'm leaning toward aggressive mode too - if noone will be againast it - I'll prepare PR in few days.

[`Black]

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]

`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]

Maybe my explantation wasn't the best, will do a video.

[pieh]

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]

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]

Maybe it's just me but I prefer the aggressive video personally.