Commit Graph

22 Commits

Author SHA1 Message Date
Giovanni Campagna
ac6c808124 MessageTray: rework icon handling to split model and view
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
2012-07-21 15:40:28 +02:00
Jasper St. Pierre
9e1a2cfeac Start using MessageTray.Source directly instead of having to subclass it
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
2012-05-17 08:32:22 -04:00
Jasper St. Pierre
f967fd21f8 windowAttentionHandler: Fix updating on title changes
We were supposed to be updating the notification's title when the
window title changes, but we didn't actually bother to re-format
the title and body, effectively leaving the notification unchanged.
2012-02-28 17:23:38 -05:00
Giovanni Campagna
17c46c2452 Port everything to class framework
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
2011-11-24 09:50:04 +01:00
Giovanni Campagna
b356aa8e3b Port message tray sources and notifications to class framework
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
2011-11-24 09:50:04 +01:00
Dan Winship
75b824d032 *.js: Make emacs modelines consistent
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
2011-10-11 08:05:12 -04:00
Jasper St. Pierre
6510904711 windowAttentionHandler: Remove "%s has finished starting"
The message is verbose and confusing. Use the traditional "'%s' is ready"
for all cases.

https://bugzilla.gnome.org/show_bug.cgi?id=660310
2011-09-29 09:59:09 -04:00
Dan Winship
aed50e2a39 shell-global: add a "display" property
and update callers to fetch that rather than doing
"global.screen.get_display()"

https://bugzilla.gnome.org/show_bug.cgi?id=654639
2011-08-03 09:09:55 -04:00
Dan Winship
898b2b903d environment: put gettext stuff into global environment
Rather than defining _() as a local function in every module, put it
into the global environment (along with C_() and ngettext()).

https://bugzilla.gnome.org/show_bug.cgi?id=649203
2011-05-16 14:57:21 -04:00
Hellyna Ng
868bf5838d MessageTray: add right click menu for summary items
This provides straight forward controls for opening the corresponding
application or removing the summary item.

https://bugzilla.gnome.org/show_bug.cgi?id=617224
2011-03-07 11:14:11 -05:00
Adel Gadllah
2ee4f57395 WindowAttentionHandler: Fix notify callback leak
Keep track of the connected handlers and disconnect them on
when destroying the source.

https://bugzilla.gnome.org/show_bug.cgi?id=640781
2011-03-04 08:27:32 +01:00
Dan Winship
de16108dff MessageTray: untangle click notifications
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
2010-10-12 17:21:58 -04:00
Marina Zhurakhinskaya
f8dc3b88f8 Use 'customContent' flag instead of 'bannerBody'
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
2010-08-31 13:47:10 -04:00
Dan Winship
6f57f07214 [MessageTray] Clean up source-vs-notification icon handling
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
2010-08-26 11:00:54 -04:00
Dan Winship
1951812a47 [MessageTray] use Params.parse in Notification
https://bugzilla.gnome.org/show_bug.cgi?id=627303
2010-08-26 10:52:01 -04:00
Dan Winship
8f6a7f393d [MessageTray] remove Notification IDs
Notification daemon notifications have IDs, but other kinds don't
necessarily, and the generic code doesn't need to bother with it.

https://bugzilla.gnome.org/show_bug.cgi?id=627303
2010-08-26 10:52:01 -04:00
Dan Winship
d3031b406a [MessageTray] remove Source IDs
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
2010-08-26 10:52:01 -04:00
Florian Müllner
4632db177a Clean up unused includes
Some late spring cleaning ...
2010-07-19 01:46:01 +02:00
Marina Zhurakhinskaya
83689e494c Show source title on hover, notification on click in the message tray
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
2010-06-23 15:23:01 -04:00
Dan Winship
3ce89e3c80 Add missing semicolons noted by jslint
Taken from a patch by Lex Hider on the mailing list
2010-03-15 09:50:05 -04:00
Adel Gadllah
e6b80927ad Fix demands attention to work with new messagetray api 2010-02-22 23:43:02 +01:00
Adel Gadllah
059504ca70 Add demands attention support to the messagetray
Inform the user about demands attention events using the messagetray.

Clicking on the notification icon moves the user to the window.

It differentiates between newly started apps and windows of already running apps, by showing different banners for this cases.

It is based on Jon Nettleton's "window attention" extension.

https://bugzilla.gnome.org/show_bug.cgi?id=610594
2010-02-22 20:09:43 +01:00