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
