Let's make it really simple and ask user interactively, once. This
simplifies things for:
* Privacy panel of gnome-control-center as it doesn't have to filter
applications.
* Apps: If they are denied access, they can simply point users to
privacy panel of gnome-control-center since they can be sure location
access for the app can be enabled in there.
Also it's less annoying to user. Before this patch, if they denied
access to application, they had to keep doing that at least each time
they launched the application.
https://bugzilla.gnome.org/show_bug.cgi?id=762559
Alex told me that since it's not geoclue but rather GNOME-components
storing/accessing app permissions, it's better if we put it under
'gnome' rather than generic 'desktop' table.
Now that we no longer skip dimming/undimming windows while showing
the overview, we can still save a bit of work by changing the dimming
without animation while the window is hidden.
https://bugzilla.gnome.org/show_bug.cgi?id=762475
We skip window animations while the overview is shown (and the window
group is hidden) to avoid unnecessary work. However when an attached
modal dialog is opened or closed, this involves checking whether the
parent window should be dimmed - skipping that test means that we can
simply fail to dim or undim a window altogether, so do that check
unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=762475
While we could have implemented this already a while ago, this would
have been a completely false security mechanism since we had no way of
reliably identifying applications. Since now with xdg-app, we can at least
reliably identify bundled applications, let's give users a choice of
which applications in particular they are OK with giving location data
to.
While we still can't reliably identify system (non-xdg-app) applications,
it seems extremely unlikely we'll ever be able to do that (at least not
in the near future) so we'll have to trust them to not lie about their
IDs.
Next release of geoclue will take the ID of bundled application directly
from corresponding xdg-app metadata so bundled applications can't simply
lie about their IDs.
https://bugzilla.gnome.org/show_bug.cgi?id=762119
This class will be responsible for authorizing applications that try to
access location information. Since this is mainly targetted for xdg-app
applications, we make use of xdg-app's D-Bus API to store
per-application authorization.
https://bugzilla.gnome.org/show_bug.cgi?id=762119
Add a dialog that is used in a following patch, to ask user if they want
a requesting application to gain access to their location.
Co-author: Florian Müllner <fmuellner@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=762119
Only recent IBus versions have support for this signal
which is used for wayland clients. In order to work
with older IBus versions we can silently ignore the
signal's absence.
https://bugzilla.gnome.org/show_bug.cgi?id=753476
We lost media controls outside of notification banners when
implementing the new notification designs. Reimplement this
functionality as a dedicated "Media" section in the message
list based on MPRIS.
https://bugzilla.gnome.org/show_bug.cgi?id=756491
Currently both the base classes for messages/sections and the message
list itself that instantiates the available sections are located in
the same module. As a result, it isn't possible to define sections
in a different module without introducing circular dependencies. The
Calendar module is already unwieldily large, so split it up a bit to
avoid it growing even bigger in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=756491
It is not always possible to determine the type of audio device that
got plugged in. Add a system modal dialog to query the user in that
case and export in on the bus to gnome-settings-daemon.
https://bugzilla.gnome.org/show_bug.cgi?id=760284
IBus now provides a new method for cursor positioning where the
coordinates are relative to the focused window. This is useful for
wayland clients which don't have access to their global coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=753476
We are already emitting a 'drag-end' signal when no more dragging
is happening, so it makes sense to emit a 'drag-begin' too when
starting, so that apps interested in implementing different logic
between those two events can easily do it without needing to deal
with the underlying 'button-press-event' signal for the actor.
https://bugzilla.gnome.org/show_bug.cgi?id=761208
Before reenabling all extensions, we update the list of enabled extensions
to catch any changes that happened while extensions were enabled. However
this is currently broken as onEnabledExtensionsChanged() is a nop while
disabled, so just call getEnabledExtensions() directly.
draggable.startDrag() is called directly here (i.e. manualMode is not set),
we must keep track of the touch event and pass it to startDrag() then.
https://bugzilla.gnome.org/show_bug.cgi?id=756748
We need to keep track of the pointer emulating touch sequence. In order
to have events properly redirected on touch devices, the
Clutter.grab_pointer and ungrab_pointer() have been replaced by the grab()
and grab_sequence() ClutterInputDevice methods, one or the other is used
depending on the device triggering DnD.
An extra "sequence" argument has been added to startDrag, passing null here
will resort to pointer grabs.
This is enough to make thumbnails in the WorkspaceBox draggable through
touch.
https://bugzilla.gnome.org/show_bug.cgi?id=756748
It overrides ::button-release-event in order to implement the
hidden/shown toggling, it must do the same on TOUCH_END, otherwise
menus stay shown on touch.
https://bugzilla.gnome.org/show_bug.cgi?id=756748
This works for pointers and touch on X11, there is however no pointer
emulation on evdev, so touch triggers ::clicked with button==0 which
is ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=756748
Animated backgrounds are based on a start time in local time - in case
of a timezone change, that time is no longer accurate. To fix, we need
to either make BGSlideShow aware of timezone changes (and notify us to
update the animation), or just reload the animation - timezone changes
should be a rare event, so go with the simpler second option.
https://bugzilla.gnome.org/show_bug.cgi?id=758939
Any time estimates we can come up with are notoriously unreliable;
even on devices that report correct (dis)charging rates, any change
in workload, screen brightness etc. can throw our estimate off by
a huge amount. This is further compounded by bad firmware and battery
firmware which reports inaccurate data as neither Windows nor Android do
not use that data.
So instead, limit ourselves to only showing the current percentage
and leave its interpretation to the user.
As an added bonus, we end up with shorter strings that are less likely
to cause problems with ellipsization when translated.
https://bugzilla.gnome.org/show_bug.cgi?id=708472
Builtin chat and network notifications already follow the notification
policy of appropriate applications, it makes sense to do the same for
autorun notifications to give users control over hotplug notifications
in Settings.
If we detected that Bluetooth devices were setup, show the Bluetooth
menu so that users can easily turn Bluetooth back on.
This is a bit of a hack, as we cannot detect whether there is a
Bluetooth adapter at all when it's disabled, so we cannot tell whether
there were any Bluetooth devices setup, at some point. This state is
saved in the gnome-shell GSettings in the had-bluetooth-devices-setup
key.
Checking whether we saw Bluetooth devices at one point is a good
enough guess of whether there will be some in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=723848
It's very unexpected that a spinner animation would
preempt idles from running.
This commit runs the spinner animation with a low
priority to ensure it doesn't take over the main
loop.
https://bugzilla.gnome.org/show_bug.cgi?id=754814
Right now the spinner animation updates every 14ms.
60 frames per second would be one frame per 16.667ms,
so we're waking up more frequently than we need to.
This commit changes the wakeup to happen after 16ms.
https://bugzilla.gnome.org/show_bug.cgi?id=754814
If the source actor is sized 0x0, the grabHelper will close the menu
on button release if the menu ends up flipped because in that case the
release event happens when the pointer is neither over the source
actor (since it's 0x0) or over the menu actor. A zero sized source
actor works for the non-flipped menu case because the menu's actor
itself ends up underneath the pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=756605
If we get another effect on the same actor, we should make sure to
remove the clone through the "overwrite" methods provided by Tweener, or
there will be a race that might end up with a stray clone being left
around.
https://bugzilla.gnome.org/show_bug.cgi?id=756714
The translation should describe the difference between the fullscreened
and unfullscreened position of the window - however we are currently
assuming a fullscreen position of (0, 0) instead of the monitor's origin,
which causes glitches on dualscreen setups.
https://bugzilla.gnome.org/show_bug.cgi?id=756697
Some labels in the system status menu - namely network names - are out
of our control, and may thus grow the width "infinitively" unless we
restrict the menu width. So far we have been doing this by setting a
fixed width or max-width, but any value we put there might end up
being too restrictive in some locales. Instead, request a width that
fits all the labels we want to show unellipsized and use that instead
of an arbitrary limit.
https://bugzilla.gnome.org/show_bug.cgi?id=708472
We use the newly introduced feature from Mutter to hook up our own
fullscreen and unfullscreen animations.
To give the illusion of a transition as smooth as possible, we create a
snapshot of the current contents of the actor before its state is
changed, and crossfade between the two states while the size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=707248
StIcon will skip loading the texture when its theme node is unset (which
may happen on style changes while the widget is hidden). While our size
request to compute the dash icon size will create the icon's theme node
if necessary (and of all its parents), a missing texture can still throw
off our computation.
Make sure this doesn't happen by ensuring the icon's style first, so the
texture is updated in response to StWidget::style-changed if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=745649
When adjusting dash icon sizes, we compute the icon padding by subtracting
the configured icon size from the first icon actor's preferred size. To
make sure that the preferred size correctly corresponds to the current
dash icon size even while the icon is animating, we enforce the size
before the size request. For that we used to temporarily manipulate
the icon texture size directly, but commit e92d204d42 cleaned this
up to use the setIconSize() method instead.
This does not work however, as the icon actor's iconSize property will
always match the dash iconSize property, making the method a noop. So
go back to the original approach of enforcing the texture size to make
sure we always base our computations on correct values.
https://bugzilla.gnome.org/show_bug.cgi?id=745649
There is nothing particularly critical about this notification, it
was only marked as such to get certain behavior like auto-expanding
and sticking-around to be acknowledged by the user (as it offers
more actions than the summary notification, so it is frustrating
when it goes away because it was missed).
As all notifications will now stay visible until we are sure the
users has seen them, the latter reasoning no longer applies.
Auto-expansion doesn't appear too important and may even be considered
annoying by users, so remove the CRITICAL hint now.
https://bugzilla.gnome.org/show_bug.cgi?id=657923
We are currently erroring out when the tab chain doesn't contain at
least one window for an app which might happen for windows that don't
take focus like xeyes. This leaves us in a state where we can't show
the switcher at all. Let's just ignore these apps instead of looking
broken.
While the GtkSettings::gtk-shell-shows-app-menu property is meant to
reflect a desktop capability (i.e. in the GNOME case: the app menu is
shown in the top bar), it is possible for users to overwrite it.
Respect the setting and actually hide the menu in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=745919
Refer to the system menu in the top bar as "System" rather than "Settings" as
it contains more than just settings and "Settings" is already used for the
settings panel. "System" is also used elsewhere, so include context for
translators.
The destroy signal handler is kept connected despite the NotificationMessage
being destroyed, which leaves dangling NotificationMessage objects that will
be mass destroyed when the Notification object these depend upon is finally
destroyed.
Depending on the amount of accumulated NotificationMessages, this may lead
to temporary freezes or other more funky issues when recursion limits are
hit.
https://bugzilla.gnome.org/show_bug.cgi?id=755425
When loading several animations at the same time, the last call
overrides the result for all of them.
This commit caches all animations separately based on the source's
schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=741453
* switch to a one-column layout (and adjust strings/widths
accordingly
* remove separator before system menu
* add link to account settings to user submenu for consistency
https://bugzilla.gnome.org/show_bug.cgi?id=751377
Since commit 79c04c93e4, we launch Polari instead of Empathy when
activating a chat notification for an IRC channel. It therefore makes
sense to follow Polari's notification policy for those notifications
rather than Empathy's.
https://bugzilla.gnome.org/show_bug.cgi?id=752881
Follow the design we have in gtk+ for buttons dialogs,
which are at the bottom and they expand full width, having
the same amount of space for each one.
Also, since this removes any space for non-button widgets
in the button area, move the spinner present in the auth prompt
dialog next to the password entry.
https://bugzilla.gnome.org/show_bug.cgi?id=746108
It may be 2015, but users still stumble upon the occasional .desktop
file that uses a filename encoding other than UTF-8. We currently
fail quite spectacularly in that case by not displaying any apps at
all - handle this case more gracefully, by only filtering out the
offending apps.
https://bugzilla.gnome.org/show_bug.cgi?id=651503
If there's a caret or focus move we should delay it until the pointer
is stationary for a little while so as to avoid jittery and spurious
viewport movements.
https://bugzilla.gnome.org/show_bug.cgi?id=752138
This object (not really a Clutter.GestureAction) sets up a captured-event
handler, which exclusively looks for 4 finger touchpad swipes, emitting
an ::activated signal under the same terms than WorkspaceSwitchAction.
https://bugzilla.gnome.org/show_bug.cgi?id=752250
shell_global_get_overrides_settings() may return %NULL in case of
custom shell modes (i.e. not the default and classic ones); while
this is not officially encouraged, we should still handle it rather
than throw an error.
https://bugzilla.gnome.org/show_bug.cgi?id=751921
The control center will call this method when the configuration dialog
for a display opens/closes, which will cause the same labels to quickly
fade out and in again, looking like it's flickering.
This commit fixes the issue by removing the tweens altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=751599
In some cases we might be allocated a size such that
this._grid.topPadding and this._grid.bottomPadding are both 0 which
means that the ScrollView fade effect gets removed. In that case don't
try to access the effect since it will be NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=750714
The menu items to move a window to the left/right workspaces were
removed when the window menu was implemented in GNOME Shell. This
is OK for the default vertical layout but not for alternatives.
https://bugzilla.gnome.org/show_bug.cgi?id=751344
And make these only handled on wayland. There's a plethora of issues
around touch passive grab and touch/pointer doubly handling to use
these right away on X11, so we stick to single-touch/pointer there.
This reverts commit 032a688a72.
https://bugzilla.gnome.org/show_bug.cgi?id=750287
Instead of using gnome-settings-daemon's D-Bus interface's presence.
iio-sensor-proxy now offers a D-Bus interface, which will exported
"HasAccelerometer = true" when an accelerometer is present.
https://bugzilla.gnome.org/show_bug.cgi?id=749671
Just reuse this gesture rather than implementing edge detection ourselves.
As a plus, we might get touchpad swipe support when Clutter handles it.
https://bugzilla.gnome.org/show_bug.cgi?id=749742
The menu is clearly associated with a particular window, so keeping
it around when the window is gone doesn't make sense - in case of
the window menu, it is actually harmful as every action will act on
the invalidated window and result in a crash. So just dismiss the
menu when the menu is unmanaged.
https://bugzilla.gnome.org/show_bug.cgi?id=749529
When chrome is added with the trackFullscreen parameter, the actor's
visibility will be updated automatically whenever its monitor's
fullscreen state changes. However as we currently ignore the fullscreen
state at the time the chrome is added, the initial visibility may well
be incorrect - fix this by updating the initial visibility as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=749383
Since the introduction of per-source notification policy in commit
098bd4509b, the NotificationPolicy::enable-changed signal has been
used to track the 'enable' setting. However as we never actually
emitted that signal, this never worked without a restart - oops.
https://bugzilla.gnome.org/show_bug.cgi?id=749279
If we aren't the active session clutter can't animate and thus we
can't expect the shield to be shown before releasing the suspend
inhibitor so we should release it immediately when becoming inactive.
https://bugzilla.gnome.org/show_bug.cgi?id=749228
The whole point of holding a suspend inhibitor is to be able to lock
before suspending.
Currently, when resuming we immediately take the inhibitor without
checking that we're locked which means that we won't be able to
release this inhibitor if we don't unlock at least once.
To prevent that and to better match the inhibitor's intention in the
first place, we can tie the inhibitor with not being locked. In
practice, we also want to let the locking animation finish before
suspending, so we'll tie the inhibitor with not being active
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=749228
This could happen if we are VT switched away and an animated
activation is requested because we're preparing to enter sleep. Since
we don't animate in this case we'd never reach
_completeLockScreenShown() before coming out of sleep, at which point
we _inhibitSuspend() again and would leak the previous inhibitor.
https://bugzilla.gnome.org/show_bug.cgi?id=749228
Commit 08690d658f generalized the banner-blocking behavior of the
dateMenu to all menus that would obscure the banner. However setting
up the 'open-state-changed' handler only when an indicator is added
does not work for indicators that change their entire menu (like the
app menu) - we currently end up with menus with no connected signal
handler, and throw an error when trying to disconnect an invalid
signal ID.
To address this, add a new PanelButton::menu-set signal and use that
to set up the 'open-state-changed' handler.
https://bugzilla.gnome.org/show_bug.cgi?id=745910
For barriers like the hot corner which are made up of multiple axis
barriers, make sure that all the barriers have been left before
resetting the barrier.
We currently block banners while the time+date menu is open, as it
would obscure the notification. However it is not necessarily the
only menu for which this is the case, so generalize the behavior
to all menus that would overlap banners when open.
https://bugzilla.gnome.org/show_bug.cgi?id=745910
As notifications appear in the time+date dropdown's message list, there's
a strong relationship between notification banners and the menu. However
while the time+date menu is centered by default, which matches the banner
position, its actual position depends on the session mode - in particular
it is moved to the right in classic mode.
Reinforce the relationship in these cases by moving notification banners
underneath the time+date menu.
https://bugzilla.gnome.org/show_bug.cgi?id=745910
Unlike entries in the calendar's message list, banners are not subject
to the normal keynav chain, and making the banner actor itself unfocusable
allows for the focus to be moved to the action area when expanded.
https://bugzilla.gnome.org/show_bug.cgi?id=747205
The window menu has all those workspace related options, but with multiple
monitors, it is much more interesting to quickly move a window 'over' to the
other monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=633994
Now that the tray is shown temporarily when a tray icon appears,
we can decrease its visible width when concealed to interfere less
with window content without hurting discoverability.
https://bugzilla.gnome.org/show_bug.cgi?id=746787
There is a balance to hit between discoverability and getting out
of the way, and the legacy tray currently fails in both regards.
To address the first issue, temporarily reveal the tray when a
new icon is added.
https://bugzilla.gnome.org/show_bug.cgi?id=746025
Resident notifications are not really a thing anymore with the new
design, so all the user sees are some notifications that mysteriously
cannot be closed. That's utterly confusing, stop doing that.
https://bugzilla.gnome.org/show_bug.cgi?id=746860
libcaribou was designed to generate X events which works under wayland
sessions for X clients but obviously doesn't work for wayland clients
and for shell chrome.
This patch adds a simple caribou display adapter which inherits from
its X display adapter and allows us to continue to work for X clients
and at the same time makes the OSK work on shell text entries by
sending key events directly to the focused text actor.
Making the OSK work for wayland clients requires much bigger changes
at various levels in the stack and either not using libcaribou or
re-working it substantially so that's left for future work.
https://bugzilla.gnome.org/show_bug.cgi?id=747274
Sources are destroyed with their last notification. This is usually the
correct behavior, however in case of chat sources, the corresponding
telepathy channel might still be open, and any further messages that
should trigger a notification are lost because chat sources are only
created when telepathy's channel dispatcher notifies us about a channel
(via ObserveChannels).
Loosing messages like this is unexpected, so keep chat sources around
even without notifications while the channel is open.
https://bugzilla.gnome.org/show_bug.cgi?id=747636
Currently the lifetime of a chat source and its single notification
are tied together. While this apparently makes sense, it means we
will lose all follow-up notifications when a source is destroyed
with the corresponding telepathy channel left open. We will fix this
soon by tying the source to the channel's lifetime rather than the
notification, prepare for this by recreating the notification if
necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=747636
Instead of saving only the current input source when entering password
mode, let's save the whole MRU list so that we can restore it when
returning to normal mode.
This is closer to user expectations since password mode is a transient
and short lived state.
https://bugzilla.gnome.org/show_bug.cgi?id=746605
We don't need a different GSettings object for each app or
favorite item.
While it practice it does not change much (AddMatch is still
obviously sent out), it minimally reduces the overhead on
changes, and makes for cleaner code.
https://bugzilla.gnome.org/show_bug.cgi?id=746509
In recent glib, change notifications don't actually happen unless all
keys have been read, in an effort to reduce unnecessary dbus
traffic for shortlived GSettings object and avoid AddMatch calls.
But we care about changes here, so we need to make sure we're
subscribed, and an easy way to do so is to reuse the same object
to watch for changes and to load the active providers at startup.
https://bugzilla.gnome.org/show_bug.cgi?id=746509
When introducing support for "default disabled" search providers
this part was overlooked, so enabling a default disabled provider
would be ignored until the next login.
https://bugzilla.gnome.org/show_bug.cgi?id=746509
When the chat app is focused, we should hide all banners immediately.
A good way to do so, without tracking which app is focused, is
to look for messages that are acked when the banner is unexpanded,
which implies they were acked by some other telepathy client.
https://bugzilla.gnome.org/show_bug.cgi?id=746364
Pause dynamic workspace management while workspaceSwitcherPopup
is shown so as to eliminate infinite creation and destruction of
workspaces, thus preventing stuttering while trying to move a
window to last workspace.
Add _isWorkspacePrepended flag to make sure only a single workspace
is prepended at a time thus preventing the possibility of prepending
infinite workspaces while dynamic workspace management is on pause.
Prepend a new workspace by creating a new workspace instead of only
shifting the windows to next workspace so that the workspaceSwitcherPopup
may appear in sync with what's happening behind the scene and display
correct number of workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=712778
To switch workspace by keyboard in the overview, the user currently
has to use the normal keybinding. However as the vertical alignment
of workspaces makes them very similar to pages in the app picker, it
makes sense to also support the standard pageUp/pageDown keys.
https://bugzilla.gnome.org/show_bug.cgi?id=742581
"Moving" a window to another workspace doesn't make sense when it cannot
be unstuck, and is potentially confusing if a new workspace is added at
the start/end - just don't do anything in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=746782
NVIDIA drivers don't preserve FBO contents across suspend / resume
cycles which results in broken backgrounds. We can work around that by
forcing a refresh when coming out of suspend.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
There is currently no way to trigger an icon's right-click menu by
keyboard. While there's a good chance that the icon will ignore
<shift>F10 and similar shortcuts, passing on key events will at
least make it work for some icons ...
https://bugzilla.gnome.org/show_bug.cgi?id=746487
While legacy status icons lack a proper accessible name of their own,
we can try to find the corresponding application or the icon's window
title - hopefully most status icons provide at least one, so they
don't show up completely "blank" in screen readers.
https://bugzilla.gnome.org/show_bug.cgi?id=746487
g-s-d has been taking care of this for us but in a very hackish way
that causes dconf writes on every startup and also doesn't handle
dynamic updates to locale1's properties which has become a problem now
that GDM keeps its greeter session running in parallel with users'.
To take care of this properly, this commit introduces a settings
abstraction with both system and session implementations. The session
implementation just wraps access to the existing gsettings while the
system one gets its values from org.freedesktop.locale1's properties.
https://bugzilla.gnome.org/show_bug.cgi?id=746288
Since commit 75745fc23f, the bodyStack itself is no longer start-aligned
to not break custom body actors like chat notifications. However we still
want "normal" body actors start-aligned to get the correct RTL behavior.
We now stopped using notification actors directly for anything, so
we can simplify the Notification class significantly by turning it
into a purely informational object others can use to built their UI
representation from.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
Since we stopped special-casing chat notifications to use the old
notification actor, we need to provide a notification banner to
maintain the inline chat functionality, so split out the UI from
the existing ChatNotification class.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
Special-casing banners of resident notifications was really a
thinly veiled special case for chat notifications, as those were
still using the old notification actor which coupled the life-time
of the notification to its actor. This is no longer the case, so
we can do the sane thing and destroy banners once they are no
longer needed.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
Passing null as body always meant clearing the existing one. While this
mattered less with the old message tray which used the expanded actor,
the new message list in the calendar uses the unexpanded body. We clearly
don't want that to disappear on icon changes, so pass the existing one.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
It makes sense for the gesture to reflect the position of the
activities button / dash. In RTL locales, those are located on
the right rather than the left, so make the gesture apply to
the opposite edge in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=737502
Instead of listening to a dbus property exported by g-s-d, listen to the
MetaBackend signal telling the last interacted device, and make sure we
only show the keyboard for touchscreens.
https://bugzilla.gnome.org/show_bug.cgi?id=745977
While legacy status icons are notoriously bad with regard to
accessibility (well, among many other things), we should still
make them available via ctrl-alt-tab ...
https://bugzilla.gnome.org/show_bug.cgi?id=746022
Currently dismissed events will simply reappear when browsing
back and forth between dates, which is clearly broken. Instead,
hide events that have been dismissed permanently. For now, we
simply store a list of ignored IDs ourselves, until we get API
in evolution-data-server to reliably store custom per-event
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
If the action was initiated by the user, we want to show the
modal dialog immediately, while if the action was initiated by
NM autoconnection policy we first show a notification and then
show the dialog when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=660293
The design calls for differentiating between dismissable reminders
and permanent events, based on whether the selected date is "today"
or some other day.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
While messages in the EventsSection are currently simple enough to
use the generic Message baseclass, the design calls for events to
only be dismissable on the current day. We will need a subclass to
implement this behavior cleanly, so add one.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
As the design calls for slightly different behavior for the current
day, move the _isToday() function out of MessageListSection to have
it available elsewhere as well ...
https://bugzilla.gnome.org/show_bug.cgi?id=744927
Currently the clear action in the section header simply removes all
messages from the section. While the result looks exactly as if the
close button of each individual message had been clicked, the messages
are not actually closed - after a restart (or some other condition that
triggers a reload), the messages simply reappear, which is confusing.
Do the expected thing instead, and make clear close all messages in the
section.
https://bugzilla.gnome.org/show_bug.cgi?id=746027
Currently a message can only be closed by its close button. However
as we want to make a section's clear action synonymous with clicking
the close button of each individual message in the list, we will need
to expose the close action, so add a corresponding method.
https://bugzilla.gnome.org/show_bug.cgi?id=746027
Currently closing all messages is subtly different from clearing
a section, which is confusing. Start making the behavior more
predictable by only showing a close button in the message when
the section's clear button would remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=746027
This closes a race between setTerms and a slow GetInitialResultSet.
The bug manifests as follows:
- initial search for a short string
- previous results === undefined, call GetInitialResultSet
- user types more, cancel previous search in setTerms()
- mainloop, then _gotResults([])
- previous results === [], !!previous results === true
- therefore call GetSubsearchResultSet with an empty list of results
- _gotResults() from GetSubsearchResultSet is empty
- much later, return from GetInitialResultSet is discarded by
cancellable
- user unhappy because what he searched for is not there
After this fix, the flow is:
- initial search for a short string
- previous results === undefined, call GetInitialResultSet
- user types more, cancel previous search in setTerms()
- mainloop, but no _gotResults
- previous results === undefined, call GetInitialResultSet again with
longer string
- some time later, return from first GetInitialResultSet is discarded
by cancellable
- soon after, return from second GetInitialResultSet comes with good
results
- user happy
https://bugzilla.gnome.org/show_bug.cgi?id=745861
If a different message ends up underneath the pointer at the end
of the removal animation, it won't receive an enter event until
the pointer is moved, and thus its hover state will not be correct.
Fix it up manually with an explicit pointer sync.
https://bugzilla.gnome.org/show_bug.cgi?id=746019
As we use two separate body actors for expanded and unexpanded
notifications, updating only one of them on notification updates
is not enough - if the notification has already been expanded,
we need to update the second label as well.
There's a strong expectation that delegating or presenting a channel
will result in a window being activated, so close both overview and
calendar as we do elsewhere.
Enabling line-wrapping of the unexpanded body is not enough to enforce
a single line when the text has embedded newlines, so replace these with
spaces (this is similar to setting ClutterText:single-line-mode, however
that would use a paragraph separator glyph instead).
If activateWindow() is called as the result of activating an item
in the Time & Date drop-down (most likely a notification), it should
behave as other items and close the calendar.
NotificationMessages set the icon either from the corresponding
notification's gicon property, or fall back to the source icon.
Except that we never actually set a notification's gicon property to
the provided icon, so we currently just always fall back, whoops!
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
