_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
Both current design and new mockups use square icons. Currently this
is implemented by setting a fixed width and height in the CSS, which
does not work for the growing/shrinking items in the new sidebar.
By moving the assumption of square items into the code, the size will
adjust according to icon size, spacing, padding and font size if not
explicitly overwritten in the CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=625887
The current design features a sidebar where the icon size shrinks
automatically to fit more items. Add a setSizeManually parameter
to BaseIcon, which disables sizes read from CSS and allows to use
BaseIcon.setIconSize() to support this.
https://bugzilla.gnome.org/show_bug.cgi?id=625887
All mockups now use a representation for documents/places similar to
the one used for applications. Rename AppIcon to BaseIcon and move its
code together with WellGrid out of appDisplay to stress their general
usefulness.
https://bugzilla.gnome.org/show_bug.cgi?id=625887
The actor emitted by ShellTrayManager is now ShellTrayIcon, a subclass
of ShellGtkEmbed which has several properties on it which are (or will
soon be) useful to the shell.
Part of the rearranging to use ShellTrayIcon means that we now show
the ShellEmbeddedWindow before creating its ShellGtkEmbed, which
requires a few modifications to ShellEmbeddedWindow (notably, telling
it at construct time what stage it will be drawn on, since it needs to
know that before it has a ShellGtkEmbed now).
https://bugzilla.gnome.org/show_bug.cgi?id=608869
Resolve a notification's ShellApp before posting the notification, so
that notification sources now always have an app associated (assuming
they came from an app as opposed to the command line). Index sources
by PID rather than by appName (so that, eg, multiple calls to
notify-send now show up as separate sources).
For Sources that have an associated app, use the app's icon for the
source, rather than tracking the notification icon.
This change also lets us get rid of appNameMap, since we can just use
shell_app_get_name() now.
https://bugzilla.gnome.org/show_bug.cgi?id=629090
Previously we were hiding the banner label if the title was too long,
but this causes queue_relayout() warnings. Instead, just set its
opacity to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=629308
Introduce the Universal Access status indicator as designed, modeled
after the similar UI provided by g-s-d. This indicator allows the user
to change rapidly the keyboard and mouse behaviour (sticky keys, slow
keys, bounce keys, mouse keys), as well as the enabled ATs (magnifier,
screen reader, screen keyboard) and the HighContrast Gtk theme.
https://bugzilla.gnome.org/show_bug.cgi?id=624916
Adds class PopupSubMenuMenuItem, which is an item holding a submenu,
that is opened when the corresponding item is active, and is keyboard
and mouse navigable like its Gtk counterpart.
https://bugzilla.gnome.org/show_bug.cgi?id=623498
This patch allows the icon in PopupImageMenuItems to be changed at
any time, while preserving the item and all other properties (style,
signals) attached and without rebuilding the whole menu. This is useful
for images reflecting a dynamic status (e.g. cellular strength
indicator or battery level)
https://bugzilla.gnome.org/show_bug.cgi?id=623652
Modal dialogs slide back into the titlebar of the parent window when destroyed.
This looks weird if the parent window itself has been destroyed, so cancel the
effect in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=629560
Extend WellGrid with an optional rowLimit parameter and an accessor
function for the grid's items, then use it to replace the custom
container used to display the application search results.
Also adjust the spacing of the search results slightly to make it
consistent with the app well.
https://bugzilla.gnome.org/show_bug.cgi?id=622446
The keyReleaseEvent handler does not take into account that a
user might release Alt while still holding shift
(the keycode becomes Meta_L/R in that case).
The result is that the switcher stays open which is unexpected.
https://bugzilla.gnome.org/show_bug.cgi?id=629368
Override the new mutter preference /apps/mutter/general/attach_modal_dialogs
to attach modal dialogs to their parent window. Animate the modal dialogs
expanding from the top of the parent window. Slowly dim the parent window
after the dialog comes up.
https://bugzilla.gnome.org/show_bug.cgi?id=612726
This patch ensures the following notifications behavior:
- Urgent notifications that have long title or banner text are auto-expanded
correctly.
- Single-line notifications that have _expandNotification() called (e.g.
because the user mouses over to them), are treated as expanded, which means
they get fully expanded if they are updated with more content and the user
can escape them.
- The position of expanded notifications is updated when they are updated.
- Notification banner is shown again on the first line if it can fully fit
there after a notification is updated, even if it was previously hidden
because the notification was expanded and the old banner did not fully fit.
- New notifications are immediately hidden if the user mouses away from them.
- If a new notification is updated while it is shown, we extend the time it
will be shown.
- If a new notification is updated while it is hiding, we stop hiding it and
show it again.
- If a summary notification is updated while it is hiding, we let it finish
hiding and show a new notification with the updated information.
Implementation details:
- Single-line notifications now have 4px bottom padding instead of 8px, which
means that their height matches the tray height, they are fully shown in the
banner mode, and don't pop out by 4px when the notification is expanded.
- Notification keeps a flag that indicates whether it is expanded, updates
its expanded look when it is updated, and emits an 'expanded' signal
indicating that its layout has possibly changed. The message tray connects
to this 'expanded' signal when it is showing a notification in the expanded
state and updates the position of the notification accordingly when this
signal is received so that the notification is fully shown. This is better
than connecting to 'notify::height' signal on the notification bin, since
it results in fewer callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=617209
The Shell is the only user of the magnifier, so there's no
reason to keep using GConf for its settings. Since it's a
session-wide tool, use a distinct schema,
org.gnome.accessibility.magnifier, stored in
/desktop/gnome/accessibility/magnifier just like before.
Put these settings in a separate schema file for clarity.
Old enums in GConf were stored as integers, we now use the
facilities provided by GSettings to save them as strings,
and convert them to integers automatically thanks to the
mapping stored in the schemas. Remove hard-coded default values,
which we can get from the schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=622414
Return a DND.DragMotionResult constant from delegate _handleDragMotion
methods as well as the existing return value from the drag monitor method dragMotion.
https://bugzilla.gnome.org/show_bug.cgi?id=607821
Expanding notifications automatically just because they popped up where
the pointer is positioned distracts the user. It can also lead to a behavior
that is surprising to the user by, for example, making the user's input
switch to the notification's text entry box.
It is possible to expand a notification that popped up over the pointer
by mousing away from it and then mousing back in immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=617209
We used to keep long titles ellipsized when a notification was expanded,
which was a bug. We now show them fully by line wrapping them.
Based on the original patch from Steven Van Bael.
https://bugzilla.gnome.org/show_bug.cgi?id=623970
We used 'bannerBody' flag to differentiate the case when we move the banner to
the body when the notification is expanded from the one when we don't do that
and only use the custom content set for the notification, as is the case for
Telepathy notifications. We also always cleared the content of the notification
on update when bannerBody was set to true.
Flag named 'customContent' reflects the use case for it more clearly. The
comments that accompany it were also updated and improved.
We now always add the banner text as the first element in the expanded
notification unless 'customContent' flag is set to true.
If the 'body' parameter is specified, we use it in addition to the banner
text. The earlier version of the code had a bug that resulted in the 'body'
parameter not being set only in the case when the 'bannerBody' was set to
true and the banner text had newlines in it.
https://bugzilla.gnome.org/show_bug.cgi?id=623970
The banner should not be appearing briefly when we are hiding the notification.
For that, we should only restore the opacity of the banner in popInCompleted()
when we are done hiding the notification. We do need to restore the opacity
in case the notification is updated and is shown in the banner mode again.
The banner should not be appearing briefly when we are showing the notification
in the summary mode. For that, we should not use the animation time to fade out
the banner in popOut() for summary notifications.
These two problems were particularly visible when the ANIMATION_TIME was increased.
https://bugzilla.gnome.org/show_bug.cgi?id=623970
In Clutter 1.2, clutter_event_get_keysym() ignored the state of the
Shift key. In 1.4, it does not, so we have to adjust our comparisons
accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=627782
The old calculation did not take into account the icon and the spacing
between columns. This resulted in the notifications that had a slightly
longer title/banner combination than could actually fit not being expandable.
The new calculation is done in _bannerBoxAllocate() so
that we don't need to hardcode which other elements are present.
https://bugzilla.gnome.org/show_bug.cgi?id=627985
A Source needs exactly one summary icon (which in the case of a
trayicon-based source won't even be just an image), but possibly many
notification icons, which may vary for successive notifications
(particularly in the case of NotificationDaemon notifications). So
differentiate these cases in the API.
https://bugzilla.gnome.org/show_bug.cgi?id=627303
The tray itself does not actually need them, and to make status icon
sources work correctly the NotificationDaemon will need to be tracking
its sources by two separate IDs, so the existing system won't work.
Also remove MessageTray.removeSourceByApp(), which is
NotificationDaemon-specific, and implement the functionality in
notificationDaemon.js instead.
https://bugzilla.gnome.org/show_bug.cgi?id=627303
The current search system uses the OR operator to concatenate search
terms. While results which are matched multiple times sort before
other matches, it is almost guaranteed that adding an additional term
to the search increments the number of results, which is rather
surprising.
https://bugzilla.gnome.org/show_bug.cgi?id=610955
When calling Notification.update, reuse the previous _bannerBox and
related labels (only changing the label content and relayouting), so
that the opacity set on popOut is preserved. As a consequence, updating
an opened notification no longer shows (or flicker) the banner at the
top.
https://bugzilla.gnome.org/show_bug.cgi?id=625502
The start date is shifted by a week if the day number of the month's
first day is smaller than the week start's day number. Probably the
only real world examples are months starting on a Sunday with locales
using Monday as start of week.
https://bugzilla.gnome.org/show_bug.cgi?id=625756
It is not obvious that only the icon is clickable to activate the
default action - in fact, with the area being that tiny, many don't
even know that notifications can be clicked.
Just extend the clickable area to the whole notification.
https://bugzilla.gnome.org/show_bug.cgi?id=613932
Adds class PopupSwitchMenuItem, which is a two-state switch similar
to those in system status indicators mockups. Also adds class Switch,
which represents the switch itself, in case it is useful somewhere
else.
https://bugzilla.gnome.org/show_bug.cgi?id=621880
In addition to already grabbing focus in the summary notifications,
we also want to grab focus in the new notifications when the user
hovers over them and expands them.
The notifications that expand automatically will only get focus once
the user hovers over them. The notifications that don't expand will
never grab focus because they don't need it.
Make sure that we toggle the way we grab focus when switching between
the overview and the main mode. This is necessary because, unlike
summary notifications that pop down when the user moves between the two
modes, new notifications keep being shown as long as the user hovers
over them or until they time out.
https://bugzilla.gnome.org/show_bug.cgi?id=617224
Because clicking on the summary item to have it display its notification
is a more deliberate action than hovering, we can now grab focus in that
notification. This makes chat notifications in the summary more convenient
to use because you don't need to click on the text entry there.
We pop down the notification when the user clicks anywhere outside of it,
triggers the overview, or the run dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=617224
This ensures that the summary appears when we are showing a new
notification and switch to the overview at the same time.
Another effect of this patch is that the summary is shown if the
user moves the mouse to the bottom right corner while a notification
is being shown, which is ok.
This patch adds the method "removeMenu" to PopupMenuManager, to allow
for removal of menus after they're inserted. In order to do this, it
needs to store along with the menu all the relevant signal connections,
that are disconnected when the menu is removed.
Also adds a parameter "position" to "addMenu", so that menus can added
in arbitrary order (in particular to reintroduce those which were removed).
This patch is intended towards dynamic menu users, like extensions for
application lists, docks, sidebars showing recent documents or favourites,
as well as advanced system tray implementations.
https://bugzilla.gnome.org/show_bug.cgi?id=622730
In GSettings, a change notification is generated immediately from context of the _set() call.
In GConf, The "value_changed" signal is emitted whenever the server
notifies your client program that a value has changed in the database (100% NOT from context of the _set() call).
https://bugzilla.gnome.org/show_bug.cgi?id=624296
We need to only connect to 'action-invoked' on notification once
when the notification is created. We were accumulating callbacks
otherwise, which resulted, for example, in the Rhythmbox skipping
through multiple tracks when the 'Next' button was hit.
Always be sure to destroy the notification when its source is
destroyed, which is the case when an action is invoked.
Note that in the future, we might not want to destroy the source
for some notifications when an action is invoked. For example,
it makes sense to keep Rhythmbox in the tray while the music is
playing and allow the user to use the controls from the summary
notification too.
