We don't want sources that are no longer associated with a running application
to stick around in the message tray.
Message tray sources were removed when the associated application’s state
changed to Shell.AppState.STOPPED . This caused sources for applications
that were still running, but did not have any open windows to be removed.
Instead, we should use the notification’s sender removal from DBus as an
indicator for when to remove the associated source from the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=645764
When a source has an associated tray icon, we would forward all clicks
to the X11 window, meaning that the summary notification could not
be opened. Instead, restore normal event flow for clicks, when the
source has notifications in the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=645753
The applications have to have a way of keeping resident notifications
updated without unnecessarily notifying the user with the information
the user is already seeing in the application window.
https://bugzilla.gnome.org/show_bug.cgi?id=630847
If the user clicks a trayicon in the overview, drop out of the
overview before passing the click on to the icon. (We have to actually
wait for the overview animation to complete, in case the icon wants to
get a pointer grab, which it would not be able to do with the overview
active.)
https://bugzilla.gnome.org/show_bug.cgi?id=641853
If the user clicks on the title of a trayicon's SummaryItem, forward
that click to the trayicon. Also adjust
gnome_shell_plugin_xevent_filter() so that if the trayicon takes a
grab as a result of this, we don't hide the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=630842
See commit f2158218bef0c51 in mutter. Basically, we need
to grab org.freedesktop.Notifications before anything else
in the session gets started.
Note: I intentionally removed the Util.killall bits. I believe that
for notification-daemon at least, if we specify
DBUS_NAME_FLAG_REPLACE_EXISTING, we'll take over the name. Not sure
about notify-osd; if that's still a problem, then what we need to do
is add killing (and possibly respawning) of notify-osd to
"gnome-shell --replace", and not have it embedded randomly in a JS file.
https://bugzilla.gnome.org/show_bug.cgi?id=642666
This fixes emitting NotificationClosed for resident notifications
that are clicked, but are not actually destroyed.
This also ensures that we emit NotificationClosed in all cases when
a notification is destroyed, which can happen when:
- a non-resident notification is clicked
- an action is invoked on a non-resident notification
- an application the notification was associated with is focused
- a transient notification is done showing
- a notification was requested to be closed by the application
- a tray icon the notification was associated with is removed
https://bugzilla.gnome.org/show_bug.cgi?id=638071
Since we have to use pkill, kludgily, for the right combination of
portability and featurefulness, put the code in one place rather than
duplicating it everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=635089
Add an entry in config.js.in for PACKAGE_VERSION and GJS_VERSION,
to be used by the notification daemon and in the future by the
extension system.
https://bugzilla.gnome.org/show_bug.cgi?id=639255
Transient notifications are removed after being shown. If the summary
is being shown while they appear, they are represented in it by a new
source icon.
We always create a new source for new transient notifications to
ensure that they don't replace the latest persistent notification
associated with the source. Because we generally don't want any
new or resident notifications to be replaced by others, associating
multiple notifications with a source is the next thing we will
implement.
https://bugzilla.gnome.org/show_bug.cgi?id=633412
Resident notifications don't get removed when they are clicked or
one of their actions is invoked, and are only removed when the app
that created them requests them to be removed or sends another
notification.
Remove the source when a notification associated with it is removed.
Except if the source is a tray icon.
Make sure that we pop down the tray when a notification is clicked
or one of the actions of a non-resident notification is selected.
Based on the initial patch by Jonathan Matthew.
https://bugzilla.gnome.org/show_bug.cgi?id=633412
NotificationDaemon-based notifications have markup in the banner/body,
but Telepathy-based notifications don't. (Eg, an XMPP message
containing "<b>foo</b>" should show up angle brackets and all, not as
bold.) Fix MessageTray.Notification to allow explicitly specifying
where there should and shouldn't be markup, and use that
appropriately.
https://bugzilla.gnome.org/show_bug.cgi?id=610219
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
Action names sometimes unintentionally overlap with icon names, so
we should only create icon buttons if the message tray source requests
it. For the notification daemon, this is done by setting the
'action-icons' hint on the notification.
The previous notification server capability used to advertise this
feature, "x-gnome-icon-buttons", has been removed in favour of the
new capability described in the notification spec, "action-icons".
https://bugzilla.gnome.org/show_bug.cgi?id=624584
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
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
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
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
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
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.
This is part of the design update for the message tray.
Source now takes an extra argument called 'title'.
All expanded message tray items are same width, which is determined by
the width of the item with the longest title, up to MAX_SOURCE_TITLE_WIDTH.
This is done so that items don't move around too much when one is expanded
and another one is collapsed.
https://bugzilla.gnome.org/show_bug.cgi?id=617224
This is our convention.
The only exceptions are double quotes for words in comments that give
them a special meaning (though beware that these quotes are not truly
necessary most of the time) and double quotes that need to be a part
of the output string.
Also reorganizes the notification layout to use an StScrollView; very
tall notifications are now scrolled instead of just taking up more and
more of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=608999
Notify() was calling setApp() unconditionally after attempting to
determine an application. However, determining the application can
fail (for example, when notify-send is used) and resulted in an exception
being printed.
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
When the currently focused app sends a notification while in the overview,
the corresponding source icon is not removed when the overview is left.
It does make some sense to treat the overview transition the same as a
normal focus change, so we should update the summary view accordingly.
When a notification is updated by the application, the corresponding
app in its source is lost, so it is no longer possible to switch to
the application by clicking either the notification or the summary icon.
As the associated application of a source never changes, it appears safe
to leave it alone on notification updates.
https://bugzilla.gnome.org/show_bug.cgi?id=610820
Source icons are no longer needed to inform the user about events
having occured in a particular application when (s)he activates the
window - treat that case just as if the user had clicked the source
icon.
https://bugzilla.gnome.org/show_bug.cgi?id=610494
We are planning to add Empathy-specific features in the message tray, but in the
meantime we handle Empathy notifications received through the notification daemon
so that their behavior is closer to the eventual design, which is how it was before
we started associating applications with a single source and enabled notification
replacement.
Use the "appName" parameter in notifications to identify the source
rather than the id - use the latter to enable update and removal of
individual notifications as laid out in the desktop notification spec.
This is a rebase of the patch by Florian Müllner.
Changes notifications like:
XChat: Private message from: danw (GimpNet) blah...
to
danw: blah blah blah blah
(the "XChat" being unnecessary since there's already an xchat icon
there anyway.)
https://bugzilla.gnome.org/show_bug.cgi?id=608915
This adds some meaningful functionality to the notification icons in the tray
and in the notification pop-up and allows to switch to the application that
sent the notification.
We get the application from the notification context and set it on the source
for the notification.
