After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 694327 - Scroll vfade cuts at the top and bottom
Scroll vfade cuts at the top and bottom
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: overview
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2013-02-21 01:23 UTC by Cosimo Cecchi
Modified: 2013-03-01 16:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
cut (596.21 KB, image/png)
2013-02-21 01:24 UTC, Cosimo Cecchi
  Details
not cut (603.23 KB, image/png)
2013-02-21 01:25 UTC, Cosimo Cecchi
  Details
st-scroll-view-fade: Don't fade out the gradients (1.98 KB, patch)
2013-02-22 12:16 UTC, drago01
rejected Details | Review
scroll-view-fade: Tweak easing at edges (1.99 KB, patch)
2013-02-28 15:40 UTC, Florian Müllner
committed Details | Review

Description Cosimo Cecchi 2013-02-21 01:23:41 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.
Comment 1 Cosimo Cecchi 2013-02-21 01:24:46 UTC
Created attachment 237001 [details]
cut
Comment 2 Cosimo Cecchi 2013-02-21 01:25:03 UTC
Created attachment 237002 [details]
not cut
Comment 3 Cosimo Cecchi 2013-02-21 01:25:55 UTC
I forgot to add this also happens mirrored vertically for the bottom row.
Comment 4 drago01 2013-02-21 08:25:59 UTC

*** This bug has been marked as a duplicate of bug 694234 ***
Comment 5 Cosimo Cecchi 2013-02-21 12:24:20 UTC
Not a duplicate of that one. This refers only to the vfade effect, items are allocated properly.
Comment 6 Florian Müllner 2013-02-21 12:53:56 UTC
That was actually a conscious change in bug 689249, but I agree that the effect should kick in sooner.
Comment 7 drago01 2013-02-22 12:16:50 UTC
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.
Comment 8 Florian Müllner 2013-02-28 15:40:58 UTC
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.
Comment 9 drago01 2013-02-28 16:07:00 UTC
(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.
Comment 10 Florian Müllner 2013-02-28 16:31:45 UTC
(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.
Comment 11 drago01 2013-02-28 16:45:04 UTC
(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.
Comment 12 drago01 2013-02-28 16:45:44 UTC
Review of attachment 237615 [details] [review]:

OK this is much better better, unless designers object go ahead and push it.
Comment 13 drago01 2013-02-28 16:46:25 UTC
Review of attachment 237167 [details] [review]:

The other one makes more sense.
Comment 14 Florian Müllner 2013-03-01 16:30:43 UTC
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 ...