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.
