When adding a favorite, we add the ID to the list of favorites, save the
setting and add the new app to the favorites map. However as writing the
settings value already results in reload() to update the favorites map,
the new app is usually already in the map when we add it.
The only exception is when the ID was found in the RENAMED_DESKTOP_IDS map,
in which case we end up adding both the renamed app and the original one.
Fix this by simply relying on reload() to properly update the map, just like
we already do in _removeFavorite().
https://gitlab.gnome.org/GNOME/gnome-shell/issues/471
On X11, reactive chrome must be added to the input region in order
to work as expected. However that region works independently from
any window stacking, with the result that the unresponsive-app dialog
currently blocks all input in the "covered" area, even in windows
stacked above the unresponsive window.
The correct fix would be to track the unobscured parts of the dialog
and set the input region from that, but that's quite cumbersome. So
instead, only track chrome when the corresponding window is focused
(or the dialog itself of course).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/273
As a mount operation's UI may be reused (for example after mistyping
the password), we only close the operation once the mount has finished
(successfully or with error).
We therefore need to track ongoing operations, which we currently do
by monkey-patching the corresponding volume object. However while the
underlying GVolume object indeed remains the same through-out the
operation, the JS wrapper object isn't referenced anywhere and may
thus be garbage collected, resulting in a stuck dialog.
Fix this issue by tracking active operations explicitly, so that all
involved objects are referenced until the end of the operation.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/565
Whenever a command runs in the run dialog, it
will be added to the history unless it is
already the last entry. This does not apply
for entries that are not consecutive, which can
result in long chains of commands which
alternate, e.g. lg, r, lg, r, lg, r. Not only is
this wasteful in terms of space, but also
inconsistent with how history works elsewhere,
e.g. in the shell.
Therefore, remove entries in the history that are
equal to the one that will be added to the end of
of the history when the entry already exists.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/524
The `hints` and `settingName` parameters to the agent call may define
the specific list of secrets NM actually needs from the user. This
seems to have been the intended use of these two parameters but only
recently did NM with the IWD backend start to use this to request 802.1x
secrets. So if `hints` is provided, ask user for the specific secrets
listed there and don't even look at what type of EAP method is in use.
Only the three types of secrets actually in use by NM's IWD backend are
supported for now -- they happen to be the same three that
_get8021xSecrets() had already supported.
gjs now relies entirely on introspection data to determine parent
types and implemented interfaces, so in order to have all methods
and properties resolve correctly, we must include the corresponding
GIRs of all types used.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/574
This attribute was previously only assigned in show(). hide() compares
this attribute to 0. If hide() is called before show() is first called,
the comparison would give the correct result (undefined > 0 is false)
but log a warning:
JS WARNING: [resource:///org/gnome/shell/ui/workspacesView.js 529]:
reference to undefined property "_restackedNotifyId"
Initialize this attribute in _init(), alongside _scrollEventId and
_keyPressEventId which are also used in hide().
dialogContent is set to one of the elements of the list DialogContent,
but not all of those have a checkBoxText property. When logging out (as
opposed to shutting down), this causes a warning:
JS WARNING: [resource:///org/gnome/shell/ui/endSessionDialog.js
763]: reference to undefined property "checkBoxText"
(The line number corresponds to this line in 3.28.3.)
The warning is apparently not triggered if the undefined property is
used as part of a boolean expression:
gjs> var x = {};
gjs> x.a;
typein:2:1 strict warning: reference to undefined property "a"
gjs> if (x.b) { log('oh no'); }
gjs> x.c || ''
""
_setCheckBoxLabel() just checks the truthiness of its 'text' argument,
and the empty string is false-y, so passing '' rather than undefined has
no functional effect.
In recent Fedora 29, connecting to wifi access points from the
user menu (top-right menu) does not work. Clicking the 'Connect'
button just animates it but does nothing else. The logs show an
error "JS ERROR: Error: Expected type utf8 for Argument
'specific_object' but got type 'undefined'".
Looking into this, it seems the problem is these uses of the
`path` property of an NMAccessPoint. NMAccessPoint inherits
from NMObject, and NMObject *does* have a path property:
https://developer.gnome.org/libnm/stable/NMObject.html#NMObject--path
so at first glance this seems fine. But I poked around a bit
using libnm via Python (which goes via introspection, just like
this JS code does), and found that indeed AccessPoint objects
don't seem to have a `path` property there either.
Looking at the libnm code, this actually makes sense, because
the property is marked "(skip)":
https://github.com/NetworkManager/NetworkManager/blob/master/libnm/nm-object.c#L1291
and the introspection docs suggest that means it should be left
out of introspected output:
https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations#Symbol_visibility
I'm a bit concerned that this was only found recently - whereas
the change to use `.path` in gnome-shell dates from October 2017
(d71af5e5) and the property has been marked (skip) in NM since
at least 2016 - but this all seems to add up. The obvious fix is
to replace use of `.path` with `.get_path()`, which returns the
path and is *not* marked (skip) and so *is* available via
introspection. I tested that this works in Python and also did
a test build of gnome-shell with this change and installed it on
an affected system, it does seem to fix the bug.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Commit a76b28bd moved the dbus-interfaces to the
dbus-interfaces directory without changing the
path for docs build as well, resulting in a fail
of the build when building with gtk_doc=true.
So change the path in the build accordingly to
ensure that the build does not fail when building
with gtk_doc=true.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/236
gjs's D-Bus convenience explicitly expects a string representation
of an interface, but the new convenience method to load an XML
description from a resource introduced in commit f42d9df3e0 only
returns a string when using gjs from the GNOME 3.30 release. We
have so far managed to keep compatibility with the previous stable
gjs release, so fix up the fallback code to cast to string.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/578
Commit dbf993300a moved all inline D-Bus interface descriptions to template
strings so we can stop escaping line breaks.
Unfortunately that unveiled a grave bug in xgettext, which currently cannot
handle files that contain both backtick and slash characters - as a result,
translations from affected files have started to disappear as translators
run xgettext/msgmerge.
Instead of reverting the change and getting the crusty escaping back, we
will take this as an opportunity to stop inlining the XML altogether and
load it from a resource instead.
To facilitate that, add a small helper method that loads a D-Bus interface
description from a dedicated resource bundle.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/537
We'll soon move the inlined XML of all interfaces we export or consume into
separate files. That's a significant increase from the interfaces for which
we install documentation, so it makes sense to use a dedicated subdir.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/537
In GNOME-3.24, pressing Super+P or a similar function key would cause
a switch to the next available monitor configuration.
However, in GNOME-3.26, this was reimplemented in mutter and gnome-shell
and the behaviour is now different: pressing Super+P and releasing will
cause no change in montor configuration[1]. In this new design you have
to press Super+P and keep holding Super in order to keep the switcher
open, then press P again (or use the arrow keys or mouse) to
select the next one in the list.
This is incompatible with many Asus products such as Asus X530UN, where
pressing the presentation mode media key (Fn+F8) actually generates
the following keypress events from the keyboard controller:
Fn pressed: nothing
F8 pressed: nothing
F8 released: Super press, p press, p release, Super release (quick burst)
Fn released: nothing
With this firmware behaviour it's not possible to hold the keys and have
the dialog come up so that you can select another new mode.
To solve this, when the switcher is opened, select the next available
display config by default, which is more similar to the pre-GNOME-3.26
behaviour. Now pressing Fn+F8 on this laptop will result in the display
mode switch taking place.
[1]: The mentioned desired behaviour will at least happen after
https://gitlab.gnome.org/GNOME/mutter/issues/281 has been fixed
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/208
Since we always keep the active workspace until the user switches
to a different one, we may end up with two empty workspaces at
the end. It's not obvious to users why this happens, and there's
indeed no good reason for the behavior - just remove the trailing
workspace in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/536
There's no relation between a window being hidden from overview/taskbars
and a window not being closable - currently we effectively disable the
fallback quit action for any application with open transients, which
simply doesn't make sense.
Instead, only exclude windows for which the close action has been
explicitly disabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/217
Meta.ScreenDirection no longer exists. This fixes window menus on
multi-monitor systems.
JS ERROR: TypeError: Meta.ScreenDirection is undefined
_buildMenu@resource:///org/gnome/shell/ui/windowMenu.js:135:17
