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 581067 - Make the current-workspace indicator in the overlay cooler-looking (eg, a halo/inverted-shadow effect using clutter-cairo)
Make the current-workspace indicator in the overlay cooler-looking (eg, a hal...
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other All
: High enhancement
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2009-05-02 01:15 UTC by Josh Adams
Modified: 2010-12-15 12:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Replaces the existing indicator with a Big.Box, partially transparent, with rounded corners (1.47 KB, patch)
2009-05-02 01:17 UTC, Josh Adams
needs-work Details | Review
[Overview] change current workspace indicator to match AppSwitcher (3.40 KB, patch)
2009-11-12 19:54 UTC, Dan Winship
reviewed Details | Review
Screenshot of how it looks with patch applied (481.16 KB, image/png)
2009-11-12 20:15 UTC, Owen Taylor
  Details

Description Josh Adams 2009-05-02 01:15:33 UTC
Make the current-workspace indicator in the overlay cooler-looking (eg, a halo/inverted-shadow effect using clutter-cairo)

This was requested on http://live.gnome.org/GnomeShell/Todo as job 1.  I'm submitting the bug into the system.
Comment 1 Josh Adams 2009-05-02 01:17:18 UTC
Created attachment 133773 [details] [review]
Replaces the existing indicator with a Big.Box, partially transparent, with rounded corners

I don't know anything about ClutterCairoTexture so I wasn't willing to try anything like an inverted halo / glow effect.  This is a slightly different effect, I think it looks marginally nicer.  Obviously ClutterCairo fanciness is going to be the way to go, and if anyone cares to mentor me briefly on it I'll gladly put the time in to get the patch a little prettier.
Comment 2 Owen Taylor 2009-05-12 18:38:56 UTC
I can barely see it at all, it needs to be fairly obvious what workspace is active.

(Also, the padding/spacing you set on the Box aren't useful in this context, since you are just using it to draw a rectangle.)
Comment 3 Dan Winship 2009-11-12 19:54:37 UTC
Created attachment 147601 [details] [review]
[Overview] change current workspace indicator to match AppSwitcher

Jon mentioned somewhere that we should use the same rounded rectangle
here as we do in the app switcher. (I can't find the bug where he said
this now though.)

Of course, to me it looks darker here than it does in the app switcher,
but that's because of the translucency, and if you had a mostly-black
workspace, the app switcher highlight would look the same as this one.
Comment 4 Owen Taylor 2009-11-12 20:15:37 UTC
Created attachment 147606 [details]
Screenshot of how it looks with patch applied

At least on my screen, I'd say it just doesn't work - the current workspace doesn't pop out out enough to let me know what workspace is current without having to think and look (I probably cropped the screenshot a bit too much - may be easier to just try the patch out)
Comment 5 Colin Walters 2009-11-12 20:16:44 UTC
Review of attachment 147601 [details] [review]:

Hm, ideally St.Widget background would be clipped by border-radius, but it's not at the moment =/  Otherwise one comment.

::: js/ui/workspaces.js
@@ +638,3 @@
+        this._frame.set_position(this._desktop.actor.x - padding,
+        this._frame.corner_radius = padding;
+        let padding = FRAME_SIZE / this.actor.scale_x;

We used to divide by scale_y for the second argument but we're now dividing by scale_x; are we sure they're always the same?
Comment 6 Dan Winship 2009-11-12 20:35:49 UTC
(In reply to comment #4)
> At least on my screen, I'd say it just doesn't work - the current workspace
> doesn't pop out out enough to let me know what workspace is current without
> having to think and look

Solid white is a little too bold though. We could use some in-between value.

(In reply to comment #5)
> Hm, ideally St.Widget background would be clipped by border-radius, but it's
> not at the moment =/  Otherwise one comment.

yeah, at some point we need to move Big.Rectangle's code into St somewhere.

> We used to divide by scale_y for the second argument but we're now dividing by
> scale_x; are we sure they're always the same?

yes
Comment 7 Colin Walters 2009-11-12 20:41:53 UTC
(In reply to comment #6)
> 
> yeah, at some point we need to move Big.Rectangle's code into St somewhere.

Actually, St.Widget uses Big.Rectangle right now (it's kind of a hack...really we need to extract the corner-rendering bits).  From a quick glance at the code it might even handle the corner_radius + background_color case right now actually.
Comment 8 Owen Taylor 2009-11-12 20:44:27 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > 
> > yeah, at some point we need to move Big.Rectangle's code into St somewhere.
> 
> Actually, St.Widget uses Big.Rectangle right now (it's kind of a hack...really
> we need to extract the corner-rendering bits).  From a quick glance at the code
> it might even handle the corner_radius + background_color case right now
> actually.

It does