GNotifications are persistent until dismissed or withdrawn, including
across restarts. As we show the time a notification was received in the
calendar, we need to include that information when serializing the
notification in order to be correct.
https://bugzilla.gnome.org/show_bug.cgi?id=775799
The following code is a syntax error in ES6:
let a = 'something';
let a = 'other thing';
Previously GJS would silently accept this code, but in the next release the
SpiderMonkey JS engine will be more ES6-compliant.
https://bugzilla.gnome.org/show_bug.cgi?id=778425
When a GNotification has the same ID as a previous one, it should
be shown as a new notification after withdrawing the old one.
However for this to work, we must not destroy the corresponding
source if withdrawing the old notification lets the notification
count drop to zero, so make sure the source is kept alive until
the replace operation has completed.
https://bugzilla.gnome.org/show_bug.cgi?id=775149
Clicking on calendar notifications might block till the DBus request times
out if the application being poked happens to be non-responsive. Perform
this asynchronously so we don't block if that is the case.
No Source subclass used it to do anything special, and with sources
no longer having any UI representation on their own, doing anything
else isn't useful either, so just kill off that hook.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
There is not good reason why activating a GTK+ notification should
behave fundamentally different from fd.o notifications - we don't
raise the app because we expect it to perform an appropriate action,
but that does not include closing overview or calendar for us ...
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Just like we leave the overview when activating a notification,
the calendar popup should be closed - after all, the only case
where the calendar is open when a notification's default action
is activated is the user clicking an entry in the message list's
notification section.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
When we will start to show notifications in the date drop-down, we
will not use the actual notification actor, but construct our own UI
based on Calendar.Message. This is similar to what we already do in
the lock screen, except that in this case clicking the notification
should activate the default action.
So rename the existing _onClicked() method to activate() to make it
clear that such use is acceptable. While not strictly necessary, also
rename the corresponding signal to match.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
This capability was only really useful for media players, and with
music notifications no longer being special, we can simplify a bit
by removing support for it.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
Music is no longer a special type of notification according
to the design. If we want to resurrect the functionality, we
can reimplement it with a dedicated API like MPRIS rather
than piggy-bagging on the notification system.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
Tray icons make for a terrible UI on their own, but trying to
shoehorn them into the notification system has only made them
worse. At least for the time being this removal is temporary
and support for tray icons will be back, but no longer as part
of the notification system.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
As far as I can tell, the only behavior change of a transient source
is that they auto-destroy after viewing their summary box pointer.
Since all transient sources are only associated with transient
notifications, it seems that we can never get to their summary box
pointer in the first place! Remove support for this.
https://bugzilla.gnome.org/show_bug.cgi?id=710115
While the existing comment is correct in that a source's notifications
will be destroyed first, the code takes a shortcut which prevents the
Source::count-updated signal from being emitted. Given that the purpose
of the signal is to keep notification counters up-to-date which is
pointless when the source is about to be destroyed, the shortcut makes
sense; just save notifications explicitly in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=710596
The new API is designed to support features like persistence and uses
the new org.freedesktop.Application specification for activating
actions on notifications. While we won't add support for persistence
yet, implement the new notification spec with parity of the old one.
https://bugzilla.gnome.org/show_bug.cgi?id=710137
Some consumers may want to construct their buttons specially, so allow them
to do that by adding a new API that takes a button instead of a label.
https://bugzilla.gnome.org/show_bug.cgi?id=710137
Destroying the notification will make the key focus be reset to NULL, which
means that gnome-shell will try to focus the MRU window, thinking the user is
done interacting and wants to go back to whatever they were doing.
Unfortunately, since we focus two windows at the same time, they will have
the same timestamp, meaning that the window that actually gets focused will
be a race as to whoever responds to their WM_TAKE_FOCUS event last.
If we explicitly set the focus beforehand, then gnome-shell will believe it
got key focus taken away from it, and won't try to focus the MRU when the
key focus drops to NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=703265
Jasper removed the ShellGlobal:stage-input-mode property after its
"last" use was removed. Adapt the (hopefully) really last use of the
property to the recent input changes.
https://bugzilla.gnome.org/show_bug.cgi?id=704095
Previously when a client requests that a window should be docked the
shell would reparent the socket window onto the stage's window and
then use ClutterX11TexturePixmap to get a texture to represent the
window. This will not work if Clutter is no longer using the X11
winsys for example if it becomes its own display server. Instead this
patch leaves the socket window as a child of the root window and lets
mutter create a MetaWindow out of it. If Mutter is acting as a display
server then this mechanism will still work via the headless x server.
The ShellGtkEmbed instance now registers for notification of the
‘window-created’ signal of the display so that it can find the
MetaWindow that gets created to represent the socket window. When this
window is found it is prevented from being displayed on the screen by
setting the actor's opacity to 0. An input shape is then set on the
window to prevent it receiving any input.
Instead of being a subclass of ClutterX11TexturePixmap, ShellGtkEmbed
is now a subclass of ClutterClone. When the MetaWindow is found for
the socket window the clone's source is set to the invisible actor for
the window so it can be displayed in the panel as before.
The ShellEmbeddedWindow no longer needs to know what the stage is
because it no longer reparents the socket window. Therefore the
ShellTrayManager doesn't need to know the stage either so
shell_tray_manager_manage_stage has been replaced with just
shell_tray_manager_manage_screen.
https://bugzilla.gnome.org/show_bug.cgi?id=693438
The notifications spec has two hints for playing a sound, sound-file
and sound-name. We can support them using the existing code that
wraps libcanberra.
https://bugzilla.gnome.org/show_bug.cgi?id=642831
The designs says that only music notifications should be shown in full
in the screenshield, the others should be either shown as a summary or
with very light details.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
Allow message tray sources to provide a NotificationPolicy object,
that will configure how and if the source is displayed. For notification
daemon sources, this object is hooked to GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
We must set the image after calling .update(), because we're passing
clear: true and thus we're removing the image too.
Also, we need to specify an explicit icon size, or St.Icon will use
the default (48px)
https://bugzilla.gnome.org/show_bug.cgi?id=692091
Legacy tray icons may want to take a pointer grab to show a popup menu,
and this is incompatible with message tray modality. To solve this,
escape the tray when forwarding clicks to the tray icons, and wait
for the input mode change to actually synthetize the X event.
https://bugzilla.gnome.org/show_bug.cgi?id=682244
Instead of manually tracking source icon changes, or requiring a manual
call to _setSummaryIcon, add a way to emit a signal when we're guaranteed
the icon has been changed, and then the source actor will automatically
update the icon.
_setSummaryIcon is still available for sources such as the notification
daemon, that require special treatment for the summary icon (to be used
with tray icons)
https://bugzilla.gnome.org/show_bug.cgi?id=680426
If a source is associated with an app, ignore the app name provided
by libnotify, as that is often garbage.
This fixes the "XChat-GNOME OSD" problem.
https://bugzilla.gnome.org/show_bug.cgi?id=681143
To allow more than one summary icon actor for a source we split
the model of the source icon (which is iconName, if the default
implementation is used, or a GIcon otherwise) and replace
createNotificationIcon() with a generic createIcon(size). Also,
the actual source actor is split into a separate class, that handles
the notification counter automatically.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
It's used right away to discard some Empathy notifications.
This regression has been introduced during the 3.4 cycle when 'hints' has been
turned to a GVariant.
https://bugzilla.gnome.org/show_bug.cgi?id=675370
For most subclasses, this is a direct swap -- a lot of the time, the
constructor was a blank class that override createNotificationIcon,
and called _setSummaryIcon in _init.
https://bugzilla.gnome.org/show_bug.cgi?id=661236
That way different system notifications, such as the ones about battery power
and the ones about software updates, are shown with separate message tray
sources.
https://bugzilla.gnome.org/show_bug.cgi?id=664138
The last patch in the sequence. Every place that was previously
setting prototype has been ported to Lang.Class, to make code more
concise and allow for better toString().
https://bugzilla.gnome.org/show_bug.cgi?id=664436
Third step in the class framework port, now it's the turn of
MessageTray.Source and MessageTray.Notification, as well as
the various implementations around the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
Historically, when applications set "image-data" they expect it to show up
as an icon. So we display it as such if an icon is not specified with an
"app_icon" argument to Notify(). We also use "image-path" for an icon if
an icon is not specified.
We only display a large image specified with "image-data" or "image-path"
if an icon is also specified.
https://bugzilla.gnome.org/show_bug.cgi?id=659158
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
Images are part of the notification spec, so we should support them.
Marina Zhurakhinskaya provided some code for getting the layout right
for this patch.
https://bugzilla.gnome.org/show_bug.cgi?id=621009
The "id" variable was being sporadically reset to null, and as far as
Florian and I could determine, this is actually a Spidermonkey bug.
The issue has something to do with:
1) use of "let" for the variable
2) Nesting a dynamic closure inside of a for() loop
Work around it here for now - I tried to create a minimized test case
to hand to the Spidermonkey developers, but failed. A big part of
the problem is it's only sporadically reproducible.
The notification spec supports the concept of a 'default' action:
"The default action (usually invoked my clicking the notification)
should have a key named "default". The name can be anything, though
implementations are free not to display it."
Support this by invoking the 'default' action rather than a emitting
the 'clicked' signal when clicking notifications which specifie a
default action.
Also don't add an action button for the default action.
https://bugzilla.gnome.org/show_bug.cgi?id=655818
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
