On the screen shield, the only possible interaction is lifting the
shield. The on-screen-keyboard is not useful for that, and the drag
gesture from the bottom may in fact conflict with dragging up the
shield, so disable it.
https://bugzilla.gnome.org/show_bug.cgi?id=788339
As notification icons now align with the title, it makes sense for
them to follow the text size in case a text-scaling-factor other
than 1 is applied.
https://bugzilla.gnome.org/show_bug.cgi?id=788265
Not doing this will throw a backtrace when running on headless mode and
trying to show a notification, due to Main.layoutManager.primaryMonitor
being undefined, so it's better to return early.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
When making any D-Bus call through the GDBus' proxy wrapper with an
invalid D-Bus object path, gnome-shell hangs.
Supposedly FdoApplicationProxy constructor should validate the passed
D-Bus object path and throw an error if the path is invalid. Since it
does not do that, we work it around by making sure that the deduced
D-Bus object path is valid or throw an exception if the path is not.
https://bugzilla.gnome.org/show_bug.cgi?id=787902
Some application IDs contain hyphens, which are not allowed in D-Bus object
paths, so we need to update the translation by converting them to something
that's a valid object path. This is consistent with what GApplication does.
https://bugzilla.gnome.org/show_bug.cgi?id=787902
Commit 289f982949 broke all remote providers when adding support for
non-auto-started search providers: Whether the provider should be
auto-started needs to be known in the constructor, so setting the
property on the constructed object doesn't work.
https://bugzilla.gnome.org/show_bug.cgi?id=787986
Ensure that key-above-tab for selecting window application is consistent
with the down key.
After focus an application in the switcher:
- if you press down, the window thumbnails are previewed, and first element
is selected
- if you press key-above-tab, the window thumbnails are previewed, however
the second element is directly selected.
Make both interactions always select the first element.
https://bugzilla.gnome.org/show_bug.cgi?id=786009
This would be used by search providers which only operate on data in the
running instance, such as the terminal's search provider which finds the
shell in the tab matching the search text.
https://bugzilla.gnome.org/show_bug.cgi?id=785380
Using a unicode character here means it may look quite different
from the intended style (for instance with emoji fonts). Avoid
this by providing a custom icon and use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=766368
It's not exactly clear what changed - gobject-introspection, gjs - but
the newly added gweather_condition_to_string_full() API no longer works
like it used to. The replacement code does look more idiomatic anyway,
so just fix the code without investigating the reason of the breakage.
https://bugzilla.gnome.org/show_bug.cgi?id=787423
If a source actor is set, use that for determining the arrow side (i.e.
whether the BoxPointer widget should expand in a certain direction).
This is better because it ensures that the popup is displayed on the
same monitor as the widget it originates from.
Without this, entering text with a vertically aligned input method
close to the bottom of a monitor would expand the BoxPointer downwards
on the monitor beneath it, instead of upwards, which is what one would
expect.
https://bugzilla.gnome.org/show_bug.cgi?id=786886
Now that full-sized window previews are allowed again it makes sense to
align the window previews with the pixel grid to prevent unscaled
windows from looking blurry in the overview.
In anticipation of showing the system actions in
the search results, it is fit to move action
specific code to its own module in order to
reuse it.
https://bugzilla.gnome.org/show_bug.cgi?id=691900
The current behavior wasn't designed, but was introduced in commit
84efaac52b to work around technical limitations when we were still
using external tools like gnome-screensaver or gnome-session-quit
to handle the actions. Those limitations are long gone, so it makes
sense to make the actions consistent with the corresponding keyboard
shortcuts: Leave the overview when launching an application, and leave
it alone otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=691900
Users already have to trust their OS, so asking whether an OS component
should be allowed to perform an OS operation is odd at best, if not
confusing. Account for this by allowing system components that require a
keyboard grab to work - namely Setting's keyboard shortcuts panel - to
do so without triggering the permissions dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=786146
This drops the requirement that SwitcherPopups need a modifier based
keybinding to work.
The existing behavior for modifier based keybindings is kept but if
the popup is triggered from a no modifiers keybinding, instead of
finishing when the modifier is released, we use a timer that
automatically finishes the popup. The timer is reset on every key
release to allow navigation to happen.
https://bugzilla.gnome.org/show_bug.cgi?id=783550
GWeather now provides us with API to request strings that don't
use sentence capitalization, so we can use it for summaries that
don't start a sentence to make for more natural phrases.
https://bugzilla.gnome.org/show_bug.cgi?id=779873
As in commit b2b2f65 and furthermore it doesn't make much sense to
change the menu item according to the number of connections since all
connections here are of the same type.
https://bugzilla.gnome.org/show_bug.cgi?id=786520
The new control-center shell split wifi configuration from the network
panel, and moved all other devices into a flat list. So instead of
manually spawning the app with the 'show-device' subcommand, we can
now simply launch the appropriate settings panel.
https://bugzilla.gnome.org/show_bug.cgi?id=786520
To make search more efficient, users don't need to move the actual
keyboard focus away from the search entry to activate the first
result. However the shift+f10 shortcut to pop up the context menu
via keyboard still acts on the actually focused widget, which is
the entry. It makes more sense to open the context menu of the
selected result instead, as that's what's highlighted and responds
to keyboard activation.
https://bugzilla.gnome.org/show_bug.cgi?id=675315
Otherwise the smaller icons will try to take too much space since the
texture rendering the icons will be scaled up on HiDPI displays according
to the scale factor, which will push the size of the StBin containing the
texture up, causing them to completely fill the folder's total space.
Explicitly setting the size of the StBin container in this case, in a
similar fashion to what we do when creating the empty placeholders (in
case where there are less than 4 apps in a folder), ensures that each
"cell" of the grid-like widget representing the folder does not take
too much space.
https://bugzilla.gnome.org/show_bug.cgi?id=786145
We need to consider the scaling factor in effect when updating the user's
avatar, and also make sure to update it as well whenever the scaling
factor changes.
https://bugzilla.gnome.org/show_bug.cgi?id=786120
The legacy tray introduced as part of the notification redesign in
3.16 was meant as a stop-gap solution to encourage applications to
move away from the concept of status icons, but it hasn't really
done anything except of getting in the way. Given that the large
majority of apps that still make use of status icons work perfectly
fine without them, we decided that it is time to drop this unloved
bit of UI altogether. Users who still want them (or use one of the
odd cases where an app really depends on the icon) can install one of
various extensions that are available, either based on the XEmbed
support that is still kept around or implementing the DBus-based
StatusNotifier spec.
https://bugzilla.gnome.org/show_bug.cgi?id=785956
Currently the chrome layer decides itself which events on the window
clone should show or hide the chrome, which makes it harder to extent.
Instead, move the decision to the window clone by letting it emit
show/hide-chrome events when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
Previews are currently limited to at most 70% of the actual window
size. This was done to indicate more clearly that the overview is
active and the window cannot be interacted with. However since then
other indications like the vignette effect have been added, so
artificially limiting the preview size doesn't look necessary anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
Now that only one window title is visible at any time, it no longer
matters if a title extends into other window previews, so we can
always show the full title.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
While the new title position gives the previews more space, they now
overlay the content which may hide valuable information. Address this
by only revealing the title as additional information on hover, like
we do for other auxiliary elements.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
We consider the window previews the primary way to identify a window,
so it makes sense to give them as much space as possible. So in order
to not have title captions take up too much vertical space, overlay
them on top of the preview borders.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
We currently expand the workspace switcher when workspaces are being
used, that is when there are any windows on a non-active workspace.
While this helps with the switcher's discoverability, it does eat into
the space available for window previews. By now the component should
be well established, so we can afford opting for space efficiency and
only expand the switcher while the user actually interacts with it.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
The overview's window picker is primarily about windows, and as the
previews that represent them are more effective the bigger they are,
it makes sense to scale down competing elements; start by reducing
the size of workspace thumbnails on the right ...
https://bugzilla.gnome.org/show_bug.cgi?id=783953
Instead of potentially loading a background mid-way when it changes, and
loading it again for every file monitor event, leverage
CHANGES_DONE_HINT events, which allow us to ignore CREATED and CHANGED
signals from the file monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=747794
About every other situation can do with synchronizing keyboard visibility,
and keyboard layout changes are already handled internally in the Keyboard
object.
A downside of this approach is that once created, there will always be a
Keyboard instance and its full actor hierarchy. Seems reasonable to do that
since we can't tell it won't ever be needed.
https://bugzilla.gnome.org/show_bug.cgi?id=785309
