If the padOsd is given a nonexistent ring/strip, things would fail
badly later when trying to paint a 0x0 StLabel. Just avoid creating
more ring/strip labels than those known by libwacom.
This is unlikely to happen, but seems better to protect against it.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
The porthole will not be destroyed when the scale factor changed.
That makes workspace thumbnail porthole still wrong size in the first
seeing after the scale factor changed.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
PopupMenu needs special-treatment of certain types of menu items,
which it determines via children's _delegate property. However as
the calendar drop-down is very unmenu-ish, we use regular actors
rather than PopupMenuItems and the missing _delegate property
triggers a warning. Just add it as the bare minimum to make
PopupMenu happy.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
The destroy effect currently relies on a monkey-patched property
added from the map effect. However on X11 it is possible that we
did no map animation for a window that is destroyed when the shell
was restarted or had taken over from another WM. Just use the real
MetaWindow property to avoid a warning in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
It's possible for updateRegions() to be called before monitors have
been properly initialized. Instead of throwing an error in that case,
just skip the strut computation (that doesn't make sense anyway without
a monitor).
https://bugzilla.gnome.org/show_bug.cgi?id=781471
findMonitorForActor() may be called before the layoutManager gets
to initialize monitors, so make sure the monitor index is in range
to avoid a warning.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
Don't try to access a non-existent engine - it probably makes sense to
use Map() instead of a plain object to track engines in the future, but
for now just add an additional check to shut up a warning.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
We only use lastItem() to reset the history index to the end, so
nobody noticed the utter nonsense in the return value until gjs
started to warn about it. As we don't actually use the value
anywhere, we could just remove it, but the function name implies
that an item is returned, so fix it to behave as advertised.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
We need to track the open-status of indicator menus, but don't want
to hook up signals more than once, so we check for the handler ID
we store on the object. As the property is only defined once we did
set up the signal connection, this check now logs a warning. We
can avoid it by checking for the existence of the property rather
than a particular value.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
To avoid recreating the app menu unnecessarily, the panel checks
whether the menu's current actionGroup already matches the target
one. However as the menu's actionGroup property is currently private,
the test always fails, whoops.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
We currently use "array[index]" to test whether an array has an
element at index before using it. However nowadays gjs warns about
accessing non-existent array elements, so the test itself already
produces a warning. Avoid this by checking the array length before
using an index to access an element.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
While we've always considered it good style to initialize JS properties,
some code that relies on uninitialized properties having an implicit
value of 'undefined' has slipped in over time. The updated SpiderMonkey
version used by gjs now warns when accessing those properties, so we
should make sure that they are properly initialized to avoid log spam,
even though all warnings addressed here occur in conditionals that
produce the correct result with 'undefined'.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
The user list uses the same indication for hover and focus, so it
is possible for two items to be highlighted at the same time. Using
different styling would improve the situation, but only to some
extent - the user would still need to figure out which highlight
corresponds to which activation method. So instead, copy the
approach we use in popup menus and use a single property for
highlights that is updated by both focus- and hover changes.
https://bugzilla.gnome.org/show_bug.cgi?id=772284
It is possible to use the scroll wheel to adjust the volume without
opening the system menu, but there is no feedback other than the
icon itself in that case. To provide a less coarse indication for
the volume level, display the OSD window when adjusting the volume
while the slider isn't visible.
https://bugzilla.gnome.org/show_bug.cgi?id=781028
Since commit 2c070d38, we add a ClickAction to the visible AltSwitcher
button to track long-presses. As a result, we now have two components
that will grab and ungrab the pointer for the button, so to make sure
we don't end up with a stuck grab, we need to release the second's
component grab when the first activates.
Currently we only drop the StButton grab on long-press, we also need
to cancel any initiated long-press on click.
https://bugzilla.gnome.org/show_bug.cgi?id=781738
Some PAM modules say "Press enter to continue" or
whatever. We need to support them.
This commit allows empty responses to PAM questions,
but still requires a non-empty response for username.
https://bugzilla.gnome.org/show_bug.cgi?id=784360
If the user fails to enter their password then hits escape, we
jump back to the user list, then ask again for a password in a
garbled screen. this commit fixes that by skipping a retry if
the operation is cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=784361
We currently assume that window state changes are accompanied by an
allocation change (triggered for example by the minimize animation).
However this misses the case where a window actor is simply hidden
without any transition, as is the case with the 'show-desktop' action
for instance, so start tracking plain visibility changes as well.
https://bugzilla.gnome.org/show_bug.cgi?id=783975
While the string returned by formatTime() should follow the locale's
text direction as a whole, the actual time part is always expected
to put hours on the left and minutes to the right. It is possible to
enforce that by inserting a left-to-right mark, but so far this is
only done by the Hebrew translation. So in order to not require all
other RTL translations to be fixed individually, just insert the
mark into the returned string ourselves like gnome-desktop's WallClock
code does[0].
[0] https://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-wall-clock.c?h=gnome-3-24#n267https://bugzilla.gnome.org/show_bug.cgi?id=784130
There were some source IDs that were not being reset to zero when
removing the associated sources, resulting on some critical errors
being dumped when _realRecalculateWindowPositions() got called
after that point, via _delayedWindowRepositioning().
Ever since commit b8e29ae8c7
(I think), start up is littered with this message:
Gjs-WARNING **: JS ERROR: could not get remote objects for service
org.gnome.SettingsDaemon.Smartcard path
since gnome-shell is now started before gnome-settings-daemon.
This commit addresses the problem by making the object manager code
not try to autostart its proxy, and instead wait for it to appear.
https://bugzilla.gnome.org/show_bug.cgi?id=772589
If the user fails to enter their password then hits escape, we
jump back to the user list, then ask again for a password in a
garbled screen. this commit fixes that by guarding against the retry
if the fail counter is reset.
This effect will only be created when the StScrollView actor has either
a non-zero vertical or horizontal fade offset defined, so we need to
add a null-check in these two cases before assuming it's there.
https://bugzilla.gnome.org/show_bug.cgi?id=783823
Gjs-Message: JS WARNING: [resource:///org/gnome/shell/portalHelper/main.js 360]: reference to undefined property top.uri
is caused by the URI variable actually being called "url".
https://bugzilla.gnome.org/show_bug.cgi?id=783286
When using an SSH tunnel (through a SOCKS proxy) to funnel all
the outgoing traffic, we need the captive portal to not go through that
proxy, otherwise we can't go through the proxy because we're not
connected to the Internet and we can't go through the portal because
we're not connected through the proxy.
This fixes a blank captive portal window and no error reporting in that
particular configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=769692
The .solid style isn't supposed to apply for modes that don't support
windows, but for this to work we have to update the style on session
mode changes.
https://bugzilla.gnome.org/show_bug.cgi?id=783202
Commit b929320d4 added a toolbar item to force garbage collection,
however it won't be visible for most users, as it uses a non-standard
legacy icon name (the default icon theme dropped it as far back as 2009).
https://bugzilla.gnome.org/show_bug.cgi?id=782982
The fullscreen animation code is now generic enough to handle any
size change animations, so stop limiting it to (un)fullscreen to
get animations on (un)maximize as well.
https://bugzilla.gnome.org/show_bug.cgi?id=766685
Currently, the translation values are set with the assumption that
one of the actors represents a fullscreen window. In order to
generalize it for any size change transition, we can simply swap
the monitor rect with the source or target rect as appropriate,
and translate the actor from the target to the source position by
subtracting the former and adding the latter.
https://bugzilla.gnome.org/show_bug.cgi?id=766685
Since there is already targetRect that represents where the
window is going to move, rename oldRect to sourceRect to
represent from where the window is moving.
https://bugzilla.gnome.org/show_bug.cgi?id=766685
If the popup happens to be mapped beneath the pointer, mutter will now
emit an implicit enter notify event (i.e. not caused by pointer motion).
In this case the switcherPopup still goes and selects the item, which
results in too sensitive alt-tab menus if the pointer happens to be in
the wrong place.
Make highlighting rely on motion events instead, so it always involves
user interaction when triggered by the pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=755164
The solid black top bar we currently use works well for maximized
or tiled windows, as it puts focus on the application content by
blending into the monitor bezel. However it also visually reduces
the screen space, which is particularly noticeable when no window
is located nearby. Having the top bar blend with the background is
a better option in that case, so track window positions and add
some transparency when the top bar is free-floating.
https://bugzilla.gnome.org/show_bug.cgi?id=747163
And merge with the "internal" show/hide() ones. Those functions don't
proxy dbus method calls anymore, so it makes no sense to expose these.
Also, the timestamp is no longer needed as there is a single source for
these events.
https://bugzilla.gnome.org/show_bug.cgi?id=777342
The caribou daemon only gives us focus tracking, which is almost 1:1 with
our own FocusCaretTracker implementation. This means we can entirely
replace the Caribou daemon inside gnome-shell, reducing the Caribou
dependency to just libcaribou, and more specifically the
CaribouKeyboardModel we pull the keyboard models from.
As we still need underneath a CaribouDisplayAdapter to drive the keyboard,
reuse the wayland one, which has been renamed to make it look generic, plus
it will use the virtual input device API from mutter/clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=777342
Some search providers such as GNOME Characters want to copy search
results to clipboard. However, on Wayland, clipboards are only
accessible from applications that have a visible surface on display.
This patch allows a search provider to request the shell to copy a
search result to clipboard when 'clipboardText' is included in the meta
of the result.
https://bugzilla.gnome.org/show_bug.cgi?id=775099
We are moving the icon to be added before the text instead of after,
which is consistent with other menu items in other popup menus, such
as the ones in the system indicator's popup menu.
https://bugzilla.gnome.org/show_bug.cgi?id=782166
This allows passing an optional icon parameter to addAction()
so that a PopupImageMenuItem instance is created instead of a
PopupMenuItem if an icon is specified.
https://bugzilla.gnome.org/show_bug.cgi?id=782166
Add an extra check to setIcon() so that either a GIcon or an string
with the icon's name is handlded, so that we can create menu items
in different ways (e.g. by passing a GIcon created from a resource).
https://bugzilla.gnome.org/show_bug.cgi?id=782166
Some extensions out there may fail to reload. When that happens,
we need to catch any exceptions so that we don't leave things in
a broken state that could lead to leaving extensions enabled in
the screen shield.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
Since 5b3fb024be, the main window is only shown when not launched
with a valid UUID. As GtkDialog isn't meant to be used standalone,
we currently trigger a (harmless but annoying) warning in case
the main window isn't shown; we can avoid the warning by setting
up the preference dialog manually instead of using the GtkDialog
convenience class.
https://bugzilla.gnome.org/show_bug.cgi?id=781545
So far, the GWeatherInfo was given the enabled weather providers
as a parameter, at construction time. Because of the way in
which libgweather was designed, setting the providers right from
the beginning enabled libgweather to use them internally in order
to update its state. Updating the internal state is only relevant
when there is a valid location set, which is not guaranteed at the
time when the GWeatherInfo object is constructed.
In order to fix this, enable no providers at construction time and
only set valid providers after setting a valid location.
https://bugzilla.gnome.org/show_bug.cgi?id=780404
Recently Music gained a flatpak manifest inside the repo in bug 779905.
However that requires the desktop file to be properly named like
DBUS addresses are.
This patch renames the old Music desktop file to the new one.
https://bugzilla.gnome.org/show_bug.cgi?id=780157
Add a new D-Bus method for setting the monitor labels. This new method
takes connector names instead of output ids for associating with actual
monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Since the workarea and margins are both in pysical pixels dimensions (we
fetch margins from Clutter, not from the theme), but the CSS expects
logical (scaled) pixels, unless we consider the scale factor when
setting max-height, it won't work on a HiDpi display.
This fixes missing scrollbars when the calendar popup is full on HiDpi
displays.
https://bugzilla.gnome.org/show_bug.cgi?id=753305
Generalizing menu toggling via keyboard in commit 1d58ea25ab
fixed keynav in many places, but it turns out that it also adds
unexpected interactions in some cases where the source is not
button-like, as for example the entry context menus provided by
ShellEntry. Commit e33c68a415 fixed one case, however it is still
possible for plain enter/space to unexpectedly trigger the menu
if the entry itself doesn't consume the event, which is the case
when ClutterText:editable is false. However for a general fix, it
makes more sense to consider the source actor's :reactive property
and disable toggling menus via keyboard when they cannot be toggled
by pointer either - expecting non-editable entries to be non-reactive
as well seems like a reasonable assumption, and indeed all our code
follows that pattern.
https://bugzilla.gnome.org/show_bug.cgi?id=758873
Instead of using directories that we'll destroy when done, use the new
"ephemeral" data manager feature, through the JavaScript version of:
webkit_web_context_new_ephemeral()
We also throw an error on startup, in the logs, if WebKitGTK is too old.
https://bugzilla.gnome.org/show_bug.cgi?id=780453
Our weather integration should follow GNOME Weather as closely as
possible, which means that we should respect its location permission
rather than using our own or none at all (which we can as a "system"
component and as geoclue's authorization agent).
https://bugzilla.gnome.org/show_bug.cgi?id=780252
It doesn't make sense to tie the proxy code for flatpak's permission
store to the location indicator, just because that was the first
component to use it, so split it into a separate module.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
The setting to globally disable location settings altogether isn't
handled by the geoclue service itself, but by the authorization
agent. This means that:
- it doesn't apply to system components
(which gnome-shell is now considered[0])
- it doesn't apply once the geoclue connection
has been authorized
However users can reasonably expect that we won't use location services
after they disabled them, so handle the setting explicitly.
[0] https://cgit.freedesktop.org/geoclue/commit/?id=a4cef6c0ad08https://bugzilla.gnome.org/show_bug.cgi?id=780252
We currently use automatic location for weather forecasts if the
corresponding Weather setting is set, however we should take other
factors into account as well:
- whether location services are enabled at all
- whether Weather has been authorized to use them
In preparation of these changes, track the setting's value in a
separate property and make _useAutoLocation a getter, so we can
extend it with additional conditions easily.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
Setting GWeatherInfo:location to null helpfully doesn't mean
"no location", but "NYC". This obviously isn't what we want
to show users, so track the location validity separately and
consider it when updating the label shown to users.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
When using the 'disable-lock-screen' setting to lock down the screen
lock, the expectation is that users cannot lock the screen. However
as it turns out, all the setting currently does is hiding the lock
button in the system menu and making the lock settings in the privacy
panel inactive. That means that if the 'lock-screen-enabled' setting
isn't disabled and locked down as well, we will just continue to
lock the screen on inactivity - not to mention the keyboard shortcut
that isn't subject to that setting anyway.
Instead of expecting administrators to hunt down every possible way
of locking the screen and disabling it individually, we can easily
handle all cases by refusing to lock the screen when disabled by the
lockdown settings.
https://bugzilla.gnome.org/show_bug.cgi?id=780212
Dragging and dropping app icons is expected to work anywhere over a
workspace, however overlaid elements are added to a separate hierarchy
and can thus block valid drop targets. This wasn't much of an issue
while we had just the window title, but since the addition of the
focus border, drops on window previews stopped working entirely.
Fix this by hiding all non-reactive overlay elements from picks.
https://bugzilla.gnome.org/show_bug.cgi?id=737166
We rely on the service to detect whether a fingerprint reader is
present. It is fine to not support fingerprint authentication
when the service is missing, but currently we don't handle this
case at all and end up with a non-functional login screen.
https://bugzilla.gnome.org/show_bug.cgi?id=780063
Currently when the wifi selection dialog is open when the screen lock is
activated, the dialog remains visible above the shield. This is clearly
broken, so close the dialog automatically on session mode changes if the
mode doesn't allow settings (as changing the access point is arguably a
user setting).
https://bugzilla.gnome.org/show_bug.cgi?id=780054
The critical hint is meant to be used for notifications that must not
be missed - running out of battery being the prime example - so it
makes sense to ignore the policy in that case and make sure to always
show them to the user. This is consistent with blocking normal
notifications while showing a fullscreen window, but letting critical
ones through.
https://bugzilla.gnome.org/show_bug.cgi?id=779974
Whenever there's more than one pad in the same group (eg. Wacom ExpressKey
Remotes), show a popdown menu to allow configuring those extra pads.
Devices are hot-pluggable, so the popdown menu will update its state
whenever pads are added/removed.
Also, allow to quickly change between pads by switching to its OSD by
just interacting with them. Always given they are in the same group.
https://bugzilla.gnome.org/show_bug.cgi?id=779986
Telepathy's role has been diminishing continuously over the last
couple of years, so while chat integration is a nice feature for
those who use it, it is hard to justify keeping it as a hard
dependency. To address this, split out the component from the
client so we can handle missing typelibs gracefully by not
providing any chat integration.
https://bugzilla.gnome.org/show_bug.cgi?id=779878
If GeoClue is not responding for some reason, the callback of
Geoclue.Simple.new would not get called, meaning that _gclueFailed
remains false. This is preventing the fallback to the most recently
used location in gnome-weather, because it requires _gclueFailed to be
true (or auto-location to be disabled). So neither code path sets a
location and the libgweather default (New York City) is being used
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=779898
For most notifications, banners are suppressed while the monitor
that is used to display banners is in fullscreen. With the old
message tray at the bottom, this used to be the bottom-most monitor,
but nowadays it's always the primary one, so update the corresponding
code to use the correct monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=779819
The telepathy integration was written at a time where gjs didn't
allow to inherit from GObject classes, which is why we needed a
C helper class. This hasn't been the case for a while now, so cut
out the middle man and implement Tp.BaseClient directly.
https://bugzilla.gnome.org/show_bug.cgi?id=771721
Rename the signals which have been used to handle XDnd events to more inclusive
ones. So that these signals can be used to handle the DnD events in Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=765003
Commit c6f22826cf added a call to update() to refresh the notification
time for sent and received messages. However as it omits the bannerMarkup
parameter, escaped text like ''' now makes it through verbatim.
Rather than adding the parameter, we can just refresh the timestamp in
the existing update() call to fix the issue - it means the notification
timestamp is only refreshed for received messages, but that reflects
the text shown in the notification, which isn't updated for sent
messages either.
https://bugzilla.gnome.org/show_bug.cgi?id=779435
Media notifications currently always show the forward and backward
buttons as clickable, regardless of whether the corresponding action
is available or not. Media players usually address this by rendering
controls insensitive in this case, so do the same here.
https://bugzilla.gnome.org/show_bug.cgi?id=773884
Without the boxy background, event messages look a bit plain and
unaligned with other messages. Adding an icon addresses this,
however as repeating the same icon over and over again in case of
many events would be rather noisy, only show it for the top event
as in the mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
Update the notification style according to the latest mockups:
- make notification icons smaller and prefer symbolic variants
- remove background box when not hovered/focused
- increase spacing between elements
- use normal text sizes
https://bugzilla.gnome.org/show_bug.cgi?id=775763
For notifications in the message list, it is usually less relevant
when exactly it occurred, but how long ago. So rather than showing
the exact time and expecting the user to figuring out the timespan
themselves, change the format to something human readable.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
Currently the secondary actor (if set) and the close button are
exclusive, that is the latter replaces the former on hover. As
the swapping feels rather busy and there's no real reason both
cannot be shown at the same time, keep the secondary actor always
visible.
A welcome side effect is that it no longer needs to be placed at
the end, so we can move the notification timestamp right next to
the corresponding title.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
The section titles usually don't provide a lot of value - messages
themselves are usually pretty unambiguous about their type, and
having a hidden shortcut to some settings panel or application isn't
essential either - except when showing the selected date when browsing
other days, as it adds context to the listed events. Based on that,
remove the section title as a general MessageListSection feature and
move it into the EventsSection, where we only show it when it is useful.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
We will eventually remove section titles from the message list to
reduce visual noise and give the actual information provided by
the messages more space. So in order to not lose the ability to
mass-dismiss messages, the latest mockups spot a "Clear All" button
at the bottom - implement that.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
The latest mockups contain a button to clear all sections at once.
As some elements cannot be cleared, we need to provide that information
to avoid offering an action that has no effect.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
Weather conditions - at least as far as online services are
concerned - don't usually change in a couple of minutes.
So when updating shortly after a previous update, assume
the current conditions are still valid and trigger an
update without showing a loading indication. This should
help a bit with not getting stuck permanently in loading
state when on a shitty network.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
Similar to the Clocks integration we've had in the date+time drop-down for
a while, the designs have called for a similar section that integrates
GNOME weather as well. Use the WeatherClient added in the previous commit
to implement that section and add it to the popover.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
In preparation of integrating GNOME Weather, add a helper class that
retrieves weather information according to Weather's configuration
if the application is installed.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
In order to avoid distracting popup size changes while browsing
other dates, we freeze the size to the last size request. However
in case of more complex size negotiations - wrapping or ellipsizing
labels, scrollable elements etc. - there's a chance of stray calls
to get_preferred_width/height() that are not used for the actual
allocation. If such a call happens to be the last size request
before the layout is frozen, the saved size will be wrong. To fix
this, save the allocated size rather than the requested one.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
We want the width of the calendar column to be determined by the
calendar, other elements should adjust their allocation accordingly.
However neither ellipsization nor wrapping will kick in unless the
parent's width is restricted, so use a small custom layout manager
that enforces the desired behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
As the telepathy integration picks up existing channels on startup,
ChatNotifications are another case where the real time the message
was received may be before the time it is picked up by the shell.
While this is less of an annoyance than restored GNotifications, as
it generally only affects restarts from the run dialog, it's an
easy fix now ...
https://bugzilla.gnome.org/show_bug.cgi?id=775799
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
Since the last notification redesign, we've been showing the time a
notification was received in the calendar drop-down. However as the
time is in fact added by the NotificationSection, it is actually the
time a notification was added to the list. Usually that difference is
not significant, except when previously received notifications are
restored on startup.
In order to be able to address those cases, we need a time that is
associated with the notification itself, so add a datetime property
that defaults to the current time, but may be set from an optional
parameter as well.
https://bugzilla.gnome.org/show_bug.cgi?id=775799
When gnome-clocks is installed, there is currently a race between the
GSettings schema being added to the database and the world clocks
session trying to use it. The prize if we win that race is an abort
in GIO, so use the newly added AppSettingsMonitor skip the race
altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=766410
When integrating with optional components like Clocks, it is not safe
to access their GSettings right after the application became visible
to the AppSystem:
Installation is usually not atomic, so the .desktop file may appear
before the settings schema, in which case Gio will abort due to an
"invalid" schema ID.
To address this, add a small helper class that wraps the settings
access in a safe way.
https://bugzilla.gnome.org/show_bug.cgi?id=766410
The display configuration now exposes a setting to automatically
shift the display color at nighttime. As there are cases where
disabling the filtering temporarily is useful, it makes sense to
expose the feature in the system menu for quick access.
https://bugzilla.gnome.org/show_bug.cgi?id=741224
Update according to the latest mockups:
- don't use a border around the list as specified
by the latest HIG version
- use more generous spacing between controls
- allow extension descriptions to take up two lines
- drop GNOME branding from the window title
- make the app name consistent with the window title
https://bugzilla.gnome.org/show_bug.cgi?id=778672
While the extension prefs tool is not meant as the primary way for
users to configure extensions - that will be Tweak Tool - it still
doesn't hurt to expose the extension kill switch to easily turn
extensions back on after a session crash.
https://bugzilla.gnome.org/show_bug.cgi?id=778664
When gnome-shell fails to start on login, gnome-session tries to
re-launch it again with all extensions disabled. This is currently
implemented by clearing the list of enabled extensions, which means
the user needs to re-enable their extensions manually again.
To make this process less annoying, add a single 'kill-switch' setting
gnome-session can use without interfering with the user setting.
https://bugzilla.gnome.org/show_bug.cgi?id=778664
On systems that support both shutdown and suspend, the latter operation
is currently only accessible via pressing the Alt key. As using the
keyboard may be inconvenient or simply not possible (e.g. on touch),
allow switching between alternatives via long-press as well.
https://bugzilla.gnome.org/show_bug.cgi?id=721173
We currently assume that if a .desktop file has been renamed (that
is, it is in our rename list), the updated ID will be used. That
assumption was mostly sound when the list contained only GNOME apps
following the same release cycle as gnome-shell, but as applications
with less ties to the GNOME schedule adopt the reverse DNS notation,
it becomes more likely for apps to appear in the list before actually
being updated on the system. Handle this case by only renaming IDs
for which the replacement can be resolved to an existing application.
https://bugzilla.gnome.org/show_bug.cgi?id=745626
The permissions hash is initialized after consulting the permission
store, however the lookup is skipped for requests that cannot be
resolved to an application, resulting in an error when accessing
the uninitialized hash for saving. Just make sure that the property
is always initialized to avoid that error.
https://bugzilla.gnome.org/show_bug.cgi?id=778661
GJS implements a basic signal system that allows monkey-patching
JS objects with signal methods resembling the GObject ones. However
it's clearly not a good idea to replace the actual GObject methods,
so use the proper GObject facilities when inheriting from GObject.
https://bugzilla.gnome.org/show_bug.cgi?id=778660
Items were inserted correctly but the synchronisation was lost if the
name of a connection was changed. Simply making sure the position is
correct after a connection is updated fixes the issue.
Reported-by: Oliver Haessler <ohaessle@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778686
Mutter now provides versioned libraries and pkg-config files, meaning
an application using libmutter and friends need to depend on a specific
version of the API.
https://bugzilla.gnome.org/show_bug.cgi?id=777317
It's weird if after you select a username from the user list, there's
a password already filled in.
This commit disables at that feature for the login screen
(but keeps it in tact for the unlock screen)
https://bugzilla.gnome.org/show_bug.cgi?id=766139
This adds a security icon (either secure or insecure) to the portal
helper's title bar. As soon as a part or all of the page and its content
is served insecurely, the icon shown will be a broken padlock.
https://bugzilla.gnome.org/show_bug.cgi?id=749197
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
Per ES6, a variable declared const should only be valid inside its lexical
scope. Previously, GJS would accept this code, but that will change in the
SpiderMonkey JS engine in the next release of GJS.
https://bugzilla.gnome.org/show_bug.cgi?id=778425
Using a MetaWindowActor's shaped texture as the source for window
clones means that if there are further MetaSurfaceActor children
(e.g. a wayland client using sub-surfaces) they don't get cloned.
This obviously wasn't an issue until wayland clients introduced the
possibility of having multiple MetaSurfaceActors under a
MetaWindowActor but there's no fundamental reason we can't clone the
toplevel actor.
WorkspaceThumbnail.WindowClone is the one class that was already using
the MetaWindowActor instead of the texture although it seems to have
been an unintended change in commit
8b99617513.
https://bugzilla.gnome.org/show_bug.cgi?id=756715
We have no guarantees on the number of ::size-changed signals that we may
receive, so the _sizeChangedWindow handler may run multiple times, which
leads to multiple calls to meta_plugin_size_change_completed(). So double
check the actor is not already being animated in the _sizeChangedWindow
handler to avoid reentrancy.
https://bugzilla.gnome.org/show_bug.cgi?id=777784
The title of the window should not be in control of a potentially
hostile hotspot provider, so only set the subtitle to be that of the
page, the main title will stay the same.
The subtitle will also be set to a URI, so that the hotspot cannot be
used to control the title shown in our UI.
Helps https://bugzilla.gnome.org/show_bug.cgi?id=749197
Even though the window is maximised when created, the window is still
resizable. This avoids making the window smaller than usable. If the
screen is smaller than the minimum window size, the maximise should make
it fullscreen and non-resizable.
https://bugzilla.gnome.org/show_bug.cgi?id=735233
Ever since commit b8e29ae8c7
(I think), start up is littered with this message:
Gjs-WARNING **: JS ERROR: could not get remote objects for service
org.gnome.SettingsDaemon.Smartcard path
since gnome-shell is now started before gnome-settings-daemon.
This commit addresses the problem by making the object manager code
not try to autostart its proxy, and instead wait for it to appear.
https://bugzilla.gnome.org/show_bug.cgi?id=772589
If the call to settings.get_connection_by_path in
ensureActiveConnectionProps returns null, we'll hit a JS error here.
Seems to happen always when activating a VPN connection. Avoid that.
Giovanni says:
"I believe this is papering over an existing bug, but it's possible for
settings.get_connection_by_path() to legitimately return null (if the
connection is owned by a different user and invisible to the current
one), so the fix is correct anyway."
https://bugzilla.gnome.org/show_bug.cgi?id=759793
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.
If an onComplete handler is passed to animate(), it is set to run at
the end of the animation via the icon grid's ::animation-done signal.
Currently the signal is connected after starting the animation, with
the result that the handler doesn't run when the animation completes
immediately (because there are no icons to animate). Fix this by only
starting the animation after connecting the signal.
https://bugzilla.gnome.org/show_bug.cgi?id=774381
We currently assume that the current view matches the 'app-picker-view'
setting. While that is usually the case, there is one notable exception:
While there isn't sufficient usage data (yet), we show all applications
instead of an empty frequent view regardless of the setting. We should
animate the actually visible icons in that case, not the (non-existent)
ones from the hidden frequent view.
https://bugzilla.gnome.org/show_bug.cgi?id=774381
Users are currently experiencing intermittent (and hard to debug) TLS
errors when loading the portal authentication page. This could be
caused by using http://www.gnome.org/ for our connectivity checks
because it redirects to HTTPS.
We can completely remove TLS from the equation by not using HTTPS.
http://nmcheck.gnome.org/ is a good choice because it doesn't redirect
to HTTPS and was created for NetworkManager's connectivity check.
https://bugzilla.gnome.org/show_bug.cgi?id=769940
Wayland clients can request their surfaces to be fullscreened before
commiting a buffer which means that we need to handle fullscreen
requests for which the old size is 0x0, preferably without warnings.
Since the mapping animation also runs for these windows, we can simply
bail out and ignore the fullscreen size change.
https://bugzilla.gnome.org/show_bug.cgi?id=770345
Wayland clients are in control of their window size so the existing
mutter plugin API, which assumes size changes are synchronous, doesn't
work for them since when our size-change handler runs the MetaWindow's
size isn't final yet.
To fix this, the mutter plugin API was extended with a size-changed
vfunc that lets us know when the MetaWindow size has actually
changed. This way we can make the window snapshot and get the old
window size on the existing size-change handler and later, on the new
size-changed handler, get the new size and start the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=770345
Our animation code not only relies on the animation being loaded
(which we handle), but also on having at least one frame - otherwise
the computation of the next frame index will turn up NaN through
division by zero. Guard against this case by treating empty animations
as not loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=774805
The top bar's network menu only supports a subset of device types
supported by NetworkManager. While not having lesser used options
in the menu itself is perfectly reasonable, not showing any network
icon at all in the top bar when the system is fully connected is
weird.
https://bugzilla.gnome.org/show_bug.cgi?id=773890
Any network devices appear as top level items in the system status
menu, so on system with an unusually high number of devices, the
menu can end up exceeding the available screen height. While this
is a corner case, leaving important system actions unreachable is
bad. The system menu does not lend itself to scrolling, so handle
this case instead by summarizing sections ("n connections") where
the number of devices exceeds a threshold.
https://bugzilla.gnome.org/show_bug.cgi?id=773892
Currently the cache is built once when the first VPN request is
handled, so plugins that are installed or uninstalled after that
aren't picked up. Fix this by invalidating the cache on changes
to the plugin directory.
https://bugzilla.gnome.org/show_bug.cgi?id=773893
commit 1d58ea25ab changed the
popupMenu code to handle key presses on source actors directly.
This fixed keynav into the session gear menu at the login screen.
Unfortunately, it also causes spurious pop ups if a modifier happens
to be held down.
This commit checks for modifiers and short circuits the up front
key handling if any are found.
https://bugzilla.gnome.org/show_bug.cgi?id=740043
This is an implementation of the pad OSD that's been previously
present in gnome-settings-daemon. Since things are moving closer
to the compositor, it makes sense to have this implemented as shell
UI.
https://bugzilla.gnome.org/show_bug.cgi?id=771067
The lightboxes used for screen blanking are created during initialization
and shown each time the screen should blank. During the (potentially long)
time where the lightbox is hidden, any actor could be raised above the
lightbox - in particular any popup menu raises itself to the top when
opened. To not exclude those elements from screen blanking, raise the
lightbox every time it is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=773875
We currently reload animated backgrounds on timezone changes, but
there are other cases where the time can change unexpectedly and
the background no longer matches the time of day. One case we can
easily handle is when coming back from suspend, so do that.
https://bugzilla.gnome.org/show_bug.cgi?id=773265
Since commit 67615a0cbc, any printable key can be used to lift the
screen shield rather than just escape/enter/space. While this is
convenient for unlocking where the input is forwarded to the password
entry, it is potentially dangerous when the screen is inactive but
not locked: If the user types her password, the first character will
lift the shield and the remaining input will go to the focused window.
To prevent this from happening, only allow printable keys when the
screen is actually locked and restrict the key presses that lift the
shield to the original set of escape/enter/space otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=773328
It will only show up when a discrete GPU is available (detected through
the switcheroo-control D-Bus service), and the application hasn't
alreayd been launched.
Note that this will not currently work for D-Bus activated applications,
eg. the menu item will be available, but the environment variable will
not be passed through to D-Bus to use when launching the application.
https://bugzilla.gnome.org/show_bug.cgi?id=773117
And adapt existing callers to the new API. This will allow us to
implement a way to launch applications on the discrete GPU for systems
where an "Optimus" system exists.
https://bugzilla.gnome.org/show_bug.cgi?id=773117
Apparently importers for the 'same' path are shared, even when the
relative paths resolve to different absolute ones. Until this bug
is fixed properly, we can work around this by expressing the current
extension path as the UUID relative to the parent directory.
https://bugzilla.gnome.org/show_bug.cgi?id=772386
You can define a new importer object by importing a subdirectory in GJS.
This is undocumented, but it is likely to at least hold until the whole
thing moves to ES6 modules, after which we'll be able to do this purely
in JS with Reflect.Loader.
Since this was the only thing the ShellJS library did, we can remove it
altogether.
This allows us to discontinue use of the gjs-internals-1.0 embedder API.
https://bugzilla.gnome.org/show_bug.cgi?id=772386
When the user gets long failure messages from pam, the authPrompt
message label will clip the message and ellipsize with '…'.
This commit turns off ellipsization from the label, so it will
properly wrap.
https://bugzilla.gnome.org/show_bug.cgi?id=764445
If Bluetooth is on but there aren't connected devices, the status in the
menu reads "Not in Use". This is potentially confusing: it's a negative
statement, even though Bluetooth is on. It also sits uneasily (and looks
even more confusing) next to the submenu item "Turn Off".
Changing the string to "On" is better.
https://bugzilla.gnome.org/show_bug.cgi?id=756432
This allows us to pass metadata fields besides the message
to log. So, if the log() call is made from an extension,
pass the extension name and UUID to the logger.
This is useful for extension developers to debug their code
as well as to instruct their users to send debug info to them
by running something like this:
journalctl GNOME_SHELL_EXTENSION_UUID=<extension@uuid>
https://bugzilla.gnome.org/show_bug.cgi?id=770717
Currently it's assumed only an extension can call this method. However
it can be useful if any part of the shell want to know if it was invoked
by an extension.
https://bugzilla.gnome.org/show_bug.cgi?id=770717
NM upstream would like to reduce periodic scanning, and that means
that clients should request scans themselves while their WiFi list
is open. Similar to the Windows and macOS WiFi dialogs/lists.
https://bugzilla.gnome.org/show_bug.cgi?id=767918
We currently rely on the "monitors-changed" signal of LayoutManager to
relayout the OSD window. That is not enough, since the scale factor also
changes the way the OSD window is sized, and that can be updated after
"monitors-changed" has been received.
The visual effect is that under some circumstances, the OSD window will
have the wrong size under HiDpi.
This commit fixes the issue by triggering another relayout when the
scale factor changes.
https://bugzilla.gnome.org/show_bug.cgi?id=772723
Similar to bug 667552 for the app switcher, attached modal dialogs
can result in an unexpected window order in the window switcher:
Selecting a window with an attached dialog will focus the dialog
instead, but as the dialog itself is ignored in the window list,
its last-used timestamp is not taken into account for the position
in the MRU list. Fix this by fetching the list of all NORMAL windows
and filter out skip-taskbar windows ourselves, while making sure that
windows appear in the position of their attached modal dialog where
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=747153
We only connect to the corresponding property notifications after both
Client and RemoteSettings are ready, so we may miss the initial signal
emission. Make sure to pick up the connections in this case to fix the
network indicator not showing up.
https://bugzilla.gnome.org/show_bug.cgi?id=772249
Similar to windows on another workspace, selecting a minimized window
doesn't look quite right - the selected window disappears, then animates
back in. Fix this by adding support for skipping the next effect to the
wm and use it to bypass the unminimize animation.
https://bugzilla.gnome.org/show_bug.cgi?id=771536
Both 'cycle-group' and 'cycle-window' shortcuts allow cycling through
windows on all workspaces. While this works, it looks quite broken
since we started showing clones for highlighting: the selected window
vanishes (when its clone is destroyed), then slides back in with its
workspace. Instead, slide the selected window to its workspace like
we do for the 'move-to-workspace-*' shortcuts.
https://bugzilla.gnome.org/show_bug.cgi?id=771536
Commit 3171819c improved window cycling by using a dedicated to clone
for highlighting rather than activating all cycled windows. Original
window actors are hidden while its clone is showing, and shown again
afterwards, however the latter is wrong for actors that are not supposed
to be visible (for example where the window is minimized, or on a different
workspace). Fix this by properly syncing the actor's visibility instead
of showing it unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=771536
ScrolledWindow changed its allocation behavior, and the extension
list only takes up the minimum width rather than the available
width as intended. To get the previous behavior back, we need
to set the newly added :propagate-natural-width property ...
https://bugzilla.gnome.org/show_bug.cgi?id=771391
If the user clicks Not Listed? to enter ask for username mode, clicks
cancel, and then attempts to log in via the user list, the user will see
"Authentication failed" after correctly typing the password, and then
will become stuck in an empty screen with just the gray noise background.
The problem is, we forgot to disconnect from the signal that's waiting
for the next button to be pressed on the username entry screen. Since
the signal handler that executes here is expecting the username to be
input, and isn't prepared for us to have switched back to user list,
various bad things happen. We try to start two gdm-password
conversations at once, for instance, one using the user's password as
the username. I stopped investigating here, because it's easy to fix by
disconnecting from the signal at the right time.
https://bugzilla.gnome.org/show_bug.cgi?id=770328
Since commit 82950ecea, we acknowledge pending messages when closing a
chat notification for a channel we are handling to prevent the channel
from popping up again immediately. While this isn't an issue for channels
we don't handle, the unread messages of the destroyed notification are
still considered for the messages indicator in the top bar, which is
clearly confusing (in particular when we end up showing the indicator
without any notifications in the list). As it's arguably correct to not
meddle with a channel handled by someone else, just reset the cache of
pending messages to address this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=770888
Mutter's plugin destroy event doesn't happen if a window is hidden
when it gets unmanaged so we also need to handle the
MetaWindow::unmanaged signal to check whether the parent should
dimmed.
https://bugzilla.gnome.org/show_bug.cgi?id=752524
meta_window_foreach_transient() iterates through all transients of a
window, not only direct transients. This means that simply checking if
a transient is an attached dialog isn't enough because it might be a
non-direct transient for the window we're checking, in which case we
don't want to dim the window.
In particular this fixes windows not getting undimmed when they have
more that one level of transient children and the direct transient gets
destroyed. In that case we would still find at least one non-direct
transient child and decide to keep the window dimmed.
https://bugzilla.gnome.org/show_bug.cgi?id=770163
Commit bd6e7f14d1 reimplemented the cycle keybindings to
fix cycling between more than two windows, but the approach
of highlighting cycled windows by actually focusing them has
the drawback that cycling messes up the MRU order of windows.
To fix this, only change the window focus when the operation
finishes, and use a dedicated actor that draws a border around
a window clone for highlighting.
https://bugzilla.gnome.org/show_bug.cgi?id=771063
There's no particular reason for this actor to be reactive and thus
preventing input events to reach actors underneath, e.g. quickly
clicking on something while the popup isn't yet finished animating
out.
https://bugzilla.gnome.org/show_bug.cgi?id=770382
Have it notify properly of changes to the current input source, as
well as exposing those in get_groups().
The support for virtual keyboard events has been replaced by
ClutterVirtualInputDevice, which can be thought of as the equivalent
to the XTEST devices in X11.
https://bugzilla.gnome.org/show_bug.cgi?id=765009
If a sandboxed app requests access to some system resource (camera,
microphone, location), the portal frontend needs to ask the user
for permission. In GNOME, we want this to be a system modal dialog,
so provide an org.freedesktop.impl.portal.access implementation
that exposes a generic system modal permission dialog on the bus.
https://bugzilla.gnome.org/show_bug.cgi?id=768669
We currently use the :active pseudo class to mark the selected day
in the calendar. Whenever the selected date changes, the class is
added to the corresponding button and removed from all others.
However when the selected date doesn't change (i.e. when clicking
the already selected date), the buttons are not updated and the
use of the :active class conflicts with StButton's builtin handling
of the class - the class is removed on the button up event and the
button is deselected.
Fix this by simply using a different pseudo class.
https://bugzilla.gnome.org/show_bug.cgi?id=746867
The last patch fixed marking days in the calendar where all
events are ignored, but it doesn't pick up the change when
an event is hidden. Emit an appropriate change notification
to fix this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=768538
Ignoring events is currently implemented in the message list's
event section, which means that the calendar does not consider
ignored events when marking days with events. In order to fix
this, move the handling of ignored events to the event source,
which is shared between both components.
https://bugzilla.gnome.org/show_bug.cgi?id=768538
Commit 9b07ce1d0d broke the code that keeps the OSD window square.
Use that opportunity to move away from the hack of setting the
min-height style property from code and adjusting the width on
allocate, and implement a proper constraint instead.
https://bugzilla.gnome.org/show_bug.cgi?id=768317
ClutterActor:width is a floating point property, so it will not be
automatically rounded to non-fractional values that properly align
to pixels. To fix the resulting blurriness, add explicit rounding.
https://bugzilla.gnome.org/show_bug.cgi?id=768317
Commit 9b07ce1d0d changed the OSD window's level bar to be a regular
actor instead of a custom drawn bar. The bar actor's width depends on
both the configured level (e.g. 40%) and the available width, however
the width is currently only updated when the configured level changes.
Fix that by properly considering changes to the parent's width as well.
https://bugzilla.gnome.org/show_bug.cgi?id=768317
Commit c39ffa111 moved the signal handling from the controls- to the
background-group to enable scrolling on non-primary monitors.
However this broke scrolling on reactive overview elements as the
workspace switcher, as they're not descendants of the background.
To fix, move scroll-event handling to the overview group itself,
which is the common ancestor of all overview elements.
https://bugzilla.gnome.org/show_bug.cgi?id=768316
When we restart, we need to update the struts for the screen before
we enter the main loop, or maximized windows will get resized to the
size of the screen without struts, then resized back.
A workaround is needed for a Clutter bug that occurs when we get
the size of an actor before the first paint of the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=761566
The memory which MetaBackground resides is freed automatically, when its
wrapper object Background is freed by garbage collection. But because the
memory for MetaBackground is huge, changing the background or changing the
background mode repeatedly makes a lot of memory to be in use until garbage
collection runs.
This patch frees the MetaBackground object explicitly when its
MetaBackgroundActor is destroyed which is the moment that the memory in the
object is not used anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=766353
Signed-off-by: Hyungwon Hwang <hyungwon.hwang7@gmail.com>
This isn't a performance critical actor and the NVIDIA driver discards
offscreen buffers in some cases which would require us to go through
extra hoops to handle here which isn't worth it.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
It is odd to switch workspaces on the primary monitor when panning on
a monitor without workspaces, so reject the gesture on non-primary
monitors when workspaces-only-on-primary is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
It is odd to switch workspaces using the scroll wheel when the pointer
is on a monitor without workspaces, so only handle scroll events on
non-primary monitors when workspaces-only-on-primary is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
We allow activating a workspace by clicking it when we know that
the user did not try to select a window and missed (namely: the
workspace is empty). However we currently always check for an
empty workspace on the primary monitor, which doesn't make sense
when the click happened on a different monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
Both the Overview::scroll-event and actions added via addAction()
are meant to work anywhere in the overview, but for now only work
on the primary monitor. Move the handling to the background group
that is known to span all outputs to fix.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
The stack was used to overlay a message indicator over the overview
group. That indicator is long gone, so there's no longer a need for
an intermediate actor in the hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
Initializing the upper bound to zero means that on panning we'd start
scrolling from the first workspace even if the current workspace when
entering the overview was different since StAdjustment clamps the
value to be inside bounds.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
The underlying logind API does not only indicate whether suspend is
available, but also whether the user is eligible for executing the
operation without further authentication. This information can be
relevant, so pass it to the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=725960
If the source actor is destroyed while the popupMenu is shown -- this
can happen if a non favorite application was closing or crashes -- the
menu actor is improperly destroyed.
This makes the popupMenu close first and does a clean ungrab instead.
https://bugzilla.gnome.org/show_bug.cgi?id=757556
The various switcher keybindings are handled identically, except for
the popup that is shown; update the code to reflect that instead of
duplicating the code again and again.
https://bugzilla.gnome.org/show_bug.cgi?id=730739
The code to handle cycling through windows without showing a popup
was removed from mutter a while ago, which left the corresponding
keybindings mostly broken (i.e. they now only switch between two
windows). With the various switch-foo keybindings handled by the
shell, it is now easier to take over the cycle-foo keybindings as
well.
https://bugzilla.gnome.org/show_bug.cgi?id=730739
Logind recently got support for a hint property in Session Object to
inform if session is Locked or not. It is up to desktop environments
to keep this property up to date.
https://bugzilla.gnome.org/show_bug.cgi?id=764773
If the drag actor is destroyed before the animation
callback is called, the callback is never called and
we're sticked with dnd grabing the events after we
dropped the target.
https://bugzilla.gnome.org/show_bug.cgi?id=757676
We currently show the orientation lock button when an accelerometer
is present, however gnome-settings-daemon's xrandr plugin only applies
rotation when a builtin monitor is present. Update the button's
visibility to match gnome-settings-daemon.
https://bugzilla.gnome.org/show_bug.cgi?id=765267
ClutterLayoutManager's size request methods have an additional container
argument before the for-width/height parameters compared to ClutterActor.
https://bugzilla.gnome.org/show_bug.cgi?id=763068
While a channel has pending messages, it will pop up again when
dismissed. That is clearly not what users expect, so clear them
out first before closing a channel.
https://bugzilla.gnome.org/show_bug.cgi?id=747991
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
The Next and Sign In buttons are disabled when the username/password
field is empty. However, the user can still bypass this button by
pressing the enter key, leading to some odd glitches with the log in
for 'Not Listed?' users.
This is easy to fix by simply not progressing to the next screen when
the button is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=746180
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
Generally a user-changed operation will be uninteresting, but if the
user is currently in the user list and the account changes to locked, we
want to remove it from the list, or if the user is not in the list and
the account changed to unlocked, we want to add it to the list. This
fixes the case where a new user account created in gnome-control-center
does not appear in the user list. The password mode is set in the new
account immediately after it is created, but the operations are not
atomic, so the login dialog considers the new user account when it is
still locked and rejects it from being displayed, then immediately
afterwards the account is unlocked. This commit causes the login dialog
to show the account when this occurs.
The containsUser() check here is not strictly necessary, but reduces
spurious calls to addUser() and removeUser(), since there's no easy way
to check if the locked status of the account has changed (as it's much
easier to connect to one signal on the UserManager than to
notify::locked on each User object).
https://bugzilla.gnome.org/show_bug.cgi?id=758568
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
LoginDialog has a private _user, but UserListItem has a public user.
Easy to get wrong since _user would be the right thing to type in 90% of
this file.
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
We currently will always allocate the user list's preferred size, so it
will grow indefinitely and never scroll; limit the height instead to
get the desired scrolling behavior when necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=754525
When the user successfully types their password, we should hide
the spinner from the button well right away, so it doesn't
consume resources until reset (which may happen significantly later
if the user is vt switched away)
https://bugzilla.gnome.org/show_bug.cgi?id=753891
The code previously tried to stop spinner after it was hidden, but
due to an incorrect check was only stoppig it after it was shown.
Also, it was only stopping after hiding due to an animation, and
failing to stop it in the non-animated case.
This left the spinner hidden and running while VT switched away
from the login screen, only stopping when the auth prompt was
reset when switching back.
https://bugzilla.gnome.org/show_bug.cgi?id=753891
* 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
We only need the user verifier for the purpose of user verification.
Once it's complete we should clear it so it doesn't get in the way
later.
This fixes a bug introduced in commit 3c8c5a5570 that leads to the
user session crashing when the login screen is reactivated.
https://bugzilla.gnome.org/show_bug.cgi?id=753181
We fade out the authentication prompt when a user successfully
logs into a user session. We reset it and fade it back in when
the user switches back to the login screen VT.
The problem is, we only fade it back in if the auth prompt status is
VERIFICATION_SUCCEEDED. It's possible for it to be NOT_VERIFYING
if the authprompt gets reset for some other reason in the interim.
This commit changes the check to be more precise. We now only skip
the fade-in, if we're already faded in, and we only skip the reset if
we're already reset.
https://bugzilla.gnome.org/show_bug.cgi?id=753181
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
The user should be allowed to cancel if verification hasn't
started yet and they're typing in their username. This
commit changes the authPrompt cancel function to not
ignore such requests.
https://bugzilla.gnome.org/show_bug.cgi?id=752739
Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
This commit addresses that bug.
https://bugzilla.gnome.org/show_bug.cgi?id=752739
If the next button ever gets set to Sign In, it won't
get reset to next until the next question asked by pam.
This commit ensures it gets reset to Next when asking
for the username.
https://bugzilla.gnome.org/show_bug.cgi?id=752739
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
We currently only cancel the user verifier on reset if
verifying, but that means we don't properly cancel it when
asking for a username at the Not Listed screen.
The object already handles getting called when there is
nothing to cancel, so just cancel it unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=752438
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
According to systemd logind's documentation, the CanSuspend() method
"returns 'na' in case "the operation is not available because hardware,
kernel or drivers do not support it", while "'no' is returned if the
operation is available but the user is not allowed to execute it".
See http://www.freedesktop.org/wiki/Software/systemd/logind
Thus, we need to return true here when the reply for the CanSuspend
method is neither 'no' nor 'na', or we would providing false positives
in cases where suspension is simply unsupported.
https://bugzilla.gnome.org/show_bug.cgi?id=748338
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
It's possible for a user to type their password so quickly
that GDM hasn't even had time to ask for the password yet,
much less have time to process the answer.
In that situation, we tuck the user response away as
_preemptiveAnswer, and pass it along to GDM when GDM is finally
ready for it.
The problem is, there's a bug in the code, where we send
null for the service name in the answer, instead of the right
service name (say "gdm-password").
This commit addresses the bug by making sure we don't pass the
answer along, until the service name is properly set in
_queryingService. To ensure that, answering query (answerQuery)
based on _preemptiveAnswer has been shifted right below
this._queryingService = serviceName;
https://bugzilla.gnome.org/show_bug.cgi?id=737586
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
If the login screen actors aren't placed at pixel
boundaries then they will show up blurred with fuzzy
text.
This commit ensures all actor allocations are floored
to integer coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=746912
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
