Commit 28ca96064b added support for setting PopupImageMenuItem's icons
via GIcons as well as via strings. However as the check whether an object
implements the GIcon interface only works on GObjects, specifying an icon
name was broken. Fix that to actually allow both strings and GIcons.
https://bugzilla.gnome.org/show_bug.cgi?id=789018
The idea behind always showing the icon on the login screen is that
the users' needs aren't known at that point. However we can achieve
the same behavior by including the 'always-show-universal-access-status'
key in GDM's presets, so drop the special-case.
https://bugzilla.gnome.org/show_bug.cgi?id=788943
We were handling being initially headless by only setting the primary
and bottom monitor if there was any primary monitor, then checking the
primary monitor reference before making calls assuming there was any
monitors.
What we didn't do was unset the primary and bottom monitor when going
headless, meaning that temporarly disconnecting a monitor while having
windows open caused an assert to be triggered due to various code paths
taking the path assuming there are valid monitors.
Unsetting both the primary and bottom monitor when going headless avoids
the code paths in the same way as they were avoided when starting
headless.
https://bugzilla.gnome.org/show_bug.cgi?id=788607
We are already closing top bar menus on session mode changes, but
as this behavior makes sense for any other menus as well - dash
context menus or the background menu for instance - just generalize
the behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=787676
Commit 1c7a3ee61b broke setting the initial key focus for default
buttons added via addButton(). Fix this by allowing the dialog class
to provide a different default widget to ModalDialog than the entire
dialog itself.
https://bugzilla.gnome.org/show_bug.cgi?id=788282
We don't use different hover- and focus indications for window previews,
so using keyboard navigation after hovering a clone often has surprising
results when the previous focus window wasn't the selected one. Address
this by simply moving the keyboard focus with the highlight.
https://bugzilla.gnome.org/show_bug.cgi?id=786546
By default the focus chain uses the same order as the list returned
by clutter_actor_get_children(), which corresponds to the z-order.
This doesn't work well in the window picker, where clones follow
the stacking of windows to ensure a correct overview transition,
but previews are laid out purely based on space efficiency. As
a result, the order in which window previews are navigated when
tabbing around is essentially random. Fix this by providing a
focus chain implementation that is based on the visual layout
of the previews rather than the stacking.
https://bugzilla.gnome.org/show_bug.cgi?id=786546
Don't assume there will always be a primary (logical) monitor, or any
(logical) monitor at all. This includes not allocating / layouting /
styling correctly when being headless.
The initial background loading will also be delayed until there are any
(logical) monitors connected.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
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
In case where a method- and property name overlap, using the method
is less unambiguous than I thought - mozjs52-based gjs will only see
the method, while mozjs38-based gjs will only see the property. We
are in luck though, and the real property name contains dashes that
allow us to refer to the property in a way that works for all gjs
versions.
https://bugzilla.gnome.org/show_bug.cgi?id=785090
ClutterActor has both a has_pointer() method and a :has-pointer
property (that we represent as 'has_pointer'). So far gjs was
able to deal with the name overlap, but now trying to use the
property will instead test for the availability of the method.
Just avoid the conflict by switching to the method, which is
unambiguous.
https://bugzilla.gnome.org/show_bug.cgi?id=785090
We now cancel animations on override, however we also want to cancel
animations altogether on unmap (that is, when hiding the overview)
to avoid icons swarming into the void.
https://bugzilla.gnome.org/show_bug.cgi?id=736148
Until now we were waiting the animation to complete to allow the user to
make a new animation. This could bring some problems and annoy nervous
users.
Instead of that, destroy clones on new animations triggers and
create a new animation with the new direction.
https://bugzilla.gnome.org/show_bug.cgi?id=736148
The animation needs the icons' final positions, so we currently defer
it to a ::notify::allocation handler; however as starting the animation
during an allocation cycle would trigger a Clutter warning, it is
further deferred to a MetaLater. While this usually works, it is possible
that the allocation is already valid when we connect the signal, in which
case the animation is triggered at a later unexpected time. Switch to
a more robust ::paint handler instead, which also allows us to get rid
of the double-delay.
https://bugzilla.gnome.org/show_bug.cgi?id=736148
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
Symbols that are defined with 'let' are no longer visible outside
the module that defines them. To unbreak the code base, define all
non-private properties as global.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
The first time that the session is started, it can happen that the
AT SPI hasn't been correctly initialized, and this results in a crash
when attempting to register the caret or focus listeners.
In order to avoid this, these changes check the result of initializing
the AT SPI, to allow further attempts when it has failed.
https://bugzilla.gnome.org/show_bug.cgi?id=785047
Customization of keycombo actions for strips/rings was lost in the
porting to new incarnation of Wacom support.
The UI here is slightly different, instead of requiring the user to
rotate/swipe in each direction to map each keycombo, the UI will
navigate the user through edition of both options, first one, then
the other.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
Commit 39a840e2c3 added an additional parameter to shell_app_launch().
When adjusting callers, the parameter was also added accidentally to
calls of the confusingly similar g_app_info_launch() ...
Remove those to fix some warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
The method currently catches errors that occur when calling the
extension's init() method, but throws itself an error if the
expected extension.js file is missing. The former is pointless
if we expect all callers to handle errors themselves anyway, and
we should avoid the latter if we don't - opt for the second option
and handle a missing extension.js file gracefully.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
While we catch errors that occur when calling init(), enable() or
disable(), the import itself can throw an exception, for instance
if the extension imports an unavailable typelib or tries to draw
in a conflicting library.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
Both reloadExtensions() and enableExtensions() are already expected
to catch extension errors. If they don't, this is the bug that
should be fixed instead of catching unhandled exceptions in the
caller.
This reverts commit ff425d1db7.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
Those will go away when we port authentication prompts to the new
MessageDialogContent widget, so pick the style classes from there
and adjust individual properties with more specific rules to re-
produce the existing style.
https://bugzilla.gnome.org/show_bug.cgi?id=784985
A lot of our modal dialogs share a similar structure:
[Icon] Some title
Maybe a subtitle
And sometimes even a body for stuff like
longer descriptions.
A dedicated widget with a common style will allow us to significantly
reduce duplication of both code and CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=784985
This is the basic dialog actor implementation, which will allow us to
use the same implementation on the session-global modal dialogs. The
ModalDialog class now uses it underneath, and so do all users of it.
https://bugzilla.gnome.org/show_bug.cgi?id=762083
let trackChrome accept actors that are not children of chrome actors.
this will be useful for the MetaCloseDialog in gnome-shell, which
is already included in the MetaWindowGroup, but needs to be tracked
as chrome for the dialog to receive pointer events on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=762083
The actor allocation will be invalid on CLUTTER_TOUCH_BEGIN, because
it comes together with a CLUTTER_ENTER event that will recalculate
styles, and queue a relayout in result.
The net result is that on CLUTTER_TOUCH_BEGIN, the relayout has been
already queued, so the slider width comes up as 0, and the value ends
up as 1. Later touch events already happen on a validated actor, so
it is corrected. Still, not fun when modifying the volume slider on a
touchscreen.
Having descriptions with multiple lines will clutter
the view and make it more confusing for the user. Apart
from that, it also makes the search result a lot bigger,
potentially losing general vertical alignment.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
The classes extending the SearchResult can now connect
to the 'terms-changed' signal emitted by the SearchResult
class. This signal enables each object to update its
internal description in order to apply the bold style
onto strings that match the search terms.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
In order to prepare for applying the bold style to the part
of the description that matches the search terms, we need
to listen for the signal that announces the fact that the
search terms have changed. Given the fact that the
SearchResults class is aware of the changes regarding the
search terms, the classes that extent SearchResult need
to have a reference to it in order to listen for the
to-be-implemented 'terms-changed' signal.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
Since results are now much more concise and take up less
space, we can use the 'saved' space to provide the user
with more search results for each provider.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
The current separator uses a gradient effect as a separator
between search results. As the mockups suggest, the gradient
separator is no longer needed, in favor of a more simple one,
which is a thin semitransparent line.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
In order to match the current mockups, the providerIcon
class needed to include both the name of the provider
and the label that informs the user about how many more
search results are available for that specific provider.
The latter replaces the plus sign icon that has been
used so far.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
In order to make gnome-shell search functionality fit on
smaller screens, like those of devices, search results
need to take advantage of more horizontal space so that
any extra space can be used efficiently.
In order to do so, change the layout of the ListSearchResult
class from a vertical one, to a horizontal one and also
decrease the padding of the list-search-result-content css
class.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
If the padOsd is given a nonexistent ring/strip, things would fail
badly later when trying to paint a 0x0 StLabel. Just avoid creating
more ring/strip labels than those known by libwacom.
This is unlikely to happen, but seems better to protect against it.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
