Tray icons replaced by a shell version are automatically filtered
and never make to the tray container, but when removed by the client
we were still trying to remove them from the tray, causing a warning.
https://bugzilla.gnome.org/show_bug.cgi?id=633028
Each menu is a focus manager group, but there is also some explicit
focus handling between non-hierarchically-related widgets. Eg, to move
between menus, or from a menubutton into its menu.
https://bugzilla.gnome.org/show_bug.cgi?id=621671
The constructor was setting this.active to reflect the switch state,
which is wrong; this.active indicates whether or not the item is
highlighted.
https://bugzilla.gnome.org/show_bug.cgi?id=621671
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
When there are menu items with right-aligned items, all the
right-aligned items should appear to the right of all the left-aligned
items.
Clutter doesn't have an equivalent of GtkSizeGroup, so hack something up
using ShellGenericContainer and some javascript.
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
MutterWindow and MutterPlugin have been renamed to MetaWindowActor
and MetaPlugin, mutter_plugin_list_windows() to
meta_plugin_list_window_actors(). Adapt to those changes.
https://bugzilla.gnome.org/show_bug.cgi?id=632500
_volumeChanged should not update the icon if the sink is muted.
Fixes the case when shell is started with a muted sink (_mutedChanged
is called before _volumeChanged).
https://bugzilla.gnome.org/show_bug.cgi?id=632868
Although within St itself there are situations where the semantics of
these functions (return TRUE or FALSE and return the actual value in
an out parameter) is useful, it's mostly just annoying at the
application level, where you generally know that the CSS property is
going to specified, and there is no especially sane fallback if it's
not.
So rename the current methods to lookup_color, lookup_double, and
lookup_length, and add new get_color, get_double, and get_length
methods that don't take an "inherit" parameter, and return their
values directly. (Well, except for get_color, due to the lack of (out
caller-allocates) in gjs.)
And update the code to use either the old or new methods as appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=632590
Add volume control indicator which uses API from gnome-volume-control
to interact with PulseAudio and shows both input and output volumes.
Also adds a small wrapper around libcanberra in ShellGlobal, used by the
volume indicator to provide auditive feedback.
https://bugzilla.gnome.org/show_bug.cgi?id=629455
Right now if XDG_DATA_DIRS is set to have duplicate entries,
then the extension system will try to load all extensions
more than once.
This commit prevents an extension from getting repeatedly
loaded by checking if its uuid is already registered.
https://bugzilla.gnome.org/show_bug.cgi?id=632477
Tray icons control their own lifespan; they're not supposed to
disappear when you dismiss their notifications like non-trayicon
notification sources do.
https://bugzilla.gnome.org/show_bug.cgi?id=631042
Previously, when you clicked on a notification, it would call
this.source.clicked(), which would emit a 'clicked' signal on the
source, and then various other stuff would happen from there. This
used to make a little bit of sense, when clicking on a notification
was supposed to do the same thing as clicking on its source, but makes
less sense now, when clicking on the source itself *doesn't* call
source.clicked()...
Change it so that when you click on a notification, the notification
emits 'clicked' itself, and the source notices that and calls its
notificationClicked() method, and the various source subclasses do
what they need to do with that, and Source no longer has a clicked
method/signal.
https://bugzilla.gnome.org/show_bug.cgi?id=631042
Redo the way that the summary item expand/collapse animation works so
that the items all resize in unison so that when moving from one to
another, the summary area as a whole stays a constant width rather
than wobbling slightly.
(Also rename all references to the "minimum" summary item title width,
since it's not a minimum, it's just the width.)
https://bugzilla.gnome.org/show_bug.cgi?id=630546
This fixes the bug when the body would be missing from the expanded notification
that has a short body that used to fit in the one-line banner and is expandable
because it has action buttons.
We always want to add the banner to the body of an expandable notification,
unless the notification has custom content. We used to only do that when
creating this._scrollArea for the content. We should also do that when creating
this._actionArea .
https://bugzilla.gnome.org/show_bug.cgi?id=631566
It's possible that an item that was added to the summary got removed before
we had a chance to show the summary because the user has interacted with
the notification (e.g. clicked on an application ready notification). We should
not be showing the summary with an unchanged set of items in this case.
However, it is possible that multiple items were added to the summary before
we had a chance to show the summary, and only some of them got removed. In view
of this scenario, we can't just use a boolean flag to indicate if the summary
needs to be shown, but have to maintain an array of new summary items instead.
https://bugzilla.gnome.org/show_bug.cgi?id=630939
Environment.init() uses Shell.Global, which is not accessible outside
the mutter process; allowing to run the function when window.global is
undefined fixes the environment for tests.
https://bugzilla.gnome.org/show_bug.cgi?id=631091
Introduce Cairo-drawn sliders to be used in PopupMenus (for example for
volume). They are stylable to some extent (colors, border width, slider
height) and have the standard behaviour of a slider, except they are
completely modal (once you start dragging, all events are intercepted by
the slider, which thus is kept active and highlighted at all times).
They show numeric values between 0 and 1 (scaling must be performed outside)
and emit value-changed on button release, but no activate, keeping the
menu open.
https://bugzilla.gnome.org/show_bug.cgi?id=625029
PopupMenuManager now connects to the destroy signal of PopupMenu, so
that destroying a PopupMenu is now enough for removing it from the
relevant manager. Useful if menu come and go on-the-fly (like in
app views or sidebars).
https://bugzilla.gnome.org/show_bug.cgi?id=630914
The semantics of the first argument changed from literal -> regexp
if the 'g' option was specified. To remove ambiguity, stop using
the spidermonkey extension and create a standard RegExp object.
https://bugzilla.gnome.org/show_bug.cgi?id=630539
Having the summary pop up automatically after a source icon has been
removed is pretty useless ("Hey, there was something interesting going
on, but you missed it and it's gone now, kthxbye").
https://bugzilla.gnome.org/show_bug.cgi?id=630939
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
