If users click outside the search entry while it's empty we reset and
thus give up key focus. This means that when using an input method
with candidate popups, interacting with the popup with a mouse click
cancels the current input method context if there's no other text in
the entry besides the preedit string.
To avoid this we can check if the entry has preedit in addition to
checking if it has normal text.
https://bugzilla.gnome.org/show_bug.cgi?id=745167
Ideally we would allow navigating into the button in the screen
reader case, so the configured clocks are read out properly.
However we can still do better than nothing short-term by pointing
to the section header as the button's label_actor.
https://bugzilla.gnome.org/show_bug.cgi?id=745393
Currently both the timestamp and the position in the notification list
are static once a notification has been added; however notifications may
be updated later, in which case those properties should be reevaluated.
https://bugzilla.gnome.org/show_bug.cgi?id=745132
Replace the time formatting in notifications and events with the
new utility method - this makes sure that all times are now following
the clock-format setting and use LC_TIME.
https://bugzilla.gnome.org/show_bug.cgi?id=745111
Currently scroll events during the swarm animation will make the
grid appear immediately in addition to the animating clones, and
there'll be a mismatch with the icon at the target position. This
badly breaks the illusion of launchers emerging from the dash and
positioning themselves in a grid - as scrolling icons "mid-air"
before they form a paginated grid doesn't make much sense anyway,
fix this issue by ignoring scroll events for the duration of the
animation.
https://bugzilla.gnome.org/show_bug.cgi?id=745574
These notifications are annoying for the most part: presence
changes happen inside an app (empathy or polari), and that app
should have in app notifications for errors, instead of spamming
the global notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=745503
The previous code was applying the per row scaling factor of the current
row to the cumulative sum of all previous rows when calculating the y
position of a row. This resulted in the row being shifted up so it would
overlap other windows when the previous rows were not using the same
scaling as the current one.
Also the previous code was not considering that the spacing does not get
scaled when calculating the scaling factor. This is wrong as well and
could result in the overview overlapping the workspace switcher in
situations with lots of windows open.
This fix gives each row the appropriate height according to its scaling
factor and then ensures that the grid remains vertically centered after
losing some of its height.
https://bugzilla.gnome.org/show_bug.cgi?id=744883
Clients can be expected to deal with the WM going away temporarily,
but not the display server - so when running as wayland compositor,
a restart is generally a fancy way of killing the user session, and
there's little we can do about it except for preventing the user to
shoot herself in the foot by throwing an error.
https://bugzilla.gnome.org/show_bug.cgi?id=741665
While those elements cannot be activated, they still provide useful
information to screen readers, so include them in the focus chain.
For the same purpose, set a more verbose accessible name, given that
it is not bound by the same space constraints as the visible label.
https://bugzilla.gnome.org/show_bug.cgi?id=706903
It doesn't make much sense to show a section if it must remain empty
due to the session mode - there won't be any events if the session
mode disallows events, or notifications if those are disallowed. So
take the session mode into account and update the sections' visibility
accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=745494
We currently show the world clocks section unconditionally, even when
the session mode disallows launching the Clocks app to configure the
displayed clocks. This does not make sense, so hide the entire section
when the session mode disallows settings.
https://bugzilla.gnome.org/show_bug.cgi?id=745494
Commit 5a8923ef95 removed support for legacy status icons from
the notification system, as we no longer want them to appear as
notifications. As we are unfortunately not quite at a point where
we can remove all support for them for good, so we now need an
alternative place to put them. Add a small dedicated tray at the
bottom which appears when any legacy status icons are active. By
default it is almost completely hidden to not interfere with the
user's windows, but can be expanded on demand to interact with
the icons.
https://bugzilla.gnome.org/show_bug.cgi?id=745162
polari is the GNOME app for IRC, empathy is for everything else
So prefer polari to empathy for IRC channels. We don't need
to check that either exists (even though polari is not a core
app) because mission control tries every handler if the preferred
one fails.
Depends on bug 745418 for polari to be mission control activatable.
https://bugzilla.gnome.org/show_bug.cgi?id=745431
Make sure the message list section is set to the current date
when opening the menu, otherwise the calendar might skip
the selected-date-changed event (because the day did not change)
which would leave the message list with an uninitialized date.
https://bugzilla.gnome.org/show_bug.cgi?id=745412
Turns out this makes interaction with the OSK or candidate popups
using a mouse basically impossible since they get dismissed when the
key focus is captured by a window in the overview.
This reverts commit aeb9f5775f.
https://bugzilla.gnome.org/show_bug.cgi?id=745245
Messages can be dismissed using a pointer device by clicking the
close button, there's no reason to not make the same action
available via keyboard as well. Delete looks like an obvious
choice ...
https://bugzilla.gnome.org/show_bug.cgi?id=745279
The overview has a longer life-time than dash items, so we are
leaking a signal connection each time an item is destroyed.
Spotted by Michele (<micxgx@gmail.com>)
https://bugzilla.gnome.org/show_bug.cgi?id=744575
As it is impossible to interact with notification banners while a DND
operation is ongoing, we can temporarily hide the banner container from
picks so that DND works as expected even while a banner is showing.
https://bugzilla.gnome.org/show_bug.cgi?id=744912
Since commit e189a34, the trayBox uses a Contraint to cover the primary
monitor's work area. This allows banners to be clipped so they don't
leak into monitors above the primary one during animations. However even
without being reactive, the trayBox now interferes with operations like
Looking Glass' object picker and overview DND.
With the trayBox no longer being positioned manually, there's no strong
reason to keep it in LayoutManager, and handling it in MessageTray allows
to hide the actor while no banner is showing, which helps with the issue
outlined above.
https://bugzilla.gnome.org/show_bug.cgi?id=744912
The actor is supposed to be hidden while no notification banner
is displayed, and in addition to that when banners are temporarily
blocked (because the calendar is open). However the current code
always shows the actor when banners are not blocked, fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=744912
The screen should be woken up when a new notification is shown on
the lock screen, but not when a notification arrives while disabled.
Add a missing condition to fix.
https://bugzilla.gnome.org/show_bug.cgi?id=744114
The mode is never set after the removal of the bottom tray, so it
no longer makes sense to pass it to allowKeybinding(). We can also
safely remove it from the ActionModes flags altogether without
requiring a synchronized update with gnome-settings-daemon, as
the latter never used any flag value above LOGIN_SCREEN.
When it comes to keybindings or gestures, there's not really a good
reason why popups associated with the top bar should behave differently
from any other shell menus. Just set the action mode generically for
all menus, so actions like screenshots or media-keys start working
with menus like the background- or app launcher context menus.
https://bugzilla.gnome.org/show_bug.cgi?id=745039
We reuse the old body text on useMarkup changes and for expanded
labels. However just taking it from the label actor does not work
when markup is used, as once applied it will be stripped from
ClutterText:text.
So to preserve markup, keep our own copy of the original string
around.
https://bugzilla.gnome.org/show_bug.cgi?id=744907
Markup in notification titles is not support (and never has been).
Therefore the text is run through g_markup_escape_text(), and as
a result we do have to use markup internally to correctly show
legal-but-escape characters like '&' or '"'.
https://bugzilla.gnome.org/show_bug.cgi?id=744894
The message indicator conveys that the message list contains unseen
messages that will not be shown as banner. So its visibility depends
on two factors: the number of unseen messages, and the number of
messages waiting in the queue to be shown as banner. As we currently
only update the visibility on changes to the former, the indicator is
not always accurate - for instance sources notify count changes before
passing on a notification to the message tray for display.
To fix, add a signal to the message tray to notify when the queue
changes and use it to update the indicator's visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=744880
Chat notifications are king of custom, so we'll leave them out for now
and keep using the old banner. However we can port the subscription
notification.
Hotplug notifications use custom notification banners to include
application icons in buttons. Bring those back by providing an
appropriate createBanner() implementation.
While we want to encourage the use of regular notification banners,
some of our built-in stuff does require more or less customized content
("more" being chat notifications, a.k.a. king of custom).
Account for this use case by delegating banner creation to a method,
so either Notification or Source subclasses can overwrite it.
Nothing except for the chat notification is really custom, so stop
specifying the flag for anything else - it will soon become a bit
harder to create non-standard notifications, so don't do it for no
good reason (discouraging this is of course the reason for making it
harder in the first place) ...
Instead of using the notification's own actor as a banner (and
keeping it around after the banner was displayed to not dismiss
the notification itself), create a separate banner actor from
the information the notification provides, just like we do for
lock screen and message list notifications.
This change breaks notifications with custom content, but only
temporarily - we will soon provide a hook to allow customizations
again.
We no longer have a single notification actor that is either displayed
as banner or reparented to the summary depending on state - both the
lock screen and the notification section of the message list create
their own UI based on the information attached to the notification
object. Adding to this that different representations of a notification
may now exist simultaneously (as they are included in the message list
immediately rather than after the banner has been displayed), it no
longer makes sense to keep the banner actor in the notification itself.
Add a new NotificationBanner class that provides a separate banner
implementation based on the message list's NotificationMessage that will
soon replace the existing notification banners.
Both the screen shield and the notification section in the message
list create their own UI for notifications rather than using the
notification actor itself. Currently there is no clean way for such
representations to include notification actions - we will need this
as we will soon use a separate actor for banners as well, so keep
track of actions added via addAction().
Notifications in the message list cannot be expanded, however we will
soon use NotificationMessage to re-implement notification banners, where
we still want actions and expanded content.
While this functionality logically belongs to the future banner subclass,
it is cleaner and easier to have the basic support in the base class.
This also leaves the door open for expanded notifications in the summary,
should that become a thing again.
The panel is not visible when in fullscreen, but critical notifications
may still be shown - having them pop out from where the panel would be
looks unpolished, so adjust the trayBox accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
It was removed as actors that should not affect the input
region can simply be added to the uiGroup instead. However
the property is useful to add non-reactive chrome, but then
use trackChrome() to add a child to the input region.
This reverts commit e62d22a50e.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Occasionally it makes sense to constrain to a monitor's work-area
rather than the entire monitor, so implement that behavior and add
a property to turn it on.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
St's hover tracking uses ClutterInputDevice, which unfortunately may use
an outdated cursor position to determine which actor is hovered. Using
MetaCursorTracker instead would fix this, but would require linking St with
libmutter - avoid this for now by manually fixing up Clutter's view of
the pointer position in the case where we rely on it working properly.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
While applications can no longer spam the users with a constant stream
of banner notifications, it is still possible to drown the summary in
the message list. Avoid this by limiting the number of notifications a
single source is allowed to display simultaniously.
test-xy-stress in libnotify's tests suddenly became fun again ...
https://bugzilla.gnome.org/show_bug.cgi?id=744850
We want to shield users from being overloaded by an overwhelming stream
of notification banners, either due to coming back from idle/lock or
because an application is misbehaving. Previously we replaced all queued
notifications with a summary notification in that case, but now that
notifications appear in the summary immediately, we can simply stop
adding them to the queue and rely on the date menu to convey that
information to the user.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
The summary may contain notifications that have not been seen by the user
and won't be shown as banner. Currently this is only the case for resident
notifications that are emitted by the focused app, but it will become more
common as we will start limiting the number of queued notifications.
Indicate to the user that more notifications are available by displaying a
small dot in the top bar button.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Source::count-updated is emitted as notifications are added or removed,
which is correct for the primary notification count. However it is not
for the unseen count, which will also change when a notification is
acknowledged without being removed. At the moment this does not matter,
as the unseen count is only used on the screen shield and notifications
are never acknowledged while the screen is locked. However we will soon
use the unseen count in the normal session as well, so emit the signal
in this case too.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
The message tray is now empty and about to be removed, so an indication
at the bottom edge of the overview becomes an odd location to convey the
status of the summary. We will eventually display an indication in the
top bar that unseen messages are available, for now just remove the
existing indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Using a "There are too many notifications" notification is a bit odd,
and we will address the issue differently soon. So rather than update
the notification to do something else than opening the mostly empty and
useless tray when clicked, remove it altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
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
It was a nice feature, but with sources no longer being represented in
the UI, there is no longer a way for users to make use of it. If we want
to bring the feature back in the future, it would probably make more
sense to implement via the chat source's policy anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Since the summary area was removed from the message tray, Source are not
longer represented in the UI, so right-click menus and summary icons are
no longer a thing.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
The notification list in the calendar drop-down now functions as summary
area, so we can drop it from the message tray and remove a lot of complexity
from the state machine.
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
Display notifications that have not been dismissed in the message
list - eventually this will replace the existing message tray summary.
Notification messages show icon, title and one line of the body and
can be clicked to activate the default action. However they cannot be
expanded, so other actions or the full body text are not accessible
in this mode.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Since notification support was added to the lock screen, notifications
are no longer necessarily represented by the actual notification actor
anymore. However when an existing notification is updated, external
representations currently become outdated.
Emit an appropriate signal which allows them to update.
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
As the popup's height depends on its content, which itself varies
depending on the selected day, browsing the calendar can result
in distracting size changes. To avoid this, the design calls for
the height to be frozen to the previous one in that case.
As the popup will always open with the current day selected, we
don't have to be very sophisticated and can just lock the popup
to the height corresponding to that day.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The message list is not only a replacement for the calendar events
list, it will also take over the notification summary from the
message tray. As we start drawing events from other sources than
calendars, hiding it based on whether or not any calendars have
been set up is no longer appropriate, so always include it in the
calendar drop-down now.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Turn the existing EventsList into a MessageListSection and add the
message list to the calendar drop-down. The new events list only
displays events for the currently selected day, but in a more
structured and friendlier way than the old one.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The message list is a scrollable list that will hold sections of
different types of time-related messages like notifications,
calendar events or birthday reminders. When no section displays
any content for the selected date, a placeholder is shown instead.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
We will start using both URLHighlighter and the _fixMarkup() helper
method the same way it's used in MessageTray. Usually we should
make fixMarkup() public and call the existing methods, but we are
planning for them to go away soon, so just keep two copies until
the original one is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
We will soon replace regular menu items in the calendar drop-down
with more complex elements.
However there will still be items that should close the drop down
when activated - rather than making the menu available throughout
the hierarchy (and eventually from outside as well when we add the
notifications list), have a public method on a global object just
like the ubiquitous Main.overview.hide().
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Menu items are on their way out of the calendar drop down, so let's
start with the easy one. This one is removed without replacement,
but then the Date & Time panel should be a one-time stop for most
users anyway, so not having a direct shortcut should not be much of
a problem. It is also the last remaining Settings item outside the
system menu ...
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The new design has the events list on the left and the calendar on the
right, so swap them around and remove the vertical separator between
them in favor of some additional whitespace as in the mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
This used to be the style-class for status icons (i.e. icon-only
top bar items). It got unused a while ago when the class used
by status icons stopped using it - except for the keyboard indicator,
which set the class manually to appear as status icon despite not
being a real icon.
Now that the button highlight is provided by the .panel-button class
on a parent, the obsolete class results in a double border on the
keyboard indicator when active - just drop it from there as well
to fix.
So we can style it differently than :hover.
We already have a active state for the menu items which includes
more than hover. For example, when the keyboard focus moves to a item
or we select programatically a item.
For this reason we need a style class named active for the meaning we
give to it in menu items, and a pseudo class active with the meaning
CSS has.
https://bugzilla.gnome.org/show_bug.cgi?id=744680
