We have initTranslations() for binding an extension's
gettext domain, but nothing to help with using gettext
from an extension.
Such help would be useful though, as an extension that
calls textdomain() like a normal application would
inadvertently changes the default domain for the whole
gnome-shell process.
Instead, extensions have to use domain-specific versions
of the gettext functions:
```js
const Gettext = imports.gettext.domain('my-extension');
const _ = Gettext.gettext;
```
Make this a bit easier by adding those functions directly
to the extensions object when initTranslations() is called,
then expose helper functions for calling them.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2594
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1941>
Regex are a crude tool for analyzing whether some code *calls* a
particular function. Spidermonkey has Reflect.parse() that returns
the AST of the passed in code, which allows for a much more precise
check for javascript.
The old script is still used for C code, where i18n-affecting changes
are much rarer.
Based heavily on Philip Chimento's mozjs migration script at
https://gitlab.gnome.org/ptomato/moz60tool.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1941>
The value can not actually be null at that point, but it's too
hard to spot for tools like coverity:
- before setting view, we chain up to the parent's acceptDrop()
- that calls _canAccept(), which we override and check for the view
Still, and extra ? doesn't hurt, and hopefully will make the tooling
happy.
CID 351269
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1950>
There is now a location portal that provides a similar role
as our agent. Settings supports that portal in its application
panel, which allows users to revisit their choice later.
Unfortunately it uses a different permission store table, so
any permissions granted (or denied) through our agent won't
show up there.
To change that, switch to the same table as the portal/Settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1945>
On startup desktop-icons-ng Wayland windows have skip-taskbar==FALSE so
initially pass `_isOverviewWindow` and they get added to the overview,
which is confusing to users. However almost immediately after that they
get `meta_wayland_client_hide_from_window_list` and are removed from
future overviews. So now we respond to `notify::skip-taskbar` immediately
and prevent desktop-icons-ng appearing in the startup overview too.
This is messy and ideally we'd like to know the window type immediately
on creation, but that option only exists in X11 and not Wayland.
https://gitlab.com/rastersoft/desktop-icons-ng/-/issues/137https://bugs.launchpad.net/bugs/1936643
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1925>
At least the last stable release of gjs has an issue with async
handlers for custom (i.e. defined in JS) GObject signals.
The handler still works, but evoking it prints the following warning:
JS ERROR: Error: Could not guess unspecified GValue type
We can avoid the warning by using the addAction() convenience
method, which makes for a small nice cleanup anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4531
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1938>
If an actor is not on any stage view, then it doesn't have a valid
resource scale, which will hit an assert later.
When that is the case (for example when running headless), we expect
that there is no valid theme node (yet) either, so simply moving
the clutter_actor_get_resource_scale() call after peeking at the
theme node is enough to avoid the crash.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4522
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1935>
The PointerWatcher passes the current pointer position to every watch,
so we don't have to query the pointer again scrollToMousePos() is used
as watch callback.
While that should be the only use, be conservative and still query the
pointer when called without arguments.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1932>
Right now the Show Password menu is shown unconditionally for password
entries, ignoring the org.gnome.desktop.lockdown disable-show-password
key.
StShellEntry now honors that key for its peek icon, and there's little
reason for the peek icon and the menu to ever be out of sync.
This commit forces the menu and the icon to always be in sync, and
so makes the menu lock down work automatically, too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/687>
There's now a setting
org.gnome.desktop.lockdown disable-show-password
that ostensibly lets admins prevent from users from
showing their password in password dialogs.
gnome-shell currently ignores this key.
As a first step, this commit adds the setting to StSettings.
Future commits will use the new setting.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/687>
Most of the keys are aligned, but "screen-magnifier-enabled" isn't.
This commit lines all the keys up, giving a little more breathing
room for future keys that have longer names.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/687>
Since we correctly call the `style_changed` vfunc superclass at the end
of our own function anyway, the style changes will get propagated to the
children of the scrollView inside `st_widget_real_style_changed` anyway.
So remove those unneeded and quite expensive (because they cause the
theme node to be regenerated) calls to `st_widget_style_changed`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/953>
