Instead of leaving the tray covering the whole last pixel row when it's
hidden, hide it completely. This avoids mouse events not being delivered to
application windows on the last pixel row.
To summon the tray we use a single reactive pixel on the corner.
https://bugzilla.gnome.org/show_bug.cgi?id=663366
We must look for the actor under the pointer in the whole message tray and not
just in the notification. This will avoid us to capture focus when a
notification comes up with the pointer on the whole tray area.
https://bugzilla.gnome.org/show_bug.cgi?id=661358
The message tray focus grabbing code sets the stage input
mode to Shell.StageInputMode.FOCUSED when the overview is
not visible. This ensures the stage window's input
region gets reshaped to include the notification chrome,
and so that input events get delivered appropriately to
the notification that grabbed focus.
The message tray code never tries to restore the stage input
mode later. Instead, the code relies on the stage input
mode (and input region) getting reset to
shell.StageInputMode.NORMAL automatically when focus moves
back from the shell chrome to a window in the user's session.
It's not really correct to set the stage input mode based
on the overview's visibility, though. At the login screen,
even though no overview is visible, the stage input mode is
Shell.StageInputMode.FULLSCREEN which is sufficient
for the notification's needs, Furthermore,
Shell.StageInputMode.FOCUSED is insufficient for the login
dialog's needs since the login dialog isn't considered
part of the shell's chrome and won't get included in the
stage input region.
This commit changes the message tray code to only set the
stage input mode if the current stage input mode isn't good enough,
rather than assuming the input mode isn't good enough just because
the overview is hidden.
https://bugzilla.gnome.org/show_bug.cgi?id=660919
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
This ensures that this._clickedSummaryItem is always unset correctly.
Because we disconnect the signals that have _adjustSummaryBoxPointerPosition()
as a callback when unsetting this._clickedSummaryItem, we no longer call
setPosition() on this._summaryBoxPointer after it is hidden. Calling
setPosition() shows the box pointer again, which previously resulted in
an empty box pointer staying behind when a notification associated with
a tray icon was clicked.
https://bugzilla.gnome.org/show_bug.cgi?id=659862
This avoids unnecessarily removing and resetting the icon in the notifications.
This fixes the new chat notification sliding down and up slightly when new
messages are received.
https://bugzilla.gnome.org/show_bug.cgi?id=659768
Previously, when the avatar changed, we would not update the summary icon
for the source at all and would only update the notification icon when the
next message was received. Instead, we should update both immediately upon
recieving the signal that the avatar has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=659768
Clutter 1.4 had a bug where it would wrap when it wasn't supposed to, and we
were unknowingly relying on it. Explicitly pass the available width/height
to get a perfect allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=659633
We don't want the tray bar to open/close quickly when adding a chat because
it happens when user opens the chat from Empathy. The notification will
popup on incoming message anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=657249
This ensures that we don't show an animation of an empty blob being hidden when
clicking an action button causes the notification to be destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=658525
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
Have LayoutManager automatically deal with sizing and positioning
boxes for the panel and messageTray relative to the monitors.
Also, now that LayoutManager knows exactly where and how tall the
panel and tray are, have it manage the pointer barriers as well.
https://bugzilla.gnome.org/show_bug.cgi?id=612662
With the old pre-boxpointer summary notifications, it sort of made
sense that the summary notification actor was a child of the message
tray. But there's no reason for that now, and in fact, it ends up
requiring special cases in some places since hovering over the summary
notification counts as hovering over the tray. So, fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=655813
_fixMarkup() was supposed to be ensuring that the markup we passed to
clutter was correct, but it was validating the syntax incorrectly, and
wasn't checking that the markup was valid (or even well-formed). This
is bad because if you pass bad pango markup to
clutter_text_set_markup(), it will g_warn and drop the string on the
floor.
Fix by fixing up the regexps, and then calling Pango.parse_markup() on
the result, and just xml-escaping everything if parse_markup() fails.
https://bugzilla.gnome.org/show_bug.cgi?id=650298
As _updateCount has been designed to be overwritable by subclasses,
move the check for _actorDestroyed into _setCount(), to fix the
problem described in commit 5f6ac33d5 in derived types as well.
When trying to update the message count after a summary icon has
been destroyed, the label to display the count is no longer valid
and trying to set its text results in some Clutter warnings.
Remove ShellGlobal's monitor-related methods, and have
Main.layoutManager provide that information instead. Move
Main._relayout() to LayoutManager, and have other objects connect to
the layout manager's 'monitors-changed' signal to know when the screen
geometry has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=636963
Every place that called chrome.addActor was specifying
visibleInOverview:true, and no existing designs call for chrome that
disappears when you enter the overview, so just drop that as an
option.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
Theme authors now have the power (and responsibility) of creating fade
effects with the new CSS length property '-st-fade-offset'. A value of
0 disables the effect.
This new CSS approach replaces the current programmatic toggle of
the 'vfade' property. A new CSS style class name 'vfade' is used as
a replacement for the old property.
https://bugzilla.gnome.org/show_bug.cgi?id=651813
Currently, the banner text is always located at the right of the
title - we need to swap those around for RTL locales. Rather than
using the locale directly to figure out the ordering, try to
determine the direction of the title label and let it control the
overall direction of the notification - this way, notifications
generally come out right when mixing scripts.
https://bugzilla.gnome.org/show_bug.cgi?id=646921
This ensures that we don't show a small black blob fading away
when the user clicks on the notification and it is removed.
Set HIDING state right away in _hideSummaryBoxPointer() so that
it is only called once. Update this._pointerInTray when the tray
is unlocked, so that we are not dependent on escapeTray() being
triggered by 'done-displaying-content' signal.
https://bugzilla.gnome.org/show_bug.cgi?id=645697
Use Meta.later_add() with BEFORE_REDRAW rather than Mainloop.idle_add()
to add the banner body so that the notification body is reliably added
after the first frame is drawn. This is important for notifications that
are expanded right away, such as the summary notifications that
were not shown as banners because the user was in the Busy mode or was
interacting with the summary. Otherwise, these notifications were sometimes
shown with an ellipsized banner and were only getting full content when
they were done animating.
Only add expanded content and signal the change once. Previously, we
used to signal the change numerous times and processing this signal was
holding up processing other things, such as the user moving the mouse
away from the notification so that the notification collapses.
https://bugzilla.gnome.org/show_bug.cgi?id=645719
Commit 31b12635d1 fixed links in notifications again, but blocked
clicks on normal labels getting through to the notification. Fix
this, so that both links and dismissing notifications work again.
https://bugzilla.gnome.org/show_bug.cgi?id=645839
The change to make Notification an StButton (06d2c0af, bug 642978)
broke links, because the link actor would ignore the
button-press-event, allowing the notification actor to receive it and
get a pointer grab, and so the link actor would never see the
button-release-event. Fix that by accepting and discarding the
button-press-event.
https://bugzilla.gnome.org/show_bug.cgi?id=645613
If a notification was updated while one of its widgets was focused,
it would lose the grab when that widget was destroyed. Fix that by
moving the focus to a safe place before destroying the old widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=643687
We want to minimize focus stealing from the user. If a non-urgent notification
comes in while the user is interacting with the tray, we add it to the tray
and only show it after the user is done interacting with the tray. If an
urgent notification comes in while the user is interacting with the tray,
we hide the tray and show the urgent notification.
https://bugzilla.gnome.org/show_bug.cgi?id=636838
We want to allow the user to scroll through all notifications from
source by using a single scrollbar. We suppress the individual
scrollbars inside the notifications.
As one exception, we keep the original scrollbar for chat notifications
because it has a distinct look, ending above the text entry box.
https://bugzilla.gnome.org/show_bug.cgi?id=611611
