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
Pause dynamic workspace management while workspaceSwitcherPopup
is shown so as to eliminate infinite creation and destruction of
workspaces, thus preventing stuttering while trying to move a
window to last workspace.
Add _isWorkspacePrepended flag to make sure only a single workspace
is prepended at a time thus preventing the possibility of prepending
infinite workspaces while dynamic workspace management is on pause.
Prepend a new workspace by creating a new workspace instead of only
shifting the windows to next workspace so that the workspaceSwitcherPopup
may appear in sync with what's happening behind the scene and display
correct number of workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=712778
User read time per character has been changed from 16ms to 48ms because the
message of information about last login is displayed for half a sec that is not
a good user experience. So time to read a character is increased to 48ms from 16ms.
https://bugzilla.gnome.org/show_bug.cgi?id=720885
To switch workspace by keyboard in the overview, the user currently
has to use the normal keybinding. However as the vertical alignment
of workspaces makes them very similar to pages in the app picker, it
makes sense to also support the standard pageUp/pageDown keys.
https://bugzilla.gnome.org/show_bug.cgi?id=742581
"Moving" a window to another workspace doesn't make sense when it cannot
be unstuck, and is potentially confusing if a new workspace is added at
the start/end - just don't do anything in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=746782
NVIDIA drivers don't preserve FBO contents across suspend / resume
cycles which results in broken backgrounds. We can work around that by
forcing a refresh when coming out of suspend.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
Currently the menu position below the button means that the menu
can extend to roughly half the screen height before ending up partly
off-screen. This is plenty of space for commonly installed sessions,
but some users have a significantly higher number of sessions in the
list. Move the menu to the side of the button in that case to maximize
the vertical space the menu may take up.
https://bugzilla.gnome.org/show_bug.cgi?id=734352
There is currently no way to trigger an icon's right-click menu by
keyboard. While there's a good chance that the icon will ignore
<shift>F10 and similar shortcuts, passing on key events will at
least make it work for some icons ...
https://bugzilla.gnome.org/show_bug.cgi?id=746487
While legacy status icons lack a proper accessible name of their own,
we can try to find the corresponding application or the icon's window
title - hopefully most status icons provide at least one, so they
don't show up completely "blank" in screen readers.
https://bugzilla.gnome.org/show_bug.cgi?id=746487
g-s-d has been taking care of this for us but in a very hackish way
that causes dconf writes on every startup and also doesn't handle
dynamic updates to locale1's properties which has become a problem now
that GDM keeps its greeter session running in parallel with users'.
To take care of this properly, this commit introduces a settings
abstraction with both system and session implementations. The session
implementation just wraps access to the existing gsettings while the
system one gets its values from org.freedesktop.locale1's properties.
https://bugzilla.gnome.org/show_bug.cgi?id=746288
There's some vestigial code for hiding the user list
that runs at the same time its parent is hidden.
Only the parent should be hidden, at this point, so
there's situations where the user list hides and
never comes back.
This commit fixes that, by deleting the vestigial code.
https://bugzilla.gnome.org/show_bug.cgi?id=719418
Since commit 75745fc23f, the bodyStack itself is no longer start-aligned
to not break custom body actors like chat notifications. However we still
want "normal" body actors start-aligned to get the correct RTL behavior.
We now stopped using notification actors directly for anything, so
we can simplify the Notification class significantly by turning it
into a purely informational object others can use to built their UI
representation from.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
Since we stopped special-casing chat notifications to use the old
notification actor, we need to provide a notification banner to
maintain the inline chat functionality, so split out the UI from
the existing ChatNotification class.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
Special-casing banners of resident notifications was really a
thinly veiled special case for chat notifications, as those were
still using the old notification actor which coupled the life-time
of the notification to its actor. This is no longer the case, so
we can do the sane thing and destroy banners once they are no
longer needed.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
Passing null as body always meant clearing the existing one. While this
mattered less with the old message tray which used the expanded actor,
the new message list in the calendar uses the unexpanded body. We clearly
don't want that to disappear on icon changes, so pass the existing one.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
