It would be nice, if we support CSS3, to do the gradient programmatically - is that possible?

Otherwise, the gradient stepping shouldn't happen if we use a high quality image and you have a reasonable graphics card.

(In reply to comment #1)
> It would be nice, if we support CSS3, to do the gradient programmatically - is
> that possible?

Yes, the gradients we use are done with cairo and are exposed in the CSS - it doesn't follow CSS3 though, but uses a heavily simplified syntax


(In reply to comment #0)
>  * use a gradient that goes to black on the right at about the point the
> workspace area starts

This one will require improvements to the CSS gradient support - currently, we don't support color stops (just start color and end color)


>  * extend the gradient to the top behind the Activities item to try to pull
> that area into the overview a bit more

Mmmmh, I guess we could set a different CSS class on the panel (or use an :overlay pseudo class) ...

Created attachment 160930 [details] [review]
[panel] Hide application menu in overview

(In reply to comment #0)
> I think it is worth trying something like this.
> 
>  * Hide the app menu when in the overview because it is misleading

Check.

OK, some more questions:

(In reply to comment #0)
> http://people.gnome.org/~mccann/screenshots/clips/20100331202800/shell-mockup-overview.png

How does the search entry in this mockup relate to bug 611095 - which one should it be?

>  * extend the gradient to the top behind the Activities item to try to pull
> that area into the overview a bit more

So what do we do with the activities button? Right now, it uses the same "activated" style as the other panel buttons (and remains activated while in overview).

Should we:
a) Remove any "state" style on the button, so that it is always the same
b) Only change its style while transitioning to/from the overview
c) Do something else

Review of attachment 160930 [details] [review]:

Mostly looks good

::: js/ui/panel.js
@@ +556,3 @@
+    show: function() {
+        if (this.actor.visible)
+            return;

I don't think you can use this.actor.visible as a short-cut when it gets updated asynchronously in hide.

hide() gets called and then immediately show(), then we'll think there's nothing to do since this.actor.visible is true until the animation completes.

You probably need a separate boolean stored in the delegate.

Created attachment 161245 [details] [review]
[panel] Hide application menu in overview

(In reply to comment #5)
> You probably need a separate boolean stored in the delegate.

Makes sense.

Created attachment 161470 [details] [review]
[panel] Hide application menu in overview

Rebased to master.

Created attachment 161536 [details] [review]
[Overview] Update background style

(In reply to comment #0)
> I think it is worth trying something like this.
> 
>  * use a gradient that goes to black on the right at about the point the
> workspace area starts

Check.


(In reply to comment #2)
> This one will require improvements to the CSS gradient support - currently, we
> don't support color stops (just start color and end color)

I was really wrong on that one - this one's getting pretty close without any non-CSS modifications, yay!


(In reply to comment #0)
> One thing I don't like about this mockup is the stepping in the gradient.  I'm
> not sure if we have the ability to dither it or if that will help much.

Thinking about it, I don't think it is something we can avoid here: the start and stop colors of the gradient are very similar - there are just not enough intermediate colors to avoid the visible stepping (it's 26 color steps blown up to about 200 pixels ...).
I'd be glad to stand corrected, but I think the only possible solution is to use a lighter start color - which would then probably require adjustments to other colors as well.

Opinions?

Review of attachment 161245 [details] [review]:

You start with:

  this._visible = !Main.overview.visible;

But you don't actually set the visibility of the actor based on that, so you might start off out of sync. Seems like you need a:

  if (!this._visible)
     this.hide();

OK to commit with that fix, if that fix makes sense to you.

(An alternate approach would be to just skip all the nice encapsulation, skip the _visible flag, and renmae show/hide to _show/_hide. But it's fine this way.)

Review of attachment 161536 [details] [review]:

Hmm, I perceive the effect of this as a faint ribbing of the background rather than an actual gradient - not sure that's an improvement from the current version.

Other than using a strong gradient, the only thing that would really improve things is to dither the gradient.

That's not too hard to do for a horizontal/vertical gradient, though is a pain for anything where we are counting on cairo to do more complex drawing. Code for dithered gradients can be found at http://cgit.freedesktop.org/plymouth/tree/src/libply-splash-core/ply-pixel-buffer.c#n311 - and probably could be adapted to our use.

(I might have used a well-constructed dither matrix, like the one from GdkPixbuf instead of the world's cheapest and worst random number generator, but I guess the point is that it just doesn't really matter how you are doing it when you are only twiddling the last bit of 8-bit colors.)

Marking patch needs-work since I don't think we want to land it exactly like this.

<halfline> owen: re gradient code...there's a slightly easier to read version here: http://cgit.freedesktop.org/plymouth/tree/src/libply/ply-frame-buffer.c?id=f594e167b9a0504539bad9cebd0d5430ddbeb522#n644
<halfline> at some point we added loop unrolling because it was slow on olpc
<halfline> but it makes it a lot harder to read

Comment on attachment 161470 [details] [review]
[panel] Hide application menu in overview

Attachment 161470 [details] pushed as a0be7fa - [panel] Hide application menu in overview

(In reply to comment #9)
> OK to commit with that fix, if that fix makes sense to you.

It does.

(In reply to comment #10)
> That's not too hard to do for a horizontal/vertical gradient, though is a pain
> for anything where we are counting on cairo to do more complex drawing. Code
> for dithered gradients can be found at
> http://cgit.freedesktop.org/plymouth/tree/src/libply-splash-core/ply-pixel-buffer.c#n311
> - and probably could be adapted to our use.

Yeah, especially the older version in the second link looks pretty easy to adapt - at least as far as adding support for horizontal gradients is concerned, not so sure about radial gradients (but then - we basically support these because it's easy to do with cairo, the current theme does not make use of them anyway ...)

I'm not sure though whether it will get in the way eventually - right now, extending the gradient support with additional / non-uniform color stops is basically a problem of CSS representation / parsing. If we start drawing the gradients ourselves, we obviously raise the entry bar for improvements - though the aforementioned stuff should still be doable.

Anything else in http://dev.w3.org/csswg/css3-images/#linear-gradients is probably harder to do, but we probably don't want that anyway, right?

No longer relevant for the new layout.