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 618460 - menu design improvements
menu design improvements
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on: 618482
Blocks:
 
 
Reported: 2010-05-12 15:11 UTC by William Jon McCann
Modified: 2010-05-19 16:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[panel] Combination of updates to match design suggestions (9.40 KB, patch)
2010-05-12 21:10 UTC, Colin Walters
needs-work Details | Review
[panel] Combination of updates to match design suggestions (10.31 KB, patch)
2010-05-17 16:51 UTC, Colin Walters
committed Details | Review

Description William Jon McCann 2010-05-12 15:11:55 UTC
Some notes on improvements to the menu design

 * as a rule of thumb a menu should have a minimum width regardless of content.  eg. even with just a Quit item the AppMenu should be the same width as the User Menu
 * app menu shouldn't really follow the width of the app name
 * separator style should match mockups
 * separator line should be same height as a line of text
 * should have a shadow
 * might try decreasing edge padding on top, bottom, left, and right (and should be consistent)
 * clicking anywhere outside the menu should probably collapse it
 * should do a fast fade in and out instead of just appearing/disappearing suddenly
Comment 1 Jeremy Perry 2010-05-12 15:49:23 UTC
I'll follow on to Jon's notes
* menu width should be set at some consistent minimum unless otherwise designed. The width of the User Menu feels about right as a guide.
* App menu Quit item could benefit from using the app name in the Quit action, eg "Quit Empathy"
* Decrease the padding around the permimeter by about a third.
* I think the separator should have about half the line height as a line of text.
* Clicking outside the menu definitely should close it.
* fade in and out is really important, and something i think we should standardize the timing for all elements that appear and disappear. Examples
** All menus
** Message tray popups
** "More" menus in the overview
** Search results and transition to/from
** ALT-Tab app switcher overlay
** Change workspace overlay

Note - the Change volume and brightness overlays already have a fade out. Could this be adopted as a standard? I think it is important for things to appear faster than they fade out, we will need to test and tweak the timing to get these right.
Comment 2 Colin Walters 2010-05-12 21:10:07 UTC
Created attachment 160929 [details] [review]
[panel] Combination of updates to match design suggestions

* Add application name to Quit
* Fade in the menu
* Drop some padding around the edges
* Add padding around the separators
* Use a gradient for separators
Comment 3 Colin Walters 2010-05-12 21:40:13 UTC
mccann says to align the edges, don't reserve space for icons.
Comment 4 William Jon McCann 2010-05-12 23:51:02 UTC
With this change my user menu is too narrow and the Account Information and System Prefs items are ellipsized.  We want to preserve a certain minimum width I think but not impose a maximum.

For the alignment issue in comment 3.  I mean something like the following:
http://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/InputLanguage

Where at the left side we reserve some space for checkmarks and radio buttons.  But we align images with with the left edge of an all text row.  In the above example the "en" is acting like an image.

Also, we want to position the separator centered on the text area of the row.  Also, as in the above mockup.
Comment 5 Colin Walters 2010-05-13 13:38:11 UTC
For the menu being too narrow, see the patch in bug 618482 that this depends on.
Comment 6 Owen Taylor 2010-05-14 18:32:32 UTC
Review of attachment 160929 [details] [review]:

Few comments

::: js/ui/panel.js
@@ +171,3 @@
+
+        let gradientHalfWidth = width / 2 - margin;
+        let gradientOffset = height / 2 - gradientHeight;

Should this be:

 (height - gradientHeight) / 2

@@ +179,3 @@
+        cr.fill();
+        pattern = new Cairo.LinearGradient(gradientHalfWidth + margin, 0, width - margin, height);
+        pattern.addColorStopRGBA(0, endColor.red / 255, endColor.green / 255, endColor.blue / 255, endColor.alpha / 0xFF);

Seems more logical to use a 3 stop gradient

@@ +327,3 @@
         this.menu.actor.show();
+        this.menu.actor.opacity = 0;
+        Tweener.addTween(this.menu.actor, { opacity: 0xFF,

We use 255 for opacity, not 0xFF

@@ +329,3 @@
+        Tweener.addTween(this.menu.actor, { opacity: 0xFF,
+                                            transition: "easeOutQuad",
+                                            time: Overview.ANIMATION_TIME });

Sounded like Jeremy wanted fade out as well
Comment 7 Florian Müllner 2010-05-14 21:05:08 UTC
(In reply to comment #6)
> Seems more logical to use a 3 stop gradient

It might be worth considering improving the CSS gradient support to do that - see bug 587003 (predates CSS gradients, but well ...) and the mockup[1] in bug 618479.

Not sure if now's the time to implement "real" CSS gradients[2] or if it would be enough to add an optional background-gradient-center property - the former looks like little fun to parse, but we could start with a very stripped down version (e.g. linear-gradient(linear|vertical, <color>, <color>(, <color>)+) - read: strip bg-position/angle to a simple orientation and reduce color-stops to a color). The latter of course should be a pretty easy addition.

Thoughts?

[1] http://people.gnome.org/~mccann/screenshots/clips/20100331202800/shell-mockup-overview.png
[2] http://dev.w3.org/csswg/css3-images/#linear-gradients
Comment 8 Colin Walters 2010-05-17 16:51:09 UTC
Created attachment 161237 [details] [review]
[panel] Combination of updates to match design suggestions

Use a 3 stop gradient
Fade out in addition to in
Comment 9 Dan Winship 2010-05-19 14:57:14 UTC
Review of attachment 161237 [details] [review]:

the code all looks fine, but i think the fade in/out time is too long?