According to the HIG we should use ellipsis when:
"Label the menu item with a trailing ellipsis ("...") only if the command requires further
input from the user before it can be performed. Do not add an ellipsis to items that only
present a confirmation dialog (such as Delete), or that do not require further input
(such as Properties, Preferences or About)"
So adjust the use of ellipsis to match that.
Pointed out by Michael Monreal.
It was decided at GNOME Summit that we would remove the invisible
setting until we have a better story for how it works with chat
and other sharing/messaging applications. We'd also need to
figure out how it relates to busy.
The action is far less common than powering off. It is mostly
used for performing system updates so the update tool should
offer the option directly. Also, currently the Shut Down option
dialog offers Restart anyway. We would like to keep the number
of entries in this menu as limited (close to 7) as we can.
Switch from St.TextureCache.load_named_icon() to using St.Icon for named
icons. Along with the advantage of getting colorization right for symbolic
icons, this allows moving some icon sizes into the CSS.
In the CSS, the system status icon size is changed to be 1em (=16px for the
default font size), at the request of the artists. See bug 613448.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Adding a "PopupMenuRadioButtonItem" wouldn't work well, because we'll
need radio-button indicators on multiple different styles of menu
item. Also, the current design draws the indicator in the menu item's
padding, so it's sort of special anyway. So just add support at the
BaseMenuItem level.
Also, redo the menu/menuitem padding so that all the horizontal
padding is in the menu item, or else the indicator dot will show up in
the wrong spot.
https://bugzilla.gnome.org/show_bug.cgi?id=631193
Rename a few, and add Suspend and Restart, although currently they do
the same thing as Shut Down (ie, they bring up a dialog that lets you
do any of those three). This will be fixed later when we have the
in-shell modal dialogs for these features.
https://bugzilla.gnome.org/show_bug.cgi?id=631193
In the new mockups, the user menu icons are on the right, not the
left.
Also, get rid of the idea of optional icons; the design doesn't have
icons on those items, and there probably aren't going to be symbolic
versions of some of those icons anyway. So if the caller specifies
PopupImageMenuItem, then always show an icon, and just use regular
PopupMenuItems for the items that don't have icons in the current
design.
https://bugzilla.gnome.org/show_bug.cgi?id=631193
Icons can be loaded as St.Icon.SYMBOLIC, FULLCOLOR, APPLICATION or
DOCUMENT. The first will look for a symbolic equivalent, the second
looks for a full-color version (and does fallback, eg, from
"drive-harddisk-usb" to "drive-harddisk"). APPLICATION and DOCUMENT do
full-color icons without fallback (as specified by the icon spec).
And update various callers to use the right flags.
Based on a patch from Matt Novenstern.
https://bugzilla.gnome.org/show_bug.cgi?id=621311
Solved by splitting the base class (PanelMenuButton) in a separate
module, ui.panelMenu, which is meant to hold also other reusable
button classes.
https://bugzilla.gnome.org/show_bug.cgi?id=621705
Currently, we use 'gtk-yes', 'gtk-no' and 'gtk-media-pause' as
user status icons. It seems more logical to use the dedicated
icons from gnome-icon-theme instead.
https://bugzilla.gnome.org/show_bug.cgi?id=620374
In all the cases where we activate GNOME 2 UI, e.g. the shutdown
dialog, pop out of the overview. Otherwise, it's fairly broken
since you won't see the result of your action.
https://bugzilla.gnome.org/show_bug.cgi?id=620525
Brute force merge these two by essentially replacing St.TextureCache
with a (renamed) Shell.TextureCache.
One function was added for convenience, namely "st_texture_cache_load_file_simple".
St.TextureCache had a function to load a texture from a filename, and it
returned NULL on error but only half the callers actually checked this. This
function is better.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
