When not logged in, the New Issue URL only redirects to an unhelpful
login page while the Issues page allows you to search for existing
issues and still offers a "New Issue" button.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3377>
Even if an invalid syntax doesn't make glib-compile-schemas error out in this
case, ensure the file is valid XML to appease third-party parsers.
Signed-off-by: Gabriel Nagy <gabriel.nagy@canonical.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3281>
The ID is currently hard-coded to the non-development one, with
the result that the .Devel app effectively doesn't have any
metainfo.
Fix that by configuring the file with the correct ID.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3158>
The `state-set` signal is emitted to change the underlying state,
which can have two reasons:
1. the user toggled the switch
2. the extension's `enabled` state changed externally
In the second case, calling enable/disable is pointless at best,
and can mess up the expected state by permanently disabling an
extension that was disabled because of the global kill switch.
Address this by only calling enable/disable if the new state does
not already match the current value of the `enabled` property.
Close https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7305
Fixes: fec523f83f ("extensions-app: Use new 'enabled' property")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3090>
The switch for enabling/disabling extensions currently bases its
state on the extension's ACTIVE state.
This is problematic in the enabled-but-inactive case, because
activating the switch tries to change the state from off to on,
which leads to enabling an already enabled extension (an obvious
no-op).
The new `enabled` property allows us to do better, and use delayed
state changes where the switch position represents the `enabled`
state, and the trough color whether the extension is ACTIVE.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7004
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3073>
The ENABLED state means that an extension's `enable()` method
was called successfully.
This usually matches whether an extension *should* be enabled
according to the enabled-extensions/disabled-extensions settings,
but not necessarily: If an extension had an error or does not
support the currently active mode, its actual state is different.
We currently only expose the actual state to external tooling,
but whether an extension should be enabled is relevant as well,
for example to disable a lock-screen only extension from the
regular session.
For that purpose we will expose a separate `enabled` property.
To avoid confusion with the existing states, change the exposed
names to (IN)ACTIVE.
This does not affect the D-Bus API, as the numeric values of
the states remain unchanged.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7004
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3073>
The newly added developer name syntax appears not implemented
across related platforms: GNOME Software, Flathub, etc.
There is no harm in using both deprecated and newly introduced
tags together, and neither appstream-glib nor appstreamcli
fails to validate this usage.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3079>
- Use the `<developer><name>` tag instead of the deprecated `<developer_name>`
- Implement appstreamcli for extra appdata validation
- Fix a release description
- Update the donation URL
- Add the translation tag
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3071>
After the last rounds of redesign, it's time to update
the appdata accordingly:
- update screenshots
- add screenshot captions
- point homepage to apps.gnome.org
- mark as mobile adaptive
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3067>
Manually adding and removing rows to dynamic lists is rather
old-fashioned, GTK 4 strongly encourages the use of models.
Modernize the code by exposing extensions as ListModel, and
bind it to the two lists with appropriate filters.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3067>
Most properties that determine the availability of an action are
not expected to change, but now that extensions are represented
as a GObject, we can just generically set up bindings for all
actions instead of explicitly tracking the properties that we
expect to change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3067>
