GNOME Bugzilla – Bug 694327
Scroll vfade cuts at the top and bottom
Last modified: 2013-03-01 16:30:47 UTC
See the two attached screenshots: in the first one, the round Brasero icon is in the first row of the view; you can see the icon gets cut at the top when scrolling it down, with no fade effect. This doesn't seem to happen for rows further down in the view, like the Emacs round icon which is in the same position, but two rows down.
Created attachment 237001 [details] cut
Created attachment 237002 [details] not cut
I forgot to add this also happens mirrored vertically for the bottom row.
*** This bug has been marked as a duplicate of bug 694234 ***
Not a duplicate of that one. This refers only to the vfade effect, items are allocated properly.
That was actually a conscious change in bug 689249, but I agree that the effect should kick in sooner.
Created attachment 237167 [details] [review] st-scroll-view-fade: Don't fade out the gradients This change turned out to be worse then what we did before (very noticable in the app picker) so revert to the previous behaviour.
Created attachment 237615 [details] [review] scroll-view-fade: Tweak easing at edges So here's an alternative patch that changes the easing function instead of reverting commit b4f5f1e46174. I've played around quite a bit with different functions, and settled on a variant that gets to the full effect extremely quick - unless I pay very close attention, I don't really notice any difference to a plain revert - but anything else looked worse to me, e.g. there was a notable cut-off at the top/bottom.
(In reply to comment #8) > I don't really notice any difference > to a plain revert - but anything else looked worse to me, e.g. there was a > notable cut-off at the top/bottom. Why no pain revert then? The code is simpler and the result is more or less the same.
(In reply to comment #9) > (In reply to comment #8) > > I don't really notice any difference > > to a plain revert - but anything else looked worse to me, e.g. there was a > > notable cut-off at the top/bottom. > > Why no pain revert then? The code is simpler and the result is more or less the > same. *unless I pay close attention* - in that case it's nicer to not have the effect pop into effect, e.g. the original argument from bug 689249 applies.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > I don't really notice any difference > > > to a plain revert - but anything else looked worse to me, e.g. there was a > > > notable cut-off at the top/bottom. > > > > Why no pain revert then? The code is simpler and the result is more or less the > > same. > > *unless I pay close attention* - in that case it's nicer to not have the effect > pop into effect, e.g. the original argument from bug 689249 applies. OK I have tested it now ... I see what you mean.
Review of attachment 237615 [details] [review]: OK this is much better better, unless designers object go ahead and push it.
Review of attachment 237167 [details] [review]: The other one makes more sense.
Attachment 237615 [details] pushed as b394d18 - scroll-view-fade: Tweak easing at edges It's better what we currently have, so let's get this off the list ...